IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 1,...

SinkTrail: A Proactive Data ReportingProtocol for Wireless Sensor Networks

Xinxin Liu, Student Member, IEEE, Han Zhao, Student Member, IEEE,

Xin Yang, and Xiaolin Li, Member, IEEE

Abstract—In large-scale Wireless Sensor Networks (WSNs), leveraging data sinks’ mobility for data gathering has drawn substantial

interests in recent years. Current researches either focus on planning a mobile sink’s moving trajectory in advance to achieve

optimized network performance, or target at collecting a small portion of sensed data in the network. In many application scenarios,

however, a mobile sink cannot move freely in the deployed area. Therefore, the precalculated trajectories may not be applicable. To

avoid constant sink location update traffics when a sink’s future locations cannot be scheduled in advance, we propose two energy-

efficient proactive data reporting protocols, SinkTrail and SinkTrail-S, for mobile sink-based data collection. The proposed protocols

feature low-complexity and reduced control overheads. Two unique aspects distinguish our approach from previous ones: 1) we allow

sufficient flexibility in the movement of mobile sinks to dynamically adapt to various terrestrial changes; and 2) without requirements of

GPS devices or predefined landmarks, SinkTrail establishes a logical coordinate system for routing and forwarding data packets,

making it suitable for diverse application scenarios. We systematically analyze the impact of several design factors in the proposed

algorithms. Both theoretical analysis and simulation results demonstrate that the proposed algorithms reduce control overheads and

yield satisfactory performance in finding shorter routing paths.

Index Terms—Wireless sensor networks, mobile sink, data gathering, routing, logical coordinates

Ç

1 INTRODUCTION

WIRELESS Sensor Networks (WSNs) have enabled a widespectrum of applications through networked low-

cost low-power sensor nodes, e.g., habitat monitoring [15],precision agriculture [11], and forest fire detection [27]. Inthese applications, the sensor network will operate underfew human interventions either because of the hostileenvironment or high management complexity for manualmaintenance. Since sensor nodes have limited battery life,energy saving is of paramount importance in the design ofsensor network protocols.

Recent research on data collection reveals that, ratherthan reporting data through long, multihop, and error-prone routes to a static sink using tree or cluster networkstructure, allowing and leveraging sink mobility is morepromising for energy efficient data gathering [1]. Mobilesinks, such as animals or vehicles equipped with radiodevices, are sent into a field and communicate directly withsensor nodes, resulting in shorter data transmission pathsand reduced energy consumption.

However, data gathering using mobile sinks introducesnew challenges to sensor network applications. To betterbenefit from the sink’s mobility, many research efforts havebeen focused on studying or scheduling movement patterns

of a mobile sink to visit some special places in a deployedarea, in order to minimize data gathering time. In suchapproaches a mobile sink moves to predetermined sojournpoints and query each sensor node individually. Althoughseveral Mobile Elements Scheduling (MES) protocols havebeen proposed to achieve efficient data collection viacontrolled sink mobility [14], [21], [28], determining anoptimal moving trajectory for a mobile sink is itself anNP-hard problem [14], and may not be able to adapt toconstrained access areas and changing field situations. Takethe precision agriculture application as an example, asshown in Fig. 1, where mobile sinks collecting data mainlyfollow trails or field boundaries in order not to damagecrops, and change trajectories dynamically according tofarmland situations.

Typically, without scheduling the trajectory for a mobilesink in advance, a data gathering protocol using mobilesinks suggests that a mobile sink announce its locationinformation frequently throughout the network. Many Sink-Oriented Data Dissemination (SODD) protocols use suchapproach, e.g., Directed Diffusion [8], Declarative RoutingProtocol (DRP) [3], and GRAB [25], whereas differentaggregation methods may be adopted. This class ofmethods is referred to as SODD in the literature [24]. Thisapproach is much more flexible in terms of sinks’ move-ment, but incurs significant control message overheads. Anexample data reporting path of SODD is presented usingblack solid route shown in Fig. 2. In addition to largeamount of energy consumption on flooding control mes-sages, change of routing paths due to the sinks’ movement,and energy cost on detouring large data packets (originallytargeted at the previous sink location, now changed to thecurrent sink location) severely impair protocol perfor-mances. This problem can be alleviated by transmittingdata via the shortest route to the mobile sink’s future

IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 1, JANUARY 2013 151

. X. Liu, H. Zhao, and X. Yang are with the Computer and InformationScience and Engineering Department, University of Florida, 406 NewEngineering Building, Gainesville, Florida 32611-6200.E-mail: {xinxin, han, xin}@cise.ufl.edu.

. X. Li is with the Department of Electrical and Computer Engineering,University of Florida, 216 Larsen Hall, PO Box 116200, Gainesville,Florida 32611-6200. E-mail: [email protected].

Manuscript received 24 July 2011; revised 23 Sept. 2011; accepted 28 Sept.2011; published online 18 Oct. 2011.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TC-2011-06-0423.Digital Object Identifier no. 10.1109/TC.2011.207.

0018-9340/13/$31.00 � 2013 IEEE Published by the IEEE Computer Society

locations, as observed in the red dashed route in Fig. 2.Therefore, if sensors can predict the mobile sink’s move-ment, the energy consumption would be greatly reducedand data packets handoff would be smoother.

In this paper, we propose SinkTrail, a proactive datareporting protocol that is self-adaptive to various applica-tion scenarios, and its improved version, SinkTrail-S, withfurther control message suppression. In SinkTrail, mobilesinks move continuously in the field in relatively low speed,and gather data on the fly. Control messages are broad-casted at certain points in much lower frequency thanordinarily required in existing data gathering protocols.These sojourn positions are viewed as “footprints” of amobile sink. Considering each footprint as a virtual land-mark, a sensor node can conveniently identify its hop countdistances to these landmarks. These hop count distancescombined represent the sensor node’s coordinate in thelogical coordinate space constructed by the mobile sink.Similarly, the coordinate of the mobile sink is its hop countdistances from the current location to previous virtuallandmarks. Having the destination coordinate and its owncoordinate, each sensor node greedily selects next hop withthe shortest logical distance to the mobile sink. As a result,SinkTrail solves the problem of movement prediction fordata gathering with mobile sinks.

Our contributions in this paper are manifold.

1. We propose a unique logical coordinate representa-tion for tracking mobile sinks without assistance ofGPS devices or predefined landmarks, which iswidely applicable to various network settings andscenarios.

2. We design a novel low-complexity dynamic routingprotocol for data gathering with one or multiplemobile sink(s), which effectively reduces averageroute length and cuts down total energy consumption.

3. We propose and evaluate an enhanced SinkTrailprotocol, called SinkTrail-S.

4. We conduct extensive comparison studies andsimulations with popular existing solutions.

The rest of the paper is organized as follows. Section 2presents related work. Detailed protocol design is intro-duced in Section 3. Section 4 presents analytical and

simulation results, and demonstrates the advantages ofSinkTrail algorithms over previous approaches. The impactof several design factors of SinkTrail is investigated andanalyzed in Section 5. Section 6 concludes the paper.

