Transcript Versatile Low Power Media Access for Wireless Sensor Networks Joseph Polastre, Jason Hill and David Culler To appear in Sensys 2004

Versatile Low Power Media
Access for Wireless Sensor
Networks
Joseph Polastre, Jason Hill and
David Culler
To appear in Sensys 2004
Introduction
• What is BMAC?
– A configurable MAC protocol for WSNs
– Small core
• Factors out higher-level functionality
– Energy efficient
• Goals
–
–
–
–
–
–
Low Power operation
Effective collision avoidance
Simple and predictable
Small code size and RAM usage
Tolerable to changing RF/networking conditions
Scalable to large numbers of nodes
MAC design approaches
• Traditional (e.g. SMAC)
– “Black-box” design
• Users pre-configure duty cycle
• Applications rely on S-MAC to adjust its operation as things
change
• Designed (and optimized) for a set of workloads that might
not always be applicable
• Minimalistic (BMAC)
– Small core functionality: media access control
– RTS/CTS, ACKs, etc are considered higher layer
functionality (services)
• Applications can turn them on and off
– More flexible and more tunable
Clear Channel Assessment
• MAC must accurately determine if channel is
clear
– Need to tell what is noise and what is a signal
– Ambient noise is prone to environmental changes
• BMAC solution: ‘software automatic gain control’
– Signal strength samples taken when channel is
assumed to be free – When?
– Samples go in a FIFO queue (sliding window)
– Median added to an EWMA filter
– Once noise floor is established (What is a good
estimate?), a TX requests starts monitoring RSSI
from the radio
CCA: single-sample thresholding
vs outlier detection
• Common approach: take single sample,
compare to noise floor
– Large number of false negatives
• BMAC: search for outliers in RSSI
– If a sample has significantly lower energy than
the noise floor during the sampling period,
then channel is clear
CCA results
• 0=busy, 1=clear
• Packet arrives between 22 and 54 ms
• Single-sample thresholding produces several false ‘busy’ signals
Low Power Listening
• Goal: minimize listen cost
• Principles
– Node periodically wakes up, turns radio on and checks channel
• Wakeup time fixed (time you spend sampling RSSI?)
• “Check time” variable
– If energy is detected, node powers up in order to receive the
packet
– Node goes back to sleep
• If a packet is received
• After a timeout
– Preamble length matches channel checking period
• No explicit synchronization required
– Noise floor estimation used to detect channel activity during LPL
Radio powerup sequence of
operations
• Goals
– Minimize time radio is
on
– Minimize number of
times radio gets
started
– Minimize sampling
time (stage e)
LPL check interval
• Single-hop application doing
periodic data sampling
• Sampling rate (traffic pattern)
defines optimal check interval
• Check interval
– Too small: energy wasted on
idle listening
– Too large: energy wasted on
transmissions (long
preambles)
• In general, it’s better to have
larger preambles than to check
more often!
LPL and neighborhood size
• More neighbors: more
transmissions
– More time spent receiving
packets
– Less time left to go to sleep
• To find the best check
interval
– Set the reporting rate
– Estimate neighborhood
size
– Best result: check interval
that gives lowest effective
duty cycle
Experimental results: throughput
Throughput (bps)
– Not as fast when ACK or
RTS/CTS is used
– Differences less
pronounced as # of nodes
increases – (why?)
– Another issue: BMAC has
CCA, thus it backs off less
frequently (and perhaps the
backoff timer is faster)
– What about hidden
terminal without
RTS/CTS?
Throughput of a congested channel
B-MAC
B-MAC w/ ACK
1
B-MAC w/ RTS-CTS
S-MAC unicast
0.9
S-MAC broadcast
Channel Capacity
0.8
16000
14000
12000
0.7
10000
0.6
8000
0.5
0.4
6000
0.3
4000
0.2
2000
0
0
0.1
5
10
Number of nodes
15
0
20
Percentage of Channel Capacity
• “BMAC is about 4.5 faster
than SMAC-unicast”
Throughput vs power consumption
•
•
•
•
10 nodes in a neighborhood
Data must arrive within 10
seconds
Average power consumption per
node
Low data rates: SMAC is better
– Very low duty cycle
•
Power vs throughput
– SMAC: linear
– BMAC: sub-linear
•
Reason: SMAC duty cycle must
increase
– More active periods, more SYNC
periods
– Cost of resynchronizing?
•
BMAC: larger preambles at low
throughput, progressively
becoming smaller
Energy vs Latency
Effect of latency on mean energy consumption
– Reason: sync packets,
probability of multiple
schedules---less time to
sleep
500
11
10
9
3
2
1
B-MAC
S-MAC
Always On
450
400
350
Energy (mJ)
• 10-hop network
• Source sends a 100-byte
packet every 10 seconds
• SMAC: change the DC
• BMAC: choose optimal
check interval
• Poor SMAC again
performs worse...
550
300
250
200
S-MAC Default Configuration
150
100
50
0
0
2000
4000
6000
Latency (ms)
B-MAC Default Configuration
8000
10000
Conclusions
• BMAC appears to be better than SMAC
–
–
–
–
–
Easier to tune
Has better channel assessment
Doesn’t use explicit sync packets
Doesn’t use RTS/CTS/ACK if it doesn’t have to
Is smaller and less complex
• Are large preambles always good?
– Not sure, but:
• They do mention ‘cyclic packet transmissions’
• They can be turned off:
–
–
–
–
Enable LPL
Send first packet, disable LPL
Send remaining packets in a big burst
Re-enable LPL