Investigating Mac Power Consumption in Wireless Sensor Network Javier Bonny Supervised by Jun Luo

Contents Introduction Source of energy waste Existing Solution S-MAC, B-MAC Our proposition Conclusion IC-29 – LCA – 02/09/2005

Energy in WSN Battery is the most critical resource It is important to reduce the waste of energy to improve network lifetime How to improve energy efficiency Routing Mobile Base Station Energy efficient MAC protocol … IC-29 – LCA – 02/09/2005

MAC Attributes for WSN Energy efficiency Collision avoidance Basic task of a MAC protocol Scalability and adaptability Network size, node density and topology change Secondary concerns Latency Channel utilization Throughput Fairness IC-29 – LCA – 02/09/2005

Source of energy waste (MAC) Idle listening Node listens to an idle channel Overhearing Node listens for a message sent to another node Collision Two nodes emit at the same time and messages must be retransmitted Control packet overhead Required frame header and signaling to implement the MAC IC-29 – LCA – 02/09/2005

S-MAC: Coordinated Adaptative Sleeping Ye, Heidemann (USC), Estrin (UCLA) 2002 IC-29 – LCA – 02/09/2005

S-MAC Reducing the waste of energy: Idle listening: by Periodic Sleep Overhearing: by switching the radio off when the transmission is not meant for that node Collision: by using RTS and CTS IC-29 – LCA – 02/09/2005

Idle Listening avoidance Periodic listen and sleep Turn off radio when sleeping Duty cycle is fixed (application dependant) Listen Sleep Listen Sleep Listen Sleep Listen Sleep IC-29 – LCA – 02/09/2005

Choosing and Maintaining Schedules Each node maintains a schedule table that stores schedules of all its known neighbors. Periodic timer synchronization among neighbors are needed to prevent the clock drift. IC-29 – LCA – 02/09/2005

Overhearing Avoidance Idea: Sleep when neighbors talk Who should sleep? E C A B D F All immediate neighbors of sender and receiver How long to sleep? The duration field in each packet informs other nodes the sleep interval IC-29 – LCA – 02/09/2005

SMAC: Pros and Cons Pros Cons Significant low power operation Schedules sleep and transmit times to enable low-power data transfer with reasonable-latency. Cons Implementation is quite complex for WSN Significant state maintenance (schedules) Neighbors synchronization Sleep and listen period are predefined and constant (not efficient for variable traffic load) This slide can be skipped? IC-29 – LCA – 02/09/2005

B-MAC: Versatile Low Power MAC Polastre, Hill, Culler (Berkeley), 2004 IC-29 – LCA – 02/09/2005

B-MAC Unscheduled sleep Unscheduled wakeup Reduces control overhead But sender incurs greater overhead to wakeup unsynchronized receiver from sleep (long preamble) Unscheduled wakeup Keep wakeup intervals very short CSMA/CA or some other app-specific scheme can be used IC-29 – LCA – 02/09/2005

B-MAC Preamble sampling Sender sends a long preamble to overlap with the receivers “carrier sense” duration. Data transmission can use RTS/CTS or some other strategy. Receiver Sleep Sleep Data Rx Sender Preamble Data Tx IC-29 – LCA – 02/09/2005

B-MAC Receiver Sleep Sleep Data Rx Sender Preamble Data Tx Duty cycle and preamble length are tunable Preamble length ≥ Check interval Long sleeping time trades transmission latency for low power consumption (suitable for sparse transmission) A long preamble increases the power consumption of all nodes in the sender’s transmission coverage due to overhearing Sender and Receiver should be tuned together (Loose Sync) Receiver Sleep Sleep Data Rx Sender Check Interval Preamble Data Tx IC-29 – LCA – 02/09/2005

S-MAC vs B-MAC B-MAC is the MAC protocol chosen for TinyOS! S-MAC Solve Idle Listening yes Solve Overhearing no Synchronisation needed Yes less Simplicity/scalability Overall performance good better Only in the Energy efficiency point of view B-MAC is the MAC protocol chosen for TinyOS! IC-29 – LCA – 02/09/2005

Our proposition: RTS Preambling Take the best of both world Based on B-Mac + add Overhearing avoidance Idea Send useful information (RTS) in the preamble instead of a constant IC-29 – LCA – 02/09/2005

RTS Preambling IC-29 – LCA – 02/09/2005

RTS Preambling Comments Basic rule: if you hear something while listening, listen until the end Listening period (duty cycle) > DIFS What to do during SIFS period? Turn off radio or continue listening? It depends on the Radio performance! SIFS < DIFS as usual If listening something, listen until you hear a full RTS. If you are the intended recipient: send a CTS after waiting for a SIFS If not, go to sleep for period T (how to define T is not yet solved!) IC-29 – LCA – 02/09/2005

RTS Preambling IC-29 – LCA – 02/09/2005

RTS Preambling Advantage Avoid overhearing Preamble (RTSs, CTS, DIFS and SIFS) no longer than B-MAC preamble SIFS < DIFS as usual If listening something, listen until you hear a full RTS. If you are the intended recipient: send a CTS after waiting for a SIFS If not, go to sleep for period T (how to define T is not yet solved!) Broadcast Alternative: WISEMAC style (send message in preamble!) IC-29 – LCA – 02/09/2005

RTS Preambling Our proposal is good for unicast We must use an alternative for broadcast, multicast Repeat message in the preamble (like WiseMAC) SIFS < DIFS as usual If listening something, listen until you hear a full RTS. If you are the intended recipient: send a CTS after waiting for a SIFS If not, go to sleep for period T (how to define T is not yet solved!) Broadcast Alternative: WISEMAC style (send message in preamble!) IC-29 – LCA – 02/09/2005

Conclusion We think RTS Preambling could improve B-MAC performance… To do Figure out how to set the NAV Finalize alternative for broadcast Finish implementation Simulation + comparison… SIFS < DIFS as usual If listening something, listen until you hear a full RTS. If you are the intended recipient: send a CTS after waiting for a SIFS If not, go to sleep for period T (how to define T is not yet solved!) IC-29 – LCA – 02/09/2005

Conclusion That’s all Folks! Any question? IC-29 – LCA – 02/09/2005