5 GHz: The band that never was

In early 2009 I started working on a high density education deployment. I tried looking at every available option to wring the last piece of performance from the WLAN design. This was prior to the ratification of the 802.11n standard, which didn't come until September of that year. What was immediately apparent was how important the 5 GHz band was going to be to achieving this goal.

At the time the Wi-Fi alliance had been certifying 802.11n Draft 2.0 gear for around two years. Because no mandatory new features were added to the final ratified standard, all Draft 2.0 gear was able to successfully interoperate with gear that came about after the standard was finally ratified. This certification was a great move from the Wi-Fi Alliance because it meant that there was a reasonably large installed base of compatible clients to make use of the 802.11n APs upon ratification, at least in the laptop space. Essentially the clients had a two-year head start. This was doubly important due to the large delays with getting 802.11n over the line. By the time it arrived in late 2009, it was desperately needed in areas such as education where one laptop (or other device) per child was starting to become the norm.

The real key to making the most out of high-density deployments is 802.11n support in the 5 GHz band. This doesn't necessarily mean that all of your clients should be in the 5 GHz band as you may be missing out on available airtime in the 2.4 GHz band - just that if all (or more realistically, most) of your clients are dual-band capable then at least you have the 5 GHz option at your disposal!

In early 2009 it was hard to gauge how many clients would be released with dual-band support. At the time I thought that two-years post-ratification (late 2011) most clients released would support not only 802.11n but also the 5 GHz band. Two years later the majority of clients did support 802.11n however unfortunately this was not the case when it came to 5 GHz support. Not only that but early experiences with the 5 GHz band on many devices (though certainly not all) has been underwhelming largely due to poor implementations by client vendors.

The Laptops

Initially most laptop drivers I tested did not prefer the band and many would jump between bands during use of the client. In addition, Cisco didn’t offer a band steering option early on and when they did introduce one (Band Select) it was CLI-only and the release notes stated that it should NOT be used. In other words, it was buggy. Later it made its way to the GUI. With bugs ironed out in the Band Select code and with improved laptop drivers, laptops began to stick to the 5 GHz band.

Most of the new laptops that I was testing in 2009 offered dual-band support so when I started a new role in late 2010 I was very surprised that my corporate laptop provided only single-band support. Not only was it 2.4 GHz-only but it didn’t even provide MIMO or support Short Guard Interval – 65 Mbps was the top data rate! This came as a big surprise but since then I have seen plenty of ultra-lightweights’ and Ultrabooks that likewise only provide single-band support.

Then of course there is band and channel support within the 5 GHz band. With the 5 GHz band broken up into five separate bands (UNII-1, UNII-2, UNII-2e, UNII-3 and ISM) there are often incompatibility issues between what bands the infrastructure supports and what the client supports. Much of this comes down to what regulatory domain your infrastructure/client vendor intends your equipment to operate in and the issues this causes when their vision doesn’t fit with yours. These vendors and the original 802.11 standard seem to have forgotten about the realities of globalisation!

In my utopian-vision, world-peace would result in real universal standards. This would eliminate the 5 GHz incompatibilities we see amongst infrastructure equipment and clients :)

For example, back in early 2009 I looked into why Cisco didn’t offer their APs in a SKU for the Australian market. Although legally we’re able to use the UNII-2e band, we get thrown into the lowest common denominator –N regulatory domain when purchasing Cisco APs. Of course we could purchase the US –A APs but then you have the issue of client support. There is no point in allowing your APs to use the UNII-2e band if few of your clients support it. Whilst many clients may be unable to use the UNII-2e band in Australia currently, I hope to see this change once 802.11ac and its larger channel widths take hold. As far as I can see the only reason an Australian SKU doesn’t exist is that Cisco doesn’t see Australia as a large enough market and no one has put pressure on them to support it. Whilst it would have been nice to have UNII-2e support here for 802.11n when using 40 MHz channels in high density environments, it is all the more important with the 80 MHz channels offered by 802.11ac, assuming you have a use case for such wide channels (I'm ignoring 160 MHz channels just like I ignored 40 MHz channels at 2.4 GHz!). Things are looking up though - the new Cisco 2600 series APs are available in a –Z SKU for the Australian / New Zealand market and hopefully this SKU will also be offered for forth-coming 802.11ac APs where it will really matter!

Besides this Australian/Cisco-centric issue, there are plenty of other issues when it comes down to individual 5 GHz band support from clients not supporting the UNII-2e band to clients not supporting individual channels (the Cisco 7925G’s lack of support for channel 165).

The Smartphones

It was quite some time before even a small percentage of available phones started to support the 5 GHz band. Within your average corporate or home network, this wasn’t a big deal – within a high-density environment such as a stadium deployment it certainly is! Whilst it is great to see phones supporting the 5 GHz band, mere support isn’t enough. If you’re going to offer dual-band support you’d better do it right! Let's examine what was one of the most popular Android-based phones - the Samsung Galaxy S II. Dual-band support? – yes! Very poor RSSI at 5 GHz – yes; favouring 2.4 GHz over 5 GHz despite band steering being enabled – yes; poor support for individual 5 GHz bands – yes. With all of these issues, I consider the 5 GHz support useless on this phone. By comparison, the Samsung Galaxy S III appears to have solved most of these issues.

Then there is of course the iPhone 5, which now offers dual-band support – hopefully more inline with the Galaxy S III than the Galaxy S II.

In my mind, in 2013 we will start to see smartphones really make use of the 5 GHz band with recent client improvements and support for the band alongside an increase in stadium/BYOD/hotspot deployments. We might even start to see some 802.11ac phones - Galaxy S IV / iPhone 6 anyone!

The Tablets

Tablets have been a mixed bag when it comes to comes to 5 GHz support. There are certainly more dual-band capable tablets out there than smartphones but particularly on the Android side of the fence, it isn’t overwhelming.

In contrast to the their smart-phones, Apple has offered dual-band support from the beginning - the iPad 1, 2, 3 and now mini all support it. Dual-band android tablet support is not so great with a mixture of dual and single band tablets out there. The issues on the Samsung Galaxy S II phone also seem to exist on Samsung’s tablets. Apple’s 5 GHz tablet support seems much more solid.

5 GHz – The band that never was

So far, many 5 GHz client implementations have been underwhelming. The issue has not been with the five to six billion oscillations per second – that is, there are no significant issues with using Wi-Fi in this band.

The issue has been with both the quality and quantity of dual-band implementations from client vendors. Looking back 3+ years, I thought we’d be in a very different place by now. Things are looking up however! From improved laptop chipset drivers to improved smartphone implementations to an overall increased quantity of dual-band capable clients. With ratified enterprise-grade 802.11ac hardware on the way hopefully the lessons that client vendors have learnt from their 802.11n 5 GHz implementations pay off and we see some of the first 802.11ac clients perform solidly on the 5 GHz band. It would have been nice if the IEEE had never supported 802.11n in the 2.4 GHz band to begin with but considering work started on it almost 10 years ago, I imagine it wasn't a realistic option back then.

In addition to the issues with client vendor implementations (or lack thereof), there is so much more that needs to be taken into account when designing for the 5 GHz band. Hopefully the knowledge gained from the v1.0 5 GHz implementations of 802.11n pays of when it comes to the v2.0 designs and implementations of 802.11ac. What about 802.11a, you may ask. That was a merely a beta!