802.11ac & 5GHz: The Emperors New Clothes? - Part 2

In part one of this series looking at 802.11ac challenges, we looked at the issues that the use of the 5GHz band brings, particularly around DFS. In this second installment, we look at further challenges to designing and deploying 802.11ac networks.

Extended Channel (UNII-2e) Device Support

Although we may be located well away from any obvious sources of radar interference, there may be other obstacles to the 5GHz nirvana outlined in the 802.11ac marketing briefs. One ugly fact affecting WiFi networks on the 5GHz band is that not all devices that use the 5GHz band support all of the unlicensed channels available in our region. 

For instance, I recently purchased a Nexus 7 tablet and was extremely disappointed to find that it only supports channels 36 to 64 (for the UK). The remaining available channels, 100 - 140 are not supported at all.

I think that this variation in support for channels was originally rooted in a lack of support for devices in the UNII-2e channels (channels 100 - 140). Why this trend still persists in some devices is a mystery to me, but there is no doubt an economic consideration at work here (i.e. lower cost chip-sets). Nonetheless, it still persists with some new devices and is certainly an issue with many older devices.

It's certainly true that UNII-2e channel support among WiFi clients has increased significantly over recent years, but there is still no guarantee that all devices that may use your wireless network will be able to use all possible 5GHz channels. This has an impact if you decide to try to use all 20+ channels across your wireless network. If a wireless client that doesn't support UNII-2e channels is in an area where all APs use UNII-2e channels, then the client will simply not be able to connect. As a work-around, it is possible to alternate AP cells in such a way as to distribute UNII-2e channels amongst AP cells using UNII1,2,3 channels, so that clients may still be able to find a supported channel. But, this is still a workaround, and not an optimum design. Making an SSID available on the 2.4GHz could also be a last-ditch fall-back, but of course, we're no longer able to use our 802.11ac speeds.

(Peter Thorneycroft did a great presentation which touches on this - you can find it here)

Whichever way you look at it, having clients that do not support UNII-2e channels in a wireless network that uses UNII-2e channels is not a great situation and requires careful planning and consideration. 

Voice Over WiFi Clients

Unfortunately, the woes around DFS channels don't end there. I recently became aware of another effect of using DFS channels recently when I attended the Wireless LAN Pros conference and saw this presentation from Martin Ericson: http://www.wlanpros.com/ten-talks-martin-ericson-vofi-phones-dfs-channels/

In summary, when using wireless voice handsets, you want to keep your roaming times between access points very low as you move around a building. If the roam time between APs is too long, this can cause poor audio quality or perhaps even drop the call. Therefore, being able to make a timely roaming decision is critical for wireless handsets. 

Wireless clients use two methods for finding new APs to roam to:

• Passive scanning - they listen to beacons which are sent every 102mS by APs and build a list of potential APs to roam to
• Active scanning - they send out probes across all channels to more rapidly find a new AP to roam to

Although the 102mS of passive scanning sounds like a short period of time, it is actually quite a long period compared to what can be achieved using active scanning. When relying on passive scanning alone, the period taken to roam between APs is too long and will cause the quality and connectivity issues we discussed previously.

The DFS process dictates that only the access point on a wireless network has to be able to detect to radar. Clients do not detect radar blasts. For this reason, clients are not allowed to probe on DFS channels, as they may be probing (and hence causing interference) on a channel that is in use by a radar system.

Given this restriction, it does not make sense to use WiFi voice clients on DFS channels. Again, we are impeded in our channel selections for 5GHz for our WiFi network, as utilizing just the non-DFS channels is our best option.

Channel Widths

One of the key strengths of the 802.11ac standard is the speed increases that it delivers. This increase in speed itself is a nice-to-have, but it's not a huge game-changer for the average mobile client. The real advantages are in the increased spectral efficiency the speed increase it can deliver (i.e. how quickly a client can use and free-up the RF medium), which delivers higher WLAN capacity and greater battery savings for mobile devices.

One of the mechanisms used to deliver this additional speed boost is channel bonding. This isn't new - in the 802.11n standard, two standard width 20MHz channels could be bound in to a single 40MHz channel to double the speed of the wireless communication between the AP and client. But, as we double up on our channels, we have less unique channels available overall for our WLAN. The diagram below shows the effect on varying channel widths within the 5GHz band:

You can see that in this diagram (for the USA), we have 25 x 20MHz channels available. This shrinks down to a total of 12 channels when we are using 40MHz channel widths. (The actual numbers available are lower than this, as the weather radar channels aren't generally used, but lets keep things simple for now) 

When considering 802.11ac, which allows the use of 80MHz channels, you can see that the number of usable channels falls again to just six (but, again, the caveat around weather radar channels reduces this). 

Unfortunately, in the real-world, we are probably looking at being able to use 5 or less (in Europe) 80MHz channels on the 5GHz band for 802.11ac devices. And, once we consider legacy devices that perhaps don't support the UNII-2e channels, we're down to just one or two channels that all devices will be able to support. 

Anyone with a basic knowledge of building 802.11 networks will quickly see that having such a small number of available usable channels is not going to work at all well. Having so few channels talks us right back to same issues we had with co-channel interference (or contention) that we've always had on the 2.4GHz band.

So, we're back in to the land of compromise. We have to reduce our channel widths and lose many of the speed benefits that 802.11ac provides. We have to take a chance on using DFS/UNII-2e channels and hope that we don't suffer with any of the potential pitfalls I have outlined above. The 802.11ac story doesn't quite stand up to close scrutiny after all. 

Many vendors are pointing to the white knight on the horizon in the form of 802.11ac wave 2. Wave 2 will allow up to 3 (or maybe 4) single stream clients (e.g. tablets, smartphones) to connect simultaneously to an AP using a technique called multi user MIMO (MU-MIMO). This should provide a significant improvement in performance in environments where single stream devices abound. But there are again caveats: the clients have to be spatially far enough apart for the beam-forming to work correctly and the clients themselves must support beam-forming (which is not mandatory in 802.11ac). Even with these improvements, none of the obstacles outlined previously magically disappear. It's also worth considering that MU-MIMO is only a mechanism that works downstream from AP to clients - it won't be possible for 4 clients to all use the same channel at the same time.



In the third and final installment of article series, we'll look at a solutions to the issues presented in parts 1 and 2.