Understanding the Sigtran Protocol Suite

SS7 has been the tried and true signaling mechanism for providing signaling in traditional PSTN networks. But, with voice-over-IP (VoIP) becoming a more important technology for carriers, carriers are starting to look for more IP friendly signaling schemes to use in their network architectures.

Enter Sigtran. Developed by the Internet Engineering Task Force (IETF), the Sigtran protocol suite lets operators carry SS7 signaling traffic between a signaling gateway (SG) and a media gateway controller (MGC) or IP-enabled signaling control point (IP-SCP), thus allowing carriers to maintain their SS7 signaling schemes while being able to tap into the IP network for transport.

In this tutorial, we'll take a look at the key elements that make up the Sigtran protocol. During the discussion, we'll show how Sigtran's new transport protocol matches up with TCP. We'll also take a detailed look at each of Sigtran's user adaptation layers.

Sigtran Basics
Sigtran is a suite of networking protocols consisting of toshe stream control transport protocol (SCTP) and a set of user adaptation (UA) layers (which transform the look and feel of SCTP into the lower layers of SS7). The Sigtran architecture is shown in Figure 1.

Figure 1: Diagram illustrating the Sigtran layers.

Sigtran currently defines four SS7-related adaptation layers. These include:

1. The message transfer part level 2 user adaptation (M2UA) layer provides the services of MTP2 in a client-server situation, such as SG to MGC. Its user would be MTP3.
2. The message transfer part level 2 peer-to-peer adaptation (M2PA) layer provides the services of message transfer part level 2 (MTP2) in a peer-to-peer situation, such as SG-to-SG connections. Its user would be MTP3.
3. The message transfer part level 3 user adaptation (M3UA) layer provides the services of MTP3 in a client-server situation, such as SG to MGC. Its users would be SCCP and/or ISUP.
4. The SS7 SCCP user adaptation (SUA) layer provides the services of the signaling connection control part (SCCP) in a client-server architecture, such as SG-to-IP SCP. Its user would be TCAP, or another transaction-based application part.

There are other UA layers defined for ISDN (IUA) and V.5.2 (VUA). While important, these will not be covered in this article.

SCTP versus TCP
The stream control transport protocol (SCTP) is a new transport protocol defined by the Sigtran specification as a a replacement for TCP. SCTP is designed to cope with time-sensitive signaling data while remaining flexible enough for general use.

SCTP has been designed to counter some features of TCP that make it unsuitable for transporting real-time signaling data, such as:

• TCP is byte-streamed—TCP provides a single stream of data and guarantees that data to be delivered in byte-sequence order. This makes it ideal for delivery of large, unstructured pieces of data, such as a file or email message. TCP is particularly sensitive to delays caused by network errors cause by loss of bytes, messages or sequence violation. When this occurs, TCP will hold up delivery of all data (for all applications) until the correct sequence is restored. Because of this, data for one application may be delayed due to problems in transporting data from an unrelated application.
• TCP timers are defined in terms of many seconds. In particular, the length of the connection, keep alive, and retransmission timers may result in excessive delays.
• There are no inherent security features in TCP itself.

SCTP is very similar to TCP, but has a number of features which aim to overcome the limitations listed above. These include:

• It defines timers of much shorter duration than TCP.
• It supports multi-homing. Each SCTP endpoint may be known by multiple IP addresses. Routing to one address is independent of all others and, if one route becomes unavailable, another will be used.
• It uses an initialization procedure, based on cookies, to prevent denial of service attacks.
• It supports bundling, where a single SCTP message may contain multiple 'chunks' of data. Each chunk contains a whole signaling message.
• It supports fragmentation, where a single signaling message may be split into multiple SCTP messages in order to be accommodated within the underlying packet data unit (PDU).
• It is message-oriented, defining structured frames of data. TCP, conversely, imposes no structure on the transmitted stream of bytes.
• It has a multi streaming capability. Data is split into multiple streams, each with independent sequenced delivery. TCP has no such feature.

Multi-streaming is the main attraction. This feature allows users to partition a single IP connection between two endpoints into separate logical streams of data, assigning each stream to a particular application or resource. The principle is that errors or delays on one stream will not interfere with normal delivery on another.

Consider the example of SS7's ISDN user part (ISUP) protocol. ISUP carries signaling messages for many PSTN resources (essentially trunk circuits). If three calls are in progress, then one of the calls experiencing a loss of data should not cause a delay in transmission of messages relating to another call. Figure 2 shows a situation where ISUP is carried over TCP. A single 'pipe' of data carries all ISUP messages for all three calls.

Figure 2: Diagram illustrating the transport of three ISUP messages over a TCP link.

If the establishment messages for all three calls are received correctly, then the calls are in progress. If the calls are then released in the same order, but the release message for Call 1 is lost, then the release messages for the other two calls will be delayed while TCP recognizes the loss of the message and recovers the data. This has the potential to delay the release of Calls 2 and 3 for a large number of seconds, which is unacceptable in today PSTN world.

