A data collection protocol for real-time sensor - Inside Mines

Pervasive and Mobile Computing 5 (2009) 369–384

Contents lists available at ScienceDirect

Pervasive and Mobile Computing

journal homepage: www.elsevier.com/locate/pmc

A data collection protocol for real-time sensor applicationsI

Lilia Paradis a, Qi Han b,∗aMicrosoft Corporation, Redmond, WA 98052, United Statesb Department of Math and Computer Sciences, Colorado School of Mines, Golden, CO, United States

a r t i c l e i n f o

Article history:Received 29 August 2008Received in revised form 15 February 2009Accepted 14 April 2009Available online 3 May 2009

Keywords:Energy efficiencyReal timeSensor data collection

a b s t r a c t

The nature of many sensor applications as well as continuously changing sensor data oftenimposes real-time requirements on wireless sensor network protocols. Due to numerousdesign constraints, such as limited bandwidth, memory and energy of sensor platforms,and packet collisions that can potentially lead to an unbounded number of retransmissions,timeliness techniques designed for real-time systems and real-time databases cannot beapplied directly to wireless sensor networks. Our objective is to design a protocol forsensor applications that require periodic collection of raw data reports from the entirenetwork in a timely manner. We formulate the problem as a graph coloring problem. Wethen present TIGRA (Timely Sensor Data Collection using Distributed Graph Coloring) —a distributed heuristic for graph coloring that takes into account application semanticsand special characteristics of sensor networks. TIGRA ensures that no interference occursand spatial channel reuse is maximized by assigning a specific time slot for each node.Although the end-to-end delay incurred by sensor data collection largely depends on aspecific topology, platform, and application, TIGRA provides a transmission schedule thatguarantees a deterministic delay on sensor data collection.

Published by Elsevier B.V.

1. Introduction

Wireless sensor networks (WSNs) may be used in a variety of event-driven applications where the network is normallyidle and only activated in response to a critical change in the observed phenomena. Once an event is detected, frequentand periodic updates from the sensors to the sink are needed for better understanding of event evolution to ensure promptresponse. Sensor data here is very time-sensitive and a real-time communication protocol needs to be in place to ensuretimely data delivery. In addition,many applications often require rawdata from the sensor network [1] since aggregated dataloses the level of detail that is often essential to exploratory research. Note that the need of raw data does not prevent thesystem fromcombining sensor readings fromdifferent nodes. For instance, one of our ongoing research projects is tomonitorsubsurface contaminants using wireless sensor networks. We are developing a closed loop system integrating a wirelesssensor network and numerical contaminant transport models [2]. The numerical models are computationally intensive andhave to be run on powerful computers. The input to the model is the raw sensor readings instead of aggregated values.Typically, to conserve energy, the sensor network is programmed to be event-driven, i.e., a node will only report whenits observation such as the sensed electrical conductivity level exceeds a certain threshold. However, once a contaminantplume is detected by certain nodes, the network is activated to report periodically so that the numerical model can becontinuously re-calibrated using a continuous stream of sensor data in order to capture transient contaminant plumes to

I This work is supported in part by NSF CSR grant CNS-0720875.∗ Corresponding author. Tel.: +1 303 273 3849; fax: +1 303 273 3875.E-mail addresses: [email protected] (L. Paradis), [email protected] (Q. Han).

1574-1192/$ – see front matter. Published by Elsevier B.V.doi:10.1016/j.pmcj.2009.04.003

http://www.elsevier.com/locate/pmc

http://www.elsevier.com/locate/pmc

mailto:[email protected]

mailto:[email protected]

http://dx.doi.org/10.1016/j.pmcj.2009.04.003

370 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (2009) 369–384

assess the source, track plumes in real time and predict future plume behavior. The need for raw data in real time is alsotrue for other applications such as landslide monitoring.It is desirable to provide a guarantee on the latency in delivering data from multiple sources to a single sink. A known

latency bound ensures real-time event detection and helps the sink to schedule application requests. However, this presentsseveral challenges. First, multihop communication coupled with the potential of combining several sensor reports into onedata packet creates unique precedence constraints. Second, both primary and secondary conflicts inwireless networksmustbe avoided [3]. A primary conflict occurs when a node transmits and receives at the same time slot or receives more thanone transmission destined to it at the same time slot. A secondary conflict occurs when a node, an intended receiver ofa particular transmission, is also within the transmission range of another transmission intended for other nodes. Third,careful reuse of spatial wireless channels (i.e., more than one node can transmit at the same time slot) can help shorten thepacket delivery latency, but interference constraints must be satisfied.This paper makes the following contributions.• We formulate the problem of minimizing latency in sensor data collection as an NP-hard graph coloring problem.• We then propose a distributed heuristic, TIGRA (Timely Sensor Data Collection using Distributed Graph Coloring), thatdetermines a transmission schedule for all the nodes in the network. The schedule provides deterministic end-to-endlatency in sensor data collection. This is achieved by using packet combination and exploiting spatial reuse of thewirelesschannel to schedule non-interfering transmissions in parallel, progressively and locally building the interference set foreach node, explicitly eliminating collisions, and implicitly avoiding network congestion. Moreover, TIGRA is independentof MAC protocols, does not need location information of nodes, and does not assume symmetric wireless links.• We further prove the correctness and termination of TIGRA, and conduct a worst case complexity analysis of TIGRA.• Finally, we compare TIGRA with several existing timeliness techniques under various network settings in TOSSIM andfurther evaluate TIGRA’s performance in a sensor network testbed.

2. Related work

Existing techniques for supporting real-time communication inWSNs cannot be directly applied to our problem at hand.Timeliness has been approached from a network design perspective and fundamental capacity limits on real-time datathat can be transmitted in a given sensor network are established [4]. Further studies on scheduling and real-time capacityhave been conducted on hexagonal WSNs [5]. Our work complements theirs by proposing a specific algorithm to improvetimeliness in data collection in a general sensor network topology.Supporting timeliness by enforcing packet speed has been explored in SPEED [6] and RAP [7]. Both protocols, however,

cannot guarantee a specific data delivery latency. In addition, both protocols rely on information about the physical locationof nodes and distances between them, which is not necessarily available in our application scenario.Concurrently scheduling non-interfering transmissions in WSNs has been studied to address timeliness by applying

graph coloring approaches [8,9]. However, both protocols are centralized. Moreover, in their work, the interference set isdetermined centrally based on the location and transmission range of each node, which is an unrealistic assumption in ourapplication scenario. Further, no packet combination is used; hence precedence dependencies between the transmissionsare not considered.Solely relying on contention-based MAC layer protocols like CSMA makes it difficult if not impossible to provide a

