Biased trajectory dissemination of uncontrolled mobile sinks for event collection in wireless sensor networks

Abstract

Considering the social properties of mobile sinks, we propose a biased trajectory dissemination of uncontrolled mobile sinks for event collection in wireless sensor networks. In biased trajectory dissemination of uncontrolled mobile sink, we first divide the whole network into clusters which can be managed by cluster heads that are elected in turn for intra-cluster event collection and inter-cluster communication. Second, for a mobile sink, we further divide the clusters it visits into biased clusters and non-biased clusters according to its staying probability. The mobile sink will send its mobility message which shows its location as it moves into a new cluster. We then construct a biased loop which is composed of all biased clusters and some non-biased clusters to disseminate a mobile sink’s mobility message only to clusters on it when the mobile sink moves into a biased cluster. We also construct query path that connects any cluster head that is not on the biased loop to a cluster head on it. An event could be transmitted to the biased loop along the query path for further forwarding to the mobile sink. Numerous simulations show the superior performance of biased trajectory dissemination of uncontrolled mobile sink compared to the representative schemes in terms of average path length, delay, and network energy consumption.

Keywords

Wireless sensor networks mobile sinks social properties event collection biased cluster

Introduction

Wireless sensor networks (WSNs) consist of a large number of tiny smart devices that can sense environmental information or collect surrounding events inside an autonomous network to communicate with the outside physical world. These devices are typically battery-powered and infeasible to replace the battery periodically or frequently for economical and practical consideration, thus the energy consumption of WSNs becomes an important factor in routing and application system design.¹

In traditional WSNs, all nodes including sinks are static deployed with constrained energy resources, forwarding sensing data to static sinks by multi-hop mechanism leading to a “hotspot” around it, which can cause routing interruption or network failure.² To alleviate the hotspot problem and un-even energy consumption problems caused by static deployed sinks, a new paradigm, which uses mobile sinks to collect sensing data by traversing the network, has been proposed and has become more and more popular in recent years.^3,4 Wang et al.⁵ apply an energy consumption model considering both transmission and computing energy consumptions and further focus on how to make the multiple mobile sinks to collect data cooperatively.

Presently, with the explosive popularity of wireless mobile intelligent terminal devices, mobile sinks carried by objects with social properties, such as soldiers in battlefield, animals in wild environment, students in campus, and cars in traffic, are widely used in many WSN applications.^6–8 In these applications, the social properties can be reflected in mobility patterns including mobility range stability, preference, and strong correlation between mobility and social encounters.⁹ For example, in campus, carriers such as students usually visit buildings such as libraries, dormitories, and classrooms; in wild environment, carriers such as animals often linger on brooks, food locations, and habitats; in rural parks, carriers such as tourists often go to some attractions to enjoy sightseeing, watch shows, and play games.

Here in this work, we mainly focus on event collection mechanism using uncontrolled mobile sinks which can move randomly in network with social properties, and the social properties depicted that mobile sinks could frequently visit some biased areas and stay there for quite a long time while could not travel all areas of the network. Considering the scalability of this mechanism, we describe the scheme with only one mobile sink in the following. Since a mobile sink has its social properties, we need to take the following two issues into consideration in the event collection mechanism: (1) how to disseminate the mobility information of an uncontrolled mobile sink efficiently in network with low overload and (2) how to forward the sensing event from an event source to a mobile sink successfully with short delivery delay.

Based on these considerations above, we propose a biased trajectory dissemination of uncontrolled mobile sinks (BTDUMS) for event collection in WSNs. In BTDUMS, we divide the network into clusters in which cluster head is responsible for intra-cluster event collection and inter-cluster communication. Each time a mobile sink moves into a new cluster, it will send its mobility message (MM) which shows its location to current cluster and previous departure cluster. The cluster head receiving this message will generate a local mobility record (MR) used to track its location. Due to the uncontrolled movement of a mobile sink, it can visit some biased clusters (BCs) frequently and stay in for quite a long time while does not traverse all the clusters.

Therefore, we construct biased loop (BL) that is composed of all BCs and certain non-biased clusters (NBCs), to disseminate the MM of mobile sink only to cluster heads on BL as it enters into a BC; in other words, the MM of a mobile sink can only be disseminated on BL instead of the whole network when it moves into a BC for the reason that it will stay in for a long time. And when the mobile sink leaves a BC into an NBC, its MM will not be disseminated on BL since it would stay in for a quite short time according to its social property, so there is no need to disseminate the message too often. Once receiving an MM, the cluster head will generate or update its local MR which can be used to track the mobile sink’s location. Therefore, in BTDUMS, cluster heads on BL can always get the latest MM of the mobile sink and update their MR in time. For the cluster heads that are not on the BL, they can send the sensing events to the BL to get the mobile sink’s latest MR for further forwarding.

