Giving Voice to the (Apps That Should Be) Voice-Less

Wi-Fi Calling is here, and that fact is causing concern for some Wi-Fi folks.  Wireless LANs that were initially installed as a value-add may be tasked with carrying mobile, high-quality, always-on voice traffic.

The 802.11 standard has had quality of service (QoS) protocols designed to accommodate voice since 2005, when the 802.11e amendment was approved.  That's good.  What's bad is that some voice applications are over-prioritizing their voice traffic, and it could lead to capacity limitations.

First, some background on Wi-Fi QoS:

The original 802.11 standard deigned that all Wi-Fi traffic would be created equally.  That is a GREAT thing for most Wi-Fi networks.  If some namby-pamby user whines to an admin, "Hey, why are you placing that AP in the OTHER room?  I want the AP closer to me," the admin can tell him (or her; women occasionally complain, too) "look, buck-o (or, buck-ess), Wi-Fi gives equal throughput to everyone who's connected.  You'll connect just as fast as everyone else" and the admin wouldn't be lying.

In some circumstances, however, equal access is no good.  For example, this circumstance:


That poor smartphone on the left may have a rough time getting a high-quality voice call if the Wi-Fi environment is crowded.

The enhanced distributed channel access (EDCA) protocol from 802.11e mitigates the problem of using voice in congested environments by creating four Access Categories (ACs).  Each AC is assigned a different range of random values that are used whenever a device is ready to send Wi-Fi data.  The minimum random value is always 0 and the maximum is called the contention window (CW).  Whichever AP or device chooses the lowest random value gets the highest priority when trying to transmit data.  The whole process is called "802.11 Arbitration".

In a crowded environment where only ONE device is running a voice app, EDCA works great.  Even if every device pictured above tries to transmit at the same time, there's an excellent chance that our little smartphone will get priority because the default CW for Voice is 3:


The above diagram is an example of why it makes sense for LOW VOLUME calling services, like FaceTime, WhatsApp and the like to use the Voice AC.

The problem with the Voice AC is that it sabotages Wi-Fi capacity when HIGH VOLUME calling services, like Wi-Fi Calling from cellular providers, are used.

Imagine the same Wi-Fi environment depicted above, but with a higher volume of voice apps:


All of a sudden, the likelihood of collisions rapidly increases because apps using the Voice AC only have four random values (0-3) to choose from during 802.11 Arbitration.

(Now, at this point I should point out that the problem only exists if devices running Voice AC apps are ready to send Wi-Fi traffic at the EXACT same moment.  In less congested environments, Wi-Fi devices RARELY try to send Wi-Fi traffic at the exact same moment.  Microsecond-level differences between different devices' transmit times occur because of natural variations in devices' abilities to get voice traffic ready for transmission.  A Wi-Fi environment needs to get REALLY congested for multiple devices running Voice AC apps to have data ready for transmission at the EXACT same moment.)

A lot of SIP app developers have reacted to the capacity limitations of the Voice AC and have designed their voice apps to use the Video AC.  The EDCA protocol from 802.11e lists the default CW number for Video AC applications as 7.  That means that devices running Video AC apps will choose a random number between 0 and 7 when Wi-Fi traffic is ready to be transmitted.  The end result is that Video AC apps will get slightly lower priority in congested areas, but have a MUCH better chance of keeping call quality high when lots of calls happen at once.  To wit:


See, much better.  Most of the traffic to/from devices running Video AC apps gets a higher priority than Best Effort AC traffic, while at the same time the odds of excessive collisions dwindle.

Unfortunately, there's not much that a Wi-Fi person can do to immediately change ACs.  The decision on which AC to use is up to the app, operating system or transmitting device.  There's nothing that can be done on the controller, network management system (NMS) or AP that can affect which AC a device will use when running a voice app.

One thing a Wi-Fi person can do about QoS is analyze which ACs are being used by popular voice apps.  Sniff Wi-Fi had a blog post on using AirMagnet to check for ACs back in 2013.

The other thing a Wi-Fi person can do about QoS is what this blog post is doing: complaining on the Internet!  If T-Mobile, Verizon and other Wi-Fi Calling providers hear enough complains that the Voice AC is endangering call quality in high-density calling environments, maybe they'll follow the lead of some SIP apps and chance the Wi-Fi Calling AC to Video.

***
If you like my blog, you can support it by shopping through my Amazon link.  You can also donate Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU 

Twitter: @Ben_SniffWiFi
ben at sniffwifi dot com

Comments

  1. Change the Def cw max value on voice ac class is a better alternative. And revise the others accordingly.

    ReplyDelete

Post a Comment

Popular posts from this blog

Spectrum Deception

Free Sniffing in Windows! (Kind Of)

What's New (and Missing) in the WiFi for iPhone 6