To accompany the new ATCA standards defined by PICMG, a new mezzanine card open
standard has been proposed by the PICMG committees. This capitalizes on the success
of the PCI Mezzanine card (PMC) but provides a whole new level of performance
and connectivity. Additionally, management functionality and hot-swap functionality
have been added to the Advanced Mezzanine card (AMC) to meet the growing requirements
The physical form-factor was designed to relate directly to the ATCA blade, enabling
up to eight AMC cards to be installed in one ATCA carrier card. However the AMC
specification is not designed with only ATCA as a carrier in mind. It has been
written in a more generic manner to allow companies to continue to use proprietary
backplane implementations and gain the benefits of AMC’s advanced modularity,
performance and capabilities.
PICMG committees published the PICMG 3.0 (Base Fabric) and 3.1 (GigE Fabric)
series of standards last year. This has led to new developments of existing
functional elements within the networking world, and with the arrival of the
AMC (AMC.0, Base Fabric and AMC.1 GigE Fabric) standards later in mid-2004,
a further development acceleration using the new open standards is to be expected.
The Sigtran working group of the Internet Engineering Task Force (IETF) has defined
a suite of protocols that are used within a signaling gateway (SG) to transport
SS7 messages from the Public Switched Telecom Network (PSTN) to a node within
an IP network.
The protocols make use of a network architecture that includes:
An SG, which forms a gateway between the PSTN and Internet Protocol (IP)
domains. The SG terminates Signaling System Number 7 (SS7) links and contains
both the (lower layer) SS7 and Sigtran protocol stacks. Messages received on the
SS7 interface are passed up to the SS7 stack until they are received by a Sigtran
protocol layer. They are then transported out over the IP interface to an Application
Server Processor (ASP) or another SG.
An ASP—a node in the IP domain that contains the Sigtran protocol
stack and upper layers of SS7. Signaling messages are received on the IP interface
and passed up through the Sigtran layers until they are received by the higher
layer SS7 protocol.
The Sigtran protocol suite consists of:
- Stream Control Transport Protocol (SCTP)—a common transport
protocol, used to carry Signaling traffic over IP.
- A number of User Adaptation (UA) layers, which are peculiar to
the SS7 layer that is being transported.
- The Sigtran adaptation layers all serve a number of common purposes:
- To carry upper layer Signaling Protocols over a reliable IP-based
transport (i.e. SCTP).
- To provide the same class of service offered at the interface of
the PSTN equivalent. For example, M3UA must provide the same look and feel
to its users as MTP3—in terms of services, at least (M3UA does not actually
replace the features and operations of MTP3).
- To be transparent: the user of the service should be unaware that
the adaptation layer has replaced the original protocol (although this is
largely dependant on the implementation).
- To remove as much need for the lower SS7 layers as possible.
Sigtran currently defines four SS7-related adaptation layers, as follows:
- M2UA provides the services of MTP2 in a client-server situation, such as
SG to ASP. Its user would be MTP3. M2UA provides a mechanism by which MTP3
on the ASP can use the services of MTP2 links on the SG, and by which SS7
messages may be routed to an MTP3 node in the IP world.
- M2PA, which is still under development and is not currently at the request
for comment (RFC) level, provides the services of MTP2 in a peer-to-peer situation,
such as SG-to-SG connections. Its user would be MTP3. Rather than provide
a link between remotely located MTP2 and MTP3 instances, it replaces an MTP2
link beneath MTP3. The user of M2PA is MTP3 at both ends of the connection
(unlike M2UA, where the one user is MTP3 on the ASP, with M2UA being a user
of MTP2 on the SG). M2PA provides a means for peer MTP3 layers in SGs to communicate
directly. In essence, it extends the reach of SS7 over the IP network.
- M3UA provides the services of MTP3 in a client-server (SG to ASP) situation.
Its users would be SCCP and/or ISUP. M3UA provides the mechanism by which
SCCP or ISUP on the ASP can use the services of MTP3 on the SG and by which
SS7 messages may be routed to an SCCP/ISUP node in the IP world.
- SUA provides the services of SCCP in a peer-to-peer architecture, such
as SG to IP SCP. Its user would be TCAP, or another transaction-based application
part. SUA provides the mechanism by which TCAP on the ASP can use the services
of SCCP on the SG, and by which SS7 messages may be routed to a TCAP node
in the IP world.
A further two layers (IUA and V5UA) deal with ISDN and V5.2 traffic, respectively.
It should be noted that the framework is flexible enough to allow for the addition
of new layers as required.
The choice of which adaptation layer to use depends very much on the service
required, and the network architecture on which it is being deployed:
- M2UA is applicable where SS7 links are spread around, with a low
density at any given physical location. In this case, the traffic is aggregated
at the ASP, where MTP3 (and the SS7 point code) will be located.
- M2PA is used when the links between a pair (or number of) SS7 nodes
are being replaced with an IP backbone.
- M3UA is more suitable where the links are concentrated at a single
point—in this case, MTP3 resides on the SG, along with the point code.
- SUA is used where TCAP services are deployed on a number of IP
nodes (IP SCPs). SUA is able to route on Subservice Number (SSN)—an
identifier for each TCAP service node.
The architecture of an SG is shown in Figure 2. This example shows the M3UA
case, with the functional requirements of the SG platform highlighted. A high-availability
solution can be provided by implementing distributing and load sharing the MTP3
point codes across many blades or modules. The user adaptation layers have high
availability built in, by supporting the possibility of multiple ASPs. Additionally
the ASPs themselves can support multiple SGs.
ATCA/AMC Signaling Gateway
In the SpiderWareSG Diagram in Figure 2, the functionality required for an
SG can be split into three functional areas: SS7 communication, bridging functionality
(SCTP, M2UA, etc.) and next-generation network communication. Additional support
is required for remote management/configuration and high-availability failover/load
sharing capabilities. This gives the derivation of a generic structure for a
signaling gateway shown in Figure 3. The vertical bars (or blades/modules) represent
specific functionality being interlinked by the commonly required horizontal
bars of generic functionality (or platform).
As mentioned in the ATCA overview, Interconnectivity and Chassis Management
functionality is defined as part of the PICMG standard. This, when combined
with the functional breakdown shown in Figure 3, allows us to propose the application
of ATCA technology to the SG, which requires blade level management and interconnectivity
between its functional elements.
Based on Figure 3, three separate ATCA blades could be applied directly to the
functions shown. However, an ATCA blade has been designed such that there is
sufficient real estate and power to fully implement the SS7 communication and
general processing capabilities of the SG. Additionally, by placing the SCTP/IP
functionality within the general-purpose processing capability on an ATCA blade,
it would be possible to use the backplane switched fabric of the ATCA rack as
the interface to the next-generation network.
This is not, however, a fully redundant system, which was part of the requirements
for an SG. A fully redundant system can be provided by adding a second blade
and utilizing the backplane of the ATCA chassis to pass the high-availability
load sharing/failover management information. Additionally, by adding extra
blades we can expand our signaling gateway to meet the final requirement of
the SG, that of expandability.
ATCA provides the structure to support the management of the elements of the
SG, however it is not as flexible as it can be. By adding a PMC site to the
ATCA blade and moving the I/O functionality to that PMC, a more generic ATCA
intelligent carrier card can be created. Thus, by using a generic ATCA intelligent
carrier blade, with PMCs added for flexible I/O configuration and the ATCA switch
fabric, a generic and adaptable signaling gateway platform can easily be created.
With the addition of Sigtran protocols and remote management, an ATCA-based
SG can provide the functionality and reliability required.
ATCA/AMC SG – The Next Generation
While using an ATCA blade to contain all of the SS7 functionality, general processing
and SCTP/IP functionality can be advantageous, these functions could be split
across even more generic modules. Then if one of these functions has a critical
failure, the entire SG blade would not be put offline.
The AMC standards have been created such that the processing and I/O capabilities
allow the creation of architecture based on a more distributed solution. Each
functional element with the SG can be run on a standard AMC. These standard
AMCs provide processing capability and I/O capabilities. The SG would normally
connect to a next-generation network and so the fabric (backplane) could be
used to pass the IP-based data.
This provides a more flexible solution as well as a more agreeable economic
prospect than having the entire SG functionality on one blade. By using a standard
ATCA AMC carrier, standard processor AMC and an I/O AMC it is possible to reduce
the overall cost of the system. Only one 1+1 AMC cards are required for failover
protection. Additionally, rather than having to add blades containing all the
SG functionality to expand the system, it is only necessary to add functionality
where it is required. For example, in a case where more SS7 links are required,
an I/O AMC module can be added. Where more processing is required, either a
faster AMC or more processor AMCs can be added. Also, with AMC hot-swap, these
additions can be made while the SG is active.
The ATCA standards provide a flexible and reliable solution for all telecom
platforms. The SG network element can be easily adapted to the form-factor and
gains several key elements from the ATCA platform. The ATCA platform is still
based on a blade format akin to the CompactPCI/cPSB platform with improvements
in all areas.
With the addition of the AMC standard, the functional breakdown no longer becomes
focused on blades, but on modules. The Signaling gateway is broken down into
functional nodes and spread across multiple AMCs, thus improving expandability
and reliability. When these AMC modules are added to an ATCA carrier, the high-availability
management, the system management and the Sigtran protocol stacks, the result
is the evolution of a highly practical and reliable system.
Boca Raton, FL.