Disabling 802.11b support on your AP… or not?

While most of us are using 802.11n devices or looking to replace them with 802.11n/ac devices, there are still some 802.11b clients wandering about. These old 802.11b devices can seriously impact the performance of our Wi-Fi networks on the 2.4 GHz band. How much? Let’s find out.

How many old guys are there?

That’s a difficult question to answer as it really depends on the network you are looking at. While new devices (AP/client) nowadays all ship with 802.11n/802.11ac chipsets (32 million 802.11ac APs shipped in 2014 [1]), there is a chance that older clients are still present on your network. Probably you have to look for them in areas where clients are less frequently updated like old desktops PCs, wireless printers, industrial equipment, …

There have been some rumours [2] that vendors were looking at 802.11b again for IoT applications, but the anticipated 802.11ah (900 MHz band) specification seems more suited for this purpose.

What’s the impact of the old guys?

802.11b client on your/neighbouring network

New Wi-Fi specifications have always been designed with backwards compatibility in mind. In case of backwards compatibility for 802.11b clients, this results in adding one or two (decision is up to the vendor) extra messages (sent at 802.11b speeds) before each data exchange between an 802.11g/n/ac AP and 802.11g/n/ac clients. Using this RTS (Request-To-Send) and CTS (Clear-To-Send) messages, as they are called, the 802.11b devices are informed of the upcoming OFDM-modulated data exchange which they will be unable to decode. And, as always in Wi-Fi, the golden rule says: once you are informed, you can not interfere.

This seriously impacts the total efficiency of your network, as each data exchange is piggy-backed with these slow RTS/CTS messages. An AP will automatically enable this protection mechanism as soon as an 802.11b client is detected on the same channel (not necessarily on the same SSID) and will inform all other clients on the network to enable this protection. So performance impact happens, even when 802.11b clients are not sending anything.

Greenfield network

Although ‘Greenfield’ is an official term, used in 802.11n to indicate that there are no 802.11a/b/g devices present, you can broaden this definition to indicate that no 802.11b devices are present. In this situation, the AP is not forced to use protection mechanisms to protect 802.11b devices.

However, you have to keep in mind that 802.11b speeds can/will always be used, even in greenfield networks. If signal quality between AP and client drops low enough, they will eventually switch back to 802.11b (or even lower), because of its robustness. Although the 802.11 specification dictates similar minimum receiver sensitivity levels (-80 dBm) for the old 802.11 DSSS modulation (1/2 Mbps) and the lowest OFDM modulation (6 Mbps), typical real-life chipsets [3] achieve better receiver sensitivity levels (-95 dBm) for DSSS.

This is also why beacons are still sent at 1 Mbps (DSSS) in the 2.4 GHz band, which is even lower than 802.11b speed (5/11 Mbps).

Also note that the RTS/CTS messages (discussed in the previous paragraph) are on most Wi-Fi networks also used as a default protection mechanism as soon as a packet is transmitted whose size exceeds a threshold (typically 2347 bytes). So, even when no 802.11b devices are in the neighbourhood, these messages can occur.

Can we solve it?

The answer is not a clear YES or NO.

Yes, most APs allow you to configure it in such a way that 802.11b clients are not allowed to connect and even allow you to just don’t care about them (force the AP to disable the protection mechanisms, described in one of the previous paragraphs). This way, the performance of your Wi-Fi network will not be impacted by the presence of nearby 802.11b devices.

No, because, as we have seen in the previous paragraph, even in greenfield networks, 802.11b (or lower) speeds will occur. Also keep in mind, that if there are 802.11b devices on your network and you configure the AP to deny them when they try to associate, they will keep on trying, consuming valuable airtime while doing this.

Conclusion

Do you want to eliminate the performance impact, but are you worried for those 802.11b devices still out there? There is only one advice: start gathering statistics on the number of old client devices on your network today! Each network will be different and it is always difficult to estimate without having the real numbers. Once you have the numbers, you can get a better view on the impact of getting rid of the 802.11b compatibility!

On the other hand, you could also reason that the 2.4 GHz band is just not intended for high throughput. The more Wi-Fi evolves, the more it becomes clear that 2.4 GHz (and perhaps 900 MHz with the 802.11ah specification) is for range and backwards compatibility while 5 GHz (or even 60 GHz with the 802.11ad specification) is for speed, so you might as well leave it as it was designed to be (with backwards compatibility).

 

References:

  1. ABI Research, 2014 – ‘802.11ac Wi-Fi CPE shipments to capture 18% of the total 176 million access points in 2014
  2. With Imagination blog, 2014 – ‘To 802.11b or not to 802.11b – that is the question
  3. Real-life, currently available 802.11 chipsets with better receiver sensitivity than required by spec:

Reader interactions

3 Replies to “Disabling 802.11b support on your AP… or not?”

  1. Hi Jan. I sometimes face this issue with my customers, although in the last couple of years it is becoming a non-issue except in the special cases you mentioned, such as compatibility with legacy, specialty devices that still need to be kept around.

    In my experience, however, there isn’t a downside to disabling the 1, 2, 5, and 11 Mbps data rates. By doing so, the beacons will be sent at the lowest mandatory data rate, which in this case will be at least 12 Mbps. Therefore, 802.11b clients will not see the beacons and will not try to associate based on seeing the beacon. (If the SSID was hidden and an old client is still around, it may occasionally probe for the SSID, but that is another matter, and not very likely).

    On a related note, in high density deployments, I have set the lowest mandatory rate for 2.4 GHz as high as 24 Mbps, which can dramatically reduce overhead.

    Reply

  2. Hi Robert, thanks for the remarks; just a few thoughts from my side: 1. disabling 1,2,5,11 Mbps (basically 802.11 and 802.11b) will make the lowest data rate 6 Mbps and not 12 Mbps as 6 Mbps is the lowest PHY rate for OFDM (802.11g). 2. Although, according to the official 802.11 specification receiver sensitivity should be more or less the same for DSSS (1, 2 Mbps) and OFDM (6 Mbps), on most chipsets (as I mentioned in my blog post) DSSS sensitivity is better than OFDM sensitivity. This means that, if you force the AP to send out beacons using OFDM (by disabling 1, 2, 5 and 11 Mbps), the coverage of the AP will be less than what you would be able to achieve using 1 Mbps beacons. I agree that in high density deployments this could be an advantage (less airtime consumed by beacons and less coverage leads to less interference), but in other situations this would be a disadvantage.

    Reply

  3. Hi Jan. You are correct. I mis-spoke and meant to include 6 Mbps in my list of the rates that I typically disable. For most of my deployments today, I am designing for capacity and not coverage, so it is essential that we have a small cell size. In one case, I had the opportunity to deploy a building at a university over a break when everyone was gone and no clients were active. At defaults, with an AP in each classroom running at the lowest possible power on 2.4 GHz (under 2 mW), overhead from the beacons alone (3 SSIDs) was around 90% (channel busy time). Setting the lowest mandatory data rate to 24 Mbps reduced overhead to about 10%. It has been running this way for a year now with good results.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.