2 RELATED WORK

Leveraging data sinks’ mobility in sensor data collection hasbeen a topic of tremendous practical interests and drawnintensive research efforts in the past few years. The mostchallenging part of this approach is to effectively handle thecontrol overheads introduced by a sink’s movement. At thefirst look, broadcasting a mobile sink’s current location tothe whole network is the most natural solution to track amoving mobile sink. This type of approach is sink orientedand some early research efforts, e.g., [3], [8], [25], havedemonstrated its effectiveness in collecting a small amountof data from the network. Several mechanisms have beensuggested to reduce control messages. The TTDD protocol,proposed in [24], constructed a two-tier data disseminationstructure in advance to enable fast data forwarding. In [7], aspatial-temporal multicast protocol is proposed to establisha delivery zone ahead of mobile sink’s arrival. Controlmessages are flooded to wake up nodes in the deliveryzone. Similarly, Park et al. [17] proposed DRMOS thatdivides sensors into “wake-up” zones to save energy. Fodorand Vidacs [5] lowered communication overheads byproposing a restricted flooding method; routes are updatedonly when topology changes. Luo and Hubaux [13]proposed that a mobile sink should move following a circletrail in deployed sensor field to maximize data gatheringefficiency. One big problem of the multicasting methods liesin its flooding nature. Moreover, these papers either assumethat mobile sinks move at a fixed velocity and fixeddirection, or follow a fixed moving pattern, which largelyconfines their application. The SinkTrail protocol withmessage suppression minimizes the flooding effect ofcontrol messages without confining a mobile sink’s move-ment, thus is more attractive in real-world deployment.Another solution utilizes opportunistic data reporting. Forinstance, in [19], Shah and Shakkottai studied data collec-tion performance when a mobile sink presents at randomplaces in the network. The method relies heavily onnetwork topology and density, and suffers scalability issueswhen all data packets need to be forwarded in the network.

152 IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 1, JANUARY 2013

Fig. 2. Comparison of routing methods: SODD versus SinkTrail. Amobile sink moves from the trail Point 1 to the trail Point 2 in a sensornetwork deployed in a wild area. The black solid route represents thedata reporting path in SODD (without location prediction); it takes sixhops to reach the trail Point 2. Whereas red dashed route representspredictive SinkTrail routing, taking only four hops to reach the mobilesink’s current location.Fig. 1. A photograph showing a typical farmland of irregular shapes. A

mobile sink’s movement in such environment is constrained. Bycourtesy of http://www.hat.net/.

Another category of methods, called Mobile ElementScheduling (MES) algorithms [4], [14], [21], [22], [23], [28],[29], [30], considered controlled mobile sink mobility andadvanced planning of mobile sink’s moving path. Ma andYang [14] focused on minimizing the length of each datagathering tour by intentionally controlling the mobile sink’smovement to query every sensor node in the network.When data sampling rates in the network are hetero-geneous, scheduling mobile sinks to visit hot-spots of thesensor network becomes helpful. Example algorithms canbe found in [4], [22], and [23]. Although the MES methodseffectively reduce data transmission costs, they require amobile sink to cover every node in the sensor field, whichmakes it hard to accommodate to large scale and introduceshigh latency in data gathering. Even worse, finding anoptimal data gathering tour in general is itself an NP-hardproblem [12], [14], and constrained access areas or obstaclesin the deployed field pose more complexity. UnlikeMES algorithms, SinkTrail, with almost no constraint onthe moving trajectory of mobile sinks, achieves much moreflexibility to adapt to dynamically changing field situationswhile still maintains low communication overheads.

SinkTrail uses sink location prediction and selects datareporting routes in a greedy manner. In [9], Keally et al.used sequential Monte Carlo theory to predict sinklocations to enhance data reporting. SinkTrail employs adifferent prediction technique that has much lowercomplexity. Moreover, SinkTrail does not rely on theassumption of location-aware sensor nodes, which couldbe impractical for some real-world applications. Therouting protocol of SinkTrail is inspired by recent researchon virtual coordinate routing [2], [6], [16], [18]. Rao et al.[18] proposed a greedy algorithm for data reporting usinglogical coordinates rather than geographic coordinates.Fonseca et al. [6] presented vector form virtual coordi-nates, in which each element in the vector represented thehop count to a landmark node. SinkTrail adopts thisvector representation and uses past locations of the mobilesink as virtual landmarks. To the best of our knowledge,we are the first to associate a mobile sink’s “footprints”left at moving path with routing algorithm construction.The vector form coordinates, called trail references, areused to guide data reporting without knowledge of thephysical locations and velocity of the mobile sink.

3 SINKTRAIL PROTOCOL DESIGN

3.1 Problem Formulation

We consider a large scale, uniformly distributed sensornetwork IN deployed in an outdoor area. Fig. 3 shows anexample deployment. Nodes in the network communicatewith each other via radio links. We assume the whole sensornetwork is connected, which is achieved by deployingsensors densely. We also assume sensor nodes are awakewhen data gathering process starts (by synchronizedschedule or a short “wake up” message). In order to gatherdata from IN, we periodically send out a number of mobilesinks into the field. These mobile sinks, such as robots orvehicles with laptops installed, have radios and processorsto communication with sensor nodes and processing senseddata. Since energy supply of mobile sinks can be replaced orrecharged easily, they are assumed to have unlimitedpower. A data gathering process starts from the time mobile

sinks enter the field and terminates when: either 1) enoughdata are collected (measured by a user defined threshold); or2) there are no more data report in a certain period. TheSinkTrail protocol is proposed for sensor nodes to proac-tively report their data back to one of the mobile sinks. Toillustrate our data gathering algorithm clearly, we firstconsider the scenario where there is only one mobile sink inIN. The multiple mobile sinks scenario is discussed inSection 3.3.

3.2 SinkTrail Protocol with One Mobile Sink

During the data gathering process, the mobile sink movesaround in IN with, relatively, low speed, and keeps listeningfor data report packets. It stops at some places for a veryshort time, broadcasts a message to the whole network, andmoves on to another place. We call these places “TrailPoints,” and these messages “Trail Messages.” Example trailpoints are shown in Fig. 3. Let � be the average transmissionrange. Apparently two adjacent trail points should beseparated by a distance longer than � , otherwise, the hopcount information will not be significantly different. Tofacilitate the tracking of a mobile sink, we assume that thedistances between any two consecutive trail points are same(or similar), denoted as K�;K � 1. However, distribution ofthese trail points does not necessarily follow any pattern. Atrail message from a mobile sink contains a sequencenumber (msg.seqN) and a hop count (msg.hopC) to the sink.The time interval between a mobile sink stops at one trailpoint and arrives at the next trail point is called one “move.”There are multiple moves during a data gathering round.The tasks of a mobile sink is summarized in Algorithm 1.

Algorithm 1. Mobile sink’s strategy

1: =�——Initialization——�=2: msg:seqN 0;

