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.
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.
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:
- 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.
- 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.
- 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.
- 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.
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.
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 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 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.
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).
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.