Rollout: DiVitas Networks Mobile Convergence Appliance and Client

DiVitas' mobile-to-mobile convergence solution is hamstrung by handset issues, short battery life and cellular data service that's not pervasively 3G. In short, it's not enterprise ready.

April 25, 2007

7 Min Read
NetworkComputing logo in a gray background | NetworkComputing

Your employees are walking telephony hubs, with desk phones, cell phones and even softphones. But they've also got multiple phone numbers and voicemail systems, and colleagues and customers may be playing phone tag instead of doing business.

One attractive solution is mobile-to-mobile convergence (MMC), in which dual-mode phones integrate Wi-Fi and cellular services to give companies inexpensive, truly mobile voice. DiVitas Networks' MCA (Mobile Convergence Appliance) and MCC (Mobile Convergence Client) are the first products to attempt vendor-agnostic, single-number access and seamless mobility between cellular and Wi-Fi networks using a single handset.

Unfortunately, DiVitas is constrained by the third-party products, technologies and interfaces sold by vendors that may not want to see DiVitas succeed. The first release suffers from limitations in the handsets' APIs and shortened battery life. Plus, seamless roaming is only possible in those areas with advanced 3G services. It also doesn't integrate with enterprise directories.

Complex EcosystemThe environment for a complete MMC solution requires multiple pieces working together: the handset, a Wi-Fi access point, a wireless carrier and the PBX.

DiVitas recognized that the only way enterprises would adopt MMC en masse would be to work with the existing infrastructure and provide handset choice. So rather than dictate platforms to the customer, the solution only requires the purchase of DiVitas' MCA, a 1U rack-mountable device, and MCC. The MCA connects to the corporate PBX over a SIP trunk (a relatively new enterprise telephony interface), while the MCC loads onto several supported dual-mode handsets. DiVitas doesn't care what WLAN is deployed.

Our Wi-Fi infrastructure consisted of a Cisco 4402 Wireless LAN Controller with a 1130 AP. We used our lab's Asterisk PBX, which is tied to three POTS lines, and created a SIP trunk to DiVitas' MCA (also based on Asterisk). We assembled four dual-mode handsets: the HP iPAQ hw6940, HTC TyTn, Symbol MC70 and a Palm handset.

The first three handsets are GSM-based with service from AT&T, though with the DiVitas solution, they should work just as well with T-Mobile. The Palm uses CDMA with Verizon Wireless (though Sprint would also be OK). All these devices run Windows Mobile 5.0. True to its vendor-agnostic approach, DiVitas has a beta of Nokia's Symbian OS 9.1 E61 handsets in progress, and two Linux devices from G-Tek Electronics are on the road map.

When it comes to the software, the DiVitas solution lacks integration with existing directory stores, and installation was more complex than it should be. The MCC software can be installed on dual-mode phones using the Web or ActiveSync. Access requires entering the MCA's IP address and the appropriate user name and password, defined manually by the admin in the MCA. For now, there is no LDAP, RADIUS or Active Directory integration, but the company says such integration is in the works.We also had to hunt for the phone's serial number/ name (it's hidden on every device, and sometimes the hex rather than decimal version must be used) and enter it on the MCA along with the device type and group name. For large deployments, this process is cumbersome--DiVitas is considering some kind of autoregistration.

Finally, because Windows Mobile does not offer the equivalent of a Windows Startup folder, there is no mechanism to load the MCC upon device power on, which means users must remember to load the client and log in with their extension and password after every soft reset and battery outage.

When In Roam

After getting the phones configured, basic calls and roaming were the next tests. Vo-Fi calls between phones worked consistently, and the voice quality was far better than with most cellular calls.

If both cellular and Wi-Fi service are available, DiVitas will default to using Wi-Fi. If the MCC determines that the Wi-Fi voice quality has weakened significantly, it initiates a roam to the cellular network. The TyTn handset had a particularly poor Wi-Fi radio and would hand off after one flight of stairs. We were able to walk half a block away with the MC70.Our roam times from Wi-Fi to cellular were much longer than the seven to 10 seconds DiVitas promised. We had roam times as short as 45 seconds, but in some instances we were subjected to more than two minutes of hold music. However, this was partly because our PBX interfaced to Syracuse University's Centrex lines, which had an abnormally long 20- to 30-second post-dial delay for long distance.

We experienced varied success in roaming from cellular back to Wi-Fi. The TyTn was the worst offender, but all the handsets failed at least once. Unfortunately, the underpinnings of the roaming algorithm were not available to us, and DiVitas was unable to provide satisfactory explanations for every failure.

Time SaverClick to enlarge in another window

Feature Set

DiVitas offers a few PBX features, including call transfer, hold and abbreviated dialing (that is, just dialing an extension). They all performed well, though transfer and hold only work in Wi-Fi mode. The software also supports basic presence and secure IM between clients. When we lacked data connectivity, any IMs we sent disappeared and we were not notified that they had been lost. DiVitas plans on addressing this in a future release.We were pleased to see that if the MCA is used as the voicemail platform, any recorded messages can be manipulated from the client rather than dialing a special access number.

However, while most cellular phones have a standby time measured in days, our demonstration units did not last the whole day and we ended up leaving them plugged in for our tests. Much work must be done by handset manufacturers to optimize the Wi-Fi radios' power consumption in all dual-mode handsets.

One frustrating problem was roaming failure due to the type of cellular data service available. When the handset cannot establish a connection to the MCA over Wi-Fi, it reverts to using the CDC (cellular data connection), which could be GPRS, EDGE, UMTS or HSDPA for the GSM phones and CDMA-1xRTT, EV-DO Rev. 0 or EV-DO Rev. A for CDMA phones. But depending on the area's type of data service, there may be limitations to operating voice and CDC simultaneously. When using a CDMA phone in a 1xRTT-only service area, for example, the active CDC prevented incoming cellular voice calls to the handset. This means roams from Wi-Fi to cellular did not succeed. A similar problems exists with GPRS and EDGE service. In our Syracuse lab, we had EV-DO Rev. 0 service, and roaming worked reasonably well.

Final Call

On the pricing front, DiVitas is competitive: It provided low-volume pricing of $550 per user--the same as the price of a nice desk phone. But beyond cost, the fact is, DiVitas' greatest strength--a vendor-agnostic solution--is also its greatest weakness.Our advice: Feel free to try out the solution, but hold off on a full implementation until issues such as the handset API quirks, roaming and integration with enterprise directory stores are resolved.

Frank Bulk is an NWC ontributing technology editor and works for a midwest-based telecommunications company. Write to him at [email protected].

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights