In this context, “dense areas” should be read as “rooms with more than one AP”. Wifi clients in dense area will select one of these nearby APs for association, and they should ideally distribute evenly across the APs, to achieve optimal utilization of the available resources, and minimum contention.
“Sticky client” is a well known term among wifi professionals. As is the concept of rooms with multiple APs, where one of them is installed close to the entrance. Without incentives to roam, many clients will stick to the entrance AP, and the other APs will be under-utilized. I have observed similar skew in client distribution in other dense environments.
The current best practise in wifi design suggests that directional antennas should be used in many of these rooms. In reality that isn’t always the case, for several reasons. You could have a large-ish room with regular ceiling height, where directional antennas would need very wide angles to cover the designated number of seats. Possibly so wide that the scenario is only marginally distinguishable from APs with built-in omnis. Or you could have an auditorium with a legacy wifi installation. Even though the APs may be upgraded from the original installation, upgrade budgets don’t always include money for wifi redesign and new cabling.
This is an attempt to investigate to what extent (static) power level adjustments can counter-act uneven AP utilization in dense areas.
Channel utilization would seem to be the best criterion to monitor, as the basis for power level control: all APs should operate on a channel with the same util% as their neighbors. But this is a very dynamic measure, laden with time resolution issues. The same goes for fps, Bps, MCS or retry rate. Having clients roam between APs based on any of these values seems impractical. In comparison, number of clients per (5GHz) radio is better suited for use as a control indicator: more stable, easily measurable, and relevant.
The selected monitoring strategy observes (counts 5GHz clients) in all dense areas 20 minutes past the hour, during business hours. This point in time is 5 minutes past lecture start, when the users/students/attendees should have settled, and the wifi clients should overall have made any roaming decision. If the wifi client count is at least 80% of seat capacity, I assume that the users have spread evenly across the room: the room is considered “full”, and client count is monitored every three minutes for all 5GHz radios, throughout the lecture.
The actual client counting is cron based, and uses my apclients script, which I presented in Prague in October 2019. E.g. output from “apclients -m mh-U6-012-01-rw” might look like:
mh-U6-012-01-rw 2 (5,21)
This interprets to an AP with 2 radios, having 5 and 21 associated clients respectively. Other options/flags may be used to determine which channel the radios operate on, and hence their frequency. Output is sorted and graphed, as e.g. for Tabletten auditorium.
PS. Cisco offers a load balancing feature, to limit the number of clients that are allowed to associate to an AP concurrently. If max client count is exceeded, the AP responds to association requests with a refusal (initially), which introduces delays in the process. Concensus is that this feature should not be used on latency-sensitive WLANs. For other WLANs, it should be enabled only after testing.
PPS. Currently “the gathering part” of the educational system in Norway has been suspended, due to the Corona virus – from kindergarden to universities. So there will be no users in “my” auditoriums for some time. Nothing to count, no basis for adjustments, and no more cases to report.