|
Opening Doors to Media Gateway Design
By Brian Carr
As VoP systems begin to roll out, designers must rethink their gateway designs. By turning to open architectures, designers can achieve the power and performance needed to make VoP gateway designs a success.
Across the world, current telecom operators and network providers are upgrading their core networks to support packet-based services. At the same time, new operators and network pro-viders are installing primarily packet-based data networks and wish to offer voice services over those networks.
The main reason for this switch to packet-based technology is the staggering growth of data service requirements driven by Internet technology, third-generation (3G) wireless systems, and the business benefits accrued by better data communications.
In addition, advances in speech and signal processing have enabled the provision of voice services within the packet data network. But the key challenge to the IP telephony equipment industry is to replicate the voice quality of the existing circuit-switched network in a packet-based infrastructure.
Voice-over-packet (VoP) technology provides telecommunication operators with a new approach to network implementation and service deployment. The transition to VoP is motivated by many factors including the pressure to reduce operational costs for voice service, the ability to acquire new customers and grow revenue sources with additional services, and the need to leverage idle capacity in existing data networks.
However, the move to packet voice equipment is being accomplished in "Internet time" rather than as the historically slow and steady development cycle. This is where open standards solutions can bring an advantage. But architecting a system using open standards requires an understanding of where bottlenecks lie within every scenario.
The traditional approach
Let's start by considering the elements of a typical standards-based media gateway (see Figure 1). Conceptually the media gateway consists of four elements: a line card, a transcoding engine, a gateway controller, and a packet network interface.
On the circuit-switched network side, a line card is required to connect the time division multiplexed (TDM) channels from the PSTN to the gateway. A transcoding engine performs processing to convert between standards. A gateway controller manages the gateway and call routing. And finally, a packet network interface routes calls between the gateway and the packet infrastructure.
Figure 2 highlights the dataflows and connectivity provided by the gateway. Although conceptually this is a straightforward and logical split in functionality, when it comes to real-world implementations and the requirement to achieve balance in a dynamic system, the choices are no longer quite as simple.
The media gateway has to perform many tasks during the process of routing calls from a circuit-switched network to the packet network and as a result different processors will be required for the different tasks.
To develop better VoP media gateways, there are some important considerations that designers need to take into account in order to make some key choices. One of the main choices a designer must make involves processing.
In most modern VoP gateway architectures, designers can spread resources between RISC microprocessors and DSPs. The key is properly balancing functions between these resources.
Overall, in a VoP design, RISC processors are a good solution for handling transmit and receive signals. DSPs, on the other hand, are better solutions for transcoding and voice encoding/decoding.
Balancing channels
But, balancing the microprocessor/DSP mix is only one key consideration. Today's designers must also balance the number of T1/E1 channels needed in a gateway as well as how these channels are distributed across the gateway.
Starting on the circuit-switched side, voice/fax/data calls come in as TDM streams within a carrier, often as a T1 or E1 stream. The balance of T1/E1 channels is typically accomplished using a card structure, which allows designers to simply add or remove a card to increase or decrease the number of T1/E1 channels. In the case of VoP gateways, two common card architectures are employed. The first is the PCI mezzanine card (PMC), which is quickly evolving into the PCI telecommunication mezzanine card (PTMC) The second is a CompactPCI (CPCI) card hooked to an H.110 backplane, which supports 4,096 channels in a chassis. Some commercially available VoP boards provide T1/E1 capability using proprietary mezzanines. These solutions, however, are similar to the PMC and PTMC.
Looking inside
Once inside the gateway, transcoding needs to occur. Transcoding involves the decoding and encoding of channels from one standard to another.
Almost universally, a circuit-switched voice call comes in as a G.711 encoded 64-kbit channel, while most packet network operators specify a compressed channel to maximize channel capacity and provide bandwidth for data services. Voice coding and compression is provided by a number of ITU standards, but most commonly G.723.1 or G.729 (A, B, or AB.) These are not too dissimilar in terms of their MHz-per-channel requirement, a metric often quoted by algorithm pro-viders. The difficulties start to arise when operators want to use different compression schemes or no compression at all.
For instance, should a packet network operator wish to maximize voice quality, or has the bandwidth to run uncompressed voice channels, the signal-processing load is reduced dramatically. Additionally, echo cancellation can have a significant effect on speech quality, and this in turn significantly affects DSP loading depending on the tail length required. (From 16 to more than 64 ms may be needed.)
Unfortunately, further back in the system, the requirements of the packet processor, which implements the packet network interface, remains unchanged.
This results in a difference in the balance between a largely G.711 system versus a system running compression, as well as between systems running differing-length echo cancellers. With changing DSP requirements, bottlenecks within the rest of the system may easily arise if these factors are not considered.
To restore balance within the transcoder and maintain maximum efficiency, two options are available to designers. The first is to increase the performance of the RISC processor, thereby enabling the DSPs to be fully utilized without the packet interface becoming a bottleneck. The second option, but less attractive from a density point of view, is to reduce the number of DSPs to balance the system. This option is not preferred since density is often an important metric in gateway applications.
Achieving maximum efficiency can be relatively simple for static systems where only one type of transcoding, or a predetermined mix of transcoders, is required. (such as G723.1 to G711 only). In these scenarios, balance remains largely unchanged. In a dynamic system where the ratio of compressed to uncompressed channels is constantly changing, a different approach may be appropriate.
Packetization
After voice coding and compression, the channel will require packetization prior to sending the data over the packet network. Real-time packets (RTPs) can be generated by either the DSP or RISC processor. In lightly loaded DSP systems (as in the case of uncompressed voice data), it will be better to process RTPs using the DSP. On the other hand, in a heavily loaded DSP system, the best approach is to perform RTPs on the microprocessor.
Following RTP generation, data is passed to a packet network interface router. At this stage, designers should be concerned with call clients and control protocols such as H.323 and SIP. In addition, designers need to consider the mode of operation that affects the network call client and RTP engine.
VoP systems can support a mode that uses voice activity detection (VAD). During a typical conversation, 50% or more of the call can consist of silence where no voice is present and only background noise can be heard. If voice is not present it is possible to avoid sending packets of data. This can significantly reduce the demands on the RTP processor and network call client. Voice quality is normally considered poorer when operating in this mode. Comfort noise generators (CNG), however, help perceived quality by adding background noise - complete silence during breaks in voice traffic is not desirable.
Therefore, during gateway design, it is important for designers to determine where RTPs are generated as well as whether VAD is enabled or disabled. These are key considerations that can dramatically impact the overall quality of a VoP gateway design.
Simple gateway design
Now that we've covered some of the key considerations designers need to make when selecting a gateway design, we can take a look at how these elements can be combined in three different ways to construct a high-density media gateway. The concepts demonstrated can also apply to other open-standard media-gateway elements.
It is best to start with a simple gateway design (see Figure 3). In this architecture, the DSP board performs all of the media gateway functionality. This is an architecture typically used where the signaling interface is relatively simple (as with channel associated signaling and ISDN primary rate interface [PRI]), and where the architecture can easily be associated with the channels that are directly terminated on the gateway processor board.
In the simple gateway design, PSTN lines are terminated directly on a PMC module located on a DSP resource board. Calls flow directly from the T1/E1 framers to the DSP board via a dedicated TDM interface.
In the gateway highlighted in Figure 3, the DSP board performs all of the telephony signaling and network protocol processing (including H.323 or SIP call signaling) as well as the voice/fax processing. The CPCI host CPU, on the other hand, is responsible for initial setup and configuration of the system, and monitors each individual card for errors or alarms. This CPU can run element manager software that allows this gateway to be administered from a central management system across its own private IP connection.
There are many benefits to using the simple gateway architecture. The main benefit, however, is that increasing the channel density of this system is straight-forward since the DSP board performs all channel-dependent processing. Thus, designers simply need to increase the number of DSP boards to increase system density.
There are, however, disadvantages to the simple gateway approach detailed in Figure 3. Normally this complete gateway in a slot solution is balanced for a particular setup, and quite often the balance point is based around the most complex compression scheme. The number of line interfaces is matched to the DSP processing power, which is also matched to the capability of the packet network interface and RTP processor. The packet network interface is also predetermined.
This balance is well-specified for a large percentage of applications and still provides a level of flexibility. The problem is that the system deviates from the efficiency created by a standards-based architecture.
This inefficiency is effectively illustrated when considering uncompressed channels. In this situation the DSP is capable of processing far more channels but the line card and network processor may become bottlenecks within the system. The system will not reduce in channel density, but equally it will not provide the best channel density considering the level processing power available. VAD could be used to lighten the load on the network processor, but that still leaves the line card as a possible restriction.
Signaling gateway
The signaling gateway is another architecture gaining popularity in the VoP design community. In this architecture, an additional open-systems line interface board handles the line-termination function, and the voice channels are passed to the DSP board using the H.110 CT bus (as shown in Figure 4). This architecture supports more-complex telephony signaling such as SS7, where signaling for all the channels can be carried on a few resilient link sets. It may also be used for very high-density termination, such as T3 or E3.
In the signaling gateway approach, the DSP board still performs all voice and network protocol processing (including H.323 signaling). Here the CPCI host performs additional functions such as signaling gateway and Media Gateway Control Protocol (MGCP) call agent functions for the system.
One advantage to this approach is that the channel-handling capacity of the DSP board is not limited by the number of channels directly terminated on the board. Thus the amount of DSP power required could more accurately be matched to the number of channels terminated on accompanying line interface boards. The onboard PMC-based line-termination capability can be used to supplement the external line-termination capability if required.
However, if the DSP board has been balanced for a compressed voice capability, then the packet processing capability may prove to be the limit for channel density using uncompressed voice. Once again choices exist here. One way to solve the imbalance is to provide an external network protocol engine. An alternative, as described within the simple gateway, may be to use VAD to reduce the packet traffic.
Trunking gateway
The final architecture explored in this article is the trunking gateway. This gateway approach builds on the signaling gateway described above. In this scenario, the line-termination and network protocol functions are performed away from the DSP board (see Figure 5). In the following discussion on packet network processing, it should be noted that the processing may be physically located on a separate CPCI board or as a PMC module sited on the DSP board.
In the trunking gateway, voice channels are still fed to the DSP board across H.110 from the external CPCI-based line card. The DSP board performs voice packet processing, but the resulting packets are sent to an additional network protocol engine for onward transmission.
One advantage of this approach is that dedicated protocol processor boards can be used that offer a much increased packet capability and better network connections compared with the on-board resources of the DSP board, which are normally Ethernet-based. It also supports direct connection to a wider range of data networks.
Interface choice
Within the trunking gateway, designers employ fully integrated board-level solutions that include the network interface. Quite often the chosen interface is Ethernet. However, the capability to link ATM, Frame Relay, and other interfaces may be required for some systems. In the trunking gateway scenario, the new I/O mechanism and associated protocol processor engine can be located away from the DSP board, either as a PMC module (physically located on the DSP carrier) or as a separate CPCI card.
When considering architectures such as the trunking gateway, a designer should think about open standards issues. With individual PSTN interfaces, transcoding resources, and packet network processors, system balance can always be achieved whether running compressed or uncompressed voice channels, long or short echo tails, or VAD enabled or disabled. By matching line cards, DSP resources, and packet network interfaces, the optimum balance can be achieved.
The disadvantage of the fully flexible trunking gateway is complexity. A fully integrated solution such as the simple gateway will always be easier to implement and manage, and often provides the best density. Since the functions of the gateway are split over a number of cards in the trunking gateway, density can fall in certain scenarios.
The advent of high-performance hardware and well-tested software has dramatically improved the ability of VoP media gateway designers to develop high-density, manageable solutions quickly and meet the needs of the service providers. However, there are still challenges to solve, and a well-balanced solution that matches voice processing capability with packet processing capability is key to the solution.
In the race to market, and with an ongoing requirement to remain flexible, open systems can provide levels of adaptability not usually available when using proprietary systems and backplanes. An open-systems approach is fundamental to this shift, and standards bodies such as the PCI Industrial Computer Manufacturers Group (PICMG), the VMEbus International Trade Association (VITA), and the PCI Special Interest Group (PICSIG) are leading the way.
| 
Puzzled by a network processing design issue?
