The Digital Tower of Babel

Electronic News, July 9, 2001 by Peter Petersen

WIRELESS HOME NETworks of the future will intermingle a variety of connected devices dependent on a wide variety of protocols. PCs and their peripherals, PDAs, TVs, cordless phones, audio systems and garage door openers will be networked via such diverse standards as 802.11, HiperLAN/2, Bluetooth, HomeRF, digital enhanced cordless telecommunications (DECT) and IrDA.

The OEMs currently designing residential gateways and other systems for these networks must realize that this emerging Babel includes protocols for both voice and data communications, the different characteristics and requirements of which can clash. Voice protocols such as DECT will serve cordless and cell phones as well as audio systems, while Bluetooth and HomeRF transmit data among PCs and peripherals, and 802.11-based LANs serving higher-speed data. The incompatibilities become self-evident.

Data networks, for example, are typified by variable bandwidths. But voice and audio networks need a fixed bandwidth. That's one difference; another is that data can be retransmitted, so bit-errors are acceptable as long as the overall transmission is error-free. But since voice and audio can't be re-transmitted, bit-errors irreparably degrade the whole transmission. Voice and audio can either be point-to-point or many-pronged, and they can travel a long, long way.

None of these variations is easy to reconcile. Add to this difficulty the fact that, in home networks, combining data protocols with voice and audio protocols results in a third set of specs. Multiple protocols must exist to transmit multiple data types, with the correct bit error-rate requirements for all data types, as well as data recovery techniques. The hybrid network also has to support point-to-point and multipoint communications. Finally, it has to cover short- and long-range transmission. Yet daunting incompatibilities exist just between point-to-point and multipoint networks. Like an off-the-lot four-on-the-floor that might not be able to handle the shift changes without blowing the clutch, a home network can be overwhelmed with protocol requirements. For a multipoint network juggling voice and data simultaneously, the minimum requirements are multiple programmable basebands, flexible memory allocation, pre- and post-data processing and the ability to unclog real-time bottlenecks. And unfortunately for home networks, cost also looms large.

OEMs need an inexpensive silicon solution that handles multiple wireless protocols, doesn't strain the host CPU and uses an operating system that supports multiprotocol stack execution, fast context switching, messaging schemes such as USB and TCP/IP and hardware-supported state machines. It should also include an API infrastructure to control and negotiate application-specific services.

This silicon implementation has to operate readily in gateways, such asset-top boxes and cordless phone base stations, as well as the whole gamut of networked consumer systems and appliances. Not easily said, even less easily done. Most existing silicon in home networks reserves its co-processor DSP for voice and compression algorithms so that the existing host CPU can handle applications and systems functions. Moving from this situation into multiprotocol processing presents some daunting challenges. Multiprotocol processing could be handled entirely in software, using different protocol stacks, but the switches from one protocol to another are both slow and prickly.

One hardware-oriented solution could involve several RF transceivers, each dedicated to a specific protocol But the cost for this, in consumer applications, is prohibitive. In addition, the OEM would have to add analog silicon for voice, memory, messaging schemes, an operating system and an Internet browser. However, for performance and cost reasons, all the necessary silicon should be included on the host CPU. New techniques must be developed to integrate embedded DSP, multiple embedded programmable basebands, embedded peripherals such as USB and Ethernet controllers, an embedded operating system and integrated APIs and application software. Such a technology could include either on-chip RF or merely feature interfaces for RF chips from different vendors.

These challenges are not easy, but they are unlikely to remain unresolved. Just as the refugees from the Tower of Babel struggled patiently to discern each other's mysterious tongues, chipmakers will find common cause with OEMs and, together, they will implement voice and data communications on multiple protocols, on the same multi-point network.

Peter Petersen is the vice president of system engineering at Embedded Wireless Devices Inc., based in Pleasanton, Calif.