In summary, the main contributions of our work are shown as follows:

Employ social properties into mobile sinks for event collection in WSNs.

Construct a BL consisting of BCs and some NBCs to disseminate the MM of a mobile sink only to cluster heads on it as the mobile sink moves into a BC.

Design a routing method to deliver the sensing event from an event source to the mobile sink based on the BL structure.

The rest of the article is organized as follows. In section “Related work,” the related work is given. In section “Details of BTDUMS design,” the detailed design of BTDUMS is presented. The performance of BTDUMS is evaluated through comprehensive simulations in section “Performance evaluation.” This article concludes in section “Conclusion.”

Related work

In this section, we give a brief overview of event collection mechanism to forward a sensing event to a mobile sink proactively in WSNs, which can be classified into two paradigms.

One is that the event source forwards an event to a mobile sink according to the mobility information that the mobile sink broadcasts all over the network. Many sink-oriented data dissemination protocols use such methods, for example, directed diffusion¹⁰ and gradient broadcast.¹¹ Besides large amount of energy consumption on flooding mobility information, energy cost on detouring event due to the inaccuracy of mobility information severely impairs the performance. Several mechanisms have been suggested to reduce control messages. In Huang et al.,¹² a spatial–temporal multicast protocol is proposed to establish a delivery zone ahead of mobile sink’s arrival, and control messages are flooded to wake up nodes in the delivery zone. Later, SinkTrail¹³ alleviates the problem by predicting sink’s future location; event is transmitted to the future location of mobile sink. Yang et al.¹⁴ propose an approach that can forward data to the mobile sink along its moving trajectory, and this method can cancel some detour route by calculating mobile sink’s movement angles.

The other one is that event sources disperse the sensing events to the network, and the mobile sink can collect them as it moves along predesigned trajectory. Some protocols based on virtual infrastructure (rendezvous region or backbone) are designed to disseminate events. Rumor routing¹⁵ does not flood the network with data, paths from event are set up by randomly walking “agents” sent out from event source, and queries also randomly walk in the field until they encounter an event path. In two-tier data dissemination (TTDD),¹⁶ a rendezvous protocol uses a proactive approach to build two-tier grid structure in which only sensors located at grid points need to acquire forwarding information. However, TTDD is based on the fact that sensor nodes are stationary and location-aware. Besides, it is best suited to deal with “localized” mobility patterns, in which a sink does not change its primary agent frequently. Artery¹⁷ is a representative rendezvous protocol in which information of event and mobility sink is disseminated to Artery located in the mid-way from the center to the boundary of the network. Only cluster head on Artery receiving the information of sink forwards the event to sink. Due to the delay of event and sink’s mobility information dissemination, some events cannot be transmitted to sink successfully. However, these rendezvous areas are subjected to become a bottleneck in the way that all sensed events are concentrated in this area. In addition, some methods focus on disseminating the event to the whole network uniformly. RaWMS¹⁸ is a protocol based on random walks in which a carried event item is repeatedly forwarded to its randomly chosen neighbors until the end of randomly walk length. The goal of RaWMS is to enable sink retrieve a representative view of sensed event by randomly visiting any set of nodes. On this basis, density-based proactive data dissemination protocol (DEEP)¹⁹ is further proposed for controlling the communication overhead, which combines a probabilistic flooding with a probabilistic storing scheme.

In summary, these proposals must dedicate a large amount of resources to distribute the event or information of mobile sink throughout the network. With the explosive popularity of wireless mobile intelligent terminal devices, people with social properties carrying mobile devices can act as the mobile sink. Under this circumstance, event collection based on the social properties can effectively decrease the quantity of data replicas and the transmission delay.²⁰

Presently, the social properties of mobile nodes are widely used to solve problems such as inter-node routing and node tracking in delay tolerant networks. In DSearching,²¹ a locator traces the target along movement path from its home (i.e. most frequently visiting location). However, such tracking leads to a long delay and high overhead on the locator by long distance moving. Later, the authors introduce TSearch²² in which nodes create encounter records and disperse them throughout the network. A locator directly moves toward target’s latest position with the latest encounter record obtained from its current location. In DTN-FLOW,²³ the authors select popular places that nodes visit frequently as landmarks. Packets are routed among landmarks utilizing all node movements, even though many nodes rarely visit the destinations of these packets.

In our BTDUMS mechanism, the social properties are employed in mobile sinks which can depict that a mobile sink could visit some biased areas frequently and stay for a long time instead of traversing all areas of the network. Considering the social properties of mobile sink, we classify the clusters into BCs and NBCs according to its staying probability. Only the clusters with staying probabilities higher than a threshold can be chosen as BC. Otherwise, the clusters are chosen as NBCs. We then construct the BL which is composed of all BCs and some NBCs to disseminate the MM of mobile sink only to clusters on it as the mobile sink moves into a BC. The reason is that since the mobile sink will stay for a longer time in BCs than in NBCs, so when it moves into a BC, it is important for the BC head to disseminate its MM on BL so that all cluster heads on BL can get mobile sink’s recent location while avoiding the message transmission overhead.

Details of BTDUMS design

In this section, we introduce the detailed design of our proposed BTDUMS mechanism which consists of three phases: (1) network architecture construction, (2) MM dissemination and MR generation, and (3) BTDUMS routing. Phase 1 provides how to cluster the network and construct the BL. Phase 2 shows how to disseminate the MM of mobile sink on BL and how to generate and update the local MR in clusters, and Phase 3 gives the specific BTDUMS routing for event collection in WSNs.

Network architecture construction

Clustering method in network

We first build a cluster coordinate and divide the network into n × n clusters which are n × n square grids with the same size, and then allocate cluster ID (CID) to all clusters. Sensor nodes are randomly deployed into clusters. Each node has a unique ID in network, and nodes in same cluster share the same CID in cluster coordinate. The cluster head can be elected periodically from nodes in each cluster based on the residual energy, which is responsible for intra-cluster event monitoring and inter-cluster communication. After each round of cluster head election, the cluster member can communicate with the cluster head by low power. A new cluster head can exchange the information stored in the previous cluster head to ensure the information consistency. In addition, a mobile sink has an independent sink ID (SID) and all cluster information in network, so it can get its specific location using additional Global Positioning System (GPS) device and calculate which cluster it locates in.

As shown in Figure 1, we build a cluster coordinate in network and divide the network into 10 × 10 clusters, in which the number on the upper right represents the CID, and we use C[i](x_i,y_i) to represents the ith cluster in the cluster coordinate, so nodes in the same cluster share the same CID and cluster coordinate. To ensure the cluster heads in two adjacent clusters communicate with each other, we suppose that a cluster’s (or a grid’s) side length is L, and the node’s transmission range is R, thus the relation of L and R should meet formula (1). For example, if the node’s transmission range is 100 m, the side length of each cluster should be smaller than 44 m

L \leq \frac{R}{\sqrt{5}}

(1)

Figure 1.

Cluster coordinate in network.

As shown in Figure 1, under formula (1), the cluster head in cluster 75 can communicate with the cluster head in cluster 76, and it also has the ability to communicate with the cluster head in cluster 85.

BL construction

Due to the social properties of a mobile sink, it can stay in BCs for a long time so that it has high probability to receive the event during its staying time.

After clustering the network, we let an uncontrolled mobile sink to move randomly in network for a long time to count its BCs based on the accumulated staying time. Specifically, we use staying probability P_s(m) to denote how likely a mobile sink is in the cluster which can be calculated as

P_{s} (m) = \frac{T_{m}}{T}

(2)

where T is the period of living time a mobile sink stays in network and T_m represents the staying time it stays in cluster m.

Here, we set a threshold to select certain BCs. The number of BCs can affect the number of sink’s mobility information dissemination. By experiment, we find that the threshold set to 0.1 can maintain a high-performance event collection while a low overhead of sink’s mobility information dissemination. When the threshold is larger than 0.1, it can reduce the clusters that are selected as BCs. The decreasing number of sink’s MM dissemination leads to an increase in the average path length and delay. When the threshold is less than 0.1, it can increase the clusters that are selected as BCs. The increasing number of sink’s MM dissemination leads to more energy consumption of clusters on BL while slight improvement of average path length and delay.

Above all and for a reasonable compromise, we set the threshold of staying probability to 0.1. The clusters in which the staying probability of a mobile sink is more than the threshold can be selected as BCs. So we can divide the clusters a mobile sink visits into BCs and NBCs in network.

For a mobile sink, there is no need to broadcast its MM to the whole network to show its location frequently when it stays in a BC since it will be there for a long time. So it makes us think that if we know the specific BC it stays in, we can almost get its location and send the event to it timely. Therefore, we construct the BL, a closed loop, which consists of all BCs and some NBCs to disseminate the MM of a mobile sink only to clusters on it when the mobile sink moves into a BC. In other words, the MM of a mobile sink can only be disseminated on BL instead of the whole network. And in this case, all the cluster heads on the BL can get the mobile sink’s recent location while avoiding the message transmission overhead. When the mobile sink leaves a BC into an NBC, its MM will not be disseminated on BL since it would stay there for a short time according to its social property. The NBCs on BL are used as relays in case those two BCs are not adjacent to each other. By connecting all BCs and NBCs in a certain order, we can get a BL which is a closed loop.

Learning from the method of constructing a convex hull in mathematics,²⁴ we can construct a BL in network with such method in Figure 2 vividly.

