Pervasive and Mobile Computing

Transcription

1 Pervasive and Mobile Computing 5 (29) Contents lists available at ScienceDirect Pervasive and Mobile Computing journal homepage: A data collection protocol for real-time sensor applications Lilia Paradis a, Qi Han b, a Microsoft Corporation, Redmond, WA 9852, United States b 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 a b s t r a c t Article history: Received 29 August 28 Received in revised form 15 February 29 Accepted 14 April 29 Available online 3 May 29 Keywords: Energy efficiency Real time Sensor data collection The nature of many sensor applications as well as continuously changing sensor data often imposes real-time requirements on wireless sensor network protocols. Due to numerous design 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 be applied directly to wireless sensor networks. Our objective is to design a protocol for sensor applications that require periodic collection of raw data reports from the entire network in a timely manner. We formulate the problem as a graph coloring problem. We then present TIGRA (Timely Sensor Data Collection using Distributed Graph Coloring) a distributed heuristic for graph coloring that takes into account application semantics and special characteristics of sensor networks. TIGRA ensures that no interference occurs and 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 a specific topology, platform, and application, TIGRA provides a transmission schedule that guarantees 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 normally idle and only activated in response to a critical change in the observed phenomena. Once an event is detected, frequent and periodic updates from the sensors to the sink are needed for better understanding of event evolution to ensure prompt response. Sensor data here is very time-sensitive and a real-time communication protocol needs to be in place to ensure timely data delivery. In addition, many applications often require raw data from the sensor network [1] since aggregated data loses the level of detail that is often essential to exploratory research. Note that the need of raw data does not prevent the system from combining sensor readings from different nodes. For instance, one of our ongoing research projects is to monitor subsurface contaminants using wireless sensor networks. We are developing a closed loop system integrating a wireless sensor network and numerical contaminant transport models [2]. The numerical models are computationally intensive and have 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 when its observation such as the sensed electrical conductivity level exceeds a certain threshold. However, once a contaminant plume is detected by certain nodes, the network is activated to report periodically so that the numerical model can be continuously re-calibrated using a continuous stream of sensor data in order to capture transient contaminant plumes to This work is supported in part by NSF CSR grant CNS Corresponding author. Tel.: ; fax: addresses: lparadis@gmail.com (L. Paradis), qhan@mines.edu (Q. Han) /$ see front matter. Published by Elsevier B.V. doi:1.116/j.pmcj

2 37 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) assess the source, track plumes in real time and predict future plume behavior. The need for raw data in real time is also true 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 presents several challenges. First, multihop communication coupled with the potential of combining several sensor reports into one data packet creates unique precedence constraints. Second, both primary and secondary conflicts in wireless networks must be avoided [3]. A primary conflict occurs when a node transmits and receives at the same time slot or receives more than one transmission destined to it at the same time slot. A secondary conflict occurs when a node, an intended receiver of a 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 the packet 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), that determines a transmission schedule for all the nodes in the network. The schedule provides deterministic end-to-end latency in sensor data collection. This is achieved by using packet combination and exploiting spatial reuse of the wireless channel to schedule non-interfering transmissions in parallel, progressively and locally building the interference set for each node, explicitly eliminating collisions, and implicitly avoiding network congestion. Moreover, TIGRA is independent of 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 and further evaluate TIGRA s performance in a sensor network testbed. 2. Related work Existing techniques for supporting real-time communication in WSNs 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 data that can be transmitted in a given sensor network are established [4]. Further studies on scheduling and real-time capacity have been conducted on hexagonal WSNs [5]. Our work complements theirs by proposing a specific algorithm to improve timeliness 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 location of 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 is determined centrally based on the location and transmission range of each node, which is an unrealistic assumption in our application scenario. Further, no packet combination is used; hence precedence dependencies between the transmissions are 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 randomly if collisions are detected, leading to unpredictable delay. Schedule-based MAC protocols for WSNs such as T-MAC [1], S- MAC [11], PEDAMACS [12], DRAND[13], or TDMA-based link scheduling [14] can be used to eliminate collisions and obtain a bound on data collection latency. However, they aim to minimize the time required for each node to communicate once with all its neighbors. They typically assign the same number of time slots to all the nodes. As a result, these protocols tend to waste time slots when a node does not have any new data in a given slot. Instead, we are interested in determining a schedule such that the entire collection can be completed in a minimal number of time slots. Directly applying their approaches may incur 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 the aggregated 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 schedule that 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 sensor networks. To this end, a coarse-grained scheduling at the routing layer combined with a fine-grained scheduling at the MAC layer is used. While the tradeoff between latency and energy is studied, minimizing the data collection latency is not the primary 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 2]. However, packet combination, which increases the scheduling complexity, is not considered in either of the papers. In addition, the algorithms presented in [18,19] are centralized and the approaches taken in [2] assume symmetric wireless links, which is not realistic, as found in previous studies [21].