guarantee on data collection latency. Those protocols do not completely avoid collisions since a node backs off randomlyif collisions are detected, leading to unpredictable delay. Schedule-based MAC protocols for WSNs such as T-MAC [10], S-MAC [11], PEDAMACS [12], DRAND[13], or TDMA-based link scheduling [14] can be used to eliminate collisions and obtaina bound on data collection latency. However, they aim to minimize the time required for each node to communicate oncewith all its neighbors. They typically assign the same number of time slots to all the nodes. As a result, these protocols tend towaste time slotswhen a node does not have any newdata in a given slot. Instead,we are interested in determining a schedulesuch that the entire collection can be completed in a minimal number of time slots. Directly applying their approaches mayincur very high latency.Energy–latency tradeoffs have been addressed in the context of aggregated sensor data collection by considering

techniques such as modulation scaling [15]. Our work, however, considers a scenario where the raw data instead of theaggregated data is needed. In addition, we do not consider adjustment of sensor nodes’ transmission powers.At the high level, our work addresses similar problems as [16]. However, instead of selecting multiple parents as in [16],

we use a single parent tree structure for data collection and our focus is to determine a conflict-free transmission schedulethat can complete the reports of all involved sensors in the shortest possible amount of time. Flexible Power Scheduling(FPS) [17] aims to reduce energy consumption while supporting the fluctuating demand of data collection traffic in sensornetworks. To this end, a coarse-grained scheduling at the routing layer combined with a fine-grained scheduling at theMAClayer is used. While the tradeoff between latency and energy is studied, minimizing the data collection latency is not theprimary objective of FPS and hence no spatial channel reuse is exploited.Our work bears certain similarity with several existing efforts in bounding sensor data collection latency [18–20].

However, packet combination, which increases the scheduling complexity, is not considered in either of the papers. Inaddition, the algorithms presented in [18,19] are centralized and the approaches taken in [20] assume symmetric wirelesslinks, which is not realistic, as found in previous studies [21].

L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (2009) 369–384 371

3. Problem formulation

We consider wireless sensor networks with a single sink and multiple homogeneous data sources for applications thatrequire rawdata periodically. In this scenario, each sensor node periodically produces a newvalue and this valuemayneed totraversemultiple hops to reach the sink. The reading from a node can be combinedwith the readings from other nodes on itsway to the sink. Given a set of sensor values that are generated periodically, our objective is to schedule all the transmissionsfor each period to be completed in the shortest possible amount of time. Ideally, all the non-interfering transmissions canbe scheduled at the same time slot to minimize the overall delay. Note that latency here is defined as the time betweenwhen the first packet is sent out and the time when the last packet is received by the sink. This latency is different from theaverage packet latency.Tree-based collection has typically been used in these applications. If the same routing tree topology is maintained, at

each period every sensor node sends the same number of readings upstream to the sink, whether generated at the node orrelayed for one of its child nodes.Previous studies have found that sensor network topology is often semi-static and does not undergo very frequent

changes [21]. Therefore, a pre-determined transmission schedule is desirable, especially in short-term monitoringapplications (typically on the order of hours or days) that we are targeting, as those described in Section 1. A pre-determinedtransmission schedule not only implicitly avoids network congestion that is often caused by bursty data traffic, but alsoeliminates packet collisions. Both network congestion and packet collisions lead to packet drop and retransmission, andthereby packet latency. Latency introduced by link or node failures will be considered in our future work.As with any scheduling-based algorithm, nodes should be clock synchronized, since a typical clock drift for a sensor node

is 30–50 µs per second. Clock synchronization is not the focus of this work: one of the existing solutions [22] may be used.

3.1. Batch transmission

In many WSN applications, a sensor reading can often be represented with a small number of bytes, so more thanone reading can fit into a standard transmission packet. We exploit this property to reduce the number of packetstransmitted. Instead of individually sending each sensor reading, the readings are batched or combined at intermediatenodes and forwarded upstream along the tree.We refer to this as ‘batch processing’. This processing differs from ‘aggregatedprocessing’, where one single value is computed over several sensor readings based on application semantics. In batchprocessing, each raw sensor report is stillmaintained in the packets. Themaximumnumber of readings that can be combineddepends on the size of a sensor reading and the packet size limitations of the platform.Although batch transmission can reduce the number of packets transmitted, which can potentially reduce energy

consumption, intuitively, it seems to conflict with our primary goal of decreasing data collection latency. However,we are more interested in the final completion time, rather than individual packet delay, so it is justifiable to exploitbatch processing. However, batch transmission processing creates additional precedence constraints when determininga transmission schedule. If m is used to indicate the maximum number of readings that one packet can have, in order tomaximize energy savings from using batch transmission, the number of ‘‘saturated’’ packets that have m readings has tobe maximized. To achieve that, unless a node is a leaf or the number of its descendant nodes is a multiple of m, it shouldtransmit only after receiving a packet from one of its children and combining its own reading with the existing payload.

3.2. Problem statement

The problem can be stated formally as follows. Given a network represented by a graph G = (V , E), where V is the setof nodes including the sink s, and E is the set of links that connect a pair of nodes where interference can happen: n = |V |is the number of nodes in G. The routes of all nodes form a collection tree and all links in the tree are transmission links. Alltraffic is destined for the sink, so every data packet at a node is forwarded to the node’s parent in the tree rooted at sink s inmultiple hops. A packet can consist of readings from m nodes. The problem, therefore, is to determine the smallest lengthconflict-free assignment of time slots during which the reading generated at each node may be combined with readingsfrom other nodes and transmitted to the sink over the collection tree. In other words, we need to schedule the transmissionlinks in E by taking into account all the possible interferences between the edges. Note that while the data collection followsa routing tree, the network itself is actually a graph since it consists of not only transmission links, but also links that mayinterfere.

4. TIGRA: A transmission scheduling algorithm

Before presenting the details of TIGRA, we first explain various terms used in the transmission schedule (Fig. 1). Thetiming hierarchy also indicates that the scheduling is conducted at different levels. We will use Fig. 2 to show an example oftiming hierarchy for a sample network and then use Fig. 3 to explain how the timing hierarchy is determined for a network.

• Round:Node vi calculates its round ki based on the number of its descendants di: ki = di mod m. Each round is scheduledsequentially; therefore, interference and spatial channel reuse are only possible within the same round.


Fig. 1. TIGRA timing hierarchy.

Fig. 2. Precedence constraints imposed by multihop batch transmissions.

Fig. 3. The three phases of TIGRA.

• Epoch: The set of m rounds will be repeated multiple times until all the packets reach the sink. We refer to a set of mrounds as an epoch. In other words, each epoch consists of m rounds. The farther the nodes are from the sink, the fewerepochs they actively participate in.• Period: A period is specified by an application to indicate the desired frequency of data collection. The applicationrequested period is expected to be longer than the length of the combined epochs necessary to transmit all the packetsto the sink. If this is not the case, TIGRA informs the application of the best possible delay it can provide.• Slot: To avoid interference and improve spatial channel reuse, each round is divided into a number of slots. The numberof slots required can vary from one round to another; therefore, forcing each round to last equal time would introduceunnecessary delay. The length of each round is determined by the number of slots that are necessary to avoid conflictsin a given round.

