14 Advanced MAC Protocols

Key Concepts

MAC Layer: The Medium Access Control sublayer of the Data Link layer; governs when and how devices access a shared communication channel
CSMA (Carrier Sense Multiple Access): A family of MAC protocols where a device senses the channel before transmitting to avoid interfering with ongoing transmissions
Random Backoff: A delay chosen from a random range before retransmitting after a collision or detected busy channel; reduces the probability of repeated collisions
Binary Exponential Backoff: A backoff algorithm where the retry delay range doubles after each failed attempt; used in Ethernet and 802.11
Duty Cycle: The fraction of time a radio is active (transmitting or receiving); lower duty cycle conserves battery life
Superframe: A periodic structure in beacon-enabled IEEE 802.15.4 networks dividing time into a contention access period and an optional contention-free period
CCA Threshold: The signal power level above which a device considers the channel busy and defers transmission

14.1 In 60 Seconds

Advanced networking topics critical for production IoT: TCP congestion control can misinterpret wireless packet loss as congestion (reducing throughput unnecessarily), IPv4 exhaustion forces NAT usage that breaks end-to-end IoT connectivity, hidden/exposed terminal problems affect CSMA-based protocols, and MTU fragmentation adds significant overhead to small IoT payloads.

14.2 Learning Objectives

By the end of this chapter, you will be able to:

Analyze TCP congestion control behavior and its impact on IoT throughput over lossy wireless links
Explain IPv4 exhaustion and NAT challenges for IoT deployments
Compare MAC protocols (CSMA, TDMA, ALOHA) for different IoT use cases
Identify and solve hidden and exposed terminal problems using RTS/CTS and TDMA
Implement QoS for prioritizing critical IoT traffic using DSCP marking
Calculate fragmentation overhead and select MTU-aware strategies for constrained networks

For Beginners: MAC Protocols

MAC (Media Access Control) protocols are the traffic rules that decide when each device is allowed to transmit data. Imagine a group conversation where everyone needs to take turns speaking – MAC protocols ensure devices do not all talk at once and create chaos on the network.

Sensor Squad: The Advanced Traffic Rules!

“We learned basic MAC protocols, but real IoT networks have trickier problems,” said Max the Microcontroller. “Like TCP congestion control – it was designed for wired networks. When a wireless packet gets lost due to interference, TCP thinks the network is overloaded and slows down. But the network was fine – it was just a momentary radio glitch!”

“That is called the TCP-over-wireless problem,” explained Lila the LED. “TCP reduces its sending rate when it should not, making things slower for no reason. Some IoT systems use UDP instead to avoid this issue, handling reliability themselves at the application layer.”

Sammy the Sensor raised another concern. “What about the hidden terminal problem? I cannot hear another sensor behind a wall, so I think the channel is free and start transmitting. But the gateway can hear BOTH of us, and our signals collide there!”

“Great example,” said Bella the Battery. “The solution is RTS/CTS – Ready-to-Send and Clear-to-Send messages. Before transmitting big data, you ask the gateway for permission. The gateway broadcasts ‘clear,’ telling all nearby devices to wait. It adds a little overhead but prevents costly collisions, especially important for battery-powered devices like me!”

How It Works: TCP Congestion Control in IoT Networks

TCP congestion control operates on a simple principle: packet loss signals congestion. Here’s the step-by-step mechanism and why it fails for wireless IoT:

Step 1: Slow Start Phase

TCP starts conservatively with 1 MSS (Maximum Segment Size)
Window doubles each RTT until reaching slow-start threshold
Example: 1 → 2 → 4 → 8 MSS

Step 2: Congestion Avoidance

After threshold, window grows linearly (+1 MSS per RTT)
Continues until packet loss detected

Step 3: Loss Response (The IoT Problem)

TCP detects loss → assumes congestion → halves window
For wired networks: loss = congestion (correct assumption)
For wireless IoT: loss = interference (wrong assumption!)

Why This Breaks for LoRa/Zigbee:

5% wireless packet loss (normal interference)
TCP interprets ALL as congestion
Window repeatedly halved → throughput collapses to 4% of capacity
Battery drains retransmitting unnecessarily

Solution: Use UDP-based protocols (CoAP) that don’t assume loss = congestion, letting application layer decide retry strategy.

14.3 Deep Dive: Advanced Networking Concepts for IoT

This section covers advanced networking topics for engineers implementing production IoT systems. Beginners can skip and return when deploying large-scale networks.

14.3.1 TCP Congestion Control and IoT Implications

TCP’s congestion control algorithms (originally designed for traditional networks) can cause problems in IoT environments.

Putting Numbers to It

TCP Congestion Window Dynamics on Lossy Links

TCP’s congestion window (CWND) determines how many bytes can be in-flight. On wireless links, packet loss causes catastrophic throughput collapse:

Slow Start phase (exponential growth): \[\text{CWND}_{\text{new}} = \text{CWND}_{\text{old}} \times 2 \quad \text{each RTT until ssthresh}\]

Congestion Avoidance (linear growth): \[\text{CWND}_{\text{new}} = \text{CWND}_{\text{old}} + \text{MSS} \quad \text{per RTT}\]

Loss Event (multiplicative decrease): \[\text{CWND}_{\text{new}} = \frac{\text{CWND}_{\text{old}}}{2}\]

