Chapter 4

Chapter 4
MAC protocols in WSNs

MSc. Nguyen Khanh Loi
nkloi@hcmut.edu.vn
2/2021
MSc Nguyen Khanh Loi
Goal of this lecture
❖ Controlling when to send a packet and when to listen for a packet

are perhaps the two most important operations in a wireless
network
❖ This lecture discusses schemes for this medium access control that
are
✓ Suitable to mobile and wireless networks
✓ Emphasize energy-efficient operation
Wireless Sensor Networks 2 MAC protocols in WSNs

Wireless sensor network
Storage Monitoring
Analysis
Processing
Internet
Sensor network 1 Sensor network 2

OSI model

WSN model
App
Tran
Net
Adaptation
Media Management Control

Remote Media Link Stats Local Media
Link Data Ack

Addr Period
Neighbor Table
Phase Pending RSSI PRR

Sample Period
Sample Phase
Phy

Data in WSN
Sensor A Sensor B
Raw data
Network layer (routing)
Data link/MAC layer
Physical layer
time

Introduction: MAC protocols
2
7
3 9
4
1 8
6

Medium Access Control
❖ Multiple network/sensor nodes share the same channel

(communication medium) for transmitting their packets
❖ MAC protocols regulate access to the common channel, i.e., tells the
network node when to send a packet and to listen for a packet
❖ Challenges when designing MAC protocols for a wireless channel
✓ Sensor networks usually operate in unlicensed ISM band –
communication affected by significant noise and interference
✓ Sender may not observe interference at the receiver
✓ High error rates due to wireless channel
✓ Node cannot generally send and receive at the same time
✓ Sending, receiving and listening on the channel consumes
significant energy

Requirements for energy-efficient MAC
❖ Recall
✓ Transmissions are costly (in terms of consumed energy)
✓ Receiving about as expensive as transmitting
✓ Only listening (not transmitting nor receiving) is also expensive
❖ Energy problems
✓ Collisions - wasted energy when two packets collide
✓ Note that collisions happen at the receiver
From 2 to 3 From 5 to 3
2 3 5

❖ Energy problems
✓ Overhearing – wasted energy in receiving a packet destined for
another node
❖ Example:
✓ Node 2 overhears the packet destined for node 5
✓ Node 3 uses an omnidirectional antenna (the broadcast nature of
wireless)
2 3 5

❖ Energy problems
another node
✓ Idle listening - sitting idly and trying to receive when nobody is
sending
❖ Example:
✓ Node 5 is listening while 2 and 3 do not transmit
2 3 5

❖ Energy problems
another node
✓ Idle listening - sitting idly and trying to receive when nobody is
sending
✓ Protocol overhead – how many extra bits to regulate access to
the channel

Design criteria for MAC
❖ Energy problems
✓ Overhearing – wasted energy in receiving a packet destined for another node
✓ Idle listening - sitting idly and trying to receive when nobody is sending
✓ Protocol overhead – how many extra bits to regulate access to the channel
❖ Design criteria
✓ Minimize collisions
✓ Minimize overhearing
✓ Minimize idle listening
✓ Minimize protocol overhead
❖ How to solve so many hard problems at once?
✓ There is no universal solution, we need to make certain tradeoffs

Main options for MAC protocols
Wireless medium access
Centralized Distributed
Schedule- Contention- Schedule- Contention-

based based based based

Centralized medium access control
❖ Idea: A central station controls when a node may access the
medium/channel
✓ Examples: Centralized computation of TDMA (Time
Division Multiple Access) schedules, FDMA
(Frequency Division Multiple Access), ...
✓ Advantage: Simple, quite efficient (e.g., no collisions)
✓ Disadvantage: Burdens the central station and not so
much the network nodes
❖ Not directly feasible for non-trivial wireless network sizes
❖ Can be quite useful when network is somehow divided into
smaller groups that can be controlled centrally – e.g.,
Bluetooth piconets
round
2 3 5 2 3 5
time
slot 2 3 5

Distributed medium access control
❖ Idea: The network nodes attempt to coordinate access to the

common channel by themselves (without any intervention by
external/central entities)

Main options for MAC protocols


Schedule-based MAC protocols
❖ A schedule exists, regulating which participant may use which resource at

which time
✓ Typical resource: a frequency band
❖ Schedule can be fixed or computed on demand
❖ Usually, collisions, overhearing, idle listening are no issues
❖ But: requires tight time synchronization + wasted slots
round
2 2 2
time
2
3 3
time
3
slot wasted slot

Contention-based MAC protocols
❖ Idea: We accept the risk of colliding packets here and there with the hope that
the coordination overhead required by schedule-based MACs can be
saved/eliminated
✓ In other words, occasional packet re-transmissions could be more
efficient than the coordination overhead in schedule-based MACs
✓ Typical involves some form of randomization when transmitting

