Band Steering v2.0

It has taken many years since 802.11n was ratified to reach a reasonable penetration of 5 GHz clients out there in the Wi-Fi landscape. In particular, only in the last ~2 years have we started to see a reasonable percentage of the most common BYO devices (smartphones and tablets) shipping with dual-band support. Whilst this has been a long time coming, many of these clients (more correctly, the clients wireless driver) still either prefer the 2.4 GHz band or will often flip between the bands.

There is a method that has been discussed in Wi-Fi circles recently that is the subject of this post but before I get to that I want to look at Band Steering v1.0! I have used a number of methods over the years in order help shift as many dual-band clients over to the 5 GHz band as possible. There are of course times when you may wish to distribute clients between the two bands more evenly (though typically with a higher percentage onto the 5 GHz band) but I won’t address those here; in this post I’m assuming you want to move the majority of clients onto the 5 GHz. Additionally, this post not address dual-band clients where you would be better off statically configuring them for a single-band (this includes most application specific devices in healthcare, retail, logistics, etc.).

Some of the traditional methods of shifting clients to the 5 GHz band:

• Separate SSIDs for 2.4 GHz and 5 GHz clients: Pre-band-steering this was one of the few methods available. As band-steering emerged and (at least some) drivers improved, I generally stopped using this method except in the odd corner case;

• Updated client drivers: Client drivers did become smarter and where I’ve had control, I ensure that client’s drivers are up to date. In most cases however, I can however only advise the customer to make this change and as-such, it is rarely done. Unfortunately many clients still prefer the 2.4 GHz band even when they receive a high signal strength from a 5 GHz radio and therefore this method is far from perfect. Another significant issue lay with the increased adoption of BYO devices – obviously an enterprise ICT team has little, if any control over these clients coupled with the poor ability to update the wireless chipsets driver on the most prevalent type of BYO client (smartphones and tablets).

• Band Steering: Whilst band steering is the main method we rely on today and it certainly helps, it is still far from perfect. It is a non-standard method and therefore introduces the possibility of causing connectivity issues. Despite this risk, we typically use it as it is quite often our only choice.

• Band Steering Tweaking: In addition to enabling band steering, you can often tweak its operation in order to increase the number of clients hitting the 5 GHz band. However, the further you stray from the vendor defaults, the more likely you are to end up with client connectivity issues.

In addition to these methods, there are some vendor-specific methods that could help. For example, Meraki hides the broadcast of the SSID on the 2.4 GHz radio when band steering is enabled. Whilst this method can help shift more clients to the 5 GHz band, hiding the SSID isn’t typically a great idea – none the less, another available option if always nice, even if you can’t disable the hidden SSID aspect of the band-steering functionality.

So what other methods are available? Recently in the Wi-Fi world there has been talk of another method to help shift more clients to the 5 GHz band. This method involves ensuring that the transmit power of your 2.4 GHz radios is sufficiently lower than the 5 GHz radios. What I absolutely love about this method is that it is taking a negative and turning it into a positive. In the same way that MIMO took a negative (multipath) and didn’t just neutralise it (diversity antennas) but actually turned it into a positive (higher throughput!). Some client drivers will prefer a higher signal strength even if the available signal strength from a more preferable radio is lower, but still very high. For example, the client might see -45 dBm from the 2.4 GHz radio of an AP and -51 dBm from the 5 GHz radio of the same AP. -51 dBm is still a very strong signal and therefore the many additional benefits offered by the 5 GHz band would ideally result in the client associating to the 5 GHz radio. As many clients are single-minded in their association choices, they often primarily (if not solely) use signal strength when deciding on which radio to associate to. There are of course other factors that a client should take into consideration when deciding which AP to associate to and the radio being 5 GHz shouldn’t be the only consideration. However often these other factors end up resulting in a preference for the 5 GHz band anyway (SNR, retries, packet loss, channel utilisation, etc.) So in short, this method takes the negative (clients preferring a high signal strength above all else) and turns it into a positive (clients associating to the 5 GHz radio, yet still with a high signal strength) by ensuring that the 5 GHz radios signal strength that the client sees is sufficiently higher than the 2.4 GHz radios signal strength.

One of the best sources of information on this design trick is provided in Aruba’s awesome Very High Density VRDs. I do however feel the values in the Aruba VRD are insufficient but perhaps I am missing something ‘Aruba-specific’ as I usually live in the Cisco world (please chime in if you have more information). Aruba states that there should be a 6 dB - 9 dB difference between the 2.4 GHz EIRP and 5 GHz EIRP. There is already a 6 dB difference between the two bands so I don’t feel these values are high enough. Even when not using this method, my 2.4 GHz radio is almost always 6 – 9 dB lower than my 5 GHz radio to compensate for this 6 dB difference (amongst other reasons). Note, this does not factor in AP and client antenna gain and polar plot. In the case of the Cisco 3700 AP that I performed testing on, the antenna gain is identical between the two radios. The polar plots however favour the 2.4 GHz radio overall; it varies across the 360 degrees of course. In addition, some 5 GHz sub-bands are worse off than others (UNII-3 typically faring poorly). Lastly, client antenna gain also often favour the 2.4 GHz and lower 5 GHz sub-bands. I won’t go into the details of 2.4 GHz vs. 5 GHz cell size except to say that in most modern BYO/office deployments, you typically want a higher SNR at your cell edge in the 5 GHz band than in the 2.4 GHz band; this is yet another factor requiring a higher AP transmit power/EIRP for the 5 GHz band. These factors coupled with the testing I’ve performed demonstrate a difference closer to 9 - 12 dB is required to be confident of this design trick working well, with 12 dB much preferred – at least with the AP I have tested this on. In the modern Cisco world, this would mean something like a 2.4 GHz radio transmit power of 2 dBm and a 5 GHz radio transmit power of 14 dBm. Of course, these values would need to be tweaked for the individual design. There are other factors that must be taken into account of course – for example you don’t want to end up with your 5 GHz radio transmit power at an overly high value. More important than the values I have mentioned here is that you test your particular deployment to ensure that your most difficult clients are seeing a 6 – 9 dB difference between the two bands if you wish to make use of this design trick.

I feel that this design method is a fantastic way to bridge the gap between what band steering has offered us so far and the world we could be living in – that is, where WLANs could be today if 802.11n had mandated 5 GHz-only support! Whilst every design method or trick should be considered before implementation, I think this is one of the most useful to have come along in a while.

I’ll end this post with this quote from the Aruba VRD – This technique is extraordinarily effective with clients that are available as of the time of writing, including legacy HT clients and newer VHT clients. That’s good enough praise for me!