3 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Problem formulation We consider wireless sensor networks with a single sink and multiple homogeneous data sources for applications that require raw data periodically. In this scenario, each sensor node periodically produces a new value and this value may need to traverse multiple hops to reach the sink. The reading from a node can be combined with the readings from other nodes on its way to the sink. Given a set of sensor values that are generated periodically, our objective is to schedule all the transmissions for each period to be completed in the shortest possible amount of time. Ideally, all the non-interfering transmissions can be scheduled at the same time slot to minimize the overall delay. Note that latency here is defined as the time between when the first packet is sent out and the time when the last packet is received by the sink. This latency is different from the average 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 or relayed 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 monitoring applications (typically on the order of hours or days) that we are targeting, as those described in Section 1. A pre-determined transmission schedule not only implicitly avoids network congestion that is often caused by bursty data traffic, but also eliminates packet collisions. Both network congestion and packet collisions lead to packet drop and retransmission, and thereby 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 3 5 µs per second. Clock synchronization is not the focus of this work: one of the existing solutions [22] may be used Batch transmission In many WSN applications, a sensor reading can often be represented with a small number of bytes, so more than one reading can fit into a standard transmission packet. We exploit this property to reduce the number of packets transmitted. Instead of individually sending each sensor reading, the readings are batched or combined at intermediate nodes and forwarded upstream along the tree. We refer to this as batch processing. This processing differs from aggregated processing, where one single value is computed over several sensor readings based on application semantics. In batch processing, each raw sensor report is still maintained in the packets. The maximum number of readings that can be combined depends 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 exploit batch processing. However, batch transmission processing creates additional precedence constraints when determining a transmission schedule. If m is used to indicate the maximum number of readings that one packet can have, in order to maximize energy savings from using batch transmission, the number of saturated packets that have m readings has to be maximized. To achieve that, unless a node is a leaf or the number of its descendant nodes is a multiple of m, it should transmit only after receiving a packet from one of its children and combining its own reading with the existing payload Problem statement The problem can be stated formally as follows. Given a network represented by a graph G = (V, E), where V is the set of 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. All traffic 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 in multiple hops. A packet can consist of readings from m nodes. The problem, therefore, is to determine the smallest length conflict-free assignment of time slots during which the reading generated at each node may be combined with readings from other nodes and transmitted to the sink over the collection tree. In other words, we need to schedule the transmission links in E by taking into account all the possible interferences between the edges. Note that while the data collection follows a routing tree, the network itself is actually a graph since it consists of not only transmission links, but also links that may interfere. 4. TIGRA: A transmission scheduling algorithm Before presenting the details of TIGRA, we first explain various terms used in the transmission schedule (Fig. 1). The timing hierarchy also indicates that the scheduling is conducted at different levels. We will use Fig. 2 to show an example of timing hierarchy for a sample network and then use Fig. 3 to explain how the timing hierarchy is determined for a network. Round: Node v i calculates its round k i based on the number of its descendants d i : k i = d i mod m. Each round is scheduled sequentially; therefore, interference and spatial channel reuse are only possible within the same round.

