1. 1 Exploiting Heterogeneity for Routing in Wireless Sensor Networks CENS Seminar Series 6 October 2006 Thanos Stathopoulos CENS Systems Lab thanos@cs.ucla.edu

2. 2 Talk Outline Overview of Heterogeneous Wireless Sensor Networks –Problem Statement Tier 1: Centralized Routing for Mote Networks Tier 2: End-to-End Routing for Dual-Radio Sensor Networks Conclusion

3. 3 Heterogeneity in WSNs WSNs in 2000: Homogeneous –Single (uniform) platform per research group –Peer design: All nodes in the network share the same functionality WSNs in 2006: Heterogeneous –Tier-1: mote-class devices –Tier-2: microservers –Discrete tasks: nodes in the network treated differently

4. 4 Problem Statement WSN architectures becoming heterogeneous Should network protocol design be homogeneous or heterogeneous? Design with heterogeneity in mind or mask it?

5. 5 A closer look at the hardware platforms: motes and microservers Microserver advantages –High-bandwidth radios –Storage –CPU power –I/O interfaces –Can use “traditional” OS –Relatively easy to program Microserver challenges –Power consumption –Infrastructure cost Mote advantages –Low cost –Low power consumption –High spatial density Mote challenges –Very limited storage (RAM, EEPROM) –More difficult to program –Very limited computational power –Low-bandwidth radios

6. 6 Why heterogeneous design? Neither platform by itself can sufficiently meet all application requirements “Use each platform for what it’s good for, not for everything” –Successfully applied to other systems i.e. Internet

7. 7 Focus of this talk “Exploit heterogeneity for routing in wireless sensor networks” –Use one platform’s advantage to offset the other platform’s disadvantage Can often lead to performance improvements –Demonstrated through two separate protocol designs Mote tier: Centralized routing Microserver tier: end-to-end routing for dual-radio duty- cycled microservers

8. 8 Tier 1: Centralized Routing for Mote Networks Overview of Heterogeneous Wireless Sensor Networks Tier 1: Centralized Routing for Mote Networks –Mote routing overview –Problem description: distributed routing for motes –Proposed solution: CentRoute –CentRoute design details –Performance evaluation Tier 2: End-to-End Routing for Dual-Radio Sensor Networks Conclusion

9. 9 Overview: Differences between traditional and WSN routing Traditional routing –Any-to-any –Reliable links –Optimized for delay, path length, throughput WSN routing –Mostly many-to-few or many-to-one –Unreliable links –Optimized for energy consumption

10. 10 Overview: Mote-based WSN Routing Established mote-based WSN routing: Tree-based, Distributed, Proactive –Tree-based: Data usually flows from leaves to root(s) –Distributed: Each node makes its own decisions Uses information from neighboring nodes Distance-Vector based –Proactive: Paths continuously maintained Continuously evaluate “best path” Examples: –MintRoute (popular mote routing protocol) –Directed diffusion (microserver-based but mote implementations exist)

11. 11 Problems with existing mote routing protocols Mote-specific problems: –Distributed decision making in conjunction with storage constraints leads to routing instabilities and inconsistencies –Limited RAM also creates scalability challenges in terms of network density and network size Additional problems –Proactive nature leads to increased energy consumption –Distance-vector leads to count-to-infinity scenarios and routing loops

12. 12 Problems in more detail: Distributed decision making under RAM constraints Selection of the next hop to a destination is based on neighbor table –Memory requirements are O(neighborhood size) Memory constraints place upper bound on table size –Cache eviction policies used when capacity is exceeded (MintRoute) Subject to thrashing, especially in dense networks Leads to routing instabilities (“flapping”) Independent decisions by nodes based on artificially constrained information lead to inconsistencies AB Node A has node B in neighbor table and as a next hop to a destination Node B doesn’t have node A in neighbor table and thus doesn’t forward the packet further

13. 13 Proposed solution: Centralized Routing Exploit heterogeneity: utilize microservers as routing decision points –Remove decisions from individual motes –Centralize the decision-making on the microservers Not resource constrained Natural centralization points due to tree-based nature Centralization refers to a single tree –Multiple trees can exist, each rooted at a different sink –Multiple trees improve performance and lead to better scaling ExScal Tenet

14. 14 Disadvantages of Centralized Routing Centralization point: Single-point-of-failure –A problem with all tree-based routing protocols –Solution: support for multiple sinks Data will be routed to alternative sink if primary sink fails Standard practice even in distributed protocols (Directed Diffusion, Multihop, Drain etc) Potentially high control overhead –Control data needs to be forwarded back to the central point Scales poorly with path length –Potential solution: on-demand protocol No periodic control messages Still an issue in long, unreliable paths

15. 15 CentRoute: Centralized on-demand routing protocol for motes Addresses mote-based routing problems –Minimizes routing inconsistencies, including loops –Minimizes memory (state) requirements on motes –Increases routing stability –Can scale to dense networks Provides additional functionality –Bidirectional unicast routing (to and from the sink) –Global view of the entire mote network at each sink Uses StateSync for reliable sink state dissemination

