# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 3 Routing Protocols for Low-Power and Lossy Networks
### Rpl
In storing without multicast MOP (MOP 2), downward routes are also supported, but are different from MOP 1; the nodes maintain, individually, a routing table constructed using DAO messages to provide downward traffic. Hence, downward forwarding occurs without the use of the root node, as illustrated in Figure 2b. Storing with multicast MOP (MOP 3) has a functioning similar to MOP 2 plus the possibility of multicast data sending. This type of transmission permits the non-root node to send messages to a group of nodes formed using multicast DAOs. In RPL, the whole process of DODAG construction is highly dependent on the OF considered by the network. Furthermore, the network performance is directly linked to the process of route selection. According to the metrics and constraints applied to select the best path between a node and a root, it is possible to increase or decrease the network performance. Furthermore, as already explained, some applications require different performance of the routing protocol. For example, e-health applications need low latency and high reliability [54]. On the other hand, some applications may require low energy consumption and mobility, such as animal monitoring applications. Thus, different types of applications can require different OFs. To fulfill the application requirements, each OF should contemplate metrics or constraints that better attend to these conditions. Based on the information of OFs, the node computes the weight of each path to the root. Hence, the selection of preferred parent and the rank calculation are performed according to OF: IETF defines, as the standard, two different objective functions: Objective Function zero (OF0) and Minimum Rank with Hysteresis Objective Function (MRHOF). Objective Function zero (OF0) [55] is defined in the RFC 6552 and is designed to find the shortest path to the root. Using the DOI message information, OF0 knows the rank of each candidate  
Figure 1: Traffic patterns supported by RPL. Lines with arrows indicate the traffic flow, while dotted lines without arrows indicate the links of the routing topology. Figure 2: P2P message forwarding using Mode Of Operations 1 (MOP 1) and MOP 2. Lines with arrows indicates the traffic flow, while dotted lines without arrows indicate the links of routing topology. neighbor. OF0 selects, as the preferred parent, the candidate neighbor with the best rank (the shortest). Additionally, OF0 stores a backup feasible successor to use as an alternative to the preferred parent. All the upward traffic received by the node is routed to the root using the preferred parent or the backup successor, according to the link conditions. OF0 does not attempt to perform any load balancing. The backup successor is used to forward a packet to the root node when it is not possible to use the preferred parent. The rank of a node is obtained through the sum of the rank of its preferred parent and the value of _rank_Increase_, which is computed using a specific equation and predefined variables [55]. The Minimum Rank with Hysteresis Objective Function (MRHOF) [56] was developed to select the path with the lowest path cost without promoting excessive changes of the preferred parent. Thus, MRHOF uses two mechanisms to fulfill this purpose. The first seeks to find the path with minimum cost, while the second performs the hysteresis. Using the hysteresis mechanism, a candidate parent is selected as the preferred parent only when it has a path cost smaller than the current preferred parent, minus a given threshold [57]. Usually, MRHOF uses the ETXrouting metric to compute the cost of each path. However, it can utilize any additive routing metric described in [58]. During the network functioning, the path cost is re-computed periodically. Nevertheless, the preferred parent selection process is executed just when the path cost for a neighbor is refreshed or a new neighbor is inserted in the neighbors' table.