Quality of Service - A Simple Explanation

When dealing with voice or video conferencing over Wi-Fi, one can use "quality of service" (QoS) mechanisms to provide differentiated services and prioritize the traffic.  Voice traffic is fairly low bandwidth but, being real-time, is very sensitive to latency (i.e. the delay time between when the message is sent vs. when it is received) and jitter (i.e. variation in latency).   Real-time video such as a two-way video conference is also sensitive to latency and jitter, as well as being high bandwidth. 

Conversely, one way video, such as a stream from a security camera or a Netflix streaming movie, is typically buffered at the receiving end to smooth out jitter effects, which allows variation in how the traffic is received to not impact playback, so long as the buffer is not empty. This buffering can lead to several seconds of delay between the source of the stream and its destination - while such a delay is obviously disastrous in two way communication, it is generally acceptable in one-way communications such as a surveillance camera feed.

The following table shows quality of service requirements for typical applications:

In order for QoS to be effective, it needs to be enabled end-to-end.  If it is enabled on some equipment but not others, you only get QoS on the enabled segments.  There is no QoS over the Internet, but many enterprise voice and video applications are contained within the network itself (e.g. two employees talking with each other over VoIP badges), and thus need not go through the Internet.   Note that QoS is important both for your wired switch devices as well as wireless APs.  If there is not provision for handling QoS on the AP, then the AP itself will not prioritize any traffic. On a network with a relatively light load, this isn't a big deal, but it could be problematic under heavy wireless loads.

There are two basic ways of setting up QoS.  The older, and simpler, method is to dedicate one VLAN as a "voice VLAN", connect all of your voice clients to that VLAN, and then prioritize that VLAN traffic through all of the equipment on the network.  Note that all traffic on the VLAN is prioritized, so if there is a mix of high priority voice traffic and low priority data traffic on the same VLAN (e.g. from a smartphone connected to the voice SSID), there is no distinguishing the traffic.  Accordingly, this approach is best suited for dedicated voice appliances (e.g. wired VoIP phones and wireless VoIP handsets or badges).  The network should be architected such that only voice devices connect to the voice SSID / VLAN.  To minimize roaming issues, wireless security should be WPA2-PSK (i.e. not Enterprise, even with 802.11r support, as some older devices don’t support 802.11r).  The other drawback to this approach is that there is generally no prioritization of the VLAN in the access points, only on the wired network.

The other major approach is QoS tagging and prioritization queues.  This is the 802.11e standard method which divides wireless traffic into four four QoS categories (i.e. in order of decreasing priority: voice, video, best effort, background), with “best effort” being the default priority on any non-QoS traffic.  QoS traffic entering the network via Wi-Fi is put into the appropriate queue and then handed off through the network.  The corresponding prioritization on the wired network actually has 8 categories in Layer 2 and 64 categories in DCSP at Layer 3, but there is a standard (and often configurable) mapping as follows:

With this method, QoS being configured "end-to-end" is extremely important.  If there is a link in the network chain that does not support QoS prioritization, the prioritization is lost and thus ineffective for the rest of the transmission.   Additionally,  the VoIP appliance or softphone application (e.g. on a laptop or smartphone, think Skype) must actually do the QoS tagging – this starts at the application layer and must be passed down within the appliance / application.  If the appliance / application does not do the tagging, then the AP will not know it is voice traffic and will classify it as best effort.   Many appliances / applications have been notoriously bad about actually doing this, making the QoS effort moot. One would hope that vendors who make products in this space are smart enough to be passing these parameters, but the only way to know for sure is to sniff and examine the contents of the actual packets.

These approaches are, fortunately, not incompatible, and if used in conjunction with each other can best assure QoS handling of voice traffic under a variety of circumstances.