Analysis: Voice Over Wireless LAN

Voice-Over-Wi-Fi, or Vo-Fi, is liberating: Employees break free of binding wires and dodge cellular costs, while IT realizes the ROI promise behind WLAN investments. But our tests show that delays in a fast-secure roaming spec could slow adoption in large enterprises, which will be loath to choose between security and voice quality. Moreover, like star athletes with steroid habits, Vo-Fi vendors must break their addictions--in this case, to proprietary methods of accomplishing everything from call access control to QoS--if they hope to move beyond their conventional vertical markets.

In particular, it's high time vendors stopped using ambiguity in the SIP (Session Initiation Protocol) standard as an excuse to remain entrenched in proprietary signaling protocols ... and to keep customers locked into their product lines. An overall lack of adherence to specs among handset makers is unnecessarily limiting choice and raising the cost of doing Vo-Fi.

Sure, standards groups are moving at their usual snail's pace in some areas, including roaming and load balancing. But the IEEE, IETF and Wi-Fi Alliance have made strides in developing open standards that vendors could tap to improve interoperability among enterprise Vo-Fi handsets, WLAN infrastructure devices and PBXs.

It's not only fear of lock-in that's slowing adoption. Performance is also a limiting factor: Data apps, such as e-mail and Web browsing in fixed locations, rarely taxed the average enterprise WLAN's ability to deliver quality service. Voice is significantly more demanding. Despite their apparent simplicity, single-mode Vo-Fi phones demand attention to signaling, power optimization, fast and secure roaming, call-admission control, and load balancing. Dual-mode phones add a twist: radio interface with cellular networks and the need for coordinated hand-offs to the company PBX. With an upper limit of eight active calls per Cisco AP, densely populated sites may experience saturation. And lack of QoS could hobble your Vo-Fi initiative if you're not careful, especially since the standardized wireless QoS method has been slow to be supported.Our take: Verticals can afford to accept proprietary choices because the benefits are there, but the general carpeted enterprise should take a wait-and-see approach. Vo-Fi is not going to gain wide traction until key standards are in place.

Continue Reading This Story...

In The Hunt

SpectraLink is the Vo-Fi pioneer. Its product came to market in 1999 with the proprietary protocols necessary to realistically support early wireless VoIP, developing and adding a wider range of PBX integration as the offering matured. SpectraLink has established itself as the market leader and just introduced a new line of handsets that reflects the next wave of Vo-Fi technology.

Cisco's Vo-Fi handset is similarly proprietary, offering no vendor-supported integration with non-Cisco PBX platforms. It's clearly meant to provide a mobile aspect to Cisco's PBX product line. Vocera Communications took a different approach. With an emphasis on hands-free voice, it uses advanced speech recognition to provide internal voice communications, with some ties into existing telephony systems. Its badge-form-factor devices are very popular in hospitals. In fact, most of its customers are in the health-care industry.

Hitachi's Hitachi Cable division represents a new era of wireless VoIP handsets built entirely around industry standards like 802.11 and SIP. These devices are an obvious choice for organizations that have a PBX with a SIP interface. Get complete results of our tests of handsets from Hitachi, SpectraLink and Vocera at nwcreports.com.Miles To Go

Before we can recommend VoWLAN for most enterprises, vendors must overcome performance and security limitations. Although standards to address some challenges have been settled, gaps remain, notably in fast-secure roaming, call-admission control and load balancing. Fixes are being worked on, but are likely a year or three away.

Unlike data applications, which are virtually insensitive to roaming events that take several hundred milliseconds (ms) or more, VoIP demands a consistent packet flow with minimal loss, latency and jitter. Even a few missing packets can be detected by the listener. To better appreciate the challenges, we diagrammed a typical roam (see "A Typical VoWLAN Roam").

The commonly accepted target roaming/cut-over/gap-time metric for voice transitions is 50 ms, generally considered the maximum acceptable break in audio. Our tests demonstrated that, with an appropriately configured WLAN infrastructure and handsets, this target time can be easily achieved ... if you don't want security. Add in WPA-PSK (Wi-Fi Protected Access with Pre-Shared Key), or even more problematic, 802.1X-based authentication, and roam times jump to hundreds of milliseconds, even in controlled circumstances.

Another concern is that the QoS resources of the target AP are not known until the roam completes. Ideally, the handset will know before the roaming event occurs if the necessary QoS is available.AP vendors have not stood still. Cisco introduced CCKM (Cisco Centralized Key Management) many years ago to address secure roaming concerns, but CCKM requires a Cisco WLAN infrastructure. This proprietary fast-roaming functionality was introduced with Cisco's LEAP (Lightweight Extensible Authentication Protocol), with EAP-FAST (EAP-Flexible Authentication via Secure Tunneling) following. Cisco added more 802.1X types (PEAP, EAP-MSCHAP, and EAP-TLS) in CCX (Cisco Compatible Extensions) Release 4, but most are supported only in the very latest Cisco WLAN infrastructure devices and cards, with the appropriate software.

Meru Networks and Extricom have taken a different approach: Don't let the client roam at all. In their architectures, each AP shares the same BSSID (MAC address). From the client perspective, it sees one large AP. The WLAN infrastructure manages which AP communicates with a given client. Although elements of this design remain problematic--for example, when roaming across APs on different controllers, delay will be around 50 ms--the benefits for Vo-Fi deployments are obvious.

So where are the standards? The IEEE has a task group working on IEEE 802.11r, which aims to minimize roaming time between APs. Although there's been speculation that fast-secure roaming would match the 20 ms to 30 ms of WEP (Wired Equivalent Privacy), the task group hasn't been able to agree on specifics regarding times.

The IEEE 802.11 schedule points to ratification of 802.11r in fall 2007, with products supporting that standard following many months later. For most enterprises this can't happen soon enough. In the meantime, organizations that don't use Cisco gear can remain open; use WEP, which is only a casual deterrent because there are attacks that can break the keys in seconds; or use WPA-PSK or 802.1X and expect occasional detectable roaming events, say, if a user is walking while talking on the phone.

Dueling HandsetsThe next challenge is to choose handsets. Dual-mode devices add a Wi-Fi radio to the GSM or CDMA radios found in normal cellular phones. In the same way that VoIP phones connect to the PBX over the corporate LAN, a dual-mode device uses the company's Wi-Fi network. Advantages include single-number access to mobile workers, single-device convergence, unified voicemail, lower cellular minute usage as calls in the office terminate over the WLAN rather than the cellular network, and a remedy for poor indoor cellular coverage.

Challenges remain as well: Device selection is limited, integration can be difficult, and savings on cellular minutes are too often gobbled up by expensive handsets; see "What'll All This Cost?". And how many of your workers really need this level of mobility? Sixty percent of respondents to our reader survey said cellular phones are provided to a very limited number of their companies' employees; for more on the results of our reader poll, see nwcanalytics.com.

Indeed, despite the hubbub around VoWLAN, unit and dollar sales of both single- and dual-mode phones remain modest. To put it in perspective, Nintendo's Wii and Sony's PlayStation 3 moved more units just this past Christmas than there've been single-mode Vo-Fi phone sales--ever.

Hey, there's nowhere to go but up. Dual-mode handsets like Nokia's E61 and HP's iPaq hw6940 have come on strong, capturing the imaginations of consumers and enterprises alike. Apple's new iPhone will only further that momentum. The MMC (mobile/mobile convergence) and FMC (fixed/mobile convergence) arenas are gaining traction at home and in the office, as evidenced by trials such as T-Mobile's HotSpot@Home and products from DiVitas Networks; find our take on FMC at nwcreports.com.

Some dual-mode phones are designed to use Wi-Fi for data only, but if the device runs the appropriate OSs, third-party applications, such as SIP clients or Skype, can be installed. Other dual-mode handsets, such as the Motorola A910, use their Wi-Fi connections for UMA (Unlicensed Mobile Access), which enables tunneling into the GSM-standard cellular network over Wi-Fi.Whichever device you choose, continued healthy growth depends on organizations building out WLANs that can actually support Vo-Fi. Our advice? Short term, resist the siren's call of dual-mode where single-mode will do. Manufacturers of dual-mode phones cut their teeth on consumer-grade cellular handsets; they lack single-mode vendors' enterprise experience. Single-mode Vo-Fi phones are much less expensive to purchase, deploy and support and work well for companies that require mobility for employees who predominately stay within range of the company WLAN. Dual-mode phones will be appropriate for those who have company-issued cell phones but could benefit from perks like access to enterprise directories, presence and mobility inside the office. You'll also save on service costs and gain better coverage.