Distributed contention-based MAC


❖ Basic ideas for a distributed MAC

❖ ALOHA (no good in most cases, nRF24L01 from labs uses this protocol)
❖ Slotted ALOHA (no good in most cases)
❖ Listen before talk
✓ Carrier Sense Multiple Access – CSMA
✓ Carrier Sense Multiple Access with Collision Avoidance – CSMA/CA
(the basis for your WiFi network)
2 1 3


✓ ALOHA protocol (no good in most cases)
▪ Transmit immediately when data ready
▪ Do not try to coordinate transmissions with other nodes
(anarchy)
2 1 3
data ready data ready
2 2
3 3 time
collision successful successful

transmission transmission


✓ ALOHA protocol (no good in most cases)
• Transmit immediately when data ready
• Do not try to coordinate transmissions with other nodes (anarchy)
❖ The expected channel utilization with ALOHA is around 18%
✓ Thus, the expected packet loss when multiple nodes compete for the same
channel is greater than 80% (Under the assumption that data arrive according to a
Poisson distribution)
2 2
3 time
data ready
collision window for packet 3

(if another transmission starts
within this window we have a collision)


✓ Slotted ALOHA protocol (no good in most cases)
• The time is subdivided in timeslots (slot accomodates a packet)
• A node is allowed to transmit only at the beginning of a slot
• Nodes must be synchronized
2 1 3
2 2
slot 3 3 time
successful successful collision



✓ Slotted ALOHA protocol (no good in most cases)
• The time is subdivided in timeslots (slot accomodates a packet)
• A node is allowed to transmit only at the beginning of a slot
• Nodes must be synchronized
❖ The expected channel utilization of slotted ALOHA is around 36%
✓ This is twice what we get with regular ALOHA
✓ The synchronization reduces the probability of collisions
data ready
2
slot 3 time
data ready
collision window for packet 3

(if another transmission starts
within this window we have a collision)


✓ Listen before talk (Carrier Sense Multiple Access - CSMA)
• If a node senses an ongoing transmission, it delays its transmission
• Nodes do not have to be synchronized
• Much better channel utilization compared to ALOHA and slotted ALOHA
2 1 3
CS (sense the channel) CS
2 2
3 3 time
CS (sense the channel) CS
successful successful collision



✓ Listen before talk (Carrier Sense Multiple Access - CSMA)
✓ Potential issue when two nodes synchronized on a transmission of a third node
✓ Q: How can we potentially resolve this issue?
CS (sense the channel) CS CS

CS
data ready
1 2 2 2
3 3 3 time
data ready
CS CS CS CS
successful collision collision collision

transmission

❖ Listen before talk in real world

✓ Q: How can we resolve collisions between synchronized nodes?
✓ A: Wait a random time (random backoff) before trying to access the channel
(Carrier Sense Multiple Access with Collision Avoidance - CSMA/CA)
✓ IEEE 802.11 protocol (your WiFi)
✓ IEEE 802.15.4 (used in ZigBee-based sensor networks)
random
CS backoff CS
data ready
1 2
3 time
data ready random random

CS backoff CS backoff CS
successful successful

Simplified IEEE 802.11 MAC (WiFi)
Freezes the counter

DIFS DIFS
and delays sending
Computer A Data NAV

Backoff Backoff
SIFS SIFS
Access Point/Gateway ACK ACK
Computer B NAV Data

Backoff
Time
B delays sending
Note:
• DIFS: Distributed Inter-Frame Spacing
• SIFS: Short Inter-Frame Spacing
• Backoff: a random number from the set {1,2,…, CW} - is expressed in short time (time
slot); CW is the maximum duration Backoff.
• NAV (Network Allocation Vector) – duration of current transmission

Hidden and exposed terminal problems
MAC protocols for wireless (sensor) networks need to address two important
challenges
✓ Hidden terminal problem
✓ Exposed terminal problem

