QBSS Load: the one IE your engineers never check
Someone runs a speed test. 400 Mbps. Ticket closed as user error.The speed test measured what one client got when it won the medium. It saidnothing about how often that client can win the medium at all. The AP has beenbroadcasting that second number in every Beacon and every Probe Response,roughly ten times a second, the whole time.It is one byte. And it is scaled to 255, not 100.Raw 222 is 87 percent. Raw 128 is 50 percent. If you have ever seen a dashboardreport "128% utilisation," you have seen a tool print the raw byte and call ita percentage. The filter is wlan.qbss.cu, and Wireshark shows you the raw bytetoo.Four things in the post that most explainers skip:- The 1024 in the formula is a TU to microsecond conversion, not a fudge factor- The measurement window is a MIB variable, so cross vendor comparison is unsound- Available Admission Capacity above 31,250 is arithmetically impossible, which gives you a free decoder sanity check- If you cannot see the element at all, check WMM before you blame the APTwo traps in there as well. BSS Load is Clause 9.4.2.26. The elementimmediately after it, 9.4.2.27, is the EDCA Parameter Set. I found ninecitations in my own codebase pointing at 9.4.2.27 and labelled BSS Load. Nine.They survived because no gate in that project ever read that file, so nothingcompared the number to the page.The second one is worse. Cisco's pre standard QBSS Load V1 sits on the sameElement ID as the 802.11e element with a different payload. A parser that seesthe ID and assumes the standard layout will misread it and return a number thatlooks fine.Read it here:https://shankarwifi.com/writing/qbss-load-channel-utilisation/On cadence. The last post went up in June and I said one every two weeks. Thathas not held. Saying so rather than going quiet about it.Shankar