Longer term, as standards develop, dual-mode phones that provide transparent roaming will find broad acceptance in enterprises and homes. Motorola, Nokia and others are working with enterprise WLAN players, such as Cisco, so integration should improve (see "Cisco, Nokia Team on FMC").

Admit None

You've outfitted the staff with sleek new Vo-Fi phones and gathered everyone in your conference room to demonstrate. But now you hear complaints that the devices aren't working. What gives? You tested each phone, and you ran through your presentation in the same room just an hour ago.

It may be difficult to believe, but even a newer WLAN may not be able to handle Vo-Fi. Although the G.711 codec with a 20-ms packetization rate may take only 75 Kbps to 85 Kbps on a wired network, overhead of the 802.11 protocol both in framing and timing, combined with the fact that most phones support only 802.11b, yields an upper limit of perhaps 14 to 15 handsets per AP, depending on how often users will be on the phone. Cisco recommends just seven to eight active calls per AP for its phones (see table, page 48).No wonder early use cases favor verticals such as retail, health care and logistics that typically cover large areas with few people.

To properly engineer your WLAN for Vo-Fi, you'll need a dense AP deployment. If an AP also serves up data on the same radio, you'll need to accommodate fluctuating traffic flows and restrict phones from monopolizing bandwidth. That's where call-admission control can help, by enforcing a limit to the number of active calls an AP will accept.

Cisco, not one to shy away from creating its own standards, has made call-admission control a part of its proprietary CCX. Cisco licenses CCX code to client manufacturers, but reserves CCX support on APs for itself. According to the company, upwards of 95 percent of new wireless chipsets sold are CCX-compatible, meaning client devices from a variety of suppliers work with Cisco WLANs.

Through capabilities exposed in CCX, the Cisco handset will receive a fast busy when attempting to make an outgoing call on an AP that can't reserve enough capacity. In the reverse, callers to Cisco handsets that are associated to APs with insufficient capacity will receive the same feedback.

Vocera claims a higher call capacity than most--10 to 12 calls per AP--depending on the infrastructure vendor. By using an advanced audio codec, its packets are just one-third of the size of standard G.711 codecs, reducing overall wireless utilization.SpectraLink implements both call-admission control and timing through its NetLink SVP (SpectraLink Voice Priority) Server. All voice traffic to and from its handsets must traverse the SVP Server, which can be configured to allow a set number of calls per AP. If a handset attempts to originate a call that would put the AP over capacity, the SVP Server informs the endpoint that the upper limit has been reached.

The most pertinent open standard related to call admission control is the Wi-Fi Alliance's WMM-SA (Scheduled Access), which is based on elements within the IEEE 802.11e specification. This standard will let clients reserve resources on the AP to ensure the necessary bandwidth, scheduling and low latency for a good telephony experience. The Wi-Fi Alliance had targeted a mid-2006 introduction, but the standard is still languishing, and our conversations with those involved in the process indicate WMM-SA is low on everyone's radar. It seems the Vo-Fi market is still too small to warrant bringing considerable resources to bear, and because Vo-Fi handset vendors have proprietary methods in place, they're not likely applying much pressure on chipset manufacturers.

It's unfortunate, because from where we're sitting, IEEE 802.11e has the process defined, it's just a matter of coding it up. SpectraLink has expressed support for WMM-SA, so hopefully we'll see it worked into its and other vendors' products once the Wi-Fi Alliance releases the standard.

Feel The Load

One way to deal with the capacity issue is to add more APs, but veteran wireless administrators know Wi-Fi clients don't always play nice and distribute themselves evenly. As 802.11 was designed, APs exert very little control over clients; rather, a client independently chooses the AP to which it will associate, with no consideration as to traffic levels or the number of active clients on the device. Even if clients were evenly distributed among all available APs, traffic utilization could be lopsided, leaving Vo-Fi clients at a disadvantage.With the advent of wireless controllers, the WLAN infrastructure gained network-wide insight into AP client counts and traffic utilization. Load-balancing clients and traffic among APs is one way to minimize the capacity problem.

But because there is, again, no standard, vendors have gotten creative.

One method is to have over-burdened APs ignore client probes and association requests for new clients. That's not ideal because as clients leave and traffic patterns change, one AP may still end up near capacity, while neighboring devices are almost idle.

A more proactive load-balancing method involves disconnecting associated clients and ignoring reconnection attempts. Problem is, some clients are aggressive. Rather than look elsewhere, they'll spin their wheels trying to reconnect, an obvious problem if done during a call. Fortunately, most WLAN infrastructure products are intelligent enough not to load-balance clients with active traffic.

Aruba Networks, Cisco, Trapeze Networks and other infrastructure vendors have--surprise!--proprietary load-balancing algorithms and methods. However, only Cisco can feed information to the client to assist it in making a better roaming decision. A CCX-enabled client can learn from the Cisco AP its network load and use that data in its roaming algorithm. On the infrastructure side, Cisco controllers can be configured such that the infrastructure will automatically move even non-CCX-compatible clients to adjacent and less-loaded APs when the clients are idle.Standards to the rescue again. Two, in fact, play a role. The IEEE Radio-Resource Management Task Group k has spent about four years working on a standard to "define and expose radio and network information to facilitate the management and maintenance of a wireless and mobile LAN." Devices that follow the TGk standard measure utilization and share information about neighboring APs, including channel, signal strength, noise and hidden stations. That means that devices can learn about neighboring APs before roaming. We're hopeful a standard will be available by year's end.

While 802.11k provides clients and APs with the necessary information, Task Group v seeks to add management control at the PHY/MAC layers for attached devices. APs will be able to take a more definitive role in client access to the extent that standards-based load-balancing may be possible. There's much more to the work of TGv than management; it's also addressing troubleshooting and monitoring. And, the project document leans on 802.11k for some monitoring information. The target for completion is January 2009.

Quality Testing

Delivering adequate and consistent voice quality is a stumbling block for wired VoIP, and QoS is even more challenging in a Wi-Fi environment.

SpectraLink tackles QoS and timing problems with its SVP, which also addresses call-admission control. Although the company doesn't make APs, it has worked closely with wireless infrastructure vendors to build SVP support into APs and wireless controllers, including those from Cisco. SpectraLink's market share--and the fact that it shares customers with all major WLAN infrastructure vendors--helped accomplish this.Working within 802.11, SpectraLink does wireless QoS in two ways. First, the AP prioritizes SVP-tagged traffic over data traffic. If the AP supports multiple queues, a high-priority queue is used for voice packets. If the AP has only one queue, voice packets are put at the head of the line. Second, SVP gains priority access to the medium by using a back-off value of zero, rather than a random value between 0 and, typically, 31. So while other devices will average back-off values around 16, SVP packets and SpectraLink handsets will have first crack at the medium.

Rivals, including Vocera, label SVP "cheating," but we have to concede that it's an effective means, within 802.11, to assure wireless QoS. Would we prefer a more standard method? Sure. Fortunately, in September 2004, the Wi-Fi Alliance introduced the WMM (Wireless Multimedia Extensions) certification based on the 802.11e QoS standard, which the IEEE ratified in September 2005. With the appropriate WMM support, APs can assign wireless-bound traffic one of four priority levels: voice, video, best effort and background; applications and clients can assign priority levels as well, with appropriate drivers. WMM requires support on the client and AP to work effectively.

Although not as aggressive as the SpectraLink zero back-off, each priority level has an appropriately sized upper-limit. Unfortunately, even though WMM was introduced more than two years ago, enterprise Vo-Fi vendors have been slow to build it into their products. When Cisco last released a software update for its aging 7920, in early 2006, for example, WMM support was conspicuously absent. Instead, Cisco relies on its proprietary CCX and native controller QoS features. Cisco's newest Vo-Fi phone, the 7921G, is WMM-compliant, a welcome change and necessary component of CCXv4.

