A Pro-Active Routing Protocol for Continuous Data Dissemination in Wireless Sensor Networks

Transcription

1 A Pro-Active Routing Protocol for Continuous Data Dissemination in Wireless Sensor Networks Daniel F. Macedo 1 Luiz H. A. Correia 1,2 Aldri L. dos Santos 1 Antonio A. F. Loureiro 1 José Marcos S. Nogueira 1 1 Dept. of Computer Science 2 Dept. of Computer Science Federal University of Minas Gerais Federal University of Lavras Belo Horizonte-MG, Brazil Lavras-MG, Brazil {damacedo,lcorreia,aldri,loureiro,jmarcos}@dcc.ufmg.br Abstract Wireless sensor networks are ad hoc networks with severe resource constraints. These constraints preclude the use of traditional ad hoc protocols, and demand optimizations that incur in solutions specific to a class of applications. This article presents, a protocol designed for continuous data dissemination networks, that interacts with the application to establish routes, allowing the application to reconfigure on runtime. A performance evaluation in topologies varying from 50 to 200 nodes showed that increases network lifetime around 7% to 12%, and has higher throughput than and TinyOS Beaconing. Furthermore, presents a softer performance degradation when the number of nodes in the network increases. 1. Introduction Wireless Sensor Networks (WSNs) are a subclass of traditional ad hoc networks, and consist of a large number of sensor nodes, each one with processor, memory, battery, sensors and transceivers. These nodes send monitoring data to an access point (AP) responsible for forwarding data to the users [6]. Unlike traditional ad hoc networks, in general it is not possible to replace or recharge batteries due to the number of nodes deployed or inhospitable environment, hence energy conservation is critical in WSNs. Energy restrictions in sensor networks have led to the development of new protocols speci c to WSNs. To increase Partially supported by CNPq, Brazil, process number / In sabbatical period at universities of Evry and UPMC/Paris6/LIP6, France. energy savings, protocols might take advantage of network speci c characteristics, such as event-driven data, the availability of geographical positions, and real-time restrictions. Another possibility to optimize the operation of the protocols is the interaction with the application. In such protocols, layer functionalities are interleaved, and the application might interact with medium access control (MAC) [11] and routing protocols [7] to optimize their operation. Sensor networks can be divided in two classes, according to the periodicity of communication [13]. In event-driven networks, data is only sent whenever an event occurs. In continuous dissemination networks, every node periodically sends data to the AP. Routing protocols are usually implemented to support one class of network, in order to increase energy savings. In such networks, routes will be periodically reconstructed, while in event-driven networks routes will be constructed only when an events occurs, since the cost of constant updates is prohibitive in this scenario. Current routing protocols for WSNs based on continuous data dissemination do not use application information in the establishment of ef cient routes. The proposed protocol, called (Proactive ROuting with Coordination), interacts with the application in order to determine which nodes can route data. This interaction allows applications to optimize the operation of the protocol, increasing its performance and adapting the traf c o w to the application s needs. The application software may employ application semantics or other kinds of information such as geographical positioning of nodes, network topology, current environment and node states to increase energy savings and performance in. Furthermore, clearly de nes which nodes will route data, allowing the application to periodically turn off nodes not routing data. To evaluate the protocol, we ran simulations and com-

2 pared to the [1] protocol and the TinyOS Beaconing protocol, the standard protocol in the TinyOS operating system [9]. We show that increases network lifetime and has higher throughput than both and TinyOS Beaconing protocols. Furthermore, presents a graceful performance degradation when the number of nodes in the network increases. The rest of the paper is organized as follows. Section 2 presents the related work. Section 3 presents an overview of the protocol and describes the algorithms for backbone construction and establishment of routes. Section 4 describes the simulation environment, the experiments performed and their analysis. Finally, Section 5 presents the conclusions and future work. 2. Related Work The use of application information to aid routing was introduced by Directed Diffusion [7]. This protocol, speci c to event-driven networks, allows data requested by the application to determine routes established to serve each request. Furthermore, an application decides when a message will be forwarded, dropped or merged with other received messages, reducing energy consumption. However, Directed Diffusion showed to be extremely inef cient in WSNs based on continuous data dissemination [5]. Span is a protocol for controlling the topology of mobile ad-hoc networks [2]. It uses information from its neighborhood to determine which nodes will be routers, while non-routing nodes might enter a power-saving mode. Router nodes form a routing structure called backbone, taking into account network connectivity and energy consumption. Span is not suitable to sensor networks due to the amount of messages and memory used to maintain local information. expands the concept of the backbone to WSNs, and uses this structure to aid topology control algorithms and also route data. TinyOS Beaconing is a protocol used in the Mica Motes platform [9]. This protocol periodically creates a minimum distance tree rooted at the base station. Nodes snoop traf c to estimate the link quality of their neighbors. Only nodes with good link quality are used to route messages. When nodes on the network are operating in power-saving modes, snooping performance is degraded since nodes do not send data for an extended period of time., on the other hand, allows certain nodes to be turned off during some time intervals. Boukerche et al. proposed a routing algorithm, called (Energy-Aware Distributed routing), which creates a routing tree that maximizes the number of leaf nodes [1]. This tree ensures that all nodes are able to send messages to the AP. Leaf nodes may turn their radios off in order to extend network lifetime. The protocol also uses backoff timers based on current node energy in order to decrease collision probability. Unlike, the protocol does not take into account application-speci c information to optimize routing. We implemented a version of this algorithm as well as a simpli ed version of the TinyOS Beaconing protocol to compare their performance to. 3. Protocol is a pro-active protocol designed to support a continuous dissemination networks. The protocol was proposed for networks which have a many-to-one traf c pattern: nodes only communicates with its neighbors and the AP. takes advantage of such traf c pattern, and builds unidirectional routes from sensor nodes to an AP, as in strategies employed in other existing protocols [1]. builds a routing structure called backbone. The backbone is composed of a set of nodes, called coordinators, that propagate information towards the AP. The backbone is a tree-like structure where nodes not in the backbone are directly connected to a node in the backbone, shown in Figure 1 (c). Nodes only need to know their parents in the backbone. Parent nodes forward the data produced by the their descendants towards the AP. To increase energy savings, the creation of the backbone tries to minimize the number of coordinator nodes. rebuilds routes periodically in time intervals called cycles. The backbone structure allows the use of topology control algorithms, where non-coordinator nodes can be on a low energy consumption operational mode. Since the backbone guarantees radio coverage on the region (as all nodes on the network are neighbors of a coordinator node), topology control algorithms may only take into account sensing coverage, simplifying its implementation [4]. Figure 1 shows the phases of the backbone creation process. Initially, nodes are self-elected coordinators (nodes in black), as shown in Figure 1-(a). Each node has a given probability of becoming a coordinator, calculated by the application, using functions called rules. The coordination election phase alone, however, may not form a complete backbone. The backbone augmentation phase, Figure 1-(b), ensures that every node nds a route to the AP through a coordinator node by adding more nodes to the backbone when necessary. The rightmost lower node, for example, does not have any coordinator node in its radio range, thus one of its neighbors (nodes in gray) will be appointed as a coordinator. Next, routes (arrows in the gure) are established, as shown in Figure 1-(c). The algorithms use only information about neighbor nodes and its current state, hence reducing the amount of memory used on the nodes. All routing messages contain the current status of the sender, which includes the node role (coordinator or not), its current cycle, residual energy and the number of hops towards the AP.

