What’s Different About 802.11ax in 6 GHz

There has been some consternation that 802.11ax should have a greenfield mode in 6 GHz, leaving behind all the protocol overhead used for backwards compatibility in the 2.4 and 5 GHz bands. This mythical mode could also have fantastic new capabilities that would now be possible without legacy PHY requirements. 6 GHz is an opportunity to so radically overhaul 802.11 that we could increment the 802.11 version bit in all 802.11 6 GHz frames (It’s been 0 for the entire history of Wi-Fi). Of course, it probably isn’t reasonable to expect the same amendment that must provide backwards compatibility in the legacy bands to also do something radically new in 6 GHz. It may also be unrealistic to expect 802.11ax client chipsets that operate in the legacy bands in legacy modes to do something radically different using the same radio in 6 GHz. Still, there are real protocol differences in 6 GHz 802.11ax operation. 802.11ax is not ratified, so it is still possible for some things to change, but I thought I’d run down what’s different and what opportunities I think were missed with 802.11ax in 6 GHz.

  • Security Upgrade – 802.11ax will make SAE and OWE mandatory replacements for PSK and open auth respectively in 6 GHz. MFP will be required. I still don’t understand how this will work with SSID’s that span the legacy bands to support legacy WPA2 clients as well as WPA3-only clients in 6 GHz. If the answer is “Just add another SSID for Wi-Fi 6E clients-only,” then I will be disappointed.
  • OFDM and HE-Only – There is no HT or VHT operation allowed in 6 GHz. Unique HE beacon IE’s indicate support for features inherited from HT and VHT. There are no HT/VHT Capabilities IE’s in a 6 GHz beacon. No HT or VHT MCS will be used in 6 GHz. OFDM is there because its shorter preamble consumes less airtime than the new HE preamble, so it will be used for those frames that don’t require the bigger HE preamble.
  • Basic HE-MCS and NSS (number of spatial streams) Set – We aren’t using legacy rates outside of the legacy preamble, RTS/CTS, and legacy ACK frames. Most frames can be modulated with HE-MCS encoding, including beacon, multi-STA blockACK, and trigger frames, some of which can be transmitted with multiple spatial streams. AP vendors may choose to continue using OFDM for these frames, however.
  • Spatial Reuse Can Work – 6 GHz STA’s can take full advantage of BSS Coloring and OBSS CCA-PD. Without legacy STA’s to conflict with, we can design for these features to significantly desensitize all intra-BSS STA’s from OBSS frames, and allow for increased spectral efficiency by reusing the channel more aggressively. If implemented, those robustly-modulated preambles are a smaller problem. However, Spatial Reuse (the OBSS CCA-PD) is optional in 802.11ax. Dual NAV is required for clients, and optional for AP’s. Confused yet?
  • EDCA Optimization – This might be the trick to getting OFDMA operation to take place more often. All 6 GHz STA’s will support OFDMA, so why not increase the contention window for the SU EDCA access categories advertised in beacons (there is a separate MU EDCA table for OFDMA)? That would reduce the likelihood of clients winning access to the channel for SU operation, and increase the likelihood that the AP will win the channel for OFDMA operation to take place.
  • Less RTS/CTS Overhead? – Because all 6 GHz STA’s can interpret the HE preamble, which includes the duration of the TxOP, normal RTS/CTS protection is redundant. The 802.11ax draft allows for several ways to establish a TxOP, including the legacy duplicate RTS/CTS method, so we will have to wait and see what the vendors choose to use in 6 GHz. In ideal circumstances, 802.11ax in 6 GHz will look like this: AP wins arbitration, trigger frame, MU-PPDU, BlockACK, repeat, repeat, repeat…
  • Reason Code 71 – 6 GHz AP’s can deny an association request from a client with poor RSSI using status “DENIED_POOR_CHANNEL_CONDITIONS” or disassociate a low RSSI client with a new reason code 71,”POOR_RSSI_CONDITIONS.” A 6 GHz client must respond to this sensibly (e.g. not blacklisting the BSSID/SSID as clients sometimes do in the legacy bands). Although vendors have had features that accomplished this for a long time, client behavior in response has always been a mixed bag.
  • 6 GHz AP Discovery and Association – A 6 GHz STA can discover, and in some cases associate to, a 6 GHz radio while operating in the 2.4 or 5 GHz bands. An AP’s beacon, probe response, and neighbor report frames in those bands can indicate the channel and channel width of their matching 6 GHz radio. Additionally, for 6 GHz-only operation, a specific subset of channels will be identified as preferred scanning channels (PSC) where the primary channel of a wide channel BSS should reside, limiting the channels a client needs to scan to discover a 6 GHz-only AP. PSC’s are spaced 80 MHz apart, so a client would only need to scan 14 channels in the US. Active probing in the 6 GHz band in the US is only allowed after a client has heard an AP transmission on the channel, which includes a beacon frame, an unsolicited probe response sent to the broadcast address, or a FILS discovery frame. However, one of these frames can be transmitted at least every 20 TU’s, which allows for less required dwell time on the channel for passive scanning. Less required dwell time and a limited set of PSC’s will make passive AP discovery faster in 6 GHz than 5 GHz.
  • 80 MHz AP Channel Width Minimum in 6 GHz? (see update) – They weren’t lying when they said “80 is the new 20.” Maybe things will change before 802.11ax is ratified, but I’ve learned that a 6 GHz AP will have to indicate support for at least 80 MHz channel width. This aligns well with the PSC’s the standard will define. I don’t know why the IEEE would require this, as it is extremely undesirable in the LPV WLAN’s where 802.11ax in 6 GHz would otherwise provide the most benefit. It’s an even larger problem in countries with unlicensed access to a smaller portion of the band. Clients may still use smaller channel widths, including a 20 MHz-only operating mode. 5/2021 update: Consumer and enterprise AP’s that have been released to the market support 20 and 40 MHz channel width operating modes in 6 GHz. Thankfully, that one problematic sentence in 802.11ax has not been interpreted to refer to a minimum channel width for operation.
  • How Much of the Wide Channel Can Be Used? – The use of wide channels followed wasteful logic in 802.11ac with dynamic bandwidth operation (DBO): If the primary 20 MHz channel of a 160 MHz BSS is busy nothing can be transmitted. If the secondary 20 MHz channel that would be used for a 40 MHz channel-width is busy then the STA can only use 20 MHz, the rest of the 120 MHz is unused. If those first two 20 MHz channels are clear, another 40 MHz is checked to see if 80 MHz of the channel is available, etc. And this pattern of checking for the next wider channel width is done serially through the CCA process which also introduces more overhead on its own. Remember, OFDMA only happens within the TxOP gained from a wide-channel arbitration process, which can be subject to the logic I just described. DBO was optional in 802.11ac and not widely implemented, and it appears to be optional in 802.11ax as well. This is important because…
  • Preamble Puncturing is Optional – What improves spectral efficiency in the scenarios above is a new 802.11ax feature called preamble puncturing, which allows a HE STA to transmit across the full 160 MHz of spectrum, but not within the specific 20 MHz subchannels that are busy. One busy subchannel doesn’t prevent the use of others, but the primary channel must still always be free for anything to be transmitted. However, preamble puncturing is an optional feature in 802.11ax. So even in the best case scenarios, OFDMA can only subdivide the channel within the 20 MHz subchannels determined to be available via CCA and (maybe) RTS/CTS. In the worst case scenario (no DBO or preamble puncturing), no data frame, OFDMA or otherwise, can be transmitted unless the entire wide channel is available (minimum 80 MHz in 6 GHz!).

