# CoAR: Congestion-Aware Routing Protocol for Low Power and Lossy Networks for IoT Applications
## 3 The RPL and Problem Description
### Problem Description  
RPL was initially designed for light traffic network. However, IoT applications in an emergency scenario sometimes make prompt responses which result in heavy and dynamic traffic. In this situation, RPL cannot handle the traffic well. The consequence is the network faces severe congestion problem which results in packet loss and delay. As the resource constrained devices are considered in RPL, the majority of the packets are lost due to the buffer overflow in a congestion situation. The problem becomes more critical when the child node does not change their current parent and keep sending data traffic even though parent node is in serious congestion. Here, we classify the RPL congestion problem and consequences as follows: First, the routing metrics used in the default OFs do not reflect the congestion situation, therefore, nodes cannot be aware of congestion. In this circumstance, the affected node cannot indicate the presence of congestion. As a result, the child nodes do not change their current parent which is suffering from congestion. This is because the OFs allows each node to select their parent which has a reliable link (ETX) and shortest distance (hops) to root, regardless of congestion. In fact, the children of the congested node cannot know the congestion status of their subordinate parent. It is due to the fact that trickle is not aware of congestion and therefore cannot send congestion notification timely. In addition, RPL is implemented on resource constrained devices with a smaller queue size. Small queues start to overflow before traffic congestion becomes heavy enough to be recognized using ETX [5]. Second is the parent selection technique in the RPL among the node with the equal rank. To better understand the problem, consider the network topology as shown in Figure 2. Let us consider the rank of the nodes 3, 4 and 5 are equal and node 4 is overloaded compared to 3 and 5. These nodes are elements of the candidate parent set of nodes [10; 13; 14; 15; 16]. In this circumstance, the network's resource is not properly balanced, which may create congestion in the future. Under low data traffic, node 4 may successfully forward data packets to the root node. However, if an event occurs in the sensing region, the node starts to send heavy traffic to their parents. In this situation, node 4 faces severe congestion because of the imbalance load. Thus, large number of packets are lost at buffer of node 4.  
The packet loss occurs due to the default OF, because it selects the parent merely based on a single metric. Although ETX typically gives a reasonable estimation of the link status, using merely ETX to select the parent is not enough to balance the load in the network. When a node wants to join the network or change its parent, it selects the parent with the smaller rank. As a result, if node 4 propagates smaller rank, it attracts the nodes so that the nodes select it as their preferred parent without considering how much it is overloaded. Node 13 or 15 may change their parent after network topology reconstruction. However, this may not be an efficient solution; instead, the balance parent selection should be achieved at the beginning of the route construction. To address this problem, we design a new metric that selects the parent in a balanced way by checking the number of child nodes associated with the parent nodes.  
Figure 2: Destination oriented directed acyclic graph (DODAG) topology in RPL: (**a**) Parent selection problem; and (**b**) Topology construction based on the proposed scheme.