Vocera recommends creating a separate VLAN for voice and assigning the whole VLAN priority. It says it endorses the WMM as standard but its own product does not support it, and claims that few customers ask for it. SpectraLink supports WMM, but recommended we turn it off in our tests and use SVP, which it says is likely to be more effective! Hitachi is the only vendor that has fully embraced WMM, and our tests demonstrated the positive results; see nwcreports.com for more.

It's a chicken-and-egg issue: Few applications require what WMM delivers, so developers have been slow to add it. WLAN infrastructure vendors, recognizing the potentially small uptake, have focused their development efforts on more pressing projects.MIXED SIGNALS

Many telephony players continue to buck the SIP trend, on both the PBX and handset fronts, preferring to implement proprietary, IP-based signaling protocols, ostensibly to support their systems' unique features.

Among handset vendors, Hitachi supports SIP, while Vocera is limited to a proprietary signaling protocol. SpectraLink does offer versions of its devices with SIP support, but you'll sacrifice some functionality.

SpectraLink entered the market prior to SIP becoming popular for telephony. The company's business goal was to enable mobile telephony for enterprises, so it had to meet enterprises where they were at the time--running PBXs with proprietary digital and analog interfaces. On the PBX-facing side, the company emulated a digital handset, while on the IP side, SpectraLink wrote its own signaling protocol, SRP (SpectraLink Radio Protocol) and standardized around the compressed ADPCM (Adaptive Differential Pulse Code Modulation) codec, rather than the more common G.711.

Vocera uses proprietary signaling to enable voice-driven hands-free communication. It has not pursued reseller relationships in the same way that SpectraLink has with PBX manufacturers, and doesn't license its protocol, as Cisco does. Of course, Vocera doesn't offer a generic handset, and it isn't seeking to enable generic device access to its system software; more important to it are form factor, weight and audio capabilities.Hitachi has the first enterprise-grade SIP-based wireless handset and claims a customer with more than 7,200 deployed devices (see our take on Hitachi's Wireless IP5000 at nwcreports.com). At Interop 2006 in Las Vegas, SpectraLink demonstrated its regular Wi-Fi handset with a SIP software load working against the Asterisk PBX. Unfortunately, that implementation still requires the SVP gateway for proprietary QoS. The good news is, SpectraLink is becoming more SIP-friendly in response to market demand. Cisco declined to license Skinny with SpectraLink's new NetLink 8000, so SIP will be the signaling protocol with Cisco's Unified CallManager.

SpectraLink also plans to target small-biz VoIP installations that may be using SIP-based PBXs such as Asterisk, Pingtel or Mitel. Ironically, however, SpectraLink discouraged us from using SIP against our Asterisk PBX in our most recent review.

Cisco has added SIP support in the latest version of its Unified CallManager and on a few desk phones, but the company does not support SIP on its popular 7920 handset. As for its newest handset, the 7921G, the company's FAQ states that support for SIP will come later.

Vocera is in a unique position because its value is not exclusively in the handset per se, but also the software on its app server that supports voice commands, unique call features such as call escalation, and can tie into third-party communication systems and apps.

Dial'S' For SecurityMost people take for granted the security built into today's cellular services. While not uncrackable, it serves the general public--obtaining a radio that can tune into the cellular bands is expensive. In contrast, today's Vo-Fi systems are quite easy to tap; a $25 wireless network card at your favorite technology big-box store and a free copy of Wireshark, and you're listening to your boss' most intimate conversations. Without encryption at Layer 2, Layer 3 or Layer 7, it's all in the clear.

We don't expect to see Vo-Fi handsets with built-in VPN support soon, if ever, and the VoIP space has been slow to implement standards such as SRTP that encrypt audio traffic. So, we need to lean on Layer 2 encryption standards such as WEP, WPA and WPA2. All enterprise Vo-Fi players offer Layer 2 encryption based on WEP, but anything more advanced has twists and turns.

When SpectraLink launched its NetLink e340/i640 handsets in 2003, it put most of the cryptographic support into the handset's hardware, based on where IEEE 802.11i was that time. SpectraLink did not announce WPA and WPA2 support until early 2005, several months after the Wi-Fi Alliance introduced the WPA2 certification. Its NetLink line supports only preshared keys, so while conversations may be secure, key management for larger shops remains a challenge. If a new key must be deployed, be prepared to reach out and touch every handset.

Cisco supports LEAP in its handsets, but LEAP is semi-proprietary--the client piece can be licensed, but not the AP side. Moreover, the introduction of the asleap attack by Joshua Wright (now at Aruba) meant that complex passwords had to be tied to each user name; otherwise, a person's credentials could be recovered. One way to mitigate this, of course, is to assign each phone its own user name and password, independent of the actual user. It's likely Cisco wasn't able to justify immediately updating the hardware to include AES support when IEEE 802.11i was ratified in mid-2004. Although its newest handset supports WPA/WPA2-PSK as well as LEAP and EAP-FAST, we saw no mention of other non-Cisco-originated EAP types.

Vocera initially launched with WEP support. It's since added LEAP, WPA-PSK and PEAP, but the company told us customers prefer WEP for its faster roam times. Vocera's badge-like device lacks WPA2 because its Wi-Fi chipset doesn't include hardware support for AES.Vocera added that only within the last few months has it seen wireless chipsets that combine the latest security capabilities--WPA2, 802.11b/g--with the low power demands and compactness it prizes. At the same time, the form factor and limited GUI of Vocera's badge makes entering user credentials especially challenging. Even the preshared key for WPA requires entering a calculated 64-character alphanumeric value rather than the normal eight-to-63-character passphrase.

Vocera's other twist is that it encrypts audio traffic with its own proprietary schemes, such that even if the 802.11 frames were decrypted the conversation would still not be laid bare.

Hitachi has, admittedly, a few security skeletons in its closet. A quick check of the Wireless Vulnerabilities and Exploits site (wve.org) reveals five issues, which the vendor claims have long since been addressed. Still, Hitachi's support for standards-based security is outstanding: Besides WEP and WPA-PSK, it also supports EAP-MD5, EAP-TLS, EAP-TTLS and EAP-PEAP within the 802.1X framework. The IP-5000 handset lacks WPA2 support, but Hitachi says it will enable that in Q2 of this year.

Again, as with QoS and signaling, each incumbent vendor has its own security handicaps. While some can be explained away due to hardware limitations, others--notably Cisco's lack of wider EAP support--only demonstrate their preference toward platform lock-in and limiting choice. As with SIP, it's time to embrace the security standards of the present and give admins the tools to integrate Vo-Fi into their standard security architectures.

Power OptimizationEnterprises will likely be disappointed with the power limitations of current Vo-Fi handsets. While cellular phones may enjoy battery lives of three to five days, Vo-Fi handsets are limited to one to two days. Longer spans are available if handset and WLAN infrastructure work together, typically with proprietary extensions.

Cellular handset vendors such as Motorola and Nokia have a distinct engineering advantage--launching dozens of new models per year, many including Wi-Fi in addition to GSM or CDMA capabilities and with manufacturing runs of tens if not hundreds of thousands, these guys have an opportunity with each successive model to "get it right." Pity the enterprise Vo-Fi vendors still selling hardware revision 1.0 at dramatically lower volumes: The Wi-Fi chipsets found in the newest Vo-Fi phones are only second or third generation, and the initial batch of handsets from enterprise Vo-Fi players Cisco, SpectraLink and Vocera were designed three to four years ago, making them dinosaurs when measured in cell-phone-innovation time--think dog years but in reverse.

Chipset manufacturers such as Atheros, Atmel, Broadcom and Texas Instruments are working hard to develop optimized silicon for these small-form-factor devices, but we expect advances to first find their way into consumer versions, until enterprise Vo-Fi vendors more aggressively rev their devices.

There are several factors unique to Vo-Fi handsets that challenge runtime. According to Michael Ward of Trinity Convergence, which develops embedded software for mobile voice and video applications, if the design dictates a DSP (digital signal processor), an additional applications processor is still required to handle such VoIP functionality as the user interface and call control.

