An Energy-Efficient MAC Protocol for Wireless Sensor Networks
Wei Ye, John Heidemann, Deborah Estrin
-- Adapted the authors’ Infocom 2002 talk
Introduction
Wireless sensor network• Special ad hoc wireless network• Large number of nodes w/ sensors & actuators• Battery-powered nodes energy efficiency• Unplanned deployment self-organization• Node density & topology change robustness
Sensor-net applications• Nodes cooperate for a common task• In-network data processing
Medium Access Control in Sensor Nets
Important attributes of MAC protocols1. Collision avoidance2. Energy efficiency3. Scalability in node density4. Latency5. Fairness6. Throughput7. Bandwidth utilization
Primary
Secondary
Major sources of energy waste• Idle listening
Energy consumption of typical 802.11 WLAN cardsidle:receive:send — 1:1.05:1.4, 1:2:2.5 (Stemm
1997)Example: directed diffusion (Intanagonwiwat 2000)
Energy Efficiency in MAC
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0 50 100 150 200 250 300
Ave
rage
Dis
sipa
ted
Ene
rgy
(Jou
les/
Nod
e/R
ecei
ved
Eve
nt)
Network Size
Diffusion
Omniscient MulticastFlooding
00.0020.0040.0060.0080.01
0.0120.0140.0160.018
0 50 100 150 200 250 300
Ave
rage
Dis
sipa
ted
Ene
rgy
(Jou
les/
Nod
e/R
ecei
ved
Eve
nt)
Network Size
Diffusion
Omniscient Multicast
Flooding
Over always-listening MAC Over energy-aware MAC
Reminder: IEEE 802.11 MAC
Very popular wireless MAC protocol Two modes: DCF (distributed coordination function) & PCF
(point coordination function) DCF is based on CSMA/CA ≈ CSMA + MACA
• RTS-CTS-DATA-ACK• Physical carrier sensing + NAV (network allocation
vector) containing time value that indicates the duration up to which the medium is expected to be busy due to transmissions by other nodes
• Every packet contains the duration info for the remainder of the message
• Every node overhearing a packet continuously updates its own NAV for virtual carrier sensing
IFS (inter frame spacing)• Short IFS (SIFS), PCF IFS (PIFS), DCF IFS (DIFS),
Extended IFS (EIFS)
Big problem with existing wireless MACs
Idle listening• Does anybody send me a RTS?• Does anyone send CTS to my neighbor
which I want to communicate with?• Huge energy consumption!
PAMAS (Power Aware Medium Access with Signaling)• Separate radio channel for RTS/CTS• Sleep for the duration of the transmission
indicated in the control packets S-MAC aims to achieve this without requiring a separate channel for RTS & CTS
Idle listening in 802.11
RTS & CTS only reserves the medium for the first data fragment & the first ACK
The 1st fragment & ACk reserves the medium for the 2nd fragment and so on
After overhearing a fragment or an ACK, a neighboring node knows that there is one more fragment to be sent • It has to keep listening until all the fragments are sent • Promote fairness; If the sender fails to get ACK after
sending a fragment, it must give up the transmission and recondtend for the medium
• For in-network processing, an entire message is needed in sensor networks 802.11 may cause a largee delay
Major sources of energy waste (cont.)• Idle listening
Long idle time when no sensing event happens
• Collisions• Control overhead• Overhearing
Reduce energy consumption from all above sources
Combine benefits of TDMA + contention protocols
Energy Efficiency in MAC
Common to all wireless
networks
Dominant in sensor nets
Sensor-MAC (S-MAC) Design
Tradeoffs
Major components in S-MAC• Periodic listen and sleep• Collision avoidance• Overhearing avoidance• Massage passing
Latency
FairnessEnergy
Periodic Listen and Sleep
Problem: Idle listening consumes significant energy
Solution: Periodic listen and sleep
• Turn off radio when sleeping• Reduce duty cycle to ~ 10% (200ms on/2s
off)
sleeplisten listen sleep
Latency Energy
Periodic Listen and Sleep
Schedules can differ
• Prefer neighboring nodes have same schedule— easy broadcast & low control overhead
Border nodes: two schedules broadcast twice
Node 1
Node 2
sleeplisten listen sleep
sleeplisten listen sleep
Schedule 2
Schedule 1
Each nodes has a schedule table- Stores the schedules of all its known neighbors
1. Listens for a certain amount of time - If it doesn’t hear a schedule, it becomes a synchronizer - It randomly chooses a schedule and broadcast it in SYNC message- SYNC message indicates that it will go to sleep after t seconds
Periodic Listen and Sleep - Choosing and Maintaining Schedules
2. If the node receives a schedule before choosing its own schedule, it follows that schedule
- follower- waits for a random delay td and re-broardcasts this schedule, indicating that it will sleep in t – td
3. If a node receives a different schedule after it selects and broadcast (border node)
- adopts both schedules - less time to sleep - consume more energy
Periodic Listen and Sleep - Choosing and Maintaining Schedules
Periodic Listen and Sleep - Schedule Synchronization
Remember neighbors’ schedules — to know when to send to them
Each node broadcasts its schedule for multiple periods of sleeping and listening• Update period can be long, e.g., tens of
secondsRe-sync when receiving a schedule
updateSync packets also serve as beacons for
new nodes to join a neighborhood
Listen
For SYNC For RTS Sleep
Receiver
Sender 1
Sender 2
Sender 3
Sleep
SYNC
CS
CS
CS CS
SYNC RTS
RTS
Send data if CTS received
Send data if CTS received
Figure 2. Timing relationship between a receiver and different senders
Periodic Listen and Sleep
Collision Avoidance
Problem: Multiple senders want to talkOptions: Contention vs. TDMASolution: Similar to IEEE 802.11 ad hoc
mode (DCF)• Physical and virtual carrier sense• Randomized backoff time• RTS/CTS for hidden terminal problem• RTS/CTS/DATA/ACK sequence
Overhearing Avoidance
Problem: Receive packets destined to others• In 802.11, each node keeps listening to all transmissions from its
neighbors for virtual carrier sensing• Each node should overhear a lot of packets not destined to itself
Solution: Sleep when neighbors talk• Basic idea from PAMAS (Singh, Raghavendra 1998)• But S-MAC only uses in-channel signaling
Who should sleep?• All immediate neighbors of sender and receiver• S-MAC lets interfering nodes go to sleep after they hear an RTS or
CTS DATA packets are normally much longer than control packets
How long to sleep?• The duration field in each packet informs other nodes the sleep
interval• After hearing the RTS/CTS packet destined to a node, all the other
immediate neighbors of both the sender and receiver should sleep until the NAV becomes zero
Message Passing
Problem: Sensor net in-network processing requires entire message
Solution: Don’t interleave different messages• Long message is fragmented & sent in burst• RTS/CTS reserve medium for entire message• Fragment-level error recovery — ACK
— Extend Tx time and re-transmit immediately if no ACK is received
Other nodes sleep for whole message time Fragmentation in IEEE 802.11
• No indication of entire time — other nodes keep listening• If ACK is not received, give up Tx & recontend for medium —
fairness
FairnessEnergy
Msg-level latency
Energy Savings vs. Increased Latency
General delay factors• Carrier sensor delay• Backoff delay• Transmission delay• Propagation delay• Processing delay• Queuing delay
Sleep delay: S-MAC specific• A sender has to wait until the receiver
wakes up
Sleep delay and Relative energy savings
Average sleep delay on the sender is 0.5Tframe = 0.5(Tlisten + Tsleep)
Relative energy saving• Es = Tsleep/Tframe = 1 – Tlisten/Tframe
Duty
Cycle
Implementation on Testbed Nodes
PlatformMotes (UC Berkeley)
8-bit CPU at 4MHz,8KB flash, 512B RAM916MHz radio
TinyOS
Compared MAC modules1. IEEE 802.11-like protocol w/o sleeping2. Message passing with overhearing
avoidance3. S-MAC (2 + periodic listen/sleep)
Experiments
Topology and measured energy consumption on source nodes
Source 1
Source 2
Sink 1
Sink 2
• Each source node sends 10 messages
— Each message has 400B in 10 fragments
• Measure total energy over time to send all messages
0 2 4 6 8 10
200
400
600
800
1000
1200
1400
1600
1800Average energy consumption in the source nodes
Message inter-arrival period (second)
En
erg
y co
nsu
mp
tion
(m
J)
802.11-like protocol Overhearing avoidanceS-MAC
Conclusions
S-MAC offers significant energy efficiency over always-listening MAC protocols
Sleep delay can be accumulated in intermediate hops Potential problem for real-time sensing in multiple environments
Future Plans• Measurement of throughput and latency
Throughput reduces due to latency, contention, control overhead and channel noise
• Experiments on large testbeds~100 Motes, ~30 embedded PCs w/ MoteNIC
URL: http://www.isi.edu/scadds/
Questions?