Example: LoRaWAN TCP connection with 5% loss rate, RTT = 2 sec, MSS = 128 bytes, link = 5 Kbps: - Ideal CWND: $\frac{5{,}000 \times 2}{8} = 1{,}250$ bytes (10 MSS) - With 5% loss: Every 20 packets, one loss → CWND halved before reaching 10 MSS - Measured CWND: oscillates 1-5 MSS, average 3 MSS → 30% of ideal - Throughput: $\frac{3 \times 128 \times 8}{2} = 1{,}536$ bps (31% of 5 Kbps capacity)

For comparison, UDP-based CoAP with application-layer retries achieves 4,500 bps (90% capacity) on the same link – explaining why IoT protocols avoid TCP on lossy wireless networks.

Solutions:

Use UDP for lossy links: CoAP (UDP-based) works better than HTTP (TCP)
Tune TCP parameters: Increase initial CWND, adjust retransmission timeout
Application-layer retries: Implement custom retry logic at MQTT/CoAP layer

Advanced Gateway Tuning Example

Use these only on a Linux gateway you control. They are tuning knobs for unusually lossy links, not beginner settings for every router.

Tuning goal	Linux setting concept	Why it may help
Use a congestion algorithm less tied to packet loss	`net.ipv4.tcp_congestion_control=bbr`	BBR estimates bandwidth and delay instead of assuming every loss means congestion.
Avoid restarting too cautiously after idle periods	`net.ipv4.tcp_slow_start_after_idle=0`	A sensor gateway that sends bursts does not always need to relearn the path from zero.
Avoid stale path assumptions	`net.ipv4.tcp_no_metrics_save=1`	Prevents old congestion metrics from biasing future connections on changing wireless links.

14.3.2 IPv4 Address Exhaustion and NAT for IoT

The IPv4 Problem:

Quantity	Approximate Scale	Why It Matters
Total IPv4 space	4.3 billion addresses	The entire address space is smaller than the number of internet-connected things.
Usable public IPv4	About 3.7 billion addresses	Private, reserved, and multicast ranges cannot be assigned as public device addresses.
IoT devices in 2026	About 18 billion	There are already far more devices than public IPv4 addresses.
Projected IoT devices by 2030	More than 30 billion	NAT and IPv6 become design requirements, not optional extras.

Network Address Translation (NAT) - The Temporary Fix:

NAT allows many devices to share one public IP:

Your home network (192.168.1.0/24):

Router public IP: 203.0.113.45 (ONE public IP)
Devices behind NAT:
- Phone: 192.168.1.100 (private)
- Thermostat: 192.168.1.101 (private)
- Camera: 192.168.1.102 (private)
- Lights: 192.168.1.103-120 (private)

Figure 14.1: NAT translation table mapping private IoT devices to one public IPv4 address

NAT Problems for IoT:

Inbound connections blocked:
- Can’t directly access smart camera from internet
- Need port forwarding or VPN
- Security risk if misconfigured
NAT traversal complexity:
- Requires STUN/TURN servers for peer-to-peer
- Adds latency (extra hops)
- Some protocols don’t work through NAT (FTP, SIP without ALG)
Port exhaustion:

A single public IPv4 address has about 65,535 TCP/UDP ports available. If 10,000 IoT devices each keep 10 cloud connections open, the router needs 100,000 translations. That exceeds the port space, so new connections can fail or time out.

IPv6: The Real Solution:

IPv6 provides $2^{128}$ addresses, roughly $3.4 \times 10^{38}$. The practical takeaway is simple: every IoT device can have multiple globally routable addresses without NAT.

IPv6 Adoption in IoT (2026):

Cellular IoT (NB-IoT, LTE-M): 100% IPv6 support
Wi-Fi 6: Full IPv6 support
Zigbee, Thread: 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)
LoRaWAN: IPv6 via IPv6-over-LoRaWAN draft standard

14.3.3 Link Layer Protocol Comparison: CSMA vs TDMA vs ALOHA

Different medium access control (MAC) protocols affect IoT network performance.

CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance): Used by: Wi-Fi, Zigbee, Bluetooth

CSMA/CA Step	What the device does
1. Listen	Sense whether the radio channel is already busy.
2. Back off if busy	Wait a random delay so many devices do not retry at the same instant.
3. Transmit if idle	Send the frame when the channel appears free.
4. Retry after failure	Use exponential backoff if an acknowledgement does not arrive.

Strength	Limitation
Fair access: every node gets a chance to transmit.	At high load, collisions and retries dominate.
Efficient at low to medium traffic levels.	Hidden terminals can transmit without hearing each other.
Distributed: no central scheduler required.	Exposed terminals may wait even when they could transmit safely.

Typical Wi-Fi channel utilization is about 70-90% with a few devices, but can fall to 30-50% in dense networks where collisions dominate.

14.3.4 MAC Protocol Challenges: Hidden and Exposed Terminals

CSMA/CA works well in simple scenarios, but wireless networks face unique challenges that don’t exist in wired networks. Two fundamental problems—hidden terminals and exposed terminals—can severely degrade network performance in IoT deployments.

14.3.4.1 The Hidden Terminal Problem

Definition: Two nodes cannot hear each other’s transmissions but both can reach a common destination, causing undetected collisions at the receiver.

