Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Re-examining 802.11n Greenfield

In my last blog I reviewed the rising use of 802.11a, despite pessimistic predictions and less than complete market acceptance of the standard. Organizations deploying Wi-Fi gear several years ago may have compared 802.11g to 802.11a and decided not to purchase dual-radio, 5-GHz capable APs, based on the fact that even though both offer the same data rates, 802.11a support added cost, had slightly less coverage, and there were many less client cards that supported the standard. And 802.11a was not picked up by all enterprise and SOHO vendors and there was much fumbling around. But 802.11n appears to be considerably different: it???s seriously regarded as the next major phase in the enterprise WLAN market offering significantly better performance, extended coverage, greater reliability, and vendor support on all fronts.
So it???s time to take full advantage of 802.11n, right? Greenfield mode, that is, the ability to configure the 802.11n access points to work only with 802.11n clients, seems like the right way to go. Why let the 802.11a/b/g clients drag performance down with mixed mode? Use multiple 40 MHz wide channels at 5 GHz to get full performance. That appears to be the right approach, but is greenfield mode perhaps a bit too idealistic?

With some organizations seeing 30 to 50% of their wireless clients associating in 802.11a mode, two closely connected questions arise: can/will I operate my legacy 802.11a access points alongside new 5 GHz 802.11n access points, and if not, what will happen to the 802.11b/g side of things as I essentially force non-802.11n capable dual-mode clients to use 802.11b/g instead of 802.11a?

There???s no easy answer. There are eleven non-overlapping 40-MHz wide channels, but not all vendors will be able to support them, at least initially. If we exclude the newer UNII-2 Extended band which has some stricter DFS requirements, only 6 non-overlapping 40-MHz wide channels remain. There are 12 non-overlapping 20-MHz wide 802.11a channels in the three remaining bands (UNII-1, UNII-2, and 5.8 ISM/UNII-3), and at least 3 of them will be used for 802.11a. Let???s presume that four of them are used and that they are all contiguous (optimistic!), leaving only four non-overlapping 40-MHz wide channels. That???s not much breathing room. At least one vendor has raised the question if contiguous 40-Mhz wide channels can be deployed without significant adjacent channel interference, and it???s plausible to ask the question if a 20-MHz wide 802.11a channel should be deployed adjacent to a 40-MHz wide one. This all presumes, of course, an overlay deployment of 802.11n APs on top of an existing 802.11a-capapble system.

A much more likely scenario will be the replacement of existing dual-radio, dual-band 802.11a/b/g APs with dual-radio, dual-band 802.11n APs for reasons of Ethernet ports and powering. That means that a greenfield 5-GHz based 802.11n deployment would automatically exclude 802.11a clients. Where does that leave those clients? They can use the AP???s 802.11b/g radio, but it???s possible that this channel is already saturated with existing clients. Sure, there will be some of the client base that already has an 802.11n-capable radio, but at this point in time it???s definitely less than the 802.11a-capable population.

The only answer to this conundrum is a pragmatic one: deploy the 802.11n-capable 5 GHz radios in mixed mode or use 20 MHz channels until that time that the 802.11n-capable client base is larger than the 802.11a one. Yes, aggregate throughput may not reach 100 Mbps as the radio slices it???s time between a larger population of 802.11a client and a few 802.11n clients, but it appears to be the only practical route to 802.11n if 802.11a is standing in your way.