Link Layer Support for Unified Radio Power Management in Wireless Sensor Networks

1. Link Layer Support for Unified Radio Power Management in Wireless Sensor Networks IPSN 2007 Kevin Klues, Guoliang Xing and Chenyang Lu Database Lab. kimsh@dbserver.kaist.ac.kr SooHyung Kim

2. Contents • Introduction • Power Management Approaches • Design of the Architecture • Supporting Flexibility • Supporting Multiple Applications • Implementation • Evaluation • Conclusion

3. Introduction • Energy is a scarce resource in WSNs. • Radio power management protocol. • Reduce the power consumed • Different protocols are better suited to some applications than others. • Habitat monitoring application • Intruder detection application

4. Introduction • Multiple applications run concurrently on a single node. • Existing WSN systems still lack architectural support for flexible radio power management. • Unified radio Power Management Architecture (UPMA) • Allows different radio power management protocols to be flexibly integrated • Allows the requirements imposed by multiple applications to be coordinated

5. Power Management Approaches • Transmission power control • During communication • Control the power at which a radio transmits • Duty cycling • During idle listening • Cycle between periods of activity and sleep

6. Power Management Approaches • TDMA • Time is divided up into discrete time slots • Scheduled contention • Nodes to schedule times in order to communication • Channel polling • Independently wake up to poll the radio channel for activity • Hybrid protocols • Combine TDMA, scheduled contention, and channel polling

7. Design of the Architecture • Architecture • Defines a set of interfaces • Support for flexibly integrating different duty cycling protocols • Support coordinating the duty cycling requirements from multiple applications

8. Supporting Flexibility • Set of uniform interfaces • Between duty cycling protocols and the MAC layer

9. Supporting Flexibility • The RadioPowerControl Interface • Allows a radio to be switched between its active and sleep power states

10. Supporting Flexibility • The ChannelMonitor Interface • Be used to expose clear channel assessment(CCA) capabilities of a radio

11. Supporting Flexibility • The PreambleLength Interface • Allows a duty cycling protocol to dynamically change the length of the preamble

12. Supporting Multiple Applications • Coordinating framework • Coordinating different power management requirements from multiple applications

13. Supporting Multiple Applications • Power Management Table • Applications insert parameters • Row • Represent a single parameter type • Column • Be used to separate the values supplied by different components • Power Coordinator • Decides how to combine these parameters • Can be customized based on the requirements of the applications

14. Implementation • Radio stacks • cc1000 • cc2420 • Implementation platform • TinyOS-2.0 • Hardware platform • Mica2 • TelosB

15. Implementation • Protocols • Polling based Low Power Listening (LPL) • Simple scheduling based Simple Synchronous Sleeping (SSS) • Basic Synchronous Sleeping (BSS) • Similar to SSS

16. Implementation • Duty Cycling Protocols • LPL(Low Power Listening) • Based on polling • Allow long sleep time • The radio channel check • If there are any incoming, polling • If no packet is present, it goes back to sleep • Two different parameters • The time interval between subsequent checks for activity • The preamble length for outgoing packets

17. Implementation • Duty Cycling Protocols • SSS(Simple Synchronous Sleeping) • Based on scheduling • Be tuned through the following interface • Start of every radio’s duty cycle must be synchronized • Same duty cycle will be able to communicate with each other • Using CSMA/CA

18. Implementation • Duty Cycling Protocols • BSS(Basic Synchronous Sleeping) • Same • Time synchronization • Time duration as specified by the user • Difference

19. Implementation • Duty Cycling Protocols • BSS(Basic Synchronous Sleeping) • Has more sophisticated scheduling algorithms • When the power the radio on and off • Application can inform BSS using following interface

20. Implementation • Coordination Policies • Combine different duty cycling requirements • Power Management Table • store the parameters • Power Coordinator • Be used to combine requirements • Produce a single coherent duty cycling schedule

21. Implementation • Coordination Policies – First • Aggregate the duty cycles according to an OR policy • BSS is more appropriate than SSS

22. Implementation • Coordination Policies – Second • Backbone based duty cycling protocol • PEAS(Probing Environment and Adaptive Sleeping) • Use probing message • When nodes wake up, they send out a probing message • If they don’t hear any responses, then active • If hear one of these responses, then sleep • Remain activity until power supply has been depleted • The amount of time is able to change dynamically

23. Evaluation • Efficiency • Protocols • LPL • SSS • B-MAC implementation

24. Evaluation • Efficiency (LPL) • Throughput vs. number of nodes in a single hop • 100% duty cycle

25. Evaluation • Efficiency (LPL) • Delivery latency vs. number of hops in a fixed route multi-hop network

26. Evaluation • Efficiency (LPL) • Difference in code size

27. Evaluation • Efficiency (SSS) • Throughput vs. number of nodes • Different duty cycles • Different hardware platforms

28. Evaluation • Efficiency (SSS) • Delivery latency vs. number of hops • 50% duty cycle

29. Evaluation • Efficiency • Result • Only incurs a negligible performance penalty • The proposed MAC layer interface • Slight increase in code • More flexibility when choosing the sleep scheduling policy • Easily be implemented on top of these interface • Channel polling based protocol • Scheduled contention based protocol

30. Evaluation • Coordinating Multiple Duty Cycles • TelosB nodes • One master node • A number of slave nodes • Each slave node • Runs sensing application • Periodically sends packets to the master node • Master node • Receive packets • Run and aggregate duty cycle

31. Evaluation • Coordinating Multiple Duty Cycles • Delivery ratio

32. Evaluation • Coordinating Multiple Duty Cycles • Duty cycle

33. Evaluation • Coordinating Multiple Duty Cycles • Result • Correctly combining the duty cycles • Potentially lead to lower energy consumption

34. Evaluation • Coordinating Duty Cycles with PEAS • Total energy consumption

35. Conclusion • Unified radio power management architecture • A set of standard interfaces • Allowing different duty cycle protocols • Coordinating the duty cycling requirements • Requirements of multiple applications

36. Thank you!!