Why It Happens:

Wireless signals attenuate with distance
Physical obstacles (walls, furniture, machinery) block signals
Nodes outside each other’s carrier sense range

Hidden terminal diagram showing node A and node C outside each other's carrier-sense range while both can reach gateway B, causing simultaneous transmissions to collide at B — Figure 14.2: Hidden terminal collision: A and C cannot hear each other but both reach gateway B

The Problem in Action:

Scenario: smart factory Wi-Fi sensors hidden behind metal machinery.

Time	What A Sees	What C Sees	What Gateway B Receives
0 ms	Channel looks idle because A cannot hear C.	Channel looks idle because C cannot hear A.	Nothing yet.
1 ms	A starts transmitting to B.	C also starts transmitting to B.	Two overlapping signals begin arriving.
2 ms	A still cannot detect C directly.	C still cannot detect A directly.	Collision: B receives garbled data from both sensors.

Result: both frames are lost, but the sensors may not know until an acknowledgement timeout, wasting time and battery.

Real-World IoT Impact:

Scenario	Hidden Terminal Effect	Performance Loss
Smart home (2-story house)	Upstairs sensors can’t hear downstairs → collisions at Wi-Fi AP	20-40% packet loss
Zigbee mesh (walls)	Nodes in different rooms → collisions at coordinator	15-30% throughput reduction
Industrial WSN (metal machinery)	Metal blocks RF → severe hidden terminals	40-60% retransmissions
Wi-Fi in dense deployment	50+ APs in building → overlapping coverage areas	50%+ channel utilization loss

Solution: RTS/CTS Handshake (Request-to-Send / Clear-to-Send)

Figure 14.3: RTS/CTS handshake preventing hidden terminal collisions

How RTS/CTS Works:

Step	Message	What It Achieves
1	Node A sends RTS to Gateway B.	A asks for permission and includes the planned transmission duration.
2	Gateway B broadcasts CTS.	All nodes that hear B, including hidden Node C, set a NAV timer and stay quiet.
3	Node A sends DATA.	C remains silent, so the frame reaches B without collision.
4	Gateway B sends ACK.	The transfer is complete and other nodes can compete for the channel again.

RTS/CTS Trade-offs:

Case	Approximate Airtime at 100 Mbps	Interpretation
DATA + ACK only	About 120 us	Best when collision risk is low.
RTS + CTS + DATA + ACK	About 124 us	Adds about 3.2% control overhead.
30% hidden-terminal collisions without RTS/CTS	About 156 us average after retries	Retransmissions cost more than the control handshake.

Rule of thumb: RTS/CTS becomes worthwhile when hidden-terminal collision rates are above roughly 10%.

When to Enable RTS/CTS:

IoT Deployment	Enable RTS/CTS?	Reasoning
Small smart home (< 10 devices)	❌ No	Low collision risk, overhead not worth it
Large smart building (50+ Wi-Fi devices)	✅ Yes	Hidden terminals common, reduces collisions
Zigbee mesh (many walls)	✅ Yes	Physical obstacles create hidden terminals
Industrial IoT (metal machinery)	✅ Yes	Severe RF blocking → many hidden terminals
LoRaWAN	❌ N/A	Uses ALOHA, not CSMA (no RTS/CTS)
Bluetooth mesh	✅ Yes	Dense deployments with obstacles

14.3.4.2 The Exposed Terminal Problem

Definition: A node unnecessarily defers transmission when its transmission would not cause a collision, reducing channel efficiency.

Why It Happens:

Node overhears a transmission not directed at its intended receiver
CSMA/CA conservatively assumes all transmissions will collide
Spatial reuse is prevented

Exposed terminal diagram showing node B transmitting to node A while node C hears B and unnecessarily defers its planned transmission to node D, even though D is outside B's interference area — Figure 14.4: Exposed terminal problem: C defers even though C to D would be safe

The Problem in Action:

Scenario: Zigbee smart lighting network.

Moment	Network State	Why It Is Inefficient
Setup	B is sending to A. C wants to send to D.	C can hear B, but D cannot hear B.
Carrier sense	C senses the channel as busy.	CSMA/CA assumes C to D might collide.
Reality	C to D would be safe because D is outside B’s range.	Spatial reuse is prevented even though no packet would be lost.
Result	C waits unnecessarily.	The channel is underused and latency increases.

Real-World IoT Impact:

Scenario	Exposed Terminal Effect	Efficiency Loss
Linear sensor array	Sensors at opposite ends defer unnecessarily	30-50% channel underutilization
Multi-floor building Wi-Fi	Devices on different floors could transmit simultaneously	20-40% throughput loss
Factory floor WSN	Sensors in different zones defer to each other	25-35% latency increase
Parking lot sensors	Distant sensors wait for nearby transmissions	15-30% reduced spatial reuse

Why Exposed Terminals Matter Less Than Hidden Terminals:

Problem	Main Effect	Severity	Engineering Response
Hidden terminal	Actual collisions, lost frames, retransmissions, wasted energy	High	Solve first with RTS/CTS, better AP placement, or scheduling.
Exposed terminal	Safe transmissions are delayed, reducing spatial reuse	Medium	Usually acceptable unless latency or throughput is mission-critical.

