802.11n Is Coming -- Here's What To Expect

Besides going through the busy work of arranging for briefings at next week's Interop in Las Vegas, I've had the pleasure over the last few weeks of receiving some roadmap and pre-announcement briefings regarding IEEE 802.11n. For those keeping score, Xirrus, Meru and Colubris have all announced their plans, while Aruba, Cisco, Extricom, Motorola, Siemens and Trapeze have still to do so. I predict that by the end of third quarter 2007 most, if not all, of the vendors will have a story to tell. Without breaking any embargoes, I've gathered some interesting points regarding 802.11n that deserve further scrutiny, and I hope to get a better handle on these in weeks and months ahead. If you have any insight or thoughts, please drop me a line (at [email protected]).

Central Vs. Distributed: If you thought the debate was over, I can tell you that it has only just begun. Those unwieldy 'fat' APs (access points) of yore were trashed for 'thin' APs, with all the traffic flowing to the core. With 802.11n holding out the promise of raw data throughputs of 600 Mbps (actual payload throughputs about one-half to two-thirds, with rates dependent on the number of radio chains, environmental conditions and channel bonding), some vendors are changing their pitch, pointing out that wireless controllers/switches will not be able to handle the tsunami of 802.11n traffic. Their answer has been to separate the management and control plane from the data plane. What this means is that the AP performs the switching of client traffic onto the wired network rather than the controller. APs are now required to perform all the security key management, session state management, network and security policy, and any firewall/access control list functions that used to be performed at the core. This is the route that Aerohive, Colubris and Trapeze are following. Meru is taking a hybrid approach by pushing its controllers to the edge switching closet, essentially scaling out its operations, but now gaining an interface into wireline traffic at the edge vs. the core.

There are several purported benefits: Splitting the planes eliminates the likely need to upgrade or add controllers at the core. Although this is true, it adds a significant amount of complexity to the AP's data switching. All the tasks previously performed in a centralized manner at the core now need to be performed on the limited processing capabilities and resources of an access point. Any policy-based user or group rule sets need to be implemented at the edge, even if there are 40 users attached to the AP.