The primary channel bottleneck is particularly troublesome because future generations of 802.11 in 6 GHz will have to account for 802.11ax operation to maintain backwards compatibility, although a lot of traffic that used to be primary channel-only can be included in OFDMA transmissions now (ACK, null-data frames). I wish we could have left behind the legacy channel arbitration process as well, or at least made preamble puncturing mandatory. Other problems may be improved in future amendments. The potential for reduced overhead and higher likelihood of the AP winning channel access are significant improvements when coupled with all 802.11ax clients in 6 GHz.

To Be Determined

  • The Wi-Fi Alliance – The WFA could decide that features that are optional in 802.11ax are mandatory for Wi-Fi 6E certification. Preamble puncturing and spatial reuse are very beneficial features that should be mandatory.
  • 802.11md – This is the maintenance work being done to roll-up 802.11 into 802.11-2020. It will include 802.11ax-2020 and leaves open the possibility of additional changes to 6 GHz operation occurring that are not part of the 802.11ax drafts, but happen within the roll-up process separately. An example of this happening in the past is 802.11 Fine Timing Measurement, which was added to the standard through the 802.11mc roll-up to 802.11-2016. That feature does not have its own 802.11xx amendment. Hopefully this will all be sorted out in December. Stay tuned.
  • 802.11ax, TBH – It’s not finalized yet, so perhaps some of this will change. I’ll update this blog if that happens.
  • AP vendors – As is often the case, the standard provides for many ways to achieve things and leaves many features as optional. It will be up to the AP vendors to determine what actually gets implemented in the real-world.

