0% found this document useful (0 votes)
6 views54 pages

ch04-MAC Protocols in WSNs

The document discusses the design and development of IoT applications, focusing on MAC protocols for Wireless Sensor Networks (WSNs). It covers key concepts such as low-power links, robust communication, multi-hop routing, and various MAC protocols like B-MAC, X-MAC, and ContikiMAC. The document highlights challenges in MAC design, including idle listening and overhearing, and presents techniques to optimize energy consumption and communication efficiency.

Uploaded by

hoainam30012003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views54 pages

ch04-MAC Protocols in WSNs

The document discusses the design and development of IoT applications, focusing on MAC protocols for Wireless Sensor Networks (WSNs). It covers key concepts such as low-power links, robust communication, multi-hop routing, and various MAC protocols like B-MAC, X-MAC, and ContikiMAC. The document highlights challenges in MAC design, including idle listening and overhearing, and presents techniques to optimize energy consumption and communication efficiency.

Uploaded by

hoainam30012003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 54

Design and Development of IoT Applications 16-Sep-24

Content
Chapter 4: MAC protocols for WSNs
Low-power link
Robust communication
Radio Duty Cycling
Synchronized and Asynchronized Protocols
B-MAC, X-MAC, ContikiMAC

Dept. of Telecoms Engineering 1


Design and Development of IoT Applications 16-Sep-24

Building A Low-Power Link


Media Management Control – not MAC

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

Dept. of Telecoms Engineering 2


Design and Development of IoT Applications 16-Sep-24

Elements of Robust Communication


 Application: feasible workload
 Packet rates, pattern, timing
 Network: finding and using good paths
 Topology discovery and route selection
 Route cost determination, selection
 Forwarding
 Link: Framing, Media Management Protocol
 On to receive during transmission
 Frame structure, error detection, acknowledgement
 Avoiding contention (MAC, CCA, Hidden Terminal)
 Link quality estimation
 Physical: Signal to Noise Ratio (SNR)
 Device Transmission Power / Receive Sensitivity
 Antenna design and orientation, obstructions, attenuation
 Receive signal vs interference, noise, multipath
 Modulation, channel coding

Dept. of Telecoms Engineering 3


Design and Development of IoT Applications 16-Sep-24

In a nutshell

TX

Dept. of Telecoms Engineering 4


Design and Development of IoT Applications 16-Sep-24

Why multi-hop routing?


 Power!
 Power to transmit distance D grows as D3 or worse
 Power to route distance D grows linearly
 Bandwidth (spatial multiplexing)
 With n nodes in a single cell, each gets at most 1/n bandwidth
 Many small cells => many simultaneous transmissions.
 Reliability
 Individual links experience interference, obstacles, and
multipath effects
 Even short-range “wireless wires” require human nurturing
 IrDA, Bluetooth, WiFi, Cell Phone
 Provides spatial diversity and receiver diversity rather than
antenna diversity
 Protocol level reliability

Dept. of Telecoms Engineering 5


Design and Development of IoT Applications 16-Sep-24

Properties of a good Link layer


 It works!
 It supports the network layer above it.
 It allows low-power operation
 It allows highly reliable communication
 It allows for low latency
 It allows bursts
 It avoids contention
 It is simple, robust and flexible

Dept. of Telecoms Engineering 6


Design and Development of IoT Applications 16-Sep-24

MAC Protocol
 MAC protocol is to ensure that the channel
can be accessed by multiple users, dealing
with the situation of interference.
Has a direct bearing on how reliably and
efficiently data can be transmitted
Long battery life
 MAC protocol design for WSNs:
Energy-efficient in sense of achieved throughput
Robust
As simple as possible

Dept. of Telecoms Engineering 7


Design and Development of IoT Applications 16-Sep-24

Major problems in WSN MAC design


Idle listening
Listening when no traffic is sent
Overhearing
Receiving packets destined to other nodes
Collision
Retransmission
Overhead
Headers for signalling

Dept. of Telecoms Engineering 8


Design and Development of IoT Applications 16-Sep-24

The “Idle Listening” Problem


 The power consumption of “short range” (i.e., low-
power) wireless communications devices is roughly the
same whether the radio is transmitting, receiving, or
simply ON, “listening” for potential reception
includes IEEE 802.15.4, Z-Wave, Bluetooth, and the many
variants
WiFi too!
Circuit power dominated by core, rather than large
amplifiers
 Radio must be ON (listening) in order receive anything.
