## 4 Local Updates to Handle Mobility of Sensors for Geocasting
An MN_BEACON packet contains the ID of MN, frequency of the beaconing, and parent ID of MN. Messaging during the local updates is illustrated in Figure 5. In the figure, MN broadcasts a MN_BEACON packet at time t\({}_{0}\). The receivers of a beacon packet first check who sent the beacon. The receiver node can be (i) the parent node P of MN, or (ii) a regular neighboring node N of MN, or (iii) a child node C of MN. Every node that receives a MN_BEACON packet sends an acknowledgement (_i.e._, ACK) message back to MN initiating the beaconing as shown in Figure 4. However, the content of the acknowledgement message is determined by the relationship between MN and the receiver node:  
* When a regular neighboring node N or the parent node P of MN receives a MN_BEACON packet, the receiver node sends an ACK_BEACON packet back to MN. Figure 5 shows that the parent node P and the neighbor node N send ACK_BEACON packets back to MN at times t\({}_{1}\) and t\({}_{2}\), respectively. An ACK_BEACON packet includes the ID of the node, the sink ID which this node is connected to, and the number of hops to the sink as shown in Figure 4.  
Figure 5: Messaging during local updates. * When a child node of MN receives a beacon from MN, the child node sends an ACK_CHILD packet back to MN. Figure 5 shows that the child nodes C\({}_{1}\) and C\({}_{2}\) send ACK_CHILD packets back to MN at times t\({}_{4}\) and t\({}_{5}\), respectively. An ACK_CHILD message includes the convex hull (_i.e._, coordinates of convex hull) of the child node as shown in Figure 4.  
It is important to point out that when the parent node or a child node of MN receives a beacon, it starts to wait for another beacon from MN (at times t\({}_{01}\) and t\({}_{02}\) in Figure 5). After the beacon interval passes, MN sends another MN_BEACON packet at time t\({}_{10}\) as shown in Figure 5. If the child node of MN does not get another beacon (since MN moves out of communication range of the child node) in the time period (beacon interval) specified in the MN_BEACON packet, it starts to _search for another parent_ at time t\({}_{11}\) (details in Section 4.5). If the parent node of MN does not receive another beacon within the beacon interval (since MN moves out of communication range of the parent node), it _removes the convex hull of MN from its local convex hull_ at time t\({}_{12}\) (details in Section 4.4). After waiting for ACK packets from its neighbors, MN executes the following actions: _(i)_ If MN does not get an ACK from a child node, it updates its convex hull and propagates the changes up on the tree (child node invalidation, see Figure 6(a)), and _(ii)_ If MN does not get an ACK from its previous parent node, it selects a new parent and propagates the convex hull up and the new hop count level down the tree after new parent selection (parent node invalidation, see Figure 6(b)). From Section 4.1 to Section 4.5, we mainly discuss two fundamental operations of local updating mechanism: (i) Child node invalidation and convex hull updating, and (ii) Parent node invalidation and hop count updating, which are needed to keep routing structure up-to-date. Figure 6(a) shows the flow chart of \"_child node invalidation and convex hull updating_\" which are explained in Section 4.1 for MN and in Section 4.4 for the parent of MN. The flow chart of \"_parent node invalidation and hop count updating_\" is given in Figure 6(b) as explained in Sections 4.2 and 4.3 for MN and in Section 4.5 for the child nodes of MN.