Consider the example in Fig. 2 where m = 4: node 1 is a leaf and it transmits its reading right away; node 4 has threedescendants, and since m = 4, it waits for the packet from node 3 before reporting its own reading; node 5, however, hasfour descendants which aremultiples ofm; it can conclude that its descendants will form a batch and it can transmit its ownreading creating a new batch for the upstream nodes. If there is no interference between nodes 1 and 5, they can transmittheir readings to their respective parents simultaneously, i.e., in the same round and same slot. Otherwise, node 1 and node5 will transmit in the same round, but at a different slot.In order to determine the timing hierarchy (i.e., round, epoch, period and slot) for a network, TIGRA consists of three

distinct phases (Fig. 3): Round Determination, Slot Determination, and Data Collection. The Round Determination phase hasthree main objectives: (1) performing network discovery and constructing the routing tree; (2) determining the number ofdescendants and deriving the round number for each node and its children; and (3) constructing the interference set. Duringthe Slot Determination phase, specific time slots within a round are determined for each transmission. The exact time wheneach round starts is communicated to the nodes at the end of the Slot Determination phase. During the Data Collectionphase, nodes send their reports to the sink periodically, according to the period requested by the application. At the start ofthe period, the first transmission round of the first epoch begins. Notations used in the paper are summarized in Table 1.

Round Determination phase: This phase essentially consists of three message exchanges through the entire network: (1)an initialization message is sent downstream by the sink, and the routing tree is constructed as a result of this messagepass; (2) response messages are sent back from the leaves to the sink, and round numbers are derived as the result of thismessage pass; (3) amessage is then sent downstream from the sink to the leaves, round conflicts are resolved between childand parent nodes, and the start time for the Slot Determination phase is communicated to the nodes.


Table 1Notations used in TIGRA.

Notation Meaning

s Sinkvi Node with ID in Total number of nodes in the networkpi Parent node of node vichi[] A set of child nodes of node vinci Number of child nodes for node vici Color of node vi , initially ∅C ri [] Color palette of node vi for round rdi Number of descendants for node viki Round at which node vi negotiates with parent piIi[] Interference set of node vim Number of roundstc Waiting period for confirmation from child or parentcr Current round

In this phase, a routing tree is built via broadcasts initiated by the sink. Each sensor maintains the ID of its parent, whichis the node fromwhich it has received the broadcast message. More specifically, a node is initially in the NotInitialized state.Once a node receives an init message, the node sends an initackmessage to the sender, letting the sender know that the nodeintends to become the sender’s child. Once an acknowledgement is received from the potential parent, the node finalizesits parent choice, and broadcasts an init message further down. Each node vi determines the number of its descendantsdi and its round ki, the set of its children chi, its interference set Ii consisting of nodes not directly related to it but withinone-hop communication range, the number of descendants dj, and the round kj for each child vj ∈ chi. If a parent vi and itschild vj ∈ chi[] have the same round number (i.e., if ki = kj), there is a round conflict. In this case, a parent assigns a newround number to such child nodes. The new round number is defined as kj = (ki + 1) mod m. Further, a node needs theinformation about the number of descendants for itself and its children to decide at which epoch it has to participate andat which it does not. The interference set discovered in this phase is not complete and will be further extended in the nextphase.During routing tree construction, it is important to ensure that the tree is balanced. If a node has too many children, this

may result in toomany slots during particular rounds being used by that node and its children, but not being used in the restof the network, which would reduce the amount of parallelism in the network. Therefore, the number of children a nodecan have should be limited. The policy used in TIGRA is that a node should have no more children than m, the maximumnumber of readings in a packet. This would allow the node to combine the readings from all of its children in one packet.The tradeoff between the maximum number of children and the height of data collection tree will be further investigatedin future work.Two special cases need to be handled differently.

• In the case with m = 2, the round determination based on the number of descendants would result in all the nodeswith even hop count using one round and those with odd hop count using the other round, which can potentially requirea number of conflicts between a parent and a child to be resolved and also cause congestion at the sink. To avoid this,the sink assigns alternate rounds (0, 1, 0, 1, . . .) to its immediate children. The round assignment then propagates fromimmediate children to the leaf nodes.• In the case withm = 1, there is only one round. However, a node cannot have the same round when it serves as a parentor as a child. Hence, TIGRA uses two rounds in a similar way as for the case wherem = 2.

Slot Determination phase: This phase schedules the transmissions within the same round, such that interference iseliminated and channel reuse is maximized. At the end of this phase, the nodes report the results of negotiation to thesink. Starting from the leaves, each node sends a packet with the maximum number of slots used for each round. If a nodedoes not participate in a current round, the number of slots for such a round is 0. Upon determining the maximum numberof slots for each round, the sink floods the network with one more message that contains start times for each round relativeto the start of each epoch. The start of each slot can be determined at the nodes locally since it is of standard size and eachnode knows the exact slots during which it will be transmitting or receiving. Details of this phase are presented in the nextsection.

Data Collection phase: In this phase, each node knows which epoch/round/slot it should transmit at based on the scheduledetermined by the previous two phases. Nodes send their reports to the sink periodically, as requested by the application.When a period starts, the first transmission round of the first epoch kicks off. Each node is responsible for setting the timersfor the slots it participates in and being awake when it serves as a child or parent. Nodes go to ‘‘sleep’’ on their ‘‘off’’ slotsor rounds. Upon receiving the report from a child, a node parses the packet, appends its own reading if the packet is notsaturated and its own reading is not transmitted yet, and sends the packet upstream.


5. A distributed graph coloring algorithm for slot determination

Since precedence constraints are addressed by the Round Determination phase, the goal of the Slot Determination phaseis to decide slot numbers of all transmissions within the same round, trying to maximize channel reuse while eliminatinginterference.Scheduling transmission links in a graph G = (V , E) is equivalent to scheduling nodes by using the following conversion.

First, we define an interference graph GI = (V , EI), where EI consists of (i) all edges in E; and (ii) all edges (vi, vj), whereeither vi or vj can hear each other or one of them can interfere with a signal intended for the other (even if they cannot heareach other). Second, we define a conflict graph GC = (V , EC ). EC includes the following edges. (i) Since a parent and a childnode cannot transmit at the same time, if (vi, vj) ∈ E, then (vi, vj) ∈ EC . (ii) If (vi, vj) ∈ EI , then (vi, vj) ∈ EC , because viand vj interfere with each other. (iii) If (vi, vj) ∈ EI and cj is a child of j in G, then (vi, cj) ∈ EC , because vi and vj interfere, ifvi is transmitting, the children of j cannot transmit at the same time since vj would hear from both vi and cj. The resultinggraph GC will include all the potential conflicts for the original graph G, and the slot determination problem then becomesthe scheduling of nodes V in GC , such that no two adjacent nodes in GC have the same color (considering that one colormapsto one time slot). This is the NP-hard vertex coloring problem.However, existing distributed graph coloring algorithms [13,14,23,24] cannot be directly applied, for the following