Transmission is infrequent. Reception α Transmit x Density
Listening (potentially) happens all the time
 Total energy consumption dominated by idle listening

Dept. of Telecoms Engineering 9


Design and Development of IoT Applications 16-Sep-24

MAC Caution
 The idle listen problem is often associated with Media
Access Control (MAC) protocols,
 TDMA, CSMA, …
 but MACs provide arbitration among multiple
transmitters attempting to utilize a shared medium
simultaneously.
 Reduce Contention and associated loss.
 May involve scheduling (TDMA) or transmission detection
(CSMA)
 The problem here is the opposite.
 Most of the time, nothing is transmitting.
 Avoid listening when there is nothing to hear.
 Scheduling and detection are involved, but to determine when
to turn on receiver, rather than when to turn off transmission.
 You need Media Access Control, but that is not enough
Dept. of Telecoms Engineering 10
Design and Development of IoT Applications 16-Sep-24

Low Power
Active Active

Sleep WakeUP Work Sleep WakeUP Work

* System design

* Leakage (~RAM)

* Nobody fools
mother nature

Ave Power = fact * Pact + fsleep * Psleep + fwaking * Pwaking

Dept. of Telecoms Engineering 11


Design and Development of IoT Applications 16-Sep-24

Where the energy goes?


 Sleep
7 uA for TI MSP
 Sensing
 Transmitting results
 Management Traffic
 Routing Structure Maintenance
only parent tracking for leaf
 Listening
 Forwarding
non-leaf
 Overhearing packets destined for others

Dept. of Telecoms Engineering 12


Design and Development of IoT Applications 16-Sep-24

Overhearing
 Receiving packets that are not destined to the
node
 Interception, waste of energy in receiving,
error responding will cause potential collision

overhearing

Tx Rx
data

overhearing

Dept. of Telecoms Engineering 13


Design and Development of IoT Applications 16-Sep-24

Traffic Pattern
Local broadcast
Schedule exchange/update between neighbours
Omni-directional transmission is desired

Nodes to sink report


Payload and signalling
In favour of directional transmission

Dept. of Telecoms Engineering 14


Design and Development of IoT Applications 16-Sep-24

Duty cycle
 Duty cycling is a widely used mechanism in
wireless sensor networks.
 Reducing energy consumption due to idle
listening.
 This mechanism also introduces additional
latency in packet delivery.

Dept. of Telecoms Engineering 15


Design and Development of IoT Applications 16-Sep-24

Power States at Node Level

Active Active

Sleep WakeUP Work Sleep WakeUP Work

Telos: Enabling Ultra-Low Power Wireless Research, Polastre, Szewczyk, Culler, IPSN/SPOTS 2005
Dept. of Telecoms Engineering 16
Design and Development of IoT Applications 16-Sep-24

Communication Power Consumption


Sleep Transmit
~10 uA ~20 mA x 1-5 ms
[20 - 100 uAs]
I

Time

Time
Listen Receive
~20 mA ~20 mA x 2-6 ms

Dept. of Telecoms Engineering 17


Design and Development of IoT Applications 16-Sep-24

Communication Power – Passive Vigilance


Sleep Transmit
~10 uA ~20 mA x 1-5 ms
[20 - 100 uAs]
I

Time

Time
Listen Receive
~20 mA ~20 mA x 2-6 ms

Listen just when there is something to hear …

Dept. of Telecoms Engineering 18


Design and Development of IoT Applications 16-Sep-24

What causes Energy Waste?


 Collisions/Interference
Basic Function of MAC layer
 Control packet overhead
e.g., RTS/CTS, Beaconing
 Overhearing unnecessary traffic
Non-target nodes
 Long idle time
Prepare for receiving packets
 Synchronization Overhead
Preamble and Start of Frame Detection

Dept. of Telecoms Engineering 19


Design and Development of IoT Applications 16-Sep-24

2 Basic Solution Techniques


Synchronized protocols
 Nodes awake/sleep on a
schedule
 periodic sleep, no idle
listening
 E.g. S-MAC, T-MAC
Asynchronized protocols:
Nodes having
independent schedule
Need some mechanism
for carrier sensing
E.g. B-MAC, X-MAC,
TSCH
Dept. of Telecoms Engineering 20
Design and Development of IoT Applications 16-Sep-24

Asynchronous vs. Synchronous


Advantages
Use extended preamble
Sender and receiver can have decoupled duty cycles.
No synchronization overhead.
Awake periods are much shorter

