# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 4 Enhanced Routing Solutions for Internet of Things Networks
### Mobile Nodes' Support  
In addition multicast transmission, the support for mobile nodes also represents an important task for the majority of applications in IoT environments, mainly in urban and industrial scenarios. Thus, an efficient mobility support protocol should provide fast, continuous, and reliable communication among mobile and static nodes. Hence, in [73; 74], the authors presented a variation of RPL based on the Corona mechanism (Co-RPL), which aims to ensure the quality of service in LLNs with mobile nodes. Co-RPL uses the default RPL control messages with additional fields to fulfill its purpose. All network nodes maintain a table with information about their neighbors (ID, DAG, corona, and link quality). When a node receives a DIO message, it selects its best parent, defines its corona ID, and computes its rank based on the objective function. The corona ID is determined through the result of the sum of the lowest corona ID among its neighbors plus one. After updating the DIO, the node resends the message in a broadcast. If a router node receives other DIO messages, it must select the preferred parent among the neighbors with the lowest corona ID. Whenever the corona ID of a neighbor changes or a new neighbor is detected, the node should execute the neighbor discovery process to update the corona IDs. Co-RPL proposes a new path recovery mechanism. When a node cannot reach the message destination, it sends the data packet to any node of the upper corona ID and sends a DIS message to its children to pause the sending of the data packet. This process occurs until the router node finds a new preferred parent. If a node cannot send the data packet to any neighbor of the high corona ID, it must inform the previous hop to pause the sending of data packets. [PERSON] et at. [75] proposed the mRPL, a solution to enhance the mobility support in RPL. The proposed solution integrates the default RPL with smart-HOP [76; 77], a hands-off mechanism initially developed for WSN. In mRPL, smart-HOP uses RPL-control messages like beacons. Considering the existence of two different types of nodes, which are Mobile Nodes (MN) and serving Access Points (AP), the smart-HOP mechanism is divided into two phases. In the data transmission phase, an MN sends a sequence of \(n\) DIS beacons to a serving AP. After receiving the \(n\) DIS, the serving AP calculates the Average Received Signal Strength Indication (ARSSI) value based on the \(n\) received messages and sends the obtained value to MN inside a DIO message. If the MN detects that the received ARSSI is lower than a defined threshold, the discovery phase begins. In this phase, an MN sends DIS control messages periodically until it receives a DIO message from an AP with an ARSSI greater than the defined threshold. When this condition is fulfilled, the MN returns to the data transmission phase with a new preferred parent. An MN can also start the discovery phase after detecting that its serving AP parent is not sending DIO messages. It is important to note that the messages exchanged in these two phases are disassociated from the data messages and control packets of RPL. Thus, mRPL nodes can coexist and interoperate in the same network when nodes execute default RPL. Considering the necessity of mobility support for healthcare and medical applications, [PERSON] et al. [54] proposed an adaption of RPL named mod-RPL. The approach contemplates applications executed over networks containing both mobile and static nodes. Thus, to attend to the routing requirements, the mod-RPL configures all mobile nodes as leaves of the DAG created by RPL. Therefore, mobile nodes are unable to send DIO messages and, consequently, be a parent of other nodes or perform routing tasks. The operation of the static nodes is equal to the default RPL. However, mobile nodes must not create or forward DIO messages, avoiding the creation of sub-DODAG and connection loss with possible child nodes.