“Imagine a classroom where everyone wants to talk,” said Sammy the Sensor. “CSMA/CA is like raising your hand and waiting for silence before speaking. If you hear someone else talking, you WAIT!”
“But what about the HIDDEN TERMINAL problem?” asked Lila the LED. “That is when two students on opposite sides of the room cannot hear each other, so they both start talking at the same time and the teacher in the middle hears a jumble!”
“RTS/CTS fixes that!” explained Max the Microcontroller. “Before speaking, you ask the teacher ‘May I speak?’ (RTS). The teacher says ‘Go ahead!’ (CTS) loud enough for EVERYONE to hear. Now the other student knows to wait!”
“And QoS is like having a priority list,” added Bella the Battery. “Emergency announcements (Voice) go first, show-and-tell (Video) goes second, regular questions (Best Effort) go third, and homework collection (Background) goes last. That way the important stuff always gets through!”
By the end of this chapter, you will be able to:
The MAC layer controls how devices share the wireless channel – who gets to transmit, when, and for how long. This chapter covers the protocols that make Wi-Fi work smoothly even when hundreds of devices compete for airtime. Understanding the MAC layer helps you troubleshoot slow networks and optimize IoT device performance.
Before diving into this chapter, you should be familiar with:
In one sentence: Wi-Fi uses CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) to share the wireless medium, with RTS/CTS handshakes solving hidden terminal problems and QoS providing priority-based channel access.
Remember this rule: CSMA/CA listens before transmitting, RTS/CTS reserves the channel, and QoS ensures time-sensitive traffic (voice, video) gets priority over bulk data transfers.
Deep Dives:
Architecture Context:
Learning Resources:
Wi-Fi uses CSMA/CA to share the medium. Hidden and exposed terminal problems can cause collisions or unnecessary backoff; RTS/CTS can mitigate hidden terminals. QoS and MAC performance depend on contention, interference, and client mix.
This variant shows the same three Wi-Fi architectures from a spatial coverage perspective - emphasizing how each mode extends or limits coverage area.
Key Insight: Choose architecture based on coverage needs: Infrastructure for single room with good AP placement, Wi-Fi Direct for temporary device-to-device links, Mesh for large areas with multiple rooms or floors. Mesh eliminates dead zones through overlapping coverage.
Characteristics:
The 802.11 frame structure adds significant overhead to small IoT packets. For a 100-byte sensor payload, the MAC overhead is substantial:
\[\text{Total Frame Size} = \text{MAC Header} + \text{Payload} + \text{FCS}\]
Worked example (temperature sensor): A sensor sends 100 bytes of data every 5 minutes: - MAC header: 28 bytes (no QoS) or 30 bytes (with QoS) - Payload: 100 bytes - FCS: 4 bytes - Total: 132-134 bytes frame size
The overhead percentage is \(\frac{32}{132} \times 100\% = 24.2\%\) of the frame. For very small IoT payloads (e.g., 20 bytes), overhead reaches \(\frac{32}{52} \times 100\% = 61.5\%\) – more than half the airtime is spent on headers, which is why OFDMA frame aggregation in Wi-Fi 6 helps IoT efficiency.
Characteristics:
Characteristics:
Scenario: A smart warehouse deploys 30 ESP32-based inventory sensors on a single Wi-Fi 4 (802.11n) access point operating at 65 Mbps PHY rate on 2.4 GHz. Each sensor sends a 200-byte inventory status update every 5 seconds. During shift changes, all sensors report simultaneously. What is the effective throughput and how much airtime does IoT traffic consume?
PHY rate: 65 Mbps (MCS 7, 20 MHz, 1 spatial stream)
MAC header: 36 bytes (QoS data frame)
Payload: 200 bytes
FCS: 4 bytes
Total frame: 240 bytes = 1,920 bits
Data transmission time: 1,920 / 65,000,000 = 29.5 microseconds
CSMA/CA overhead per frame:
DIFS: 50 microseconds (802.11n, 2.4 GHz)
Average backoff: 67.5 microseconds (CWmin=15, slot=9us, avg = 15/2 x 9)
SIFS: 10 microseconds
ACK: 14 bytes at 6.5 Mbps = 17.2 microseconds
Total overhead: 50 + 67.5 + 10 + 17.2 = 144.7 microseconds
Total airtime per frame: 29.5 + 144.7 = 174.2 microseconds
MAC efficiency: 29.5 / 174.2 = 16.9%30 sensors transmitting simultaneously:
All 30 sense channel busy, enter backoff
Average contention resolution time per frame:
With 30 contenders, collision probability per slot = 1-(1-1/16)^30 = 86%
Expected collisions before success: ~2-3 per frame
Each collision doubles CW: CWmin=15 -> 31 -> 63
Average successful frame delivery: ~800 microseconds
Total burst duration: 30 x 800 = 24,000 microseconds = 24 ms
Burst throughput: (30 x 200 x 8) / 0.024 = 2.0 Mbps effective
Efficiency during burst: 2.0 / 65 = 3.1% (contention overhead dominates)Without RTS/CTS (default for small frames):
Collision wastes: full frame time (174 microseconds)
At 30 contenders: ~14 collisions during burst
With RTS/CTS enabled (threshold = 0 bytes):
RTS: 20 bytes at 6.5 Mbps = 24.6 microseconds
CTS: 14 bytes at 6.5 Mbps = 17.2 microseconds
Additional overhead per frame: 24.6 + 10 + 17.2 + 10 = 61.8 microseconds
But collision only wastes RTS (24.6 us), not full frame
Net effect for 200-byte frames: RTS/CTS HURTS performance
(overhead 61.8 us > saved collision cost for small frames)
RTS/CTS breakeven: frames > ~1,000 bytes at this contention levelWithout QoS: All 30 sensors use AC_BE (Best Effort)
AIFS = DIFS + 2 x slot = 50 + 18 = 68 microseconds
CWmin = 31, CWmax = 1023
With QoS: Sensors assigned to AC_BK (Background)
AIFS = DIFS + 7 x slot = 50 + 63 = 113 microseconds
CWmin = 31, CWmax = 1023
Frees channel priority for VoIP phones (AC_VO) and cameras (AC_VI)
Result: IoT sensors yield to real-time traffic during contention,
preventing warehouse VoIP quality degradation during sensor burstsKey Insight: For small IoT payloads (200 bytes), CSMA/CA overhead dominates – MAC efficiency drops to 3-17% depending on contention. RTS/CTS makes things worse for small frames. The practical solution is QoS classification: assign IoT telemetry to AC_BK (Background), reserving channel priority for latency-sensitive traffic like voice and video.
Understanding CSMA/CA overhead is not just academic – it determines how many IoT devices a single access point can practically support. Many deployments fail because engineers calculate only data throughput and ignore MAC-layer contention overhead.
Consider a practical scenario: a greenhouse monitoring system with ESP32 sensors reporting temperature, humidity, and soil moisture every 60 seconds.
Per-sensor traffic profile:
Payload: 64 bytes (3 sensor values + metadata)
802.11 overhead: 36 bytes MAC + 20 bytes IP + 8 bytes UDP = 64 bytes headers
Total frame: 128 bytes = 1,024 bits
TX time at 24 Mbps (typical for ESP32): 42.7 microseconds
CSMA/CA overhead: ~145 microseconds (DIFS + backoff + SIFS + ACK)
Total airtime per transmission: 187.7 microsecondsTheoretical capacity per AP:
Available airtime per 60-second window: 60,000,000 microseconds
Usable airtime (accounting for management frames, beacons, retries): ~70%
Effective airtime: 42,000,000 microseconds
Maximum transmissions per minute: 42,000,000 / 187.7 = 223,760
With 10% collision rate at high density: ~200,000 usable slots
Sensors reporting 1x per minute: 200,000 sensors (theoretical maximum)Why the real limit is much lower:
The theoretical calculation above assumes perfect scheduling. In practice, CSMA/CA random backoff causes collisions when many devices contend simultaneously. The real constraint is the burst collision window – what happens when 50+ sensors all wake from sleep and contend at approximately the same moment?
50 sensors waking within a 2-second window:
Collision probability per slot: 1-(1-1/16)^50 = 96%
Average successful delivery time: 1,200 microseconds per frame
Total burst resolution: 50 x 1,200 = 60,000 microseconds = 60ms
This is fine -- all 50 complete within the 2-second window
200 sensors waking within a 2-second window:
CW escalation after repeated collisions: CWmin=15 -> 31 -> 63 -> 127
Average successful delivery: 4,800 microseconds per frame
Total burst resolution: 200 x 4,800 = 960,000 microseconds = 960ms
Still within 2-second window, but some sensors timeout at 500ms
500 sensors waking within a 2-second window:
Severe contention -- many frames exceed retry limit (7 retries)
10-15% packet loss, requiring application-layer retry
Effective resolution time: 3-5 seconds (exceeds window)Practical guideline: For battery-powered ESP32 sensors using timed wake + transmit patterns, limit to 100–150 devices per 2.4 GHz AP and stagger wake times using random jitter of 0–10 seconds to spread contention. For 5 GHz with wider channels, this scales to 200–300 devices.
A common mistake in Wi-Fi IoT system design is selecting hardware based on PHY data rate (e.g., “we need Wi-Fi 5 for better throughput”). For IoT devices sending small, infrequent packets, the PHY rate is almost irrelevant – MAC layer overhead dominates total airtime. Understanding this relationship prevents over-specifying hardware and reveals the true bottleneck.
Airtime breakdown for a 100-byte IoT sensor reading at different PHY rates:
| Component | Wi-Fi 4 (24 Mbps) | Wi-Fi 5 (433 Mbps) | Wi-Fi 6 (1200 Mbps) |
|---|---|---|---|
| DIFS wait | 50 us | 34 us | 34 us |
| Random backoff (avg) | 67 us | 67 us | 67 us |
| Preamble + headers | 36 us | 44 us | 52 us |
| Data transmission | 33 us | 1.8 us | 0.7 us |
| SIFS | 10 us | 16 us | 16 us |
| ACK | 24 us | 24 us | 24 us |
| Total airtime | 220 us | 187 us | 194 us |
| MAC efficiency | 15% | 1.0% | 0.4% |
The counterintuitive result: Wi-Fi 6 at 1200 Mbps uses nearly the same total airtime as Wi-Fi 4 at 24 Mbps for a 100-byte IoT packet. The data transmission shrinks from 33 us to 0.7 us, but the fixed MAC overhead (DIFS, backoff, preamble, SIFS, ACK) remains 150–190 us regardless of PHY rate. The actual data occupies less than 1% of the total frame exchange time.
What this means for IoT deployments:
Upgrading from Wi-Fi 4 to Wi-Fi 6 does not meaningfully increase the number of small-packet IoT devices an AP can support. The bottleneck is MAC contention slots, not data transmission time.
Wi-Fi 6’s real IoT benefit is OFDMA, not speed. OFDMA allows multiple small IoT packets to be scheduled in a single OFDM symbol, eliminating the per-device DIFS/backoff/ACK overhead. With OFDMA, 9 IoT devices can transmit 100-byte packets in the airtime that one device uses with CSMA/CA.
RTS/CTS overhead is proportionally devastating for small packets. Adding RTS/CTS to a 100-byte payload adds 62 us of overhead (28% increase in total airtime) for a payload that takes only 0.7–33 us to transmit. RTS/CTS only breaks even for payloads above ~1,000 bytes.
Practical guideline: For IoT networks where most traffic is small sensor readings (<256 bytes), focus AP selection on OFDMA support (Wi-Fi 6), client density (number of associated stations), and QoS classification – not on PHY data rate. A Wi-Fi 4 AP at 72 Mbps can serve the same number of small-packet IoT devices as a Wi-Fi 6 AP at 1200 Mbps when OFDMA is not utilized.
Explore how payload size, PHY rate, and number of contending devices affect MAC efficiency and total airtime.
Understanding how these MAC layer concepts relate to each other:
| Concept | Depends On | Enables | Trade-off |
|---|---|---|---|
| CSMA/CA | Carrier sense, DIFS/SIFS timing | Fair channel access | Overhead vs collision avoidance |
| RTS/CTS | Hidden terminal detection | Collision-free reservation | Airtime overhead vs reliability |
| QoS Access Categories | 802.11e support, AIFS config | Priority-based channel access | Fairness vs latency requirements |
| Frame Aggregation | AMSDU/AMPDU support | Reduced per-frame overhead | Buffer requirements vs efficiency |
| Contention Window | Binary exponential backoff | Collision reduction at scale | Delay vs fairness |
RTS/CTS adds 4 additional frame exchanges before every transmission. For small frames (< 500 bytes), RTS/CTS overhead exceeds any hidden-node benefit. Only enable RTS/CTS for large frames or in known hidden-node environments.
802.11 uses SIFS (ACK, CTS) < PIFS (PCF) < DIFS (normal data) < EIFS (after error). Devices always wait the appropriate IFS before transmitting. Misunderstanding this hierarchy causes incorrect protocol behavior analysis.
An 802.11 ACK only confirms the frame was received by the peer MAC layer. It does not guarantee the frame was passed to the application, processed correctly, or forwarded to the next hop. Application-level confirmation requires end-to-end acknowledgment.
A-MPDU aggregation combines small frames into one large transmission (improves throughput). Fragmentation breaks large frames into smaller pieces (improves reliability in noisy channels). Enabling fragmentation with aggressive thresholds disables aggregation benefits.
This chapter covered Wi-Fi MAC layer and protocol fundamentals:
For deeper exploration of related topics:
| If you want to… | Read this |
|---|---|
| Review channel analysis and utilization | Wi-Fi Channel Analysis |
| Learn Wi-Fi architecture and topology | Wi-Fi Architecture Fundamentals |
| Understand Wi-Fi 6 MAC improvements | Wi-Fi 6 Features |
| Apply MAC knowledge to IoT apps | Wi-Fi MAC Layer and IoT Applications |
| Deploy Wi-Fi practically | Wi-Fi Deployment Planning |