Disadvantages
Frame exchange delay even if receiver awakes before
preamble ends
Overhearing problem
Preamble latency is expensive for multi-hop routes

Dept. of Telecoms Engineering 21


Design and Development of IoT Applications 16-Sep-24

LPL: Low-Power Listening


 Goal: minimize listen cost
 RX: CCA 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

 Example: B-MAC preamble data

listen

channel sniff
Dept. of Telecoms Engineering 22
Design and Development of IoT Applications 16-Sep-24

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
 Transmitting node precedes data packet with preamble
slightly longer than sleep period of receiver.
 During awake period, node samples medium & if a preamble
is detected it remains awake to receive the data.

Dept. of Telecoms Engineering 23


Design and Development of IoT Applications 16-Sep-24

B-MAC Protocol
Rx Check
Receive data
interval

Carrier sense
Tx Long preamble Data transmission

 Shift most burden to the sender


 Sender uses a long preamble before each packet
to wake up the receiver.
 Data transmission can use RTS/CTS or some other
strategy.

Dept. of Telecoms Engineering 24


Design and Development of IoT Applications 16-Sep-24

Key challenges of B-MAC


Rx Check
Receive data
interval

Carrier sense
Tx Long preamble Data transmission

 Check Interval has to be very short to ensure reasonable length


preamble
 Carrier sense duration also has to be very short to ensure receiver
does not spend too much energy.
 Carrier sense has to be very accurate to reduce:
 latency of transmission
 energy consumption at sender

Dept. of Telecoms Engineering 25


Design and Development of IoT Applications 16-Sep-24

How to Fix Some Issues in B-MAC


 X-MAC: A Short Preamble MAC Protocol for Duty-Cycled
Wireless Sensor Networks
(M. Buettner, G. V. Yee, E. Anderson, R. Han)

 B-MAC = CSMA + LPL + Noise Floor Estimation + Explicit ACK

 X-MAC = B-MAC + Early ACK + Encoded preamble (???)

Dept. of Telecoms Engineering 26


Design and Development of IoT Applications 16-Sep-24

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.
Reduces per-hop latency and energy
Dynamic duty-cycle algorithm

Dept. of Telecoms Engineering 27


Design and Development of IoT Applications 16-Sep-24

X-MAC
Strobed preamble
 Allowing interruption and wake up faster
Short preamble
 Embedded with address information of the target

Dept. of Telecoms Engineering 28


Design and Development of IoT Applications 16-Sep-24

X-MAC vs LPL: Operations

Dept. of Telecoms Engineering 29


Design and Development of IoT Applications 16-Sep-24

X-MAC: Benchmarking parameters


 Design goals of the X-MAC protocol for duty-cycled WSNs:
 Energy-efficiency
 Low loss % of packets
 Low latency for data
 High throughput for data
 Duty cycles
 Small pauses between preamble packets permit the target
receiver to send an ACK
 Truncating preamble saves energy at transmitter and
receiver and allows for lower latency.
 Non-target receivers which overhear the strobed
preamble can go back to sleep immediately
 X-MAC’s strobed preamble approach outperforms
traditional LPL.
Dept. of Telecoms Engineering 30
Design and Development of IoT Applications 16-Sep-24

ContikiMAC

Dept. of Telecoms Engineering 31


Design and Development of IoT Applications 16-Sep-24

ContikiMAC: Unicast and Broadcast

Dept. of Telecoms Engineering 32


Design and Development of IoT Applications 16-Sep-24

ContikiMAC: Phase Lock

Dept. of Telecoms Engineering 33


Design and Development of IoT Applications 16-Sep-24

TSCH
Time Slotted, Channel Hopping (TSCH) technology is
the basis for the wireless network of two industrial
standards
HART Foundation (over 200 companies worldwide):
WirelessHART- published 9/07
ISA (over 30,000 members worldwide): ISA100 Committee,
ISA100.11a working group- in working group draft
TSCH has been implemented by multiple companies
on multiple 2.4 GHz IEEE std. 802.15.4 platforms

Dept. of Telecoms Engineering 34


Design and Development of IoT Applications 16-Sep-24

TSCH: Timeslot Access


Slot Frame Cycle

Unallocated Slot Allocated Slot

timeslot
CCA: RX startup, Transmit Packet: Preamble, SFD, RX startup or RX ACK
Tx listen, RX->TX Headers, Payload, CRC TX->RX

RX RX packet Verify Calculate ACK Transmit


Rx startup MIC MIC ACK

RX/TX
turnaround

TX/RX packet TX/RX ACK