Figure 2.

The BL construction method.

As shown in Figure 2, there are three steps to construct the BL: (1) mark all sink’s BC heads and (2) find the ith cluster with minimum value of y_i as pole O to build a polar coordinate system. In this system, the distance from other BC heads to pole O is referred as the polar radius, and angle θ between the polar radius and polar axis (OX) is called the polar angle. Starting from the polar axis, the BC heads with an increasing polar angle θ expand from small to big and added into the BL in sequence; (3) judge whether two adjacent BC heads in sequence are adjacent to each other or not in the cluster coordinate. If not, NBC heads are added to the sequence acting as relays to connect them while making the BL maintain a maximum inside scope.

Finally, based on the above method, we construct a BL which consists of eight BCs and 14 NBCs as shown in Figure 3. We first choose a BC (CID 36) head as the pole O to build a polar coordinate system. Starting from the polar axis (OX), logically, BC 59 (CID 59) will be the next cluster after BC 36 on BL, but for the reason that cluster head of BC 36 cannot communicate with the cluster head of BC 59 directly, that is, these two BC heads in the cluster coordinate are not adjacent to each other. Here, some proper NBC (CID 37, 38, 39, and 49) heads should be added as relays to connect BC 36 and BC 59 and so they become the relay clusters from BC 36 to BC 59. By such analogy, a BL that consists of all BCs and some NBCs is constructed. And in this construction, we make the BL maintain a maximum inside scope.

Figure 3.

The BL construction.

In Figure 3, the BL consists of BC 36, NBC 37, NBC 38, NBC 39, NBC 49, BC 59, NBC 69, BC 79, NBC 78, BC 77, NBC 87, BC 86, NBC 85, BC 84, NBC 83, NBC 73, BC 63, NBC 53, BC 43, NBC 33, NBC 34, and NBC 35. Then we can get a BL chain list stored in each cluster head on BL as shown in Table 1.

Table 1.

The BL chain list.

List number	1	2	3	4	5	6	7	8	9	10	11
CID	36	37	38	39	49	59	69	79	78	77	87
BC/NBC	BC	NBC	NBC	NBC	NBC	BC	NBC	BC	NBC	BC	NBC
List number	12	13	14	15	16	17	18	19	20	21	22
CID	86	85	84	83	73	63	53	43	33	34	35
BC/NBC	BC	NBC	BC	NBC	NBC	BC	NBC	BC	NBC	NBC	NBC

CID: cluster ID; BC: biased cluster; NBC: non-biased cluster.

Query path construction

Since the mobile sink with the social properties is inclined to stay in BCs for its preference, it is obvious that the cluster heads on BL can always get the latest MM of the mobile sink and update their MR in time, so the basic idea comes to us that for the cluster heads that are not on the BL, they can send the sensing events to the BL to get the mobile sink’s latest MR for further forwarding. Therefore, we construct query path that connects any cluster head that is not on the BL to a cluster head on it, an event could be transmitted to the BL along the query path to find the mobile sink’s latest MR for further forwarding, and the event will be sent to the mobile sink according to it.

Next we give the query path construction process. At first, the cluster heads on BL broadcast “path message” with hop set to 1 to the whole network. If a cluster head receives this message for the first time, it stores the value of hop and set the cluster head that sends the message to it as its next hop, and then this cluster head continues to broadcast the path message with the value of hop added by one. Otherwise, if the cluster head receives multiple path messages from clusters on BL, it compares the value of hop in new messages with the existing one it stores; if the existing value is smaller, it discards the message, or it will update the value of hop it stores and its next hop according to the new message. By this kind of method, any cluster head that is not on the BL can have query path to a cluster head on it with smallest hop count; the query path is essentially a shortest path between them. We give some examples in Figure 3 to show the query path, and the query path from cluster 1 (CID 1) to BL is three hops (1 → 11 → 22 → 33), the query path from cluster 6 (CID 6) to BL is three hops (6 → 16 → 26 → 36), and the query path from cluster 65 (CID 65) to BL is two hops (65 → 64 → 63).

MM dissemination and MR generation

When a mobile sink enters into a new cluster, it sends its MM that is used to show its location to the current visiting cluster head and the previous departure cluster head; the format of MM is shown in Table 2, where SID denotes the ID of a mobile sink, PrevCID is the CID of the previous departure cluster for the mobile sink, PresentCID is the CID of the current visiting cluster for the mobile sink, and Timestamp represents the time when the mobile sink sends this message.

Table 2.

Format of mobility message (MM).

SID

PrevCID

PresentCID

Timestamp

SID: sink ID; CID: cluster ID.

