802.11e, WMM and Windows Vista

While VoIP and video streaming in the home network might have been exotic applications just a year or two ago, they are more and more moving into the main stream segment. Quite a number of VoIP phones are on the market now such as the Linksys Skype phone, the UTStarcom F1000G SIP phone or the Nokia E-series 3G/Wifi phones. While network load on the wireless link is low, speech quality is usually rather good. Things start to deteriorate, however, once the network starts to get loaded, e.g. due to a high bandwidth file transfer.

To improve things, the IEEE standards body has created the 802.11e standard which defines a number of Quality of Service measures for 802.11b/g/n Wifi networks. All are backwards compatible so 802.11e compatible Wifi access points can handle new and old devices simultaneously. In addition, the Wifi Alliance has created the WMM (Wireless Multimedia) certification program to ensure that devices are interoperable with each other and implement the most important options of the 802.11e standard, priorities and prioritized scheduling (EDCA, Enhanced DCF Channel Access).

While researching the topic, I was wondering how applications running on a PC or notebook for example can take advantage of WMM. After all, not all packets originating from a single device should be treated alike by the wireless card. While packets of a VoIP SIP client running on a machine should be treated with the highest priority, packets of a simultaneously ongoing download or web session should be treated with less priority in order for the VoIP packets to flow smoothly. It took quite some reading to find the answer to the puzzle:

• The WMM certification requires that an application shall control the setting of the QoS field in the 802.11 header by setting the DSCP (Differentiated Services Code Point) field in IP (layer 3) packets according to the priority needs of the application. I gave it a try with a SIP soft-phone client and indeed the DSCP field is set to "Expedited Forwarding" instead of "default" as is the case in other packets (see picture above).

• This and this blog entry by Gabe Frost explain how an application can set the DSCP field when opening a socket connection in Windows Vista and how a WMM compatible wifi network driver then makes use of this information to add a QoS header to the 802.11 MAC (layer 2) frame. In addition, wireless devices will only get the "Designed for Windows Vista" sticker if they implement WMM. Good thing!

Once the frame is maked with a QoS header it is delivered to the wifi card. The wifi card then uses the layer 2 QoS header field to put the frame into the correct priority queue. The following parameters, which are broadcast by the wifi access point, are then used by the network card to decide how long to wait before attempting to send a packet once the air interface is not used by another device:

• The number of slots to wait before starting the random backoff procedure. This value is called the AIFSN (Arbitrary Inter-Frame Space Number). The highest priority queue has to wait for the fewest number of slots before the random backoff procedure is started.

• The random backoff procedure is used to prevent several network clients to start transmitting at the same time. The backoff window size for a frame also depends on the priority queue it is currently waiting in. High priority queues have lower maximum backoff window sizes then lower priority queues. This allows other wireless clients to send their high priority frames before low priority frames of other clients.

• The maximum time before the client has to cease transmitting (TXOP). High priority frames are usually very short (e.g. 74 bytes of a VoIP RTP packet compared to 1500 bytes of data contained in a frame which transports part of a web page). A low TXOP time for high priority queues prevents applications mis-using a high priority for large data transfers and they are also not able to interfere with high priority frames from other local and remote applications.

So if access point vendors, network card manufacturers and operating system designers do their homework VoIP calls and video streaming over wifi should be smooth in the future, no matter what other users are doing in the network simultaneously.

P.S.: QoS issues do not end at the Wifi access point of course. Other measures have to be taken to let the VoIP packets flow in the DSL up- and downlink just as nicely. But that’s another story for another day 🙂