Rate-Controlled Reliable Transport for Wireless Sensor Networks

1. Rate-Controlled Reliable Transport for Wireless Sensor Networks Jeongyeup Paek, Ramesh Govindan

2. Reliability: Sensor Network Applications • Structural Health Monitoring • Wisden, NetSHM • Tenet-Wisden deployment at Vincent Thomas Bridge • Imaging • Tenet-Cyclops deployment at James Reserve (Tenet: [Gnawali et.al., Sensys’06]) Motivation Design Goals Design Evaluation Conclusion

3. Rate-Control: Congestion Collapse • Four seasons building deployment (Wisden, 2004) • Sensors measured vibrations and transmitted it to a base station, over multiple hops • Preconfigured rates for each flow • Led to congestion • Some packets took more than an hour to recover, while collecting 10_minutes worth of vibration data • Was not anticipated during lab tests Loss recovery latency Motivation Design Goals Design Evaluation Conclusion

4. Rate-Controlled Reliable Transport RCRT is a protocol that reliably transports sensor data from many sources to one or more sinks without incurring congestion collapse App. Sink Sink Motivation Design Goals Design Evaluation Conclusion

5. Design Goals Reliable end-to-end delivery Network efficiency Support concurrent applications Flexibility Minimal sensor functionality Robustness Motivation Design Goals Design Evaluation Conclusion

6. ri r’i-1 r’j r’… r’i+1 r’… r’1 Protocol Overview Congestion detection Sink Rate adaptation ri r’i Rate allocation End-to-end loss recovery Placing rate control functionality at the sink allows the system to have a global view of the network, resulting in efficiency and flexibility Data transmission Connection establishment source node Motivation Design Goals Design Evaluation Conclusion

7. Reliable end-to-end delivery Network efficiency Support concurrent applications Flexibility Minimal sensor functionality Robustness End-to-end Loss Recovery • Loss recovery mechanism • Negative ack. • End-to-end retransmission • Cumulative ack. • RCRT uses loss-recovery information for congestion detection Motivation Design Goals Design Evaluation Conclusion

8. Ci L U Congestion Detection • “The network is not congested as long as end-to-end losses are repaired quickly enough” Loss recovery latency • Use ‘time to recover loss’ as congestion indicator • Ci is the average number of RTTi’s to recover a loss from node i. • Simple thresholding technique on Ci. Allow losses, as long as they are recovered quickly enough. Use the fact that sink has complete view of network. Under-utilized if Ci ≤L, ∀i Congested if Ci≥ U, ∃i Motivation Design Goals Design Evaluation Conclusion

9. Reliable end-to-end delivery Network efficiency Support concurrent applications Flexibility Minimal sensor functionality Robustness Rate Adaptation • “Having a global view of the network allows more efficient rate adaptation.” • AIMD on total aggregate rate of all the flows observed by sink: • Increase • Decrease • How is M(t) determined? Motivation Design Goals Design Evaluation Conclusion

10. r / p r(1-p) / p Adaptive Multiplicative Decrease: M(t) Expected foward traffic rp received r Source Sink p r (1-p) lost.. Expected reverse traffic Expected total traffic M(t) is larger than 0.5 for p ≥ 0.67 Motivation Design Goals Design Evaluation Conclusion

11. Does RCRT avoid congestion collapse? Regardless of r’(t), r’(t+1) is always below capacity. congestion M(t) is more aggressive when r’(t) is higher Motivation Design Goals Design Evaluation Conclusion

12. Reliable end-to-end delivery Network efficiency Support concurrent applications Flexibility Minimal sensor functionality Robustness Rate Allocation • “Having a global view of the network allows RCRT to decouple rate allocation from adaptation” • Flexible use of different rate allocation policies • Minimal sensor functionality • Assign ri(t) to each flow based on the associated rate allocation policy P • Demand-proportional (Weighted) • Demand-limited • Fair Can implement and use different kind of policies without having to modify anything on the sensors Motivation Design Goals Design Evaluation Conclusion

13. Evaluation 32 4 31 38 40 39 37 36 35 34 33 3 30 5 29 6 2 21 1 20 7 28 27 25 19 18 16 14 13 12 9 8 26 24 23 22 15 11 17 10 4th fl. 40-node telosb testbed A snapshot of routing tree during an experiment Motivation Design Goals Design Evaluation Conclusion

14. RCRT Results efficient AIMD fair goodput …and of course, 100% reliable packet delivery Motivation Design Goals Design Evaluation Conclusion

15. Efficiency RCRT achieves 88% of sustainable reliable and fair rate Reliable transport without congestion control RCRT Motivation Design Goals Design Evaluation Conclusion

16. Reliable end-to-end delivery Network efficiency Support concurrent applications Flexibility Minimal sensor functionality Robustness App.1 App.2 Demand-limited Demand-proportional Sink.1 Sink.2 Sensors 2 applications, 4 sets of flows Robustness and Flexibility Demand-limited App.2 starts Tiered Network App.1 App.1 App.2 App.2 Two concurrent applications with two different rate allocation policies ran successfully on a tiered multi-sink network. Demand-limited Demand-proportional App.2 ends Sink.1 Sink.1 Sink.2 Sink.2 App.1 starts 2 applications, 4 sets of flows (2 flows per node) App.1 ends Demand-proportional Sensors Sensors Sensors Sensors 2 different sets of flows per application RCRT is robust to node joins & leaves, (and routing dynamics) Motivation Design Goals Design Evaluation Conclusion

17. Comparison with IFRC When we use software ack. and promiscuous mode on RCRT… RCRT achieves x 1.7 the rate achieved by IFRC Motivation Design Goals Design Evaluation Conclusion

18. Related Work Distributed Cong. Control Centralized Cong. Control No Congestion Control Reliable Flush RCRT Wisden, Tenet, RMST Non- reliable IFRC, Fusion, CODA QCRA, ESRT RBC Motivation Design Goals Design Evaluation Conclusion

19. Conclusion • RCRTis a reliable transport protocol for wireless sensor networks Centralized congestion control provides better perspective into the network, which enables better aggregate control of traffic and affords flexibility in rate allocation Motivation Design Goals Design Evaluation Conclusion

20. Future Work • Design • Inter-sink cooperation • Providing excess bandwidth to unconstrained nodes, and isolating exceptionally poorly connected links. • Application’s behavior to rate-adaptive transport • Implementation & deployment • Integration into Tenet • James Reserve deployment (Tenet/Cyclops) Thank youhttp://enl.usc.edu Motivation Design Goals Design Evaluation Conclusion