reasons. Although the data collection graph (or tree) is generated initially, the interference set needs to be dynamicallydetermined in a decentralized manner given that we do not have location information of each node. This implies that thegraph to be colored is not fully established before coloring begins and many links related to schedule conflicts need to begradually discovered during coloring. In addition,wireless links are asymmetric, leading to directed graphs.Wehence designa new distributed graph coloring heuristic specifically appropriate for our application scenario.

5.1. Color palette and order of coloring

One of the fundamental questions is the number of colors used in the coloring. The length of each round is determinedby the number of colors used to color the vertices belonging to that round. The number of colors is determined by theamount of interference between the nodes in the round. Each node only transmits (as a child) during one of the roundsbut can potentially be receiving transmissions (as a parent) from its children in any other round; therefore, each node hasto actively participate in its own coloring as well as coloring for all of its children. There is no concern about interferencebetween transmissions that are scheduled in different rounds since different rounds are scheduled sequentially; therefore,each node can maintain a separate palette of available colors for each round that it participates in either as a sender or as areceiver.The colors are represented by integers corresponding to a time slot assignment within that round. The number of colors

in a palette is not predetermined, but new colors are only added when necessary. If all the transmissions were interferingwith each other, each node would need a separate slot to transmit and the number of colors across all the palettes would beequal to the number of nodes n. In order to minimize the number of colors, the nodes always try to get the lowest availableinteger from their palette. As colors become unavailable when nodes overhear other nodes in the same round using them,those colors get deleted and the lowest available remaining color becomes the next candidate. As a result of this color palettemechanism, the coloring with a minimal number of colors will be produced.A top-down coloring approach is more efficient in our application scenario with a tree-based collection structure. In

TIGRA, a parent node assigns different colors to each of its children; as a result, only conflicts between non-related pairs ofnodes (i.e., nodes with different parents) have to be resolved.

5.2. Details of the algorithm

In the Slot Determination phase, each node vi negotiates its color ci with its parent pi in its round ki. Node vi also assignsand negotiates color cj at round kj for each of its children vj in chi. As a result, each node will get a time slot within itsrespective round ki. The conflicts and additional interference not in the current interference set are detected by snoopingand by specifically inquiring from nodes in interference set Ii about their colors if snooping did not succeed.A node adds new colors to the palette only when needed as existing colors are deleted. This is ensured by constraining

a node to always use the next available color in negotiation. For any palette at each node, the color can be either availableor unavailable (deleted) at any given time. It is possible for a color to go from unavailable to available. If the color cannotbe confirmed because of the conflict at one of the nodes, the other node makes that color available in its palette again — toavoid the false blocking problem.The following greedy heuristic runs in a distributed manner at each node vi. A node has three high-level states (Fig. 4):

Listening, AsParent, AsChild. Based on the Round Determination phase, each node knows at which round it should negotiateas either a child or a parent, the length of the negotiation round, and the start time of the Slot Determination phase. A nodesets up a timer for the beginning of each round it will participate in. The timers are used for a node to know when it shouldstart negotiating the slot number either for itself or each of its child nodes. For instance, in Fig. 4, a node vi has its own roundnumber as ki, and its child vj’s round number as kj. vi will set up a timer for itself (with length as the product of its round


Fig. 4. Finite state machine of node vi .

Fig. 5. Finite state machine for node vi in state AsChild. Note: n.a.c. stands for ‘next available color’, and Ci refers to C cri .

number ki and the length of a negotiation round) and also a timer for each of its children. When any of the timers expires,the node negotiates the slot number either as a child or as a parent depending on the round number.

The AsChild state:When a node serves as a child (Fig. 5), it transitions among five different states. It waits for its parent toassign a color to it. Upon receiving a suggested color, it negotiates based on whether the color is available in its palette forthis round.

• AsChildWaitAssignment: A node (vi) starts with the AsChildWaitAssignment state and waits for its parent to assign acolor to it.(1) If the node receives a color assignmessage, and that color (x) is available in the node’s palette, the node transitionsto the AsChildAvailColorRcvd state; if color x is not available in the node’s palette, the node transitions to theAsChildUnavailColorRcvd state.

(2) If a node overhears that a color has been assigned, requested, or confirmed, the node deletes the color from its ownpallette.

• AsChildAvailColorRcvd: The node sends a confirmmessage to its parent, makes the color unavailable in its own palette,and transitions to the AsChildWaitConfirmation state.• AsChildUnavailColorRcvd: The node selects the lowest available color y from its palette, makes that color unavailable,sends a request message to its parent proposing a new color, and transitions to the AsChildWaitConfirmation state.• AsChildWaitConfirmation:(1) If the node receives a confirm message from its parent, it finalizes the color choice, broadcasts a finalconf message,and transitions to the AsChildConflictDetection state.

(2) If the node receives a finalconf message from its parent, it finalizes its color choice, and transitions to theAsChildConflictDetection state.


Fig. 6. Finite state machine for node vi in state AsParent. Note: n.a.c. stands for ‘next available color’, and Ci refers to C cri .

(3) If the node receives an assign message from its parent and the color is different from the original color, it adds theoriginal color back to its palette, and then transitions to the AsChildAvailColorRcvd or AsChildUnavailColorRcvd statedepending on whether the new color is available or not.

(4) If the node overhears that a new color is being assigned, requested, or confirmed, it removes the color from its palette.(5) If the node either receives a conflict for the current color, or overhears that the current color is being assigned,requested, or confirmed, it removes the color from its palette, picks the next available color from the pallette, andthen sends a request message to its parent and start the confirmation timer tc .

• AsChildConflictDetection: If there are any nodes in the node’s interference set for which the color is not knownfrom snooping, the node sends an explicit inquiry to those nodes about their color selections. In the rare case ofdetecting a conflict, the node that first detects the conflict selects the next available color from the palette, makesthat color unavailable, sends a request message to its parent proposing a new color, and transitions back to theAsChildWaitConfirmation state. At the end of the negotiation round, a node transitions to the Listening state.

The AsParent state:When a node serves as a parent (Fig. 6), it may negotiate with more than one child node at the sametime. The node first selects the lowest available color for each of its children in a given round,makes these colors unavailablein its palette, and broadcasts an assignmessage. Child nodes and surrounding nodes receive themessage. This allows for anyinterfering node that has a conflict to send a conflict message. The node then negotiates with each child individually basedon the availability of the colors in both parent’s and child’s palettes. The detailed process is as follows.

• If the node receives a confirm message from a child node, it finalizes the color selection, and broadcasts the finalconfmessage.• If the node receives a request message for a different color from a child node, and that color is available in its palette, itmakes the original color assigned to that child available and the new proposed color unavailable in its palette, and sendsa confirm message to that child. If that color is not available in its palette, it selects the next available color, makes theoriginal color assigned to that child available and the new proposed color unavailable in its palette, and broadcasts anassignmessage.• If the node overhears an assign, request or confirmmessage coming from an unrelated node, it checks to see if the colorin the message is available in its palette. If the color is available, the nodemakes it unavailable. If the color is unavailable,i.e., the color is being used by the node for one of its children, it sends a conflict message to the sender of the overheardmessage.• If the node overhears another color is being assigned, requested, or confirmed, then it removes that color from its ownpalette.

