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.

Methodology

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-rw2(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.

At WLPC in Prague I presented some scripts I’ve written to collect client data from Cisco WLCs via SNMP. A handful of people have asked for more details regarding one of my use cases: providing and logging connection data when a user runs speedtest from a Wi-Fi client.

How it’s done

When the user clicks the start button, the speedtest server picks up the client’s IP address and sends it in a UDP packet to a Wi-Fi lookup server, which uses my scripts to retrieve data from the wireless LAN controlllers. This data is returned to the speedtest server, and forwarded to the client browser as part of the normal speedtest response.

There’s some additional details, like what happens if the client is connected via cable, and syslog’ing of test results, but I’ll assume that’s below the noise floor. Look it up in the code or try it out if you’re interested. Or ask.

The code

The speedtest server extension (PHP code) is written by an ex-colleague of mine (who can contact me if he wants his name here), and inherits its license from the speedtest application (GPL). The Wi-Fi lookup code in Perl is mine, and it’s GPL’ed too.

Installation

The APtools scripts must be installed and capable of retrieving data from Cisco WLCs. Copy the two additional Perl scripts into the same directory as aplist/apuser/apclients.

Verify that lookups work locally, based on client IP address

The PHP files are aligned with the speedtest version on the WLAN Pi. If that’s your speedtest server platform, copy them to /var/www/html/

Adjust the speedtest files to your environment (see below).

Adjust the Wi-Fi lookup files to your environment (ditto).

Adjustments

Determine a UDP port which gets through from your speedtest server to the Wi-Fi lookup server. In my environment the default 23456/udp is blocked by firewall/ACL, so I settled for 53/udp instead. Which is what DNS uses. Not very nice, I know.

Also, to use a port <1024 the Wi-Fi lookup server must be started as root. If that’s the case for you, change $suUser in speedtesterWiFiLookupSrv.pl from ‘wifimgr’ to a user that actually exists on the host.

conf_settings:php: change to the host and port of your Wi-Fi lookup server.

speedtest_worker.js: you may want to change getIp_ispInfo from ‘true’ to ‘false’ in line 52.

speedtesterWiFiLookupSrv.pl:
– in line 55-58 you may want to insert the paths as prefixes to the external programs
– change the reg.exp in line 65 (sub accessAllowed{…}) to the IP address of your speedtest server, i.e. /^(MY.IP.ADD.RESS)$/

And GO!

Start “speedtesterWiFiLookupSrv.pl rcvPort=yourUDPport debug=on”, and begin by verifying that the UDP packets flow from the speedtest server host to Wi-Fi lookup server and back. To do that, determine the IP address of a Wi-Fi client and use nc(1) in a terminal window with your server and port:
wlanpi@wlanpi: echo WI.FI.CLIENT.IP |nc -u lookupSrv lookupPort