It is possible to use an integrated SoC (system on a chip), which combines both the DSP and applications processor into one physical device. In many cases, an applications processor alone can be used to perform all VoIP processing. The benefit of using an SoC or single-application-processor design is the positive effect of lower power draw due to the lower number of components, as well as a smaller overall package for the components, which allows more space to be allocated to a larger battery. Because most Vo-Fi vendors are using chipsets from three to four years ago, SoC support is limited.WLAN infrastructure vendors have a significant role to play in optimizing power consumption for Vo-Fi handsets. Take simple things like pruning unnecessary broadcast and multicast traffic and performing proxy ARP. The legacy power-save mode, part of the original IEEE 802.11 standard, requires the client to wake up as often as twice per second to listen to the AP's beacon and determine if there's traffic buffered for transmission. In addition, there are client-set intervals to listen for unicast traffic. All this checking in adds up to significant power consumption, even when there's no call in progress.

In one case, simply extending the interval between checks and converting multicast to unicast boosted battery life from 17 hours to more than 100 hours, according to Aruba.

But the greatest power savings are realized when handset and WLAN infrastructure work together. Meru claims it can increase battery life by more than 200 percent if the handset manufacturer uses Meru's sleep-mode drivers. More recently, Aruba announced a comprehensive, aggressive road map toward enterprise fixed-mobile convergence. One element is a plan to provide drivers to Linux-based handsets to optimize interaction with the WLAN infrastructure for battery conservation and roaming performance. Behind the scenes, Cisco has likely undergone the same energy-enhancing tweaking between its own handset and WLAN infrastructure.

Are you detecting a continuation of the proprietary theme here?

The solution in this case is the Wi-Fi Alliance's WMM Power Save standard. WMM Power Save is based on U-APSD (Unscheduled/Unsolicited Automatic Power Save Delivery), which is in turn modeled on some elements within the broader IEEE 802.11e specification.With WMM Power Save, the application, not the device Wi-Fi driver, dictates how frequently it needs to communicate with the AP. The spec also gives the client flexibility as to the retrieval of buffered frames waiting at the AP; this ensures more timely delivery of packets, reducing both latency and jitter. Rather than wait until the next beacon, every 100 milliseconds or so, the client can send a trigger frame. The second advantage is less signaling overhead to flush buffered frames, which results in more efficient use of available airtime.

Unfortunately, of the 25 devices currently listed on the Wi-Fi Alliance's Web site as supporting WMM Power Save, only one is a Vo-Fi-capable phone, and it's from a relatively unknown vendor, MediaTek.

The standard has been out since December 2005, but no enterprise Vo-Fi vendor has a shipping product that takes advantage of it. SpectraLink told us it will support WMM Power Save and shared that, behind the scenes, it's working on interoperability testing with WLAN infrastructure vendors.

Cisco's newest handset, the 7921G, supports 12 hours of talk time or 100 hours of standby. And SpectraLink, with its NetLink 8000 series, offers a choice of batteries, topping out at 160 hours. Apparently Vo-Fi vendors understand the need to stay juiced.

Vocera will likely remain status quo until they release devices based on a new hardware platform. Hitachi plans to make U-APSD part of its next software release but may not undergo Wi-Fi Alliance certification. Cisco's newest phone supports U-APSD, and hopefully when the device is released, it will also be WMM-PS-certified.While each platform is always optimized at the hardware layer for the best balance between power and performance, enterprise Vo-Fi vendors need to work a little quicker to take advantage of relevant standards that address real problems.

Pace Setters

Four vertical markets--retail, health care, manufacturing and supply chain--are taking the lead in Vo-Fi use; they've ironed out implementation kinks and provide models for developing a Vo-Fi infrastructure. The common denominator: A significant number of mobile employees who need ready access to others within, and sometimes outside, the enterprise.

Early on, many verticals deployed proprietary radio systems from the likes of SpectraLink, Engenius and others. Although an improvement over wired systems, these radio deployments locked companies in. Complete forklift upgrades were required to replace aging systems. That changed with the advent of Wi-Fi for data access and inventory; once a WLAN was in place, adding Vo-Fi made sense.

Take health care: In the emergency room, immediate access to nurses and doctors can make a life-or-death difference. Rather than using a delayed pager or call an external cell phone, members of the health team can use in-house systems to make contact immediately. When supply-chain or retail employees need to verify inventory for a customer, prepare an order or load a truck, Vo-Fi can provide affordable voice connectivity in locations where cellular coverage is poor and lots of intrasite communication occurs.If the WLAN infrastructure is ignored as a sunk cost for regular data support, the $300 to $600 price per single-mode Vo-Fi handset is not unreasonable compared with the $250 to $750 tab for today's digital and IP desk sets. Of course, a mobile worker also may have his own or a shared desk set, but the companies that we spoke with consistently said that productivity increases offset those costs.

List prices for single-mode phones range from $300 to $600 each, with accessories, supporting infrastructure and extended warranties extra. SpectraLink introduced a new line of single-mode phones with the NetLink 8000 series but told us it intends to continue marketing its hardy e340 device with a SIP load, and push the price down into the sub-$300 range, to attract the small-business market.

Dual-mode phones are higher, $500 to $700, and prices will likely stay somewhat stable as dual-mode smartphones, which incorporate multiple radios, continue to develop into multimedia computing devices.

Despite the price gap, both Disruptive Analysis and Infonetics Research say sales of dual-mode phones will soon overtake sales of simpler single-mode devices. Infonetics predicts that by 2009, 91 percent of handset revenue will come from dual-mode.

What Will All This Cost?List prices for single-mode phones range from $300 to $600 each, with accessories, supporting infrastructure and extended warranties extra. SpectraLink introduced a new line of single-mode phones with the NetLink 8000 series but told us it intends to continue marketing its hardy e340 device with a SIP load, and push the price down into the sub-$300 range, to attract the small-business market.

Dual-mode phones are higher, $500 to $700, and prices will likely stay somewhat stable as dual-mode smartphones, which incorporate multiple radios, continue to develop into multimedia computing devices.

Despite the price gap, both Disruptive Analysis and Infonetics Research say sales of dual-mode phones will soon overtake sales of simpler single-mode devices. Infonetics predicts that by 2009, 91 percent of handset revenue will come from dual-mode.

Participating Vendors

Hitachi Cable, SpectraLink and Vocera CommunicationsTESTING SCENARIO

We tested Vo-Fi devices on our Cisco WLAN infrastructure, which consisted of a Cisco 4402 Wireless LAN controller communicating over LWAPP to dual-band Cisco 1240AG APs, and our Asterisk PBX. To assess voice quality we used Agilent's Voice Quality Tester Telegra-R, which sends a prerecorded human voice through each handset and assigns a MOS (mean opinion score) to the received signal. We worked inside an RF-shielded chamber.

We generated background traffic by having Ixia's Chariot 5.0 send a 100-kilobyte file for the duration of our testing.

To test for QoS we connected the handsets to our Agilent Voice Quality Tester and placed a call with a SIP-based Polycom IP500 connected over Ethernet to our Asterisk PBX. In scenarios with QoS disabled, each handset was associated to one SSID configured to use the Silver (Best Effort) QOS profile. Where QoS was enabled, we associated each handset to an SSID with QOS profile Platinum (Voice), which provided priority queuing for voice packets.

We measured roaming performance using Azimuth Systems' Phone Roaming script and two Cisco 1240AG APs, one on Channel 1 and the other on Channel 11, placed in isolation chambers and connected over RF cables to the Azimuth chassis. Through the use of variable attenuators, the Azimuth system moved one AP closer to the VoFi phone while moving the other away by increasing or decreasing path loss.For unsecured roams, we configured our infrastructure with open authentication and encryption disabled. For secure roams we used WPA-PSK (TKIP-based) encryption, which involves only AP-to-handset interaction and forgoes 802.1x back-end infrastructure concerns that can add to roaming times.

For a more on the test specifics, go to nwcreports.com.

SCORING CRITERIA

We did not issue a report card.

