In this section, we first present an overview of DERM and then introduce the detailed design of each key component in DERM.

#### 4.1. Design Overview

As analyzed in

Section 3.2, DERM can be abstracted into the energy-optimal dynamic destination region anycast problem named EO-DRA.

To address this problem, the design of DERM mainly includes three components, as shown in

Figure 2. Firstly, a

geographic routing protocol tailored for EO-DRA is proposed. Each node estimates the current sink location and destination region by the sink mobility pattern. Then, it delivers the newly generating packet to any node in that region in a greedy manner based on a comprehensive metric considering both the location information and the link quality. To handle the communications void, we adapt the traditional perimeter routing for EO-DRA and demonstrate the efficacy. Secondly, we observe that the estimated location may not be accurate due to some factors such as pauses and velocity fluctuations. Therefore, an efficient

sink location calibration method is adopted, with which each node updates the sink location when its route length dilation exceeds a certain limit caused by the outdated information. The method has low control overhead, and can still ensure high routing energy efficiency. Thirdly, for each node, there still exist unexpected sink location errors incurred by delayed updating or unpredicted movement deviations in future. Thus, we further propose a fault-tolerant mechanism named

track routing. If a packet has been transferred to and buffered in an RN, but finds that the sink has not arrived by the deadline, it will exploit a reliable forwarding approach to track the sink along the path

P and complete the last-mile delivery.

To facilitate the subsequent descriptions of DERM, we introduce the network initialization operation here. In the initial phase, the sink broadcasts a message including its ID, mobility pattern (

P,

${v}_{M}$,

$tp$), initial location

${P}_{init}$, and the time to start moving

${t}_{init}$. Each node receiving the message stores this information in the sink list. All RNs will launch a procedure to preliminarily construct a route along the sink path, which will be elaborated in

Section 4.4. Furthermore, each node exchanges its status information (i.e., node ID, PRR, and location) with the 1-hop neighboring nodes, and the graph planarization required for void handling is completed in a distributed manner.

#### 4.3. Sink Location Calibration

As stated above, the sink location estimated by the mobility pattern may deviate from the real one, which will lead to inefficient routing. A straightforward solution is that the sink regularly broadcasts its location to the entire network. However, it will bring tremendous control overhead. Therefore, we introduce a location calibration method with which the updated location information is forwarded by a node (e.g., node

i) only when the route length is enlarged beyond a threshold due to the stale information [

11].

Let ${d}_{updt}$ denote the estimated routing path length of a packet when the updated sink location is used for forwarding, and let ${d}_{prev}$ denote that when the previous location information before updating is used. The method ensures ${d}_{prev}/{d}_{updt}\le \alpha $, where $\alpha $ is the route length dilation threshold and $\alpha >1$. ${d}_{updt}$ and ${d}_{prev}$ are estimated as

${d}_{updt}$ is calculated as the shortest distance from node

i to the travel path within the delay constraint, termed

${L}_{updt}$, which is predicted based on the updated sink location. To compute

${d}_{prev}$, we first calculate the distance from

i to the travel path

${L}_{prev}$ predicted based on the previous location, and obtain the corresponding virtual destination

${D}_{prev}$. If

${D}_{prev}$ is not on the path

${L}_{updt}$, to ensure on-time delivery, the packet should be further transferred to

${L}_{updt}$ via the track routing introduced in

Section 4.4. Thus,

${d}_{prev}$ includes an additional item,

$dist({D}_{prev},{L}_{updt})$.

Figure 5 shows an example of the sink location calibration in DERM. The sink is currently located at

A deviated from the estimated location

B for

$\Delta $ meters. The travel path length within the delay constraint is

l. The sink broadcasts its current location information. Each node receiving the updated information will calculate its

${d}_{updt}$ and

${d}_{prev}$ based on Equations (

12) and (

13).

Figure 5 depicts

${d}_{updt}$ and

${d}_{prev}$ of three nodes, i.e.,

${N}_{1}$ in Area I,

${N}_{2}$ in Area III, and

${N}_{3}$ in Area V. Take node

${N}_{3}$ as an example. Its

${d}_{updt}$ is

$|{N}_{3}C|$ and

${d}_{prev}$ is

$|{N}_{3}E|+|CE|$. If

${d}_{prev}/{d}_{updt}>\alpha $, the node will update the sink location and forward it. Without loss of generality, the coordinate of

A is set as (0, 0). A node whose coordinate is

$(x,y)$ will be required to forward the updated location if satisfying the following conditions:

From Equation (

14), we can sketch out the location updating area (e.g., the shaded area in

Figure 5).

