Internet Protocol (IP) switching has become remarkably popular in the last few years, due largely to reduced costs and the integration of voice and data. The Internet switching model can cost two orders of magnitude less than conventional circuit-switched architectures, making the economics of an IP-based network very attractive.
A telecom circuit switch costs around $5 million to $20 million, whereas packet-switch routers with the same bandwidth cost about $1 million or less. Additionally, the ease of integration of packet-switched IP-based systems is attractive for developing and installing new services, compared to a circuit-switched model in which a wide variety of open and proprietary interfaces may be needed to implement even a single service. Finally, for the service operator supporting both voice and data, a single IP network can be simpler to maintain and provision than a hybrid network of circuit and packet lines.
Today, wireless networks are almost completely circuit-switched and voice-oriented. Yet, in Japan, the Wireless Application Protocol (WAP) and iMode are receiving phenomenal acceptance in the marketplace. WAP is also taking off in Europe, and is making inroads in the United States. Consequently, in the last few years there has been a strong push toward wireless IP architectures, paralleling the trend in wired networks.
To address this trend, during the last year the two worldwide wireless standards organizations-Third Generation Partnership Project (3GPP) and Third Generation Partnership Project #2 (3GPP2)-have initiated programs to create an IP-based architecture for their core networks to support both voice and data on a single architecture.
Data is inherently Internet Protocol-based. To date, however, voice-over-IP (VoIP) has not been used in the wireless domain. Currently, participants from all areas of the industry are actively pursuing ways of transporting VoIP in the wireless arena and are trying to define and resolve the key issues surrounding wireless VoIP.
Among the major issues facing wireless-system designers is the fact that there are a large variety of VoIP protocols and related algorithms. In a system, some level of support is needed for all of these algorithms, to preserve backward compatibility with existing and previous standards. In addition, new voice codecs are continually being developed to increase compression ratios and reduce latencies.
A second issue is the close coupling of existing vocoder technology with the air-interface protocol. The air-interface protocol and the vocoder in a CDMA, TDMA, GSM or wideband CDMA (W-CDMA) handset have been optimized together for maximum efficiency.
A third issue designers face is packet loss, a phenomenon common in all packet-switching networks, including IP networks. Unlike public switched telephone network circuit-switched networking, no end-to-end physical circuits are established in IP networks. IP packets from many sources are queued for transmission over an outgoing link in a router. Packets are transmitted one-by-one from the head of the queue. If there is no space in the queue, an arriving packet is lost in the network. As traffic grows, routers often become congested, resulting in packet loss.
Packet loss can cause severe damage to voice quality for IP telephony. Each IP packet contains 20 ms to 80 ms of speech data, matching the duration of critical units of meaning, which in speech are called phonemes. When a packet is lost, a phoneme of continuous speech is lost. While the human brain is capable of reconstructing a few lost phonemes in speech, the loss of too many packets creates unintelligible messages.
Beyond these initial barriers, system designers are confronted with the use of conventional microprocessor, DSP and ASIC technologies, which have processing power limitations, given the computationally intensive demands of VoIP. Computational requirements for VoIP algorithms range from 8 Mips to 35 Mips. Adaptive computing machine (ACM) circuitry is an emerging class of IC technology that gives designers higher performance and lower power to resolve these VoIP processing limitations.
The ACM is specialized computing circuitry consisting of adaptive function blocks married to programmable interconnections, all of which can be changed in real-time. In short, it allows software to create hardware on demand, providing a solution with the flexibility of software and the performance
of hardware. Consequently, an ACM architecture is significantly more efficient than a rigid and inflexible DSP- or ASIC-based VoIP implementation.
Resources on an ACM chip can be allocated in parallel to the limit of availability, since these resources aren't dedicated to particular functions as they normally would be in a microprocessor, DSP, or ASIC. This allows an ACM-based device to act as a parallel processing machine, as opposed to the single-threaded and/or limited parallelism in a typical microprocessor or DSP. While a large fraction of a microprocessor's or DSP's fixed resources may sit idle at any particular moment, most of the time they are idle while awaiting an assignment for which they are suited. Also, DSPs generally operate on fixed data sizes that are typically multiples of a byte. However, the dynamic or adaptive logic of an ACM operates on any data width, and the width can vary with time to suit the needs of a VoIP design problem.
The necessary logic for each portion of VoIP algorithm is thus optimally implemented on the adaptive silicon at any given point in time. As a result, the need for DSPs, ASICs and microprocessors or microcontrollers is eliminated.
The challenges are whether to carry existing VoIP over the air-interface protocols and rely on existing VoIP vocoders; introduce new vocoders that are better suited to the air interface; or transcode between existing air interface and VoIP vocoders so that these two technologies will operate efficiently together. All of these changes must be made without discarding many of the existing efficiencies of the air-interface protocols.
Any IP-based application carries with it a certain amount of overhead, meaning it contains header information. In a wireless environment, this header information is very significant because it is correlated with a loss of capacity. In a 10- or 100-Mbits/second Ethernet-based system, a 20 percent or 30 percent overhead for header information is insignificant. However, that same amount of overhead is highly unacceptable in a wireless environment and to a wireless carrier, which is expected to include VoIP.
The industry must therefore find a way to efficiently transport or extend VoIP protocols to a terminal. It is not yet clear how best to do this.
The 3GPP2 organization has wrestled with this issue for some time. Part of the discussion involves further design phases as a way to resolve this problem. Also, the group has discussed extensively whether the Internet Protocol stops at the cell site or continues to the mobile station. As far as transferring data, most agree that some compression techniques should be developed to shrink the header overhead. However, the jury is still out on whether this is adequate for voice.
Considering these perplexing and problematic areas, these questions arise: How can the industry design cellular phones that can support VoIP? What VoIP algorithm can handle the highly computationally intensive VoIP codecs? And the system designer must keep in mind that there are two sets of vocoder standards-one set from the wired domain, the other from wireless. Although their function is similar, they are not the same.
Further questions include: How can a VoIP wireless handset be designed to deal with all of these codecs? Should system designers rely on conventional wireless codecs on the air-interface portion, and then reconvert data from these codecs to VoIP codecs at some point over the network? Or, do they use existing VoIP codecs and transport them to mobile stations? Or, will wireless OEMs have to encourage VoIP codec vendors to support wireless codecs in addition to the current VoIP standards?
From the view of a wireless handset OEM, these crucial questions pose significant engineering and profit/loss concerns as the demand for VoIP continues. Presently, there is no single right answer; instead, there are numerous right answers, and this number will only continue to grow. Thus, trying to design a VoIP wireless handset is a major challenge.
The recommendations of the International Telecommunication Union (ITU) for VoIP wire-line voice encoding standards include the 729, 729a, 729e, 728, 726 and 711 standards. A wide variety of vocoders are used in wireless standards. These include Qualcomm's Code-Excited Linear Predictive (QCELP); cdma-One's Enhanced Variable Bit Rate Code (EVRC); and Adaptive Multi-Rate (a suite of codecs). Coming soon is the cdma2000 Selectable Mode Vocoder (SMV), available in early 2001. An engineering analysis shows that each of the VoIP codec algorithms contains four to 12 "hot spots" that consume more than 1 percent of the Mips. Hot spots are a particular grouping of an algorithm's inner code loops or subroutines that consume inordinate power. The total percentage of the Mips consumed by the four to 12 hot spots for each codec algorithm ranges from 90 percent to 99 percent. For example, the VoIP G.729e consumes 35 Mips, and 12 inner code loops of this particular codec algorithm account for 90 percent to 99 percent of the Mips.
The computational intensity required to run each of these codecs or vocoders is increasing significantly with each new version. System engineers must also factor into their third- and fourth-generation designs the fact MPEG-4 for wireless personal videoconferencing and videophones will require another 3.7 billion operations per second. Each new wireline/wireless VoIP vocoder typically doubles or triples its computational requirements over those of the previous generation, due to the increasingly sophisticated techniques employed to achieve better quality and increased compression. Examples of these techniques include active noise suppression, echo cancellation and more sophisticated forms of error recovery.
Against this backdrop of increasing computational requirements, it is prudent for wireless designers to take stock of their processing needs. Ideally, design engineers want to efficiently run a VoIP algorithm's code by performing it in as few clock cycles as possible. Running any of the VoIP algorithms on a conventional DSP or microprocessor incurs a large number of clock cycles, primarily due to instruction fetches and operand read/writes.
For example, an engineering analysis shows that it takes about 1,000 microprocessor clock cycles to perform the addition of 27 floating-point numbers on a traditional processor. On the other hand, a DSP doing the same job can complete the task in about 100 clock cycles. However, ACM technology has the ability to implement in silicon the exact hardware required at any given point in time. Thus, an algorithm that implements the 27-input adder can be downloaded into the ACM chip, and this computation is completed in seven clock cycles-an order of magnitude improvement over DSP. Hence, an ACM can execute any and all VoIP algorithms in their most efficient form and use considerably less clock cycles and computational power in doing so.
An ACM chip adapts its architecture on the fly to perform a variety of VoIP tasks. As an ACM-based wireless system operates, the silicon changes or adapts itself to become the most efficient hardware needed to execute the specific task. It adapts itself repeatedly, changing its architecture hundreds or thousands of times per second as needed by the application. Thus, it can efficiently handle any of the various VoIP algorithms with considerably less computational power than a DSP-based design.
The ACM allows a software algorithm to build its own engine and then embed itself into the most efficient hardware possible. This adaptive chip also has the advantage of being algorithmically programmable. This means it permits a VoIP wireless system to adapt to the task at hand. The optimum hardware that an algorithm requires comes into existence for the minimum time that the algorithm needs to run.