Title: An Energy-Efficient MAC Protocol for Wireless Sensor Networks (S-MAC)
1An Energy-Efficient MAC Protocol for Wireless
Sensor Networks (S-MAC)
- Wei Ye, John Heidemann, Deborah Estrin
2Sensor Network MAC Differences
- Energy Consumption
- Difficult to recharge
- Request long lifetime of work
3Major source of energy waste
- Collision
- Overhearing
- Control Overhead
- Idle Listening
- Listening to possible traffic that is not sent
- 50-100 energy drain compared with receiving
4Main Contributions
- Periodic listen and sleep
- Collision avoidance
- Overhearing avoidance
- Message passing
5- What is the main idea this paper propose?
- Duty Cycles
6Listen/Sleep Schedule Assignment
- Synchronizer
- Listen for a mount of time
- If hear no SYNC, select its own SYNC
- Broadcasts its SYNC immediately
Listen
A
Sleep
Go to sleep after time t
Listen for SYNC
Broadcasts
- Follower
- Listen for a mount of time
- Hear SYNC from A, follow As SYNC
- Rebroadcasts SYNC after random delay td
Listen
Sleep
Go to sleep after time t- td
td
Broadcasts
7Listen/Sleep Schedule Assignment
- B receive As schedule and rebroadcast it.
- Hear a different SYNC from C.
- Adapt both schedules
- Late sleep results to longer listening period
- Early sleep results to early wake up in the next
schedule
Listen
Sleep
Go to sleep after time t1
Listen for SYNC
Broadcasts
Listen
B
Sleep
td
Broadcasts
Only need to broadcast once
Listen
C
Nodes only rarely adopt multiple schedules
Sleep
Go to sleep after time t2
Listen for SYNC
8Listen/Sleep Schedule Assignment
- Maintaining Schedule
- Reason Clock drift
- Solution Sent SYNC periodically
- Listen interval is divided into two parts
- SYNC
- RTS/CTS/DATA/ACK
- No data transmission during synchronization
9(No Transcript)
10Collision and Overhearing Avoidance
- Collision Avoidance
- Similar to 802.11
- RTS/CTS
- Virtual carrier sense (NAV)
- Physical carrier sense
- Overhearing Avoidance
- Problem A node picks up packets that are
destined to other nodes - Solution Interfering nodes go to sleep when
overhear RTS, CTS or ACK.
11Example (To sleep, or not to sleep, this is a
question)
- A is talking to B
- D receives CTS from B -gt sleep
- Ds transmission will collide Bs
- C receives RTS from A -gt sleep
- C cannot receive CTS/DATA from E
- All immediate neighbours of transmitting node
sleep - How long should they sleep?
- C and D update their NAV
- Keeping sleeping until NAV count down to zero
12Message Passing
- How to transmit long message?
- One long packet
- Many small packets with RTS/CTS/DATA/ACK for each
- S-MAC Divide into fragments, transmit all in
burst - RTS/CTS reserve medium for the entire sequence
- Fragment-errors recovery with ACK - no control
packets for fragments
13Acknowledgment to Pro. Jun Yang
Why use ACK?
14Hidden Terminal Example
15Why utilize message passing?
16Message Passing
- Advantages
- Energy saving immediate node go to sleep when
sense transmissions - Reduces control overhead by sending multiple ACK
- Disadvantage
- Node-to-node fairness reduces
- However, message-level latency reduces
17Experiment
Listen time 300ms Sleeping time 1s SYNC every
13s (10 listen/sleep period) A, B, C use the same
schedule
18Energy save due to periodic sleep
802.11
Energy save due to avoiding overhearing by using
message passing
OA
SMAC
Heavy Traffic
Light Traffic
19OA In light traffic status, sources nodes keep
listening for quite a long time
20SYNC overhead
Overhearing avoidance still benefit
Heavy Traffic
Light Traffic
21Discussion
- What is the tradeoff by using duty cycles?
- How can we make the schedule more intelligent?
22- Acknowledgment to Jun Yang (CS, Duke) and Romit
Roy Choudhury