It can be observed that: (1) exploiting the mobility for delay-aware routing can effectively reduce the overhead of location calibration, compared to the immediate multi-hop routing. For instance, nodes in Area III need not update the sink location as their routing paths are not affected by the estimation error; (2) the updated area is bounded, and its size is related to $\Delta $ and $\alpha $. Only if the deviation $\Delta $ does exist and incurs route dilation at a node beyond the threshold $\alpha $, the updating information will be relayed. These two facts indicate that the introduced method can deal with the sink movement deviations and guarantee energy-efficient routing in DERM at a very low cost.

The detailed procedure of the sink location calibration is shown in Algorithm 1. Node

i records the updated sink location

${P}_{uM}^{i}$ and its last forwarded sink location

${P}_{lM}^{i}$. Each location entry has a corresponding time (e.g.,

${t}_{uM}^{i}$ for

${P}_{uM}^{i}$). All nodes in the network set a location check timer. When the timer expires, the sink checks whether the deviation between its real location

${P}_{uM}$ and the estimated one

${P}_{eM}$ (deduced from

${P}_{lM}$) is beyond a threshold

${\Delta}_{th}$. If so, it broadcasts a location updating message

$LocMsg$ including

${P}_{uM}$ and the corresponding time

${t}_{uM}$ to its neighboring nodes (Lines 1–4). It is noted that the updating area might be separated into two parts as shown in

Figure 5. Thus, the sink needs to send an area anycast message

$AnyCastMsg$ to a circular region [

38] whose center point is

$\tilde{{P}_{uM}}$ (the estimated sink location after

${D}_{s}$ seconds, e.g., point

C in

Figure 5) and radius is

R (Line 5). If there are no nodes in that area, the radius will be increased and the anycast message will be retransmitted. When a node inside the target area receives the

$AnyCastMsg$, as a new source of the updated information, it also floods a

$LocMsg$ to its neighbors (Lines 15–21). While receiving a new

$LocMsg$, node

i updates its previously recorded sink location

${P}_{uM}^{i}$ to

${P}_{uM}$. If

${d}_{prev}/{d}_{updt}>\alpha $, it propagates

$LocMsg$ to the neighborhood (Lines 22–28). Otherwise, it suppresses the forwarding of

$LocMsg$ temporally. Regularly, when the timer expires, the node checks

${P}_{lM}^{i}$, which is regarded as the previous location in this case. If

${d}_{prev}/{d}_{updt}>\alpha $, it broadcasts a

$LocMsg$ containing the updated information (Lines 9–12). The approach is obviously efficient because the sink does not need to send a message continuously to trigger the updating process when it moves.

#### 4.4. Track Routing

As introduced in

Section 4.1, the sink floods an announcement message to the entire network in the initial phase. In the meantime, the shortest path tree can be constructed as in [

49]. Then, along the tree, each RN replies to the sink with a message including its location. Here, we define the

access point of a node as the closest point to it on the sink path, which can be intuitively regarded as the site where the sink collects the data buffered in the node. We call two nodes “adjacent” if their access points are nearest in either direction along the path. The sink can find the adjacent nodes of each RN and send their locations to that RN through the corresponding reverse route. In this way, every RN is aware of its adjacent nodes, and thus a route sequentially connecting all the RNs along the path, called

adjacent route, is established. Note that a route to an adjacent node outside the communication range can be discovered via geo-routing.

**Algorithm 1** Sink location calibration algorithm at sensor node i. |

**Input:** $\alpha $, ${\Delta}_{th}$; ${P}_{uM}^{i}$, ${P}_{lM}^{i}$, and their corresponding time; the sink mobility pattern; |

**Output:** newly calibrated sink location; |

1: | **while** Location check timer expires **do** |

2: | **if** i is the sink **then** |

3: | **if** $dist({P}_{uM},{P}_{eM})>{\Delta}_{th}$ **then** |

4: | Broadcast $LocMsg({P}_{uM},{t}_{uM})$ to its neighbors; |

5: | Send an $AnyCastMsg(\tilde{{P}_{uM}},R,{P}_{uM},{t}_{uM})$; |

6: | ${P}_{lM}\leftarrow {P}_{uM}$; |

7: | **end if** |

8: | **else** |

9: | **if** ${P}_{uM}^{i}!={P}_{lM}^{i}$ and ${d}_{prev}/{d}_{updt}>\alpha $ **then** |

10: | Broadcast $LocMsg({P}_{uM}^{i},{t}_{uM}^{i})$ to its neighbors; |

