The territory for large-scale enterprise wireless LANs is mostly uncharted, yet many are now looking at how to build a standards-based, enterprise-grade WLAN for both voice and high-user-density data. But getting to the sort of user density that large enterprises will expect for pervasive WLAN deployments, and running voice across the same enterprise wireless network, is not easy over traditional systems designed for basic data connectivity. Nonetheless, such a network is possible.
A typical access point can support between 10 and 20 connections, a number easily exceeded in high-density areas. For example, an access point that serves a radius of 50 feet covers an area of 7,800 square feet, and if there are more than 20 active contenders it may exceed the recommended ratings for the system to achieve higher density.
By its very nature, voice is responsible for two problems in this scenario. First, pervasive voice deployment will dramatically increase client density because every enterprise user will carry an always-on device. Second, voice is a demanding application with respect to missed or delayed packets. Though not harmful to data, such events can destroy a voice call.
Specifically, to bring voice and data together in the enterprise, data traffic needs predictable throughput, low loss and no disruption of service while roaming. For its part, voice traffic needs low latency, low jitter, toll-quality voice and imperceptible handoffs.
It turns out that the requirements for both data and voice can be satisfied adequately without requiring any specialized hardware, firmware or software upgrades at the clients over the IEEE 802.11-standard media-access control (MAC) function. Instead, the requirements can be met through innovation in both algorithms and architecture in the WLAN infrastructure.
Such innovation makes it possible to support more than thirty 64-kbit/second voice calls/cell; a sustained end-to-end throughput of over 6 Mbits/s aggregate per cell for up to 100 users per cell; a mix of high-density voice and data traffic in the same network; and 2-millisecond handoffs for clients. This can be accomplished on an 802.11b network, with 100 percent standard IEEE 802.11 Distributed Coordination Function (DCF) clients and no specialized client software. For 802.11a/g clients, the benefits are commensurately higher.
The importance of sticking with plain, standards-compliant DCF for a WLAN design stems from the need to simplify the support required when the network is deployed. There are many vendors, each selling different types of cards with different firmware versions that fix some problems and introduce others-and all of that behaving differently, depending on the flavor of Windows each laptop or client uses. There is no unified mechanism for enforcing firmware enhancement or compatibility. The safe bet is to assume that clients are only using the basic IEEE 802.11 DCF MAC protocol.
Peak transmission rates have risen dramatically, from 2 Mbits/s to 11 and 54 Mbits/s, and soon they will top out at over 100 Mbits/s. While almost every client supports rates of more than 11 Mbits/s, the effective performance in a cell with 20 clients nonetheless drops below 200 kbits/s per client.
It turns out that all of that extra bandwidth goes to contention-the fighting that each station does to get time on the air. The way to solve this problem is by coordinating the protocols across access points (APs). Infrastructure that does this can now combine both downlink and uplink scheduling, in order to achieve statistically predictable channel access. Unlike quality-of-service (QoS) tagging, this is needed for dense data networks whether or not voice is present-let alone voice networks of any real scale.
In 802.11, the clients decide when and where to associate and hand off, and they do so independent of one another. This causes a Ping-Pong effect, where clients spend much of their time flopping from AP to AP rather than transmitting or receiving data. Voice transmissions cannot afford the losses involved with too many handoffs or of handoffs taking more than a few milliseconds, which may reduce the quality to unacceptable levels, as measured by the Mean Opinion Score.
If a network uses IPSec or other security protocols, the handoff can also destroy the security context as the network interface goes down and up. The renegotiation time could be in the seconds. The key here is for the infrastructure, rather than the client, to take on the role of deciding handoffs, as in a cellular network, and to perform these handoffs as quickly as possible. The best way to do this is to create "virtual access points" that span multiple radios but appear as one AP to the client.
In the end, it boils down to air traffic control, or the provisioning of the air for downlink and uplink packets. In environments where the air is well used, such as a converged enterprise network, air traffic control is critical for any form of predictable or uniform end-to-end performance.
While most WLANs experience unpredictable latency and jitter as a result of random channel access (top), proper air traffic control overcomes latency and jitter issues by providing uplink and downlink QoS (bottom).
In many vendors' minds, QoS equates just to priority scheduling. While this thinking applies very well to switched networks, it does not work for wireless networks, which use a shared, hublike medium. Wireless, of course, uses multiple transmitters that make independent decisions. To keep the independent transmitters from fighting, an access point must take into account uplink and downlink scheduling. Maintaining control of the channel is the key.
Just as with cellular networks, the actual control of who transmits and who doesn't is what gives the network robustness and scalability.
Vaduvur Bharghavan is chief technical officer and vice president of engineering at Meru Networks (Sunnyvale, Calif.)