Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > RF/Microwave

Run VoIP through your wireless LAN

Posted: 08 Jun 2005 ?? ?Print Version ?Bookmark and Share

Keywords:wi-fi? design basics? phone system? 802.11b? phy?

By Greg Chesson

Atheros Communications Inc.

Wireless Net DesignLine

Technology companies have created WiFi-based phone systems serving niche markets for several years. Early products were introduced with 802.11b-only wireless subsystems having maximum phone capacity of about five voice calls. These systems often used proprietary signaling and QoS techniques. The wireless phone links wouldn't have been secure, and there wouldn't have been sufficient bandwidth to service data applications and phones simultaneously by current expectations.

Ongoing improvements in 802.11 technologyhigh-rate PHYs, voip through your wireless LAN (cont)" target=_blank>wpa security, and QoS methodspromise to bring voice-over-ip (VoIP), VoIP-plus-data, video-plus-data, and VoIP-plus-video-plus-data applications into the mainstream. The growth of VoIP service providers, small and large, suggests business opportunities for applying 802.11 technology to VoIP, or for providing VoIP service over 802.11.

Unfortunately, there are no standard practices for providing VoIP/802.11 service. There are high-level problems to resolve such as billing, call processing, and secure rapid handoff between systems. There are 802.11-level problems to resolve, such as how to support both VoIP and data on the same wireless channel while also optimizing handset battery life.

Emerging VoIP/WLAN systems will be compared with, and may compete with, cellular phone systems. The cellular systems are synchronous; the phones, base stations, and backhaul connections have common timing. Thus, capacity and timing are known and unvarying. There's only one class of service, voice; thus, QoS access methods aren't needed to provide differentiated or guaranteed classes of service. Even when data services are added, they're added in a way that's compatible with the time slots, multiplexing, and management of the voice services. Cellular systems use licensed spectrum and have planned deployments that avoid interference between base stations. For all these reasons, cellular systems are predictable to the microsecond level.

802.11 systems aren't synchronous, are seldom planned, use unlicensed spectrum, can experience significant interference from multiple wireless networks and other non-WLAN devices, and are generally unpredictable at the microsecond level even though they may be robust overall. Talk time, i.e. battery life, is an important point of comparison between cellular telephony and VoIP-over-WLAN. When 802.11 subsystems are added to cellular handsets, they're constrained to use the existing battery system and will be compared directly with the cellular implementation. A well-designed 802.11 subsystem can deliver talk times and power budgets comparable to cellular systems only by placing the 802.11 subsystem into sleep mode between transmitting voice packets, just like the cellular systems.

Microsecond predictability of synchronous cellular systems is conducive to a synchronous sleep-wake scheduling discipline for the hardware and firmware in the handset. The 802.11 universe, instead, uses CSMA contention methods that conspicuously lack centralized synchronous timing. This is the principal strength of 802.11, and can be viewed as yet another replay of the perpetual debate between packet-and circuit-switching, between Ethernet and ATM, and between robust/adaptive channel access (good enough) and rigid timing (perfection). This means that new protocol engineering is needed to develop power-save timing techniques that work in the non-synchronous 802.11 world.

It's possible to change the 802.11 MAC into a synchronous, slotted-TDMA design either on a full-time or part-time basis. Numerous proposals and proprietary implementations do exactly that. But the result would no longer be Wi-Fi. Although a technically valid approach, a globally synchronous Wi-Fi infrastructure would be incompatible with existing 802.11 devices, and in some cases, not compatible at all. For the immediate future, we must concentrate on how to work with VoIP and Wi-Fi as it's understood today. That means taking full advantage of the toolkit of new features produced by the TGe QoS group and beginning to be certified as WMM (Wi-Fi Multimedia).

VoIP profiles

VoIP is a constant bit rate (CBR) application. VoIP packets, or frames, are continually generated at a constant interval, usually 10-, 20- or 30ms, although there are exceptions (22.5ms). The CBR frames travel from source to sink, passing through a various equipment and links along the path. ITU-T Recommendation G.114 specifies an end-to-end latency budget of 150ms or less. If there's a wireless LAN at the source and/or sink, each WLAN can have only a small portion of the 150ms. If the CBR packets traverse the Internet or a busy corporate network, the arrival timing at the sink won't faithfully replicate the injection timing at the source. Packets will arrive late, or sometimes not at all. And packets may arrive in bunches at well-timed CBR intervals.

Internet-style latency, jitter, packet loss, and bunching are problems for older codecs. The legacy codecs are far less tolerant of packet loss and jitter than modern codecs designed for Internet use. Some would say the classic codecs are largely intolerant of sub-optimal channels. That's understandable given their history. It's s also understandable that there's interest in tweaking wireless LANs to support the stringent needs of legacy codecs. However, that becomes less important with the proliferation of new codec technology.

In the world of VoIP over broadband Internet, conditions are far less than synchronous or optimal. This has spurred development of advanced codec designs that compare favorably with high-end ITU specifications, such as G.729. For example, the iLBC codec from Global IP Sound is now mandatory in the CableLabs PacketCable spec, is an experimental track specification (RFC 3952) within IETF, and is the basis for at least one well-known Internet VoIP product (Skype). This codec claims to withstand 30% packet loss while maintaining voice quality in the presence of Internet-like delay and jitter. It seems to be the perfect answer for a non-synchronous, open system like 802.11.

next page

Article Comments - Run VoIP through your wireless LAN
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top