At the end of the negotiation round, the node transitions to the Listening state.During the negotiation either as a parent or a child, a color only gets finalized after two confirmation messages are

broadcast — one from the child and the other from the parent. This ensures that all the nodes in both neighborhoods havea chance to learn about the choice, and potentially interfering nodes in either neighborhood can send a conflict message tothe pair of negotiating nodes.


6. Analysis of the TIGRA algorithm

Theorem 1. TIGRA will always provide an collision-free transmission schedule.

Proof. No two nodes that transmit in different rounds can interfere with each other by definition, because different roundsare separated temporally. Therefore, we only need to be concerned with the nodes that transmit in the same round. Thereare three different cases:

a. Sibling nodes: For any set of nodes that send their reports to the same parent, conflicts are guaranteed to be eliminatedduring the Slot Determination phase because the parent assigns the colors to them and ensures that no two childrenwiththe same round number have the same color.

b. Parent–child pair: In the case when a parent and child have the same round number, the parent forces the child to use adifferent round during the Round Determination phase. Hence, no interference occurs between two such nodes.

c. Unrelated nodes:Multiple levels of prevention are used to prevent unrelated nodes that transmit in the same round frominterfering with each other. First, slot negotiation for nodes with the same round number happens in parallel. If a conflictexists, it is usually discovered by snooping; a conflict message is sent, and interference is prevented by selecting a newcolor for one of the nodes. Second, it is possible that channel sensing fails, and such nodes transmit their negotiationmessages at exactly the same time and choose the same color. To prevent conflicts caused by such situations, actions aretaken at each phase of TIGRA.(i) During the Round Determination phase, each node vi uses snooping to construct an interference set Ii and, if possible,snoops the round number for each node in Ii. If the round number for a node in Ii is different fromnode vi’s own roundnumber ki, such a node is removed from Ii.

(ii) During the Slot Determination phase, node vi makes sure that no node vj in Ii is assigned the same color as vi. If thecolor for a node vj cannot be determined implicitly by snooping, node vi sends an explicit message to vj inquiringabout vj’s color. If a conflict is discovered, one of the conflicting nodes is assigned a new color.

We show that, in all possible cases, time slot conflicts between nodes are prevented by TIGRA. Therefore, TIGRA providesan collision-free transmission schedule.

Theorem 2. TIGRA will eventually terminate.

Proof. To prove that the algorithm terminates, wemustmake sure that there is no deadlock or livelock (infinite loop) at anyphase of the algorithm. In the Round Determination phase, nodes transmit an init message only once. Furthermore, a nodewaits for a constant time to receive feedback from potential children before concluding that it is a leaf node. With theseconstraints, no deadlock nor infinite loop is possible. Therefore, the Round Determination phase terminates as long as thenumber of nodes in the network is finite.During the Slot Determination phase, some node pairs may go through asmany iterations as the size of their interference

set before ending negotiation; however, such negotiation definitely terminates because the nodes eventually use all thecolors in their palettes and then add a new color. As can be seen from the Finite State Machine (FSM) diagrams (Figs. 5and 6), a pair of nodes never goes back to the color that was already chosen and made unavailable in one of their palettes.Therefore, no deadlock nor livelock can occur.During theData Collection phase, each node transmits itsmessage in its assigned time slot; no deadlock is possible during

that phase.There is no possibility for a deadlock or livelock at any phase of the algorithm; thus, the algorithm does terminate.

6.1. Complexity analysis of the Round Determination phase

In the Round Determination phase, the first initialization packet propagates from the sink until it reaches all nodes inthe network. Each node broadcasts the packet once and reports to its parent once. Once the leaf nodes are reached, theresponse packets propagate back towards the sink. Again, each node only transmits once. Therefore, during the RoundDetermination phase, the number of messages exchanged is O(n) and the time complexity is O(n), if we assume that theone-hop transmission delay is a constant.

6.2. Complexity analysis of the Slot Determination phase

During the Slot Determination phase, every child–parent node pair exchanges at least threemessages: the parent assignsa color to each child, each child sends a confirmmessage, and the parent broadcasts a finalconf message. If the initial colorassignment does not work for the child, it proposes a new color. If the new color does not work for the parent, it proposesanother color. In the worst case, there is not a color that is available in both the child’s and the parent’s current palettes,and a new color must be added. In other words, if we use l to denote the maximum palette size in a given round, the timecomplexity for a child–parent pair to select a color is O(l) in the worst case.In TIGRA, nodes that transmit at the same round perform the coloring simultaneously, unless they interfere with each

other. Themaximum number of colors required by nodes in a given round is O(l). Therefore, the worst case time complexity


a b

c d

Fig. 7. The worst case scenario for a negotiation round during the Slot Determination phase.

for TIGRA to complete the coloring in a given round is O(l2), and is on the order of O(m · l2) for m rounds. m is limited bythe packet size and is a small constant; therefore, the run time of the entire algorithm is on the order of O(l2). For a networkwith n nodes, the maximum number of colors used in a palette satisfies∆max ≤ l ≤ n, where∆max is the maximum vertexdegree. Therefore, in the worst possible scenario, the time complexity for the Slot Determination phase is O(n2).As a specific example, let us consider the topology represented in Fig. 7. Although it is a very unlikely case, let us assume

that all the parent nodes (1, 2, 3, and 4) can hear all the child nodes (5, 6, 7, and 8); the child nodes, however, hear only theirrespective parents and neither parent nodes can hear other parent nodes, nor can child nodes hear other child nodes. (A):Nodes 1, 2, 3 and 4 assign the first available color, i.e., 1, to their respective child nodes. (B): Node 5 confirms the assignmentfirst, other parent nodes overhear the confirm message, and send the next available color, i.e., 2, to their respective childnodes. Let us assume that node 6 confirms the second assignment first, and both remaining parent nodes 3 and 4 overhearthe confirmmessage. (C): Nodes 3 and 4 select the next available color, i.e., 3, and send it to their child nodes; node 7 confirmsit first. (D): Nodes 4 and 8 must negotiate one more time before they can stop at color 4. In this scenario, g(g + 1)/2 setsof negotiation messages are exchanged before convergence, where g is the number of negotiating node pairs, and the set ofnegotiation messages contains a set of request, confirm and finalconf messages or any subset thereof pertaining to a specificcolor.In practice, each node, whether a parent or child, eavesdrops and updates its own palette if its neighbor confirms a

color. This prevents a pair of nodes from traversing the palette before finding a color that works for both of them. This alsomakes negotiation for each pair closer to a constant time (as opposed to O(l)). Even though eavesdropping cannot guaranteeconstant time for each negotiation, since a child may not hear all of its parent’s neighbors and vice versa, it reduces thenumber of messages necessary for each pair and brings the algorithm run time closer to O(l), where∆max ≤ l ≤ n.

6.3. Latency bound of the Data Collection phase

