13 Wi-Fi MAC Layer and Protocols

13.2.1 Beginner MAC Pieces

13.2.6 Beginner Example

A room sensor that uploads ten bytes every minute can still fail a MAC review if every sensor wakes at the same time. The payload is small, but the evidence must cover wake timing, channel busy behavior, retries, service acceptance, stale-data state, and what the user sees when reports arrive late.

13.2.7 Overview Knowledge Check

13.3.1 How It Works: MAC Review Route

First, Name the traffic. Record whether it is periodic, bursty, event-driven, live, bulk, diagnostic, or setup traffic. Next, Inspect channel access. Look for busy-channel behavior, retry trends, latency, synchronized wake periods, and AP load. Then, Separate link evidence from service evidence. ACKs and retries are not the same as application acceptance, command execution, or dashboard freshness. After that, Test targeted controls. Use placement, channel choices, traffic staggering, scoped RTS/CTS, QoS, aggregation, or power-state changes only where the evidence justifies them. Finally, Record the decision. Include limits, owner, support observations, and the retest trigger for firmware, AP profile, site, or workload changes.

13.3.2 Intermediate Example

A warehouse adds Wi-Fi sensors near metal racks. RSSI to the AP looks acceptable, but retry rate rises when devices on opposite sides of the racks report together. A reviewable response tests AP placement, device grouping, channel changes, traffic staggering, or scoped RTS/CTS and compares retries, latency, delivery, and user-visible freshness before accepting a repair.

To diagnose the warehouse retries, inspect Figure 13.2 before changing transmit power or channels. The drawing distinguishes what each station can sense from what the access point or receiver must decode.

+

Read Figure 13.2, trace A’s transmission toward B, then note that C lies outside A’s sensing range but can still reach B. C may therefore transmit while B is receiving A, connecting the rack-separated geometry to collisions that good RSSI at each client does not reveal.

After finding hidden-node collisions, inspect Figure 13.3 to ask when a station wastes airtime by waiting even though its send would not harm the first receiver.

+

Read Figure 13.3 from B’s transmission toward A, then inspect what C can hear. C senses B and defers even though its own transmission to D would not interfere at A, so the medium loses a safe reuse opportunity. Compare that silence with the hidden-terminal case, where a sender cannot hear the competing transmitter and causes a collision at a shared receiver. The two diagrams show opposite errors caused by local carrier-sense geometry: one permits too much simultaneous traffic, while the other suppresses traffic that could have succeeded.

13.3.3 MAC Evidence Ledger

13.3.4 Practitioner Knowledge Check

13.4.1 DCF Timing And Frame Evidence

For deeper reviews, treat the 802.11 distributed coordination function as a timing ledger. A station waits for the required interframe space, chooses a random backoff from the current contention window, freezes that counter while the medium is busy, and retries with a larger window after a collision. The default contention window is only a starting point; the useful question is whether the selected access category, contention window, retry limit, and transmit opportunity match the number of contenders and the traffic promise.

Before interpreting retries, inspect Figure 13.4 to follow one station’s access delay in time. The timeline separates mandatory interframe waiting, another station’s busy period, and the random backoff that follows.

+

The stepping stones turn the timeline’s backoff counter into a visible path. Watch what happens to the remaining stones when a second radio uses the lane.

The timer finishes before Remi draws a random set of stones. Another radio takes the lane, so Remi stops on the same stone instead of using up the count. When the lane clears he resumes; the final clash widens the next set of choices. The timeline above shows those same pauses as airtime.

Read Figure 13.4 left to right: after an interframe wait, a busy medium makes the station wait for another clear interframe interval before starting randomized backoff. The separate backoff ledger below shows what happens when a busy medium interrupts an in-progress countdown.

RTS/CTS adds a short reservation exchange before the data frame. The sender asks for the medium with Request to Send, the receiver answers with Clear to Send, and nearby stations that overhear either control frame treat the announced duration as busy in their Network Allocation Vector. That virtual carrier-sense state is why RTS/CTS can reduce some hidden-terminal collisions, while still adding control overhead that has to be justified by before-and-after retry and latency evidence.

To understand why carrier sensing alone cannot solve hidden terminals, inspect Figure 13.5 across all four stations. The control exchange reserves time for nodes that hear different parts of the conversation.

+

Read Figure 13.5, follow B’s RTS to C, C’s CTS back to B, then DATA and ACK; meanwhile compare A, which hears RTS, with D, which hears CTS. Both set their virtual carrier-sense timer, connecting reservation signalling to fewer collisions around the receiver.

