Link Layer Support for Unified Radio Power Management in Wireless Sensor Networks IPSN 2007 Kevin Klues, Guoliang Xing and Chenyang Lu Database Lab. Soo Hyung Kim

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

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

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

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

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

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

Supporting Flexibility  Set of uniform interfaces Between duty cycling protocols and the MAC layer

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

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

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

Supporting Multiple Applications  Coordinating framework Coordinating different power management requirements from multiple applications

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

Implementation  Radio stacks cc1000 cc2420  Implementation platform TinyOS-2.0  Hardware platform Mica2 TelosB

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

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

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

Implementation  Duty Cycling Protocols BSS(Basic Synchronous Sleeping)  Same  Time synchronization  Time duration as specified by the user  Difference SSSBSS Application specify a periodic radio duty cycle Application request the radio to be turned on or off just before each transition

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

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

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

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

Evaluation  Efficiency Protocols  LPL  SSS B-MAC implementation

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

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

Evaluation  Efficiency (LPL) Difference in code size

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

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

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

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

Evaluation  Coordinating Multiple Duty Cycles Delivery ratio

Evaluation  Coordinating Multiple Duty Cycles Duty cycle

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

Evaluation  Coordinating Duty Cycles with PEAS Total energy consumption

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

Thank you!!