The degree to which a particular network benefits from TIGRA largely depends on the depth of the routing tree,the maximum node degree of the network, and the node density. For a given network, data collection delay can bedeterministically bounded as Delay ≤ m · e · l · tpacket , where m is the number of rounds, e is the number of epochs, l isthe maximum number of time slots used in a round, and tpacket is the time it takes to transmit a standard packet.

7. Performance evaluation

The objective of the performance study is to validate our proposed algorithm TIGRA, and evaluate and compareits performance against existing algorithms under different network settings using simulation. To further study theeffectiveness of TIGRA, we also evaluate it on a sensor network testbed.

7.1. Simulation settings

Our empirical studies thoroughly compare the performance of TIGRA against two existing protocols. As a baselinecomparison, we compare TIGRA to a basic data collection protocol, referred to as BASIC, which first builds a routing tree andthen collects data from each node. No mechanisms above the MAC layer are developed to support timeliness. However, upto five retransmissions are allowed for messages that do not successfully reach the next hop. In addition, we compare TIGRAto SPEED [6].We chose SPEED for comparison because SPEED is a real-time protocol designed tominimize the deadlinemissratio in sensor networks and it is compatible with most existing best-effort MAC protocols, which is consistent with TIGRA.


9 16 25 36

TIGRA BASIC SPEED

49Network size (nodes)

Scheduling Latency vs. Network Size(grid topology, avg neighborhood size: 8, reading size: 3B)

Late

ncy

(sec

onds

)64 81 100

0

0.5

1

1.5

2

2.5

Fig. 8. Impact of the network size on the scheduling latency (grid topology).

All three protocols (BASIC, SPEED, and TIGRA) are implemented in TOSSIM 2.0 [25]. The default TOSSIM MAC protocol isCSMA. We use the default values for TOSSIM’s radio model that are based on the CC2420 radio. In TOSSIM, all time valuesare specified in terms of radio symbols. The MAC object is configured to act like the standard TinyOS 2.0 CC2420 stack: ithas 4 bits per symbol and 64 k symbols per second, for 256 kbps. The radio must detect a clear channel twice before it willtransmit. The radio will back off infinitely before signaling failure. For other values of CSMA, interested readers may referto [26]. We also integrated FTSP [27], 1 one of the most precise time synchronization protocols where the average per-hopsynchronization error was in the one microsecond range.TIGRA is an energy-aware timely protocol for sensor data collection. The objective of TIGRA is to provide a transmission

schedule that guarantees a deterministic data collection latency for a given sensor network in an energy-efficient manner.Therefore, we separately measure the energy consumption and latency incurred in (1) the Round Determination and SlotDetermination phases and (2) the Data Collection phase.

7.2. Simulation results

The performance of all three protocols (BASIC, SPEED, and TIGRA) is tested under both grid and random networkdeployment; we also varied the network size and node density. We observe that the performance trend and comparisonunder random network topology is very similar to that under grid topology, so the following discussion is focused ongrid topology. tpacket is set to be 7 ms based on the empirical results, and a new reading is generated by each node every10 s. A simulation run consists of initialization and data collection periods. For TIGRA, initialization consists of the RoundDetermination and Slot Determination phases. For BASIC, initialization consists of building a collection tree by flooding thenetworkwith an initialization packet from the sink. This packet also includes the time to start the data collection. SPEEDdoesnot use a static collection tree; therefore, the initialization packet is used only to broadcast the start of the data collectionperiod.Wemeasure the latency and energy consumption separately for the initialization (i.e., scheduling) anddata collectionperiods. Each data point is based on 20 experiments. We use a 95% confidence interval for the error bars.

7.2.1. Impact of the network sizeThe latency for both scheduling (Fig. 8) and collection stages (Fig. 9) in TIGRA increases as the network size increases

because the depth of the routing tree increases and so does the number of epochs needed to deliver all the sensor readingsto the sink. For both SPEED and BASIC, the scheduling latency increases with the size of the network also due to a deeperrouting tree. The collection latency, however, increases up to a certain point and then flattens out or decreases becausemanydata packets get dropped due to collisions. Since the collection latency is measured while data packets are received at thesink, packets from nodes farther away from the sink, which are more likely to get dropped, often do not contribute to thecollection latency.Fig. 10 illustrates a higher scheduling overhead imposed by TIGRAwhen compared to BASIC and SPEED. Fig. 11 shows that

TIGRA consumes less energy than SPEED or BASIC while still providing a significantly higher packet delivery ratio (Fig. 12).This is due to the batch transmission method and explicitly avoiding collisions. Although these energy savings come at thecost of higher scheduling overhead, after scheduling the transmissions in the Round Determination and Slot Determinationphases once, TIGRA can use the resulting schedule for as many periods as needed or until the application requirements orthe network topology change. This provides significant energy savings overall.While the latency comparison in Fig. 9 appears pessimistic for TIGRA, Fig. 12 reveals the real reasons behind this.

Although we do not consider link or node failures, both SPEED and BASIC rely on a CSMA-based MAC layer protocol to

1 FTSP has been included in the TinyOS 2.x CVS repository and the codemay be downloaded fromhttp://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/ftsp/.

http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/ftsp/

http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/ftsp/


9 16 25 36 49 64 81 100

TIGRA BASIC SPEED

Network size (nodes)La

tenc

y (s

econ

ds)

0

0.5

1

1.5

2

2.5

Collection Latency vs. Network Size(grid topology, avg neighborhood size: 8, reading size: 3B)

Fig. 9. Impact of the network size on the data collection latency (grid topology).

90

5001000150020002500300035004000

16 25 36 49 64 81 100

TIGRA BASIC SPEED

Network size (nodes)

ener

gy c

onsu

mpt

ion

(uJ)

Scheduling Energy Consumption vs. Network Size(grid topology, avg neighborhood size: 8, reading size: 3B)

Fig. 10. Impact of the network size on the scheduling overhead (grid topology).

0200400600800

100012001400160018002000

ener

gy c

onsu

mpt

ion

(uJ)

9 16 25 36 49 64 81 100Network size (nodes)

TIGRA BASIC SPEED

Collection Energy Consumption vs. Network Size(grid topology, avg neighborhood size: 8, reading size: 3B)

Fig. 11. Impact of the network size on the data collection overhead (grid topology).

avoid interference, and it does not scale well; hence, they lose many packets due to interference, and the packet deliveryratio decreases drastically as the network size increases. In contrast, TIGRA negotiates a precise schedule for each node’stransmission and explicitly avoids interference. This feature is demonstrated in Fig. 13 that shows the cumulative sensorreading delivery ratio as collection time progresses for a constant network size and density. Given enough time, TIGRAachieves a 100% packet delivery ratio, whereas BASIC and SPEED deliver a certain number of sensor readings early in thedata collection period, after which they do not deliver any more readings to the sink due to interference. Further, TIGRA’spacket delivery ratio is always higher than that of BASIC and SPEED at any given time of the data collection period becauseof the collision-free schedule, as well as the batch transmission processing (up tom sensor readings are delivered to the sinkin a single packet).

