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

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

3. 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

4. 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

5. 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

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

7. 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

8. 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

9. 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

10. 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

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. 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

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

19. 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

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

21. 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

22. 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

23. 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

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