Once receiving an MM, both the cluster heads of the current visiting cluster and the previous departure cluster will generate or update their local MRs which record the moving trajectory of the mobile sink and can be used to track the mobile sink’s location for event forwarding; the format of MR is shown in Table 3.

Table 3.

Format of mobility record (MR).

SID

NextHopID

Timestamp

SID: sink ID.

Here, SID and Timestamp are the same as the items in the receiving MM. NextHopID is the cluster head ID of PresentCID in the receiving MM or SID of the mobile sink; for the cluster head of the current visiting cluster, it can update the NextHopID to SID, and for the cluster head of the previous departure cluster, it can update the NextHopID to cluster head ID of PresentCID in the receiving MM. And so when a cluster head receives an event, it can forward it to the mobile sink according to the NextHopID item in the local MR.

In addition, if the mobile sink moves into a BC on BL, this MM should be disseminated by the BC head to all other cluster heads on BL, which can store and update their local MR. It should be noted that after the MM dissemination, all clusters on BL have the same local MR. The detailed MM dissemination on BL and MR updating process is described in Algorithm 1.

Algorithm 1. Mobility message dissemination on BL and mobility record updating.
1. when the mobile sink moves into a new cluster
2. it sends its mobility message to the current visiting cluster head;
3. and sends its mobility message to the previous departure cluster head;
4. when the cluster head of the previous departure cluster receives this message
5. MR.NextHopID = cluster head ID of MM.PresentCID;
6. updates its mobility record;
7. when the cluster head of the current visiting cluster receives this message
8. MR.NextHopID = SID;
9. updates its mobility record;
10. if the cluster head is a BC head then
11. disseminates the mobility message to all other cluster heads on BL;
12. for all other cluster heads on BL;
13. MR.NextHopID = cluster head ID of MM.PresentCID;
14. update their mobility records;
15. else the cluster head is an NBC head
16. does not disseminate the mobility message;
17. end if

BTDUMS routing

In this section, we propose a routing method based on the above network architecture to guarantee the event delivering from an event source to the mobile sink, and we define the cluster head sensing and gathering event in a cluster as the event source. When a cluster head launches an event, it will be delivered to the BL along the query path for further forwarding. Certainly, there is no need to do this process if the event source is on the BL.

Once the event is delivered to a cluster head on BL, it can be further routed to the specific cluster the mobile sink locates in according to the MR in the cluster head. In its MR, if MR.NextHopID is SID, the event can be sent to the mobile sink directly by the cluster head. Or if MR.NextHopID is a cluster head ID on BL, the cluster head first forwards the event to this cluster on BL along the BL chain list, and then sends it to the mobile sink. Otherwise the cluster head just forwards the event to MR.NextHopID according to its MR until the mobile sink.

The detailed routing method is described in Algorithm 2.

Algorithm 2. BTDUMS routing.
1. when a cluster head receives an event
2. if the cluster head m is on BL then
3. m checks its local mobility record (MR);
4. if (MR.NextHopID = SID) then
5. m.nexthop = SID; //m sends the event to the mobile sink directly
6. else (MR.NextHopID = ID of cluster head n)
7. if the cluster of n is the d_th cluster in BL chain list then
8. the cluster of m is the s_th cluster in BL chain list;
9. l is the length of BL chain list;
10. l₁ = \|d-s\|;
11. l₂ = l- \|d-s\|;
12. if ( (l₁ ≤ l₂ && d > s)\|\|(l₁ ≥ l₂ && d < s) ) then
13. m.nexthop = head of (s+1)_th cluster;
14. //m forwards the event to n along the BL chain list
15. else ( (l₁ < l₂ && d < s)\|\|(l₁ > l₂ && d > s) )
16. m.nexthop = head of (s-1)_th cluster;
17. //m forwards the event to n along the BL chain list
18. end if
19. else the cluster of n is not in BL chain list
20. m.nexthop = n; //m forwards the event to n
21. end if
22. n checks its local mobility record (MR);
23. while (MR.NextHopID ! = SID) do
24. n.nexthop = MR.NextHopID; //n forwards the event to MR.NextHopID
25. n = n.nexthop;
26. n checks its local mobility record (MR);
27. end while
28. n.nexthop = SID; //n sends the event to the mobile sink
29. end if
30. else the cluster head is not on BL
31. the event is forwarded to a cluster head m on BL along the query path;
32. the event is further forwarded from the cluster head m to the mobile sink;
33. end if

Here in Figure 4, we give the illustration of BTDUMS routing event collection, and the event sources S1 and S3 are not on BL while the event source S2 is on BL.

Figure 4.

Illustration of BTDUMS routing for event collection.

