Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

The signaling gateway bridges next-generation IP and traditional packet-switched telephony networks (PSTNs) that handle, for example, the signals for establishing, controlling, and billing calls. Gateway design calls for the blending of IP-based protocols, conventional switched-circuit protocols, operating systems, management, and high-reliability hardware system design. MicroTCA, AdvancedMC hardware, and offthe- shelf software can provide building blocks to develop standalone signaling gateway designs that can scale with the growing demand for IP-based telephony.

Telephony needs two types of gateways: the media gateway for handling voice, video, and data, and the signaling gateway to handle call control. Some European telephony systems use the same physical link for both functions. Therefore, the media and signal gateways can be the same device. However, others—including the networks in North America—have signals and media travel on different physical links. Consequently, developers can separate the media and signaling gateways into independent units.

One way to address both types of installations is to create a standalone signaling gateway in module form that can serve as a component or building block in either system type. The module form allows it to plug into an available AMC site to create a combined gateway design as one system element. Or, it can serve as the basis of a pure signaling gateway that scales to handle growing call volume simply by adding more gateway modules.

The gateway module hardware design has to provide PSTN ports, typically handling E1/T1/J1 PSTN signals at a 64-kbit/s data rate for each SS7 link, with grouping for high-speed links (both clear and ATM-based). Gateways also have processors that can run both PSTN and IP networking stacks and at least two IP ports, such as Gigabit Ethernet connections, so they have redundant links to the IP network. While this seems simple, the design of a standalone gateway module can become a major challenge.

To meet telecom needs, the gateway must be designed to be available at least 99.999% (five nines) of the time. This requires an ability to cope with software and hardware failures while maintaining uninterrupted service. The ability to upgrade and/or replace hardware and software is another critical part of supporting five nines, requiring software redundancy with load-sharing and fail-over capability. In addition, the hardware supporting that software, including the module, rack, power modules, fans, and interconnect, must detect and respond to system failures (utilizing redundant hardware), provide the means to hot-swap equipment, and support a mechanism for software/firmware upgrade.

System management support is also needed because the gateway typically operates in the network as a “black box,” functioning without operator intervention. Thus, it needs to provide self-management of its hardware and protocol stack operations, including failure detection and response. Furthermore, the design needs support for setup and control of the gateway’s operation when it’s first installed in the network.

XTCA MEETS GATEWAY NEEDS
One way to reduce the magnitude of this challenge is to use a base framework that handles these required functions for the modules/blades, freeing the designer to focus on the gateway functions. The Advanced Telecommunications Computing Architecture (ATCA) and MicroTCA (combined, they’re considered xTCA) are open specifications that can address these system needs. Numerous vendors have created system building blocks based on these specifications.

A signaling gateway design based on ATCA or MicroTCA specifications, then, starts out with a significant amount of the work already completed and available as off-the-shelf hardware and software from a variety of suppliers. The specifications’ controlling organization, PICMG (PCI Industrial Computer Manufacturers Group), runs an interoperability program to promote interoperability, freeing designers to mix and match components as desired.

Both ATCA and MicroTCA use a modular design approach that builds system management and hot-swap capability into its components. As part of this, the Advanced Mezzanine Card (AMC) was initially developed as an extension to the flexibility of ATCA (by providing a hot-swappable mezzanine card for such purposes as I/O) and has since expanded its role to become the basic foundation of MicroTCA.

In ATCA, the AMC, as its name implies, is a mezzanine card that resides on a larger system card or blade, which then plugs into the system backplane. In MicroTCA, the same AMC card plugs directly into a backplane. With this approach, a common AMC design can serve without modification in systems providing a large level of scalability.

The ATCA and MicroTCA architectures offer built-in support for the design of high-availability systems. Each AMC module incorporates a module management controller (MMC) that provides a mechanism for remote control of the module’s power, operation, and backplane connection.

For MicroTCA, a MicroTCA carrier hub (MCH) within the chassis provides system management and interacts with each module’s MMC (Fig. 1). (In ATCA systems, these functions reside in combinations with the shelf management controller and the IPMC on the ATCA card capable of supporting AMCs). The interaction between MCH and MMC allows the MCH to turn AMCs on or off, interrogate them, and disable their backplane access. This gives the MCH an ability to deliver services such as electronic keying, fault detection, and fault isolation at the module level.

Options within the MicroTCA architecture support the use of redundant power supplies, cooling fans, and MCH control modules. As a result, a system can readily be designed with full hardware redundancy running high-availability system software, much of it available off-the-shelf.

Emerson’s Centellis 1000 MicroTCA chassis, for example, provides a single MCH module, with redundant power supplies. It can hold as many as 10 additional full-size AMCs, allowing it to support a variety of applications. The Centellis 500 MicroTCA chassis is a low-cost-of-entry solution using one standard MicroTCA MCH and power module to support four mid-size AMCs. The two solutions offer designers flexibility in gateway size and architecture for their particular application.

Continued on page 2

