1. Wireless Sensor Networks MAC Layer
Professor Jack Stankovic
University of Virginia
2006

2. What is a MAC Protocol Medium Access Control
Coordinate actions over a shared channel (basic theme of many solutions)
Test channel to see if busy
If busy, wait
If not busy, transmit
If collision, back off and try again later

3. WSN Architecture – MAC?

4. Ad Hoc Wireless Sensor Networks
Reality –
Irregular
Multi-
cast
2 6
data 6 2

5. Outline 802.11 DCF (essential aspects) S-MAC (briefly) B-MAC
Multi-Channel MAC

6. Types of MAC Protocols Contention Based Scheduled Based
802.11b DCF (CSMA)
S-MAC, T-MAC, Z-MAC and B-MAC (all for WSN)
Scheduled Based
TDMA, NAMA, TRAMA
Multi-Channel - MMAC

7. TDMA on Wired Network A B C B C A Repeat Cycle 1 2 3 Time (Slots)1 2 3
Time (Slots)
Scales?

8. TDMA in Wireless NetworkB D E A C
/D? B C A /E
Time
Disadvantages? WSN Issues?
Optimizations?

9. 802.11 DCF Main Parts Sense channel – if not busy transmit
CTS B
Main Parts
Sense channel – if not busy transmit
Send Request to Send (RTS) – include how much time is needed for transmission – a function of the length of the message
Clear to Send (CTS) – include (repeat) how much time is needed
Send Data Packet
Data

10. 802.11 DCF Main Parts Sense channel – if not busy transmit A B
CTS B
Main Parts
Sense channel – if not busy transmit
If busy then do a random backoff in a window before trying again
Data
Interval is time slotted (e.g., 10 slots)
Use counter (choose counter value in window)
Wait until channel is clear and start decrementing
the counter as long as channel remains idle
If channel is/gets busy then freeze counter until free
When counter = 0 try RTS

11. 802.11 DCF Main Parts A B If RTS is lost
CTS B
Main Parts
If RTS is lost
Detected by no CTS
Consider this congestion
Then double the length of the window
Data

12. 802.11 DCF Main Parts Inter-frame spacing
CTS B
Main Parts
Inter-frame spacing
4 different inter-frame spacings
Enables each packet to have a different priority when contending for the channel
Data
ACK
SIFS
SIFS
PIFS
DIFS
EIFS
CTS/ACK
Increasing in
Length of
wait
DIFS
RTS

13. 802.11b

14. 802.11 DCF Main Parts Power Saving Mode – doze mode A B C Time ATIM
ATIM-ACK B
Main Parts
Power Saving Mode – doze mode C
ATIM
Window
Time
Beacon
Beacon
All nodes awake in ATIM window
A and B stay awake during entire beacon interval
If node does not send or receive ATIM it enters
Doze mode until next beacon

15. 802.11 DCF Example – no concurrency
RTS A
CTS B
Example – no concurrency
Sense channel – if not busy transmit
RTS
C responds with CTS
Data
B sends to C
A hears RTS
D hears CTS –
Both A and D
know to wait
and for how
long
A B C D
B’s Range C’s Range

16. 802.11 DCF Hidden Terminal Problem A B Use same example (B sends to C)
RTS A
CTS B
Data
Hidden Terminal Problem
Use same example (B sends to C)
D cannot hear B so what if it transmits before C sends a CTS
A B C D
B’s Range C’s Range

17. 802.11 DCF Exposed Terminal Problem B sends to A
RTS A
CTS B
Data
Exposed Terminal Problem
B sends to A
C wants to send to D, but is prevented because it heard that B is transmitting
A B C D
B’s Range C’s Range

18. Design - Fn(Types of Traffic)
Classical MACs optimize for the general case and for arbitrary patterns and workloads
WSN
Local Uni/broadcast
Nodes to sink (perhaps all in one direction)
Periodic or rare (burst communication)
Must consider energy

