Nomadic vs True Roaming

It used to be that roaming, even when it was poor, wasn’t a big deal in most networks that weren’t specifically supporting voice traffic. Most users of WLANs were laptop users and they were more nomadic. A nomadic user shuts the lid to their laptop, tucks it under their arm while walking to or from a meeting, then opens the laptop to continue working. The perception of this user is that the wireless has been working the whole time, even though they were likely disconnected while their laptop went into a power save mode. This works because they aren’t actively using their device as they move.

Enter the smartphone/phablet/tablet era. Now people move about with their device connected all the time. If they leave the device in their pocket then they are still a nomadic user. Once they pull that device out to check email, their favorite social media network, or maybe even have a quick video conversation, they are a roaming user. They are actively using their device as they transition between APs. We want the perception of a seamless network and a relatively predictable transition from AP to AP. This is much harder to achieve when the user is truly roaming, and to keep things interesting we also have to rely on the clients to make their own roaming decisions. Unfortunately, we often have little real data on how clients make roaming decisions and many clients are in the habit of making poor choices.

SNR Impact

What happens when we don’t have nice transitions from AP to AP? The user perception suffers. For example, with the sticky client problem a device remains associated to a given AP longer than optimal. This results in lower connection speeds, more airtime usage, and more retransmits and co-channel interference. This can happen when client drivers are making particularly poor decisions. There is not much we can do about the drivers, but we can encourage the client to roam by limiting slow data rates and by using features like ClientMatch to force the client to move to a better AP. Even when using data rates to encourage the client to move, the SNR could drop to the point that the user experience is negatively impacted, especially if the installation is in a very noisy environment. This can be more pronounced for wider channels. You can see this in the great chart from Revolution Wi-Fi at Wi-Fi SNR to MCS Data Rate Mapping Reference. The numbers across the top represent the SNR and you can see the 40MHz channels need a better SNR for a given MCS than the 20MHz channels.

HT and VHT Rates

So, what does all that mean? It means that using the technique of limiting slower connection rates to encourage clients to roam has become less effective at ensuring a quality user experience and limiting wasted airtime. To help explain what I mean, let’s look at another useful chart. Here’s a bit of the chart available at mcsindex.com: Let’s assume we are using a commonly suggested minimum rate of 24Mbps in a cell. A client using a 20MHz wide channel will drop below 24Mbps when the MCS drops below 3. A client on a 40MHz channel doesn’t drop below the minimum until it hits MCS 0. A client using an 80MHz or larger channel width still has a greater than 24Mbps connection rate even at MCS 0! As the SNR degrades, the client will be using more airtime and dealing with higher levels of retransmissions while still remaining associated with a suboptimal AP. Whereas a client on a 20MHz channel would have already moved to a better AP.

You might be tempted to disable the MCS rates that use BPSK and QPSK. I was planning to suggest that as a viable option because you could do that with 802.11n, but it turns out you cannot do that with 802.11ac. The standard defines MCS 0–7 as mandatory with only MCS 8 & 9 being optional. 

This makes features like ClientMatch more important to keep in mind when planning your design. In very high density environments, the recommendation is to use 20MHz channel widths, but even in lower density deployments using narrow channels is something to consider. I'm rethinking using 40MHz wide channels at all, save for the smallest deployments.