There are arguments for and against disabling low data rates, and it’s my hope, that after reading this blog, you will understand why disabling lower legacy data rates may help your WLAN perform better.
My typical configuration looks like this:
My only basic (mandatory) rate is 24M. All rates below 24M are disabled. All rates above 24M are enabled/optional.
There are three kinds of frames in WiFi: 1) Management, 2) Control, and 3) Data. Legacy data rates (1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, & 54Mbps) or MCS rates may be used for Data frames, Management frames, or Control frames carried in an A-MPDU. (802.11-2012, sections 184.108.40.206 and 220.127.116.11) Other control frames have special rules for transmission data rates. I suggest not disabling any MCS rates because the negative impacts, if any, are unknown (untested) to date.
In 2.4GHz, your first goal is to get rid of non-WiFi interference sources. Your second goal is to get rid of 11b client devices. Use of 11b clients necessitates use of low (non-OFDM) data rates, which forces the use and ripple of protection mechanisms (e.g. RTS/CTS and CTS-to-Self). See this white paper.
Using 24M as your minimum basic rate (MBR) will disconnect all 11b devices and will prevent protection ripple, both of which will add capacity to your network.
Before you über WIFi geeks get started down that road of, “But the PHY header is always sent at the minimum supported PHY rate for the band!“, it’s important to remember that the clients have to decode the MAC header in order to understand the frame type, and that includes beacons and probe responses. The MAC header is part of the PSDU/MPDU and is sent at higher/configurable rates. For further info, see Andrew’s blog on the topic.
Management Frame Airtime (Overhead)
Many frames may or must use the MBR, including beacons, probe requests, probe responses, and broadcast/multicast traffic (which is more common with mDNS/Bonjour and IPv6). If you haven’t checked out Andrew Von Nagy’s SSID Overhead Calculator spreadsheet or iPhone app, just do it (right now). 🙂
Note that these tools only calculate airtime consumption for beacons. It’s very common to see 2-3x more Probe Requests and Probe Responses on a channel than Beacons, so multiply his number by double or triple for real-world management/discovery traffic overhead. This tool will quickly show you how fast management/discovery traffic will eat your airtime. It’s almost shocking.
Just wait until channel sounding (which uses the MBR) gets ugly with MU-MIMO! See below from the esteemed Chuck Lukaszewski at Aruba Networks, who gave a masterful presentation on MU-MIMO at the Feb 2016 WLPC conference. While Chuck’s suggested MBR of 12M (which works well with Apple devices when the network is properly designed) or 18M (which may have compatibility problems with some clients) in the screenshot below is reasonable, I have had exceptionally good luck with 24M in the field in a variety of scenarios. Further, I’ve seen VHD (very high density) deployments that use 36M MBR very successfully.
To dive a little deeper into the “why not 18M?” question, note that mandatory support for 6, 12, and 24Mbps data rates is specified in the 802.11-2012 (Section 18.104.22.168) standard. This was originally specified at a time when radio quality was quite poor (802.11a) as compared to today’s radios. 802.11a/g radios are quickly on their way out, and in most networks comprise a very small percentage of the overall client population. With newer, better quality radios, clients no longer need the lower data rates for stable connectivity. Some (very few) 5G capable client drivers were written to accept only required support of 6, 12, and 24M rates (“Basic Rates”) – or they wouldn’t connect. Most 5G capable client drivers have been written to accept any rate or set of data rates that an AP is announcing as Basic. Further still, there are a few 5G capable client drivers out there that will only accept 6, 12, or 24M, but nothing else. This is why 18M, when used as the only basic rate, may not be a good idea – as it will cause clients to not connect to the BSS.
The pertinent time slots, related to minimum basic rates, in Chuck’s presentation include:
24:25 – 26:11
1:09:07 – 1:10:34
1:12:28 – 1:13:33
Data Frame Airtime (Performance)
In order to achieve a higher SNR, the client will need to be closer to the AP or the AP’s output power will need to be higher (not recommended due to CCI). Having clients closer to APs means that they will use higher data rates and use less airtime for data transmissions. Less airtime utilization means higher capacity per BSS. Raising the MBR to 24M will require the use of 16QAM modulation, which means that the PSDU (MPDU) will only be decodable at a shorter range.
The typical recommended indoor AP coverage from most vendors is around 2,500-3,000. At that range, it’s important to keep output power low to avoid CCI. Keeping power low further necessitates keeping clients close to APs in order to maintain high SNR and MCS rates. Further, use of low data rates, even with Airtime Fairness enabled (if supported and working properly), consumes a BSS’s airtime quickly. Any argument for enabling lower legacy data rates is an argument for allowing clients to use those data rates, and that’s the last thing you want. Without Airtime Fairness, the negative impact to a BSS is overwhelming – essentially giving each member of the BSS the same capacity as the least capable client at any given instant.
One school of thought is that if frames cannot be decoded, then those frames will become noise/interference for other WiFi stations. Modifying the MBR has a near-zero effect on CCI caused by the AP since the PLCP preamble and header are always transmitted at the lowest supported rate of the band (e.g. 6Mbps for 5GHz and 1Mbps at 2.4GHz). However, clients extend the interference radius of a BSS and the farther they are allowed to roam away from the AP (while remaining connected), the more CCI they cause. Clients don’t have to be able to receive the MPDU in order to detect the PLCP preamble and header and to back off appropriately.
The more sophisticated the modulation type, the higher the RSSI and SNR you need to decode it. Said backwards (for clarity), the less sophisticated the modulation type, the lower the RSSI and SNR you need to decode it. BPSK and QPSK are the two lowest-order modulation types in use in WiFi, and they are more easily decoded. 16QAM (used with the 24M legacy data rate) is more difficult to decode, and therefore requires higher SNR to do so.
See the AP radio sensitivity chart below. Whether you’re talking about a client or AP, lower orders of modulation can be decoded at less RSSI and SNR.
The hope is that a client device will scan and attempt to roam when it reaches an RSSI (or SNR) threshold set by its manufacturer, but client device manufacturers rarely publish their receive sensitivity or roaming algorithm specifications. Therefore, one of our design goals should be that all users will have an optimum user experience given the device and applications that they’re using.
It’s interesting that even an MBR as high as 24M is still achievable at really low RSSI/SNR levels. Clients should always roam before they get anywhere near the low data rates we’re proposing to disable. For example, iOS devices (v8 and later) trigger roam scanning at -70dBm and roam when there is an 8-12dB difference between the current and new APs.
Sticky Clients \ Roaming
Sticky clients just suck. If a client device has poor SNR (either unidirectional or bi-directional), it will use unsophisticated modulation, and so will use low MCS/data rates. Equally bad, sticky clients significantly extend the interference range of a BSS, and CCI drives down network capacity. By raising the MBR to 24M, it limits the data rate that both the AP and the clients can use for MAC layer operations.
In the graphic below, you will see that the laptop in the center is associated with the AP to the left. Both APs in the graphic are on the same channel. While the APs cannot hear each other, they (and many of their other clients) can hear the laptop. In this situation, the client effectively conjoins the two BSSs and causes CCI. For this reason, it’s important for clients not to roam too far from their associated AP.
As shown in the graphic below, per-data-rate coverage areas get larger as the client moves away from the AP because lower order modulation types are easier to decode. This means that lower legacy data rates will have larger coverage areas (larger concentric rings in the graphic below) than higher legacy data rates.
Poor client drivers are partially to blame for stickiness, and poor network design is the rest of the story. Good enterprise design often means use of fairly low AP power to prevent CCI. (Before you WiFi nerds start throwing out corner cases, I used the word “often” on purpose.) Turning the AP power down means that clients won’t be able to hear the AP as far, and so will be forced to roam sooner.
If client drivers are taking into consideration successful or failed frame transmissions at the current MCS/data-rate, and not just RSSI (or SNR), then they may be more inclined to be sticky with the use of low data rates. I know of several clients that take more than RSSI into consideration when roaming, and as a sanity check, I asked multiple architect-level engineers to review this blog before publishing. They too know of several client devices whose roaming algorithm takes into consideration more than just RSSI.
For the sake of argument, let’s look at some clients that use RSSI as their primary metric. Here is Apple’s iOS9 roaming reference. It’s pretty clear from this reference, and from having months of hands-on time testing roaming for Apple iOS-based devices, that they do exceptionally well using 12 or 24Mbps as their only MBR, with all lower data rates disabled.
A good tool to validate that the mobile client is roaming is Net Analyzer. They have a “Lite” version that will work as well. The same tool is available both from the Apple App store (for iOS devices) and the Google Play store (for Android devices).
Notice that with this tool, you can see both the SSID and BSSID that the client is associated with. As you roam from place to place, you will see your BSSID change. It has worked like a champ for me, for months.
By having a higher MBR (e.g. 12 or 24Mbps), clients are influenced to make better choices about which AP to associate with. Because they can decode the MPDU at a smaller distance, they can decode beacons and probe responses from a smaller set of APs in the environment. This approach helps clients associate with the AP that is best able to serve them rather than APs that may be marginally acceptable.
When you’re designing the network, the AP’s MBR should be considered alongside its placement, output power, and channel because it will determine effective cell sizing. Using walls (e.g. putting APs in rooms) to your advantage will block much of the signal beyond your desirable RSSI level.
If you’re trying to piece-meal transition your network from an elderly “coverage” design to a more modern “coverage/capacity” design by rip and replace without a new design, it’s advisable to assess whether 12M or 24M would be better for you.
12M / 24M Difference
I’ve seen both data rates work perfectly well in mobile-enabled, high-density, high-performance environments. It’s my preference to go with 24M for two reasons:
- It consumes less airtime both now and at some point in the future with MU-MIMO
- It uses 16QAM modulation, which harder to decode than QPSK
These reasons may or may not be important to you in your deployment. You can err on the side of caution or the side of performance, but either way, it’s a small differential.
Keeping legacy data rates enabled might have been a good thing for the “coverage” designs of pre-2009, but given today’s landscape of high-density, highly-mobile, mobile-device-centric WiFi, that almost always requires high performance, keeping clients on the optimal AP, at high data rates, will yield the best user experience – and user experience is king. Before you say, “my network doesn’t require high performance”, ask your end users whether they prefer a fast WiFi network or a slow one.
I have one final thought. If you insist on supporting low data rates, do it in the 2.4GHz band, where the user experience is often poor anyway, as enabling low legacy data rates is only going to further impair your user experience.