19. What Makes a Good MAC for WSN
Low power operation
Effective collision avoidance
Simple implementation, small code and RAM size
Efficient channel utilization at low and high data rates
Reconfigurable by network protocols
Tolerant to changing RF/networking conditions
Scalable to large numbers of nodes

20. Energy Consumption Idle Listening (largest amount) Due to collisions
Protocol overhead (control packets)
Overhearing (a node receives packets not destined for it – could have been asleep)

21. Idle Listening
When will a node receive a packet? Listen 100% of the time. Expensive!
Three Schemes
Schedule (like S-MAC)
Wake-up packet – use energy in packet
Use duty cycle in CSMA and a long preamble
Node awakes periodically and listens for preamble; if preamble there, it stays awake

22. Duty Cycle Example Preamble Stay awake W sleep sleep W Node here wants
to send packet
Nodes awake and hear
preamble
W = wake up their radio

23. S-MAC Node’s radio is asleep during the passive part of frame
Active part: communicate with neighbors and send any messages queued during the passive/sleep time
Active
Passive/Sleep
115 ms ms
Clock drift of say 500 microsecs is not a problem

24. S-MAC At each active period, nodes exchange sync info
After SYNC period, data can be sent using RTS-CTS
If a node overhears a RTS-CTS it sleeps, but will awake a short time after the neighbor has transmitted to immediately send its own data
NOTE: All communication is packed into the active part

25. S-MAC
End result: Trades saving energy for less throughput and greater latency
Good for what type of traffic patterns?
Light traffic
When latency not a problem

26. B-MAC CSMA Improves over S-MAC
Better packet delivery rates
Higher Throughput
Lower Latency
Less energy consumption
Adaptive preamble sampling scheme to reduce duty cycle and minimize idle sampling
Moves MAC functions up the stack

27. B-MAC Configurable (Key Feature!) Small core
Factor out functionality and expose to higher layers
Can be tailored to different types of networks

28. B-MAC – 4 Capabilities Clear channel assessment (CCA) Packet backoff
Link layer acks
Low power listening (LPL)
Via an interface these 4 things can be adjusted

29. B-MAC CCA Determine if the channel is clear How
Ambient noise changes over time
Use weighted moving average of samples when the channel is presumed to be idle
Use 5 to 10 samples
Note: uses 1 sample
Subject to many false alarms (i.e., protocol thinks that noise is a packet)
Wastes energy

30. B-MAC Listen (is there a real packet coming?) Check 5 samples
If outlier spike well below threshold then this is not a packet
A real packet would have too much energy to have such a “negative” spike
If no outlier, then this is a packet
THR
Real Packet

31. B-MAC Interface – turn CCA off/on
OFF -> implement a scheduling protocol above B-MAC (e.g., you know when the channel is idle or busy)(such as TDMA)
ON ->
When ready to send there is an initial backoff time
Caller can set that time, else a default
After the initial backoff, run CCA listen
Wake Up Ready to Send Backoff
CCA Listen
Time

32. B-MAC If Not Clear on CCA Listen
Use a congestion backoff time (if none provided use a default)

33. B-MAC At receiver (no packet to send) Node wakes up Turns on radio
Listens
If it hears a preamble/packet it stays awake to receive incoming packet
After packet arrives it goes back to sleep
If no packet was received after a timeout then just go back to sleep

34. B-MAC At sender CCA is used to see if channel is clear
At receiver CCA is used to see if channel is active and hence this receiver needs to stay awake

35. B-MAC LPL (low power listening)
Duty cycle the radio through periodic sampling
100 ms
Uses
CCA
No. of samples
Of radio signal
Idle listening is defined as being awake and sampling
when nothing is being sent.

36. B-MAC
Preamble length is matched to the interval that the channel is checked for activity
Check every 100 ms then preamble must be at least 100 ms
Wake up, listen, detect activity, receive the preamble, receive the message
Wake up, listen………..nothing, go back to sleep
B-MAC Interface
Check interval and preamble length are parameters