7.2.2. Impact of the network densityFigs. 14 and 15 showhownetwork density affects the scheduling and collection latency. As the network density increases,

so does the amount of interference. A lower network density causes TIGRA to use a deeper routing tree and more epochs


90

Pac

ket d

eliv

ery

ratio

0.2

0.4

0.6

0.8

1

1.2

16 25 36 49 64 81 100

TIGRA BASIC SPEED

Packet Delivery Ratio vs. Network Size(grid topology, avg neighborhood size: 8, reading size: 3B)

Network size (nodes)

Fig. 12. Impact of the network size on the packet delivery ratio (grid topology).

0 0.1 0.2 0.3 0.4Time (Seconds)

Pac

ket d

eliv

ery

ratio

0.5 0.6 0.7 0.80

0.2

0.4

0.6

0.8

1

1.2

TIGRA BASIC SPEED

Packet Delivery Ratio vs.Time(grid topology, 49 nodes avg neighborhood size: 8, reading size: 3B)

Fig. 13. Cumulative packet delivery ratio vs. time (grid topology).

4 8 12 20 24 28 36 44 48Network density (avg neighborhood)

0

Late

ncy

(sec

onds

)

0.5

1

1.5

2

2.5

TIGRA BASIC SPEED

Scheduling Latency vs. Network Density(grid topology, 64 nodes, reading size: 3B)

Fig. 14. Impact of the network density on the scheduling latency (grid topology).

compared to a higher network density, which leads to more slots being allocated within each round. As a result, TIGRA’sscheduling and collection delay stay relatively constant as network density changes. However, we do observe that thecollection latency decreases slightly and then increases. This is because of the policy we implemented to balance the routingtree, i.e., limiting the maximum number of children a node can have (Section 4). As the network gets dense, the routing treegets wider, but its height gets smaller, thereby decreasing the data collection latency. However, when the tree width (or thenumber of a node’s children) gets beyond m used in our policy, we force the tree to expand in height not in width, leadingto the increase of data collection latency.The higher collection latency of TIGRA when compared to BASIC and SPEED can be explained by the results in Fig. 16.

The packet delivery ratio for BASIC and SPEED increases as the density increases, because higher density corresponds toa shorter routing tree and packets have fewer chances of getting dropped. However, with a higher density comes higherinterference, leading to more collisions; this explains why the packet delivery ratio for SPEED and BASIC is low even for


40

Late

ncy

(sec

onds

)

0.5

1

1.5

2

2.5

8 12 20 24 28 36 44 48Network density (avg neighborhood size)

TIGRA BASIC SPEED

Collection Latency vs. Network Density(grid topology, 64 nodes, reading size: 3B)

Fig. 15. Impact of the network density on the collection latency (grid topology).

4 8 12 20 24 28 36 44 48

Network density (avg neighborhood size)

TIGRA

Pac

ket d

eliv

ery

ratio

Packet Delivery Ratio vs. Network Density(grid topology, 64 nodes, reading size: 3B)

BASIC SPEED

0

0.2

0.4

0.6

0.8

1

1.2

Fig. 16. Impact of the network density on the packet delivery ratio (grid topology).

4 8 12 20 24 28 36 44 48Network density (avg neighborhood size)

TIGRA BASIC SPEED

0500

ener

gy c

onsu

mpt

ion

(uJ)

100015002000250030003500

Scheduling Energy Consumption vs. Network Density(grid topology, 64 nodes, reading size: 3B)

Fig. 17. Impact of the network density on the scheduling overhead (grid topology).

higher densities. TIGRA, on the other hand, reserves a specific slot for each node, explicitly avoiding interference. Hence,TIGRA’s packet delivery ratio is unaffected by the network density.Fig. 17 demonstrates that TIGRA overhead during the scheduling stage increases as the network density increases. This

is due to a higher interference causing parent–child pairs to go through more negotiation iterations before confirming amutually available color. Fig. 18 shows that TIGRA imposes less collection overhead than SPEED or BASIC, at the price ofoccasional scheduling. The overhead of the collection stage decreases as the network density increases because of the shorterrouting tree.


4 8 12 20 24 28 36 44 48Network density (avg neighborhood size)

TIGRA BASIC SPEED

0200400600800

1000120014001600

ener

gy c

onsu

mpt

ion

(uJ)

Collection Energy Consumption vs. Network Density(grid topology, 64 nodes, reading size: 3B)

Fig. 18. Impact of the network density on the collection overhead (grid topology).

0

Pac

ket d

eliv

ery

ratio

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.5 1 1.5 2 2.5Time (seconds)

(testbed results, 43 nodes)

3 3.5 4 4.5 5

Fig. 19. Performance of TIGRA in a sensor network testbed.

Performance summary: Irrespective of network size or density, TIGRA always guarantees 100% packet delivery from allnodes to the sink with deterministic latency. Given the same time constraint from an application, TIGRA is able to deliversignificantly more packets than SPEED or BASIC.

7.3. Testbed evaluation of TIGRA

We implemented TIGRA on an indoor testbed of 43 Tmote Sky nodes [28] using TinyOS 2.0. Those nodes are placed in arough grid topology. The nodes are approximately 3–4 meters apart from each other. The following modifications are madeto TIGRA in order to improve its testbed performance. First, the short transmission slots used in simulation are unsuitable forthe real-world environment. In our simulation experiments a single-hop transmission never exceeds 7 ms, but it takes onthe order of 15 to 20ms in the testbed environment.We, therefore, set tpacket to be 20ms. Second, we add one retransmissionfor each packetwhen no ACK is received. Increasing the number of retransmissions beyond amaximumof two does not yielda noticeably better packet delivery ratio.Fig. 19 shows the cumulative packet delivery ratio as the data collection time progresses. Each point is based on ten

experiments. The packet delivery ratio of TIGRA (65.5%) is significantly less than in our simulation experiments (always100%). We believe this is caused by varying link quality due to some external condition in the laboratory. In our testbed, themotes are arranged in a noisy grid with four columns hanging from the ceiling of a laboratory. The columns are not straightlines and themotes are deployed around obstacles such as light fixtures, pipes, and pillars.We also notice that to deliver thismuch data takes about 4.5 s. In contrast, our simulation experiments for a network of 49 nodes show delay of less than 1 sfor a grid topology and less than 1.5 s for a random topology. This suggests that even though TIGRA provides a deterministicdelay in theory, in practice, reliability features must be added to the protocol before similar performance can be achieved.

8. Conclusions

TIGRA can eliminate packet collisions and avoid network congestion, two major factors for latency. Other causes oflatency include node failures due to battery depletion or environmental influence and link failures due to external objects


and conditions. Recovery from these faults typically involves retransmission, and thereby packet delivery latency. Aninteresting direction for future extension of TIGRA is adding fault tolerance to data collection while trying to decrease theend-to-end latency. Providing reliability and timeliness simultaneously in an energy-aware manner presents an interestingchallenge. Timeliness and reliability are two competing goals; ensuring reliable data delivery in an unreliable networkinvariably requires additional retransmissions, whether as part of themesh routing or hop-by-hop recovery. Multiple copiesof the same packet increase the chances of the packet reaching the sink, at the cost of higher energy expenditure and longerdelay.In order to guarantee delay bounds and be consistent with TIGRA’s timing hierarchy (period, epoch, round, slot),