When the mobile sink moves into BC 36, it sends MM to both the cluster head of the current visiting cluster (BC 36) and the previous departure cluster (NBC 46). The head of BC 36 disseminates the MM to all other cluster heads on BL which can update the NextHopID item as the cluster head ID of BC 36 in the MR. The mobile sink will stay in BC 36 for a long time. Event sources S1 and S2 forward the event to the cluster head of BC 36 which further sends the event to the mobile sink. After a period of time, the mobile sink moves into NBC 16, during which it sends the MM when moves into a new cluster; now event source S3 launches an event. S3 first forwards the event to the head of BC 33 along the query path (1 → 11 → 22 → 33), and then the head of BC 33 further forwards the event to the head of BC 36 (according to its MR.NextHopID) along the BL chain list by four hops (33 → 34 → 35 → 36); since the mobile sink is not in BC 36, the head of BC 36 continues to forward the event to the mobile sink hop by hop according to MR.NextHopID in each cluster (36 → 26 → 16 → sink).

BTDUMS is scalable for multiple mobile sinks in a large-scale network, and we consider an event collection is completed so long as the event can be forwarded to any one of the mobile sinks. We here assume that there are three mobile sinks in network, and therefore we can construct three BLs (BL 1, BL 2, and BL 3) as shown in Figure 5 according to their social properties. In Figure 5(a), the three BLs are non-overlapping for the three mobile sinks have distinct BCs, while in Figure 5(b), the three BLs are overlapping for the three mobile sinks have some identical BCs; the BC heads A, B, C, and D will disseminate the MM of different mobile sinks on different BLs.

Figure 5.

Multiple mobile sinks in network: (a) non-overlapping and (b) overlapping.

After the BLs’ construction, cluster heads on BLs will broadcast the path message to the whole network at the same time; a cluster head that is not on BLs may receive several messages from cluster heads on different BLs, and it chooses the one with the shortest hops to a BL to store and retransmit. When a cluster head receives MMs from different mobile sinks, the cluster head will generate different local MRs for them, respectively.

In Figure 5(a), an event can only be delivered to one BL for further forwarding along it, while in Figure 5(b), when BC head A receives an event, it would forward the event to MR.NextHopID according to its MR along BL, and since it has three MRs for the three mobile sinks, it then calculates the hops from it to MR.NextHopID in each BL chain list and chooses one with the fewest hops to forward the event; so in this case, the event can be forwarded to a mobile sink in fewest hops.

Performance evaluation

We implement simulations in Omnet++ to evaluate the performance of BTDUMS. In simulation, we increase the network size from 100 × 100 m² to 1000 × 1000 m². The transmitting and receiving power consumption of an event for a sensor node are 0.66 and 0.395 W, respectively. The communication range for each node is set to 100 m, and three or four nodes are randomly deployed in a grid (cluster) with 44-m side length.

In this simulation, the movement of a mobile sink with social property is a little different from the random moving. The mobile sink first selects the ith cluster and jth cluster in BCs arbitrarily as the source and destination clusters, respectively. Then, it moves randomly from the ith cluster to jth cluster with constant velocity. When the mobile sink arrives at the destination cluster, it will stay there for a period of selected time. After that, it selects a new destination cluster in BCs to re-start a new movement.

In BTDUMS, we mainly concentrate on three parameters to evaluate the performance, which are average path length, average delivery delay, and total energy consumption, respectively. The average path length is defined as the average hops to deliver an event from event source to a mobile sink. The average delivery delay is referred to the average time spent on delivering an event from event source to a mobile sink successfully which indicates the time efficiency of the routing as well as the freshness of events. The total energy consumption means the total communication energy the network consumes both to disseminate the MM and to forward the event.

Performance evaluation with single mobile sink and multiple mobile sinks

We evaluate the performance of BTDUMS in both the condition of single mobile sink and multiple mobile sinks in network. As shown in Figures 6 and 7, both the average path length and the average delivery delay increase as the network size increases, and it also can be seen that the average path length and the average delivery delay with multiple mobile sinks are less than that with single mobile sink in network.

Figure 6.

The average path length.

Figure 7.

The average delivery delay.

The reason is that increasing the network size can increase the numbers of BCs of mobile sink, and thus may enlarge the size of BL, which further increases the average hops to deliver an event from event source to the mobile sink. Besides, we can construct more BLs when we increase the number of mobile sinks, so there will be more clusters on BLs which can usually forward events to the mobile sink along the BL chain list. And with more BLs in network, an event has more chance to choose a shortest hop to a BL for further forwarding. In addition, more BLs may overlap each other; a cluster head located in the overlapped clusters of multiple BLs will choose one BL chain list with the fewest hops to a mobile sink to forward the event; in this case, the event can be forwarded to a mobile sink in less hops.