4 372 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) 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 m rounds as an epoch. In other words, each epoch consists of m rounds. The farther the nodes are from the sink, the fewer epochs they actively participate in. Period: A period is specified by an application to indicate the desired frequency of data collection. The application requested period is expected to be longer than the length of the combined epochs necessary to transmit all the packets to 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 number of slots required can vary from one round to another; therefore, forcing each round to last equal time would introduce unnecessary delay. The length of each round is determined by the number of slots that are necessary to avoid conflicts in 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 three descendants, and since m = 4, it waits for the packet from node 3 before reporting its own reading; node 5, however, has four descendants which are multiples of m; it can conclude that its descendants will form a batch and it can transmit its own reading creating a new batch for the upstream nodes. If there is no interference between nodes 1 and 5, they can transmit their readings to their respective parents simultaneously, i.e., in the same round and same slot. Otherwise, node 1 and node 5 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 has three main objectives: (1) performing network discovery and constructing the routing tree; (2) determining the number of descendants and deriving the round number for each node and its children; and (3) constructing the interference set. During the Slot Determination phase, specific time slots within a round are determined for each transmission. The exact time when each round starts is communicated to the nodes at the end of the Slot Determination phase. During the Data Collection phase, nodes send their reports to the sink periodically, according to the period requested by the application. At the start of the 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 message pass; (2) response messages are sent back from the leaves to the sink, and round numbers are derived as the result of this message pass; (3) a message is then sent downstream from the sink to the leaves, round conflicts are resolved between child and parent nodes, and the start time for the Slot Determination phase is communicated to the nodes.

5 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Table 1 Notations used in TIGRA. Notation s v i n p i ch i [] nc i c i C r[] i d i k i I i [] m t c cr Meaning Sink Node with ID i Total number of nodes in the network Parent node of node v i A set of child nodes of node v i Number of child nodes for node v i Color of node v i, initially Color palette of node v i for round r Number of descendants for node v i Round at which node v i negotiates with parent p i Interference set of node v i Number of rounds Waiting period for confirmation from child or parent Current round In this phase, a routing tree is built via broadcasts initiated by the sink. Each sensor maintains the ID of its parent, which is the node from which 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 initack message to the sender, letting the sender know that the node intends to become the sender s child. Once an acknowledgement is received from the potential parent, the node finalizes its parent choice, and broadcasts an init message further down. Each node v i determines the number of its descendants d i and its round k i, the set of its children ch i, its interference set I i consisting of nodes not directly related to it but within one-hop communication range, the number of descendants d j, and the round k j for each child v j ch i. If a parent v i and its child v j ch i [] have the same round number (i.e., if k i = k j ), there is a round conflict. In this case, a parent assigns a new round number to such child nodes. The new round number is defined as k j = (k i + 1) mod m. Further, a node needs the information about the number of descendants for itself and its children to decide at which epoch it has to participate and at which it does not. The interference set discovered in this phase is not complete and will be further extended in the next phase. 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 too many slots during particular rounds being used by that node and its children, but not being used in the rest of the network, which would reduce the amount of parallelism in the network. Therefore, the number of children a node can have should be limited. The policy used in TIGRA is that a node should have no more children than m, the maximum number 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 investigated in 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 nodes with even hop count using one round and those with odd hop count using the other round, which can potentially require a 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 (, 1,, 1,...) to its immediate children. The round assignment then propagates from immediate children to the leaf nodes. In the case with m = 1, there is only one round. However, a node cannot have the same round when it serves as a parent or as a child. Hence, TIGRA uses two rounds in a similar way as for the case where m = 2. Slot Determination phase: This phase schedules the transmissions within the same round, such that interference is eliminated and channel reuse is maximized. At the end of this phase, the nodes report the results of negotiation to the sink. Starting from the leaves, each node sends a packet with the maximum number of slots used for each round. If a node does not participate in a current round, the number of slots for such a round is. Upon determining the maximum number of slots for each round, the sink floods the network with one more message that contains start times for each round relative to the start of each epoch. The start of each slot can be determined at the nodes locally since it is of standard size and each node knows the exact slots during which it will be transmitting or receiving. Details of this phase are presented in the next section. Data Collection phase: In this phase, each node knows which epoch/round/slot it should transmit at based on the schedule determined 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 timers for the slots it participates in and being awake when it serves as a child or parent. Nodes go to sleep on their off slots or rounds. Upon receiving the report from a child, a node parses the packet, appends its own reading if the packet is not saturated and its own reading is not transmitted yet, and sends the packet upstream.

