Designing an Embedded Voice Over Packet Network Gateway
The basic concept behind voice over packet
networks is to enable telephones and fax machines to work over traditional data networks, such as IP, ATM, or Frame Relay.
By Eric Bear
The major attraction of voice over packet networks (VoP) is the potentially dramatic cost savings that can be realized through these new, converged voice and data networks. Consumers may pay just pennies per minute for telephone calls, and corporations may benefit from adding voice capabilities to existing private data networks, eliminating the need to
maintain and operate separate voice and data networks. New product announcements occur daily as equipment vendors rush to place voice capabilities in their data products and data network connections in their voice products.
Telecommunication equipment vendors can cost effectively participate in and benefit from this surging new market by embedding VoP-enabling technology within their datacom or telecom equipment. Attention to system details in the design of this technology will ensure a quality product and
foster end user acceptance of this emerging technology.
VoP technology is causing the consolidation of what has historically been two separate industries; the voice industry dominated by PBX/ voice switch manufacturers, such as Nortel, Lucent, and Siemens, and the data industry led by router/data switch manufacturers like Cisco, 3Com, and Bay Networks.
This article provides an overview of system-level design issues critical to the development of embedded VoP gateways. Topics covered include
design-level trade-offs between PC-based and embedded gateways, DSP and microprocessor selection, memory requirements, telephony network interface, packet network interface, codec selection, and echo cancellation, as well as an overview of a typical embedded software architecture for VoP.
Enabling VoP
The basic concept behind VoP is to enable telephones and fax machines to work over traditional data networks such as Frame Relay, IP, or ATM. A gateway is the network component necessary to make the
conversion between the two networks. Gateways are important because they provide a way for users of legacy telephony equipment to achieve the benefits of VoP. Given the massive installed base of legacy telephony equipment, gateways have quickly achieved noted significance to the datacom and telecom equipment manufacturers entering this new market.
Perceived quality of voice service by end users must be comparable to traditional fixed telephony. Consumers are willing to forgive a lack of quality in mobile
phones for the calling freedom they give and occasionally people will put up with a lack of quality on their personal calls if the service is free or, at a minimum, inexpensive. People are less likely to sacrifice quality in business calls outside the intra-office environment.
Additionally, reliability must be high. Users feel inconvenienced when their computers or Internet connections are down, but business comes to a standstill when there is no dial tone.
PC vs. embedded
A market for quick,
low-cost ways to add these capabilities to existing products led to the manufacture of PC-based plug-in cards with telephony interfaces and digital signal processor (DSP) resources. These boards provided the basic VoP functionality, but were unable to produce the quality of voice necessary for the technology to gain immediate acceptance. In a recent test, three PC-based gateway products were pitted against an embedded product. An embedded product is built specifically for the function it provides, with
dedicated hardware, real-time operating systems (RTOS), and a combined hardware/software architecture designed for the application. The embedded product was awarded “Best in Test” by the publication performing the test.
Why is the quality of an embedded solution superior to PC-based solutions? The major reasons are voice quality, system reliability, lower cost, higher density, and scaleability.
PC processors and OSes are designed for multitasking nonreal-time applications. When the processor on
the PC motherboard is used to process packetized voice, OS queuing and protocol stack processing often cause delay and jitter (variation in delays), resulting in severe voice quality problems.
While PC-based platforms are increasing in reliability, especially with the application of redundancy schemes like redundant array of inexpensive disks (RAID), most low cost PC-based gateways do not have the reliability of their embedded counterparts. One of the key reasons for the greater variability is the
hodgepodge of third-party software running concurrently on the PC platform. Just think about how many times in a year a typical PC crashes and compare that to how often a phone has no dial-tone. At the most basic level, this accounts for much of the difference between embedded and PC-based design platforms.
Cost is another compelling reason to design VoP products using an embedded approach.
PC-based platforms have less initial engineering investment in the design and test phase, making their up-front costs
attractive. However, recurring per channel costs are much lower for an embedded solution in larger production volume.
Finally, density and scaleability, two of the most critical issues for manufacturers looking to deploy carrier-class gateways, are best realized using an embedded solution. A PC can typically accommodate up to four T1/E1 interfaces. Today’s carrier class equipment must scale to DS3 (twenty-eight T1s) and above.
To allow packetized voice quality to approach the quality and reliability
of the PSTN, it is essential to have the dedicated hardware and software of an embedded solution. As a real life checkpoint, how many of the Cisco router platforms are built from a PC platform?
Hardware requirements
Whether building a new product or adding packetized voice to an existing product, new hardware will probably be required. A block diagram of the necessary components is shown in
Figure 1.
In most embedded VoP solutions, the processing is split between a
digital signal processor (DSP) and a microprocessor. As is widely known, DSPs have a very specialized architecture and instruction set that make them excellent at repetitive complex-algorithm calculations necessary for voice compression, echo cancellation, fax modems, and other real-time voice and fax applications. Some microprocessors are starting to mimic DSP capabilities as their processing power grows, but are still probably a generation or two from executing multichannel DSP applications. By the same
token, DSPs will also continue to make huge gains in performance, following the principle of Moore’s Law.
Channel density is usually one of the most important considerations in the selection of a DSP. The number of voice and fax channels that can be serviced by a DSP is a function of the processing power of the DSP MIPS available, as well as the memory available to run algorithms.
There are many factors to consider when selecting the appropriate DSP. The first is availability of software to run on the
DSP. Next, a comparison of the physical board space, power requirements, heat dissipation, DSP cost, supporting chip costs, and flexibility for future applications should be considered among the DSPs with the available software. Finally, there are important features such as internal memory available, ability to support external memory, and specialized communication ports. Normally, the availability of software for the DSP will have a strong correlation to the application-specific special features of a DSP.
Another important aspect of the embedded solution is the choice of microprocessor (RISC/CISC) solution. Two major issues are available processing power sized for the application and cost. A secondary issue is the ability to handle integrated functionality at a low cost (i.e., as demonstrated in an Ethernet communications controller).
Most VoP microprocessor software is delivered in source code to allow the developer the flexibility of selecting the microprocessor and using the development environment
of choice, thus simplifying the process of compiling code and linking it to other applications.
|
|
Figure 1
|
Program and data memory are also required in the system for the microprocessor and the DSP. Non-volatile memory is additionally required
for program storage. In
Figure 1,
the microprocessor acts as the master controller responsible for loading the code into the DSP upon startup from Flash, and in some cases dynamically loading code into the DSP during operation. This flexibility can lower the DSP memory requirements in some applications while maintaining DSP flexibility.
In low-density embedded applications, the hardware would commonly interface to the telephony network through an analog interface to an attached phone,
fax, or PBX. The interface would physically look like a standard RJ-11 phone jack.
Digital interfaces can be provided as well. One of the most common is a T1 or E1 interface provided by a chip called a framer. This chip multiplexes 24 channels or 30 channels of voice along with signaling into a single digital stream. The framer chip terminates this stream on the receive side and originates it on the transmit side. The received voice channels need to be fed to the DSP and the signaling to the
microprocessor for VoP gateway processing.
Communicating between hardware
The output of the codec or framer needs to be interfaced to a DSP, typically via a buffered serial port (BSP) or time division multiplexed (TDM) interface. In applications with multiple channels and multiple DSPs it is desirable to have the capability of routing a DS0 to a DSP. This provides the flexibility of running specific applications in specific DSPs or in routing calls around a failed or busy DSP. This routing can be done
with a DS0 switch or time slot interchanger (TSI). Components are commercially available that provide this functionality, but many embedded gateway designers create their own custom FPGA to provide special functions such as clocking or synchronized pulsing of the voice data.
Telephony signaling messages, such as on-hooks and off-hooks, are not understood in the packet network environment, which relies on setup messages to connect and disconnect circuits. The microprocessor monitors the lead changes and
converts them to signaling packets for communication with the remote gateway across the network.
Shared memory is a common approach used to facilitate communication between the DSP and the microprocessor. Many DSP architectures include a host port interface that is merely a block of memory accessible by both processors. Each writes information to the shared memory that is destined to the other processor. The processors are then informed of waiting voice, fax, or data messages either through interrupts or
polling. Polling allows the microprocessor to have very deterministic workloads, while interrupts can minimize the potential for latency and unnecessary work on the part of the processor. Typically, the hardware is designed to support interrupts, which can be enabled or disabled under software control.
Sizing the processor bandwidth
Sizing the required data bandwidth between the two processors is an important part of system design. The bandwidth must be sufficient to handle the worst case or
heaviest traffic flow while minimizing delay, lost packets, and jitter. The worst case situation in voice systems is usually in packetizing uncompressed (64-kbps PCM) voice channels. The bandwidth required is then the maximum information rate plus the packet-header overhead rate multiplied by the number of channels.
The DSP and microprocessor functions can be on the same physical circuit card or on separate cards. In either case, minimizing the delay and potential for lost packets or jitter is a very
important design issue that is central to achieving excellent voice quality in a packet network.
To minimize these possible problems, the network physical interface is often put on the same card as the microprocessor running the network protocol (TCP/IP, Frame Relay, ATM). In some applications, the hardware might be flexible enough to choose from multiple interface types. Many software applications are flexible enough to take advantage of multiple interface types while complying with their varying standards
and formats.
Software requirements
Many people still think a voice compression codec is all the software needed to transmit voice over a packet network. However, the codec is just one part of a very complex, highly integrated software product. Packetizing voice and placing it on data networks requires a core software functionality for voice compression, echo cancellation, tone processing, and jitter removal.
Figure 2
illustrates an embedded software design for a voice over
IP gateway. The software consists of the following major subsystems: DSP, telephony signaling gateway, network interface protocols, network management agent, and system services.
The voice packet software is composed of the following software modules: PCM interface unit, tone generator, line echo canceller, acoustic echo canceller, voice activity detector (VAD), speech dialing, voice codec, packet playout, protocol encapsulation, voice encryption, and DSP control unit.
The PCM interface unit receives
PCM samples from the analog interface and forwards them to the appropriate DSP software module for processing. It also forwards processed PCM samples to the analog interface.
|
|
Figure 2
|
The tone generator generates call progress tones to
the user and generates in-band dual tone multifrequency (DTMF) digits to the network based on key presses relayed from the user interface. For certain voice codecs, the compression algorithm does not permit faithful transmission of DTMF tones. For those algorithms, e.g., G.723.1, the software generates an in-band message to the network that is used by the remote gateway to regenerate the DTMF tone.
The line echo canceller unit performs ITU G.168 compliant echo cancellation on sampled, full-duplex voice
port signals. Echo in a telephone network is caused by signal reflections generated by the hybrid circuit that converts between a 4-wire circuit (a separate transmit and receive pair) and a 2-wire circuit (a single transmit and receive pair). These reflections of the speaker’s voice are heard in the speaker’s ear. Echo is present even in a conventional circuit-switched telephone network. However, it is acceptable because the round-trip delays through the network are less than 50 ms and the echo
is masked by the normal side tone every telephone generates. Echo becomes a problem in voice over packet networks because the round-trip delay through the network is almost always greater than 50 ms. Thus, echo cancellation techniques are required. G.168 defines performance requirements for echo cancellers. Echo is cancelled toward the packet network from the telephone network. The echo canceller compares the voice data received from the packet network with voice data being transmitted to the packet network.
The echo from the telephone network hybrid is removed by a digital filter on the transmit path into the packet network.
The VAD detects voice activity and activates or deactivates the transmission of packets in order to optimize bandwidth. When activity is not detected, the encoder output will not be transported across the network. This software also measures idle noise characteristics of the interface and reports this information to the packet voice protocol for periodic forwarding to the gateway. Idle
noise is reproduced by the remote end when there is no voice activity so that the remote user will not feel that the line went “dead.”
The optional speech dialing unit provides digit recognition for hands-free dialing.
The voice codec unit performs packetization of the 64-kbps data stream received from the user. Various compression algorithms exist, which have different performance characteristics: G.711 PCM, which operates at 64 kbps (no compression), G.726 ADPCM, which operates at 16
kbps, 24 kbps, 32 kbps, and 40 kbps, G.723.1, which operates at 5.3 kbps or 6.3 kbps, and G.729, which operates at 8 kbps. Typically, voice algorithms that perform greater compression require much more processing power.
The packet playout unit performs compensation for network delay, network jitter, and dropped packets. Many proprietary techniques are used to address these problems since there are currently no standards in place for packet playout.
Packet protocol encapsulation performs encapsulation of
the packet voice data destined for the network interface. For VoP this encapsulation is per the real-time transport protocol (RTP), which runs directly on top of UDP.
Voice encryption provides optional encryption of the voice packet data prior to transmission over the network to ensure privacy.
Finally, the DSP control unit coordinates the exchange of monitor and control information between the DSP and MCU. The information exchanged includes software downline load, configuration data, and status
reporting.
The telephony signaling gateway (TSG) subsystem performs the functions for establishing, maintaining, and terminating a call. The TSG consists of the following software modules:
-
Call processing
performs the state machine processing for call establishment, call maintenance, and call tear down.
-
Address translation and parsing
performs digit collection and parsing to determine when a complete number has been dialed and makes this dialed number available for address
translation.
-
H.323
is an ITU standard that describes how multimedia communications occur between user terminals, network equipment, and assorted services on local and wide area IP networks.
The following H.323 standards are used for VOP:
-
H.225
call signaling protocols perform signaling for establishment and termination of call connections based on Q.931.
-
H.245
is a control protocol that provides capability negotiation between the two end-points
such as voice compression algorithm to use, conferencing requests, etc.
-
Registration, admission, and status (RAS)
is a protocol used to convey the registration, admissions, bandwidth change, and status messages between IP telephone devices and servers called gatekeepers, which provide address translation and access control to devices.
-
Real-time transport control protocol (RTCP)
provides statistical information for monitoring the quality of service of the voice call.
The network management subsystem supports remote management by a network management system. The network management agent performs the network management functions, including status monitoring and alarm reporting, gathering of statistics in response to SNMP queries, etc. from a network management system.
An optional embedded web server provides administrative support via a standard web browser, presents the user with web pages for configuration and for gathering statistical information, and may provide
java applets for loading to the user’s PC, e.g., for status polling.
The next module performs the simple network management protocol (SNMP) functions for processing management information base (MIB) data and sets the generation of alarm traps, and trivial file transport protocol (TFTP) is used to download software updates into Flash memory.
The network interface protocols support communications over the LAN, and consist of the following software modules:
-
The transport control protocol
(TCP)
provides reliable transport of data including retransmission and flow control. It is used for web queries, and call signaling functions.
-
The user datagram protocol (UDP)
provides efficient but unreliable (nonguaranteed) transport of data. It is used for the transport of real-time voice data since retransmission of real-time data would add too much delay to the voice conversation and be unacceptable. UDP is also used for SNMP and TFTP network management traffic.
-
The
Internet protocol (IP)
provides a standard encapsulation of data for transmission over the network. It contains a source and destination address used for routing.
-
A
media access control (MAC)
performs management functions and handles
address resolution protocol (ARP)
for the device.
-
An Ethernet driver
configures and controls the Ethernet controller hardware, including setting up DMA operations.
System services consists of the following software
modules:
-
The startup/initialization module
provides startup and initialization of the hardware and software.
-
The POST module
provides power-on self-test (POST) functions.
-
The RTOS module
provides functions such as task management, memory management, and task synchronization.
-
The board support package (BSP) module
provides hardware interface drivers, interrupt vectors, etc. that allows the RTOS to operate on the target hardware platform.
-
The watch dog timer driver
provides control of a hardware watchdog timer as a control mechanism to prevent lock-ups due to a software or intermittent hardware failure.
-
The Flash memory manager
provides functions for reading/write data from/to the Flash memory.
-
The DSP interface manager
provides the driver for exchanging information between the MCU and DSP, including software download, voice packets, and network management functions.
Searching
for the “killer app”
Creating a system that places voice and fax over packet networks is a very complex undertaking. There are many system issues and trade-offs that need to be addressed early on in the design of the product. The good news is much of the functionality can be implemented in a flexible software-based solution that is configurable by the end user and later remotely upgraded by the vendor to keep pace with rapidly changing requirements and standards in the industry.
Market
projections for VoP-enabled products are staggering. The market research group IDC has predicted that by the year 2002, the Internet could carry 11% of U.S. and international long distance traffic. Between today and 2002, a plethora of VoP networking products will be introduced, many of which will be based on the same or similar embedded system design techniques discussed in this article. The industry leaders of tomorrow are already designing and developing such products. Today’s marketplace observers
have only seen a fraction of the potential that this technology has to unleash more network efficiencies and “killer” applications.
Eric Bear joined Telogy Networks in November 1996. He has over 11 years experience in the telecommunications industry in various engineering and management roles at Telogy Networks, MCI, and GTE. Bear received a BSEE from Bradley University and an MSEM from George Washington University. He can be reached at
ebear@telogy.com.
Puzzled by a network processing design issue?