RESULTSHitachi Cable's WirelessIP5000E Vo-Fi handset doesn't require back-end gateways or telephony servers. If you want direct, standards-based integration into an existing PBX, the IP5000 is appealing. Hitachi's handset is ahead of the curve in wireless standards support and security features, and the company blew away the competition on price because its IP5000 handsets do not need a back-end server.

SpectraLink NetLink system is available in two versions, to support circuit-switched PBXs through the NetLink Telephony Gateway or for direct communications between handsets and an IP PBX. We found voice quality consistently high in all scenarios except when QoS mechanisms were disabled. We also got a peek at SpectraLink's OAI (Open Application Interface) Gateway, which lets third-party applications send and receive text messages from NetLink handsets.

The Vocera Communications System is unique, using small, lightweight speaker-phone badges and voice recognition to allow hands-free communications. This is particularly useful in verticals, such as retail and health care, where mobile workers must remain accessible but on the move. Vocera supports WEP, WPA-PSK and 802.1X mechanisms including EAP-LEAP and EAP-PEAP for wireless security, and we found the speech-recognition system effective and intuitive.

Find our complete product evaluation at NWCREPORTS.COM. Go to nwcanalytics.com for our original in-depth research and analysis on the Vo-Fi arena.

Review

Voice-Over-Wi-FI Handsets use voice-over-IP technology integrated with 802.11-based radios in a cell-phone-like form factor. This technology is particularly popular in verticals, such as hospitals and retail environments, but enterprises may find that a VoWLAN initiative reduces corporate cell phone costs by making use of existing PBX and WLAN infrastructures while giving employees the freedom to take calls anywhere within WLAN coverage.Admittedly, savings won't be fully realized until dual-mode handsets and FMC (fixed/mobile convergence) initiatives let IT aggregate cellular and Vo-Fi functionality into a single device. But as we discuss in "Voice Over Wireless: Past the Hurdles" prices for dual-mode devices are high, and may well remain so for a few years. If VoWLAN is on your radar, a single-mode device might be the best solution right now.

We asked enterprise Vo-Fi handset vendors Cisco Systems, Hitachi Cable, SpectraLink, 3Com and Vocera and to send Vo-Fi handsets that support 802.11b, WPA-PSK (Wi-Fi Protected Access Preshared Key) encryption, and SIP-based or proprietary VoIP telephony to our Syracuse University Real-World Labs®. We also sized up some consumer-focused devices from Hitachi Cable, Linksys and UTStarcom; see "Why Not Go Consumer-Grade?".

Vocera sent us eight lightweight communications badges as well as an eight-bay charger. Hitachi Cable provided us with six of its enterprise-oriented Wireless IP5000A-E phones. SpectraLink sent eight of its industrial i640 handsets, as well as eight smaller e340 phones.

Cisco Systems initially agreed to send its 7920 handset but later backed out, citing timing issues. 3Com did not respond to our invitation.

In addition to evaluating feature sets and usability, we measured voice quality in six different scenarios ranging from basic, involving a sole handset, to complex, including six handsets and three data clients generating background traffic (see "How We Tested Vo-Fi Handsets"). Voice consistently remained at toll quality with all products, except where QoS mechanisms were disabled.Roaming performance was likewise superb for the e340 SpectraLink handsets and Vocera badges, but Hitachi's 5000A-E phones often took two to four times as long as the competition to transition between access points. Hitachi assured us that roaming times can be minimized through optimized settings tailored to each AP and deployment environment. Although we didn't quantitatively measure battery life, our subjective assessment matches talk-time values provided by vendors, with SpectraLink's lasting the longest at four hours, followed by Hitachi's at 3 hours and 10 minutes and Vocera's at just two hours.

Roam On The Range

Roaming occurs as wireless devices transition from service on one AP to another. Although roaming is a key issue in all wireless networks, cellular or otherwise, it's especially important in VoWLAN installations: Vo-Fi handset users often will remain mobile during calls, transitioning between multiple APs, and breaks in service are noticeable.

The roaming algorithms and decisions implemented on handsets play a large role in maintaining acceptable service, because roaming behavior is generally dictated by the client, not the infrastructure; we say "generally" because Meru's and Extricom's schemes are different, as we discuss in "Voice Over Wireless: Past the Hurdles."

In the best-case scenario, handsets will implement pre-emptive AP-discovery roaming, which means they're constantly monitoring the signal quality of their connections while maintaining a list of nearby APs to transition to. Roaming is decidedly complex during a call: Because Vo-Fi handsets have only one 802.11 radio, they must go off their current channels, scan for adjacent APs, and return before the next voice frame--a process requiring precise timing.To assess how well each handset dealt with roaming situations, we used Azimuth Systems' handset roaming test, which measures in milliseconds how long a device takes to transition from one AP to another in a controlled manner.

Wire-line interfaces such as SONET recommend 50 ms as an upper fail-over limit. Meanwhile, the IEEE and Wi-Fi Alliance are discussing sub-50 ms roaming times as a recommendation for the upcoming 802.11r fast-roaming standard. We spoke with a member of the 802.11r Task Group, who said that a hard number for target roam times has yet to be established, but the goal is to minimize service disruptions as devices transition from one AP to another. Of course, there's much debate as to what "minimize" means, but we expect that 50 ms is likely the internal upper limit.

The simplest of roaming scenarios is an unsecured environment with encryption and authentication disabled. In this test, we measured average roaming times of 21 ms for Vocera's handset, 26 ms for SpectraLink's and 93 ms for Hitachi's over 10 successive roams. The Hitachi WIP5000's roaming time was not only the highest of the group, it also varied significantly, from a minimum of 41 ms to a maximum of 202 ms. Rival devices barely broke 33 ms, well under the 50 ms recommendation.

Our second scenario involved WPA-PSK security, which increases roaming complexity because the handset and infrastructure must negotiate encryption keys before voice packets can flow freely. In this case, we measured 81 ms for Vocera's device, 104 ms for SpectraLink's and 219 ms for Hitachi's--once again, a significantly larger delay than the competition's.

Of course, all the products in this case are above the 50 ms recommendation. The takeaway is that security will add additional overhead to roam times, ranging from 60 ms to 110 ms. We brought this to the vendors' attention; both SpectraLink and Vocera said our numbers seemed reasonable. Long roaming times can cause momentary delays in voice conversations--more than 50 ms is detectable by most human ears--or in the worst case a complete disconnection of the call. Although Hitachi's results were higher than competitors, they were not show-stopping, and at no point was a call lost during the test.Voice Quality

VoIP protocols depend on a steady stream of packets to provide acceptable voice quality. Because most voice codecs sample, encode and transmit audio information every 20 ms to 30 ms, the underlying networking infrastructure--wired or wireless--must provide a reliable transport mechanism to support this real-time application. Unfortunately, much can go wrong in a VoIP conversation: Latency or delay in packet delivery can cause echoes and lulls in the voice conversation. Jitter or variations in latency is frustrating for users and can make callers talk over one another. Lost packets, arguably the worst condition, can cause short, silent gaps in conversations, often requiring callers to repeat themselves.

Moreover, because wireless networks are built on a shared-medium architecture, contention among handsets and data clients can cause impact the regular delivery and receipt of packets, potentially affecting voice quality. To ensure voice packets are appropriately prioritized over competing data packets, QoS must be provisioned.

One WLAN QoS mechanism occurs at AP level and involves queuing. By maintaining separate queues for different traffic classifications, such as voice, video, best effort and background traffic, the AP can differentiate among traffic types and prioritize them appropriately. In the case of our Cisco WLAN infrastructure used in this review, QoS involves separating voice and data traffic on separate SSIDs and prioritizing them accordingly. In this manner, packets in the voice queue will be transmitted ahead of packets contained in the data queue, but this mechanism maintains voice quality in the downstream direction only.

Upstream QoS involves over-the-air mechanisms to ensure voice clients gain access to the medium before competing data clients. Because the 802.11 standard relies on CSMA/CA, WLAN clients must first listen to see if the medium is free, then pick a random back-off time to avoid collisions. Before transmitting, each client counts down from its selected back-off time until it reaches zero, at which point it can transmit if the channel is clear. Because all WLAN clients--except the SpectraLink devices--select random back-off times from the range defined by the standard, each has an equal probability of gaining access to the medium.In its proprietary form of QoS, called SVP and explained in more depth in "Voice Over Wireless: Past the Hurdles," SpectraLink lowers the maximum back-off of its handsets to zero, thereby decreasing the amount of time they wait to transmit. Although this method of QoS lets SpectraLink's handsets gain access to the medium first, it may also increase the likelihood of collisions among the devices because each backs off at the same rate.