Developers of standalone signaling gateways, then, can meet telephony system needs by starting with an AMC design for a MicroTCA system and apply different MicroTCA chassis types to scale up from there as needed. The footprint of an AMC is large enough to carry all of the hardware required for a multichannel gateway, as well as provide room for multiple front-panel connections to the PSTN. Therefore, all of the required functionality is available on a single card.

In MicroTCA, these AMC modules plug into a protocolagnostic, switched serial backplane. This backplane can support Gigabit Ethernet as its base fabric, allowing the AMC module to connect directly to an IP network without the need for additional conversion.

GATEWAY SOFTWARE REQUIREMENTS
The software design for a signaling gateway is more complicated. Though the hardware consists mostly of generic network interfaces, processors, and memory, the software must handle the conversion of signals between widely different protocols while implementing high-reliability behavior. On the PSTN side is the time-multiplexed SS7 call control protocol. The packet-based Internet Protocol (IP) is on the other side.

The signaling gateway’s task is to ensure that signaling generated on one network can reach destinations on the other network. In addition, two PSTN networks can connect through an intervening IP network. The media gateways (MGs) move/convert voice, video, and data through the IP network to either other MGs or to an IP end point. The signaling gateways (SGs) encapsulate and send SS7 control signals to a media gateway controller (MGC, also known as softswitch). The MGC manages connections as they enter and exit the IP network, as well as handles connections originating from within the IP network. SGs also encapsulate the SS7 signals for transport across the IP network to another SG when the IP network links two PSTN networks. A fully bridged network thus has the structure shown in Figure 2.

As with hardware, fortunately, the availability of standardsbased, off-the-shelf building blocks greatly simplifies the software design of a standalone signaling gateway. A key element is the SIGTRAN protocol stack, which prepares and supports SS7 messages for transport over an IP network (Fig. 3). It works by replacing SS7’s MTP layers with a stream control transport protocol (SCTP) to move the control signals across the IP network.

The SIGTRAN adaptation layers mimic the missing MTP layer protocols to the upper protocols of SS7, keeping the high-level message structure intact. This structure allows the signaling gateway to terminate the MTP layers. Then it transports the upper layers to the softswitch for processing when linking IP to PSTN telephones or simply transfers the messages essentially intact to another SG to be passed along to another PSTN.

SYSTEM DESIGN DECISIONS
The specific design of the AMC modules, however, depends on how developers decide to combine modules into a highavailability system. The xTCA architecture provides the pieces, but assembling the puzzle is open to a variety of approaches.

One way to create a gateway utilizes two different AMC modules: one to handle the SS7 interface and one to handle the IP interface. These modules would split the SIGTRAN stack and communicate with each other over a high-speed backplane link, such as PCI Express. Splitting the SG functions in this manner would allow the hardware to handle a large amount of signaling efficiently.

An alternative approach is to place SIGTRAN, SCTP, and SS7 interfaces onto a single AMC module. This approach offers several significant advantages that may offset its reduced call-handling density for many installations. The first advantage is that the single-module design simplifies fail-over. Two modules can load-share the SS7 signaling, each running at 40% capacity. Therefore, when a failure occurs, the system can simply switch all of the traffic to the remaining module until the failed module gets hot-swap-replaced. Because the functionality is all within a single module design, hot-swap remains simple because there’s no need re-initialize a partner module.

Another advantage of the single-module design approach is that it offers finer granularity for system scaling. The relatively low bandwidth of SS7 signaling means that a single-module design can handle a significant number of SS7 links. This means developers can create a minimal-cost product using just a few modules in a pico-sized MicroTCA chassis (such as the Centellis 500), which suits the small gateway needs that currently comprise most of the market. If capacity demands increase, the system can then expand in small steps at modest cost, rather than in the large steps and higher cost of a two-module approach.

The single-module design provides the lowest cost of entry to the signaling-gateway market space. Because the design is focused on one AMC, it is by definition the lowest common denominator of a system and, hence, the lowest possible cost.

A side benefit is application flexibility. The AMC operates as a fully functioning black-box SG, so the single-card SG created for a MicroTCA system can also be plugged into an ATCA MG card design to create a unified gateway design. The SG AMC could also simply occupy an otherwise unused mezzanine card slot in an ATCA system to provide this additional function to a central office at minimal cost.

Consequently, implementing a standalone SG on an AMC for xTCA lets designers build a range of small to midsize products with full redundancy and expansion capacity. Furthermore, the AMC design can bring SG functionality to larger systems by being incorporated onto ATCA cards. This positions the design to address both current and future communications industry needs in its ongoing transition from the PSTN to IP-based networks.

STUART JAMIESON, director, industrial relations/architect, holds a BEng (1st class Hons) in electrical and electronic engineering and an MPhil in engineering from Heriot Watt University, Edinburgh, Scotland, U.K.

GARETH SMITH, product manager, holds a BA Hons. in engineering science from Lincoln College, Oxford University, U.K., and an MSc in computer systems engineering, Edinburgh University.