Real-time Power-Aware Routing in Wireless Sensor Networks (RPAR)

1. Real-time Power-Aware Routing in Wireless Sensor Networks(RPAR) Octav Chipara, Zhimin He, Guoliang Xing, Qin Chen, Xiaorui Wang, Chenyang Lu, John Stankovic, Tarek Abdelzaher Washington University in St. Louis University of Virginia University of Illinois at Urbana-Champaign

2. Mission critical applications for WSNs • Must operate for moths to years on battery power • Must deliver information tight deadline constraints • E.g. a firefighter must remain aware of fire conditions Seismic structure response Intruder detection Fighting wildfires

3. Challenges for routing protocols • Unreliable communication • Probabilistic and asymmetric links • Time-variable link quality • Limited energy budget • Limited processing power and memory • E.g. MICA2 has • MCU (8Mhz, 8bit) • Memory (Data 4KB, Program 128Kb)

4. Design goals • Minimize energy consumption subject to deadline constraints • Adaptive to packet deadlines • Handles unreliable links • Small overhead

5. Outline • Velocity requirements • Impact of transmission power on velocity • The Real-time Power-Aware Routing (RPAR) protocol

6. Outline • Velocity requirements • Impact of transmission power on velocity • The Real-time Power-Aware Routing (RPAR) protocol

7. S A B D Velocity requirement • The velocity requirement of a packet: • Transformed the end-to-end delay requirement into a velocity requirement that may be enforced locally • Adapt to based on the progress of the packet

8. Outline • Velocity requirements • Impact of transmission power on velocity • The Real-time Power-Aware Routing (RPAR) protocol

9. Empirical setup • Used XSM motes (similar to MICA2) • BMAC as MAC layer • Simple CSMA/CA without RTS/CTS • Implemented ARQ • Varied: • One-hop distance • Transmission power • Observed: • Delivery velocity 4pkt/s 1 2 3 4 5

10. Empirical results • Increasing the one-hop distance has a positive impact up to a point • A higher transmission power results in higher velocity

11. Outline • Velocity requirements • Meeting velocity requirements via power control • A Real-time Power-Aware Routing (RPAR) protocol

12. RPAR “Find the most energy efficient forwarding choice (N, p) that meets the delay requirement”

13. Forwarding policy • Determine the velocity requirement • The velocity provided by A selecting (N,p) as forwarding choice: • Estimated energy consumption (N,p) Energy consumed for one transmission Energy cost of forwarding a packet to N Energy cost of routing a packet to D

14. Delay estimator • Goals: • Reduce storage cost • Estimate of the expected worst-case delay of (N,p) • One-hop delay: • To minimize the storage cost split the estimator • To estimate the worst-case delay we account for the variation in contention and number of retransmissions

15. Neighborhood management • Goal: • Discover new neighbors that meet the velocity requirements quickly • Challenges: • Limited storage – cannot keep stats for all possible neighbors • Probabilistic links – neighbors that have poor links may be included • Link quality changes over time – stats accurate for only the frequently used neighbors

16. Power adaptation Tunes the power to an existing neighbor: • If the velocity requirement is not satisfied increase the power to a promising neighbor • E.g., When routing Vreq = 15m/s increase power to M • If the velocity requirement is satisfied decrease the power to improve energy efficiency • E.g., When routing Vreq = 15m/s decrease power to M Prog(N)=7m Prog(M)=10m

17. Neighborhood discovery • Goal: Find new neighbors when power adaptation fails • Approach: • Broadcast a request to route (RTR) • Nodes receiving the RTR randomize their replies in a window • Not all nodes should reply: • Neighbors that reply may not meet the delay requirement • Prolonged time until a forwarding choice that meets the delay requirement is found • Need to concentrate only on potentially “good neighbors”

18. Identifying the “good” neighbors • Is it already in the table? • Is the maximum velocity it provides higher than the required velocity? • E.g. Assuming link quality of 1, when routing Vreq = 20m/s we need a progress of more than 11m Prog(M)=10m M Prog(O)=12m O Prog(N)=7m D N A K Prog(K)=11m

19. Experimental setup • Prowler simulator with settings similar to MICA2 • Bandwidth 40Kbps • 31 power levels [-10dbm, 20 dbm], current consumption [3.7mA, 21.5 mA] • Implemented the USC probabilistic link model • Many-to-one traffic pattern • Topology of 150mx150m, a node per grid of size 11.5mx11.5m • Packets are generated according to an exponential distribution whose mean is varied M. Zuniga and B. Krishnamachari, “Analyzing the transitional region in low power wireless links,” in SECON ’04

20. Experimental setup (2) • Baselines: • MaxV – select the forwarding choice with max. velocity • MinE – select the most energy efficient forwarding choice • Two versions: high power and default power • Beacon-based neighborhood management • Metrics: • Miss ratio – the fraction of packets missing their deadline • Energy per packet – total energy per delivered packet

21. Miss ratio results • MinEL – achieves low delivery velocity, resulting in high miss ratio • MaxVH – achieves high delivery velocity, resulting in low miss ratio • RPAR • Comparable performance to MaxVH • Neighborhood management has limited effect on best-case performance

22. Energy consumption results • MinEL is more energy efficient than MaxVH • RPAR is the most energy efficient • When routing packets with lax deadlines lower power is used • More energy efficient neighborhood discovery

23. Related work • Providing QoS • Manipulate MAC parameters (e.g., 802.11e, [H. Zhu et. al. ’04]) • Admission and rate control (e.g., SWAN [G.-S. Ahn et. al. ’02]) • Routing (e.g., CEDAR [P. Sinha et. al 99], [Y. Yang and R. Kravets 04]) • Power-aware routing • A vast body of work • Not concerned with meeting deadlines • Closer related to RPAR • SPEED [T. He et. al.’03] - delivers packets at a single uniform speed • MM-SPEED [E. Felemban et. al. ‘05] – has multiple speed and reliability domains • LAPC [M. R. Fouad et. al. ’05] – uses power control but reduces the end-to-end delays in a best-effort manner

24. Conclusions • Power control is an effective actuator for meeting end-to-end delays • RPAR is a novel power-aware routing protocol that meets end-to-end deadlines at low energy cost • Reduces the miss ratio • Adapts to the deadline requirement • Has low overhead • Handles probabilistic links

25. Questions?