Priority order: solve hidden terminals first, accept some exposed-terminal inefficiency, and use directional antennas or TDMA when deterministic behavior is required.

14.3.4.3 MAC Protocol Comparison: Handling Hidden/Exposed Terminals

MAC Protocol	Hidden Terminal Solution	Exposed Terminal Solution	IoT Use Cases
CSMA/CA	❌ Poor (collisions common)	❌ Poor (spatial reuse limited)	Wi-Fi, Zigbee (add RTS/CTS for improvements)
CSMA/CA + RTS/CTS	✅ Good (handshake prevents collisions)	❌ Poor (still defers unnecessarily)	Dense Wi-Fi, industrial Zigbee
TDMA	✅ Excellent (no collisions, time slots)	✅ Excellent (spatial reuse via slot assignment)	Cellular IoT, mission-critical WSN
ALOHA	❌ Terrible (no carrier sensing at all!)	✅ Good (transmits anytime → spatial reuse)	LoRaWAN (works due to sparse traffic)
FDMA	✅ Excellent (different frequencies)	✅ Excellent (simultaneous transmission)	Cellular (frequency bands per user)

Real-World Mitigation Strategies:

Phase	Strategy	Practical Actions
Design	Network planning	Perform a site survey, identify hidden-terminal zones, and place APs or gateways to reduce radio shadows.
Deployment	Protocol configuration	Enable RTS/CTS for networks with many devices or obstacles, tune backoff settings, and use mesh paths where appropriate.
Enterprise	Advanced techniques	Use beamforming, MU-MIMO, TDMA scheduling, or frequency hopping when reliability requirements justify the complexity.

Case Study: Wi-Fi Smart Factory Deployment

Metric	Initial Deployment	After RTS/CTS + Redesign
Topology	80 Wi-Fi sensors across a metal-heavy factory floor	RTS/CTS on APs, two extra APs, mesh redundancy
Packet loss	45% during peak traffic	5%
Critical alert latency	3-5 seconds	200-500 ms
Retransmission rate	60%	8%
Business outcome	Missed alerts and downtime risk	About $50,000/year avoided downtime for about $2,000 extra AP cost

Having covered hidden and exposed terminal mitigations for CSMA, the remaining MAC protocols – TDMA and ALOHA – take fundamentally different approaches that sidestep these problems altogether.

TDMA (Time Division Multiple Access): Used by: Cellular (GSM, LTE), some industrial WSN

TDMA Aspect	Explanation
Basic idea	A coordinator assigns each node a time slot. Nodes transmit only in their own slots.
Example	In a 10 ms frame with 10 nodes, each node might get a 1 ms slot. The schedule repeats every 10 ms.
Strengths	No collisions, predictable latency, and low power because nodes can sleep outside their slot.
Limitations	Requires time synchronization and a coordinator; unused slots waste capacity.
Typical performance	Cellular-style TDMA scheduling can reach about 85-95% utilization with many devices.

ALOHA / Slotted ALOHA: Used by: LoRaWAN Class A, Sigfox

Method	How It Works	Maximum Channel Utilization
Pure ALOHA	Transmit whenever data is ready; retry after a random delay if a collision occurs.	About 18%
Slotted ALOHA	Transmit only at slot boundaries, but still without carrier sensing.	About 36%
CSMA/CA	Listen before talking and use random backoff.	About 70-90% at low to medium load
TDMA	Use scheduled time slots.	About 85-95%

ALOHA still works for LoRaWAN because traffic is sparse, nodes can sleep most of the time, and devices do not need to coordinate before transmitting.

Choosing MAC Protocol for IoT:

Use Case	Traffic Pattern	Best MAC	Why
Smart meter (1 msg/hour)	Infrequent, periodic	ALOHA (LoRaWAN)	Simple, low power, scales well for sparse traffic
Industrial sensor (100 Hz)	Frequent, deterministic	TDMA	Predictable latency, no collisions, mission-critical
Smart home devices	Bursty, on-demand	CSMA (Wi-Fi, Zigbee)	Fair access, efficient for dynamic traffic
Real-time video	Continuous, high-rate	TDMA (LTE)	Guaranteed bandwidth, low latency

Try It: ALOHA Network Capacity Calculator

Explore how the number of nodes and transmission duty cycle affect channel throughput under ALOHA.

Show code

viewof num_nodes = Inputs.range([1, 500], {value: 100, step: 1, label: "Number of nodes"})
viewof duty_cycle_pct = Inputs.range([0.01, 10], {value: 1, step: 0.01, label: "Duty cycle per node (%)"})
viewof aloha_mode = Inputs.select(["Pure ALOHA", "Slotted ALOHA"], {label: "ALOHA type", value: "Slotted ALOHA"})

Show code

aloha_results = {
  const G = num_nodes * (duty_cycle_pct / 100);
  const S_pure = G * Math.exp(-2 * G);
  const S_slotted = G * Math.exp(-G);
  const S = aloha_mode === "Pure ALOHA" ? S_pure : S_slotted;
  const max_util = aloha_mode === "Pure ALOHA" ? 18.4 : 36.8;
  const collision_prob = Math.max(0, 1 - Math.exp(aloha_mode === "Pure ALOHA" ? -2 * G : -G));
  return { G, S: Math.min(S, 1) * 100, max_util, collision_prob: collision_prob * 100 };
}