Consider now ISUP carried over SCTP. This is shown in Figure 3.

Figure 3: Diagram illustrating the delivery of ISUP messages over SCTP.

In this case, loss of a message relating to Call 1 affects only that stream of data. Calls 2 and 3 are serviced as normal.

The Four UA Layers
The Sigtran protocol defines four UA layers: the M2UA, M2PA, M3UA, and SUA. All four of these layers service a common purpose: to carry a higher layer's protocol messages from the point of termination in the SS7 network, over an IP network, to the point of presence of the higher layer itself.

Figure 4 is a generic depiction of where the UAs lie in the Sigtran architecture.

Figure 4: Diagram illustrating Sigtan's four UA layers.

The higher SS7 layer would be message transfer part level 3 (MTP3) or above (as described in the following sections) and would reside on either an MGC or an IP-SCP. The purpose of the Nodal Interworking Function (NIF) is defined by the UA in use. In general, it provides a mapping of management, data and control messages from the UA to the specific lower SS7 layer.

Let's take a look at each of the four user layers in more detail. We'll start with the M2UA layer.

1. The M2UA Layer
M2UA is used to transfer MTP2 user data between the MTP2 instance on a SG and the MTP3 instance on an MGC. As such, it operates a client-server model, where the MGC is the client and the SG is the server.

M2UA provides a means by which an MTP2 service may be provided on an MGC—in essence, extending SS7 into the IP network. Effectively, the MTP3 instance on the MGC is the user of the MTP2 instance on the SG. Neither MTP2 nor MTP3 are aware that they are remote from one another. This process, by which signaling messages are passed over IP from the top of one SS7 layer to the bottom of another, is described as backhauling.

The MTP3 user at the MGC would usually be ISUP. This architecture is most applicable when there is a low density of SS7 links at a particular physical point in the network (perhaps as low as one) and when there are a large number of physically separate SG functions (due to the SS7 links being physically located remotely from each other).

In this case, it makes sense to host MTP3 in the MGC. The SS7 address (the pointcode) of the system resides with MTP3. If each SG had its own MTP3 layer, a large number of pointcodes would be required to implement a (logically) single gateway.

2. The M2PA Layer
M2PA is the peer-to-peer equivalent of M2UA. 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 (with M2UA, one user is MTP3 and the other is an SG IWF). This is not typical of the overview given in Figure 4.

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.

The M2PA architecture is most applicable for a SG-to-SG connection, used to bridge two SS7 network 'islands'. In this case, each SG may connect to multiple other SGs, none of which need to know about the upper layer that they are supporting.

MTP3 is present on each SG to provide routing and management of the MTP2/M2PA links. Because of the presence of MTP3, each SG would require its own SS7 pointcode.

Replacing MTP2 links with M2UA is a distinct case from accessing an IP-SCP from an SG (the service provided by SUA). In the SUA case, it is known that the higher layer is TCAP and the SCCP services can be explicitly provided. M2PA, on the other hand, has no knowledge of the upper SS7 layer.

3. The M3UA Layer
M3UA is similar to M2UA, in that it operates in a client-server way to provide an upper layer SS7 with protocol remote access to the lower layers. M3UA, however, operates between an SG and an MGC, providing an MTP3 service on the MGC.

The MTP3 in the SG is unaware that the user is located on a different node. Similarly, the user layer at the MGC will be unaware that it is not served by a local MTP3. This is another example of the MGC backhauling signaling messages from the SG.

This architecture is most appropriate when there is a high enough density of SS7 links to make a standalone SG viable. It is also useful when the SS7 links are physically accessible at a single point.

Both situations highlighted in the paragraph above are common in North American networks, where the SS7 links are physically separate from the voice circuits. In this case, a number of links are gathered together into a single physical medium (for example, a T1 line). Here, each SG has a local MTP3 instance, and so must have its own SS7 pointcode.

4. The SUA Layer
SUA provides a means by which an application part (such as transaction application capabilities part [TCAP]) on an IP-SCP may be reached via an SG. The network architecture associated with SUA allows for multiple IP-SCPs to be reached via a single SG. The IP-SCP(s) do not have local MTP3 instances, and so do not require their own SS7 pointcodes (MTP3, and the pointcode, reside on the SG).

The functionality of SUA could be provided by M2UA or M3UA. However, SUA provides the mapping between SCCP addresses and IP addresses (at the SG). Without such a function, SCCP would have to be present at each IP-SCP and the external SS7 network would require knowledge of each such SCCP instance. SUA can abstract the presence of each IP SCP, thus providing one SCCP address to cover all nodes.

SUA is also flexible enough to support application parts running between two network nodes wholly within the IP network. This is particularly relevant to emerging networks, where there may be no need for an underlying 'traditional' SS7 network. In this case, the IP-SCP stack would be the same on both (IP based) nodes.