UC Over Wireless LANs
Much to my surprise one of the big topics at the Lync Conference last month and at Enterprise Connect last week was the idea of supporting UC users, particularly real time voice and video users, over wireless LANs. Back in 2008, I published my first (and only) book titled Voice over WLANs- The Complete Guide, so 6 years later, the topic is finally coming into vogue. There has been some limited adoption in industry verticals like health care and big box retail using purpose-built Wi-Fi phones from SpectraLink, Cisco, Vocera, and Ascom, but the idea has clearly not broken into the mainstream. With UC, organizations are looking to use WLANs to mobilize the whole UC experience using smartphones and tablets.
Along the way I was fortunate to meet two of the folks who are instrumental in brining this idea to fruition, Pascal Menezes, Principal Program Manager in the Skype and Lync Strategic Relations and Solutions group at Microsoft and Manfred Arndt, Chief Technologist for UC&C at HP. The battle here is being fought on two primary fronts: the UC Interoperability Forum (UCI Forum) and the Wi-Fi Alliance.
One of the big challenges in UC networking for real time voice and video is the need to provision quality of service (QoS) capable paths through the network to minimize latency, packet loss and jitter thereby ensuring a high quality user experience. The traditional mean of providing those services involved programming the packet handling priorities in the switches and routers in the network and then having the end point mark each packet with the appropriate QoS markings (e.g. Diff Serv Control Points or 802.1p priority markings) to indicate their status.
Basic mechanisms like that can work with purpose-built voice over WLAN handsets like those from SpectraLink or Vocera, but it becomes all the more challenging in UC. In a UC environment by definition a single end point can be generating multiple data streams (e.g. voice, video, IM, email, screen sharing, etc.) that will have different QoS requirements. What’s more, in those end points there is often no link between the applications generating those data streams and the Layer 2/Layer 3 components that are responsible for setting the packet and frame markings. The situation is not unlike an IP softphone that can be sending time sensitive voice packets along with traditional data traffic out over the same physical interface.
On one front, the UCI Forum is working with the Open Networking Foundation (ONF), developer of the OpenFlow protocol for software defined networks (SDNs) on an enhancement to SDN called UC SDN. As I described in an earlier piece, OpenFlow provides a means for SDN network controllers to send instructions to network elements (e.g. switches and routers). UC SDN is what the ONF refers to as a “Northbound Protocol” allowing things like UC controllers (i.e. the servers that make connections in a UC environment) to communicate with the SDN controller.
In this environment, when a user required a real time voice or video call, the UC controller could order it up via the SDN network controller that would in turn signal to the switches and routers in the path to provision the connection. The switches and routers would not need to be pre-provisioned, and the voice/video packets would not need to be marked. At the outset, HP and WLAN switch maker Aruba Networks are supporting UC SDN for Microsoft’s Lync controllers.
UC SDN addresses the QoS requirements of real time UC services, but there are other challenges in doing voice when we introduce WLANs. For some years we have had a QoS capability for WLANs that was described in IEEE 802.11e; the Wi-Fi Alliance’s certification for that is called Wi-Fi Multi-Media (WMM). It too suffers from the same inter-layer communications problem as the applications generating the traffic have no way to indicate to the Layer 2 components to mark the voice packets and handle them according to the WMM specifications.
Providing a good user experience in a WLAN requires more than just packet marking. WLANs operate half duplex (i.e. can only send in one direction at a time) over shared media (i.e. all stations associated with a given access point share that one half duplex channel). While WMM can allow voice and video packets to be given priority access to the shared channel, the network also needs call admission control to ensure that it can process all of the voice and video packets its offered. If too many voice/video connections are allowed to set up on the same access point (or if additional active voice/video users roam in), latency and jitter will inevitably increase.
That job of “protecting voice from voice” is made all the more challenging because WLAN clients will operate at different data rates depending on what radio link standards they support (e.g. 802.11a, b, g, n, and ac) and how far the user is located from the access point. So an 802.11n user operating at 72 Mbps could be sharing the channel with an 802.11b user sending at 1 Mbps. Each of those stations will be sending 50 packets and receiving 50 packets per second, but that 1 Mbps user is going to be keeping the channel busy for a lot longer doing so. Also, the data rates for each station can vary throughout the call as the user moves around. The IEEE 802.11e standard did have a signaling mechanism called TSpec so stations could indicate how much bandwidth they would need, but it has not been widely implemented.
The other pressing problem with WLAN voice is roaming between access points, or more specifically what we refer to as the “stickiness” problem. Unlike a cellular network where the decision to roam to another cell is managed jointly by the client and the base station, in Wi-Fi, the client alone decides when to drop one access point (AP) and associate with another.
The problem is that the decision to move is made by the Wi-Fi driver, and the drivers in smartphones and tablets are typically designed for data as opposed to voice use. In a data environment, we don’t want the client jumping willy-nilly from AP to AP, so it will be designed to cling to that original AP for as long as possible. If the driver follows that same logic on a voice call, it may stick to that original AP until the signal gets so weak, the call drops. As before there’s no way for the application in the client to signal to the driver that it’s setting up a voice rather than a data connection, and even if it could, the roaming parameters in the driver are not “adjustable.”
The Mobile Multimedia Marketing Task Group at the Wi-Fi Alliance is looking to address this and other problems with a certification to solve this and other problems with WLAN voice. The task group’s 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 certification called Enterprise Voice that looked to address some of the voice over WLAN issues but it was not widely adopted.
So while the situation is somewhat rocky on the UC over WLAN front at the moment, things are starting to move in the right direction. Problems like stickiness and the need to incorporate QoS and call admission control in WLANs to support voice were recognized years ago by companies like SpectraLink who made voice over WLAN handsets, but ironically, they now need to be “rediscovered” in UC.
However, the wheels are starting to turn, and hopefully in the not to distant future, we will be able to deliver the type of UC user experience over WLANs that our users will undoubtedly expect.