For a long time the general approach to Wi-Fi design has been about coverage – ensuring there’s an adequate signal level across the desired service area. That’s fine for some deployments but if you’re going to have 150 devices in a room it’s necessary to think about how much capacity your wlan can offer.

“Nobody can connect to the Wi-Fi” reported the helpdesk. This was from the large reading room/study space in one of our library buildings, where people are working on essays and research. Connectivity is important and the users were understandably restless.

The room in question is a large (449m²), open space that was serviced by a single Aruba AP-225. SNR across the space was healthy and had recently been surveyed as part of a major upgrade of Wi-Fi across the library buildings.

I like a low meantime to innocence and jumping to that AP on our Airwave management platform showed there were lots of clients associated, they had an IP address and responded to ping. Users were spread fairly evenly across the 2.4GHz and 5GHz radios. The throughput was low, airtime use was minimal and there was no indication of interference. Everything looked healthy.

So it was with some smugness that I headed to the library to verify that, in fact, everything was absolutely fine… Only it wasn’t.

The user reports were that either they couldn’t connect, or that Wi-Fi performance was very poor. It quickly became clear this problem wasn’t affecting all users. Many were working away perfectly happily. My own experience verified that getting connected did take longer than I would expect, and then performance was indeed poor. 

Most notably I could see that my two devices didn’t associate with the AP in the room that has the best RF, but a less desirable radio further away. Suspicious…

This graph, showing how many clients had associated with the the AP over the previous week holds the answer in its suspicious flat tops which, although brief, indicate a limit has been reached.

All access points have a limit to how many clients can be associated. There will be a hardware limit and then usually this further configurable in software. Importantly most systems have a software default that’s a lot lower than the hardware limit.

On Aruba OS you configure this on a per SSID, per radio basis. We had this set at 64 which means an AP would accept 64 clients on our eduroam SSID for each radio. It’s hard to make out on the graph posted here, but the total clients does go just above 128, this is because of a handful of clients using other SSIDs.

The AP had simply reached it’s capacity (configured in this case, rather than hardware) and would not accept any more clients. The secondary RF coverage was coming from an AP too far away to provide good service.

Capacity in wi-fi networks can be a tricky thing to plan. The question of how many clients an AP can support can only be really be answered with “it depends”. My Aruba AP-225 may have hardware support for 512 clients, but that’s far more than you would want in any realistic scenario and these numbers can really only be considered valid for marketing purposes, not network design.

There are tools available to help set a baseline, such as the excellent capacity planner from Revolution Wi-Fi, but it comes down to what your clients are actually going to be doing. 

The most important limiting factor will be whether devices are able to access the RF medium. A very large number of clients not doing very much might be absolutely fine. Conversely a small number all trying to move a large amount of data can run out of channel capacity pretty quickly.

There are only so many channels, perhaps so many places you can install an AP and only so much budget available to buy equipment so this becomes a juggling act of needing to understand what the users need to do and how many of them there will be in order to plan for the necessary capacity.

Most of our users are carrying around at least two devices. Someone using a laptop in our troubled room probably also has a phone and maybe a tablet with them. The phone and the tablet are both associated with the AP but possibly only doing a bit of background sync, moving very little data. These devices spend most of their time sleeping, but they contribute to the client count and they do take up some airtime.

Understanding what users need to do is key, but it’s also challenging in higher education because, often, nobody really sets the requirements, instead we have to look at patterns of user behaviour. Doing this has told us that APs in our popular study spaces can handle a lot of clients because they’re not moving much data around.

Running APs with high numbers of clients can be risky. Too many devices on a channel can quickly reach a tipping point where users are having to wait to send their data. Throw in the inevitable increase in collisions that takes place and a well performing network can quickly fall apart. Always watch your channel use and re-transmissions!

The number of clients associated with our network is always slowly increasing. There are particular peak times in the year where certain spaces are in demand. Around Easter every study space in the library is full pretty much around the clock and the network needs to be able to handle these peaks.

Back to our troublesome room. In this case the answer was simple. We have plenty of 5GHz channel space available, so I added a few more APs on different channels, placed these strategically around the room and the number of clients on each AP, and therefore each channel dropped. Doing so has significantly increased the available capacity of the network.

So what are the all important learning outcomes of this episode? A few things to note:

• I’d assumed the spread of clients across 2.4GHz and 5GHz radios was due to a number of clients not having 5GHz capability, but I was wrong, most of them not being allowed to join the 5GHz club because the APs radio was at capacity.
• I’d failed to keep an eye on the trend of increasing numbers of clients in that study space. This is something our network monitoring can do for me, and this has now been set up.
• I had to eat some humble pie about my high performing network not being to blame. But, by going in person, I got the client perspective. In this case all the information I needed to diagnose the problem was available to me from my desk, however verifying the problem in person likely led to a quicker solution. It also helped reassure the struggling users that something was being done.
• Tell the users that action has been taken. The addition of more network capacity was advertised and it became apparent some people had been avoiding the space at busy times because they couldn’t get online. They hadn’t reported this, and simply found somewhere else to work. By announcing the improvements, we increased user satisfaction in our service.