3 Coordinator Election AP (a) Backbone Augmentation AP (b) AP (c) Route Formation Figure 1. The backbone creation process Access Point The AP is responsible for initiating the creation of the backbone. This process tries to balance energy consumption among nodes and corrects broken routes. A cycle (and thus the recreation of the backbone) is initiated when the AP sends a synchronization message (M Sync ) to the network (line 7 in Algorithm 1; for simplicity, we refer to the lines in the algorithms throughout the text as l.). Algorithm 1 Access Point: Backbone Maintenance. 1: procedure BaseStation(CycleT ime) 2: nextcycle 0; // cycle being started 3: loop // start a new backbone 4: M Sync.cycle = nextcycle; 5: M Sync.hops =0; 6: M Sync.coord = true; 7: send(m Sync, broadcast); 8: nextcycle nextcycle +1; 9: wait CycleT ime seconds; 10: end loop 11: end procedure Algorithm 2 Sensor Nodes: Routing Backbone. 1: parent nil; // parent node on the routing tree 2: curcycle integer; // current cycle number 3: Neighbors ; // neighborhood status list 4: coordinator false; 5: procedure SensorNodes() Require: receive(m Sync); // set coordinator 6: Neighbors Neighbors M Sync.state; 7: parent UpdateRoute(); // select parent node 8: if curcycle < M Sync.cycle then 9: curcycle M Sync.cycle; 10: prob App.ElectCoordinator(Neighbors); 11: coordinator ( rand() <prob); 12: App.NotifyNewState(coordinator); 13: CurrentNodeState(M Sync); 14: send(m Sync,BROADCAST); // broadcast node state 15: wait BackoffT ime(); 16: parent UpdateRoute(); // new parent node 17: if parent.coordinator = false then 18: CurrentNodeState(M Coord); 19: send(m Coord, parent); 20: Neighbors parent.coord true; 21: end if 22: end if Require: receive(m Coord); // coordinator set by other node 23: Neighbors Neighbors M Coord.state; 24: coordinator true; 25: App.NotifyNewState(coordinator); 26: CurrentNodeState(M Sync); 27: send(m Sync,BROADCAST); Require: receive(m Data); // forward data to parent node 28: if App.forwardData(M Data) =true then // App. might discard of fuse data 29: send(m Data, parent.address); 30: end if 31: end procedure 3.2. Sensor Nodes The operation of the sensor nodes is shown in Algorithm 2. The construction of the backbone starts when a node receives a synchronization message called M Sync (l.6-22), and comprises the coordinator election and the backbone augmentation phases. In the rst phase, started when nodes receive a M Sync message, every node executes the coordinator election procedure (l.10-12). In the second phase, nodes examine if the backbone is complete, appointing nodes to become coordinators if necessary (l.15-21). Coordinator election is the rst phase in the backbone creation. This algorithm uses the rules provided by the application to determine if the current node will be a coordinator in this cycle. For every rule, the application associates a value V in the interval [0, 1] for the node (l.10). The sum of the values of all rules is V T, also in [0, 1]. This value represents the probability of the node to become a coordinator (l.11). Next, the algorithm de nes if the node will become a coordinator, then sends a M Sync message to the network reporting the change in node s state (l.13-14). Backbone Augmentation occurs after receiving the rst M Sync message of a cycle. Nodes wait a random amount of time and determine if the backbone is complete. To do so, nodes verify if the parent node chosen by the route establishment algorithm is a coordinator (l.15-21). If the parent is not a coordinator, the node sends a coordinator indication message (M Coord ) to its parent (l.17-21). The receiver of the M Coord message becomes a coordinator, and sends a M Sync message to its neighbors propagating its new state. The random waiting time, mentioned above, avoids selecting more than one node as coordinator. Thus, the veri cation of the parent node in distinct times allows that less nodes are appointed coordinators Route Establishment The route establishment algorithm is executed when a node receives a M Sync message, electing parent nodes using the Algorithm 3. Routing establishment depends on the node role (coordinator or not) and takes into account neighborhood information. stores an n-uple (hops, curcycle, coord, energy) for every neighbor node (the set Neighbors in Algorithm 3). hops is the hop distance of the neighbor node to the AP, coord indicates if the node is coordinator or not, and energy is the nodes residual energy. In our implementation, curcycle is used only to guarantee that the information stored is still fresh, thus it is not shown in Algorithm 3. Those n-uples are updated with every routing packet received (l.6, l.23 in Algorithm 2).