37. B-MAC Optional link layer ACK Why is this useful?
If on, there will be an ACK sent for every packet
Note: you can decide on a packet by packet basis if you want ACK or not
Why is this useful?
High priority packets want ACK
Sensing redundancy – may not need ACKs

38. B-MAC
Analytical Model for Energy Consumption (see paper if interested)
E = E(Transmit) + E(Receive) + E(Listen) + E(Data Sampling) + E(Sleeping)
E(Listen) can be reduced via MAC layer
Plus reduce collisions, max time in sleep
Lower transmit power

39. B-MAC Other points to make (about paper)
No RTS/CTS (no waste of energy)
Consider (small data) packet sizes!!!!
Micro-benchmarks
Typical needs/operations (see what they consider typical for a MAC protocol)
You may need to define micro-benchmarks for your project, if any

40. B-MAC Analytical model is validated (generalize)
Interesting tradeoffs demonstrated
Compare against state-of-art S-MAC in actual implementation
Workload: Run real Surge application (monitoring type application) – integrate BMAC and MintRoute

41. B-MAC See Figure 1 – Interfaces for BMAC in nesC
Table 1 – code and data sizes
Table 2 – Time and current consumption for various send/rcv operations

42. Single Channel MAC (up to now)
Example – Mica2 Motes
Choose either 433MHz OR 916MHz as frequency channel
Implies ONE channel
Requires ONE transceiver per node
Entire system runs with this single frequency channel

43. Multi-Channel MAC N transceivers per node – expensive
Example with 2 per node
RTS/CTS F1
Control Channel A B F2
Data Channel
50% of bandwidth for control

44. More Transceivers 2 transceivers per node N transceivers
1 for control
1 for data and reuse the control channel during data transmission phase
N transceivers
Expensive and form factor
Solutions not that practical for WSN

45. Multi-Channel MAC
Can you have multi-channel MAC with single transceiver per node?
YES
As long as that transceiver can dynamically shift between frequencies
Time
Different nodes can
Transmit simultaneously
Negotiate
For Freq.
On Default Freq

46. Negotiate on default frequency – F-0
via typical RTS/CTS
F-N
F-1
Does not require multiple radios (transceivers)
per node! (also can reuse F-0)

47. Multi-Channel MAC
Utilize multiple channels/frequencies to avoid conflicts and increase throughput
802.11b allows multiple frequencies at physical layer (14 channels, but use 3 to avoid overlap)
MAC for is designed for a single channel – not suitable for multi-channel
5 MZ
~25 MHz apart 6 1 11

48. Multi-Channel MAC MMAC – Multi-channel MAC Other solutions exist
SSCH – Slotted Seeded Channel Hopping
MMSN – Multi-Channel Mac for Sensor Networks

49. MMAC Assumptions N channels No Overlap Same Bandwidth in each channel
Single half-duplex transceiver (transmit or receive but not both)
Time to switch channels is 224 usec
Nodes are synchronized
Clock sync also needed for tracking, computing velocity, identifying time of an event, …

50. Basic Idea Beacon Interval ATIM Window Negotiate and choose Channels
Listen on default
channel
Nodes contend in here
just as for doze
mode

51. A and B might collide or both may get through during this interval
Won’t happen
B can only be using
1 channel per period C F2 X A F1 D B E F1
A, B choose
Same freq C B A
Time

52. Hidden Terminal Problem
Nodes may be listening on a different channel and not hear RTS, e.g., node C A B C D
RTS T I M E
C not on freq 2
CTS (freq 2)
RTS
Data
CTS (freq 2)
Data
Collison

53. MMAC How do we decide which node will use which channel?
Recall, every node is awake during ATIM window
Only nodes with something to send or receive need participate in this overall cycle
Beacon Interval - cycle

54. MMAC - Preferable Channel List (per node)
Records the use of channels within the range of this node (each cycle)
High – channel already chosen by this node for this interval
At most one chosen per beacon interval
Mid – channels not yet chosen
Low – already chosen by a neighbor, plus a count as how many nodes plan on using this channel this period

