QBSS Load: the one IE your engineers never check

The ticket says the Wi-Fi is slow. Someone runs a speed test. It comes back at 400 Mbps and the ticket gets closed as user error. · ​

The speed test measured what one client could get when it won the medium. It said nothing about how often that client can win the medium at all. The AP has been broadcasting that second number, in every Beacon, roughly ten times a second, the entire time.

It is a single byte.

The element

BSS Load is Clause 9.4.2.26, IEEE Std 802.11-2024, page 1065. Figure 9-372 gives the format:

Seven octets total, five of payload. The standard describes it plainly: the element contains information on the current STA population and traffic levels in the BSS, and notes it might be used by the STA for vendor-specific AP selection when performing BSS transition.

That last clause is the part people miss. This element is not decoration. It is input to client roaming decisions.

The one byte that matters

Channel Utilization is defined as the percentage of time, linearly scaled with 255 representing 100%, that the AP sensed the medium was busy.

So the raw byte is not a percentage. Divide by 255:

If you have ever seen a dashboard report 128% utilisation, or a field labelled utilisation: 192, you have seen a tool print the raw byte and call it a percentage. It is not.

This is not a theoretical confusion. There is a Wireshark mailing list thread from 2010 in which an engineer reports expecting a 1 to 100 percentage and seeing values as high as 150 in his captures. The answer came back the same as above: normalised to 255, so 150 is 59%. Fifteen years later, tools still print the raw byte.

The formula, and why 1024 is in it

The standard gives the computation directly:

Three things are worth pulling out of that.

channel_busy_time is measured in microseconds during which the CS mechanism indicated busy. Not airtime you transmitted. Not airtime your clients transmitted. Any energy the receiver counted as busy, including the neighbour BSS two floors down and the microwave in the break room.

The 1024 is a unit conversion, not a fudge factor. dot11BeaconPeriod is in Time Units, and 1 TU is 1024 microseconds. Multiply beacon intervals by beacon period by 1024 and you have total elapsed microseconds in the measurement window. Numerator and denominator are both microseconds, the ratio is dimensionless, then it scales to 255.

The window is dot11ChannelUtilizationBeaconIntervals long. That is the number of consecutive beacon intervals over which busy time is accumulated, and it is a MIB variable. Two APs from different vendors, sitting side by side, seeing identical RF, can advertise different numbers because they average over different windows. Compare utilisation across vendors with that in mind.

The caveat that invalidates most wide-channel analysis

Straight from the standard:

Your 160 MHz BSS reports utilisation for 20 MHz of spectrum. Your 320 MHz Wi-Fi 7 BSS reports utilisation for 20 MHz of spectrum.

If the interference is sitting on a secondary channel, this byte will read clean while your clients are failing CCA on the wide channel and falling back to narrower bandwidth. The element is not lying. It is answering a narrower question than the one you asked.

Available Admission Capacity, and a free sanity check

The last two octets are the remaining medium time available via explicit admission control, in units of 32 µs/s.

That unit gives you a bounds check for free. One second is 1,000,000 microseconds, so:

Raw 31,250 is 100% of the medium available. Any value above that is impossible. If your capture shows Available Admission Capacity at 40,000 or 65,535, you are looking at an AP that either does not implement admission control and is padding the field, or a decoder that has the byte order wrong. It takes five seconds to check and it tells you whether to trust the rest of the element.

What to do with the number

The element rides in every Beacon and every Probe Response of a QoS BSS, so you do not need to catch a specific exchange. Any thirty seconds of capture in the affected area will do.

If you do not see the element at all, check WMM before you blame the AP. An AP advertises BSS Load only when QoS is enabled. On a Cisco WLC, setting the WLAN WMM policy to Allowed or Required is what turns the advertisement on. An AP with WMM disabled is not broken and not old, it simply has nothing to advertise.

Three filters. Note that Wireshark shows you the raw byte, not a percentage:

The first shows every frame carrying the field. The second isolates anything above 70%. The third is the pre-2.0 Wireshark field name, still worth knowing because most of the documentation you will find online predates the rename.

Under 40% (raw ~102) if you carry voice.

Voice is the tightest constraint and it moves the line well below the data thresholds below. Cisco's default Call Admission Limit is raw 105, which is 41%, and the practitioner consensus lands in the same place. If you run VoWiFi, 40% is your ceiling, not 50.

Under 50% (raw ~128) for data.

The medium is not your problem. Look at retries, MCS selection, RSSI at the client, DHCP, DNS, upstream.

50 to 70% (raw 128 to 178).

Contention is real. Client throughput is already degraded even though every individual link looks healthy. Speed tests will still pass, because a speed test is one greedy station taking what it can.

Above 70% (raw 178+).

Adding APs on the same channel makes this worse, not better. Look at the channel plan, legacy protection, and what is generating the traffic before you buy hardware.

And check it per AP, not per site. One AP at 87% in a lecture theatre is invisible in a site-wide average of 30%.

The trap that cost me a day

BSS Load is 9.4.2.26. The element immediately after it, 9.4.2.27 on page 1066, is the EDCA Parameter Set element. Different element, different purpose, adjacent clause numbers, both QoS-related, both riding in Beacons.

I found nine citations in my own codebase that pointed at 9.4.2.27 and labelled it BSS Load. Nine. In the same file, one line already had it right as 9.4.2.26, which is how the error survived: it looked internally inconsistent in a way that reads like sloppiness rather than error, so nobody followed the number to the page.

Both clauses exist. Both are real elements. A citation that points at a real thing about a different subject is far more durable than one that points at nothing, because it survives every check short of actually opening the standard. If you have BSS Load parsing in your own tooling, the clause is 9.4.2.26, page 1065 of IEEE Std 802.11-2024. Worth two minutes.

A second trap, one layer down

The clause number is not the only thing that collides. Cisco shipped a pre-standard QBSS Load V1 that occupies the same Element ID as the 802.11e element, with a different payload layout. That is precisely why the two are mutually exclusive on Cisco APs: you get one or the other, never both, because they cannot coexist in the same ID. A later V2 adds a Call Admission Limit field on top.

So a parser that sees the element ID and immediately assumes the five-octet 802.11e layout will happily misread a V1 element and produce a plausible, wrong number. Same shape as the clause confusion: the failure is silent because every intermediate step looks valid. If your decoder handles this element, check what it does when the length field does not match what it expected.

The short version

• Channel Utilization is one byte, scaled to 255, not 100.
• The measurement window is vendor-configurable. Compare with care.
• It covers the primary 20 MHz only, whatever your channel width.
• Available Admission Capacity above 31,250 is impossible. Free decoder check.
• Voice ceiling is 40% (raw ~102), not 50%. Cisco's default CAC limit is raw 105.
• No element usually means WMM is off, not that the AP is old.
• Element ID collides with Cisco's pre-standard V1. Check the length before trusting the layout.
• It is in every Beacon and Probe Response. You have already captured it.