For a similar reason, we can see that in Figure 8 the total energy consumption increases as the network size increases. With multiple mobile sinks in network, we get more BLs, and the energy consumption used to forward the event reduces while the energy for cluster heads on BLs to disseminate the MM of multiple sinks increases, but the energy consumption in disseminating the MM of mobile sinks is relatively smaller compared with the energy consumption in forwarding the event, so the energy consumption has an declining tendency with the increasing number of the mobile sinks.

Figure 8.

The total energy consumption.

Performance comparison with representative protocols

In this part, we compare the above performance of BTDUMS with that of Artery, TTDD, and Rumor in network with three mobile sinks.

As can be seen in Figures 9 –11, BTDUMS performs better than Artery, TTDD and Rumor, and the efficiency of BTDUMS is better when the network scale is large. The reason could be that in Rumor routing, each event source first generates three agent packets which can be broadcasted for restricted time, and only when an agent comes across sink’s moving trajectory that may be long and not regular, it could further forward the event to sink along this trajectory. So the Rumor routing has a lot of uncertainties which contain randomness for event collection. Therefore, this method increases a lot of energy consumption accordingly.

Figure 9.

The average path length.

Figure 10.

The average delivery delay.

Figure 11.

The total energy consumption.

While in TTDD, the source node sends event to its dissemination node, which subsequently forwards this event to nodes from which it receives the mobile sink’s mobility information, so on and so forth until this event arrives at the mobile sink’s immediate dissemination node, which further relays the event to the mobile sink along the sink’s moving trajectory. Because all the dissemination nodes are located around each crossing point of the grid, and the event can be forwarded along these dissemination nodes, the average path length and the delivery delay are relatively shorter than that in Rumor as shown in Figures 9 and 10. However, in TTDD, the source node first divides the field into a grid of cells and sets itself as one crossing point of the grid. It propagates event announcements to reach all other crossings, called dissemination points, through the whole sensor field so that each dissemination point on the grid is served by a dissemination node, which causes more energy consumption for GPS localization and event announcements forwarding than that in Rumor as shown in Figure 11.

Above all, in both Rumor and TTDD, event forwarding along the mobile sink’s moving trajectory generates higher delay and more energy consumption compared to that in BTDUMS where event always is forwarded to the BC before sending to the mobile sink.

In Artery, an event also needs to be forwarded to a cluster on Artery (like BL) along query path, and the cluster head on Artery will duplicate and forward the event across the whole Artery; when the clusters on Artery get the location position message of mobile sink that is broadcasted along the query path, they start to forward the event also along it to the mobile sink. Compared with BTDUMS, duplicating events across the whole Artery inevitably consume more energy, and because clusters on Artery do not know the location of a mobile sink before getting the location position message from the mobile sink, the Artery takes more delivery delay and more hops to deliver an event from event source to a mobile sink.

However, in BTDUMS, except the shorter query path, the path length for forwarding the event on BL to a BC head (where the mobile sink will stay for a long time) is less than half the length of BL chain list. On the whole, BTDUMS needs fewer hops to deliver an event to the mobile sink. And the main energy of BTDUMS is consumed to disseminate the location message of mobile sinks and event forwarding, for the mobile sinks spend more of their time in BCs; in most of the cases, it only needs to disseminate the location message on BL other than the whole network; meanwhile, event forwarding along static BL chain list also decreases the unnecessary energy cost.

Conclusion

In this article, we investigate the scheme for event collection of uncontrolled mobile sinks which can move randomly with the social properties in WSNs. The social properties allow the mobile sinks visit some biased areas frequently and stay for a long time instead of traversing all areas. Comprehensive simulations demonstrate that our BTDUMS perform better in terms of path length, delay, and energy consumption compared to representative protocols such as Rumor, TTDD, and Artery. In future, we can use opportunistic routing method to forward event from clusters on BL to the mobile sink other than along the BL chain list; explore more social properties to accurately predict mobile sinks’ location; apply energy consumption model considering both transmission and computing for system evaluations;²⁵ and improve current algorithm for query-based event collection applications.

Footnotes

Acknowledgements

The authors would like to appreciate all anonymous reviewers for their insightful comments and constructive suggestions to polish this article in high quality.

Academic Editor: Jie He

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The research was supported by the National Nature Science Foundation of China (no. 61602305), Shanghai Engineering Research Center Project (no. 14014), and the program for Professor of Special Appointment (Eastern Scholar) at Shanghai Institutions of Higher Learning jointly. All funds declare to cover the costs to publish in open access.

References

Chatzigiannakis

Nikoletseas

Spirakis

Efficient and robust protocols for mobility detection and propagation in smart dust networks. Mobile Network Appl 2005; 10: 133–149.

Chatzigiannakis

Dimitriou

Nikoletseas

. A probabilistic algorithm for efficient and robust data propagation in wireless sensor networks. Ad Hoc Netw 2006; 4: 621–635.

Powell

Leone

Rolim

