## 4 Local Updates to Handle Mobility of Sensors for Geocasting  
For handling changes in routing trees and local convex hulls due to mobility of nodes, the global updating is triggered periodically by sinks. One of the drawbacks of this approach is that a mobile node has to wait for the next global update for addition of itself to its new neighborhood, _i.e._, selecting a new parent. Until next global updating, the mobile node will be disconnected from the network since it does not have a parent. Moreover, global updates periodically rebuild all routing trees and the local convex hulls of all nodes to ensure the routing structure is up-to-date. This approach updates even the tree branches which are not affected by the mobile nodes and consumes energy for unnecessary updates. In this work, we introduce _local updates_ initiated by the mobile sensors to update only the subtrees affected by mobility of nodes. In local updating, each mobile node decides its updating frequency based on its mobility and therefore does not have to wait for a global mechanism to select a new parent node. Local updating provides a continues process to keep track of changes in the network. With local updating mechanism, the removal of a mobile node from its old neighborhood and the addition of a mobile node to its new neighborhood are done in a timely manner. In addition, local updating mechanism is more efficient since local updates are limited in scope meaning that only the tree branches affected by mobility are updated. In the following, we give the details of the local updating mechanism. When a mobile node (MN) moves from one location to another, it may change its neighborhood, including its parent and child nodes. As result of mobility, the child nodes of the MN may need to re-associate themselves to another parent node and/or the MN may need to re-associate itself to a new parent node. Figure 3 shows an example of nodes and local convex hulls that are affected by the mobility of a node. MN and one of the child nodes (_i.e._, C\({}_{2}\)) have to associate themselves with new parent nodes (_i.e._, P\({}_{New}\) and PC\({}_{new}\)) after the movement of MN. Also, the convex hulls of new parent nodes (_i.e._, P\({}_{New}\) and PC\({}_{new}\)), and old parent nodes (_i.e._, P\({}_{old}\) and MN) change due to mobility. In the following we explain how to detect these changes by the neighbors of MN and how to update accordingly the tree and the convex hulls of the affected nodes. As shown in Figure 4, the neighbor list of a MN consists of the child nodes (_i.e._, Node C\({}_{1}\) and C\({}_{2}\)) and a parent node (_i.e._, Node P) of MN and the other close-by nodes (e.g., Node N). To inform neighbors about its movement, MN periodically broadcasts _beacon_ packets called MN_BEACON. The frequency of MN beaconing depends on the transmission range, speed of MN, and a parameter \(k\) (_i.e._, _beaconing parameter_) reflecting the characteristics of the network. The following equation shows how the frequency of MN beacon packets is calculated:  
\[\texttt{MN\_BEACON\_INTERVAL}=\frac{R_{TX}}{V_{MN}}\times k \tag{1}\]  
Figure 4: Beaconing to handle mobility of MN in the routing tree. Figure 3: Effects of movement of MN on the routing tree and convex hulls. where \(0<k\leq 1\), \(V_{MN}\) and \(R_{TX}\) denote the maximum mobile node speed (m/s) and the maximum radio range (m), and \(\frac{R_{TX}}{V_{MN}}\) is the time to leave the transmission range. The parameter \(k\) helps to determine how often a MN_BECON packet should be sent to achieve prompt updates. It can be designated based on the network characteristics such as node density. The effect of the parameter \(k\) on the performance of the local updating is evaluated with simulations in Section 5.5. It is important to note that MN_BEACON_INTERVAL is the local update rate since it is determined by the speed of MN. Each mobile node in the network has its own beaconing (updating) interval. Figure 4 shows the content of a MN beacon packet.