3.1. Motivation
When a sink sets on static location, geographic routing can be used successfully, i.e. sending the packets to the closest node to the destination. As for the static sink, it only needs to broadcast once to the whole network at the initial stage of the network operation, which would not result in significant energy dissipation. If a sink moves quickly to be out of last hop node’s transmission range, geographic routing can’t be executed correctly without a mobile sink’s location updates because the sink can’t receive last hop forwarding without any additional reactions. For solving this problem, the mobile sink can periodically flood its location to all sensors but it is not efficient and scalable for large sensor networks and each time the sink changes its location in the network. Due to high packet overhead of flooding, when these nodes use up their energy, no more data can be transmitted back to the sink. Thus, sinks should update limited number of sensors own current location instead of flooding to all sensors. Therefore, the mobile sink only needs to broadcast to a subset of nodes in the network each time when it arrives at a new site, thus saving much energy.
In a general way, a source node that has detected an event of interest tries to send its data to the sink. Therefore, the mobile sink broadcasts its location information over the subset of nodes in the network [see
Figure 2(a)]. However, when the sink moves out of a destination node, it has to rebroadcast its location information over the network to a new destination node. We argue that this repeated network-wide broadcasting brings extra high energy loss which could impair the lifetime gains from sink mobility, especially in large-scale WSNs.
To address this problem, we provide source node’s location in the WSNs [see
Figure 2(b)]. A significant difference between our proposed scheme and the traditional mobile sink supporting scheme is that the source node provides its location service server. Therefore, it is necessary to propose an energy efficient location service protocol to balance sensor node energy consumption.
In this paper, we propose a data dissemination model called EDA (Eight-Direction Anchor) for geographic. Sinks should be able to acquire current source node’s location with bounded time and overhead. EDAs are location server sensors that track source node’s position.
Figure 2 illustrates our motivation for proposing the location service servers. As shown in
Figure 2(a), selection of location service servers will be established using six lines of grid nodes, three lines of grid nodes traversing the network vertically and three lines of grid nodes traversing the network horizontally. But from
Figure 2(a), EDA can reduce the traversing path from 6 to (2+2
) compared with ALS. EDA prevents intensive energy consumption at the border sensor nodes; consequently, the energy consumed is well balanced for all the sensor nodes.
After the source node gets the sink’s location, the source node should be able to transfer the sensed data to shortest path.
Figure 3 illustrates our motivation for proposing the shortest path relay.
When the sink has mobility, the sink agent has to relay the data from the source node to the sink. Then, this occasions a detour case (see
Figure 3(a)). Therefore, it is necessary to propose an energy efficient shortest path relay. In our proposed algorithm, once the sink is aware of the source node’s location, the sink can directly request the data forwarding from the source node [see
Figure 3(b)]. It can efficiently forward data from a source node to a sink with minimal delay path. Therefore the sink can quickly get source node’s data.
3.2. Global Grid Construction
SDLS constructs a shared global grid structure once all the sensor nodes are deployed. Global grid construction can be enabled when all sensor nodes obtain their locations using a local positioning system and maintain their one-hop neighbors’ geographic locations in their tables. Specifically, the grid is set up in parallel with the
X-axis and
Y-axis of the positioning system. The positive directions of the
X- and
Y-axes of the predefined positioning space are pointing to the east and north, respectively. The baseline coordinate (
Xbase,
Ybase) of a pre-defined positioning system is set in the mission messages or hard coded in each sensor node. The all sensor field is divided into small virtual grids. The basic idea of the grid-based approach is to establish a grid using the intersection points called grid points. The distance to the grid point is the cell size and is determined by the user such that grid points are not within transmission range. The sensor field is divided into square-shaped grids of user-defined size α. Each cell is an α × α square. Based on the global grid, the virtual coordinate (
Xp,
Yp) is determined to be grid point, the nearest node to the grid point is called the “grid node”, and the grid nodes that take the role of the location server for a specific source node are named “anchors”. The grid points are determined using the baseline coordinate (Xbase, Ybase) as follows:
The first grid point sends a grid node announcement message to each of the four adjacent grid points, using simple geographic forwarding through intermediate nodes. As a result, the node that is geographically closest to each of the grid points becomes the grid node. Finally, several nodes are selected as grid nodes to cover all grid points across the original network. Every grid node will be in charge of a location server and will maintain the location information of the source node in its cache. After selection, the grid nodes will announce their role to the adjacent grid nodes. Then, neighboring grid nodes send notification messages to each other to establish a neighbor grid node table. The main objective of global grid is to deliver location information of the source nodes to the multiple mobile sinks. In the case of multiple mobile sinks, it is difficult to keep tracking the location of mobile sinks, since links between the source node and the sink may be easily broken. In our protocol, once the sink obtains the location of the source node using the global grid structure, the sink can directly send a query to the source node. This will be explained in Section 3.5.
3.3. Eight-Direction Anchor System
Although some location services have been proposed to address location tracking, they suffer from inefficient energy consumption or their specifications are not detailed in. Especially, ALS [
23] suffers from concentrated energy consumption, as it always uses border nodes, when it provides the sink location. Though SLS [
24] generates lower overhead than existing protocols such as flooding, TTDD, and ALS, they do not consider both location response time and resilience in case one query message fails. Therefore, we propose the Eight-Direction Anchor (EDA) system to solve these problems. EDA is built using the following procedures.
Once an event occurs, a source node selects the nearest grid node as its source agent (see
Figure 4, source node and selected source agent) and distributes the location information of the source node.
The source agent broadcasts the location of the source node in eight directions (East, West, South, North, Northeast, Northwest, Southeast, and Southwest) through anchor setup messages.
The anchor setup messages are relayed by intermediate sensor nodes between two neighboring grid nodes and the recruited anchors store a copy of the location of the source node.
These anchor setup messages are generated by a geographical routing protocol. That is, the source agent distributes the location information of the source node to its eight-direction neighboring grid nodes until the message reaches the network border. EDA can prevent intensive energy consumption at the border sensor nodes and considers location response time and success rate to obtain location information.
Algorithm 1 explains how to make an Eight-Direction Anchor system at source nodes.
Algorithm 1.
Pseudo-code to make an Eight-Direction Anchor system at source nodes.
Algorithm 1.
Pseudo-code to make an Eight-Direction Anchor system at source nodes.
Procedure: |
01: initially startNode, middleNode, endNode = 0; |
02: source node finds the nearest grid node as source agent |
/* source node floods a query within a local area about a cell size. */ |
03: startNode = source agent; |
04: for (source agent’s each neighbor grid node) /* to eight-direction */ |
05: endNode = neighbor grid node; |
06: while (endNode != border node) |
07: middleNode = forward (startNode, endNode); |
/* finding the nearest neighbor node to reach the destination node */ |
08: if (middleNode == grid node) |
09: saveLocationServer (source node’s location information); |
10: end if |
11: startNode = middleNode; |
12: if (startNode == endNode) |
13: endNode = startNode.neighbor grid node; |
/* i.e.) if the message is from the east, startNode’s neighbor grid node is same direction. */ |
14: end if |
15: end while |
16: end for |
3.4. Query and Data Dissemination
A sink queries the network to collect the location of source nodes. Query and data dissemination are achieved using the following procedures. After creating the anchor through the anchor nodes selection stage, the sink can identify the location of the source node by sending a query when the sink wants to receive events. To do this;
The sink will register with the nearest grid node, known as the sink agent (see
Figure 4, sink and selected sink agent).
The sink agent sends four location query packets (East, West, South, and North) to find the location of the source node.
The sink can obtain the location of source nodes from the location response at intersecting anchor nodes (
Figure 4).
Furthermore, once the sink agent obtains the source node’s location information, it does not obtain it again. If one query message fails, the other two queries will serve as backups to retrieve the source node’s location information. This also shortens the query response time, because the sink will utilize the first response.
Once the sink agent receives the location information of the source node, the sink agent forwards it to the sink. The sink then finally can communicate with the source node using the GPSR protocol.
Since our protocol provides the location of the source nodes, instead of the location of the mobile sinks, the anchor system, which is the location server, can maintain the location information of the source nodes, although the sinks move fast and continuously.
Algorithm 2 explains how to find location of source nodes at sinks.
Algorithm 2.
Pseudo-code to find location of source nodes at sinks.
Algorithm 2.
Pseudo-code to find location of source nodes at sinks.
Procedure: |
01: initially startNode, middleNode, endNode = 0; |
02: sink finds the nearest grid node as sink agent |
/* sink floods a query within a local area about a cell size. */ |
03: startNode = sink agent; |
04: for (sink agent’s each neighbor grid node) /* to four-direction */ |
05: endNode = neighbor grid node; |
06: while (endNode != border node) |
07: middleNode = forward (startNode, endNode); |
/* finding the nearest neighbor node to reach the destination node */ |
08: if (middleNode == grid node) |
09: if (exist a new source node’s location) |
10: getLocation (sink agent); /* reply to the sink */ |
11: end if |
12: end if |
13: startNode = middleNode; |
14: if (startNode == endNode) |
15: endNode = startNode.neighbor grid node; |
/* i.e.) if the message is from the east, startNode’s neighbor grid node is same direction. */ |
16: end if |
17: end while |
18: end for |
3.5. Sink Mobility and Data Forwarding Maintenance
In this section, we propose a Location-based Shortest Relay (LSR) protocol to provide shortest path from a sink and a source node in mobile sink environments. In SDLS, once the sink obtains the location of the source node from the sink agent, the sink can directly send a query to the source node. Our protocol does not need to use a global grid structure to support a mobile sink. The sink selects the nearest sensor node as its Primary Agent (PA) to do so.
After the source node receives the query from the sink, it sends data to the PA. Thereafter, the source node can continuously send the data to the sink, once the data stream starts flowing. We now introduce the following efficient rules to support sink’s mobility. The
algorithm 3 explains how to maintain sink mobility and data forwarding.
Algorithm 3.
Pseudo-code to maintain sink mobility and data forwarding.
Algorithm 3.
Pseudo-code to maintain sink mobility and data forwarding.
Procedure: |
01: sink finds the nearest sensor node as sink primary agent |
02: if (source node receives query message from sink) |
03: source node sends data to sink |
04: end if |
05: if (source node continuously sends data to sink) |
06: if (sink is automatic operation) |
07: go to algorithm 3-1 |
08: end if |
09: if (sink is manual operation) |
10: go to algorithm 3-2 |
11: end if |
12: end if |
3.5.1. Automatic Operation
The first rule is an automatic operation. When the sink moves out of the range of its current PA, within a predefined distance (e.g., a cell size), it selects another neighboring node as its Immediate Agent (IA) and sends the location of the IA to its PA. The sink continuously updates its instant location as its New Immediate Agent (NIA) so that future data are forwarded to the NIA. This process can be done by broadcasting a solicit message from the sink and then choosing the node that replies with the strongest signal-to-noise ratio. When the sink moves outside a predefined distance from its PA, it selects a New Primary Agent (NPA). If it only considers allowing the chain between the PA and the NPA as in ALS, the following quandary occurs. Even though the sink moves toward the source node, the sensed data from the source node takes a detour. This causes large energy consumption with a long data delivery when the source node repeatedly sends the data to the sink. In the SDLS, the previous distance from the source node to the last IA of the sink is compared with the current distance from the source node to the sink’s NPA. If the NPA is less than the threshold (i.e., half of previous distance), the NPA is updated through the Old Primary Agent (OPA). Until the source node obtains the location of the NPA, the OPA can forward the data continuously to the mobile sink. In particular, when the amount of data increases, the data forwarding cost will significantly increase. The following
algorithm 3-1 summaries the first rule.
Algorithm 3-1.
Pseudo-code to automatic operation.
Algorithm 3-1.
Pseudo-code to automatic operation.
Input: distance between source node and NPA |
Output: shortest path in automatic operation |
Parameter: |
PA: Primary Agent, NPA: New Primary Agent |
IA: Immediate Agent, NIA: New Immediate Agent |
l1: distance between sink and PA (NPA) |
l2: predefined distance (i.e. half of cell size) |
l3: distance between PA and IA (NIA) |
l4: predefined distance (i.e. three times of cell size) |
l5: distance between source node and NPA via old PA |
l6: predefined distance (i.e. two times of distance between source node and NPA) |
Procedure: |
01: initially startFlag = true; |
02: do |
03: if (startFlag) |
04: if (l1 > l2) |
05: find IA and send IA’s location information to PA |
06: startFlag = false; |
07: end if |
08: end if |
09: else |
10: if (l1 > l2) |
11: if (l3 > l4) |
12: find NPA |
13: if (l5 > l6) |
14: update (NPA) /* update to source node */ |
15: end if |
16: end if |
17: end if |
18: else |
19: find NIA and send NIA’s location information to previous |
20: while (sink has mobility) |
3.5.2. Manual Operation
The second rule is a manual operation. At that point, if the sink wants to move far-away, the sink informs its movement to the PA. Then, the PA notifies the source node to stop sending data. Nevertheless, the source node will continuously store the flowing data in its cache to prepare to resend the data. If the sink wants to renew the data flow, it sends the query through the new PA. The source node sends the data including the stored data in its cache. This approach is possible because the sink can quickly obtain the location of the source node whenever it wants. Let us consider an example in
Figure 5. Assume that a mobile sink is located at points A, at time T1, and B, at time T2. The routing path for ALS and LSR at T1 is the same as P1. However, at T2, the routing path for ALS and LSR is P1 + P2 and P3, respectively. This is due to the LSR generating a new path based on the distance between the location of the source node with the current location of the sink and the last registered PA. Conversely, ALS simply forwards data without considering the distance between the location of the source node and the sink. The following
algorithm 3-2 summaries the second rule.
Algorithm 3-2.
Pseudo-code to manual operation.
Algorithm 3-2.
Pseudo-code to manual operation.
Input: estimated distance between source node and sink |
Output: shortest path in manual operation |
Parameter: |
PA: Primary Agent, NPA: New Primary Agent |
Procedure: |
01: if sink wants to move far-away from PA /* close to source node */ |
02: sink sends stop message to source node |
03: if source node receives stop message |
04: source node saves data in its cache |
05: end if |
06: end if |
07: if sink wants to renew data |
08: sink finds NPA and sends query message to source node |
09: if source node receives query message |
10: source node sends data including stored data |
11: end if |
12: end if |