3: msg:hopC 0;

4: Announces step size parameter K

5: =�——Moving strategies——�=6: while Not get enough data or Not timeout do

7: Move to next trail point;8: msg.seqN msg.seqN þ1;

9: Stop for a very short time to broadcast trail message;

10: Concurrently listen for data report packets;

11: end while

12: End data gathering process and exit;

LIU ET AL.: SINKTRAIL: A PROACTIVE DATA REPORTING PROTOCOL FOR WIRELESS SENSOR NETWORKS 153

Fig. 3. Data gathering with one mobile sink: large solid dots indicate themobile sink’s trail points, and sensor nodes maintain trail references aslogical coordinates. Shaded areas stand for obstacles.

In the SinkTrail algorithm, we use vectors called “TrailReferences” to represent logical coordinates in a network.The trail reference maintained by each node is used as alocation indicator for packet forwarding. All trail referencesare of the same size. Notations used throughout theprotocol description are listed in Table 1.

The data reporting procedure consists mainly twophases. The first phase is called logical coordinate spaceconstruction. During this phase, sensor nodes update theirtrail references corresponding to the mobile sink’s trailmessages. After dv hop counts have been collected, a sensornode enters the greedy forwarding phase, where it decidehow to report data packets to the mobile sink.

3.2.1 Logical Coordinate Space Construction

At beginning, all sensor nodes’ trail references areinitialized to ½�1;�1; . . . ;�1� of size dv. A special variable� that is used to track the latest message sequencenumber is also set to �1. After the mobile sink S entersthe field, it randomly select a place as its first trail point�1, and broadcasts a trail message to all the sensor nodesin IN. The trail message, <msg:seqN;msg:hopC>, is set to<1; 0>, indicating that this is the first trail message fromtrail point one, and the hop count to S is zero.

The nodes nearest to S will be the first ones to hear thismessage. By comparing with �, if this is a new message,then � will be updated by the new sequence number. Andnode ni’s trail reference vi is updated as follows: first, everyelement in vi is shifted to left by one position. Then, the hopcount in the received trail message is increased by one, andreplaces the right-most element ei

dv in vi. After ni updatedits trail reference, this trail message is rebroadcasted withthe same sequence number and an incremented hop count.The same procedure repeats at all the other nodes in IN.Within one move of S, all nodes in the network haveupdated their trail references according to their hop countdistances to S’s trail point �1. If a node receives a trailmessage with a sequence number equals to �, but has asmaller hop count than it has already recorded, then the lasthop count field in its trail reference is updated, and this trailmessage is rebroadcasted with the same sequence numberand an incremented hop count. Trail messages that hassequence number less than � will be discarded to eliminateflooding messages in the network. The steps described inAlgorithm 2 summarizes the operations to update a trail

reference. During the data gathering procedure, a node’strail reference needs to be updated every time a new trailmessage is received.

Algorithm 2. Trail reference update algorithm1: while Data gathering process is not over do

2: =�——Receive a trail message——�/3: if msg.seqN > � then

4: � msg:seqN;

5: Shift vi to left by one position;

6: eidv msg:hopCþ 1;

7: msg.hopC msg.hopC þ1;

8: Rebroadcast message;9: else if msg.seqN ¼ � then

10: Compare eidv with (msg:hopCþ 1);

11: if eidv > ðmsg:hopCþ 1Þ then



14: Rebroadcast message;

15: else

16: Discard the message;17: end if

18: else if msg.seqN < � then

19: Discard the message;

20: end if

21: end while

22: =�——Reset Variables——�=23: For j ¼ 1; . . . ; dv ei

j �1;

24: � �1

After each node in the network received dv distinct trailmessages, the logical coordinate space is established. Asnapshot of a part of the network IN is shown in Fig. 4. Trailreferences, such as ½3; 1; 1� or ½2; 2; 2�, are considered logicalcoordinates of the sensor nodes in a network.

3.2.2 Destination Identification

SinkTrail facilitates the flexible and convenient constructionof a logical coordinate space. Instead of scheduling a mobilesink’s movement, it allows a mobile sink to spontaneouslystop at convenient locations according to current fieldsituations or desired moving paths. These sojourn places ofa mobile sink, named trail points in SinkTrail, are footprintsleft by a mobile sink, and they provide valuable informa-tion for tracing the current location of a mobile sink.


TABLE 1Notations for the SinkTrail Protocol

Fig. 4. Example execution snapshot of SinkTrail: large solid dots indicatetrail points and its moving path.

Considering these footprints as virtual landmarks, hopcount information reflects the moving trajectory of a mobilesink. A logical dv-dimensional coordinate space is thenestablished.

One advantage of SinkTrail is that the logical coordinateof a mobile sink keeps invariant at each trail point, given thecontinuous update of trail references. This is becausethe mobile sink’s hop count distance to its previousdv � 1 footprints are always Kðdv � 1Þ; Kðdv � 2Þ; . . . ; K,and 0 to its current location. Therefore, the logicalcoordinate ½Kðdv � 1Þ; Kðdv � 2Þ; . . . ; 0� represents the cur-rent logical location of the mobile sink. We call thiscoordinate “Destination Reference.” This destination refer-ence does not necessarily require a mobile sink to havelinear moving trajectory. Although arbitrary movement of amobile sink may deteriorate the accuracy of destinationreference, it can still serve as a guideline for data reporting.Here, we set K ¼ 1 and dv ¼ 3 to ease our presentation. Alarge value of K means even less broadcast frequency. Theimpacts of mobile sinks’ moving pattern and broadcastfrequency are investigated in Section 5. In Fig. 4, assume S isat the trail Point 3 now, then its destination reference shouldbe ½2; 1; 0�. When S moves to the trail Point 4, the coordinatespace is updated based on trail Points 2, 3, and 4, anddestination reference of the mobile sink is still ½2; 1; 0�.

3.2.3 Greedy Forwarding

Once a node has updated the three elements in its trailreference (we use dv ¼ 3 for easy understanding and clearpresentation), it starts a timer that is inverse proportionalto the right-most element in its trail reference. Forexample, node n5’s trail reference is ½6; 7; 9� in Fig. 4, thenthe duration of its timer is set to T5 ¼ Tinit � �� 9. Here,Tinit and � are predefined constants. The choice of timerfunction, Tinit, and � may vary. However, we assume thetimer durations are significantly longer than the propaga-tion time of a trail message, so that timers on all nodes areviewed as starting at the same time. The timer mechanismis mainly used to differentiate data reporting orders(another usage is discussed in SinkTrail-S protocol); sothe clock on each sensor node does not need to beperfectly synchronized. Since the right-most element in anode’s trail reference is the latest hop count informationfrom this node to a mobile sink, the inverse proportionaltimers ensure that nodes faraway from S have shortertimer durations than those close to S, thus will start datareporting first. When a node’s timer expires, it initiates thedata reporting process.

Every sensor node in the network maintains a routing

table of size OðbÞ consisting of all neighbors’ trail references.

