sigtran
SS7 over IP Signaling Transport & SCTP
Definition
Signaling Transport (SIGTRAN) is a new set of standards defined by the International Engineering Task Force (IETF). This set of protocols has been defined in order to provide the architectural model of signaling transport over IP networks. As such, only the signaling solutions are defined in this tutorial; transport of bearer traffic is not covered.
Overview
The communication industry is going through a period of explosive change that is both enabling and driving the convergence of services. Data is becoming more significant as a proportion of traffic compared to voice. Operators are seeking ways to consolidate voice and data traffic, platforms, and services in order to reduce the operational, maintenance, and initial cost of the network. With a number of technological solutions to choose from, Internet protocol (IP) is now considered the most promising media on which to build the new integrated services. There is an on-going integration of circuit networks and IP networks. Fixed and mobile telephone network operators are designing all–IP architecture, which includes support for signaling system 7 (SS7) signaling protocols. IP provides an effective way to transport user data and for operators to expand their networks and build new services. Mass popularization of communication services, including short message services (SMS), contribute to the rapid growth of signaling networks. As such, more scalable and flexible networks, such as the Internet and its technologies, are needed. The benefits of using an IP network in comparison to a legacy time division multiplex (TDM)–based network include:
? Ease of deployment—When using signaling gateways (such as access service group [ASG]), there is no need to disrupt the existing SS7 network, and future enhancements are transparent.
? Less costly equipment—There is no need for further expensive investments in the legacy signaling elements.
? Better efficiency—SIGTRAN over an IP network doesn't require the physical E1/T1 over synchronous digital hierarchy (SDH) rings. Using new technologies like IP over SDH and IP over fiber, for instance, can achieve
much higher throughput.
? Higher bandwidth—SIGTRAN information over IP does not constrain to link capacity as it does in the SS7 network. The IP network is much
more flexible than the TDM-based legacy network.
? Enhanced services—Implementing a core IP network facilitates a variety of new solutions and value-added services (VAS).
Figure 1. Sample Implementation for Signaling Transport over
IP
Figure 1 depicts the diversity of solutions achieved by using signaling transport protocols. Using SIGTRAN protocols such as an MTP3 user application (M3UA) and a signaling connection control part user application (SUA), the application vendor (i.e Short Message service center [SMSC], IP—home location register [IP-HLR], and so on) only has to develop the application layer and does not have to deal with the complex SS7 interfaces. By making the network introduction complexity and integration problem much shorter, the time for marketing these new applications will be much faster. SS7 over IP also solves the throughput limitation that was inherited from the SS7 standards, thus allowing high-end machines like SMSC, HLR, and so on to be able to support heavy SS7 traffic needs.
By using signaling gateways, both legacy and new equipment can seamlessly continue to operate over high bandwidth, scalable and available IP–based core network, instead of burdening the TDM–based legacy SS7 network.
Topics
Definition and Overview
1. SIGTRAN Overview
2. Why Develop a New Transport Protocol; The Motivation
3. Stream Control Transport Protocol (SCTP)
4. Message Transfer Part 2 Peer-to-Peer Adaptation (M2PA)
5. M2UA
6. M2PA and M2UA Comparison
7. Message Transfer Part 3 User Adaptation (M3UA)
8. SUA
9. SUA and M3UA Comparison
10. Conclusion
Self-Test
Correct Answers
Glossary
1. SIGTRAN Overview
Description of SIGTRAN Working Group
SIGTRAN (Signaling Transport) is a working group within the IETF standard
organization. Its primary purpose is to address the transport of packet-based
public switched telephone network (PSTN) signaling over IP networks, taking into account the functional and performance requirements of the PSTN signaling.
In order to interwork with the PSTN, IP networks need to transport signaling such as integrated service digital line (ISDN) (e.g. Q.931) or SS7 (e.g. ISDN user part (ISUP), SCCP, and so on) messages between IP nodes such as a signaling gateway (SG), a media gateway controller (MGC), a media gateway (MG), or an IP–based database. The SIGTRAN working group specific goals are:
1. Functional and Performance Requirements—The working group
produced several informational requests for comment (RFC), identifying
functionality and performance requirements to support signaling over IP
networks. Signaling messages (especially SS7) have a very stringent loss
and delay requirements in the existing telephone networks that must to be
adhered to.
2. Transport Issues—The working group produced a "standard track"
RFC, which defines the transport of signaling protocols using a newly
defined transport protocol, based on the requirements identified above. SIGTRAN Protocol Architecture (RFC 2719)
The architecture that has been defined by SIGTRAN work group consist 3 components:
? A standard IP.
? A common signaling transport protocol—A protocol that supports a common set of reliable transport functions for signaling transport. In
particular, SCTP is a new transport protocol that has been defined by the
IETF.
? An adaptation sub-layer that supports specific primitives, such as management indications, required by a particular signaling application
protocol. Several new adaptation sub-layer protocols have been defined by the IETF: M2PA, M2UA, M3UA, SUA, and IUA. Only one protocol has to
be implemented at a given time.
Figure 2. SIGTRAN Protocol Stack Model
2. Why Develop a New Transport Protocol?—The Motivation
? Transmission Control Protocol (TCP) (RFC793) performs an enormous service as the primary transport protocol in the means of
reliable data transfer in IP networks. However, because it was defined a
long time ago and was designed as a packet-oriented protocol, TCP
imposes several limitations for new emerging applications. An increasing
number of recent applications have found TCP too limiting. Some of the
limitations include the following:
? Reliability mechanisms—TCP provides both reliable data transfer, through acknowledgments mechanism, and strict order of transmission
delivery of data, through sequencing mechanism. Some applications need
reliable transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these cases the head-
of-line blocking caused by TCP adds unnecessary delay.
? Real-time issues—The abovementioned acknowledgement mechanism (which added the unnecessary delay) makes the TCP inappropriate for
real-time applications.
? TCP sockets—The limited scope of TCP sockets complicates the task of providing highly available data transfer capability using multi-homed
hosts.
? Security issues—TCP is relatively vulnerable to denial-of-service attacks. All the abovementioned limitations of TCP are relevant while trying to transport SS7 signaling over IP networks, and this is the direct motivation for the development of SCTP as a new transport protocol for SIGTRAN. SCTP has not been developed solely for SIGTRAN; thus SCTP may be a good solution for the requirements of other applications.
3. SCTP (RFC 2960)
Overview
SCTP is a new IP transport protocol, which exists at an equivalent level with TCP and user datagram protocol (UDP) and which currently provides transport layer functions to many Internet-based applications. SCTP has been approved by the IETF as a proposed standard, and is specified in RFC 2960.
Architectural View of SCTP
SCTP is architecturally viewed as a layer between the SCTP user adaptation layer (see Figure 2) and a connectionless packet network service such as IP (This tutorial assumes that SCTP runs on top of IP). The basic service offered by SCTP is a reliable transfer of user messages between peer SCTP users. SCTP is connection oriented; thus it establishes a connection between two endpoints (called association in SCTP context) before transmitting the user data itself.
Functional View of SCTP
The SCTP transport service can be fragmented into several functionalities. These functions are depicted in Figure 3 and explained in the remainder of this section.
Figure 3.
Note: "SCTP user" refers to adaptation protocol in this context.
1. Association Startup and Teardown—An association is initiated by a
request from the SCTP user. A cookie mechanism is employed during the initialization to provide protection against security attacks.
2. Sequenced Delivery within Streams—The SCTP user can specify at
association startup time the number of streams to be supported by the
association.
3. User Data Fragmentation—SCTP supports fragmentation and
reassembly of user messages to ensure that the SCTP packet passed to the lower layer conforms to the path multiple-tenant unit (MTU).
4. Acknowledgement and Congestion Avoidance—SCTP assigns a
transmission sequence number (TSN) to each user data message
(fragment or unfragmented). The receiving end acknowledges all TSNs
received, even if there are gaps in the sequence.
5. Chunk Bundling—The SCTP packet delivered to the lower layer consists
of a common header followed by one or more chunks. The following table depicts the general structure of an SCTP packet:
1. Packet Validation—A mandatory verification tag field and a 32-bit
checksum field are included in the SCTP common header.
2. Path Management—The SCTP path-management function chooses the
destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set.
SCTP Common Header Format
The following table depicts the common header format of SCTP:
Source/Destination Port Number Field: 16 Bits
Indicates the SCTP sender's/destination's port number.
Verification Tag Field: 32 Bits
The receiver of this packet uses the verification tag to validate the sender of this SCTP packet.
Checksum Field: 32 Bits
This field contains the checksum of this SCTP packet. SCTP uses the Adler-32 algorithm for calculating the checksum.
4. M2PA
M2PA defines a protocol supporting the transport of SS7 MTP3 signaling messages over IP, using the services of the SCTP. M2PA allows for full MTP3 message-handling and network-management capabilities between any two SS7 nodes communicating over an IP network. M2PA supports:
1. Seamless operation of MTP3 protocol peers over an IP network connection
2. The MTP2/MTP3 interface boundary, management of SCTP transport
associations, and traffic instead of MTP2 links
3. Asynchronous reporting of status changes to management
The MTP specification requires that each node with an MTP3 layer will be represented by an SS7 point code. Thus, each IP signaling point must have its own SS7 point code.
Figure 4 depicts an SS7 signaling point connected through an SG equipped with both traditional SS7 and IP network connections to an IP signaling point. The IP signaling point processes MTP3–to–MTP2 primitives. In effect, the SG acts as an STP.
Another example, related to the above figure, refers to two SGs connected over an IP network to form an SG mated pair similar to the way STPs are provisioned in traditional SS7 networks.
Figure 5 depicts another example. In this example MTP3 is adapted to the SCTP layer using the M2PA in an all–IP architecture.
Here the IP signaling-points MTP3 uses its underlying M2PA as a replacement for MTP2. Communication between the two layers—MTP3 or M2PA—is defined by the same primitives as in MTP3/MTP2 communication. M2PA performs
functions similar to MTP2.
5. M2UA
M2UA defines a protocol for transport of SS7 MTP2 user (e.g. MTP3) signaling
messages over IP using SCTP. The only SS7 MTP2 user is MTP3. M2UA provides
support for:
? MTP2/MTP3 interface boundary
? Communication between layer-management modules
? Support for management of active associations
Figure 6. Connection of SG to IP Signaling Point
In an SG, it is expected that the SS7 signaling is received over a standard SS7
network termination, using the SS7 MTP to provide transport of SS7 signaling messages to and from an SS7 signaling endpoint. The SG then provides
interworking of transport functions with IP SIGTRAN in order to transport the
MTP3 signaling messages to the IP signaling point where the peer MTP3 protocol layer exists. In M2UA, the IP signaling point's MTP3 uses the SG's MTP2 as its lower SS7 layer using the appropriate primitives defined between the layers. The MTP3/MTP2 communication is defined as M2UA messages and sent over the IP connection.
6. M2PA and M2UA Comparison
Figures 4 and 6 depict a possible architecture to describe the differences between the two protocols:
M2PA M2UA
MTP3 Data Messages Transport MTP3 data
messages
Transport MTP3 data messages
Interface with MTP3 Present an MTP2 upper
interface to MTP3
Present an MTP2 upper interface to
MTP3
Primitives IP signaling-point
processes MTP3–to–
MTP2 primitives IP signaling point transport MTP3-to-MTP2 primitives to SG's MTP2 (via the interworking function) for processing
Types of Links SG to IP signaling-point
connection is an SS7 link
(in MTP3 aspects). SG to IP signaling-point connection is not an SS7 link. It is an extension of MTP2 to a remote node.
Point Codes SG is an SS7 node with a
point code. SG is not an SS7 node and has no point code.
SS7 Upper Layers SG can have upper SS7
layers, e.g., SCCP.
SG does not have upper SS7 layers
because it has no MTP3.
Management Relies on MTP3 for
management procedures
Uses M2UA management procedures 7. M3UA
M3UA defines a protocol for supporting the transport of any SS7 MTP3 user signaling (e.g., ISUP/SCCP messages) over IP using the services of the SCTP. This protocol would be used between an SG and a media gateway controller (MGC) or IP–resident database. M3UA is suitable for transfer messages of any MTP3 user part. The list of these protocol layers includes, but is not limited to, ISUP, SCCP, and telephone user part (TUP). Note: Transaction capabilities application protocol (TCAP) or radio access network application protocol (RANAP) messages are transferred transparently by the M3UA as SCCP payload because they are SCCP user protocols.
The M3UA layer provides the equivalent set of primitives at its upper layer to the MTP3 users as provided by the MTP3 to its local MTP3 users at an SS7 signaling
endpoint. In this way, the ISUP and/or SCCP layer aren't aware that the expected
MTP3 services are offered remotely from an MTP3 layer at an SG, and not by a local MTP3 layer. The MTP3 layer at an SG may also be unaware that its local
users are actually remote user parts over M3UA. In practice, the M3UA extends access to the MTP3 layer services to a remote IP–based application.
Figure 7.
Application Server Process (ASP)—MGC, IP SCP, or IP HLR
Figure 7 depicts an SG containing an instance of the SS7 SCCP protocol layer that may, for example, perform the SCCP global title translation (GTT) function for messages logically addressed to the SG SCCP. If the result of a GTT for an SCCP message yields an SS7 destination point code (DPC) or DPC/subsystem number (SSN) address of an SCCP peer located in the IP domain, the resulting request is sent to the local M3UA for ongoing routing to the final IP destination using the services of SCTP/IP layers.
Figure 8. All–IP architecture
In this example, SCCP messages are exchanged directly between two IP signaling
points with resident SCCP user protocol instances, such as RANAP or TCAP. SS7 network interworking is not required; therefore there is no MTP3 network-
management status information for the SCCP and SCCP user protocols to consider.
8. SUA
SUA defines a protocol for the transport of any SS7 SCCP user signaling (e.g.,
TCAP, RANAP, etc.) over IP using SCTP services. The protocol is designed to be
modular and symmetric so as to allow it to work in diverse architectures such as an SG–to–IP signaling-endpoint architecture as well as a peer-to-peer IP
Signaling Endpoint architecture. SUA supports the following:
? Transfer of SCCP user part messages (TCAP, RANAP, etc.)
? SCCP connectionless service
? SCCP connection oriented service.
? Management of SCTP transports associations between a SG and one or more IP–based signaling nodes
? Distributed IP–based signaling nodes
? Asynchronous reporting of status changes to management
Figure 9. Architecture for Connectionless Transport
ASP—MGC, IP SCP or IP HLR
In this architecture, the SCCP and SUA layers interface in the SG. Their needs to
be interworking between the SCCP and SUA layers to provide the seamless transfer of the user and management messages. For messages destined for an
ASP, there are two scenarios:
? SG as Endpoint
In this case, the connectionless SCCP messages are routed on point code and
SSN. The subsystem identified by SSN and SS7 network appearance is regarded as local to the SG. This means that from the SS7 point of view, the SCCP user is located at the SG.
? SG as relay point
A GTT must be executed at the SG before the destination of the message can be determined. The actual location of the SCCP user is irrelevant to the SS7 network. GTT yields an "SCCP entity set," which now may contain one or more ASs (refer to Chapter 17). Selection of the AS is thus based on the SCCP called-party address.
All-IP Architecture
This architecture can be used to carry a protocol that uses the transport services of SCCP but is contained within an all–IP network. This allows extra flexibility in developing networks, especially when interacting between legacy signaling is not needed. Figure 10 describe this case:
Figure 10.
9. SUA and M3UA Comparison
In general, the protocol stack based on SUA is less complex and more efficient compared to the protocol stack based on SCCP and M3UA. Consequently, SUA can enhance the efficiency of the core network and can provide the means for simpler implementations.
M3UA SUA
SCCP Flavors The signaling point is
required to support
different flavors of SCCP
if it has to interoperate
with different national
systems.
This problem is eliminated using
SUA.
Implementation Complexity M3UA needs the SCCP
services.
One protocol layer less. The
elimination of SCCP reduces the
complexity of the network node
(implementation as well as
management), therefore reducing
costs.
Routing Aspects In M3UA the message is
handled from point code
to point code.
SUA allows the IP network to
route the messages using global
title information.
Addressing Aspects Using M3UA each IP
node is required to have
both the IP address and
point code assigned to it.
Using SUA each IP node does not
consume scarce point-code
resources.
ISUP Services Supported Cannot be supported
As we can see, in general, SUA provides a better solution. SUA provides much better scalability and flexibility for signaling network implementation in all–IP network compared with the SCCP/M3UA option. The powerful addressing and routing capability of SUA can greatly reduce the signaling transfer latency.
10. Conclusion
Network Evolution to an All–IP Network Operators want to migrate towards IP–based network architecture. Since the transition to an all–IP network will not happen overnight, both traditional circuit-switched and IP–based services need be supported by a single network
infrastructure simultaneously. It is believed that circuit switching will live for many years together with IP services. Hybrid architecture may be the best solution for most of the operators because it allows low-risk evolution from the current networks, while enabling a new services offering. These reasons have lead to several standard working-group studies, among them the SIGTRAN working group in the IETF organization. The architectural model that has been defined by the SIGTRAN working group enables the network evolution toward an all–IP network. The architectural model defines two new components—SCTP and several user adaptation sub-layer protocols (e.g. M2PA, M3UA, SUA)—which together enable the required mechanisms for converging these two networks.
Figure 11. Example for Network Architecture using SIGTRAN
Protocols with the Signaling Gateway