Wireless Sensor Networks MAC Layer

1
Wireless Sensor NetworksMAC 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
• 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
C
B
A
Repeat Cycle
0
1
2
3
Time (Slots)
Scales?
8
TDMA in Wireless Network
B
D
E
A
C
/D?
C
B
A
/E
Time
Disadvantages? WSN
Issues? Optimizations?
9
802.11 DCF
RTS
A
B
CTS

• 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
RTS
A
B
CTS

• 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
RTS
A
B
CTS

• 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
RTS
A
B
CTS

• 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
ATIM
A
B
ATIM-ACK

• 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
RTS
A
B
CTS

• 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
Bs Range Cs Range
16
802.11 DCF
RTS
A
B
CTS
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
Bs Range Cs Range
17
802.11 DCF
RTS
A
B
CTS
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
Bs Range Cs 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

• Nodes 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 885 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 802.15.4 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 -gt implement a scheduling protocol above
  B-MAC (e.g., you know when the channel is idle
  or busy)(such as TDMA)
• ON -gt
• 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
• 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
• 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 802.11 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 802.11 doze mode
51
A and B might collide or both may get
through during this interval
Wont happen B can only be using 1 channel per
period
C
F2
X
F1
A
D
B
F1
E
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
C not on freq 2
T I M E
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

R
S
57
PCL
Example
F1 mid F2 mid F3 mid F4 mid
S sends to R that F2 is preferable R agrees
High
X
Initialize at beginning of cycle (each
node)
58
PCL
Example
If Z overhears that S and R have chosen F2 then
it lowers F2 to low and sets Counter 1
F1 mid F2 mid F3 mid F4 mid
LOW Ctr1
X
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
Example
ATIM
A, B, D awake this entire time
C
D listens on ONE freq Per cycle!
F1
A
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 -gt not all nodes with
  packets get to have a channel
• If ATIM is too large -gt 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 cant 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

ATIM Window
Time
Beacon
Beacon
All nodes awake in ATIM window If A and B need
to communicate then they stay awake during entire
beacon interval ANDcontend 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
• 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)