This routing table is built up by exchanging trail references

with neighbors, as described in Algorithm 3; and it is

updated whenever the mobile sink arrives at a new trail

point. Although trail references may not be global identi-

fiers since route selection is conducted locally, they are

good enough for the SinkTrail protocol. Because each trail

reference has only three numbers, the size of exchange

message is small. When a node has received all its

neighbors’ trail references, it calculates their distances to

the destination reference, ½2; 1; 0�, according to 2-norm vector

calculation, then greedily chooses the node with the

smallest distance as next hop to relay data. If there is a tie

the next hop node can be randomly selected. The complete

procedure of greedy forwarding is presented in Algo-

rithm 3. Take the network in Fig. 4 as an example, when

node n8 decides to report its data, it compares n4, n5, and

n7’s vector distance with ½2; 1; 0�. Since n5 and n7’s distance

to ½2; 1; 0� isffiffiffiffiffiffiffiffi133p

andffiffiffiffiffiffiffiffi249p

, respectively, and n4’s distance

isffiffiffiffiffi90p

, n4 is chosen as the next hop of n8.

Algorithm 3. Greedy data forwarding algorithm

1: =�——Start a timer——�=2: if All elements of the trail reference are updated then

3: Start timer Ti ¼ Tinit � �� eidv4: Exchange trail references with neighbors

5: end if

6: =�——When timer expires——�=7: Set destination as ½ðdv � 1Þ; . . . ; 2; 1; 0�8: =�——Probe mobile sink——�=9: if A mobile sink is within radio range then

10: Send data to the mobile sink directly

11: else

12: Choose the neighbor closest to destination as the next hop

13: Forward all data to next hop

14: end if

3.3 SinkTrail Protocol with Multiple Mobile Sinks

The proposed SinkTrail protocol can be readily extendedto multisink scenario with small modifications. Whenthere is more than one sink in a network, each mobile sinkbroadcasts trail messages following Algorithm 1. Differentfrom one sink scenario, a sender ID field, msg.sID, isadded to each trail message to distinguish them fromdifferent senders.

Algorithms executed on the sensor node side should bemodified to accommodate multisink scenario as well. Insteadof using only one trail reference, a sensor node maintainsmultiple trail references that each corresponds to a differentmobile sink at the same time. Fig. 5 shows an example of twomobile sinks. Two trail references, colored in black and red,coexist in the same sensor node. In this way, multiple logicalcoordinate spaces are constructed concurrently, one for eachmobile sink. When a trail message arrives, a sensor nodechecks the mobile sink’s ID in the message to determine if it isnecessary to create a new trail reference. The procedure issummarized in Algorithm 4. In SinkTrail trail references ofeach node represent node locations in different logicalcoordinate spaces, when it comes to data forwarding,because reporting to any mobile sink is valid, the node canchoose the neighbor closest to a mobile sink in any coordinate


Fig. 5. Example execution snapshot of SinkTrail of multiple mobile sinksscenario.

space. Sink location in each logical coordinate space is still

½2; 1; 0�, as we use K ¼ 1; dv ¼ 3. If each mobile sink has a

different K value, sensor nodes will calculate neighbors’

distances to multiple destination references and select route

accordingly. Detailed description is in Algorithm 5. It is well

known that geographic routing and virtual coordinate-based

routing ensure loop-free routes [6], [18], so does SinkTrail.

Algorithm 4. Trail reference update algorithm for multiple

mobile sinks

1: while Data gathering process is not over do

2: =�——Receive a trail message——�=3: if New mobile sink ID then

4: Createvi_mID;

5: Create �_mID;

6: else

7: =�——Message from a known sink——�=8: if msg.seqN > �_mID then

9: Shift vi_mID to left by one position;




13: else if msg.seqN ¼ �_mID then

14: Compare eidv with ðmsg:hopCþ 1Þ;

15: if eidv > msg:hopCþ 1 then




19: else

20: Discard the message

21: end if

22: else if msg.seqN < �_mID then


24: end if

25: end if

26: end while

27: =�——Reset variables——�=28: vi_prototype ½�1;�1; . . . ;�1� of size dv;

29: �_prototype �1;

Algorithm 5. Greedy data forwarding algorithm for multi-

ple mobile sinks

1: =�——Start a timer——�=2: if All elements of the trail reference are updated then

3: Start timer Ti ¼ Tinit � �� eidv4: Exchange trail references with neighbors

5: end if

6: =�——When timer expires——�=7: Set destination as ½ðdv � 1Þ; . . . ; 2; 1; 0�8: =�——Probe mobile sink——�=9: if A mobile sink is within radio range then

10: Send data to the mobile sink directly

11: else

12: Compare neighbors’ trail references with destination

reference in already established logical coordinates

13: Choose the neighbor closest to any mobile sink as the next

hop

14: Forward all data to next hop

15: end if

Fig. 5 gives us an example of data gathering in multiplecoordinate spaces. For node n5, its neighbor node n2’svector distance to ½2; 1; 0� with regard to the red mobile sinkon the left is two, and

ffiffiffiffiffi43p

to the right gray mobile sink.And all other neighbors of n5 has larger vector distance tothe two sinks. So n2 is used as the next hop to route to thered mobile sink.

3.4 SinkTrail-S Protocol

In SinkTrail, flooding trail messages to the whole networkcan be nontrivial in terms of energy consumption. Tofurther optimize the energy usage and eliminate unneces-sary control messages in the network, we propose SinkTrail-S algorithm as an improvement to the original SinkTrail.SinkTrail-S algorithm is mainly based on the following twoobservations. First, in a large-scale sensor network, thesensor nodes that are far away from a mobile sink may notbe significantly affected by a single movement of the mobilesink. Take the sensor network shown in Fig. 6 as anexample, when the mobile sink moves from trail point A totrail point B, the yellow sensor node at the left bottomcorner may still have the same hop count distance to themobile sink, and the routing path chosen from last “move” ofthe mobile sink may still be valid. In this case, the trailmessages can be suppressed with high probability. Second,when a node has finished data reporting and forwarding,trail reference updating becomes meaningless and results inhuge waste of energy, especially for peripheral sensornodes. To properly handle these two situations, we proposea message suppression policy at a small cost of extra statestorage at each sensor node. Each sensor node will comparethe current hop count distance to a mobile sink with themost recently received one. If these two are same, itindicates the path length through the node to the mobilesink is still same, making it unnecessary to rebroadcast thistrail message. In case of the second situation, each nodemaintains a state variable in its memory. When a nodefinishes data reporting, it marks itself as “finished,” andinforms all its neighbor nodes. A node stops trail referenceupdating and trail message rebroadcasting whenever itselfand all its neighbors are “finished.” Again, this method isguaranteed by the timer mechanism that ensures sequentialdata packets reporting order from network peripheral to amobile sink’s current location. For accidental situations dueto timer failure, a new data packet may arrive at a node thathas already stopped trail reference updating. In that caseold trail references are used. This may cause a longer