JDP

. Energy optimal data propagation in wireless sensor networks. J Parallel Distr Com 2007; 67: 302–317.

Jarry

Leone

Powell

. An optimal data propagation algorithm for maximizing the lifespan of sensor networks. In: DCOSS’06, San Francisco, CA, 18–20 June 2006, pp.405–421. Berlin, Heidelberg: Springer.

Wang

Zheng

YR.

Optimum energy- and spectral-efficient transmissions for delay-constrained hybrid ARQ systems. IEEE T Veh Technol 2014; 65: 5212–5221.

Shen

Srisathapornphat

Jaikaeo

Sensor information networking architecture and applications. IEEE Pers Commun 2001; 8: 52–59.

Juang

Oki

Wang

. Energy-efficient computing for wildlife tracking: design tradeoffs and early experiences with ZebraNet. In: Proceedings of the 10th international conference on Architectural support for programming languages and operating systems (ASPLOS-X), San Jose, CA, 5–9 October 2002. New York: ACM.

Thiagarajan

Ravindranth

LaCurts

VTrack: accurate energy-aware traffic delay estimation using mobile phones. In: Proceedings of the 7th ACM conference on embedded networked sensor systems (SenSys’09), Berkeley, CA, 4–6 November 2009. New York: ACM.

Zhao

Zhu

LM.

Correlating mobility with social encounters: distributed localization in sparse mobile networks. In: IEEE 9th international conference on mobile ad hoc and sensor systems (MASS 2012), Las Vegas, NV, 8–11 October 2012, pp.10–18. New York: IEEE.

10.

Intanagonwiwat

Govindan

Estrin

. Directed diffusion: a scalable and robust communication paradigm for sensor networks. In: Proceedings of the 6th annual international conference on mobile computing and networking (MobiCom), Boston, MA, 6–11 August 2000, pp.56–67. New York: ACM.

11.

Zhong

. Gradient broadcast: a robust data delivery protocol for large scale sensor networks. Wirel Netw 2005; 11: 285–298.

12.

Huang

Roman

Spatiotemporal multicast in sensor networks. In: Proceedings first ACM conference on embedded networked sensor systems (SenSys), Los Angeles, CA, 5–7 November 2003, pp.205–217. New York: ACM.

13.

Liu

Zhao

Yang

. SinkTrail: a proactive data reporting protocol for wireless sensor networks. IEEE T Comput 2013; 62(1): 151–162.

14.

Yang

. Tracking mobile sinks via analysis of movement angle changes in WSNs. Sensors 2016; 16(4): 449.

15.

Braginsky

Estrin

. Rumor routing algorithm for sensor networks. In: First ACM international workshop on wireless sensor networks and applications, Atlanta, GA, 28 September 2002. New York: ACM.

16.

Luo

Cheng

. A two-tier data dissemination model for large-scale wireless sensor networks. In: Proceedings of the 8th annual international conference on mobile computing and networking (MobiCom), Atlanta, GA, 23–28 September 2002, pp.148–159. New York: ACM.

17.

Lin

. Artery: a data-centric architecture for wireless sensor networks. In: CCCT 2003, Orlando, FL, 31 July–1–2 August 2003, pp.123–128.

18.

Bar-Yossef

Friedman

Kliot

RaWMS—random walk based lightweight membership service for wireless ad hoc networks. ACM T Comput Syst 2008; 26: 1–66.

19.

Vecchio

Carneiro Viana

Ziviani

. DEEP: density-based proactive data dissemination protocol for wireless sensor networks with uncontrolled sink mobility. Comput Commun 2010; 33(8): 929–939.

20.

Xiang

Jia

Min

. Research of data collection technology in crowd sensing based on social behavior analysis. Appl Res Comput 2015; 32(12): 3534–3541.

21.

Chen

Shen

. DSearching: distributed searching of mobile nodes in DTNs with floating mobility information. In: Proceedings—IEEE INFOCOM, Toronto, ON, Canada, 27 April–2 May 2014, pp.2283–2291. New York: IEEE.

22.

Yan

Shen

TSearch: target-oriented low-delay node searching in DTNs with social network properties. In: IEEE conference on computer communications (INFOCOM), Hong Kong, 26 April–1 May 2015, pp.1858–1866. New York: IEEE.

23.

Chen

Shen

DTN-FLOW: inter-landmark data flow for high-throughput routing in DTNs. IEEE ACM T Network 2015; 23(1): 212–226.

24.

Graham

RL.

An efficient algorithm for determining the convex hull of a finite planar set. Inf Proc Lett 1972; 1: 132–133.

25.

Wang

Zheng

YR.

Energy efficiency and spectral efficiency tradeoff in type-I ARQ systems. IEEE J Sel Area Comm 2014; 32(2): 356–366.