Wi-Fi: What We Need and What We Keep Getting

wifi_signal-1

No technology is perfect, but for most of my career in Wi-Fi there has been a persistent set of problems that continue to have no resolution in sight. They could be fixed, other wireless protocols have solutions for some of them, and there have been attempts to fix them but the results are so watered-down that they are ineffective. Today I’m going to channel my inner Lee Badman and get a little grumpy about Wi-Fi. Please bear with me as I go through my list of gripes. These are the real problems that real enterprises have with Wi-Fi, and each successive generation of Wi-Fi has does little to address them.

Crap Clients

Much has been written about the sorry state of Wi-Fi clients, so I won’t go too far into what is already well-documented. But so many Wi-Fi clients are utter garbage! They lack support for enterprise security (WPA2/3-Enterprise), some only support the enterprise-unfriendly 2.4 GHz band, there are new clients on the market today with 802.11g radios in them, their drivers are buggy and often go unpatched, and few clients support amendments to the 802.11 standard that are important to enterprise Wi-Fi performance and security (802.11k/v/r/w). I could go on… but why beat a dead horse?

Bad Roaming

This is mostly a client problem in Wi-Fi, but it deserves a callout all its own. Very, very few Wi-Fi clients roam effectively. Some are so sticky that they are totally unusable in a multi-AP network unless they never move. Further, most clients provide zero visibility into their roaming algorithm, let alone provide any configuration to correct it. Yes, some manufacturers have published roaming specs, but they are not telling the whole story, and real-world observations often contradict their documentation.

There have been engineering efforts at IEEE to improve roaming, but very little has come of it, and the Wi-Fi Alliance does not test that clients roam effectively in its certification programs. It’s the wild west, anything goes, and you don’t know what you are getting until you take a client out of the box and test it yourself.

And yet, the tools to fix the situation already exist. I believe that the right combination of 802.11k and 802.11v features could fix the sticky client problem. With 802.11k beacon reports, all clients could periodically report their RSSI and the RSSI of nearby AP’s to the AP. The AP could then use 802.11v BSS transition frames to direct clients to roam to the appropriate AP at the appropriate RSSI or MCS threshold. The WLAN administrator could configure whatever RSSI or MCS threshold was appropriate for the WLAN as designed, and all clients would roam in accordance with it. This is similar to the method LTE uses for handoffs (roaming in cellular-speak).