Fig. 6. An illustrative example to show that mobile sink’s movement hasless impact on remote sensor nodes than immediate ones.

routing path but the result is still acceptable for datareporting. Algorithm 6 presents a detail description ofSinkTrail-S protocol.

Algorithm 6. Trail reference update with message

suppression

1: while Data gathering process is not over do

2: =�——Receive a trail message——�=3: if msg.seqN > � then

4: � msg:seqN;

5: if eidv ¼ msg:hopCþ 1 then

6: Discard the message

7: else

8: Shift vi to left by one position;



11: Rebroadcast message;12: end if

13: else if msg.seqN ¼ � then

14: Compare eidv with (msg:hopCþ 1);

15: if eidv > ðmsg:hopCþ 1Þ then




19: else


21: end if

22: else if msg.seqN < � then


24: end if

25: end while

26: =�——Reset Variables——�=27: For j ¼ 1; . . . ; dv ei

j �1;28: � �1;

4 PERFORMANCE EVALUATION

There are many mobile sink oriented approaches for datacollection in sensor networks, e.g., Directed Diffusion [8],TTDD [24], and GRAB [25]. These protocols, as inSinkTrail, do not pose any constraint on a mobile sink’smovement, nor do they require any special setup phase,generaly referred to as sink-oriented data disseminationapproaches. Although SODD approaches may applydifferent aggregation functions for better performance,similar strategies can be applied to SinkTrail as well. Inorder to gain more insights on the energy efficiency ofSinkTrail, and to demonstrate the advantage of incorporat-ing sink location tracking, we compare the overall energyconsumption of SinkTrail with these protocols. Simulationresults for SinkTrail-S are also presented to show furtherimproved performance.

4.1 Theoretical Analysis

Before we proceed the following variables are defined forclear presentation and fair comparison. We consider anetwork IN that consists of N sensor nodes and M mobilesinks. All the sensor nodes are data sources. We assumesensor nodes are deployed in a grid topology for ease ofunderstanding. However, our analysis can be extended to

other uniformly distributed topology. Therefore, the edgeof the grid is roughly

ffiffiffiffiffiNp

. Denote the energy cost fortransmitting or receiving a control message be �,1 and thecost for a data packet be �. We have � >> � sincecompared to trail messages, data packets are usually largerin terms of data size, which is proportional to the energycost for radio transmission.

In SinkTrail, energy consumption mainly includes datapacket forwarding cost, Edata, routing table maintenancecost, Erouting, and trail message transmission cost, Etrail.

Two factors affect the energy cost of data forwarding:number of data packets and the average route length. Thenumber of data packets is determined by the number ofdata sources in a network, in this case, N . The average routelength, on the other hand, may vary depending on thelocations a mobile sink has traveled. We estimate an upperbound of the average route length by considering thesituation that a mobile sink appears randomly at a locationinside the deployed field. In this case, we can find N

2 pairs ofsensor nodes that any one pair of nodes’ distances to themobile sink added up to at most

ffiffiffiffiffiffiffi2Np

. Thus, the averageroute length should be upper bounded by N

2 �ffiffiffiffiffiffiffi2Np

=N . Weuse a coefficient c, where 0 < c � 1

2 , to describe the averageroute length. Hence, we have

Edata ¼ � � c �ffiffiffiffiffiffiffi2Np

�N: ð1Þ

This energy cost upper bound for data reporting will not beaffected by the number of mobile sinks, since every datareporting message will travel through the shortest possiblepath. Increased number of mobile sink will only decreasethe total energy cost for data reporting.

According to SinkTrail protocol, the total number of trailmessages depends on the network size, N , the number oftrail points visited by each mobile sink, D�, and the numberof mobile sinks, M. The energy consumption for trailmessage transmission is given by

Etrail ¼ � �M �N �D�: ð2Þ

In SinkTrail, the energy consumption for each node tomaintain local routing information is linearly proportionalto the number of its neighbors, denoted by b. If there aremultiple mobile sinks, the energy consumption increases aseach node keeps a different trail reference for each mobilesink. Because of the broadcast nature of wireless media, thistype of control message only needs to be transmitted onceby each sensor node. Therefore, the energy cost for routinginformation maintenance is summarized by

Erouting ¼ � �N �M: ð3Þ

The overall energy consumption of SinkTrail protocol is

EST ¼ � � c �ffiffiffiffiffiffiffi2Np

�N þ � �M �N �D� þ � �N �M: ð4Þ

TTDD [24] is a well-known data dissemination protocolthat uses mobile sinks. Since in TTDD, data collectionrequests are initiated by mobile sinks, it in fact belongs tothe category of SODD approach. The basic data gatheringprocedure of TTDD is preceded by a data grid setup phase,


1. In practice, energy cost for transmitting and receiving might beslightly different.

where each data source propagates some descriptiveinformation about its data to the whole network in orderto construct a grid structure for guiding the forwarddirection of query messages. When a mobile sink queriesfor certain data, this query message is only flooded within agrid cell, then the preconstructed data grid structure willhelp the query find the corresponding data source.According to this description, the total energy consumptionof TTDD includes the following three components: energyused for grid constructing, Egrid; query flooding, Equery; anddata reporting, E0data.

The energy cost for data reporting in TTDD is deter-mined by amount of data packets and length of routingpaths. Since in TTDD, data packets are routed toward amobile sink that appears randomly in the deployed field,the average route length is similar to SinkTrail. Therefore,we have

E0data ¼ � � c �ffiffiffiffiffiffiffi2Np

�N: ð5Þ

According to TTDD protocol, the whole deployed area isdivided into small cells. A query for data is only floodedinside one cell. However, as we are considering a datacollection process that aims at getting all sensed data in thenetwork, it is reasonable to argue that this single query willaffect each of the data sources, thus will be propagated byall sensor nodes in the network. Therefore, we have

Equery ¼ � �M �N � bcast; ð6Þ

where bcast is the number of such query broadcasts.In the grid construction phase every data source in the

network propagates a descriptive message about its data tothe whole network, so that certain nodes will becomeanchors for a particular data source. Since every node is apotential data sources, the energy cost for this procedure is

Egrid ¼ � �N �N: ð7Þ

Adding the energy consumption of different taskstogether, we have

ETTDD ¼ � � cffiffiffiffiffiffiffi2Np

�N þ � �M �N � bcast þ � �N �N: ð8Þ

Comparing (4) and (8), we can see that one of thedifferences lies in the second term. Since D� represents thenumber of broadcasts a mobile sink makes during the datagathering procedure in SinkTrail, and bcast indicates thenumber of times a sink initiates a query in TTDD, these two

variables can be set as equal. Thereafter, the difference canbe ignored here. Another difference is between the routinginformation exchange cost and grid construction cost.Typically, the number of mobile sinks should be signifi-cantly less than total number of sensor nodes, i.e., M << N ,and � �N �M << � �N �N . Hence, we have EST < ETTDD,meaning that the total energy consumption of SinkTrailprotocol is less than the energy cost by TTDD under thesame condition.