Devices are configured with a slot-frame and timeslots to communicate
with each other.

Dept. of Telecoms Engineering 35


Design and Development of IoT Applications 16-Sep-24

Timeslot Basics
All devices in the same network synchronize slotframes
All timeslots are contained within a slotframe cycle
Timeslots repeat in time: the slotframe period
Device-to-device communication within a timeslot
includes packet Tx/Rx & ACK Tx/Rx
Configurable option for CCA before transmit in
timeslots

Dept. of Telecoms Engineering 36


Design and Development of IoT Applications 16-Sep-24

Timeslot Operation In Devices


Devices use timeslots to:
 Schedule when they wakeup to transmit or listen
 Keep time synchronized
 Specification on time difference tolerances
 Time synchronization mechanisms
 Time the sequence of operations
 Allow the source and destination to set their frequency
channel
 Listening for a packet
 Sending a packet
 Listening for an ACK
 Generating an ACK
 Synchronizes channel hops
 Provide time to higher layers
Slide 37
Dept. of Telecoms Engineering 37
Design and Development of IoT Applications 16-Sep-24

TSCH: Link Types


Dedicated Link – assigned to one device for
transmission and to one or more devices for
reception
A dedicated broadcast link is assigned to all
devices for reception
Shared Link – assigned to more than one
device for transmission
ACK failures detect collisions
A slot based back-off algorithm resolves collisions

Dept. of Telecoms Engineering 38


Design and Development of IoT Applications 16-Sep-24

TSCH: Channel Hopping


Slot n-2 Slot n-1 Slot n Slot n+1 Slot n+2
11
12
13
14
15
802.15.4 Channels

16
17
18
19
20
21
22
23
24
25
26

• Combined with timeslot access to enhance reliability

Dept. of Telecoms Engineering 39


Design and Development of IoT Applications 16-Sep-24

TSCH: Channel Hopping


Mitigate Channel Impairments
Channel hopping adds frequency diversity to mitigate the
effects of interference and multipath fading
Increase Network Capacity
One timeslot can be used by multiple links at the same
time
More secured

Dept. of Telecoms Engineering 40


Design and Development of IoT Applications 16-Sep-24

Link = (Timeslot , Channel Offset)


Time One Slot
D
Chan.
A
offset
BA

CA
C
DA
B
BA

BC
E F BE
BF

• The two links from B to A are dedicated


• D and C share a link for transmitting to A
• The shared link does not collide with the dedicated links

Dept. of Telecoms Engineering 41


Design and Development of IoT Applications 16-Sep-24

TSCH: Channel Hopping


Time
Channel Offset

BA BA BA


(ch 15) (ch25) (ch18)
CA CA CA
DA DA DA

BA BA BA

BC BC BC


BE BE BE
BF BF BF
ASN= N*4 N*4+1 N*4+2 N*4+3 (N+1)*4

Cycle N Cycle N+1 Cycle N+2


• Each link rotates through k available channels over k cycles.
– Ch # = Chan Hopping Seq. Table ( ( ASN + Channel Offset) % Number_of_Channels )
• Blacklisting can be defined globally and locally.

Dept. of Telecoms Engineering 42


Design and Development of IoT Applications 16-Sep-24

TSCH: operating frequency


 The channel offset is translated in an operating frequency f

 ASN (Absolute Slot Number): total # of slots that elapsed since


the network was deployed (5 bytes):

where:
 S is the slotframe size, k the slotframe cycle
 nch : number of used channels (16)
 t: slot in the slotframe
 chOf: channel offset
F is implemented as a look-up-table containing the sets of
available channels

Dept. of Telecoms Engineering 43


Design and Development of IoT Applications 16-Sep-24

TSCH: frequency

nch=16 (channel 11-26)

k=
=0

Dept. of Telecoms Engineering 44


Design and Development of IoT Applications 16-Sep-24

TSCH: Scheduling
The standard only explains how the MAC layer
executes a schedule it does not specify how such a
schedule is built
Centralized Scheduling
a manager node is responsible for building and maintaining
the network schedule
Distributed Scheduling
No central entity
Each node decides autonomously

Dept. of Telecoms Engineering 45


Design and Development of IoT Applications 16-Sep-24

Non-conflicting Timeslot assignment


• Devices with multiple radios can be given one or more offsets.
• Devices can be given one or more slots in a particular slotframe.
• Devices with management ability can be given a block of (slot,offset)s
slot
Chan. offset

Dept. of Telecoms Engineering 46


