No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

A Little More Voice (and UC) Over Wireless LANs

This is a little follow-up to Zeus Kerravala's piece on the requirements for sending acceptable quality voice over a WLAN. To be sure, Zeus is dead on with his observation that there is a resurgence of interest in using WLANs as a potential vehicle for providing local mobility to UC deployments, and Microsoft's Lync is at the center of that interest. I saw that at Enterprise Connect and even more so a month earlier at the Lync Conference in Las Vegas. The bad news is that delivering a good user experience for voice over a WLAN is a challenge today--but there are initiatives underway that could make it a whole lot easier.

Back in 2008, I published a book titled Voice over WLANs--The Complete Guide, and now 6 years later it seems the topic is coming back around. VoWLAN had already caught on to a minor degree in certain industries like health care, hospitality and big box retail, using purpose-built Wi-Fi phones from SpectraLink, Cisco, Vocera, and Ascom. However, the idea is catching its second wind for the broader market with the growing adoption of UC. The challenge increases with UC in that the idea is to use the WLAN to mobilize the whole UC experience with smartphones and tablets.

Zeus hit most of the big requirements for bringing a WLAN up to snuff for voice. Those would include dense pervasive coverage so the user is guaranteed to have a good signal wherever they roam. Further, the idea of having overlapping access point coverage and the ability to "fill the hole" should an access point fail will certainly improve reliability.

However, there is also a requirement for quality of service (QoS) to minimize latency, packet loss and jitter--thereby ensuring a high-quality user experience. WLANs operate on the principle of "shared media" where all users associated with a given access point share one half-duplex radio channel, but the Wi-Fi Multi Media (WMM) certification (also identified by the IEEE standard 802.11e) provides a mechanism to prioritize voice and video packets over data traffic.

WMM provides a basic (though ingenious) prioritization mechanism, but you should also investigate call admission control to limit the number of voice calls that can be set up through any access point (AP). As voice traffic is given priority, if too many voice calls are running through the same AP, you can essentially "squeeze out" all data traffic, and if the situation continues, you can even overflow the AP's capacity for voice traffic, leading to degraded voice quality. The IEEE 802.11e QoS standard did have a signaling mechanism for call admission control, called TSpec, so stations could indicate how much bandwidth they would need, but it has not been widely implemented.

A bigger problem we are facing with smartphones and tablets is referred to as "stickiness." Unlike a cellular network where the decision to roam is made jointly by the network and the client, in Wi-Fi the client device alone decides when to drop one AP and associate with another. Unfortunately, the drivers in those smartphones and tablets are optimized for data service, which means they try to hang on to the same AP as long as they possibly can. As they do that, the signal gets weaker, the data rate drops, and the call may disconnect before the roaming decision is made.

There are some tricks that can be done in the infrastructure to drive a voice user away from an AP, but it's not a "clean" solution. That clean solution will be difficult because the Wi-Fi drivers in those clients are not normally "adjustable." Even if they were, there is no link between the application that knows it is placing a voice call and the driver that controls things like QoS and roaming. This isn't a problem with purpose-built voice over WLAN handsets because all they do is place voice calls (also these vendors have been working on this problem for a lot longer).

Help for the stickiness problem may be on the way within the Wi-Fi Alliance. The Alliance has assembled a Mobile Multimedia Marketing Task Group whose charter is to: "Develop a certification that improves Wi-Fi roaming and application performance in the enterprise, public venues and the managed home in a manner that is compelling for vendors." There had been an earlier Alliance certification called Enterprise Voice that looked to address some of the voice over WLAN issues, but it was not widely adopted.

The Wi-Fi Alliance is obviously focused on the challenges involved in sending voice over WLANs, but there is a solution in the works for the bigger problem of user experience in both wired and wireless infrastructures for UC. The UC Interoperability Forum (UCI Forum) is working with the Open Networking Foundation (ONF), the organization that manages the OpenFlow protocol for software defined networks (SDNs), on an enhancement to SDN called UC SDN.

OpenFlow provides a means for SDN network controllers to send instructions to network elements (e.g. switches and routers), but UC SDN is what the ONF refers to as a "Northbound Protocol."

A Northbound protocol would allow things like UC controllers (e.g. a Lync controller or a Cisco Unified Communications Manager) to communicate with the SDN controller to "order up" a QoS-capable path with sufficient bandwidth. Proponents say that this will be simpler and far more reliable than the current process of pre-provisioning QoS parameters and marking voice and video packets for priority handling.

So the situation is still somewhat rocky with regard to running Lync or any voice traffic over WLANs, but the growing adoption of UC is causing the industry to put more focus on it. Importantly, it's now the bigger vendors who are talking up the idea, and with the need to deliver a high-quality user experience, those vendors appear to be willing to put some "weight" (read "investment") behind the technologies needed to make this work.

Follow Michael Finneran on Twitter and Google+!
@dBrnWireless
Michael Finneran on Google+