## 2 Related Works
### Mobility-Aware RPL Routing  
Mobility creates an inconvenience for all layers of the protocol stack, especially the routing protocol. While RPL supports infrequent joining and leaving of nodes, it performs poorly upon the dynamics imposed on the network topology. The authors in [16], survey the enhancements made to RPL to support mobility and focus on the specific mechanisms that have been altered. A more recent survey [17] classifies mobility extensions of RPL into solutions including (i) only mobile nodes (e.g., VANETs) and (ii) those with a fixed infrastructure as well as mobile nodes. One of the extensions of RPL that addresses mobility of nodes is BRPL [18], which combines backpressure routing [19] with the objective functions of RPL. To support high-throughput traffic, BRPL takes into consideration the queue backlogs of the neighbors. This allows BRPL to utilize sub-optimal routes when the optimal route is congested. In mRPL [13], MN operates in two phases of data transmission and discovery. In the _Data Transmission phase_, static nodes (SNs) constantly monitor the link quality and compare the Received Signal Strength Indication (RSSI) measurements to a threshold \(T_{l}\) that indicates the minimum RSSI threshold in a reliable channel. If the link quality crosses the threshold, the SNsnotify the MN with a beacon, and then MN stops transmitting data packets and instead starts the _Discovery Phase_ by sending DIS packets to request the neighboring SNs to respond with DIO packets. Then the MN analyses the received DIO packets, and if the RSSI values from other SNs are higher than \(T_{h}\), it performs the handoff process and resumes data transmission, otherwise, it continues sending DIS packets. An enhanced version called mRPL+ [20], relies on overhearing of mobile nodes' packets by alternative parents. Then mRPL+ takes a similar approach to mRPL by selecting the preferred parent based on some thresholds. For the case where all nodes are mobile, [PERSON] et al. [21] adjust the Trickle timer according to mobile nodes' velocity, and utilize geographical information as the routing metric. If the mobile nodes are not equipped with IMU sensors, _Doppler Effect_ can be used to estimate their velocity as explained in [22]. [PERSON] et al. [23] introduce D-trickle to support mobility, where the chosen DIO interval depends on the number of neighboring nodes. In a dense network, D-trickle sends DIO packets less frequently but for a sparse network, frequent DIO packets boost the connectivity of the network. [PERSON] et al. [24] propose RL-Probe for using reinforcement learning methods to determine when to send probing packets to estimate link qualities. Using RL and multi-armed bandit theory in RPL minimizes the communication overhead while keeping the network responsiveness at a high level. Another approach has been implemented in GTM-RPL, which is based on game theory to select the optimal transmission rate of the nodes [25]. The authors prove the existence of Nash Equilibrium. In other words, each node can reach an optimal strategy with no incentive to change while other nodes keep their current strategy. In the next step, nodes select the preferred transmission rate based on the mobility of nodes (detected by RSSI) and other parameters. This approach is only practical in applications where the transmission rates can be manipulated. ARMOR [26] is a recent work that calculates the time each parent is available based on location data and selects the node with the so-called longest \"Time-To-Reside\". We use ARMOR as a benchmark in our work, and we will further explain it later in Section 5.1. RMA-RP [27] introduces a similar metric called \"Time-To-Stay\" using only two recent RSSI measurements. The choice of this metric is debatable since these two models may choose links that are active for a long time but are lossy since stability is interpreted with the duration of the connection rather than the link quality. This metric manages to reduce the number of performed handoffs and preserves energy consumption.