4 If the node is a coordinator, it selects its parent among the neighbors with shortest distance towards the AP, with priority to coordinator nodes. In case of having two or more nodes with the same distance towards the AP, the node with highest energy is chosen. The selection of routes by the least distance criterion avoids cycles. Algorithm 3 Sensor Nodes: Route Establishment. 1: procedure UpdateRoute( ) 2: if coordinator = true then 1 3: return min(neighbors, {hopsdist, coord, energy }); // neighbor with smallest hop distance and highest energy 4: else 1 5: return min(neighbors, {coord, hopsdist, energy }); // neighbor, pref. coord., with smallest hop distance and highest energy 6: end if 7: end procedure When a node is not a coordinator, it seeks in its neighborhood a coordinator with the shortest distance towards the AP. If no coordinators are found, the node selects the neighbor node with shortest hop distance towards the AP and highest energy as its parent Fault Tolerance Fault tolerance is an essential requirement in the project of routing protocols for WSN, since hardware and communication failures are frequent. Failures occur due to harsh environmental conditions [6] or due to poor link conditions [12]. In order to increase its fault tolerance, uses MAC-layer noti cations to identify parent node failures and bad links. Whenever a certain number of data packets is not acknowledged, identi es that the route is broken, and recalculates the parent node Application Rules The application rules in provide an interface for the application software to adjust, allowing routes to adapt to network and application properties. Each rule is implemented as a function, its return value de ning the probability of a node to route data in the current cycle. This allows applications to assist in the task of route establishment, modifying the behavior of the protocol in runtime according to changes in application or network state. The application might use any information available as input for the application rules, such as node and protocol con guration, current network state or even data from sensors or actuators. It is possible, for example, to use data such as geographic position of nodes, network topology, signal strength, remaining energy, among others, in the implementation of rules. does not demand that applications possess any knowledge concerning routing operation. Thus, guarantees that routes are established even if the application does not appoint coordinators. Besides, applications are not obliged to implement rules, as they could use a set of standard rules, described below, aimed at reducing energy consumption and prolonging network lifetime. This allows to operate with current application software, without the need of any modi cation. The rst rule is an adaptation of the cluster-head election of LEACH [15]. Sensor nodes that recently have been coordinators are less likely to be elected coordinators for a period of time. This allows an exchange of coordinators, thus distributing energy consumption more uniformly among nodes. The second rule adjusts the number of coordinators according to the density of each area in the network. To elect a x ed number of coordinators closer to an ideal value, measured empirically for each network, we apply the following rule: The probability of a node to be elected coordinator is inversely proportional to the number of neighbor nodes. We veri ed empirically that this rule makes coordinator density more uniform in the network. Finally, we propose a third rule, where sensor nodes near the AP have high probability of becoming coordinators. Sensor nodes close to the AP forward more data than distant nodes, hence they spend more energy. By increasing the number of available routes near the AP, traf c tends to be distributed among more nodes, distributing energy consumption over more nodes. This policy is implemented by electing more coordinator nodes in the vicinity of the AP. 4. Performance Evaluation was implemented in the simulation environment NS-2 [10]. We simulated an homogeneous network composed of Mica2 nodes [9]. The simulated traf c is modeled upon the Great Duck Island project [14], where every node sends a 36-byte message to the AP every 70s. Results are presented for networks containing from 50 to 200 nodes, placed randomically. The AP is placed at the corner, maximizing network depth. Node density was kept constant in 23 neighbors in average. Results are calculated for 9000s of simulation time. Each node fails once, following a uniform distribution. Whenever a node fails, it is unavailable for 120s, then resumes its normal operation. Node bandwidth is limited to 12kbps, and 4% of the packets are lost due to errors, as in the Mica2 architecture [3]. Energy consumption values and radio range (15m) were taken from [16]. The MAC protocol employed is similar to B-MAC [11]. In case of a lost message the application will retransmit it one more time. There is one packet queue for routing packets and another for data packets, each with a maximum length of 16 packets. Routing packets have higher priority over data packets, thus data packets are only sent when the queue for routing packets is empty. This strategy reduces routing establishment times [17]. We adjusted parameters based on empirical observations. In our simulations, cycle time was set to 180s.

