On Wed, Nov 03, 2021 at 04:03:08PM +0300, Sergey Ryazanov wrote: > Hello Stefan, > > On Sun, Oct 31, 2021 at 9:25 PM Stefan Sperling <s...@stsp.name> wrote: > > Some access points advertise BSS load information in beacons in > > order to help clients make informed roaming decisions. > > > > BSS load information includes the number of associated stations, > > the channel utilization (this takes other networks on the same > > channel into account), and current admission capacity (interesting > > for clients which use QoS, which we do not). > > > > We currently ignore BSS load information and only use RSSI to tell APs > > apart. With this patch we store bss load information for APs during > > scans if available, and take it into account when chosing an access point. > > > > Unfortunately, I do not have a suitable AP available to test with. > > tcpdump can be used to check whether an access point supports this > > feature. Run this command while associated to the access point: > > tcpdump -n -i iwm0 -y IEEE802_11_RADIO -s 4096 -v > > > > If the AP reports BSS load information you should see something like > > this among the information printed by tcpdump: > > 64 stations, 100% utilization, admission capacity 0us/s > > > > It would help to get this patch tested in an environment where access > > points advertise BSS load information, with a roaming test between > > different access points. > > I wrote down information about how roaming can be tested here: > > https://marc.info/?l=openbsd-tech&m=163329420019842&w=2 > > This topic was discussed a couple of weeks ago on the hostapd mailing > list (http://lists.infradead.org/pipermail/hostap/2021-October/039961.html). > And Jouni Malinen provide a few concerns about switching to the QBSS > load IE usage. I would like to quote him: > > > I would also point out that at least the last time I did some testing > > between vendor implementations, the reported values were completely > > different between two APs on the same channel in more or less the same > > location in the test setup.. In other words, I would not place much, if > > any, trust in this value being something that could be compared between > > two different APs. The only thing that seemed to be more or less > > comparable was the values from the same AP device in a sense that the > > channel load value increased when there was more traffic on the > > channel.. > > So I do not think that the complete switching to the BSS load metric > is a good idea. But utilizing the AP assistance in the BSS selection > procedure sounds nice.
I wasn't aware of this research that was done at hostapd. This is good to know and might save us some time in figuring out how to use these metrics properly. Thanks! My patch ignores RSSI on purpose in case BSS load is advertised precisely because we need to figure out whether "channel load" is indicated reliably. The standard doesn't really go into much detail about how to decide whether a channel is "busy". It suggests that either virtual or physical carrier sense could be used. I guess just letting any faint but valid wifi signal block the channel would be a bad idea. So vendors may need to use some threshold to decide whether a given signal is actually keeping the channel busy in the vicinity of the AP. As with RSSI, measurements of such physical quantities could differ between any two given APs and between moments in time for a single AP. If channel load is not a reliable indicator I would hope vendors are at least able to reliably count and report the number of associated stations?