According to the theoretical analysis, we can see thatTTDD’s special grid setup phase facilitates a mobile sink toquickly collect a small amount of data in the network,unsuitable for collecting data from all sensors. The energyconsumption of TTDD to collect all data includes energyconsumption of the generalized SODD method plus aconstant grid setup cost.

4.2 Simulation Results

We conducted extensive simulations for different scenariosusing TOSSIM [10] to compare the performance of Sinktrailand SODD. SODD is implemented following the abstractiondescribed in [24]. An extension to TOSSIM is implementedto allow us simulate the sink mobility following predefinedmoving patterns. Simulation of TTDD is omitted for thefollowing reasons. First, TTDD falls into the category ofgeneral SODD approach, hence, generalized SODD ap-proach can capture the main features of TTDD. Moreover,after the theoretical analysis, we can see that the grid setupphase in TTDD is targeted at querying specific data, and notvery suitable to our data collection scenario.

Note that SinkTrail-S is not included in this set ofcomparison. Another set of simulation results will bepresented later to investigate the effectiveness of messagesuppression.

In the SODD approach, whenever a mobile sink moves toa different location, it broadcasts its current position to thewhole network. As the message propagates a routing tree isestablished. Each node reports back its sensed data to parentnode and finally, all data are merged at the root. ThisSODD approach suffers from losing track of the sink whenlocation update is infrequent. To ensure fair comparison, abroadcast frequency higher than typically required bySinkTrail is used to ensure proper termination of SODD.We use one mobile sink in this set of simulations. The mobilesink moves in a rectangular or circular fashion in bothalgorithms. We set the data gathering threshold to 98 percent.From Figs. 7a and 7b, we observe that SinkTrail protocol


Fig. 7. Performance comparison between SODD and SinkTrail. (a) Average routing path length. (b) Total energy consumption. (c) Route lengthvariances: circular sink movement. (d) Route length variances: rectangular sink movement.

outperforms SODD for every experimental network size.The energy consumption saving is on average 35.06 percentwith a route length deduction of 33.80 percent for one sinkSinkTrail. Figs. 7c and 7d show the standard deviation of theroute lengths generated by SODD and SinkTrail protocols.As you can see, SinkTrail protocol results in a more evenrouting path length distribution throughout the network. Allthese results validate the conclusion that SinkTrail helps amobile sink to achieve energy efficient data gathering inwireless sensor networks.

To demonstrate the effectiveness of message suppres-sion in SinkTrail-S, we simulated SinkTrail-S with circularand linear sink moving patterns and compare the resultwith the basic SinkTrail protocol. It is worth noting thatenergy cost for informing neighbors is also counted inimplementation. In Fig. 8, we observe that, althoughSinkTrail-S spends extra costs on state storage andinforming message transmission, the method effectivelyreduces energy consumption in the investigated scenarios.

5 IMPACT FACTORS

5.1 Impact of Moving Patterns of a Mobile Sink

First, we examine how the moving pattern of a mobile sinkcan affect the energy consumption for data collection, asdirectional change in a mobile sink’s movement is unavoid-able due to occasional obstacles depicted in Fig. 3.

To numerically model the moves conducted by a mobilesink, we trace the moving trail of a mobile sink on a plainand measure the directional change at each trail point.Specifically, suppose at some time the mobile sink arrives attrail point �i 2 �, we define the angular displacement �i asthe angular variation of moving directions. Fig. 9aillustrates an example of recorded angular displacementsat multiple trail points. As a result, the accumulativeangular displacement of a mobile sink becomes a quanti-tative metric for the moving pattern. In Figs. 9b, 9c, and 9d,

we depict three representative moving patterns performedby a mobile sink. In simulation, we distributed sensornodes in a grid topology. The network size varied from6� 6 sensor nodes to 26� 26 (with step size 1). Anempirical radio signal strength trace is loaded for eachsimulated sensor nodes. The radio sensitivity parameter isadjusted so that each node has about 5 to 12 neighbors,which is in accordance with realistic situations. We alsodesignate � to be 20 times of � in the simulation [26]. Theperformance of SinkTrail is inspected in terms of averageroute length and overall energy consumption. Threemoving patterns including circular, random, and linearmoves are compared. The results are shown in Figs. 10aand 10b.

From these two figures, we observe that, both theaverage route length and energy consumption increase asthe network size grows. For the three moving patterns,linear movement incurs the least energy consumption andthe shortest average route length. As to the circularmovement case, the mobile sink changes its directionregularly and smoothly, leading to performance close tothe linear movement case. Finally, for the random movecase, the results vary in a wide range that indicated by thedashed bars bounding the average values. This is because itis more difficult to track and predict the behavior of arandomly moving mobile sink. Therefore, SinkTail’s overallperformance may suffer greatly when the directionalchange is radical at some trail point. Although SinkTraildoes not place any moving restriction in general, changingdirections strategically in a smooth and regular manner ismore beneficial than radical and unpredictable moving inSinkTrail.

5.2 Impact of Number of Mobile Sinks

We are interested in finding out how the number of mobilesinks affects the overall system performance. In the scenariowith multiple mobile sinks, several logical coordinatespaces are constructed concurrently and data packets areforwarded to the destination reference via the shortest pathin any coordinate space. It is natural to think that increasingthe number of mobile sinks reduces the average route lengthand thus reduces the total energy consumption. None-theless, more mobile sinks also impose heavier burdens fortrail message broadcasting and routing information main-tenance. Even worse, multiple number of mobile sinks in anetwork aggravate control traffic congestion and commu-nication delays, which will in turn result in higher packetloss and retransmission rate. To acquire visualized resultson the impact, we simulate the multiple mobile sinks


Fig. 8. Performance comparison between SinkTrail protocol andSinkTrail-S protocol.

Fig. 9. Mobile sink moving pattern. (a) Angular displacement �i at eachtrail points. (b) Circular moving pattern, ��i is 360 degree. (c) Randommoving pattern, ��i is greater than 360 degree. (d) Linear movingpattern, ��i is 0 degree.

Fig. 10. Impact of mobile sink’s moving pattern.

scenario using the aforementioned simulation setup. Thenumber of mobile sinks used is up to three and they areinjected into the network at the same time. For faircomparison all the mobile sinks moved randomly viadifferent routes, and broadcasted at the same frequency.We averaged the results of 20 simulation runs and theresults are exhibited in Figs. 11a and 11b. The trends shownin the figures confirm our analysis. The average route lengthis reduced by 46.54 and 53.70 percent for two andthree sinks, respectively; while for the total energy cost,using more mobile sinks increases trail messages androuting table costs, thereby yield to 17.6 and 33.06 percentenergy consumption increment for two and three sinks,respectively. Overall, defining route length deduction overextra energy cost as performance price ratio, we have 2.64for two sinks and 1.62 for three sinks scenario. According tothis, we conclude that adding multiple sinks is moresuitable for applications with tight data gathering deadlines.

5.3 Impact of Broadcasting Frequency