Show code

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
  <p><strong>Offered load (G):</strong> ${aloha_results.G.toFixed(3)} (total channel demand, normalized)</p>
  <p><strong>Channel throughput (S):</strong> <span style="color: ${aloha_results.S < 20 ? '#E74C3C' : aloha_results.S < 30 ? '#E67E22' : '#16A085'}; font-weight: bold;">${aloha_results.S.toFixed(1)}%</span></p>
  <p><strong>Theoretical maximum:</strong> ${aloha_results.max_util}%</p>
  <p><strong>Estimated collision probability:</strong> ${aloha_results.collision_prob.toFixed(1)}%</p>
  <p style="font-size: 0.85em; color: #7F8C8D;">${aloha_mode === "Pure ALOHA" ? "Formula: S = G·e^(−2G), max at G=0.5" : "Formula: S = G·e^(−G), max at G=1"}</p>
</div>`

14.3.5 MTU, MSS, and Fragmentation in Constrained Networks

Maximum Transmission Unit (MTU): Maximum packet size a network can carry without fragmentation.

Link Type	Typical MTU	Note
Ethernet	1500 bytes	Most wired LANs.
Wi-Fi	1500 bytes	Usually matches Ethernet for compatibility.
6LoWPAN / IEEE 802.15.4	127 bytes at the frame level	Very constrained; headers leave little application payload.
LoRaWAN	51-242 bytes	Depends on spreading factor and region.
NB-IoT	About 1358 bytes	Larger than low-power mesh links but still mobile-network constrained.
PPPoE	1492 bytes	Ethernet MTU minus the PPPoE overhead.

Maximum Segment Size (MSS): Maximum TCP payload size (MTU - IP header - TCP header).

Link	MSS Calculation	Result
Ethernet over IPv4/TCP	1500 byte MTU - 20 byte IPv4 header - 20 byte TCP header	1460 byte TCP payload
6LoWPAN with compressed IPv6	127 byte frame - compressed IPv6 header - TCP header - link overhead	Often only about 63-85 bytes for TCP payload

Fragmentation Problem:

Scenario: a 6LoWPAN sensor sends a 400 byte HTTP request over a 127 byte link.

Calculation	Result
Required fragments	`ceil(400 / 127) = 4` fragments
Fragment sizes	127 bytes, 127 bytes, 127 bytes, and 19 bytes
Per-fragment loss	5%
Datagram success probability	$(0.95)^4 = 81.5\%$
Effective datagram loss	18.5%

If any fragment is lost, the whole datagram is lost. A single unfragmented packet would have only the original 5% loss risk.

Try It: MTU Fragmentation Loss Calculator

Adjust the per-fragment loss rate and payload size to see how fragmentation multiplies effective packet loss.

Show code

viewof frag_loss_pct = Inputs.range([0.1, 20], {value: 5, step: 0.1, label: "Per-fragment loss rate (%)"})
viewof payload_bytes = Inputs.range([64, 1500], {value: 400, step: 1, label: "Payload size (bytes)"})
viewof mtu_bytes = Inputs.range([50, 1500], {value: 127, step: 1, label: "Link MTU (bytes)"})

Show code

frag_results = {
  const p_loss = frag_loss_pct / 100;
  const p_ok = 1 - p_loss;
  const n_frags = Math.ceil(payload_bytes / mtu_bytes);
  const p_success = Math.pow(p_ok, n_frags);
  const effective_loss = (1 - p_success) * 100;
  const unfrag_loss = p_loss * 100;
  return { n_frags, p_success: p_success * 100, effective_loss, unfrag_loss };
}

Show code

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
  <p><strong>Fragments required:</strong> ${frag_results.n_frags}</p>
  <p><strong>Datagram success probability:</strong> ${frag_results.p_success.toFixed(1)}%</p>
  <p><strong>Effective datagram loss rate:</strong> <span style="color: ${frag_results.effective_loss > 10 ? '#E74C3C' : '#16A085'}; font-weight: bold;">${frag_results.effective_loss.toFixed(1)}%</span> vs ${frag_results.unfrag_loss.toFixed(1)}% without fragmentation</p>
  <p style="font-size: 0.85em; color: #7F8C8D;">Formula: (1 − loss/100)^fragments × 100% success probability</p>
</div>`

Mitigation Strategies:

Strategy	What to Do	Why It Helps
Path MTU discovery	Send packets with the “Don’t Fragment” bit set; if the path rejects them, reduce packet size and retry.	Finds the largest safe packet size before production traffic fails.
Application-level chunking	Send four 100 byte messages instead of one 400 byte message.	Each chunk fits in one low-power frame, so one loss does not destroy the whole large message.
Protocol choice	Prefer CoAP/UDP with block-wise transfer over TCP-heavy HTTP on constrained links.	Smaller headers and built-in chunking reduce fragmentation pressure.

14.3.6 Quality of Service (QoS) for IoT Traffic Differentiation

Not all IoT data is equal - some requires priority handling.

DiffServ (Differentiated Services) Model:

IPv4/IPv6 packets have DSCP (Differentiated Services Code Point) field:

IP header diagram showing the DS field byte split into six DSCP bits for quality-of-service marking and two ECN bits for congestion notification, with IoT examples such as fire alarm, video, and telemetry traffic — Figure 14.5: DSCP and ECN fields inside the IP quality-of-service byte

IoT Traffic Classes:

Application	Latency Requirement	Loss Tolerance	Suggested QoS
Fire alarm trigger	<100ms	0% loss	EF (highest priority)
Video surveillance	<500ms	1-5% loss	AF41 (high priority)
Temperature reading	<5s	10% loss OK	AF21 (medium priority)
Firmware update	<1min	0% loss (use TCP retries)	Best Effort (bulk)
Historical data sync	<1hr	0% loss (use retries)	Best Effort (lowest)

Real implementation idea: marking alarm packets

Packet type	Marking choice	What the device or gateway does	Beginner meaning
Fire alarm	Expedited Forwarding (EF)	Set the IP quality-of-service field before sending the packet.	Treat the alarm as urgent traffic.
Video alert	Assured Forwarding (AF41)	Mark it as important but not more important than life-safety alarms.	Keep video responsive without starving alarms.
Temperature reading	Best Effort	Leave the packet unmarked.	Routine telemetry can wait behind urgent traffic.
Firmware update	Best Effort / bulk	Send slowly or schedule outside busy periods.	Large background transfers must not delay alarms.

Router Configuration (Cisco example):

Configuration Step	Cisco Concept	Beginner Meaning
Match alarm packets	`class-map match-any IOT_ALARMS` plus `match dscp ef`	Find packets already marked as emergency/expedited traffic.
Create a priority policy	`policy-map IOT_QOS` and `priority percent 10`	Reserve a low-latency queue for alarms so bulk traffic cannot bury them.
Apply the policy	`service-policy output IOT_QOS` on the WAN interface	Activate the queue on the link leaving the site.

Advanced: Cisco IOS Command Version

This is useful if you already administer Cisco IOS routers. Beginners should focus on the table above first.

IOS idea	Command concept	What it means
Identify alarm packets	`class-map` plus `match dscp ef`	Build a named group for packets already marked as emergency traffic.
Reserve priority handling	`policy-map` plus `priority percent 10`	Give alarms a small low-latency queue so bulk traffic cannot bury them.
Attach policy to the link	`service-policy output` on the WAN interface	Turn the queue on for packets leaving the site.

Measured Impact:

Condition	Alarm Latency	Jitter	Drops During Congestion
Without QoS: alarm competes with firmware download	5-50 seconds	+/- 20 seconds	Occasional drops
With QoS: alarm uses EF priority class	50-200 ms	+/- 10 ms	Zero drops

14.4 Worked Example: Solving Hidden Terminal Collisions in a Warehouse IoT Network

Scenario: A logistics warehouse (80m x 40m) deploys 30 Zigbee inventory sensors on shelving units to track pallet locations. The sensors report to a single gateway mounted at the center ceiling. Metal shelving creates radio shadows, causing hidden terminal problems – sensors on opposite sides of shelving rows cannot hear each other but both reach the gateway. During peak hours (07:00-09:00), 25% of sensor reports are lost to collisions. Design a MAC-layer solution.

Step 1: Quantify the Hidden Terminal Problem

Parameter	Value
Sensors	30, reporting every 5 seconds
Packet size	40 bytes (20B payload + 20B headers)
Data rate	250 kbps (Zigbee 802.15.4)
Transmission time per packet	40 x 8 / 250,000 = 1.28 ms
Offered load	30 packets / 5 seconds = 6 packets/second
Channel busy time	6 x 1.28 ms = 7.68 ms per second (0.77% utilization)

At 0.77% utilization, CSMA/CA should experience almost zero collisions. Yet 25% of packets are lost. Why?

The hidden terminal explanation: With 30 sensors, approximately 10 pairs cannot hear each other (behind shelving). When sensor A transmits, sensor B (hidden from A) senses the channel as free and also transmits. Both signals arrive at the gateway simultaneously, destroying each other. The 0.77% utilization calculation is misleading because it assumes all nodes see all other transmissions – hidden terminals violate this assumption.

Step 2: Evaluate MAC Protocol Solutions

Solution	How It Works	Collision Rate	Overhead	Suitable?
Pure CSMA/CA (current)	Listen before transmit	25% (hidden nodes can’t listen)	Minimal	No – hidden terminals bypass carrier sensing
RTS/CTS	Request permission from gateway before data	~2% (gateway arbitrates)	28 bytes per exchange (14B RTS + 14B CTS)	Yes, but doubles airtime
TDMA slots	Gateway assigns time slots to each sensor	~0% (no contention)	Beacon overhead + synchronization	Yes, best for predictable traffic
Frequency hopping	Sensors use different channels	~5% (reduced collision probability)	Channel coordination overhead	Partial – reduces but doesn’t eliminate

Step 3: TDMA Slot Calculation

Assign each sensor a dedicated time slot within a 5-second reporting cycle:

TDMA Design Parameter	Value
Superframe duration	5,000 ms, one complete reporting cycle
Sensors	30
Slot duration	1.28 ms data + 0.5 ms guard time + 1.0 ms ACK = 2.78 ms
Active period	30 x 2.78 ms = 83.4 ms
Sleep period	5,000 - 83.4 = 4,916.6 ms, or 98.3% sleep time