11: | ${P}_{lM}^{i}\leftarrow {P}_{uM}^{i}$; |

12: | **end if** |

13: | **end if** |

14: | **end while** |

15: | **while** Receiving a new $AnyCastMsg(\tilde{{P}_{uM}},R,{P}_{uM},{t}_{uM})$ **do** |

16: | **if** i is inside the target area **then** |

17: | Broadcast $LocMsg({P}_{uM},{t}_{uM})$ to its neighbors; |

18: | **else** |

19: | Forward the $AnyCastMsg$ greedily; |

20: | **end if** |

21: | **end while** |

22: | **while** Receiving a new $LocMsg({P}_{uM},{t}_{uM})$ **do** |

23: | ${P}_{uM}^{i}\leftarrow {P}_{uM}$; |

24: | **if** ${d}_{prev}/{d}_{updt}>\alpha $ **then** |

25: | Forward $LocMsg({P}_{uM},{t}_{uM})$ to its neighbors; |

26: | ${P}_{lM}^{i}\leftarrow {P}_{uM}$; |

27: | **end if** |

28: | **end while** |

When a packet finds that the sink has not visited the RN it buffered in before the deadline due to delayed location updating or unpredicted faults, it must be delivered via multi-hop routing. To address this problem, we propose a method named track routing, as shown in Algorithm 2. The design of Algorithm 2 is elaborated as follows.

#### 4.4.1. Determining the Forwarding Direction

When a packet enters the track routing mode at a node called

tracking node (e.g.,

${N}_{0}$ in

Figure 6), it will determine the packet forwarding direction first (Lines 2–20). Our method supports two types of sink paths, i.e., the round-trip path and the cyclic path.

For the round-trip path, the tracking node broadcasts a message to its neighbors to query their sink

Beacon timestamps. Obviously, the fresher the timestamp, the closer the distance between a node and the sink. Therefore, the neighboring RN having the freshest timestamp will be selected as the next-hop forwarder. Assuming the timestamps of the tracking node and node

i are

${t}_{0}$ and

${t}_{i}$, respectively, the forwarder has a maximum

${t}_{i}-{t}_{0}$. If there are no RNs in the neighborhood, the tracking node will choose the adjacent node with a fresher timestamp as the forwarder. The packet forwarding direction (termed

$fwdDirec$) can be represented by a vector from the current node to the next-hop node. For example, in

Figure 6a,

${N}_{3}$ is the forwarder and the vector

$\overrightarrow{{N}_{0}{N}_{3}}$ (or

$\overrightarrow{BA}$) indicates

$fwdDirec$.

**Algorithm 2** Track routing algorithm at sensor node i. |

**Input:** the neighbor node set $N\left(i\right)$; the sink path, the timestamp ${t}_{i}$; $fwdDirec$, $reverse\_flag$; |

**Output:** the next-hop forwarder; |

1: | **while** receiving or buffering a packet in the track routing mode **do** |

2: | **if** node i is the tracking node **then** |

3: | **if** $tp$==$round$-$trip$ **then** |

4: | Find the node j with the maximum ${t}_{j}$ in $N\left(i\right)$; |

5: | **if** $j!=null$ **then** |

6: | Forward the packet to j; |

7: | $fwdDirec=\overrightarrow{i\phantom{\rule{1.0pt}{0ex}}j}$; |

8: | **else** |

9: | Forward the packet to the adjacent node k with the maximum ${t}_{k}$; |

10: | $fwdDirec=\overrightarrow{i\phantom{\rule{1.0pt}{0ex}}k}$; |

11: | **end if** |

12: | **else** |

13: | Determine $fwdDirec$ based on Equation (15); |

14: | Find the node j satisfying Equation (17); |

15: | **if** $j!=null$ **then** |

16: | Forward the packet to j; |

17: | **else** |

18: | Forward the packet to the adjacent node in $fwdDirec$; |

19: | **end if** |

20: | **end if** |

21: | **else** |

22: | **if** $dist(i,M)\le R$ **then** |

23: | Deliver the packet to M; |

24: | **else if** $reverse\_flag==true$ **then** |

25: | Forward the packet to the adjacent node in $fwdDirec$; |

26: | **else if** $is\_missed==true$ **then** |

27: | Reverse $fwdDirec$ and forward the packet to the adjacent node in new $fwdDirec$; |

28: | $reverse\_flag=true$; |

29: | **else** |

30: | Find the node j satisfying Equation (17); |

31: | **if** $j!=null$ **then** |

32: | Forward the packet to j; |

33: | **else** |

34: | Forward the packet to the adjacent node in $fwdDirec$; |