The impact of sink broadcast frequency is two sided. If themobile sink broadcasts its trail messages more frequently,sensor nodes will get more up-to-date trail references, whichis helpful for locating the mobile sink. On the other hand,frequent trail message broadcast results in heavier transmis-sion overheads. Suppose the time duration between twoconsecutive message broadcasting is �t, we derive a generalrange of �t to guide the proper implementation of SinkTrailand SinkTrail-S.

Assume the trail message is transmitted instantaneously,then �t is determined by mobile sink’s traveling time �tmbetween two consecutive trailing points and sojourn time �tsat each trail point

�t ¼ �tm þ�ts: ð9Þ

Given the average mobile sink moving speed , we firstformulate the lower bound for �t. Note that it is useless forthe m obile sink to broadcast multiple times before it movesout of a sensor node’s radio range, as all these broadcastmessages will have the same hop counts. Hence, the firstrestriction is that two trail points should be separated by adistance longer than sensor node’s average radio range � ,we have

��tm > �: ð10Þ

Combining (9) and (10) makes �t > � þ�ts. In addition,

for each transmission, the time duration should be long

enough for a trail message to permeate the wholenetwork, let this permeation time be ’, the lower boundof �t is maxf� þ�ts; ’g.

On the other hand, the upper bound of �t is applicationspecific. If the data gathering process is expected to finish in�total time, then during this time, the mobile sink should atleast traversed all the dv trail points. Therefore, we have�t < �total

dv. In summary, the range of �t is given by

�t 2 max�

þ�ts; ’

� �;�total

dv

� �: ð11Þ

Once �t is determined, we can derive the step sizeparameter K as follows:

�tm � ¼ K � �)

K ¼ �tm � �

:

ð12Þ

As this theoretical range of �t is very broad andapplication specific, in Figs. 12a and 12b, we plotted somesimulation results for a number of broadcast frequencies.The broadcasting frequency is indicated by the time intervalbetween to consecutive broadcasts. We can see that shorterbroadcast interval, i.e., more frequent control messagebroadcasting, does benefit the average route length, as trailreferences are refreshed in a timely fashion. However, higherupdate frequency propagates more messages, therebyincurring more energy consumption, especially for largenetwork size. It is important to find a tradeoff pointbalancing different requirements when it comes to realapplication implementation.

Based on the conceptual sensitivity analysis in this section,choices of these parameters settings depend on specificapplication scenarios and user requirements. The analysishere can be used as a guideline for real system design, andcan also be used as performance metrics for comparisonstudy with other schemes.

6 CONCLUSION

We presented the SinkTrail and its improved version,SinkTrail-S protocol, two low-complexity, proactive datareporting protocols for energy-efficient data gathering.SinkTrail uses logical coordinates to infer distances, andestablishes data reporting routes by greedily selecting theshortest path to the destination reference. In addition,


Fig. 12. Impact of broadcast frequency.Fig. 11. Impact of the number of mobile sinks.

SinkTrail is capable of tracking multiple mobile sinkssimultaneously through multiple logical coordinate spaces.It possesses desired features of geographical routing with-out requiring GPS devices or extra landmarks installed.SinkTrail is capable of adapting to various sensor fieldshapes and different moving patterns of mobile sinks.Further, it eliminates the need of special treatments forchanging field situations. We systematically analyzedenergy consumptions of SinkTrail and other representativeapproaches and validated our analysis through extensivesimulations. The results demonstrate that SinkTrail findsshort data reporting routes and effectively reduces energyconsumption. The impact of various design parametersused in SinkTrail and SinkTrail-S are investigated toprovide guidance for implementation.

We are currently working with collaborators in theGreenSeeker system [20]. Through one-hop sensing, theGreenSeeker system applies the precise amount of Nitrogenadaptive to spatial and temporal dynamics of the farmland,increasing yield and reducing Nitrogen input expense. TheSinkTrail protocol can be further integrated with theGreenSeeker system to enable large-scale multihop sensingon demand and automate spray systems for optimalfertilizer and irrigation management.

ACKNOWLEDGMENTS

The work presented in this paper is supported in part byUS National Science Foundation under Grant Nos. CNS-0709329, CNS-0923238, and CNS-0940805 (BBN subcontract)and OCAST.

REFERENCES

[1] S. Basagni, A. Carosi, E. Melachrinoudis, C. Petrioli, and Z.M.Wang, “Controlled Sink Mobility for Prolonging Wireless SensorNetworks Lifetime,” ACM/Elsevier Wireless Networks, vol. 14,pp. 831-858, 2007.

[2] C. Chou, K. Ssu, H. Jiau, W. Wang, and C. Wang, “A Dead-EndFree Topology Maintenance Protocol for Geographic Forwardingin Wireless Sensor Networks,” IEEE Trans. Computers, vol. 60,no. 11, pp. 1610-1621, Nov. 2010.

[3] D. Coffin, D. Van Hook, S. McGarry, and S. Kolek, “DeclarativeAd-Hoc Sensor Networking,” Proc. SPIE, vol. 4126, p. 109, 2000.

[4] M. Demirbas, O. Soysal, and A. Tosun, “Data Salmon: A GreedyMobile Basestation Protocol for Efficient Data Collection inWireless Sensor Networks,” Proc. IEEE Third Int’l Conf. DistributedComputing in Sensor Systems, pp. 267-280, 2007.

[5] K. Fodor and A. Vidacs, “Efficient Routing to Mobile Sinks inWireless Sensor Networks,” Proc. Third Int’l Conf. Wireless Internet(WICON), pp. 1-7, 2007.

[6] R. Fonseca, S. Ratnasamy, J. Zhao, C.T. Ee, D. Culler, S. Shenker,and I. Stoica, “Beacon Vector Routing: Scalable Point-To-PointRouting in Wireless Sensornets,” Proc. Second Conf. NetworkedSystems Design and Implementation (NSDI), pp. 329-342, 2005.

[7] Q. Huang, C. Lu, and G. Roman, “Spatiotemporal Multicast inSensor Networks,” Proc. First ACM Conf. Embedded NetworkedSensor Systems (SenSys), pp. 205-217, 2003.

[8] C. Intanagonwiwat, R. Govindan, and D. Estrin, “DirectedDiffusion: A Scalable and Robust Communication Paradigm forSensor Networks,” Proc. MobiCom, pp. 56-67, 2000.

[9] M. Keally, G. Zhou, and G. Xing, “Sidewinder: A Predictive DataForwarding Protocol for Mobile Wireless Sensor Networks,” Proc.IEEE Sixth Ann. Comm. Soc. Conf. Sensor, Mesh and Ad Hoc Comm.and Networks (SECON), pp. 1-9, June 2009.

[10] P. Levis, N. Lee, M. Welsh, and D. Culler, “TOSSIM: Accurate andScalable Simulation of Entire Tinyos Applications,” Proc. FirstACM Conf. Embedded Networked Sensor Systems (SenSys), pp. 126-137, 2003.

