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 only basic (mandatory) rate is typically 12M. All rates below 12M are disabled. All rates above 12M 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 220.127.116.11 and 18.104.22.168) 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 12M 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 through increased airtime capacity.
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. Chuck 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). I have had a good experience with 12M in the field in a variety of scenarios, and 24M may be necessary for airtime conservation in VHD environments.
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 22.214.171.124) 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.
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, which raises airtime consumption at longer range.
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 12M is still achievable at 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 12M, it limits the data rate that the AP can use for transmissions.
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. 12Mbps), clients are influenced to make better choices about which AP to associate with. Because they can decode the beacons and MPDUs at a shorter range, 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 would be better for you.
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.