Prioritizing traffic breaches 802.11

Quality of service violates 802.11 standard. But so what?

Supporting quality of service on wireless LANs violates the 802.11 standard.

But so what?

A few weeks ago, I described how SpectraLink Voice Priority (SVP) technology works with many wireless LAN and IP PBX vendors’ gear to enable wireless voice on campus networks.  SVP has long been a boon to enterprises, especially those in which VoIP has been a primary WLAN application, such as hospitals.

And it has never been any secret that SVP is a proprietary method of prioritizing voice over WLANs.  In fact, SpectraLink filled an important gap in the wireless industry even before the forthcoming 802.11e QoS extension was a gleam in anyone’s eye.

In my earlier newsletter, I noted that a wireless guru from WLAN start-up Airespace (which OEMs its WLAN systems to Nortel and NEC) mentioned that his company felt that one of SVP’s requirements, zero random backoff, violated the 802.11 standard.

This is no big deal. After all, giving preferential treatment of any kind to a packet, by definition, violates the current 802.11a/b/g standard. This is because the CSMA/CA part of the current 802.11a/b/g MAC specifies random backoff after every packet transmission. The goal with this particular media access method is to provide equal access to every client station.

By definition, then, giving one station or packet priority over another is a breach. So any vendor touting its QoS or VoIP support would technically be in violation. But if you have voice applications, do you really care?

When the original 802.11 standard was approved in 1997, WLANs were intended primarily as a cable replacement for fixed workstations. So it made sense for all best-effort data packets to have equal access to the wireless medium.

As is typical in networking, though, as network applications evolve, so do standards. Admittedly, 802.11 and its many extensions must have set a new world record by now.  (We’re up to 802.11r, for “roaming” – a task group just getting started at defining inter-AP handoffs.)

Finally, a point of clarification: In an SVP-enabled WLAN, SVP technology per se exists only in the client handsets and in the SpectraLink NetLink SVP Server, which connects to a traditional wired Ethernet switch. In the WLAN vendor’s access points, there is no SVP “code.”

SpectraLink merely asks that the WLAN AP vendor find a way to 1) prevent voice packets from contending for the access medium and 2) prioritize voice such that it does not sit in queue. Whichever way WLAN vendors choose to technically satisfy these criteria is OK with SpectraLink.

Note: SpectraLink does publicly state that SVP is “compatible” with 802.11. That means that SVP works just fine on an 802.11 LAN. Is SVP “compliant” with 802.11? No.