6 374 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) A distributed graph coloring algorithm for slot determination Since precedence constraints are addressed by the Round Determination phase, the goal of the Slot Determination phase is to decide slot numbers of all transmissions within the same round, trying to maximize channel reuse while eliminating interference. 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 G I = (V, E I ), where E I consists of (i) all edges in E; and (ii) all edges (v i, v j ), where either v i or v j can hear each other or one of them can interfere with a signal intended for the other (even if they cannot hear each other). Second, we define a conflict graph G C = (V, E C ). E C includes the following edges. (i) Since a parent and a child node cannot transmit at the same time, if (v i, v j ) E, then (v i, v j ) E C. (ii) If (v i, v j ) E I, then (v i, v j ) E C, because v i and v j interfere with each other. (iii) If (v i, v j ) E I and c j is a child of j in G, then (v i, c j ) E C, because v i and v j interfere, if v i is transmitting, the children of j cannot transmit at the same time since v j would hear from both v i and c j. The resulting graph G C will include all the potential conflicts for the original graph G, and the slot determination problem then becomes the scheduling of nodes V in G C, such that no two adjacent nodes in G C have the same color (considering that one color maps to 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 dynamically determined in a decentralized manner given that we do not have location information of each node. This implies that the graph to be colored is not fully established before coloring begins and many links related to schedule conflicts need to be gradually discovered during coloring. In addition, wireless links are asymmetric, leading to directed graphs. We hence design a new distributed graph coloring heuristic specifically appropriate for our application scenario 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 determined by the number of colors used to color the vertices belonging to that round. The number of colors is determined by the amount of interference between the nodes in the round. Each node only transmits (as a child) during one of the rounds but can potentially be receiving transmissions (as a parent) from its children in any other round; therefore, each node has to actively participate in its own coloring as well as coloring for all of its children. There is no concern about interference between 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 a receiver. 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 interfering with each other, each node would need a separate slot to transmit and the number of colors across all the palettes would be equal to the number of nodes n. In order to minimize the number of colors, the nodes always try to get the lowest available integer 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 palette mechanism, 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 of nodes (i.e., nodes with different parents) have to be resolved Details of the algorithm In the Slot Determination phase, each node v i negotiates its color c i with its parent p i in its round k i. Node v i also assigns and negotiates color c j at round k j for each of its children v j in ch i. As a result, each node will get a time slot within its respective round k i. The conflicts and additional interference not in the current interference set are detected by snooping and by specifically inquiring from nodes in interference set I i 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 available or unavailable (deleted) at any given time. It is possible for a color to go from unavailable to available. If the color cannot be confirmed because of the conflict at one of the nodes, the other node makes that color available in its palette again to avoid the false blocking problem. The following greedy heuristic runs in a distributed manner at each node v i. 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 negotiate as either a child or a parent, the length of the negotiation round, and the start time of the Slot Determination phase. A node sets up a timer for the beginning of each round it will participate in. The timers are used for a node to know when it should start negotiating the slot number either for itself or each of its child nodes. For instance, in Fig. 4, a node v i has its own round number as k i, and its child v j s round number as k j. v i will set up a timer for itself (with length as the product of its round

7 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Fig. 4. Finite state machine of node v i. Fig. 5. Finite state machine for node v i in state AsChild. Note: n.a.c. stands for next available color, and C i refers to C cr i. number k i 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 to assign a color to it. Upon receiving a suggested color, it negotiates based on whether the color is available in its palette for this round. AsChildWaitAssignment: A node (v i ) starts with the AsChildWaitAssignment state and waits for its parent to assign a color to it. (1) If the node receives a color assign message, and that color (x) is available in the node s palette, the node transitions to the AsChildAvailColorRcvd state; if color x is not available in the node s palette, the node transitions to the AsChildUnavailColorRcvd state. (2) If a node overhears that a color has been assigned, requested, or confirmed, the node deletes the color from its own pallette. AsChildAvailColorRcvd: The node sends a confirm message 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 the AsChildConflictDetection state.

8 376 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Fig. 6. Finite state machine for node v i in state AsParent. Note: n.a.c. stands for next available color, and C i refers to C cr i. (3) If the node receives an assign message from its parent and the color is different from the original color, it adds the original color back to its palette, and then transitions to the AsChildAvailColorRcvd or AsChildUnavailColorRcvd state depending 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, and then sends a request message to its parent and start the confirmation timer t c. AsChildConflictDetection: If there are any nodes in the node s interference set for which the color is not known from snooping, the node sends an explicit inquiry to those nodes about their color selections. In the rare case of detecting a conflict, the node that first detects the conflict selects the next available color from the palette, makes that color unavailable, sends a request message to its parent proposing a new color, and transitions back to the AsChildWaitConfirmation 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 same time. The node first selects the lowest available color for each of its children in a given round, makes these colors unavailable in its palette, and broadcasts an assign message. Child nodes and surrounding nodes receive the message. This allows for any interfering node that has a conflict to send a conflict message. The node then negotiates with each child individually based on 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 finalconf message. If the node receives a request message for a different color from a child node, and that color is available in its palette, it makes the original color assigned to that child available and the new proposed color unavailable in its palette, and sends a confirm message to that child. If that color is not available in its palette, it selects the next available color, makes the original color assigned to that child available and the new proposed color unavailable in its palette, and broadcasts an assign message. If the node overhears an assign, request or confirm message coming from an unrelated node, it checks to see if the color in the message is available in its palette. If the color is available, the node makes 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 overheard message. If the node overhears another color is being assigned, requested, or confirmed, then it removes that color from its own palette. 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 have a chance to learn about the choice, and potentially interfering nodes in either neighborhood can send a conflict message to the pair of negotiating nodes.

9 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) 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 rounds are separated temporally. Therefore, we only need to be concerned with the nodes that transmit in the same round. There are three different cases: a. Sibling nodes: For any set of nodes that send their reports to the same parent, conflicts are guaranteed to be eliminated during the Slot Determination phase because the parent assigns the colors to them and ensures that no two children with the 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 a different 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 from interfering with each other. First, slot negotiation for nodes with the same round number happens in parallel. If a conflict exists, it is usually discovered by snooping; a conflict message is sent, and interference is prevented by selecting a new color for one of the nodes. Second, it is possible that channel sensing fails, and such nodes transmit their negotiation messages at exactly the same time and choose the same color. To prevent conflicts caused by such situations, actions are taken at each phase of TIGRA. (i) During the Round Determination phase, each node v i uses snooping to construct an interference set I i and, if possible, snoops the round number for each node in I i. If the round number for a node in I i is different from node v i s own round number k i, such a node is removed from I i. (ii) During the Slot Determination phase, node v i makes sure that no node v j in I i is assigned the same color as v i. If the color for a node v j cannot be determined implicitly by snooping, node v i sends an explicit message to v j inquiring about v j 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 provides an collision-free transmission schedule. Theorem 2. TIGRA will eventually terminate. Proof. To prove that the algorithm terminates, we must make sure that there is no deadlock or livelock (infinite loop) at any phase of the algorithm. In the Round Determination phase, nodes transmit an init message only once. Furthermore, a node waits for a constant time to receive feedback from potential children before concluding that it is a leaf node. With these constraints, no deadlock nor infinite loop is possible. Therefore, the Round Determination phase terminates as long as the number of nodes in the network is finite. During the Slot Determination phase, some node pairs may go through as many iterations as the size of their interference set before ending negotiation; however, such negotiation definitely terminates because the nodes eventually use all the colors in their palettes and then add a new color. As can be seen from the Finite State Machine (FSM) diagrams (Figs. 5 and 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 the Data Collection phase, each node transmits its message 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 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 in the network. Each node broadcasts the packet once and reports to its parent once. Once the leaf nodes are reached, the response packets propagate back towards the sink. Again, each node only transmits once. Therefore, during the Round Determination phase, the number of messages exchanged is O(n) and the time complexity is O(n), if we assume that the one-hop transmission delay is a constant Complexity analysis of the Slot Determination phase During the Slot Determination phase, every child parent node pair exchanges at least three messages: the parent assigns a color to each child, each child sends a confirm message, and the parent broadcasts a finalconf message. If the initial color assignment does not work for the child, it proposes a new color. If the new color does not work for the parent, it proposes another 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 time complexity 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. The maximum number of colors required by nodes in a given round is O(l). Therefore, the worst case time complexity

10 378 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) 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(l 2 ), and is on the order of O(m l 2 ) for m rounds. m is limited by the packet size and is a small constant; therefore, the run time of the entire algorithm is on the order of O(l 2 ). For a network with n nodes, the maximum number of colors used in a palette satisfies max l n, where max is the maximum vertex degree. Therefore, in the worst possible scenario, the time complexity for the Slot Determination phase is O(n 2 ). 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 their respective 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 assignment first, other parent nodes overhear the confirm message, and send the next available color, i.e., 2, to their respective child nodes. Let us assume that node 6 confirms the second assignment first, and both remaining parent nodes 3 and 4 overhear the confirm message. (C): Nodes 3 and 4 select the next available color, i.e., 3, and send it to their child nodes; node 7 confirms it 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 sets of negotiation messages are exchanged before convergence, where g is the number of negotiating node pairs, and the set of negotiation messages contains a set of request, confirm and finalconf messages or any subset thereof pertaining to a specific color. 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 also makes negotiation for each pair closer to a constant time (as opposed to O(l)). Even though eavesdropping cannot guarantee constant time for each negotiation, since a child may not hear all of its parent s neighbors and vice versa, it reduces the number of messages necessary for each pair and brings the algorithm run time closer to O(l), where max l n 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 be deterministically bounded as Delay m e l t packet, where m is the number of rounds, e is the number of epochs, l is the maximum number of time slots used in a round, and t packet 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 compare its performance against existing algorithms under different network settings using simulation. To further study the effectiveness of TIGRA, we also evaluate it on a sensor network testbed Simulation settings Our empirical studies thoroughly compare the performance of TIGRA against two existing protocols. As a baseline comparison, we compare TIGRA to a basic data collection protocol, referred to as BASIC, which first builds a routing tree and then collects data from each node. No mechanisms above the MAC layer are developed to support timeliness. However, up to five retransmissions are allowed for messages that do not successfully reach the next hop. In addition, we compare TIGRA to SPEED [6]. We chose SPEED for comparison because SPEED is a real-time protocol designed to minimize the deadline miss ratio in sensor networks and it is compatible with most existing best-effort MAC protocols, which is consistent with TIGRA.

11 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Scheduling Latency vs. Network Size (grid topology, avg neighborhood size: 8, reading size: 3B) Latency (seconds) Fig Network size (nodes) Impact of the network size on the scheduling latency (grid topology). All three protocols (BASIC, SPEED, and TIGRA) are implemented in TOSSIM 2. [25]. The default TOSSIM MAC protocol is CSMA. We use the default values for TOSSIM s radio model that are based on the CC242 radio. In TOSSIM, all time values are specified in terms of radio symbols. The MAC object is configured to act like the standard TinyOS 2. CC242 stack: it has 4 bits per symbol and 64 k symbols per second, for 256 kbps. The radio must detect a clear channel twice before it will transmit. The radio will back off infinitely before signaling failure. For other values of CSMA, interested readers may refer to [26]. We also integrated FTSP [27], 1 one of the most precise time synchronization protocols where the average per-hop synchronization 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 Slot Determination phases and (2) the Data Collection phase Simulation results The performance of all three protocols (BASIC, SPEED, and TIGRA) is tested under both grid and random network deployment; we also varied the network size and node density. We observe that the performance trend and comparison under random network topology is very similar to that under grid topology, so the following discussion is focused on grid topology. t packet is set to be 7 ms based on the empirical results, and a new reading is generated by each node every 1 s. A simulation run consists of initialization and data collection periods. For TIGRA, initialization consists of the Round Determination and Slot Determination phases. For BASIC, initialization consists of building a collection tree by flooding the network with an initialization packet from the sink. This packet also includes the time to start the data collection. SPEED does not use a static collection tree; therefore, the initialization packet is used only to broadcast the start of the data collection period. We measure the latency and energy consumption separately for the initialization (i.e., scheduling) and data collection periods. Each data point is based on 2 experiments. We use a 95% confidence interval for the error bars Impact of the network size The 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 readings to the sink. For both SPEED and BASIC, the scheduling latency increases with the size of the network also due to a deeper routing tree. The collection latency, however, increases up to a certain point and then flattens out or decreases because many data packets get dropped due to collisions. Since the collection latency is measured while data packets are received at the sink, packets from nodes farther away from the sink, which are more likely to get dropped, often do not contribute to the collection latency. Fig. 1 illustrates a higher scheduling overhead imposed by TIGRA when 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 the cost of higher scheduling overhead, after scheduling the transmissions in the Round Determination and Slot Determination phases once, TIGRA can use the resulting schedule for as many periods as needed or until the application requirements or the 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 code may be downloaded from 2.x/tos/lib/ftsp/.

12 38 L. Paradis, Q. Han / Pervasive and Mobile Computing 5 (29) Collection Latency vs. Network Size (grid topology, avg neighborhood size: 8, reading size: 3B) Latency (seconds) Network size (nodes) Fig. 9. Impact of the network size on the data collection latency (grid topology). energy consumption (uj) Scheduling Energy Consumption vs. Network Size (grid topology, avg neighborhood size: 8, reading size: 3B) Network size (nodes) Fig. 1. Impact of the network size on the scheduling overhead (grid topology). energy consumption (uj) Collection Energy Consumption vs. Network Size (grid topology, avg neighborhood size: 8, reading size: 3B) Network size (nodes) 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 delivery ratio decreases drastically as the network size increases. In contrast, TIGRA negotiates a precise schedule for each node s transmission and explicitly avoids interference. This feature is demonstrated in Fig. 13 that shows the cumulative sensor reading delivery ratio as collection time progresses for a constant network size and density. Given enough time, TIGRA achieves a 1% packet delivery ratio, whereas BASIC and SPEED deliver a certain number of sensor readings early in the data collection period, after which they do not deliver any more readings to the sink due to interference. Further, TIGRA s packet delivery ratio is always higher than that of BASIC and SPEED at any given time of the data collection period because of the collision-free schedule, as well as the batch transmission processing (up to m sensor readings are delivered to the sink in a single packet) Impact of the network density Figs. 14 and 15 show how network 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