QBSS Load: the one IE your engineers never check
"The AP is broadcasting its utilisation in every Beacon frame. Your engineers are running speed tests." ·
The call came in at 11am. Wi-Fi was slow in the open-plan office. The AP was showing green on the dashboard. Three engineers had already run speed tests and confirmed throughput was degraded. Nobody had opened a Beacon frame.
I pulled a PCAP. Filtered to Beacons from the problem AP. Element ID 11 — QBSS Load — was right there. Channel Utilisation: 0xD8. That is 216 out of 255. 85% channel utilisation. The AP was not broken. The AP was saturated. It had been telling us exactly that in every Beacon for four hours.
What QBSS Load contains
Element ID 11, 5 bytes:
Channel Utilisation (1B) — 0 to 255, divide by 255 for percentage
Available Admission Capacity (2B) — in 32 µs TXOP units
Channel Utilisation counts the fraction of time the medium was detected busy — including neighbouring APs on the same channel. This is not "how busy is the AP." It is "how busy is the channel." Those require completely different fixes.
Two filters
Frames containing QBSS Load IE. Expand Tagged parameters → BSS Load element → read Channel Utilization.
Beacons where utilisation exceeds 200/255 (~78%). Sustained above 160/255 in a production office is worth investigating.
Own BSS vs OBSS
Filter wlan.bssid == [your AP] and check frame density. If most frames are from other BSSIDs, this is co-channel contention — channel reassignment or BSS Color, not AP tuning. If it is your own clients at low MCS, check coverage and client density.
802.11v uses this data
BTM Requests include QBSS Load of candidate APs in the Neighbor Report. A client rejecting a BTM steer toward a 90% utilisation AP is correct behaviour — not a roaming failure.