[11] Z. Li, N. Wang, A. Franzen, P. Taher, C. Godsey, H. Zhang, andX. Li, “Practical Deployment of an In-Field Soil Property WirelessSensor Network,” Computer Standards and Interfaces, vol. 33, pp. 13-23, 2011.

[12] B. Liu, W. Ke, C. Tsai, and M. Tsai, “Constructing a Message-Pruning Tree with Minimum Cost for Tracking Moving Objects inWireless Sensor Networks is Np-complete and an Enhanced DataAggregation Structure,” IEEE Trans. Computers, vol. 57, no. 6,pp. 849-863, June 2008.

[13] J. Luo and J.-P. Hubaux, “Joint Mobility and Routing for LifetimeElongation in Wireless Sensor Networks,” Proc. IEEE INFOCOM,vol. 3, 2005.

[14] M. Ma and Y. Yang, “Data Gathering in Wireless Sensor Networkswith Mobile Collectors,” Proc. IEEE Int’l Symp. Parallel andDistributed Processing (IPDPS), pp. 1-9, Apr. 2008.

[15] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J.Anderson, “Wireless Sensor Networks for Habitat Monitoring,”Proc. First ACM Int’l Workshop Wireless Sensor Networks andApplications (WSNA), pp. 88-97, 2002.

[16] T. Moscibroda, R. O’Dell, M. Wattenhofer, and R. Wattenhofer,“Virtual Coordinates for Ad Hoc and Sensor Networks,” Proc.Joint Workshop Foundations of Mobile Computing (DIALM-POMC),pp. 8-16, 2004.

[17] T. Park, D. Kim, S. Jang, S. eun Yoo, and Y. Lee, “Energy Efficientand Seamless Data Collection with Mobile Sinks in MassiveSensor Networks,” Proc. IEEE Int’l Symp. Parallel and DistributedProcessing (IPDPS), pp. 1-8, May 2009.

[18] A. Rao, S. Ratnasamy, C. Papadimitriou, S. Shenker, and I. Stoica,“Geographic Routing without Location Information,” Proc. Mobi-Com, pp. 96-108, 2003.

[19] D. Shah and S. Shakkottai, “Oblivious Routing with Mobile FusionCenters over a Sensor Network,” Proc. IEEE INFOCOM, pp. 1541-1549, 2007.

[20] J. Solie, M. Stone, W. Raun, G. Johnson, K. Freeman, R. Mullen, D.Needham, S. Reed, C. Washmon, and P. Robert, “Real-TimeSensing and N Fertilization with a Field Scale GreenSeekerApplicator,” Proc. Am. Soc. Agronomy, 2002.

[21] A.A. Somasundara, A. Ramamoorthy, and M.B. Srivastava,“Mobile Element Scheduling for Efficient Data Collection inWireless Sensor Networks with Dynamic Deadlines,” Proc. IEEE25th Int’l Real-Time Systems Symp. (RTSS), pp. 296-305, 2004.

[22] A.A. Somasundara, A. Ramamoorthy, and M.B. Srivastava,“Mobile Element Scheduling for Efficient Data Collection inWireless Sensor Networks with Dynamic Deadlines,” Proc. IEEE25th Int’l Real-Time Systems Symp. (RTSS), pp. 296-305, 2004.

[23] O. Soysal and M. Demirbas, “Data Spider: A Resilient MobileBasestation Protocol for Efficient Data Collection in WirelessSensor Networks,” Proc. Int’l Conf. Distributed Computing in SensorSystems (DCOSS), 2010.

[24] F. Ye, H. Luo, J. Cheng, S. Lu, and L. Zhang, “A Two-tier DataDissemination Model for Large-Scale Wireless Sensor Networks,”Proc. MobiCom, pp. 148-159, 2002.

[25] F. Ye, G. Zhong, S. Lu, and L. Zhang, “Gradient Broadcast: ARobust Data Delivery Protocol for Large Scale Sensor Networks,”Wireless Networks, vol. 11, no. 3, pp. 285-298, 2005.

[26] M. Younis, M. Youssef, and K. Arisha, “Energy-Aware Routing inCluster-Based Sensor Networks,” Proc. IEEE 10th Int’l Symp.Modeling, Analysis and Simulation of Computer and Telecomm.Systems (MASCOTS), pp. 129-136, 2002.

[27] L. Yu, N. Wang, and X. Meng, “Real-Time Forest Fire Detectionwith Wireless Sensor Networks,” Proc. Int’l Conf. Wireless Comm.,Networking and Mobile Computing, vol. 2, pp. 1214-1217, 2005.

[28] M. Zhao, M. Ma, and Y. Yang, “Mobile Data Gathering withSpace-Division Multiple Access in Wireless Sensor Networks,”Proc. IEEE INFOCOM, pp. 1283-1291, Apr. 2008.

[29] M. Zhao, M. Ma, and Y. Yang, “Efficient Data Gathering withMobile Collectors and Space-Division Multiple Access Techniquein Wireless Sensor Networks,” IEEE Trans. Computers, vol. 60, no. 3,pp. 400-417, Mar. 2011.

[30] M. Zhao and Y. Yang, “Bounded Relay Hop Mobile DataGathering in Wireless Sensor Networks,” IEEE Trans. Computers,vol. 61, no. 2, pp. 265-277, Feb. 2012.


Xinxin Liu received the BE degree in softwareengineering from Jilin University, China. Cur-rently, she is working toward the PhD degree inthe Department of Computer and InformationScience and Engineering at the University ofFlorida. Her research interests include wirelesssensor networks and resource management.She is a student member of the IEEE.

Han Zhao received the BE degree in softwareengineering from Jilin University, China, and theMSc degree in computer science from Oklaho-ma State University. Currently, he is workingtoward the PhD degree in the Department ofComputer and Information Science and Engi-neering at the University of Florida. His researchinterests include parallel and distributed comput-ing, autonomic systems, and P2P systems. Heis a student member of the ACM and the IEEE.

Xin Yang received the BS degree in theDepartment of Computer Science and Technol-ogy from Nanjing University, China. Currently,he is working toward the PhD degree in theDepartment of Computer and InformationScience and Engineering at the University ofFlorida. His research interests include high-performance computing and cloud computing.

Xiaolin Li received the PhD degree in computerengineering from Rutgers University. Currently,he is working as an associate professor in theDepartment of Electrical and Computer Engi-neering at the University of Florida. His researchinterests include parallel and distributed sys-tems, cyber-physical systems, and networksecurity. His research has been sponsored byUS National Science Foundation (NSF), Depart-ment of Homeland Security (DHS), and other

funding agencies. He is an associate editor of several internationaljournals and a program chair or cochair for more than 10 internationalconferences and workshops. He is on the executive committee of IEEETechnical Committee on Scalable Computing (TCSC) and served as apanelist for NSF. He is directing the Scalable Software SystemsLaboratory (http://www.s3lab.ece.ufl.edu). He received the NationalScience Foundation CAREER Award in 2010. He is a member of theIEEE and the ACM.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 1,...

Documents

Transcript of IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 1,...