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!