Shifting wireless client traffic from the AP directly onto the edge switching infrastructure also requires the switch port to expose the necessary VLANs (virtual LAN). Previously, the APs were VLAN-agonistic, as all the traffic was tunneled to the core; now, network administrators need to make sure their VLAN design can support the wireless network. Because network administrators are likely to be reticent to deploy every wireless client VLAN to the switch port of every AP, roaming now introduces a new complexity. Whereas before the controller anchored every client connection and created tunnels between controllers as necessary, an AP now may need to act as that anchor if the Wi-Fi client roams to an AP that does not have direct access to the client's VLAN. It's not clear at this point how Colubris and Trapeze implement this L3 roaming (Aerohive has this task on its roadmap for the third quarter '07) and what kind of scalability limits there are, but it will be an important question.

Another purported benefit of AP-based client traffic switching is reduced traffic levels, lower latency and decreased jitter. In a larger installation, where there may be a department server and other resources, a local switching solution avoids sending the traffic to the core and back again. It's not clear how much east-west vs. north-south traffic there is in a typical organization, but this makes eminent sense in a headquarters/branch-office configuration. On the other hand, in a campus deployment most wireless usage is to access e-mail, Web pages and other Internet content. File and print may be the only local resources. Concern about saturating the distribution layer with unnecessary and high volumes of traffic seems unlikely. Most networks have 1-Gbps links at the distribution layer. While 802.11n will support higher access speeds, Wi-Fi still makes up a small percentage of overall LAN traffic and higher link rates do not necessarily translate into greater usage, except perhaps for higher bursts. There's no reason to believe that wireless is the straw that broke the gigabit link.In regards to latency and jitter, Trapeze recently issued a press release highlighting test results that demonstrated a 2.41-millisecond delay for 512-byte packets, in contrast to Aruba's 18.22-millisecond finish. While requiring all the wireless traffic to travel the core and through a controller inevitably adds 'some' latency--and no wireless vendor argues that point--it's questionable how significant an impact it makes. Aruba shared with me a rebuttal report containing its own test results, which shows that the company has latencies in the range of low-to-mid 3 milliseconds for the correctly sized byte frames, as you would see in a VoIP deployment. In any case, a VoIP device's jitter buffer, which could range from 20 to 100 milliseconds, would effectively negate any concerns.

Channel Bonding and Plans: The 2.4-GHz band (a little over 80-MHz wide in the United States) only has three non-overlapping channels: 1, 6 and 11. The three UNII bands in the 5-GHz range are 100-MHz wide and support four 20-MHz-wide channels, each. With advent of channel-bonding to increase performance, each channel is 40-MHz wide. That effectively means that the 2.4-GHz range can support only one 40-MHz-wide channel. On the other hand, at face value it would seem that each UNII band would support two 40-MHz-wide channels, for a total of six. This would make channel planning that much easier.

But there appears to be a catch: One vendor has told me that because of spectral bleedover, only one 40-MHz-wide channel can be used per UNII; this reduces the number of available 40-MHz-wide channels across all UNII bands to just three. If this is true, it means that the channel-bonded systems will essentially mimic the channel plans of existing 802.11b/g systems. (It's still possible to use a collocated 20-MHz-wide channel on the far side of the band.) Another vendor claims that this may be the case in the initial wave of chipsets, but that the limitation will disappear as things are tightened up, as it did with 802.11g.

Perhaps this begs the question, will enterprises deploy channel bonding to maximize throughput or will they maximize the number of channels?

Coverage Layout, Design and Verification: The most significant technical element of 802.11n is MIMO (multiple in, multiple out). This technique takes advantage of the multipath, which was a problem in legacy deployments, now using those multiple RF 'routes' to carry unique sets of information. This increases system gain, which translates into better throughput and coverage. In fact, with direct line of sight the performance could actually 'drop.' Because performance depends so heavily on environmental characteristics, the coverage pattern will necessarily be more 'spiky' and inconsistent. What this means is that all the planning tools, whether integrated into the WLAN vendor's product or provided via a third-party vendor, must be upgraded to account for these characteristics. It also means that the coverage maps won't be as smooth, and guaranteeing service levels at the highest data rates will become problematic.Power Over Ethernet (PoE): As is to be expected, the additional radio chains in 802.11n-style chipsets, up to 3x3, combined with dual-band support, will cause enterprise-grade APs to draw more power than current 802.11b/g chipsets. Today's IEEE 802.3.af standard dictates a maximum power draw of 15.4 watts, while the upcoming IEEE 802.3at standard promises to at least double that. One vendor confirmed that its access point would be running at less than full power and capabilities when powered by a single PoE switch port or power injector. It appears that if an organization wants 'full' output power (generally 100 mW in 2.4 GHz and 40 mW at 5 GHz), use of both bands with channel bonding and with all the radio chains, then additional power will need to be supplied. It remains to be seen what the actual requirements will be--perhaps the WLAN vendors are hoping that the IEEE 802.3at task group will wind down their work so they can point customers to a finished standard.

If this holds true, there are options: Power the AP with a second PoE port, purchase a pre-standard PoE injector or collocate the AP with a power adapter using building power.

Implementation Approaches: A greenfield environment is the simplest new install, but most organizations have some level of Wi-Fi deployment. The majority of shops run an 802.11b/g network, which leaves the 5-GHz range wide open. Even locations that have installed a dual-band radio see light 802.11a usage. Therefore, the best approach to trialing and rolling out 802.11n is to overlay the existing network using the many channels of the 5-GHz band. This will not interfere with clients using 802.11b/g, and the organization can transition users from one standard to another over time instead of flash cutting.

Coverage in the 5-GHz range traditionally has been slightly less, but the extra distance provided by MIMO should allow even existing 2.4-GHz deployments to collocate shiny new 802.11n APs beside an 802.11b/g AP. One possible concern is that the initial 802.11n client chipsets from Atheros and Broadcom have operated only in the 2.4-GHz range, but dual-band chipsets are already underway.

Upgrade Path to the Full Standard: I've been talking the whole time as if the IEEE 802.11n standard has been completed, but the latest information suggests that it won't be finished until early 2009. The good news is that the Wi-Fi Alliance has engaged with the industry and decided to issue certification based on Draft 2.0 of the standard. This week, the alliance announced their testbed, and the first testing will occur the last half of June. And there's no reason to believe that the final standard will deviate in significant fashion from the Draft 2.0 standard, for which there are millions of chips being printed. In fact, there will be a strong financial disincentive to do anything but make sure it's compliant. That said, the enterprise WLAN vendors are making no promises at this time in regards to the upgradeability of the Draft 2.0 product they sell today or tomorrow. The most optimistic case is that it will be a firmware upgrade, and you can bet that all the vendors will be lobbying their main chipset supplier, Atheros, to make sure that happens.These are a few of the challenges and questions surrounding 802.11n that will remain under intense discussion until the first few enterprises deploy this new standard and best practices from the vendors and consultants emerge. In the meantime, vendors will attempt to clarify and differentiate their products and approaches from the competition, fine-tuning their marketing and messaging to crack the market and ruffle the feathers of the current market leaders. In the meantime, if you have any questions or considerations of your own, or comments on mine, please drop me a line ( mailto:[email protected] ) and I'll be sure to poll the vendors for their response.