Unfortunately, client support for 802.11k is limited and support for beacon reports is even more limited. Same for 802.11v. AP vendors let you enable or disable these features, but give little insight into how they will actually behave (e.g. What a client actually does with 802.11k neighbor reports is anyone’s guess because they are absorbed into their already flawed, proprietary roaming algorithms, and how and when AP’s use BSS transition frames is largely undocumented). Because the IEEE decided these features are optional, and the Wi-Fi Alliance does not require their support for certification, we will never be able to fix roaming this way. This major problem will remain unresolved for as far as I can see into the future.

Unstable WLAN Infrastructure Products

If you have worked with Wi-Fi long enough, you have a favorite facepalm-inducing example of an access point bug that should never have been allowed out into the wild. And yet they are, frequently, as if no quality assurance or beta testing is ever done on the code that so many mission critical WLAN’s rely on. No AP vendor is immune. It’s shocking. It’s scandalous. Managers often don’t believe what their wireless engineers tell them about the shoddy state of the code they are running on networks that support patient care in hospitals and critical factory production lines, but it is a very real problem.

I used to think, “Well, once we get to the next major release they will have all this fixed.” That was many years ago.

Cumbersome Enterprise Security

Provisioning client suppliants for enterprise Wi-Fi security is much more difficult and complex than it ought to be, and for many clients it is impossible. Supplicant support is lacking or broken, and bulk provisioning is even harder to execute.

No Guest Wi-Fi Security

Why, in 2020, should guest Wi-Fi be unencrypted, and lack identity verification of the network? Is there a more common protocol than 802.11 that still isn’t completely wrapped in TLS?

Opportunistic Wireless Encryption (OWE) solves part of the problem by implementing encryption for open networks, but it doesn’t provide network identity verification, and it became optional when the Wi-Fi Alliance controversially stripped it out of WPA3, so like so many other promising innovations in Wi-Fi, I doubt that it will ever be universally supported.

Captive Portal Hell

There are few technologies that are as user-punishing as Wi-Fi captive portals. They require ugly hacks to sort-of-work, and the constant increase in HTTP and DNS security makes them more and more of a problem. There has to be a better way, but as best as I can tell, no one is working on one.

Hotspot 2.0 has a feature called Online Sign-Up (OSU), which does address it, but only for Passpoint networks, and the big RADIUS server vendors have yet to build support for it. There is no telling if they will.

What We Keep Getting

Alright, so I’ve aired my grievances. What makes them so tiring is that so little progress has been made to resolve them. Roaming has always been a problem in Wi-Fi, junk clients continue to be manufactured and certified, infrastructure code is still a mine field, and 802.11 security still does not meet enterprise requirements.

If we look at each successive generation of Wi-Fi, you’ll see that they always delivered higher data rates, which is a welcome improvement, but in reality that has produced diminishing returns since 802.11n. 802.11ax has really pushed this to the extreme, with efficiency gains that are welcome in large public venues, but are not needed with any real urgency elsewhere. There is no end in sight to this trend. The next generation of Wi-Fi in development at the IEEE is called Extremely High Throughput. It will bring 320 MHz channel widths and 4096 QAM. These features will solve exactly zero problems in Wi-Fi. If a Wi-Fi network isn’t fast enough, this is almost always a design problem, not a protocol limitation. What use are ever higher data rates for clients that roam poorly and struggle to get connected securely in the first place? It is time that increased throughput took a backseat to improved real world client performance, stability, and security improvements.

We have a new security scheme in WPA3, and while hardening Wi-Fi against quantum computing attacks is good, I suppose, it is way down the list of priorities for most WLAN operators. Simpler, bulk provisioning is a much more tangible improvement, and would lead to improved security too. How often do we have to just give up and resort to WPA2-PSK due to client limitations, bad supplicants, and no streamlined provisioning process? It is very rare to find an enterprise WLAN that isn’t using WPA2-PSK, which is branded WPA2-Personal by the Wi-Fi Alliance because it is appropriate for use in home, consumer WLAN’s. That alone should tell you something is very wrong.

WPA3 had a new and promising device provisioning protocol (DPP) that would be nice, but its since been stripped out and dumped into an optional certification called Wi-Fi Easy Connect. I think we all know what that means for its future…