the chosen fault-tolerant approach must require a predictable amount of time each period. This means a deterministicguaranteed approach of caching and retransmitting dropped packets when needed is not effective, since the potentialnumber of retransmissions is unbounded. Combiningmulti-path techniques or a predetermined number of retransmissionsfor the same packet with TIGRA’s timely data collection solution has a potential for creating an effective algorithm with aprobabilistic reliability guarantee and deterministic delay bound.

Acknowledgement

We would like to thank Kyle Fullerton and Josh Auger for getting FTSP working in our evaluation.

References

[1] D. Chu, A. Deshpande, J. Hellerstein, W. Hong, Approximate data collection in sensor networks using probabilistic models, in: Proceedings of the IEEEInternational Conference on Data Engineering, ICDE, 2006.

[2] L. Porta, T.H. Illangasekare, P. Loden, Q. Han, A.P. Jayasumana, Continuous plume monitoring using wireless sensors: Proof of concept in intermediatescale tank, ASCE’s Journal of Environmental Engineering (in press).

[3] R. Ramaswami, K. Parhi, Distributed scheduling of broadcasts in a radio network, in: Proceedings of the IEEE Infocom, 1999.[4] T.F. Abdelzaher, S. Prabh, R. Kira, On real-time capacity limits of multihop wireless sensor networks, in: Proceedings of IEEE Real-Time SystemsSymposium, RTSS, 2004.

[5] S. Prabh, T.F. Abdelzaher, On scheduling and real-time capacity of hexagonal wireless sensor networks, in: Proceedings of Euromicro Conference onReal-Time Systems, ECRTS, 2007.

[6] T. He, J.A. Stankovic, C. Lu, T.F. Abdelzaher, Speed: A stateless protocol for real-time communication in sensor networks, in: Proceedings of IEEEInternational Conference on Distributed Computing Systems, ICDCS 2003, 2002.

[7] C. Lu, B.M. Blum, T.F. Abdelzaher, J.A. Stankovic, T. He, Rap: A real-time communication architecture for large-scale wireless sensor networks, in:Proceedings of IEEE Real-Time and Embedded Technology and Applications Symposium, RTAS, 2002.

[8] H. Li, P. Shenoy, K. Ramamritham, Scheduling communication in real-time sensor applications, in: Proceedings of IEEE Real-Time and EmbeddedTechnology and Applications Symposium, RTAS, 2004.

[9] H. Li, P. Shenoy, K. Ramamritham, Scheduling messages with deadlines in multi-hop real-time sensor networks, in: Proceedings of IEEE Real-Timeand Embedded Technology and Applications Symposium, RTAS, 2005.

[10] T. van Dam, K. Langendoen, An adaptive energy-efficient MAC protocol for wireless sensor networks, in: Proceedings of the ACM InternationalConference on Embedded Networked Sensor Systems, SenSys, 2003.

[11] W. Ye, J. Heidemann, D. Estrin, An energy-efficient mac protocol for wireless sensor networks, in: Proceedings of IEEE Conference on ComputerCommunications, INFOCOM, 2002.

[12] S. Ergen, P. Varaiya, PEDAMACS: Power efficient and delay awaremediumaccess protocol for sensor networks, IEEE Transactions onMobile Computing5 (7) (2006) 920–930.

[13] I. Rhee, A. Warrier, J. Min, L. Xu, DRAND: Distributed randomized TDMA scheduling for wireless ad-hoc networks, in: Proceedings of The 8th ACMInternational Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc, 2006.

[14] S. Gandham, M. Dawande, R. Prakash, Link scheduling in sensor networks: Distributed edge coloring revisited, in: Proceedings of the IEEE Conferenceon Computer Communications, Infocom, 2005.

[15] Y. Yu, B. Krishnamachari, V. Prasanna, Energy–latency tradeoffs for data gathering in wireless sensor networks, in: Proceedings of the IEEE Conferenceon Computer Communications, Infocom, 2004.

[16] A. Keshavarzian, H. Lee, L. Venkatraman, Wakeup scheduling in wireless sensor networks, in: Proceedings of The 8th ACM International Symposiumon Mobile Ad Hoc Networking and Computing, MobiHoc, 2006.

[17] B. Hohlt, L. Doherty, E. Brewer, Flexible power scheduling for sensor networks, in: Proceedings of the IEEE International Conference on InformationProcessing in Sensor Networks, IPSN, 2004.

[18] C. Florens, M. Franceschetti, R. McEliece, Lower bounds on data collection time in sensory networks, IEEE Journal on Selected Areas in Communication(JSAC) 22 (6) (2004) 1110–1120.

[19] C. Florens, R. McEliece, Packet distribution algorithms for sensor networks, in: Proceedings of the IEEE Conference on Computer Communications,Infocom, 2003.

[20] S. Gandham, Y. Zhang, Q. Huang, Distributed minimal time convergecast scheduling in wireless sensor networks, in: Proceedings of the 26thInternational IEEE Conference on Distributed Computing Systems, ICDCS, 2006.

[21] J. Zhao, R. Govindan, Understanding packet delivery performance in dense wireless sensor networks, in: Proceedings of the ACM Conference onEmbedded Networked Sensor Systems, SenSys, 2003.

[22] F. Sivrikaya, B. Yener, Time synchronization in sensor networks: A survey, IEEE Network 18 (4) (2004) 45–50.[23] I. Finocchi, A. Panconesi, R. Silvestri, Experimental analysis of simple, distributed vertex coloring algorithms, in: SODA’02: Proceedings of the

Thirteenth Annual ACM-SIAM Symposium on Discrete algorithms, 2002, pp. 606–615.[24] G.D. Marco, A. Pelc, Fast distributed graph coloring with o(delta) colors, in: Proceedings of ACM-SIAM Symposium on Discrete Algorithms, 2001.[25] P. Levis, N. Lee, M. Welsh, D. Culler, Tossim: Accurate and scalable simulation of entire TinyOS applications, in: ACM International Conference on

Embedded Networked Sensor Systems, SenSys, 2003.[26] T. Tutorial, TOSSIM. http://docs.tinyos.net/index.php/TOSSIM (access date: February 2009).[27] M.Maróti, B. Kusy, G. Simon, A. Lédeczi, The flooding time synchronization protocol, in: Proceedings of the 2nd International Conference on Embedded

Networked Sensor Systems, SenSys, 2004, pp. 39–49.[28] Moteiv, Tmote sky. http://mistlab.csail.mit.edu/ (last accessed on February 2007).

http://docs.tinyos.net/index.php/TOSSIM

http://mistlab.csail.mit.edu/

A data collection protocol for real-time sensor - Inside Mines

Documents

Transcript of A data collection protocol for real-time sensor - Inside Mines