55. PCL Example: F1 mid F2 mid F3 mid F4 mid
Initialize at beginning of cycle (beacon interval)
(each node)

56. Rules
All channels in PCL are Mid at boot and at each beacon interval start
If S and R agree they both record High
If node overhears ATIM-ACK or ATIM-RES make channel Low if currently Mid and set counter = 1
If channel was High – stay High
If channel was Low – increment counter S R

57. PCL Example: F1 mid F2 mid F3 mid F4 mid S sends to R that
F2 is preferable;
R agrees X
High
Initialize at beginning of cycle
(each node)

58. PCL Example: F1 mid F2 mid F3 mid F4 mid If Z overhears that
S and R have chosen
F2 then it lowers
F2 to low and sets
Counter = 1 X
LOW
Ctr=1
If Z overhears that
T and R chose F2
Then Counter = 2
Initialize at beginning of cycle
(each node)

59. Scenario in ATIM Window (use default channel)
RCV (R)
Sender (S)
PCL – S
PCL -
RCV
PCL – S
Choose Channel
ATIM-ACK
Check Channel if OK
If not, wait until
Next beacon period
ATIM-RES
Neighbors of each
Overhear and update
their PCLs!

60. ATIM Window ATIM packets can collide
Random backoff before sending ATIM packet
A and B collide … B
A (so A waits)

61. Save Energy
Nodes that are not senders or receivers for the next interval can go into DOZE mode
With respect to communication
RECALL! The nodes can still be awake using their sensors, computing, generating the need to send packets, …
Wake up communication at next beacon sync point (start of beacon interval)

62. A, B, D awake this entire time
Example
ATIM
A, B, D awake this entire time C
D listens on
ONE freq
Per cycle! A F1 D B F1
Any optimizations?
C can enter Doze mode

63. Precise Rules – Choosing Best Channel
If there is a High channel in PCL then choose it (first R and then S)
If same channel is Mid in both S and R then choose it (more than 1 choose any)
If Mid on either R or S then choose it
If all are Low choose one with the lowest count
If sender cannot use channel selected it waits until next beacon period

64. Performance Increase total throughput by using multiple channels
Reduce packet delay
ATIM window – 20 ms (out of 100ms)
Note: One ATIM exchange is needed for every flow that will occur in the interval

65. ATIM Overhead
If ATIM is too small -> not all nodes with packets get to have a channel
If ATIM is too large -> wasted bandwidth
Adapt size of ATIM? (another optimization)

66. One Limitation
Node A has packets for B and C, but B and C have chosen different freq
A sends to one of them and can’t switch freq until next beacon period – wastes BW
Allow switch – another optimization (but be careful – perhaps a node wants to send to node A!)

67. MMAC Compare to 802.11 doze mode Time ATIM Window Beacon Beacon
All nodes awake in ATIM window
If A and B need to communicate then they
stay awake during entire beacon interval AND contend over the SAME frequency
If node does not send or receive ATIM it enters
Doze mode until next beacon

68. MMAC Compare to S-MAC Active Passive/Sleep 115 ms 885ms All packets
here

69. MMAC Compare to B-MAC (low power listening) 100 ms Uses CCA Listen for
Preamble to stay
awake
No. of samples
Of radio signal

70. MMAC Designed for ad hoc wireless networks Appropriate for WSN?
An exercise: go through the list of desirable features for a WSN MAC layer and see if they apply to MMAC

71. Summary MAC is a key protocol for performance Optimize MAC for WSN
Throughput
End-end delay
Energy!!!
Optimize MAC for WSN
Single and multiple frequency systems require different solutions

72. Summary - Questions What will be the impact of MMAC
How will MMAC affect other protocols in the WSN stack

73. Summary MMAC – what if Full duplex transmission
More dynamic policies for switching frequencies (in MMAC 1 freq per node per cycle)
Different BW in each channel (perhaps choose a freq that matches node BW requirements)