A compact throughput estimate separates three probabilities. Let tau be the probability that one station transmits in a randomly chosen slot, and let n be the number of contending stations. The frame-level collision probability is approximately p = 1 - (1 - tau)^(n - 1). The expected number of attempts before success is 1 + p + p^2 + … + p^K for a retry limit K. The expected backoff slots depend on the backoff stage, for example b_k = 2^k CWmin / 2 before any maximum-window cap is applied.

The station’s useful rate is not the PHY rate. It is useful payload over expected slot time. A slot can be idle, successful, or collided; a busy slot includes preamble, payload airtime, SIFS, ACK time, and AIFS. For equal-length packets at one PHY rate, a useful review can write the shape as S = useful payload / E[slot] and then test whether observed retry, busy-time, and latency evidence agree with that model. If the model says the window is too small for the contender count, the repair may be traffic staggering, AP/channel changes, QoS tuning, or a different radio plan rather than simply increasing transmit power.

The two contention plots below use one explicit illustrative model, so their optima are reproducible. Assume saturated stations, one fixed contention window, a uniform backoff counter, 3,000 useful payload bits, an idle slot of $\sigma=9\,\mu\mathrm{s}$, a successful busy time of $T_s=320\,\mu\mathrm{s}$, and a collision time of $T_c=270\,\mu\mathrm{s}$. Then

and

Evaluating $CW\in\{16,32,64,128,256,512,1024\}$ gives the five-station maximum at $CW=32$: 7.79 Mbit/s, compared with 7.61 Mbit/s at 64. For 30 stations the same calculation peaks at $CW=256$ with 7.67 Mbit/s. These are model-specific teaching optima, not universal 802.11 settings; frame length, PHY timing, retry-stage growth, QoS category, and offered load can move them.

Light and heavy contention peak at different contention-window settings in Figure 13.6.

+

Read Figure 13.6, follow the five-station curve to its earlier peak, then compare the thirty-station curve whose optimum shifts toward a larger window. Small windows waste airtime in collisions under load, while oversized windows waste idle slots, linking contention tuning to useful payload throughput.

The frame fields are part of the same evidence. An 802.11 data frame carries frame control, duration, receiver/transmitter addressing, sequence control, optional fourth address, payload, and frame check sequence. Frame-control bits such as type, subtype, To DS, From DS, retry, power management, and protected-frame state explain whether a capture is showing association traffic, data transfer, retry behavior, roaming, or security handling. Aggregation changes the evidence again: A-MPDU aggregation batches MPDUs with block acknowledgments, while A-MSDU aggregation packs several payloads under one MAC header. Both reduce overhead for compatible batches, but neither makes tiny urgent messages free.

Not every frame competes through the same queue, either. Wi-Fi Multimedia (WMM) defines four Access Categories — Voice, Video, Best Effort, and Background — with different contention parameters, so a capable station can prioritize its latency-sensitive traffic. Multicast and broadcast frames follow a separate rule: if any client is asleep, the AP holds them and sends them right after each DTIM beacon, and many chipsets keep a dedicated after-beacon queue (and a beacon slot) for this, although the standard does not require that queue layout. Reviewing a QoS claim means checking which access category the client driver actually assigns to the traffic in question, not just confirming that the AP advertises support for all four — a sensor stack that tags everything Best Effort gets no benefit from an AP that implements the rest.

13.4.2 Why ACKs, Retries, And Applications Must Stay Separate

A MAC acknowledgment means that a frame exchange reached the expected receiver at the link layer. It does not prove that the application parsed the payload, stored the reading, executed a command, updated a dashboard, or recovered from a duplicate. A useful review keeps link evidence, network evidence, service evidence, and product evidence in separate columns.

The same separation applies to retry counters. A rising retry count may point to weak signal, channel contention, hidden terminals, rate adaptation, roaming, or synchronized wake bursts. The MAC layer can report symptoms, but the release decision needs a joined trace: AP or sniffer observation, device log, service timestamp, user-visible state, and final application outcome. That trace is what stops a radio repair from masking a service problem.

13.4.3 Advanced Example

A maintenance tablet controls equipment while moving through a site. The review cannot approve the workflow from a single speed test. It needs route evidence, busy-channel behavior, reassociation or reconnect events, command response, stale-state display, and support logs that can explain whether a failure came from channel contention, roaming, security, service delivery, or the application. If RTS/CTS, QoS, aggregation, or power-save tuning is changed, the record should show the before/after symptom, the user-visible outcome, and when to roll the change back.

13.4.4 Failure-Boundary Checks

13.4.9 Try It: MAC Readiness Sentence

Write one sentence for a device class: “This MAC behavior is accepted for this traffic class, on this AP profile and channel plan, with this retry and latency evidence, these service outcomes, these support observations, and this retest trigger.” If the sentence cannot be completed, the readiness claim is still too broad.

13.4.10 Under-The-Hood Knowledge Check