# 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  
**Multipath opportunistic routing by sender's decision. ** [PERSON] et al. propose a multipath opportunistic RPL over IEEE 802.15.4 to support delay-sensitive alarm applications [32]. In this scheme, each packet is assigned a deadline according to the class of service, and each node has packets ordered by their deadlines in the queue. Whenever a packet is dequeued for transmission, the node tries to find a parent candidate to which the packet is correctly transmitted within the local time budget constraint. Since the authors consider the IEEE 802.14.5 in beacon-enabled mode, the transmission delay means the delay until the superframe of the candidate starts plus the average delay until the candidate correctly receives the packet. If more than one parent candidate can satisfy the delay constraint, the one with the least ETX is selected. As a consequence, a node opportunistically forwards packets over multiple parents on a per-packet basis. For efficient interoperability between multipath RPL and IEEE 802.15.4, they modified the cluster-tree formation mechanism of IEEE 802.15.4 so that a node can associate with several parent nodes by adequately organizing superframes at the MAC layer. For performance evaluation, the authors compared the opportunistic RPL with the basic RPL using WSNet/Worldsens simulator in which they ported the Contiki RPL implementation. For the MAC layer, beacon-enabled IEEE 802.15.4 was used. The two RPL versions both took advantage of the 802.15.4 superframe scheduling in order to adaptively choose a parent. Simulation results show that the opportunistic RPL improves delay and packet delivery ratio for the traffic types with the delay constraints. Although the primary goal of this scheme is to satisfy the delay constraint rather than to reduce congestion, the simulation results show that the scheme can enjoy improved network lifetime and fairness since traffic is spread more uniformly over all feasible parents. **ORPL. ** ORPL [27], proposed by [PERSON] et al., is an opportunistic routing protocol that supports any-to-any, on-demand traffic as well as upward and downward traffic. In ORPL, a node anycasts a packet instead of choosing a next hop and then forwarding a packet to it. For upward routing, a next hop is selected during transmission. That is, the first neighbor that (1) wakes up, (2) successfully receives the packet, and (3) is the closer to the root, is supposed to acknowledge the packet and forward it. Therefore, forwarding decision is made at the receiver rather than at the sender. This is one of the major differences between ORPL and the opportunistic RPL proposed by [PERSON] et al [32]. For routing downwards, ORPL uses the notion of 'routing set'. The routing set of a node, which is the set of nodes in the sub-DODAG rooted at the node, provides the information on whether a node is on a path to the destination or not. A node forwards a packet downwards if the node (1) wakes up, (2) successfully receives the packet, (3) is farther from the root, and (4) has the destination in its routing set. For any-to-any traffic, a packet is routed upwards to a common ancestor, and then downwards to the destination. ORPL aims to achieve space efficiency and scalability by using routing sets instead of routing tables and by adopting bitmaps or bloom filters to store routing sets. As a routing metric, ORPL uses EDC (Estimated Duty Cycled wake-ups) [49] which reflects the expected number of duty cycled wakeups required to reach the root. EDC is an adaptation of ETX for energy-efficient anycast routing. The EDC of node \(i\) is computed recursively as follows. \[EDC(i)=\frac{1}{\sum_{j\in F_{i}}p_{ij}}+\frac{\sum_{j\in F_{i}}p_{ij}EDC(j)}{ \sum_{j\in F_{i}}p_{ij}} \tag{15}\]  
where \(F_{i}\) is the set of node \(i\)'s forwarders, \(p_{ij}\) is the probability that node \(i\) successfully sends a packet to node \(j\).