Do you ever feel like you’re being pulled in all directions at once? You’re constantly being told that you have to have a QoS-enabled network in order to provide the type of performance your time-sensitive applications require. You’ve been told to provide ubiquitous network coverage in every corner of your office by building an overlay wireless LAN so that people can work during their coffee breaks. But wireless is a shared medium—how on earth do you provide QoS over that? If the two aren’t mutually exclusive, what compromises do you have to make to satisfy both requirements?

The application touted as this year's killer app for enterprise wireless LANs, voice, requires quality of service. That, and other problems, make voice less than ideal on these wireless LANs. However, even without running voice, if your WLAN is heavily used, you may find yourself needing to make distinctions amongst the data applications and the users of those applications.

802.11
First off, let’s see what we’ve got in the standard today. 802.11 itself defines the mechanism by which stations transmit into the air. We know that wireless is a shared medium, but while traditional shared Ethernet used CSMA/CD, it’s not so easy to detect collisions on a wireless network, so the equivalent is CSMA/CA (for Collision Avoidance, rather than Collision Detection).

There are actually two aspects to this functionality: the Distributed Coordination Function (DCF) that is mandatory within the specification and the Point Coordination Function that’s optional.

DCF works by each wireless station listening to hear if anyone else is transmitting. If so, it waits till that is complete. Then it basically waits a random backoff time (chosen between two extreme limits pre-configured into it) before it starts to transmit. If, while it’s counting down from its backoff time, another station starts to transmit, it pauses, waits till completion, and resumes counting.

With PCF, the access point takes control of the airwaves and creates contention-free time periods where all stations wait to be polled by the AP. This would be good except that there’s no way to distinguish between different traffic types and in fact it’s not widely used in commercial products.

802.11e
A new standard, 802.11e is currently being worked on by the IEEE to deal specifically with QoS. This builds on the ideas of DCF and PCF, using a mechanism called the Hybrid Coordination Function (HCF), which itself includes two access mechanisms: Enhanced Distributed Channel Access (EDCA) and HCF Controlled Channel Access (HCCA).

The two mechanisms are different, acording to commentators, because they come from the voice and data sides of the industry. The practical differences are as follows.

EDCA is the basis of the mandatory Wi-F Multisimedia Extentions (WME), which are good for priorititising data applications. EDCA is similar to DCF but will make provision for up to eight user priorities to be set, which can be mapped to up to four transmit queues. The range of backoff times used in DCF can now be changed for each queue discretely, so that in effect higher priority traffic will stand a better chance of getting onto the network more quickly.

HCCA is the more voice-and-video friendly part of 802.11e, and the basis of the Wi-Fi Scheduled Multimedia (WSM). Similar to PCF, HCA again allows access to the network to be granted on a polled basis. Since everything is under the control of the Hybrid Controller (HC), backoff times can be brought down very low, and the HC is QoS-aware, so can schedule transmissions, amount of time a station can have access to the media etc. to support very time-critical traffic.

Vendor options today
Of course, tings will be great when 802.11e devices start to ship. It will be supported on both APs and end stations, so we may even get interoperability, although there will be optional extensions to the specification to watch out for. However, the standard’s not ratified yet, so that is a while off. In the meantime, manufacturers have developed their own mechanisms, although these operate at differing levels.

Most AP vendors offer some sort of QoS-based prioritisation on their APs. Typically it’s done by changing the minimum and maximum limits for the backoff timer within DCF, based on QoS parameters. That’s fine as far as prioritising traffic out of the AP is concerned, but what about the traffic that goes from the end station into the network?

This depends greatly on the end station. Both Symbol and Spectralink, amongst the earliest manufacturers of VoIP handsets, have inbuilt prioritisation for their phones. These interoperate with certain other manufacturers’ APs: Spectralink in particular has proved its Spectralink Voice Priority (SVP) mechanism, which runs on its own Netlink range, with APs from the likes of Avaya, Cisco, and Proxim.

The Cisco 7920 IP handset runs a version of the Enhanced DCF functionality present on the Aironet APs, and support for this EDCF-lite is planned for not only Cisco wireless NICs, but also any NICs following its Cisco Compatible eXchange (CCX) program, as this develops. But in the meantime, while downstream AP to client QoS isn’t so rare these days, upstream is limited to a few specialist end station devices.

You’re actually probably in a better position if you need wireless QoS for voice than for data, as there are phones out there that can do it—albeit in a proprietary manner. If it’s for a softphone running on a laptop, or a data application, then you may have to be wary about what you can and can’t do, and make sure you pin your suppliers down to exactly what they mean when they say they can provide QoS on your WLAN.