Before OFDMA, every wifi frame was a private conversation: one client, the entire channel, for as long as it took to send a thing that may have been six bytes long. ref 0x01 A fleet of chatty 2.4 GHz IoT clients could melt a 20 MHz channel from sheer airtime contention, not throughput.
802.11ax did something that looks mundane in the spec sheet and is, in practice, the single biggest thing that has happened to dense-client wifi in a decade. It split the channel into resource units — the smallest is 26 tones, ~2 MHz wide at the 11ax subcarrier spacing of 78.125 kHz — and lets the AP hand each one to a different client in the same transmit window.
what actually changes
The AP becomes a scheduler. It sends a Trigger frame announcing “everyone with traffic, here are your RUs,” and N clients respond in lockstep with a multi-user uplink. ref 0x03 Capture this once and the elegance sinks in. What used to be N back-to-back conversations is now one.
$ tcpdump -ni wlan0mon -c 8 type ctl subtype trigger 12:42:08.412 trigger ru-alloc: 484/242/242 80MHz · ch149 12:42:08.416 mu-ul sta-04: 1480 B · sta-09: 312 B · sta-21: 96 B 12:42:08.421 mu-block-ack 12:42:08.427 trigger ru-alloc: 996 full-channel SU 12:42:08.431 mu-ul sta-12: 4096 B ...
The headline win is not raw throughput — it is airtime efficiency. A 64-byte status update from a thermostat used to monopolize the entire channel for the duration of its PHY preamble plus MAC overhead. Now it gets a 2 MHz tube alongside up to eight other small clients in the same TXOP and the channel is free again before the next trigger.
the four ways it quietly breaks
1. uplink discipline
Trigger-based MU-UL only works if clients shut up between triggers. ref 0x02 Some legacy NICs cheerfully ignore this and keep doing EDCA contention — the AP allocates them an RU they never use, while their un-scheduled frames step on the muUL window. The fix is a quiet allow-list of well-behaved clients per SSID; the policy lever is usually named something like ofdma-ul-allowed-stas.
2. RU fragmentation under puncturing
80 MHz cleanly tessellates into the well-known RU sizes from 11ax Table 27-7. 160 MHz does not when DFS holes force preamble puncturing — and 11ax’s puncturing is far more restricted than the patterns 11be later opened up. In the wild, expect the AP to fall back to single-user 80 MHz operation under puncturing more often than the marketing slide suggests.
3. small-frame starvation
The scheduler optimizes for fairness, not for your latency-sensitive client. A camera streaming H.264 will pull a 996-tone RU happily; an unmanaged wifi-to-cloud bridge uploading 64-byte presence frames often waits a full beacon interval (default 102.4 ms at 100 TU) for a 26-tone slot. ref 0x04 This is fine, until it is not — TWT exists precisely for this class of client.
“OFDMA fixed the bandwidth problem nobody had and made the airtime problem everyone had finally tractable.” — unattributable, but correct.
4. vendor knobs
Three vendors, three different exposures of the same primitive. ref 0x05 Aruba’s per-radio OFDMA mode, Mist’s AI-RRM RU planner, and Cisco’s RRM-driven OFDMA scheduling (which is not FRA — that’s Flexible Radio Assignment, a dual-band radio knob) are not the same lever; treating them as one will lead to a deployment that performs differently in three rooms of the same building.
so should you turn it on
Yes. With caveats. The cleanest deployments we’ve seen flip OFDMA on per-radio, leave MU-MIMO off until the client mix justifies the sounding overhead, and treat the muUL allow-list as a living configuration. The wrong defaults will not melt your network — they will just leave 30% of your headline number on the floor.
We will return to BSS coloring and spatial reuse in the next transmission. Those two primitives are where 11ax stops being a story about your campus and starts being a story about your neighbour’s AP, too.