WMM (Wireless Multimedia), a subset of the 802.11e standard, offers far more granular QoS mechanisms. Four different access categories are defined in the form of best effort, background, video and voice, each with different maximum back-off times. The voice-access category has the lowest maximum back-off time, giving it the highest statistical probability of gaining access to the medium first. In addition, WMM can be implemented on APs, providing the same back-off-based, over-the-air QoS mechanisms in the downstream and upstream directions.

As for pricing, we asked the vendors to quote numbers for both 100- and 500-handset deployments, including software, licenses, a three-year maintenance contract and required hardware except the PBX--such as a back-end gateway. Hitachi blew away the competition on price, coming in at less than half the next lowest quote on a 100-unit scenario thanks to the fact that its WIP5000 handsets don't need a back-end server. SpectraLink was the most expensive, both with SIP and SVP support. See "Enterprise Vo-Fi Handset Pricing."

We decided against awarding an Editor's Choice because the Vo-Fi handsets we evaluated are targeted at different markets, and likewise our recommendation is dependent on your needs.

Hitachi Cable's handset is ideal for companies that have made investments in SIP PBXs and are looking to complement their desktop VoIP phones with wireless. SpectraLink's durable and utilitarian handset design lends itself to industrial and manufacturing environments, where conditions are treacherous. In addition, SpectraLink's wide array of analog and digital connectivity options are perfect for extending a legacy PBX system into the wireless world. Vocera's badge communication system is most applicable to hospital and retail environments, where the hands-free voice-activated user interface lets workers remain mobile and productive, yet still accessible.Hitachi Cable Wireless IP5000

Unlike its competitors, Hitachi Cable's Vo-Fi handset doesn't require back-end gateways or telephony servers but instead offers direct, standards-based integration into SIP-based IP PBXs. This is especially appealing to organizations with investments in wire-line SIP PBXs and WLAN infrastructures.

Hitachi's handset is ahead of the curve in wireless standards support as well. The integrated 802.11b/g radio allows for denser handset deployments, as voice packets transmitted using 802.11g consume less airtime than the slower 802.11b standard. Security support is impressive as well, ranging from WEP and WPA-PSK to 802.1X mechanisms, including EAP-MD5, EAP-TLS, EAP-TTLS and EAP-PEAP. Standards-based QoS is also included in the form of WMM, which prioritizes voice packets over data traffic. The WIP5000 maintained excellent voice quality throughout our test scenarios. It buckled only in the downstream direction when QoS was disabled, but this proved a challenging scenario for all the devices.

The WIP5000 handset has a rounded, surf-board-like shape that's sleek yet professional-looking. The handset is well-built, though it's decidedly less rugged than SpectraLink's offering, which may prohibit deployments in industrial environments. Using its large LCD screen, two soft keys and a four-way thumb navigation stick, we easily traversed through the handset's intuitive interface.

Features include a 200-entry phone book that's searchable by name or number and supports PC-based backup over a USB interface. Many organizations will appreciate the presence functionality, which maintains a list of user-defined "buddies" and displays pop-up notifications when their handset's status is updated. Two-way text messaging is also supported through the SIP message command, not SMS. A majority of these features rely on integration within the PBX, so it's important to assess your PBX's SIP capabilities before buying.We could configure the WIP5000 using in-phone menus or the expansive administrator's Web interface built into each device. Both options are well-designed, particularly the five separate wireless configuration profiles, useful for handsets that travel to locations with different WLAN parameters. Administrators will find the TFTP-based configuration upgrade functionality particularly helpful for distributing common configuration settings without having to program each handset individually. Software updates are TFTP-based and initiated through the phone or Web interface. For mass upgrades of a multitude of handsets, Hitachi offers the WirelessIP Manager, a centralized Web administration interface installed on a Linux server. After importing a CSV file containing each handset's MAC address, we could remotely push software updates on an immediate or scheduled basis.

SpectraLink NetLink Wireless Telephones

From the ground up, the SpectraLink NetLink Wireless Telephone system is designed to integrate with a company's existing PBX. The NetLink supports circuit-switched PBXs, through the NetLink Telephony Gateway, or direct communication between handsets and an IP Telephony PBX (see "SpectraLink Setups").

In the circuit-switched case, the NetLink system interfaces over analog or digital wire-line links, letting even legacy PBX systems support wireless. A variety of IP PBX vendors, including Alcatel, Avaya, Inter-Tel and NEC, resell SpectraLink's handsets and produce specialized code releases tailored to each system's protocols and feature sets. The telephony gateway can perform both gateway and SVP functions in small installations--fewer than four telephony gateways or 64 handsets--otherwise a separate SVP server must be used.

We tested a digital version of the NetLink Telephony Gateway sporting a T1 interface, which we interconnected to our lab's Asterisk PBX. Through this interconnection we easily routed calls from handset to handset, handset to PBX and vice versa. We were also able to leverage Asterisk's built-in conference room and voicemail functionality, only two of a variety of built-in PBX functions that can be used on the NetLink handsets.SpectraLink sent us a beta version of its SIP code-base, letting us assess its IP Telephony Integration option. After a few configuration troubles, we were able to link the NetLink handsets directly to our Asterisk PBX. Although we didn't put this version through our gauntlet of voice-quality and roaming tests because of its beta status, we're pleased to see SpectraLink moving forward and offering standards-based telephony integration to complement its existing support for a variety of proprietary protocols. Note that Cisco will not license SCCP (Skinny) for the NetLink 8000 line, so all future work with Cisco's Call Manager will be SIP-based.

Regardless of which PBX integration option you select, SpectraLink requires that the appropriate number of SVP servers be installed on the network--a ratio of one server per 80 calls for an IP system, 120 calls for a telephony system.

The SVP servers order, time and tag voice packets using SpectraLink's proprietary SVP protocol. In addition, the SVP servers provide call-admission control to limit the number of handsets associated with any single AP, thus preventing data clients from being bandwidth starved by SpectraLink's zero-back-off QoS mechanism.

We found the voice quality of the SpectraLink system consistently high in all scenarios, except when QoS mechanisms were disabled. In the future we expect that the SVP server will be phased out as infrastructure vendors implement QoS and call-admission control features included in the 802.11e standard. Although SpectraLink claims to offer standards-based QoS through WMM, multiple SpectraLink VIEW (Voice Interoperability for Enterprise Wireless)-certified deployment guides--including those for Cisco, Trapeze and 3Com infrastructures--explicitly state that WMM must be disabled for SVP to function, certainly painting a conflicting picture of WMM support.

NetLink Telephony and SVP server configuration are handled through text-based administration menus, accessible over telnet or serial interface. Although we navigated these ASCII menus easily enough, we found this type of configuration a bit archaic and cumbersome compared with competitors' Web consoles. In addition, each gateway and server must be managed and monitored individually, causing unnecessary overhead. Although basic remote SNMP monitoring is supported, the inclusion of a centralized configuration and alert aggregation interface would be helpful for large installations.SpectraLink offers three NetLink handsets: The enterprise-oriented e340; the health-care-focused h340; and the rugged i640, which is designed for industrial applications. All handsets provide a four-line alphanumeric LCD display with status indicators along the top and four soft-key commands along the bottom. Each handset supports WEP, WPA-PSK, WPA2-PSK and Cisco's CCKM (Cisco Centralized Key Management) with LEAP-based authentication security. We tested the e340 and i640 and found both well-designed, with a durable feel that bodes well for their intended usage.

The i640 is set apart by its larger footprint, increased durability and integrated PTT (Push-to-Talk) capabilities. True to its industrial design, the i640 is drop-tested up to 24 feet onto a ceramic surface. Through the use of the eight-channel PTT feature, users can broadcast messages in a walkie-talkie fashion, useful for situations where information must be communicated quickly to many parties. Administrators should note that IP multicasting must be enabled for PTT functionality, and standby battery life will be reduced to roughly 30 hours as each broadcast message requires radio power-on.