Metric	CSMA/CA (current)	TDMA (proposed)
Collision rate	25%	~0%
Successful delivery	75% (requires retries)	99.5%+
Average latency	5-15 ms (with backoff)	Deterministic (assigned slot)
Radio on-time per sensor	~50 ms/cycle (listen + transmit + retries)	2.78 ms/cycle
Battery impact	Baseline	18x less radio on-time

Step 4: Decision

TDMA is the optimal choice for this scenario because:

Traffic is predictable – every sensor reports at the same 5-second interval, making slot assignment straightforward
Hidden terminals are eliminated – no contention means no collisions regardless of radio shadows
Battery savings are dramatic – sensors sleep 98.3% of the time instead of continuously monitoring the channel
Capacity headroom exists – 83.4 ms of 5,000 ms used, allowing the network to grow to 150+ sensors before slots become tight

When CSMA/CA would be better: If sensors report only on events (unpredictable timing), TDMA wastes empty slots. For event-driven traffic with hidden terminals, RTS/CTS is the pragmatic choice despite its overhead.

Incremental Examples: Beginner Level

Scenario: You have 3 smart home sensors (temperature, motion, light) connected to a Wi-Fi access point.

Challenge: Why does your motion sensor sometimes fail to report movement immediately?

Answer: Hidden terminal problem! The temperature sensor in the basement can’t hear the light sensor in the attic. Both think the channel is idle and transmit simultaneously to the AP, causing collision. The motion sensor’s urgent alert gets caught in the collision.

Solution: Enable RTS/CTS on your AP. Before transmitting large data, sensors request permission. The AP broadcasts “clear to send” which ALL sensors hear, preventing collisions.

Incremental Examples: Intermediate Level

Scenario: A warehouse IoT deployment with 100 Zigbee sensors experiences 30% packet loss during peak hours (07:00-09:00).

Analysis:

Sensors report every 30 seconds (100 sensors / 30s = 3.3 packets/second)
At 250 kbps, channel utilization should be < 1%
But loss is 30% - why?

Root Cause: Hidden terminals behind metal shelving + pure CSMA/CA

Calculation:

10 sensor pairs can’t hear each other
Collision probability when hidden nodes transmit: ~30%
CSMA/CA can’t prevent what it can’t hear

Solution: Upgrade to TDMA with time slots. Each sensor gets dedicated 100ms window. Zero collisions, 98% packet delivery.

Incremental Examples: Advanced Level

Scenario: Design MAC protocol for 500-hectare farm with 1,000 soil sensors reporting every 15 minutes over LoRaWAN.

Requirements:

15 km range
10-year battery life
40-byte payload
< $10/sensor

Protocol Selection Decision Tree:

Option A: TDMA

Pros: No collisions, deterministic
Cons: 1,000 slots × 2s each = 33 minutes cycle → Too slow for 15-min requirement
Verdict: ❌ Infeasible

Option B: Slotted ALOHA

Channel efficiency: 36.8%
At 1,000 sensors, collision rate: ~8%
Retransmissions: 8% of readings need retry
Battery impact: Acceptable (extra 2-3 retries/day)
Verdict: ✅ Works but not optimal

Option C: Adaptive CSMA (LoRaWAN Class A)

Listen Before Talk (LBT) in EU868
Collision rate: < 2% with proper duty cycle
No coordination overhead
Battery: 10+ years achievable
Verdict: ✅ Optimal choice

Key Insight: At sparse traffic (1,000 sensors × 4 readings/hour = 0.01% duty cycle), pure ALOHA-style approaches outperform coordinated TDMA due to zero synchronization overhead.

14.5 Concept Relationships: MAC Protocols and IoT Design

Concept	Depends On	Enables	Conflicts With
TCP Congestion Control	Reliable transport, packet sequence numbers	Flow control, network stability	Wireless loss interpretation, LoRa duty cycles
NAT (Network Address Translation)	IPv4 exhaustion, private addressing	Home network scaling, cost savings	Peer-to-peer IoT, inbound connections, end-to-end principle
CSMA/CA	Carrier sensing, random backoff	Fair channel access, distributed coordination	Hidden terminals, exposed terminals, high-density deployments
RTS/CTS Handshake	CSMA/CA foundation, NAV timer	Hidden terminal mitigation, collision reduction	Adds 3-4% overhead, not viable for tiny packets
TDMA Slots	Time synchronization (GPS/PTP), coordinator	Deterministic latency, zero collisions, high efficiency	Requires infrastructure, wasted slots if no data, limited scalability
QoS/DSCP Marking	DiffServ architecture, router support	Traffic prioritization, latency guarantees	Requires configuration at every hop, no benefit without congestion

Application to IoT Design:

Low-power sensors (LoRa) → ALOHA (no coordination cost)
Mission-critical control (industrial) → TDMA (guaranteed delivery)
Dense deployments (smart buildings) → CSMA/CA + RTS/CTS + QoS (handle contention + prioritize critical)
Mesh networks with obstacles → RPL routing + RTS/CTS (cope with hidden terminals)

14.6 See Also

