802.11n Upgrade: AP Substitution. Is it viable?By CWNP On 10/16/2007 - 1 Comments
I'm sure that by now you've read the early 802.11n deployment documentation by various vendors. It's pretty much a consensus in these documents that there are a small set of ways to deploy an 802.11n upgrade to an 802.11a/g network. As a precursor, it is highly recommended by most vendors to use 5 GHz for the bulk of 802.11n deployments due to more available channels and bandwidth.The first option, put forth by Multiple Channel Architecture (MCA) vendors, is to deploy a greenfield overlay network in parallel to the 2.4 and 5 GHz networks that are already in place. That is, choose a small (minimum of 3) set of Wi-Fi channels to be used in a reuse (aka tiling) pattern just like channels 1, 6, and 11 are used today in the 2.4 GHz band. This may require stealing channels from your existing channel reuse plan. This plan is ok except for the fact that it's expensive having multiple, separate 5 GHz networks and to get any real benefits from 802.11n, you need to use 40 MHz wide channels. This fact will make this strategy all the more difficult.
A second option, put forth by Single Channel Architecture (SCA) vendors, is to deploy a second 5 GHz channel dedicated to 5 GHz 802.11n. This is the same strategy of greenfield overlay without the worry of running out of channels in the process.
A third option is to rip out all 802.11a/g network nodes (access points and client devices) and replace them with 802.11n nodes. This is also a greenfield deployment method, but I don't think I have to state the obvious drawbacks to deploying 802.11n in this manner.
A fourth and final option is to implement an AP substitution upgrade strategy. This is where you replace 802.11a/g APs with 802.11n APs on a 1-by-1 basis. This is how most organizations will implement 802.11n upgrades, but the drawbacks can be considerable.
802.11n APs have multiple transmit and receive chains. Radio chains are sets of radios and antennas. Each .11n radio chain is very sensitive and each radio chain works in conjunction with other radio chains in the AP to do some pretty amazing things. Depending on which 802.11n features are implemented in a 3x3 802.11n AP and/or client stations, significant additional range is possible. This additional range can result in sticky connections where stations will stay connected to an AP far longer than they should. For example, a station can roam from an AP on channel 36 into an area covered by an AP on channel 40. No big deal, right? That depends... Then it keeps roaming into another somewhat nearby area where another AP is using channel 36. The two APs on channel 36 may not cause each other any problems, but the station transmitting on channel 36 from cell B to cell A causes both cells significant interference. Adjacent channel (e.g. channels 36 and 40) interference and co-channel (e.g. channels 36 and 36) interference problems can be pretty significant depending on AP spacing, output power, antenna sensitivity, antenna gain, obstacles, and other factors. Just slipping an 802.11n AP into a network designed for 802.11a/g will, in most cases, experience significant interference problems.
As my great grandmother used to say, "What to do, what to do?" A new site survey - each and every time an 802.11n AP replaces an 802.11a/g AP. Impossible? Yes....and no. It's obviously not feasible to do a manual site survey every time you do a 1:1 replacement. So what do we do in the meantime? Automagic RF management features in WLAN controllers. Turn it on, hope it understands the difference between 802.11a/g characteristics and 802.11n characteristics and the interaction between the two. If it does a good job of selecting the right output power and channels, perhaps the problems will be minimized. But these features won't take into consideration client-side capabilties. How many 802.11a/g clients do you have? How many 802.11n clients?
Then there's the applications like VoWiFi. Most company's best practice documents for deploying VoWiFi say to do manual (static) site surveys. Some VoWiFi phone vendors say that it's absolutely mandatory if they're going to support the deployment. What then? To be honest, I don't know yet. I'm betting I'll be hearing all about the woes of these issues soon enough. Maybe we'll luck out and someone will have a great solution soon.