Configuration of the handsets is achieved through local administration menus on each phone or the NetLink configuration cradle, which links to a PC over a serial port. We found entering SSID and security information using the phone's alphanumeric keypad cumbersome, so we'd recommend the cradle method. The NetLink configuration-cradle software is intuitive, albeit a little rough around the edges. Admins can easily provision a multitude of handsets through the use of system-, group- and user-level profiles, which allow generally static settings, such as WEP keys, to be archived and reused. In addition, each handset checks the administrator-defined TFTP server for new software on boot-up, making firmware upgrades nearly automatic. That's an important management consideration for any reasonably sized deployment.

In addition to voice services, SpectraLink's OAI (Open Application Interface) Gateway lets third-party applications send and receive text messages from NetLink handsets. Although we tested only basic text messaging, SpectraLink's Certified Messaging Application lets external apps, such as e-mail or nurse-call systems, extend this functionality; something that would certainly be valuable in vertical applications such as health care.

We also had a look at a beta version of SpectraLink's NetLink 8030 series handset, which offers a larger LCD screen than its predecessors as well as updated styling and new features. In contrast to the 802.11b-only wireless interface found in many other Vo-Fi handsets, the 8030 series includes a dual-band 802.11a/b/g radio, allowing for even denser deployments. Battery life may also be increased via extended or ultra-extended batteries, with possible talk times of six and eight hours, respectively. A 20-entry phone book with speed dial makes frequently dialed numbers easily accessible, and an integrated speaker phone can be enabled or disabled by administrators, useful for varying deployment scenarios.The configuration method is updated to support USB instead of SpectraLink's previous serial-port-based configuration cradle. In addition, 24 regular plus one emergency-override PTT channels are included, permitting one-to-many broadcasts. We anticipate the new handset will be a welcome addition to the NetLink family; it should be available by the time you read this.

Vocera Communications System

The Vocera Communications System uses Vo-Fi technology in a way completely unique among our competitors. By using small, lightweight speaker-phone badges and voice recognition, Vocera allows hands-free communication through simple voice commands. This will be particularly useful in vertical markets, such as retail and hospital environments.

The Vocera Communications System consists of a back-end Vocera server responsible for badge-to-badge communications and speech-recognition software licensed from Nuance Communications. For PBX or PSTN access, the Vocera Telephony Server supports digital or analog interface cards from Dialogic and can be installed on the same hardware as the back-end server. Each Vocera badge supports wireless security via WEP, WPA-PSK and 802.1X mechanisms, including EAP-LEAP and EAP-PEAP.

We found the speech recognition portion of the Vocera system effective and intuitive. By issuing commands in natural spoken language, for example, "Call John Doe," badge users can perform a multitude of tasks, including placing calls, creating group conferences and listening to voicemail. There were times we found ourselves repeating certain commands, so if we were going to use the systems long term we'd take advantage of the option to train the speech-recognition engine.Over-the-air QoS support is conspicuously lacking in the Vocera badges. Despite this, both our subjective and objective results found the Vocera system maintained consistent voice quality, except, again, when QoS mechanisms were disabled. Even though only downstream QoS was provided by our Cisco infrastructure, through AP-level queuing, we found voice quality consistently above toll-quality levels in both directions. This was especially surprising to us in the upstream direction, as both the Vocera badge and data clients contend following the same 802.11 standard rules. The company told us that it does not set the backoff to zero, a la SpectraLink.

Configuration of the Vocera system is managed through a well-designed Web interface that includes system-wide, telephony server, speech recognition and user profile options. The hierarchical organization of user settings is first rate: We organized users into groups and groups into departments, each with specialized speech-recognition commands. One interesting feature is the location functionality, which lets admins track badge users down to the APs with which they're associated--provided you've assigned "friendly" location names to each AP's MAC address. Call-forwarding options are extensive, letting badge users route their calls to other badge users, groups, internal extensions or external numbers.

Note that a widespread deployment of Vocera badges may require specialized WLAN coverage. Compared with typical Vo-Fi handsets, which are used much like cell phones, the Vocera badge is worn at chest height against the body, so a person's orientation toward or away from an AP can mean the difference between an adequate or weak signal, as the human body attenuates RF waves.

To assess the Vocera system on a larger scale, we spoke with the University Hospital at Upstate Medical University, here in Syracuse. A hospital representative said the facility has used the Vocera system since late 2003 and has found it essential for employee communications. Specifically, using Vocera has improved staff accessibility and reduced overall noise, as the overhead paging system is used less frequently. With a deployment size of 1,100 badges--though not all used concurrently because of employee shifts--University Hospital's installation attests to the system's scalability. Note that Vocera recently released version 4.0, which supports as many as 4,200 simultaneous users, up from the previous 1,800.

How We Tested Vo-Fi Handsets

In all our testing scenarios we used our Cisco WLAN infrastructure, consisting of a Cisco 4402 WLAN controller running release 3.2.171-6 and communicating over LWAPP (Lightweight Access Point Protocol) to dual-band Cisco 1240AG APs. We selected Cisco gear for our test bed because the company is the market leader for enterprise WLAN infrastructure equipment.To interconnect our APs, servers and telephony gateways we used a 24-port Cisco 3750G switch with integrated power-over-Ethernet capabilities. All devices were contained in a single Layer 3 subnet. Our Asterisk PBX runs version 1.2.11 and contains a four-port T1 interface card provided by Digium.

To assess the voice quality of each handset, we used Agilent Technologies' Voice Quality Tester, which sent pre-recorded human voice through our handsets and assigned an MOS (mean opinion score) to the received signal using the PESQ (Perceptual Evaluation of Speech Quality) algorithm, based on the ITU-T P.862 standard. Although results were repeatable, we found that Agilent's tool returned slightly low scores for all the products.

We also ran the voice tester on Syracuse University's Verizon Centrex service and received a score of 3.3. Using this measurement as a control, we concluded that though our results were skewed, they were skewed consistently, with values 3.0 and above representing PSTN quality. In addition, necessary volume and gain adjustments on the Agilent tool introduced variables that limit explicit comparisons among vendors.

Inside an RF-shielded chamber, we connected the handset under test to our Agilent VQT with a 2.5-mm headset jack and placed it into a call with a SIP-based Polycom IP500 connected over Ethernet to our Asterisk PBX. In scenarios with QoS disabled, each handset was associated to one SSID (Service Set ID) configured to use the Silver (Best Effort) QoS profile, and WMM (Wi-Fi Multimedia) was disabled.

In scenarios where QoS was enabled, we associated each handset to an SSID with QoS profile Platinum (Voice), which provided AP-level priority queuing for voice packets. WMM support remained disabled, except when we tested Hitachi Cable's handsets (they support WMM). In all cases, background data traffic was associated to a separate SSID with QoS profile Silver (Best Effort).We generated background traffic using Ixia's Chariot 5.0 with the TCP-based throughput.scr script repeatedly sending a 100-KB file for the duration of our testing. Background data clients consisted of three laptops--two Dell D610s and one Hewlett-Packard nc6220--each with a Cisco CB21AG WLAN card running driver version 3.0.0.104, with one downstream and one upstream Chariot traffic flow per laptop.

We measured the roaming performance of Vo-Fi handsets using Azimuth Systems' Phone Roaming script. In our test setup, two Cisco 1240AG APs, one on Channel 1 and the other on Channel 11, were placed in isolation chambers and connected with RF cables to the Azimuth chassis. We placed the Vo-Fi phone under test in a separate isolation chamber, interconnected using a near-field antenna. Through the use of variable attenuators, the Azimuth system "moved" one AP closer to the Vo-Fi phone while moving the other away by increasing or decreasing path loss. In this manner, we simulated a "smooth roam," indicative of a real-world situation.

We performed 10 successive iterations of each roaming test, with 100 seconds of delay between each. Throughout the process, WildPackets' AiroPeek analyzers listened on each AP's channel and monitored how long the roam took, in milliseconds, measured from last data packet before the roam to first data packet after the roam.

