Analyzers aid VoIP-WLAN rollout: retransmissions, dropped packets among the problems associated with voice-over-wireless networks.

Adoption of voice over IP (VoIP) over wireless local area networks (WLANs) in corporate and university environments is gaining momentum. Unlike data, however, VoIP is far less tolerant to momentary delays and errors common to WLANs, and such problems quickly degrade voice quality. Integrating VoIP into a corporate data network requires careful planning, especially if you plan on operating VoIP over 802.11 WLANs. There are several key questions to resolve when planning a WLAN-based VoIP rollout.

To start, a VoIP conversation using G.711 encoding audio at 64 Kbps requires about 90 Kbps for a high-quality conversation, including the protocol overhead. Other VoIP devices, such as instant messaging, can get by with as little as 10 Kbps, although with lower voice quality.

On an 802.11 b WLAN, frames are transmitted at up to 11 Mbps. There is a lot of overhead before and after the actual transmission of frame data, however, and the real maximum end-to-end throughput is more on the order of 5 Mbps. So, in theory, 802.11b should be able to support 50-plus simultaneous phone calls to and from phones that directly support Vole or to end nodes with VoIP capability, such as wireless laptops.

802.11g increases the transmission rate to 54 Mbps and has less overhead, but "pure g" environments are still rare and the presence of just one 802.11 b neighboring device can ruin the efficiency of 802.11g. 802.11a is another alternative, but has its own pros and cons.

VoIP traffic is sensitive to dropped packets, network latency (delay), jitter (packets arriving at a variable rate) and packets arriving out of order. Packets typically arrive every 20, 30 or 60 milliseconds, depending on voice sampling in the end-node VoIP client and the bandwidth available to the end node. A buffer on the receiving end (usually called the "jitter buffer") typically delays the release of the packet to the user by one packet (thus 20 to 60ms) in case of late packet arrival.

Frames that are totally lost or dropped are rare in WLANs. What is common, however, is that frames are susceptible to errors. Cordless phones, microwave ovens, multipath reception, distance from the access point and nearby WLAN channel interference can all cause WLAN frames to be corrupted during transmission. Unlike Ethernet, which disregards error frames at the MAC layers, WLANs have an immediate acknowledge-and-resend mechanism for data frames.

Thus, WLANs recover from frame errors quickly without the upper-layer protocols even knowing about them. Error recovery does introduce some delay, however, and causes other WLAN traffic sharing the same channel to be put on a short hold. Most TCP retransmissions seen on a WLAN analyzer are usually caused elsewhere in the wired part of the network infrastructure.

A WLAN protocol analyzer can be used to check the arrival rate of VoIP packets. The analyzer can help determine if the packets present in its capture buffer are likely to be dropped by the receiver.

Another issue is that when a WLAN has to resend a frame, it typically does so at the next lower supported data rate. For example, if a frame fails at 11 Mbps, it is resent at 5.5 Mbps, effectively taking the equivalent bandwidth of three frames at 11 Mbps to send one frame. If the retransmission fails, the next try is at 2 Mbps. Some IP phones are configured to resend data at 11 Mbps, but the problem with this approach is that it requires a solid signal from the access point to continue to operate at this data rate. If the user moves beyond the range of 11 Mbps, the phone may not function.

To help spot coverage or bandwidth problems across the WLAN, a protocol analyzer can be used to look for 802.11 retransmissions and the data rate of the retransmission.

Along with retransmissions, using an analyzer can reveal other issues. For example, simultaneous two-way conversations with IP phones are possible. Two people would not necessarily be talking at the same time, but any background noise at the listener's location is also transmitted while the other party is talking.

Another issue is simultaneous data transfers. If the WLAN does not have quality of service (QoS) implemented for VoIP (i.e., the 802.11e standard or a vendor's interim proprietary solution), the number of supported conversations drops even further. A WLAN analyzer, however, should be able to quickly spot the nature and origin of these problems.

Generally, VoIP systems are encrypted on the WLAN to prevent anyone from tapping in on voice conversations. Most end points (clients or access points) encrypt and decrypt fast enough to have little effect on VoIP quality, but occasional problems do arise.

Analyzing encrypted data can be a challenge, but a protocol analyzer can overcome this obstacle by:

* identifying a steady stream of encrypted VoIP traffic, given knowledge of the end application associated with a particular MAC address;

* providing a WEP key from a VoIP phone and plugging it into the analyzer to fully decode the protocols; or

* using an analyzer on the wired side of the access point to look at the unencrypted traffic.

LAN analyzers usually offer optional advanced VoIP analysis features, such as the ability to play back conversations, vary the jitter buffer values on playback, diagram the signaling and transport protocols, and compute a voice-quality score, such as mean opinion score. These features provide a measure of each conversation's quality relative to the others and to what users are reporting.

Another advantage to looking at unencrypted packets is that many VoIP devices send out period reports containing jitter information experienced by the receiver. Real jitter, as experienced by the end nodes at both ends of the conversation, can be seen without having to place an analyzer at those endpoints.

Ultimately, users interested in a complete picture of VoIP performance issues will want a combination of LAN and WLAN analyzers, because once on the LAN side, the wireless errors or traffic load that may be present on the WLAN cannot be seen.

For more information from Wildpackets: www.rsleads.com/502cn-252