5 To evaluate the in uence of rules in the performance of the protocol, we employed the rules described in Section 3.5. Those rules are applicable to any application. Results were also taken for, a simpli ed version of TinyOS Beaconing [8]. Link layer quality estimation was not implemented. Empirical evaluation of showed that the beaconing interval of 120s yielded the best performance for the protocol. We also implemented [1] (Section 2), and adjusted empirically the route recreation interval to 120s, in order to yield the best performance in our simulations. Results are an average of 33 simulations, plotted with a 95% con dence interval Network Size Scenario Figure 2 shows the average delivery rate. For networks up to 150 nodes, all protocols deliver nearly all messages. For networks over 150 nodes, however, the amount of messages sent saturates the network, and the difference among the protocols is more pronounced. For 175 nodes, and are superior to in 2%. For networks with 200 nodes, achieves an increase of 6% and 3% over and, respectively. achieved lower latency times for all network sizes, as shown in Figure 3. This is mostly due to rule 3 which induces the existence of more coordinator nodes near the AP (Section 3.5). It creates more routes, allowing traf c to be distributed among more nodes. The latency of is, on average, 1.3s lower than s, and 0.3s lower than s for networks under 150 nodes. For 200 nodes, however, latency signi cantly increases for all protocols. For those networks, achieves an average latency of 12.1s, while and have latencies 11% and 34% higher, respectively. The behavior of the network becomes increasingly irregular as the number of nodes increase, shown by an increase in the con dence interval. Average delivery rate (%) Average latency (s) For networks of 175 nodes or more, the sudden increase in latency indicates network contention. Figure 5 corroborates this, since the number of collisions signi cantly increase for networks over 175 nodes. showed better performance for networks over 175 nodes because the spread of traf c over more routes diminished the number of collisions. and, on the other hand, aim at concentrating traf c over less routes, decreasing delivery rates and increasing latency, due to the elevated number of collisions. The increase in performance of over and tends to increase for bigger networks, since implements rules to decrease contention and distribute trafc among more routes. Average hop count Figure 4. Average hop count. Number of collisions Figure 5. Number of collisions. Figures 6 and 7 present the average number of routing messages sent and the average energy consumption per node, respectively. sends between 13% less messages than and 4% less messages than. We also observed that the amount of energy consumed increases linearly with the number of nodes in the network, increasing from 15J to 104J, on average. routing packets account to 19% of the packets sent in simulations for 50 nodes, 24% for and 20% for. As the number of nodes increase, routing packets are responsible for 11%, 12% and 10% of total traf c for, and, respectively. Number of routing packets sent Energy consumption (J) Figure 2. Average delivery rate. Figure 3. Average latency. Figure 6. Routing packets sent. Figure 7. Average energy spent. Figures 4 and 5 present the average hop count towards the AP and the average number of collisions, respectively. These metrics identify the sources of delay in the network. Figure 4 shows that the number of hops gradually increases with the number of nodes. The latency increase is proportional to the increase of hops for networks up to 150 nodes Network Lifetime Scenario In the second simulation scenario we evaluate network lifetime in a network composed of 200 nodes, where each node stores 100J of energy in its battery. This simulation