For unsecure roams we configured our infrastructure with open authentication and encryption disabled. For secure roams we used WPA-PSK (TKIP-based) encryption, which involves only AP-to-handset interaction and eliminates the 802.1X backend infrastructure concerns that can add to roaming times.

All NETWORK COMPUTING product reviews are conducted by current or former IT professionals in our Real-World Labs® or partner labs, according to our own test criteria. Vendor involvement is limited to assistance in configuration and troubleshooting. NETWORK COMPUTING schedules reviews based solely on our editorial judgment of reader needs, and we conduct tests and publish results without vendor influence.

Vo-Fi'S Holy Grail: Fixed/Mobile ConvergenceFixed/mobile convergence, or FMC, may be the springboard that will propel Vo-Fi into the mainstream for businesses large and small. Let's face it: Although current Vo-Fi solutions have footholds in verticals, including health care, manufacturing and retail, the technology's appeal has been limited.

FMC involves two main ideas: service extension and call handoff. With service extension, a user's mobile phone is tied to the PBX, often through software. When an incoming call is received for an extension on the PBX, the call is directed to both the user's desk phone and her mobile phone on the cellular network. Users also can place phone calls through the PBX or the mobile handset.

When calls are placed through the PBX, the user places a call as she normally would. The service-extension software on the mobile device communicates to the PBX over a data network, like 1xRTT, GPRS or EDGE, to set up the call--for example, to determine what line the call is coming from and the destination phone number.

Next, the software places an outgoing call to the PBX over the PSTN. In some cases, the software will set up a call, and the PBX will place a voice call to the user's mobile device when a free PSTN line on the PBX is available. Finally, the FMC software connected to the PBX places a separate PSTN call from the PBX to the number the user dialed, then links the mobile handset's call into the PBX with the outgoing call, in much the same way as a conference call might be provisioned between two parties connected to the PBX.

Yes, this architecture requires tying up two PSTN lines on the PBX for every call placed from a mobile handset through service extension, but there are some offsetting advantages. First, by using a service extension and placing calls through the PBX, enterprise IT gains better call-auditing capabilities--especially important in industries where regulatory concerns loom large. IT can also realize cost advantages, particularly for long-distance and international calls, which are less expensive over landline voice or IP networks than over a cellular network.In addition to voice services, service extensions can provide users with access to other PBX functions, including hooks into to the corporate phone directory, presence and instant messaging. Users get a unified voicemail box as well, a benefit for both mobile workers and IT, which gains full control over auditing of voicemail messages.

Many established vendors, including Avaya; Cisco, through its purchase of Orative Systems; and Research in Motion, through its purchase of Ascendent Systems, can play a part in tying an enterprise PBX to users' mobile handsets. Not all vendors offer all the features presented here, so think carefully about which capabilities are important to you before going shopping.

We examined FirstHand Technologies' Enterprise Mobility Gateway to get a feeling for what FMC has to offer. FirstHand provides OEM services to BroadSoft, Nortel Networks and 3Com, and plans to develop service extension capabilities for other PBX providers, including open-source vendors such as Asterisk, over the next year. We tested Enterprise Mobility Gateway against a 3Com PBX using a BlackBerry 8700c as a client device. In addition to the BlackBerry platform, FirstHand can extend PBX services to Windows Mobile and Symbian clients.

Overall, we were impressed. During our tests, we could receive calls simultaneously on our desk handsets and our mobile devices and could dial other PBX users by extension or by looking up contact information from a corporate LDAP directory. In addition, we could see a user's presence and conduct IM chats--the benefits of extending the PBX feature set to mobile devices are clear.

Over the coming year, we expect FirstHand, along with other vendors, to tackle the flip side of FMC, call handoff. When combined with a growing number of Wi-Fi-enabled business-class phones, like the Nokia E61 and HTC Excalibur (known commonly as the T-Mobile Dash), call handoff lets calls be seamlessly routed from a cellular network to a Wi-Fi network and back. Placing calls on the enterprise Wi-Fi network allows for both better in-building mobile coverage and cost savings as calls bypass the mobile carrier's network.We're also looking for mobile carriers to come up with plays of their own in enterprise FMC. In December, Sprint and Avaya announced hosted PBX extension services for Avaya PBXs. T-Mobile announced call handoff based on UMA (Unlicensed Mobile Access) service last year as well. However, it was targeted at consumers.

Finally, the carriers' shift toward IMS, or IP Multimedia Subsystem, which moves the core of cellular networks from a circuit-switched to a packet-switched model, will further drive FMC initiatives. The MobileIgnite Program, an alliance of service providers, wireless client manufacturers and testing vendors, including Aruba Networks, BridgePort, VeriSign and others, is devoted to developing interoperable best practices to use IMS to bridge cellular and Wi-Fi. At the 3GSM conference in March 2006, BridgePort demonstrated call handoff with two MobileIgnite partner vendors (E28 and PCTEL). In addition, VeriSign has worked with BridgePort to develop a hosted system for carriers looking to deliver FMC services to their customers. --Sean Ginevan

Why Not Go Consumer-grade?

If none of the available enterprise-class Vo-Fi phones excites you, why not just pick up a consumer model? One word: Security. Although the three handsets we examined--from Hitachi Cable, Linksys, and UTStarcom--offer WEP or WPA-PSK security, they lack the 802.1X authentication mechanisms found in more enterprise-focused devices.

These phones more closely mimic the styling of modern cell phones, with features such as full-color LCD displays and, in UTStarcom's case, a flip form factor. A common theme is support for both G.711 and G.729a voice codecs and standards-based SIP signaling, which lets the devices be used with a local SIP-based PBX or a variety of VoIP service providers, including BroadVoice and Vonage.

The Linksys Wireless IP330 has an 802.11b/g wireless interface and a large, color LCD display with a four-way navigation keypad, useful for browsing the well-designed user interface. The IP330 is based on Windows CE and includes Microsoft applications, such as Internet Explorer and Media Player. We found the integrated Web browser particularly useful for authenticating against Wi-Fi hotspots, but typing can be cumbersome on the alphanumeric keypad.The IP330 also lets you view images directly from a Linksys Web cam. Configuration is managed through in-phone menus or the Web interface, which is accessible once the phone has associated to an AP. We found both methods simple and intuitive; in particular, the 10 supported Wi-Fi profiles will be useful for travelers who connect at multiple locations, say, home, work and a T-Mobile hotspot.

One notable point is the lack of STUN (Simple Traversal of UDP through NAT) support, which limits the device's ability to work behind a NAT firewall. Although the Linksys IP330 is a well-rounded phone, its hefty price tag of $369 will induce some sticker shock.

UTStarcom's F3000 Wi-Fi handset offers a stylish clamshell design with an integrated 1.8-inch color display and an 802.11b/g wireless interface. Similar to the IP330, the F3000 supports as many as four Wi-Fi profiles, plus three SIP profiles, useful for those with multiple service-provider accounts.

Other handy features include text messaging and STUN support, which allows for VoIP calls behind the NAT environments often found in the home. Configuration is managed through phone menus or TFTP-based provisioning, useful for service providers. Although configuring the phone was simple, we experienced repeatable handset crashes when attempting to set our SIP settings as "active." Despite a firmware update provided by the vendor, the problem persisted, limiting our evaluation time. Pricing is set at $200, and the F3000 is available from a variety of resellers.

We also evaluated the Hitachi Cable Wireless IP3000 handset. This consumer version of the Wireless IP5000 offers most of the features we liked in its enterprise-oriented big brother, for a lower price.The WIP3000 has a sleek candy-bar shape with a matching white charging cradle. Notable features include an integrated 200-entry phone book, text messaging over SIP and presence support. Configuration is managed through in-phone menus or a Web interface; both are well-designed and easily navigated. In comparison with rival consumer handsets, however, the WIP3000 supports only the slower 802.11b standard and has a gray-scale LCD display, while others sport full-color screens. Despite these limitations, the WIP3000 is an excellent, stable phone with a no-frills design, priced around $270.

Jameson Blandford is the lab director at the Center for Emerging Network Technologies at Syracuse University. Write to him at [email protected].

Frank Bulk is a contributing editor to Network Computing. He works for a telecommunications company based in the Midwest. Write to him at [email protected].