Hidden terminal problem
❖ In the shown network scenario, node 2 is not aware of node 3 (they do not
fall in the transmission ranges of each other
❖ Nodes 2 and 3 are said to be hidden from each other
collision at node 1
2 to 1 3 to 4
2 1 3 4

Exposed terminal problem
❖ Node 3 is exposed to node 1 (and vice versa)

✓ Node 1 cannot send due to CSMA MAC protocol (listen before talk)
✓ In principle, 1 -> 2 and 3 -> 4 could transmit at the same time without
collisions
node 3 hears transmission

by node 1 and refraines
from transmission
1 to 2 3 to 4
2 1 3 4

Handling the hidden terminal problem
1 2 3 4
In the context of wireless sensor networks, the hidden
terminal problem is more serious than the exposed terminal
✓ Sensors are battery operated, and the hidden terminal
RTS
problem results in large number of collisions and re-
transmissions
CTS
✓ Idea: A receiver informs potential interferers before a
reception is on-going
✓ One simple and real-life mechanisam is based on
during this period

RTS/CTS control packets
during this period

Will be quite
Will be quite
• Sender first sends RTS (Request to Send) packet Data
• Receiver responds with CTS (Clear to Send)

packet
• Potential interferers overhear either RTS or CTS
and stay quite during the transmission of the data
ACK
packet
• RTS/CTS control packets are much shorter than
regular packets carrying data
Handling the hidden terminal problem
❖ RTS/CTS mechanism makes sense only if the size of control packets significantly
smaller than the size of data packets. Why?
❖ RTS/CTS help but do not completelly solve the problem
1 2 3 4
RTS
CTS
RTS
CTS
Data
Data
ACK

Energy-efficient MAC protocols
❖ Sensor nodes are usually battery-operated, therefore MAC protocols must be energy
efficient
✓ Indeed, sending or receiveing over a radio channel is very costly operation
(in terms of energy consumption)
✓ Since MAC protocols have a full control over when to send or receive, the
design of MAC protocols can contribute significantly to the energy consumption
❖ CSMA/CA MAC protocols are simple and robust but
✓ Require a node to be awake most of the time and listen for channel activity
✓ This can quickly exhaust the energy of on a sensor node (think a bit about your
mobile phone battery when WiFi is switched on)
✓ We need a better solution
❖ Solution:
✓ Put a node to sleep whenever possible (use low duty cycle)
✓ How to coordinate access to common channel?

Sensor-MAC (S-MAC) protocol
❖ S-MAC protocol allows nodes to go to sleep

• It is a distributed contention-based MAC protocol
• Sensor nodes periodically awake and perform their communication
• This is excellent from the energy-consumption point of view, yet how can two or
more sensors nodes exchange data/packets with each other?
cycle
active sleep
2 2 2
time
2
3 3 3
time
3

❖ Idea: To enable two sensor nodes to exchange packets, S-MAC ensures that
neighboring nodes turn on simultaneously
✓ A node wakes up (first time) and listens on the channel for some time.
✓ If the node does not receive anything, it chooses its own schedule according to
which it will periodically go to sleep (and wake up)
✓ The node sends its own schedule to the channel
✓ The node goes to sleep
✓ Next time it wakes up, the node will first send its own schedule
send
wake up schedule go sleep wake up wake up wake up
2 2 2 2
time
2 nothing
received

❖ Idea: To enable two sensor nodes to exchange packets, S-MAC ensures that
neighboring nodes turn on simultaneously
✓ If a new/second node receives a schedule, it will join this schedule (at this point
the two nodes are in sync and will wake up together)
receive
wake up schedule go sleep
2 1 1 1
time
1
send
wake up schedule go sleep
2 2 2 2
time
2 nothing receive
received wake up schedule sleep wake up
2 3 3
time
3
sensor nodes get synchronized

❖ Once synchronized, each node follows its own schedule
✓ It wakes up, sends out its schedule for re-synchronization
✓ Uses CSMA and RTS/CTS handshake to send receive packets
✓ Network allocation vector (NAV) duration is the transmission time required by
frame, which is the the time for which the channel will be busy
receive
wake up schedule go sleep sleep
2 1 CTS ACK 1
time
1
send
wake up schedule go sleep sleep
2 2 RTS Data 2
time
defer access
2 nothing sleep
received
NAV (Base on RTS)
sleep
NAV (Bo CTS)

time
Other

❖ Maintaining Synchronization
✓ Clock drifts – not a major concern (listen time = 0.5s – 105 times longer than
typical drift rates)
✓ Need to mitigate long term drifts – schedule updating using SYNC packet
(sender ID, its next scheduled sleep time – relative);
✓ Listen is split into 2 parts – for SYNC and RTS/CTS
✓ Once RTS/CTS is established, data (if available) sent in sleep interval
Active/Listen
Sleep For SYNC For RTS For CTS Sleep

❖ Example Scenarios

❖ Example Scenarios
DATA

❖ Sending a long message

✓ As a single packet: increase cost of retransmission for message corruption

Drawbacks of S-MAC
❖ Active (Listen) interval – long enough to handle to highest

expected load
✓ If message rate is less – energy is still wasted in idle-
listening
❖ S-MAC fixed duty cycle – is NOT OPTIMAL

T-MAC: Timeout-MAC
❖ Listen for a short time after awake period.

❖ Sleeps if IDLE.
❖ Improves on S-MAC by shortening the awake period if IDLE.
❖ For variable payloads, T-MAC uses ~20% of energy used in S-MAC.
❖ Adaptive duty cycle
❖ A node is in active mode until no activation event occurs for time TA (Traffic Aware)
✓ Periodic frame timer event, receive, carrier sense, send-done, knowledge of other
transmissions being ended
❖ Communication ~ S-MAC
❖ Frame schedule maintenance ~ S-MAC
Active Active Active
Sleep Sleep
TA TA TA

T-MAC: Timeout-MAC
❖ Requirement: a node should not sleep while its neighbors are communicating,
potential next receiver
❖ TA > C+R+T
✓ C – Contention interval length (Nodes wait for a random time within a
contention interval after detecting a collision.)
✓ R – RTS packet length;
✓ T – Turn-around time, time between the end of RTS and start of CTS
❖ TA = 1.5 * (C+R+T)
TA
Contention interval RTS
R
CTS
T
LPL: Low-Power Listening
❖Goal: minimize listen cost
❖RX: Clear Channel AssessmentCCA to sample, ON to receive packet
✓ Extremely short CCA (500 us)
❖Tx uses short ‘chirp’ messages as preamble
✓ Addressing → minimizes overhearing cost
✓ Data time → receive cost independent of sample period
❖Nodes wake up for a short period and check for channel activity.
✓ Return to sleep if no activity detected.
❖If a sender wants to transmit a message, it sends a long preamble to make sure that
the receiver is listening for the packet.
✓ Preamble has the size of a sleep interval
❖Very robust
✓ No synchronization required
✓ Instant recovery after channel disruption
preamble data
listen
channel sniff

B-MAC
❖ Uses local schedules
❖ Send preamble that is slightly longer than the sleep period.
❖ Long preamble assures that the neighbor will receive packet.
❖ Suffers from overhearing problem.
❖ During awake period, node samples medium & if a preamble is detected it remains
awake to receive the data.
Target
address
preamble data
listen data
listen

X-MAC
❖ Short preamble
✓ Reduce latency and reduce energy consumption
❖ Target in preamble
✓ Minimize overhearing problem.
❖ Strobed preamble
✓ Reduces latency for the case where destination is awake before preamble
completes.

X-MAC vs LPL: Operations

ContikiMAC

ContikiMAC: Unicast and Broadcast

ContikiMAC: Phase Lock


Chapter 4 - MAC Protocols in WSNs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 4 - MAC Protocols in WSNs

Uploaded by

Copyright:

Available Formats

MAC protocols in WSNs

❖ Controlling when to send a packet and when to listen for a packet

Wireless Sensor Networks 2 MAC protocols in WSNs

Sensor network 1 Sensor network 2

Wireless Sensor Networks 3 MAC protocols in WSNs

Wireless Sensor Networks 4 MAC protocols in WSNs

Media Management Control

Link Data Ack

Phase Pending RSSI PRR

Wireless Sensor Networks 5 MAC protocols in WSNs

Data link/MAC layer

Wireless Sensor Networks 6 MAC protocols in WSNs

Wireless Sensor Networks 7 MAC protocols in WSNs

❖ Multiple network/sensor nodes share the same channel

Wireless Sensor Networks 8 MAC protocols in WSNs

Wireless Sensor Networks 9 MAC protocols in WSNs

Wireless Sensor Networks 10 MAC protocols in WSNs

Wireless Sensor Networks 11 MAC protocols in WSNs

Wireless Sensor Networks 12 MAC protocols in WSNs

Wireless Sensor Networks 13 MAC protocols in WSNs

Wireless medium access

Schedule- Contention- Schedule- Contention-

Wireless Sensor Networks 14 MAC protocols in WSNs

Wireless Sensor Networks 15 MAC protocols in WSNs

❖ Idea: The network nodes attempt to coordinate access to the

Wireless Sensor Networks 16 MAC protocols in WSNs

Wireless medium access

Schedule- Contention- Schedule- Contention-

Wireless Sensor Networks 17 MAC protocols in WSNs

❖ A schedule exists, regulating which participant may use which resource at

Wireless Sensor Networks 18 MAC protocols in WSNs

Wireless Sensor Networks 19 MAC protocols in WSNs

Wireless medium access

Schedule- Contention- Schedule- Contention-

Wireless Sensor Networks 20 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

Wireless Sensor Networks 21 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

data ready data ready

collision successful successful

Wireless Sensor Networks 22 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

data ready data ready

collision window for packet 3

Wireless Sensor Networks 23 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

data ready data ready

data ready data ready

successful successful collision

Wireless Sensor Networks 24 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

collision window for packet 3

Wireless Sensor Networks 25 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

data ready data ready

data ready data ready

CS (sense the channel) CS

successful successful collision

Wireless Sensor Networks 26 MAC protocols in WSNs

❖ Basic ideas for a distributed MAC

CS (sense the channel) CS CS

successful collision collision collision

Wireless Sensor Networks 27 MAC protocols in WSNs