So crap clients, bad roaming, unstable WLAN infrastructure products, cumbersome enterprise security, half-baked guest Wi-Fi security, and captive portal hell are here to stay. The IEEE and Wi-Fi Alliance are not prioritizing these longstanding, real world problems.

Is it any wonder that no one complains that Wi-Fi doesn’t support the CBRS band? Instead we look with excited anticipation at the promise of private LTE and 5G in the enterprise. The powers that be should take note of that lack of disappointment. We are close to the point where Wi-Fi is no longer looked to for mission critical applications that demand stability and reliability. Allowing these long standing issues to persist will cause Wi-Fi to be relegated to a best-effort, bulk traffic transport, not the wireless protocol of choice for important applications.

Organizations are signalling that they are ready to trade the high throughput of Wi-Fi (that they often don’t need) for the reliability of LTE in CBRS for those applications that are most critical. Meanwhile, IEEE continues the march towards 802.11be Extremely High Throughput with its 320 MHz channel width that will make a mess of the 6 GHz band, and 4096 QAM modulation. Features that do not solve real-world problems.

Work from Home Tips

Aerial view of a man using computer laptop on wooden table

Alright, I’ll get in on this topic too. I started working from home a couple days a week in 2017 and transitioned into a full-time WFH position in 2018. Maybe I’m a little late to this but I have some unique things to add, so here goes.

  • Be available! Working from home is a privilege that I don’t take for granted. I spent several years commuting to an office and am very happy that I no longer have to do that. So I want to make myself as available as possible to my coworkers so that myself being remote is less of an inconvenience for them when they need me. I don’t want it to be a problem. That said…
  • Check your email once an hour or less. Email is not for real-time communication. That’s what Slack, Teams, IM, and phone calls are for. Changing your attention to your inbox frequently is a major disruption to any work that is complex or requires consistent attention. If it is right-now critical, someone will call you.
  • Do your work first. You know what your job responsibilities are and what long-term projects you must make progress on each day. Work proactively by giving these tasks priority. Take care of them before the all small daily requests that cross your desk get attention whenever possible. They can drop your productivity on important tasks to zero if you let them.
  • Schedule your solo work. You might be very busy, but a remote worker with an empty calendar leaves the opposite impression with their coworkers and boss. This has the added benefit of deterring others from gobbling up your whole day with productivity-killing meetings.
  • A wireless headset is a must. This allows you to get up and move around on audio-only calls. Make a coffee, empty the dishwasher, or just get up to keep the blood flowing. Headsets often have less sensitive mics that won’t pick up softer noise, which is an added bonus. Get one with its own mute button too. There are two wireless standards used for headsets, Bluetooth and DECT. DECT offers much lower latency and higher quality audio than Bluetooth, although it is more expensive. Consider using a wired headset for your most critical calls.
  • Default to mute. If you aren’t talking, keep your mic muted. Some noises are unpredictable (doorbell, kids, computer ding, etc.).
  • Start your car once a week. Let it run for a few minutes. Its not good for a car to sit for weeks without running.
  • Maintain a separate workspace. I have a dedicated home office, but this could easily be a bedroom, dining room, or even a garage. Wherever you can escape from the other activity at home is perfect. On nice days, it might be even be the back deck. Setup your workspace like you would in an office with a second monitor, comfortable chair, separate mouse and keyboard, and a dock for your laptop.
  • You don’t have to use Wi-Fi. A wired connection at your desk is generally more reliable, and it allows you to experiment on your Wi-Fi network without affecting your computer’s connectivity. Most homes don’t have cat5 cable run to each room like an office building, but you can still get Ethernet from your router to your workspace using Powerline Ethernet (electrical lines) or MoCA 2.0 (coax). I use MoCA 2.0 at home with excellent results.
  • Take a lunch break. You still need mental breaks from work to stay fresh, even though you are at home. This is a good time to get outside for a bit and clear your mind.