16. 16 CentRoute design overview Runs on both motes and their sink (microserver) –Motes forward control data to microserver –Decision-making logic implemented exclusively on microserver On-demand protocol –Tree maintained by data packets Dynamic single-sink support –Sink selected at runtime –At-most-one protocol Motes only send data to (and keep state for) one sink at a time –Multi-sink ambiguity resolved in microserver tier StateSync(*) used for inter-sink communication Uses Source Routing * StateSync is work done by Lewis Girod

17. 17 CentRoute design: Tree Formulation CentRoute Motes that aren’t part of a tree periodically broadcast “join request” beacons. A mote receiving a join beacon will only forward it if it has a unicast path to the sink. A sink receiving a join request will send a source- routed unicast “join reply” to the requesting mote thus grafting it to the tree. Motes receiving the join reply will set their “next hop” to be the mote that forwarded them the join reply A sink receiving multiple join requests from a mote will select the “best path” to send the reply to, based on its routing metric

18. 18 CentRoute design: Path Maintenance Paths in CentRoute maintained by data packets –Tradeoff: reduced control overhead vs potential higher path repair time Link-layer ACKs and retransmissions used to determine if next hop is valid –Each data packet is retransmitted N times –If link to parent fails (no ACK received), mote invalidates path and invokes join mechanism again CentRoute doesn’t attempt to find better path once one has been established –Only “bad news” can force a path to change –Tradeoff: path stability vs potential sub-optimal paths

19. 19 CentRoute: Performance Evaluation Simulation and testbed experiments to evaluate: –Network connectivity –Control overhead –Performance in sparse, long networks –Convergence time –Path length and stability –Inconsistencies and loops Simulation scenario: –100 motes arranged in a 100x100 grid –1 sink in the middle of the top row –Adjusted power to control mote neighbor density: Number of motes in neighborhood with average link quality of 70% or better –3 hour-long experiments Performance comparison with MintRoute and Multihop

20. 20 Centroute Performance: Network Connectivity At very low densities, CentRoute’s performance suffers At low and medium densities, both CentRoute and MintRoute can maintain 100% connectivity At higher densities, CentRoute maintains 100% connectivity while MintRoute’s performance suffers due to its linear scaling properties CentRoute stays at 100% MintRoute drops to 90%

21. 21 CentRoute performance: Control Overhead At very low densities, CentRoute has a high overhead –Sparse network leads to longer paths which incur higher overhead As density increases, CentRoute’s overhead is 5 times less than that of the DV proactive protocols. –On-demand nature CentRoute at 0.3 b/s/m Mintroute at 4 b/s/m

22. 22 CentRoute Performance Path Inconsistencies and Loops Inconsistency: source mote believes it has a route to the sink but that opinion is not shared by all motes along the path. –A loop is a special kind of inconsistency CentRoute exhibited no inconsistencies and no loops –Reasons: centralized decision making, sink-delegated paths, fast broken path notification and source routing

23. 23 CentRoute performance: Convergence Time CentRoute can quickly connect a significant part of the network –No need to wait for periodic link estimator to “warm up” Phased join operation –Nodes near the sink connect quickly –Linear latency cost for modes further away from the sink 20% in 10 seconds 80% in ~60 seconds 100% in 150 seconds 20% in 150 seconds 80% in ~180 seconds 100% in 210 seconds CentRouteMintRoute

24. 24 CentRoute Summary A centralized, on-demand routing protocol for motes Based on a heterogeneous design –Exploits heterogeneity by centralizing routing decisions on the microserver –Alleviates hardware limitations of motes Addresses problems of current mote routing protocols –Scales well with density More than 99% connectivity in medium and high densities –Energy and memory efficient As low as 0.3 bytes/sec/mote transmission cost Constant RAM requirements on motes –Robust and stable Very stable paths, loop-free

25. 25 Tier 2: End-to-End Routing for Dual-Radio Sensor Networks Overview of Heterogeneous Wireless Sensor Networks Tier 1: Centralized Routing for Mote Networks Tier 2: End-to-End Routing for Dual-Radio Sensor Networks –Problem description: routing for duty-cycled nodes –Proposed solution: using the low-power radio –Wake-path design –Performance evaluation Conclusion

26. 26 Overview: Duty Cycling in the Microserver Tier Microserver resources come at a price: energy consumption –CPU, RAM, network interface, peripherals Line-powering not always possible –Outdoors deployments, infrastructure costs Solution: duty-cycling –Turn off radio, put CPU to sleep when not needed

27. 27 Problem Description: Routing in Duty Cycled Nodes Problem: Creating an end-to-end multihop path in the presence of duty-cycled microservers while minimizing –Energy consumption –Data transmission latency Example applications –Seismic event detection –Intrusion detection and tracking