Routing Fundamentals - How packets find paths through multi-hop networks, RPL for IoT meshes
Transport Protocols - TCP vs UDP trade-offs, when to use each for IoT
LoRaWAN Fundamentals - ALOHA-based MAC in action, Class A/B/C devices
Wi-Fi Deep Dive - CSMA/CA with RTS/CTS in 802.11, hidden terminal mitigation
Zigbee and Thread - CSMA/CA over 802.15.4, TDMA-like GTS (Guaranteed Time Slots)
Quality of Service - DSCP marking, traffic shaping, priority queuing for IoT

Try It Yourself: Hidden Terminal Experiment

Objective: Observe hidden terminal collisions in a real Zigbee network and measure the impact of RTS/CTS.

Materials:

3× Zigbee devices (e.g., XBee or nRF52840)
1× Coordinator/gateway
Metal barrier (aluminum foil screen or filing cabinet)

Setup:

Lab Element	Placement
Node A	5 m from the gateway on one side
Gateway	In the centre, reachable by both nodes
Node C	5 m from the gateway on the opposite side
Metal barrier	Positioned so Node A and Node C cannot hear each other, while both can still reach the gateway

Experiment Steps:

Step	What to change	What to measure	Expected observation
Baseline test	No obstruction; both nodes can hear each other.	Gateway delivery rate.	About 95-98% delivery, allowing for normal wireless loss.
Hidden-terminal test	Place the metal barrier so Node A and Node C cannot hear each other.	Gateway delivery rate and retransmissions.	About 30-50% packet loss because both nodes transmit into the gateway at the same time.
RTS/CTS mitigation	Enable RTS/CTS or use a gateway setting that reserves airtime before data transmission.	Gateway delivery rate, airtime overhead, and latency.	Loss drops toward 10-15%; overhead rises slightly because control frames are added.

What to Observe:

Without RTS/CTS: Collision rate increases dramatically when nodes can’t hear each other
With RTS/CTS: Gateway’s CTS broadcast prevents simultaneous transmission
Trade-off: RTS/CTS adds ~3% overhead but prevents 20-40% collision loss

Hint: If your Zigbee hardware doesn’t support RTS/CTS toggle, use Wi-Fi with iw dev wlan0 set rts <threshold> on Linux to enable/disable RTS/CTS dynamically.

Solution pattern:

Test condition	Command idea	Evidence to record
RTS/CTS disabled	`iw dev wlan0 set rts off`	Throughput, packet loss, and retransmission rate with the hidden terminal present.
RTS/CTS enabled	`iw dev wlan0 set rts 100`	Throughput, packet loss, and any added latency after the gateway reserves airtime.
Decision	Compare both measurements.	Use RTS/CTS only when the collision reduction is larger than the control-frame overhead.

Extension: Try varying the RTS threshold (100, 500, 1500, 2346 bytes) and plot throughput vs overhead. Find the optimal threshold for your packet size distribution.

Common Pitfalls

1. Using a CCA Threshold That Is Too Sensitive

Setting the CCA threshold too low (detecting very weak signals as “busy”) causes unnecessary deferrals and reduces throughput, especially near the edge of coverage. Fix: calibrate the CCA threshold to a level that detects genuine transmissions in the deployment environment, not background noise.

2. Not Accounting for ACK Timeout in Latency Calculations

IEEE 802.15.4 requires an ACK within 192 µs. If no ACK arrives, the device retransmits up to 3 times. At worst, one packet delivery takes 4 × (transmission time + 192 µs). Fix: include the maximum MAC-layer retry delay in end-to-end latency budgets for time-critical applications.

3. Forgetting That MAC Layer Behaviour Varies Between Devices

Two “Zigbee” devices from different vendors may use different backoff ranges or retry counts, causing one to monopolise the channel. Fix: verify MAC parameters across all device vendors in a mixed deployment and normalise settings through coordinator configuration where possible.

14.6.1 Label the Diagram

14.6.2 Code Challenge

14.7 Summary

TCP congestion control interprets wireless packet loss as network congestion, causing severe throughput degradation on lossy IoT links
NAT allows IPv4 sharing but blocks inbound connections and creates complexity for peer-to-peer IoT
MAC protocols differ significantly: CSMA is fair but collision-prone; TDMA is deterministic but requires coordination; ALOHA is simple but low efficiency
Hidden terminals cause collisions that CSMA cannot detect - solve with RTS/CTS handshaking
QoS with DSCP marking ensures critical IoT traffic (alarms) gets priority over bulk transfers
Fragmentation increases effective loss rate - design for MTU constraints rather than fragmenting

14.8 What’s Next

Build on the MAC-layer concepts covered here by exploring the related chapters below:

Hands-on MAC labs: Networking Labs lets you simulate hidden-terminal collisions and RTS/CTS mitigation in practice.
Routing over IoT meshes: Routing Fundamentals shows how forwarding decisions build on MAC-layer delivery.
TCP vs UDP trade-offs: Transport Fundamentals explains when congestion-controlled TCP or lightweight UDP fits better.
LoRaWAN ALOHA in practice: LoRaWAN Overview shows why sparse long-range traffic can tolerate simpler access methods.
Wi-Fi CSMA/CA and RTS/CTS: Wi-Fi Fundamentals dives deeper into 802.11 channel access in dense deployments.
Zigbee TDMA slots: Zigbee Architecture covers 802.15.4 timing and deterministic slot behavior.