6 identi es the behavior of the protocols during network lifetime and, most importantly, how they respond when energy is almost depleted. Figure 8 shows the throughput achieved for this scenario. We observe that protocols have an irregular throughput, around 2.6 packets per second (pps) for, 2.4pps for and 2.26pps for. The standard deviation for the throughput was, respectively, 0.2, 0.3 and 0.36pps. Figure 9 shows the throughput for the last 3000s of simulation. At around 8000s the throughput starts to decline, as nodes are starting to fail due to energy depletion. increases network lifetime in 12.5% and 7.6% when compared to and, respectively, increasing network lifetime to 9900s. This gain in operation time is due to the rules employed, which allowed to divide energy spendings more evenly among nodes. Those results are not shown in this paper. also presented a graceful performance degradation in comparison to the other two protocols. Throughput Simulation time (s) Figure 8. Throughput. 5. Conclusions Throughput Simulation time (s) Figure 9. Throughput (zoomed). This work presented a pro-active routing protocol for at WSNs, called. It is the rst protocol designed for continuous dissemination networks which uses applicationspeci c information to improve routing. The protocol operation consists of a backbone which is periodically rebuilt. Rules use application-speci c information to change behavior in run-time, thus optimizing operation. We derived limits on the number of routing messages sent and amount of memory consumed by. A performance evaluation considering topologies varying from 50 to 200 nodes showed that increases network lifetime in 6%, and has higher throughput than and TinyOS Beaconing protocols. Further, showed a graceful performance degradation when the number of nodes in the network increases. References [1] A. Boukerche, X. Cheng, and J. Linus. Energy-aware datacentric routing in microsensor networks. In Proceedings of the 6th international workshop on Modeling analysis and simulation of wireless and mobile systems, pages 42 49, [2] B. Chen, K. Jamieson, H. Balakrishnan, and R. Morris. Span: an energy-ef cient coordination algorithm for topology maintenance in ad hoc wireless networks. Wireless Networks, 8(5): , [3] I. Crossbow Technology. MPR/MIB mote user manual, October [4] F. Dai and J. Wu. Energy-Ef cient Coverage Problems in Wireless Ad Hoc Sensor Networks. Journal of Computer Communications on Sensor Networks, [5] C. M. S. Figueiredo, E. F. Nakamura, and A. A. Loureiro. Protocolo adaptativo h brido para disseminação de dados em redes de sensores sem o auto-organizáveis. In 22 Simpósio Brasileiro de Redes de Computadores, pages 43 56, Gramado, Brasil, May [6] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. A Survey on Sensor Networks. IEEE Communications, 40(8): , [7] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, and F. Silva. Directed diffusion for wireless sensor networking. ACM/IEEE Transactions on Networking, 11(1):2 16, Feb [8] C. Karlof and D. Wagner. Secure routing in wireless sensor networks: Attacks and countermeasures. In IEEE International Workshop on Sensor Network Protocols and Applications, pages , February [9] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler. TinyOS: An operating system for wireless sensor networks. In W. Weber, J. Rabaey, and E. Aarts, editors, Ambient Intelligence. Springer-Verlag, New York, NY, [10] Ns-2 simulator. [11] J. Polastre, J. Hill, and D. Culler. Versatile low power media access for wireless sensor networks. In Proceedings of the 2nd international conference on Embedded networked sensor systems, pages , [12] N. Reijers, G. Halkes, and K. Langendoen. Link layer measurements in sensor networks. In 1st IEEE Int. Conference on Mobile Ad hoc and Sensor Systems (MASS 04), Oct [13] L. B. Ruiz, A. A. F. Loureiro, and J. M. Nogueira. Functional and information models for the MANNA architecture. In Colloque Francophone sur la Gestion de Reseaux et de Services, pages , February [14] R. Szewczyk, J. Polastre, A. Mainwaring, and D. Culler. Lessons from a sensor network expedition. In Proceedings of the First European Workshop on Sensor Networks (EWSN), pages , Jan [15] W. R. Heinzelman and A. Chandrakasan and H. Balakrishnan. Energy-Ef cient Communication Protocol for Wireless Microsensor Networks. In Proceedings of the 33rd Hawaii International Conference on System Sciences, [16] W. Ye and J. Heidemann and D. Estrin. An Energy-Ef cient MAC protocol for Wireless Sensor Networks. In Proceedings of the IEEE Infocom, pages IEEE, June [17] A. Woo, T. Tong, and D. Culler. Taming the underlying challenges of reliable multihop routing in sensor networks. In Proceedings of the first international conference on Embedded networked sensor systems, pages 14 27, 2003.