35: | **end if** |

36: | **end if** |

37: | **end if** |

38: | **end while** |

For the cyclic path, the sink travels along the path in a uniform direction all the time. Thus, moving the packet to chase the sink based on the freshness of timestamps may result in a long detour. In this case,

$fwdDirec$ is a Boolean value and can be set as:

where

${t}_{current}$ denotes the current time and

T is the time for the sink to complete one cycle of movement. If the time since the sink passed node

${N}_{0}$ is beyond

$T/2$, it may have travelled half the path with respect to

${N}_{0}$. Hence, the packet will be forwarded in the opposite direction of the sink movement, as shown in

Figure 6b.

#### 4.4.2. Selecting the Forwarder

After determining $fwdDirec$, a node would select a best next-hop forwarder (Lines 21–37). An intuitive solution is directly forwarding the packet to its adjacent node in the direction $fwdDirec$. However, it will make the packet visit the RNs one by one along the path towards the sink, which is obviously inefficient. We perform the track routing in a greedy manner.

To facilitate the presentation, we define

$Ad{v}_{fD}^{P}(i,j)$ as the advance along the path

P in the direction

$fwdDirec$ when a packet is forwarded from node

i to

j. Denote

${P}_{i}$ and

${P}_{j}$ as the access points of

i and

j on the path

P, respectively.

$Path({P}_{i},{P}_{j})$ represents the path from

${P}_{i}$ to

${P}_{j}$, which may include turning points of

P.

$Ad{v}_{fD}^{P}(i,j)$ can be calculated as

If $Path({P}_{i},{P}_{j})$ has the same direction as $fwdDirec$, $Ad{v}_{fD}^{P}(i,j)$ equals the length of $Path({P}_{i},{P}_{j})$. Otherwise, it is negative.

When node

i receives a packet in the track routing mode, it will first check whether the sink is within the communication range. If so, the packet will be directly delivered. Otherwise,

i chooses a neighbor

j as the forwarder which satisfies following conditions:

$\beta $ is a factor used to restrict the single-hop advance because an excessively large advance may result in missing the mobile sink. Generally, we set

$\beta $ as 1. If

i cannot find such a node

j, it will forward the packet to its adjacent node in the direction

$fwdDirec$.

We also consider an infrequent situation that the packet misses the sink due to a long advance. Assume the timestamps of node i and its last-hop node are ${t}_{i}$ and ${t}_{last}$, respectively. The situation will be recognized if (1) ${t}_{i}<{t}_{last}$ when the path is round-trip; or (2) ${t}_{i}<{t}_{last}$ when the path is cyclic and $fwdDirec$ is $same$; or (3) ${t}_{i}>{t}_{last}$ when the path is cyclic and $fwdDirec$ is $opposite$. The principle is that the Beacon timestamps mutate at the node being visited by the sink. In this case, the forwarding direction will be reversed. The packet will be forwarded back to the adjacent node in new $fwdDirec$ and enter the reverse track routing mode. When receiving a packet in the reverse track routing mode, a node just transfers it to the adjacent node in $fwdDirec$.

We take

Figure 7 as an example to illustrate the track routing process in DERM. The dashed lines represent the adjacent route. A packet at node

${N}_{0}$ needs to be delivered to the sink

M. As in

Figure 6a, the packet will be first transferred to

${N}_{3}$ with the freshest timestamp, and the forwarding direction is determined as

$\overrightarrow{{N}_{0}{N}_{3}}$. Then,

${N}_{3}$ chooses

${N}_{6}$, which has the maximum

$Ad{v}_{fD}^{P}$ as the next-hop forwarder. Note here that forwarding to the adjacent node

${N}_{4}$ will incur a longer route. On receiving the packet,

${N}_{7}$ fails to find a neighboring RN and sends it to the adjacent node

${N}_{9}$ through an ordinary node

${N}_{8}$ outside the region

$\Omega \left(P\right)$. When the packet arrives at

${N}_{11}$, it realizes that the sink is missed.

${N}_{11}$ will reverse the forwarding direction and transmit the packet to its adjacent node

${N}_{10}$, which is within the communication range of

M.

It can be observed that the track routing adopts a “greedily advance, discreetly step back” strategy, achieving high energy efficiency as well as reliable data delivery. Compared to the pheromone-based forwarding scheme [

14], with our approach, the packet will not get stuck when failing to locate a neighboring node with a fresher timestamp. It takes full advantage of the path information, and thus (1) just needs to query the timestamps once for determining the forwarding direction and (2) can also obtain better performance for the cyclic path.