Wi-Fi & 802.11 · Study deck

Wi-Fi MAC Layer and Protocols

Picture a door sensor trying to report while several cameras use the same air.

Radio Remi is your guide for this deck.

wifi-maccsma-caframe-exchange
Radio Remi, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain how Wi-Fi MAC channel access shares airtime among IoT stations.
  • Connect backoff, ACK, retry, hidden-terminal, RTS/CTS, QoS, aggregation, and power-save evidence to service outcomes.
  • Separate MAC-layer evidence from application delivery evidence in readiness reviews.
  • Build validation records that tie contention, latency, freshness, and supportability to the actual workload.
iotclass.org

Major section

Start With the Wireless Story

Strong signal bars did not prove prompt delivery.

  • The medium access control rule decides when each Wi-Fi device may speak.
  • A protocol is an agreed set of message and timing rules.
  • Latency means the time from sending to a useful result.
  • Quality of service means rules that give some traffic different handling.

Why it matters

The sensor is close to the network base, yet its warning arrives late because every device must wait for a turn.

iotclass.org

Major section

The Wi-Fi MAC Layer Shares Airtime

The Wi-Fi MAC layer is the rule set that decides when a station may use the wireless channel.

  • In an IoT deployment, it connects radio behavior to product behavior: a sensor waits, transmits, receives an acknowledgment, retries if needed, sleeps, wakes, and eventually has to prove that the application received fresh enough data.
Use the MAC evidence map to keep the review layered: CSMA/CA and retry behavior explain the radio exchange, while application class and validation records decide whether the IoT workload is ready.
Use the MAC evidence map to keep the review layered: CSMA/CA and retry behavior explain the radio exchange, while application class and validation records decide whether the IoT workload is ready.
iotclass.org

Major section

The Wi-Fi MAC Layer Shares Airtime (continued)

A review should ask what workload is sharing the airtime, not just whether the device joined the AP.

  • The MAC evidence therefore sits between raw RF observations and service evidence.
  • The beginner mistake is to treat Wi-Fi like a private wire.
  • The map separates protocol evidence from the application-level acceptance claim.
iotclass.org

Major section

The Wi-Fi MAC Layer Shares Airtime (continued)

That record keeps the airtime claim tied to the workload, not the payload size.

  • Devices listen before transmitting, defer when the channel appears busy, use random backoff, and compete with other devices that may have different traffic classes, power states, and locations.
  • This layered reading connects shared-airtime mechanics to freshness, reliability, and energy requirements instead of judging the MAC by link rate alone.
  • Data, management, and control frames provide different evidence.
iotclass.org

Major section

The Wi-Fi MAC Layer Shares Airtime (continued)

Ten bytes sent at a quiet minute is easy; ten bytes sent by hundreds of devices at the same scheduled wake time can become a queue, a retry burst, or a stale dashboard.

  • The acceptance record should name the traffic class, expected freshness, AP profile, channel plan, retry observations, service outcome, and retest trigger.
  • If you only need the core idea, use this rule: a small payload does not make MAC behavior irrelevant.
  • Many small frames can still queue, collide, retry, or arrive too late when devices wake together.
iotclass.org

Major section

The Wi-Fi MAC Layer Shares Airtime (continued)

The station checks whether the medium appears free, waits when needed, and uses backoff so multiple stations do not all transmit at once.

  • Sleeping devices may delay downlink commands or buffered frames, so freshness and command response need their own evidence.
  • 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.
iotclass.org

Major section

Build a MAC Evidence Record

A practical MAC review starts with the traffic class, not the protocol feature.

  • The review should state which behavior is required, which evidence was observed, and which change would trigger retest.
  • A warehouse adds Wi-Fi sensors near metal racks.
  • The drawing distinguishes what each station can sense from what the access point or receiver must decode.
Hidden terminal: A transmits to B, but C -- out of A's radio range -- cannot sense the transmission and may transmit at the same time, colliding at B.
Hidden terminal: A transmits to B, but C -- out of A's radio range -- cannot sense the transmission and may transmit at the same time, colliding at B.
iotclass.org

Major section

Build a MAC Evidence Record (continued)

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.

  • 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 identifying hidden-node collisions, inspect Figure: Exposed terminal to see the opposite inefficiency: a station may defer even when a second transmission would not harm the first receiver.
  • This separates wasted airtime from packet collision.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs

MAC controls can improve a bounded problem, but they also create tradeoffs.

  • QoS can help selected latency-sensitive flows while failing if everything receives the same priority.
  • Aggregation can reduce overhead for compatible batches while increasing delay for traffic that needs immediate delivery.
  • RTS/CTS adds a short reservation exchange before the data frame.

Why it matters

RTS/CTS may reduce hidden-terminal collisions while adding control overhead.

CSMA/CA DCF timeline showing interframe spacing, a busy medium, and the randomized backoff before the next frame.
CSMA/CA DCF timeline showing interframe spacing, a busy medium, and the randomized backoff before the next frame.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

A compact throughput estimate separates three probabilities.

  • 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 timeline separates mandatory interframe waiting, another station's busy period, and the random backoff that follows.
  • The frame-level collision probability is approximately p = 1 - (1 - tau)^(n: 1).
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

The station's useful rate is not the PHY rate.

  • 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.
  • That sequence connects shared-channel rules to the latency and energy cost seen by an IoT frame.
  • The frame fields are part of the same evidence.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

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: RTS/CTS timeline across stations A across all four stations.
  • A maintenance tablet controls equipment while moving through a site.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

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.
  • A slot can be idle, successful, or collided; a busy slot includes preamble, payload airtime, SIFS, ACK time, and AIFS.
  • The review cannot approve the workflow from a single speed test.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

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.
  • Both reduce overhead for compatible batches, but neither makes tiny urgent messages free.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

RTS/CTS may reduce hidden-terminal collisions while adding control overhead.

  • 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.
  • The chart makes clear that the best backoff range depends on how many stations are active together.
  • A MAC acknowledgment means that a frame exchange reached the expected receiver at the link layer.
iotclass.org

Major section

Under The Hood: Protocol Controls Change Tradeoffs (continued)

A rising retry count may point to weak signal, channel contention, hidden terminals, rate adaptation, roaming, or synchronized wake bursts.

  • An 802.11 data frame carries frame control, duration, receiver/transmitter addressing, sequence control, optional fourth address, payload, and frame check sequence.
  • A useful review keeps link evidence, network evidence, service evidence, and product evidence in separate columns.
  • That trace is what stops a radio repair from masking a service problem.
iotclass.org

Deck summary

Key takeaways

Strong signal bars did not prove prompt delivery.

  • The Wi-Fi MAC layer is the rule set that decides when a station may use the wireless channel.
  • A review should ask what workload is sharing the airtime, not just whether the device joined the AP.
  • That record keeps the airtime claim tied to the workload, not the payload size.
  • Ten bytes sent at a quiet minute is easy; ten bytes sent by hundreds of devices at the same scheduled wake time can become a queue, a retry burst, or a stale dashboard.
iotclass.org

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1A team says an IoT sensor's Wi-Fi MAC behavior is safe because each telemetry payload is only a few bytes. What is the strongest review response?

AAccept the claim because small payloads cannot create contention or retries.
BEnable RTS/CTS globally and skip measurement.
CRequire evidence for wake timing, channel busy behavior, retries, ACK behavior.
DMove every IoT frame to the highest QoS class.
Show answer

Answer: C Small frames still compete for shared airtime and can fail during synchronized or congested periods.

iotclass.org

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2Two sensors can both reach the access point but cannot reliably hear each other across metal racks. Retries rise when they report together. Which action best fits a MAC-layer review?

ATreat RSSI to the AP as sufficient proof that both stations can avoid collisions.
BDisable acknowledgments so the retry counter stops increasing.
CMove background updates to the highest QoS class.
DRecord before-and-after evidence while testing AP placement, device grouping, channel changes.
Show answer

Answer: D Hidden-terminal symptoms need location-aware evidence and measured repair options.

iotclass.org

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3Why should a Wi-Fi MAC review keep ACK and retry evidence separate from application delivery evidence?

ABecause a link-layer exchange can succeed while the application still rejects, delays, duplicates.
BBecause a MAC ACK can serve as command completion evidence while retry counts remain radio diagnostics.
CBecause retries belong only in throughput tuning, while application logs should handle delivery faults.
DBecause successful application logs are enough to close a radio review after intermittent delivery problems.
Show answer

Answer: A MAC evidence is necessary but not sufficient for product readiness.

iotclass.org

Print reference

Answers

Answer key.

  1. C · Small frames still compete for shared airtime and can fail during synchronized or congested periods.
  2. D · Hidden-terminal symptoms need location-aware evidence and measured repair options.
  3. A · MAC evidence is necessary but not sufficient for product readiness.
iotclass.org