# A Survey on Congestion Control for RPL-Based Wireless Sensor Networks
## 4 Congestion Control Schemes for RPL
### Schemes Exploiting Path Diversity
#### 4.2.2 Multipath Opportunistic RPL Algorithms
The first term approximates the expected delay from node \(i\) to any forwarder, the second term the expected delay from a forwarder to the sink. The forwarder set \(F_{i}\) consists of \(i\)'s neighbor nodes \(j\) that provide routing progress, i.e., \(EDC(j)<EDC(i)-w\), where \(w\) is a weight for the balance between opportunism and the number of hops. The authors evaluate ORPL using the Indriya testbed [50] consisting of 135 telosB nodes. The ContikiMAC which they used has a phase-lock mechanism where senders record their neighbor's wake-up phase, and use it to make the next transmissions cheaper. To avoid losing synchronization when long wakeup intervals are used, they extended the ContikiMAC default phase lock guard time from 15 to 63 ms. Evaluation results show that in a data collection scenario, ORPL outperforms the basic RPL, collection tree protocol (CTP) [51], opportunistic routing for WSN (ORW) [52], and low-power wireless bus (LWB) [53] in terms of packet delivery ratio, end-to-end delay, and duty cycle used as a metric for energy efficiency. For one-to-many and any-to-any traffic, ORPL outperforms RPL in terms of latency, PDR, and duty cycle. However, the authors state that since duty-cycled anycast used by ORPL sometimes causes multiple nodes to forward the same packet and to generate duplicates, they filtered out duplicates at the routing layer to reduce unnecessary forwarding. Experimental results show that the duplicates accounted for 9% to nearly 50% of the total traffic. The authors point out that this is an inherent drawback of ORPL, which is exacerbated as the wakeup interval decreases. Also, [PERSON] et al. point out that the routing set for downward routing cannot be used with the nonstoring mode of operation [42]. **ORPL-LB. ** Motivated by the fact that ORPL cannot avoid energy hotspots without an explicit load balancing policy, [PERSON] et al. propose ORPL-LB [33], a load balanced extension of ORPL. Like ORPL, ORPL-LB enables the receiver to make a forwarding decision. That is, the sender node transmits continuously until any of its neighbors wakes up, receives the packet, decides to forward it and acknowledges it. However, ORPL-LB considers a wake-up interval which affects a node's availability as a forwarder in the future. Each node adjusts its wake-up interval continuously to reach the target duty cycle, which is pre-defined or determined at runtime. If the average duty cycle is lower than the target duty cycle, the node decreases the wake-up interval in order to reach the target. This causes lightly loaded nodes to wake up more frequently and to hear and forward more traffic. As a result, these nodes' loads increase whereas their overloaded neighbors' loads decrease. Conversely, a node with a high duty cycle increases its wake-up interval, which leads to reduction of traffic load and idle energy consumption. The authors evaluated performance using a periodic data collection scenario in the Indriya testbed which had about 93 Tmote Sky nodes. For ORPL, they set the wakeup interval to 500 ms which was optimal for the experiment. Experimental results show that compared to ORPL, ORPL-LB reduces the highest duty cycle at the cost of increasing the average duty cycle slightly. Reducing the highest duty cycle means that energy consumption is better balanced between nodes. By making many nodes fail almost at the same time, ORPL-LB extends the network lifetime by 33% compared to ORPL. **ORPL-DT. ** [PERSON] et al. observed that ORPL suffers from unreliable routes when downward traffic is dominant [34]. The reason is that since ORPL updates routing metrics using upward packets only, it fails to provide up-to-date EDC information if there is a lack of upward traffic. To enhance ORPL for diverse traffic patterns, the authors propose ORPL-DT (ORPL for diverse traffic) [34] which constructs reliable routes in diverse traffic scenarios by exploiting both upward and downward packets to update the EDC metric which ORPL uses.