Design and Development of IoT Applications 16-Sep-24

Non-conflicting timeslot assignment


 Multiple slotframes with different lengths can operate at the
same time.
 4 cycles of the 250ms slotframe are shown, along with a
1000ms slot frame
 There are never collisions if the 1000ms slot frame uses only the
empty slots of the 250 ms slot frame

250ms 250ms 250ms 250ms

1,000ms

Dept. of Telecoms Engineering 47


Design and Development of IoT Applications 16-Sep-24

Examples of TSCH Capability


 Data collection
 100 pkt/s per access point channel using 10 ms slots*
 1600 pkt/s (16*100) network capacity with no spatial reuse of
frequency
 Radio duty cycle (power consumption)
 Near theoretical limit for networks with moderate to high traffic
 ~0.02% for very low traffic networks
 Latency
 10ms / PDR (Packet Delivery Rate) per hop: best case
 Statistical, but well modeled

* 10 ms slots are an example – the standard can define a range of slot


sizes that can be selected for use

Dept. of Telecoms Engineering 48


Design and Development of IoT Applications 16-Sep-24

Link Layer – Abstraction


 Media Management Control
Local Media: Sample Period + Phase
Remote Media: Sample Period + Phase + Pending
 Neighbor Connectivity Statistics
Signal Quality (RSSI)
Success Rates (windowed average)
Data Ack Media Management Control
Remote Media Link Stats Local Media

Link
Neighbor Table Sample Period

Addr Period Phase Pending RSSI Success Sample Phase

Phy
Dept. of Telecoms Engineering 49
Design and Development of IoT Applications 16-Sep-24

Link layer in Contiki OS


 Framer layer is not a regular layer implementation; it is actually a collection of
auxiliary functions that are called for creating a frame with data to be transmitted
and parsing of data being received. There are two types of Framer layers: framer-
802154.c and framer-nullmac.c.
 Radio Duty-Cycle (RDC) layer takes care of the sleep period of nodes. This is the
most important layer for deciding exactly when the packets will be transmitted and
it is responsible for making sure that the node is awake when packets are to be
received. Examples of RDC layers that are implemented: contikimac.c, xmac.c,
lpp.c, nullrdc.c and sicslowmac.c.
 Finally, the MAC layer takes care of addressing and retransmission of lost packets.
We have only two types of MAC layers available: csma.c and nullmac.c.

Dept. of Telecoms Engineering 50


Design and Development of IoT Applications 16-Sep-24

Open Issues for Research and Industry


 Sampled vs Synchronized
 Is time synchronization required for the network to work at all?
 Or is it an optimization
 Multi-channel usage
 Frequency agility
 Increased diversity
 Impact on prediction, link assessment
 Distributed vs. Centralized
 How much is determined locally vs network wide
 Fundamental lower bounds
 energy is required to maintain structure
 Where is the optimal point
 Visibility
 How does network level inform link of relevance
 How does link level inform network of status

Dept. of Telecoms Engineering 51


Design and Development of IoT Applications 16-Sep-24

Connectivity
 Much of the CS work on network protocols
Routing, cluster head formation, topology formation, …
assumes a unit disk model
• If Distance < R, Connectivity = 1, otherwise 0

Empirical models based on fading, signal-to-noise ratio


(SNR), modulation, and coding.
• PRR (packet receive rate) for SNR (g), frame size (f)…
For Mica2 with FSK CC1000

• Nakagami and Rayleigh Fading

Dept. of Telecoms Engineering 52


Design and Development of IoT Applications 16-Sep-24

PRR – Packet Reception Rate


Calculated based on packet
receipts
~RSSI/LQI
TI CC2420:
 IEEE 802.15.4 compliant
 2400 – 2483.5 MHz RF tranceiver
 O-QPSK Direct Sequence Spread
Spectrum (DSSS)
 250 kpbs data rate, 2 Mchips/s
 0 dBm (1 mW) transmit power
 -95 dBm receive sensitivity
 30/45 dB adjacent channel rejection
 53/54 dB alternate channel rejection
 PIFA PCB antenna

Dept. of Telecoms Engineering 53


Design and Development of IoT Applications 16-Sep-24

Summary
Many of the best protocols are opportunistic
Use whatever connectivity occurs
Topology determination and route selection is a
constant and gentle process
Passive monitoring wherever possible
Use every piece of information available to track quality
Concentrate link estimation on the few important
candidates.
Additional network density helps reliability
If the media management is done right

Dept. of Telecoms Engineering 54

You might also like