Five (Long) Steps Towards VoIP/WLAN Convergence

May 19, 2005

Jeff Vance

Two of the hottest networking trends in the enterprise, VoIP and WLANs, are on a collision course. And most IT managers see this as a good thing, hoping to replicate with voice the productivity boosts they saw when they first unwired data applications.

However, while voice/data convergence seems like a natural way to leverage two existing technologies, it's not quite that simple.

Voice places a number of demands on WLANs that data does not, and since WLANs and the standards behind them were originally designed to be data-only networks, CIOs must carefully plan for the addition of voice.

To integrate voice effectively, a CIO should keep these five fundamental issues in mind:

Handset Availability. According to a new study from ABI Research, annual global sales of "dual-mode" mobile phones, which can connect to either a conventional cellular service or a Wi-Fi network, are likely to exceed 100 million during the final year of this decade.

According to Phil Solis, a senior analyst at ABI, when these services are mature, you will be able to start a phone call at home, continue it in the car, and finish it up at work. All the while, your phone will detect and shift between various Wi-Fi and cellular networks.

That's the hope, but that vision is nowhere near a reality.

While dual-mode phones have begun hitting the market (for instance, Hewlett Packard's iPAQ hc6315, a cell phone/PDA hybrid, offers both Wi-Fi and GSM capabilities, while Motorola intends to release a dual-mode phone soon), problems still exist.

Most service providers have yet to get behind the Voice over WLAN (VoWLAN) push, seeing it as a threat to their revenues -- and other problems, like session persistence, roaming, and the need for multiple accounts for multiple networks, could also slow growth.

Standards. Normally, the standards debate is cast as a choice between 802.11b/g and 802.11a. By selecting 802.11g, network managers get the advantage of greater range and legacy support, since 802.11g networks are designed to accept 802.11b clients.

802.11a, on the other hand, operates in a cleaner spectrum band (the 5 GHz band, rather than the crowded 2.4 GHz band) and it offers as many as 20 available channels, as opposed to the three channels offered by 802.11b/g.

"The problem with the 802.11b/g vs. 802.11a debate is that it's a false one -- if you plan properly, it's a choice you don't have to make," says Scott Lindsay, VP of Marketing for Engim, a manufacturer of multi-channel WLAN chipsets.

"WiFi spectrum is scarce, so why choose one standard and its corresponding spectrum swath over the other when you can deploy both?" he asks. "If wired networking has taught us anything, it's that you can never have enough bandwidth."

Vendors like Engim and Atheros offer multi-channel chipsets, which allow AP (access point) vendors to design both 802.11b/g and 802.11a into a single AP.

Lindsay noted that a multi-channel design has other benefits as well, such as enabling the consolidation of features like roaming, QoS (quality of service), network scanning, and intrusion detection.

Coverage vs. Capacity. In technical terms, this is one of the key issues in the 802.11b/g vs. 802.11a debate.

802.11b/g offers a much greater range (read: better coverage area) than 802.11a, while 802.11a is designed in a manner better suited for high density environments (read: capacity).

"That's a trade-off you can make in data networks," says Phil Solis of ABI. "However, when you add voice to a WLAN, you need to design for both coverage and capacity."

This is easier said than done, especially in 802.11b/g networks. Since adjacent APs can interfere with each other, and since those on the same channel can cause co-channel interference, RF planning gets pretty tricky.

Lindsay argues that time-sensitive applications like voice and video should be segregated from traditional data traffic and placed on their own channels, while other vendors seek to change how all traffic is handled in WLANs.

"In an environment with a limited amount of traffic, such as a small office or a warehouse, today's WLAN designs will support both voice and data," says Joel Vincent, director of product marketing for Meru Networks, a provider of WLAN infrastructure products. "Traditional WLAN vendors are preaching a design strategy that's exactly the opposite of what you want to do with voice."

In data networks, if you need more capacity, you add more APs. Aside from interference issues, this is also a design that's not well suited for voice.

In voice networks, coverage areas should be large enough to limit client handoffs. In other words, Vincent believes that cellular network design principals should be applied to WLANs.

"If you intend to add voice to a WLAN, you must ask your infrastructure provider whether their equipment can offer broad coverage without sacrificing QoS and how they manage nearby access points on the same channel," he says.

Since RF signals don't stop conveniently at the end of their coverage areas, even the best-planned network will have to cope with co-channel interference in a manner more sophisticated than AP placement.

QoS. At present, WLANs employ best-effort mechanisms for QoS. The networks are designed to handle bursty, unpredictable data since, typically, data packets experience a variety of delays due to network congestion.

In the data world, since applications simply reassemble the packets as they arrive, minimal packet delays don't degrade the end-user experience. Voice, on the other hand, demands a steady stream of uninterrupted packets to ensure a quality call.

Even a slight interruption in the flow will degrade call quality.

While bursty traffic can be addressed through various prioritization schemes, WLAN traffic tends to be "lossie" as well. Not only are packets delayed, but they are also often lost entirely.

With a voice call, the applications cannot recover when too many packets are lost, and the call is dropped. Standards like 802.11e will supposedly address this, but until they are approved, the issue remains.

Vendors like Engim advocate placing voice and data on separate channels, while the likes of Meru believe that treating WLAN traffic in a time-sensitive (rather than bandwidth-sensitive) way will improve QoS without sacrificing coverage.

Either way, before committing to a WLAN infrastructure, CIOs must figure out how their networks will address QoS issues.

Roaming. When it comes to VoWLAN deployments, there are two types of roaming, the first being from the cellular network to the WLAN, and the second being intra-WLAN roaming from AP to AP.

The problem for CIOs is that planning for cellular-to-WLAN roaming necessitates a wait-and-see attitude, since much of that issue will be determined by carriers who have yet to commit fully to the idea, and handset vendors who are just beginning to debut dual-mode phones.

"The first thing you have to ask is: 'Why aren't there more Wi-Fi-enabled telephones today?'" says Lindsay. "Basically, it boils down to power consumption. Poor battery life is the main reason that handset manufacturers have been slow to commit to Wi-Fi."

The second type of roaming -- intra-WLAN roaming -- is actually the major culprit here. Much of the battery-life problem is related to how clients roam in today's WLANs. AP-to-AP roaming puts a huge burden on the client, since it's up to the client to scan the network and determine where to go next, thereby consuming a lot of power.

"The big problem with WLAN roaming today is that it's not intelligent," Lindsay says. "Infrastructure needs to move away from burdening clients to assisting them. If your network can scan channels and available APs for the clients, telling them where to go rather than forcing them to waste power scanning the network themselves, you'll see much better performance on the client side."


0 Comments (click to add your comment)
Comment and Contribute

Your comment has been submitted and is pending approval.



 (click to add your comment)

Comment and Contribute

Your name/nickname

Your email


(Maximum characters: 1200). You have characters left.