28. 28 Potential solution: Periodic wakeup Nodes periodically wake up to send data –Well-known solution used in e.g. TDMA MACs Wakeup schedule can be static or adaptive –Works well if a model for the observed phenomenon exists or can be learned Tradeoff: energy efficiency vs event (and data) latency –Periodic algorithm cannot always provide both

29. 29 Proposed solution overview: Using a second, low-power radio Wake-path: wake up nodes along the expected 802.11 path by using a low-power radio Exploit heterogeneity: use the low-power advantages of motes to offset the disadvantages of microservers Use mote-class devices to: –Remain vigilant for large periods of time while microservers are asleep –Wake up the host microserver when needed –Coordinate with other motes to wake up the microservers required for the multihop path

30. 30 Wake-path: Assumptions Each microserver has a mote-class device attached –Either Stargate+mote, or LEAP nodes The MCU that controls the low-bandwidth radio is not put to sleep –Can at any point wake up the main CPU The low-bandwidth network is connected –Required if the low-bandwidth network is to be used as a control channel No-partition assumption does not imply that the two network topologies match! –Two different, independent routing protocols used –Radios can have similar ranges, or –The low-bandwidth topology needs to be sufficiently augmented by adding standalone motes

31. 31 Wake-path design: Establishing a Path Microserver wakes up based on an external event (i.e. sensor input) Microserver uses low-bandwidth radio to request a multihop path via the topology controller Controller uses 802.11 routing information to decide which microservers to wake up Controller sends messages via the mote network to required microservers Once all required microservers are up, controller informs the source and data transfer can begin over 802.11

32. 32 Performance Evaluation Overview Wake-path compared to alternative approaches Analysis: Simple numerical models to determine energy consumption of each approach –Studies effects of event frequency, data size and network topology –Quantifies impact of transition constants Testbed evaluation –Energy and latency evaluation of Wake-path –Testbed characterization

33. 33 Performance evaluation: Alternative approaches Always-On: All radio and CPU resources on all the time –No need for a second radio –Lowest latency, highest energy consumption Periodic-wakeup: Nodes periodically wake up to send data –No need for a second radio –Energy/latency tradeoff Wake-all: Nodes are all woken up when an event occurs –Needs a second radio to inform nodes about wakeup –Wakes up all nodes in the network –Low latency, energy consumption depends on size of the network

34. 34 Numerical Analysis: The impact of transition constants High-bandwidth radio more efficient if: –Powerdown-to-on: Data size > 464 KBytes –Suspend-to-on: Data size > 63.8 KBytes –Testbed results: high-bandwidth radio increasingly more efficient in multihop case Effect of different power saving modes on energy efficiency: –Suspend preferred to powerdown mode in medium event frequencies: 6 events/hour for 400 Kbytes of data –Powerdown mode better for smaller frequencies –Above 100 events/hour: no duty-cycling better –Increasing the data size results in even smaller event thresholds

35. 35 Experimental Testbed Setup 11 Stargates with attached Mica2 motes 13 extra standalone motes providing strong connectivity for the CC1000 network DSR in 802.11 network –4 MB data transfers to node 169 using TCP Performance comparison of Wake-path vs Wake-all –Energy consumption –Latency –Reliability Testbed characterization –Multihop efficiency of the two radios –Topology correlation

36. 36 Wake-path performance: Energy Consumption Wake-path consistently better than Wake-all –Less pronounced difference at larger path lengths Path-to-total-nodes ratio increases –Expected result from numerical models Significant energy consumption for both mechanisms in larger path lengths –Byproduct of sparsely connected 802.11 testbed and TCP –Still, energy consumption much higher than model More than 60% energy savings

37. 37 Wake-Path performance: Latency Wake-path adds low extra latency compared to Wake-all –Grows almost linearly with number of nodes in the path Considerable extra latency added by DSR –Conservative timers –Optimization: disable DSR path establishment Carry next hop information in low-bandwidth radio control packets Considerable data transfer latency due to poor links and TCP ~6 sec DSR latency due to internal timers Large latency due to poor links and TCP retransmissions

38. 38 End-to-end routing for duty-cycled microservers: Summary Wake-path: Topology control protocol for duty-cycled dual-radio microservers –Enables low-latency and low energy consumption multihop path construction over 802.11 Uses low-bandwidth radios as multihop control channel Selectively wakes up only the nodes required for the path Numerical and testbed performance evaluation –Energy savings up to 60% compared to waking up all the nodes –Low additional latency: 6 sec compared to wake-all, 9 sec compared to always-on

39. 39 Conclusion Heterogeneous WSNs –Different platforms with distinct advantages and disadvantages Exploiting heterogeneity for routing in WSNs –Take advantage of different capabilities of platforms in heterogeneous system –Can often lead to performance improvements Mote tier: CentRoute Microserver tier: end-to-end routing for duty-cycled microservers

40. 40 The End Thank you!