You are on page 1of 127

SS 7 over IP (SIGTRAN) Siemens

SS 7 over IP (SIGTRAN)

1 Classical SS 7 3
2 Broadband SS7 23
3 SS7 over IP - Architecture 37
4 SCTP 65
5 MTP level 3 User Adaptation 103

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

2 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

1 Classical SS 7

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

1.1 SS 7 Network Architecture and Protocols

The standard signaling system in telecommunications is the common channel
signaling system No. 7 as it is specified by ITU-T (or in some modified way by ANSI).
The historic success of SS 7 comes from its high flexibility with respect to new
applications and environments. On the other hand the classical SS7 using time
division multiplexed signal transmission like PCM has very stringent restrictions
concerning the transmission capacity (typically 64 kbps for one signaling link on a
PCM30 line) and also the configuration of a time division multiplexing transport
network is heavily dependent on the physical topology of the network. With new
versions of SS7, namely High-Speed SS7 and SS7-over-IP, it is tried to overcome
these two limitations.

Let us first consider the basic network architecture of classical SS7 that will hold on in
the new, more powerful systems. The network elements in SS7 can have two of the
following basic functionalities:
Signaling Point (SP) : A signaling point SP is source and/or destination of
signaling messages. In other words the user applications of the signaling system
reside within the signaling points.
Signaling Transfer Point (STP) : A signaling transfer point STP does not
terminate or produce signaling messages. Instead it is used to forward a received
message to a SP for message consumption or to a STP for further routing.
A SS7 network element can of course combine these two functionalities or can
implement only one of them.

As the main task of a signaling transport system is to sent a message from its
originator to its destination, there must be an addressing scheme provided by the
signaling system. In case of SS7 every SS7 network element is identified by a
Signaling Point Code (SPC). The SPC is usually 14 bit (ITU-T) or 24 bit (ANSI or
modified ITU-T). The addressing space is flat for ITU-T defined SS7.

To interconnect SS7 network elements a set of signaling links is configured

between them. A signaling link in classical SS7 is formed by a timeslot on a PCM
system running with 64 kbps (analog lines are possible too with 4.8 kbps). All the
signaling links between two network elements are denoted as signaling link set.
The standard restricts the number of signaling links within one signaling link set to 16.
Some vendor specific mechanisms can extend this.

Routing of signaling messages in SS7 is done hop-by-hop. This means, that a

signaling message starting at SP A for SP B is routed by the SS7 protocols in SP A
either towards STP T1 or STP T3. The selection depends on a load sharing scheme.
The two possible ``next hops correspond to two possible link sets LSET A1 and
LSET A3. They are called the possible routes from SP A to SP B. To select one of
the routes and a signaling link within the link set associated with this route is all that
SP A has to do.

4 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

If STP T1 has been selected, then the same story begins again. But now STP T1 has
the two possible routes via STP T2 (LSET 12) or STP T3 (LSET 13). STP T1 selects
again one of the routes and a signaling link within the associated link set. This is the
way the message is routed on every hop (STP).


T1 T2



Link 1
Link 2 LSET A3

Fig. 1 Classical SS7 network architecture and basic routing principles.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The protocol stack of classical SS7 is formed according to the 4 level model. This
model divides the tasks of signaling transport into a hierarchy of four layers. The
basic transport protocol of SS7 is the MTP (Message Transfer Part) forming the
three lowest layers in this model:
MTP level 1 (Signaling Link) : Level 1 of MTP defines the transmission
characteristics for bits on the physical level. So it describes a very raw transport
service. For classical SS7 the MTP level 1 is coincident with the specification of
PCM 24, 30 or 120 for digital transmission lines. A signaling link is required to
provide 64 kbps in this case, in other words a signaling link corresponds to one
timeslot on a PCM system.
MTP level 2 (Signaling Data Link) : In contrast to level 1 which cares about bits
and bytes, MTP level 2 is already message oriented and therefore introduces
frames (so called signaling units). The aim of MTP level 2 is to enhance the raw
bit transport service of MTP level 2 especially with reliability. Hence MTP level 2
enable error detection with a check sum and error correction by automatic
requested retransmission in case of detected failures. MTP level 2 restricts the
size of a higher layer data unit to a size of less than 273 octets.
MTP level 3 (Signaling Network) : MTP level 1 and 2 are individual for each
signaling link. In contrast to that MTP level 3 is common to all signaling links of a
SS7 network. The task of MTP level 3 comes in two big groups - signaling
message handling and signaling network management. Signaling message
handling functionality means nothing else than routing - selection of a route and a
link within the associated link set. Signaling network management deals especially
with failures of signaling links, signaling routes and restart of network elements.
MTP level 3 shall guarantee a working signaling network as long as possible.

The fourth level of the signaling protocol system is formed by the so called MTP User
Parts. User parts are the protocols that are typically used by the system specific
applications to trigger operations remotely (e.g. call set up in the next switch). But
since the arise of non-call related application also other transport protocols (e.g.
SCCP) can use MTP for their message transport.

6 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


User User ... User


MTP Level 3


Level 2 Level 2 Level 2


Level 1 Level 1 Level 1

... TS 5 ... TS 16 ... . . . TS 16 . . .

PCM line 1 PCM line 2

Fig. 2 Classical SS7 protocol suite.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

1.2 MTP Level 2 Frames - Signaling Units

MTP level 2 defines three basic frame formats that are called signaling units.
LSSU (Link Status Signaling Unit) : A LSSU is used by MTP level 2 to indicate
the status of the signaling link to the remote end. With this both nodes of the
signaling link can synchronize their link status knowledge - this procedure is also
known as link alignment. Link alignment is needed because of the retransmission
that is performed by MTP level 2. LSSU frames are purely related to MTP level 2
and can not be seen by higher layers. Furthermore a LSSU is always related to
one link, hence there is no routing information inside.
MSU (Message Signaling Unit) : The MSU is the data carrier of MTP level 2.
Protocol messages from user parts or signaling network management messages
from MTP level 3 are transported within. Therefore a MSU will usually contain a
routing information part that defines source and destination of the message (the
only exception of this rule are some link related network management messages).
FISU (Fill In Signaling Unit) : The FISU is an empty MTP level 2 frame. It is used
when no higher layer data has to be sent to keep the synchronization.

Some information elements are common to all three frame formats:

Flag (F) : The flag is used for frame delineation, so it marks beginning and end of
a signaling unit. The flag has always the unique value `0111 1110.
Backward Sequence Number (BSN) / Backward Indicator Bit (BIB) : BSN and
BIB are used for acknowledgement. The BSN indicates the number of the MSU
that is expected next. An alternating BIB indicates a negative acknowledgement,
whereas a constant BIB means a positive acknowledgement.
Forward Sequence Number (FSN) / Forward Indicator Bit (FIB) : The FSN is
the sequence number to label the MSU. For LSSU and FISU this has no meaning.
The FIB is used to indicate the start of a retransmission (reaction to negative
acknowledgement) when the FIB changes. A constant FIB indicates that new MSU
frames will come.
Length Indicator (LI) : The LI is used to discriminate between the three signaling
unit types. If LI=0 then we have a FISU, LI=1,2 means a LSSU. If LI>2 then a MSU
is meant. But if the MSU is longer than 63 octets, the length indicator will not give
the real length (that is what the flag is used for).
Check bits (CK) : The check bits form a 16 bit check sum over the signaling unit
from BSN up to excluding the CK field. Of course it is used to detect bit errors in
the transmission.

Additionally each signaling unit type contains specific elements. The FISU contains
nothing (empty frame). The LSSU contains a status field which is one or two octets in
length. The status field is used to indicate the status of the signaling link. The two
byte status field is used only in vendor specific environments. The MSU contains a
data part which contains the MTP level 3 data with either user part data or MTP level
3 network management messages. The size of the MTP level 3 data is restricted to
273 octets. Any longer message must be segmented by the user part itself.

8 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

MSU (Message Signaling Unit)

8 16 N*8 (274>N>2) 2 6 1 7 1 7 8
F CK MTP level 3 data A LI I FSN I BSN F

LSSU (Link Status Signaling Unit)

8 16 8 or 16 bits 2 6 1 7 1 7 8
F CK Status Field A LI I FSN I BSN F

FISU (Fill In Signaling Unit)

8 16 2 6 1 7 1 7 8

Fig. 3 MTP level 2 frame formats - signaling units.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

1.3 MTP Routing, Routing Label and Service Indicator

As already explained, MTP level 3 performs routing on a hop-by-hop basis. In other
words each MTP level 3 that receives a signaling message determines the next hop
only, but not the complete message path (although the message path is fixed
determined by the operator's network configuration). MTP when sending a MSU will
include a routing label and a service indicator octet (SIO).

The service indicator octet (SIO) is used to indicate the following two things:
Network Indicator (NI) : The network indicator enables to distinguish between
several logically separated SS7 networks. Specified are four different networks
(NAT 0, NAT 1, INAT 0, INAT 1). A network element can be part of any of these
networks simultaneously, this means that such a node would be an element of
multiple SS7 networks. Such nodes are typically used as gateway elements that
interconnect different networks.
Service Indicator (SI) : The service indicator (SI) distinguishes the different MTP
user parts on top of MTP level 3. Hence it is used by the receiving MTP of the
signaling destination to distribute the message to the correct user part.

10 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

MSU (Message Signaling Unit)

8 16 N*8 (274>N>2) 2 6 1 7 1 7 8
F CK MTP level 3 data A

User Part Message Routing Label SIO

SubService Service
Indicator Indicator

D C B A Network type
D C B A MTP User part
0 0 x x INAT 0
0 0 0 0 MTP network mgt.
0 1 x x (INAT 1)
0 0 0 1 MTP test & maintenance
1 0 x x NAT 0
0 0 1 1 SCCP
1 1 x x NAT 1
0 1 0 0 Telephone user part
0 1 0 1 ISDN user part
0 1 1 0 Data user part
0 1 1 1 Data user part
1 0 0 0 MTP testing user part
1 0 0 1 Broadband ISDN user part
1 0 1 0 Satellite user part

Fig. 4 MTP service indicator and network indicator.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The routing label of MTP level 3 is dependent on the MTP user part. But some
elements must be present:
DPC (Destination Point Code) : The DPC is the signaling point code SPC of the
destination of the message. It is the main element that is used for routing by MTP
level 3.
OPC (Originator Point Code) : The OPC is the signaling point code SPC of the
message source node. Optionally it can be used for routing in a manufacture
specific way. Usually it is not used for routing purposes but to identify the originator
in the message receiver.
SLS (Signaling Link Selection) : The SLS is a four bit value that is used to
organize the load sharing of signaling traffic towards the same DPC over all
available routes and signaling links within these routes. Especially MTP level 3
guarantees that messages with the same pair (SLS,DPC) from one OPC will
always take the same path through the network, except in case of network failures.

In case that call related messages are transported (ISUP or BICC) the CIC (Circuit
Identification Code / Call Instance Code) will also be part of the routing label. The
CIC is used to associated a user part message of ISUP or BICC to a speech trunk or

12 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

MSU (Message Signaling Unit)

8 16 N*8 (274>N>2) 2 6 1 7 1 7 8
F CK MTP level 3 data A LI I FSN I BSN F

User Part Message Routing Label SIO

4 14 14


12 4 14 14


Fig. 5 MTP level 3 routing label for non-call related and call related signaling protocols.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The message transfer from the originator user part to its peer destination is running in
the following way:

1. The MTP user part creates the signaling message on request of an application
process. The newly formed message is then packed into a MTP-Transfer
Request primitive. The primitive contains the user message together with DPC
and SLS.
2. When MTP level 3 receives the MTP-Transfer Request primitive it will analyze
the routing information DPC and SLS. The DPC usually leads to a table of
possible routes that are configured for this DPC. Using the value of the SLS and
a load sharing key one of the possible routes is selected. With this route a certain
link set is associated.
3. Next the MTP level 3 has to select a signaling link within the selected link set. For
this purpose again the SLS is used. Another load sharing key together with the
SLS will select one of the configured signaling links within the link set. Now the
message will be forwarded to the MTP level 2 of this signaling link.
4. The MTP level 2 of the signaling link creates a MSU frame and includes the user
message, DPC, SLS, OPC and SIO. OPC and SLS will come directly from MTP
level 3, because each user part uniquely belongs to one OPC and network
indicator. The service indicator is set by MTP level 3 according to the higher layer
protocol. Now the message is forwarded to the signaling link and will be
transported bit by bit.

5. On the receiving side the MSU frame will be removed by MTP level 2 and the
MSU will be acknowledged.
6. Now MTP level 3 will check whether the DPC of the message is the SPC of this
node. If not the message will be forwarded to routing to the next routing process
to find the next hop (only when STP functionality is provided). If the DPC is the
SPC of this node, then MTP level 3 will analyze the service indicator within the
SIO and distribute the message to the correct user part with the MTP-Transfer
Indication primitive which also includes the OPC of the message.

14 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

MTP User MTP User

MTP-Transfer.Request MTP-Transfer.Indication
(DPC, SLS, (OPC, user message)
user message)

MTP Level 3 MTP Level 3

(DPC,SLS -> Link No.) (DPC=SPC) Routing

L2 L2 L2 L2 L2 L2 L2 L2
... ...
L1 L1 L1 L1 L1 L1 L1 L1


Fig. 6 Internal routing process within MTP level 3.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

1.4 Routing between different networks - SCCP

Global Title Translation
As the MTP protocol suite was defined the only real application was call-related
signaling for TUP (Telephone User Part) or ISUP. In call related signaling
applications the call is set up segment by segment. Of course each segment lies
completely within one network, there is no need for signaling across network borders.
This picture has changed completely with mobile communication and roaming.

The MTP cannot route across network borders, because the signaling point codes
are unique within one network only. So it can easily happen that two network
elements in different networks are assigned the same signaling point code.

16 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


04-3-03-7 05-3-14-3
06-4-14-2 02-5-09-1


MTP cannot route directly

between two networks.

Fig. 7 Connection of two MTP networks - inability to route across the network borders.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

To overcome this limitation a new routing principle has been introduced into SS7 very
early - Global Title Translation (GTT). GTT is implemented into the protocol SCCP
(Signaling Connection Control Part) which is part of SS7 in general. SCCP can
use so called global titles as routing addresses. Famous examples of global titles are
ISDN numbers, MSISDN numbers or the IMSI of GSM/UMTS. A common property of
all these numbers is that they have a structure that allows to indicate country and
operator (network).

The global title translation is a different routing approach than the MTP routing using
signaling point codes. The MTP routing uses the SPC (and SLS) to find a link where
the message is sent on. During global title translation the SCCP uses the global title
to find the MTP address (signaling point code) of the next SCCP translation point or
the address of the end point.

In detail this looks like the following:

1. An SCCP subsystem (SCCP user) issues a signaling message for transmission.

As destination a global title GT B will be specified. The SCCP that gets the
message will take GT B and look in its routing tables to find out the DPC of
another SCCP - DPC b. This DPC is of course in the same network as the
originator is in. Now we can send the message using the MTP services.
2. When the message is received in DPC b, it will of course be forwarded to the
local SCCP in this node. The special thing of the intermediate node is that it is
part of two networks. SCCP will be able to connect both. Simply the SCCP takes
the GT B again and performs a translation. In its routing tables it will find for GT B
the DPC 1 of the signaling end point in network 1. With this data the message is
again sent to the MTP.
3. MTP can now route the message to its destination because there is no network
border to cross anymore.

18 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Network00 Network



GT B -> DPC 1, network 1

GT B -> DPC b

User message



Fig. 8 Global title translation to have signaling across network boundaries.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

1.5 MTP requirements

Classical SS7 is one of the most reliable systems for signaling exchange. Since
nearly 30 years it is used in fixed line, circuit switched telecommunications. Also the
most successful telecommunication system GSM makes wide use of SS7 within the
switching subsystem and in the base station subsystem. No wonder that even UMTS
utilizes SS7.

The reliability of MTP within SS7 is described by the following items:

Message Loss: There should be no more message loss than 1 out of 10E7.
Sequence Error: No more than 1 out of 1E10 message may be delivered out of
Residual Message Error : No more than 1 out of 1E10 message error may be
Downtime: A signaling route to a DPC must not be more than 10 minutes
unavailable per year.
Round Trip Delay : Between sending and acknowledgement of a MSU there shall
be no more than 500 1200 ms.

These reliability requirements are very hard and of course they lead to high overhead
in the communication (frame headers) and to high costs in development and
hardware. Even worse in many situations and applications such a stringent demand
for reliability is not needed.

These facts together with the already mentioned drawbacks of limited capacity,
limited message size and low flexibility concerning network configuration leads to the
development of modification of SS7 using newer (maybe cheaper) transmission
technology like ATM and IP.

20 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SS 7


Round Trip Delay : 500...1200 ms


Message Loss : 10E-7

Sequence Error : 10E-10

Residual Message Error : 10E-10
Max. downtime of signaling route: 10 min/year

Fig. 9 Performance requirements of SS7 to MTP.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

22 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

2 Broadband SS7

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

2.1 Generalized Protocol Model

The historic evolution of (circuit switched) telecommunication systems brought a clear
separation of signaling and data transport. In case of ISDN/GSM this can be seen by
the fact that the operator has to configure a timeslot either to be a signaling link or to
be a speech trunk. This separation reduces the flexibility concerning resource
utilization drastically, (for example there may be speech trunk timeslots empty, but
they cannot be used for signaling if needed).

Since the arise of IP this dogma of separation vanishes more and more. In IP
networks a common transport network layer (IP) serves signaling and user data
transfer request in the same way. Especially the IP layer does not distinguish
between signaling and user data, there is no distinguished service for this. The same
concept is implemented also in ATM.

As the old OSI reference model (7 layer model) considers the signaling part only, it is
no longer sufficient. A new model is needed and provided by ATM specification. We
present a more detailed model than the ATM model. This more detailed model comes
from UMTS specification and has the following elements.

The model is horizontally and vertically structured:

Plane : A plane in principle describe a complete protocol stack for a certain task
on the interface. Three plane are defined :
Control Plane : The control plane contains all pure signaling protocols that
provide system specific procedure control.
User Plane : The user plane contains protocols that provide transport services for
user data (which means data that has no control relevance for this interface).
Network Control Plane : The network control plane is used when user data
bearer services shall be set up and released dynamically. In this case a special
transport network related protocol provides the procedures for dynamical control of
bearer services(In UMTS this protocol is called ALCAP = Access Link Control
Application Part).
Layer : Layers are the horizontal ordering of the protocol model. The two main
layers are the Transport Network Layer which is responsible for the transport
services and the System Specific Layer which contains the protocols that are
relevant for the system only.
The Transport Network Layer contains two common protocols, namely the physical
transport layer and the Transport Network Protocols. They provide a common data
transport system used for signaling and data transfer. The offered transport service is
very raw and may not be good enough for any application. Therefore the transport
system shall offer bearer protocols which in case of ATM are called Adaptation
Layers. These adaptation layers enhance the raw transmission service with further
functionality needed by applications. For instance for signaling very often a reliable,
sequenced transport service is needed. In contrast to that for a circuit switched user
data stream reliability may not be important, but a very strong timing requirement

24 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

must be fulfilled. A last element of the Transport Network Layer is the signaling
protocol for dynamical bearer configuration.

Control Plane User Plane

(User) Data Streams

Application Specific
Parts Network Layer
(system specific)
Control Plane

Bearer Control

Signaling Bearer (User) Data Bearer Transport

Protocols Protocols Network
Transport Network Protocol

Physical Transport System

Fig. 10 Generalized protocol model for common data transport networks (UMTS - UTRAN protocol model).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

2.2 ATM - Asynchronous Transfer Mode

ATM allows a very flexible network configuration with the concept of virtual
channels. A virtual channel is an end-to-end layer 2 connection between two ATM
end-points. The virtual channel has a predefined path through the ATM network that
will be defined during set up.

The switching of such a virtual channel in ATM is done link-by-link using Virtual Path
Identifier (VPI) / Virtual Channel Identifier (VCI). When an ATM cell is sent by an
ATM switch it will contain VPI/VCI in its cell header. The receiving ATM switch will
analyze VPI/VCI and look up in a table (for the corresponding input port) and find out
the VPI/VCI for the next link and the associated output port. This is what is called
ATM switching. The advantage is that it can be implemented near to the hardware,
and so it is very fast. With this concept it is possible to configure end-to-end links
over very big distances. Also this kind of switching is completely transparent to higher
layers. Thus a very flexible network topology can be obtained from ATM.

But the virtual channel that is established in this way is a low level transport service
only. To make the virtual channel suitable to the application's need, every virtual
channel is assigned to a special adaptation layer. The adaptation layer describes the
transmission characteristics.

The ATM cell is the transport frame of ATM. On the physical link a constant
(synchronous) cell stream is running all the time. ATM will multiplex all virtual
channels that go over this link to this cell stream. The asynchronous component of
ATM is now, that there is no fixed timing scheme for the multiplexing. Instead ATM
will schedule the different virtual channels according to the quality of service profile
and their traffic volume. This concept allows ATM to serve variable bit rate services,
but you can never tell which ATM cell will carry which virtual channel data.

When we will use ATM for signaling transport it is necessary to note that ATM can
discard cells and can disorder cells in case of fail-over procedures. For SS7 user
parts such a behavior cannot be accepted. Thus we will need very special adaptation
layers for SS7 signaling transport over ATM.

26 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Virtual Channel

ATM user ATM user

Incoming Outgoing
AALx VPI VCI Input Port VPI VCI Out. Port AALx
1 1 A 2 2 B
... ...

VPI 1; VCI 1 VPI 2; VCI 2

Virtual Link Virtual Link

48*8 8 1 3 16 12

ATM cell Payload HEC L PT VCI VPI

Fig. 11 ATM - virtual channel concept and ATM cell. (PT = Payload Type, CLP = Cell Loss Priority, HEC = Header Error Check).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

ATM currently defines four different adaptation layers to enhance the basic
transmission service and to describe the ATM user traffic characteristics (Quality of
Service). These four adaptation layers are called AAL (ATM Adaptation Layer) and
are labeled in the following way:

AAL type 1 (AAL1) : AAL1 is a stream oriented transport service, so there no

message or frame boundaries of the ATM user preserved during transmission. The
traffic characteristics of AAL1 virtual channel is that of a constant bit rate stream.
The virtual connections are usually purely point-to-point. AAL1 enables a
synchronous transmission of ATM networks and is widely used for ISDN speech
AAL type 2 (AAL2) : AAL2 is like AAL1 stream oriented, but supports streams that
run on a variable bit rate. AAL2 become more and more important and is expected
to completely substitute AAL1 in future. AAL2 is very interesting for speech codecs
with voice inactivity detection or for multi-rate codecs (AMR) like the ones used in
AAL type 5 (AAL5) : AAL5 is a message oriented protocol (but can also support
stream oriented services). This means AAL5 is very suitable when the ATM user
produces data in forms of messages or frames. Also AAL5 supports variable bit
rate streams, but is especially adopted to handle traffic that comes in bursts. AAL5
virtual channels are usually point-to-point, but can also configured for point-to-
multipoint topology.

Additionally ATM defines AAL type 3/4, but we will not need it here. The AAL5
service is very suitable for signaling transport, but AAL5 does not give any reliability
(backward error correction).

28 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

ATM virtual channel transport characteristics

(ATM Adaptation Layers)

AAL type 1 AAL type 2 AAL type 5

-stream oriented -stream oriented -message oriented

(stream oriented possible)

- constant bit rate - variable bit rate - variable bit rate

- bursty traffic
-Point-to-point -Point-to-point
(connections) (connections) -Point-to-Point
- Point-to-Multipoint

Fig. 12 ATM adaptation layers and their properties.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

2.3 SS7 transport over ATM

To transport SS7 signaling messages over ATM one searches for a way with minimal
amount of changes in already existing protocols. The easiest way doing this is the

Broadband SS7 will keep the basic architecture of SS7 networks and will substitute
the PCM timeslots by ATM virtual channels. Therefore the main protocol of
broadband SS7 is still

MTP3B (MTP level 3 Broadband) : Main protocol of SS7 remains MTP level 3
with its functionality for message handling (routing and distribution) and signaling
network management. Only the network management is slightly modified to be
conform with the new transmission technology. Routing is still the same, except
the result of routing is no longer a timeslot of a PCM line, instead as result of a
routing process one will get an ATM virtual channel used for signaling transport.

The major change concerns MTP level 2 and level 1, because they do no longer
exist. Instead they are replaced by an ATM virtual channel with the following
signaling bearer protocols to adapt the ATM transfer service to MTP3B's needs.

AAL5 : The transmission characteristics of signaling coming from MTP3B is

obviously message oriented and the traffic is bursty. Hence AAL5 is used to adjust
the support of such traffic.
SAAL (Signaling ATM Adaptation Layer) : As already explained, AAL5 does not
provide reliability. This is the task of SAAL layer.

SAAL together with AAL5 characterize the virtual channel as a (virtual signaling link).
An interesting part of SAAL is its upper layer interface towards MTP3B. To keep the
basic implementation of a MTP level 3, SAAL offers exactly the same primitives as
MTP level 2. So there was no need to design a new MTP level 3.

30 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


MTP level 2/level3 interface


MTP Level 3 (Broadband) MTP Level 3 (Broadband)


... ...
5 5 5 5 5 5

(Virtual Channel)

Fig. 13 SS7 over ATM - concept and principles.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The SAAL layer mainly substitutes MTP level 2 and therefore overtakes the tasks of
it. In detail is is:

Reliable Message Transfer : This task splits into :

Message Delimitation : SAAL provides frames to delineate the messages.
Error Detection : AAL5 provides error check on transmitted SAAL messages and
reports errors that occur to SAAL.
Error Correction : In case of reported errors from AAL5 SAAL will trigger the
retransmission of the erroneous messages.
In-Sequence Delivery : SAAL applies a send sequence number N(S) for each
transmitted message, which is used for acknowledgement and retransmission, but
also to deliver messages in sequence.

Signaling Link Status Control : Like MTP level 2 also SAAL has to monitor the
availability of the remote end and has to observe the quality of the signaling link.
Signaling Link Error Rate Monitoring : SAAL counts the errors that occur on the
signaling within a certain time.
Alignment of Signaling Link : SAAL utilizes special link status messages to
synchronize the link status information with its peer protocol.

Flow control : SAAL is able to indicate load congestion information to its peer to
stop or enable sending of new data frames.

Within the SAAL DATA frame there will be the well known information elements of
MTP level 3, as there are SIO, routing label and data field. The MTP user data field
can have a length of up to 4096 octets. The SAAL protocol information is included in
the SAAL frame as trailer.

32 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SAAL tasks and functions, SAAL Sequenced Data PDU

Flow Control Local Congestion Indication

Signaling Link Status Control Signaling Link Error Rate Monitoring

Alignment of Signaling Links

Reliable Message Transfer Message Delimitation

Error Detection (performed by AAL5)
Error Correction
In-Sequence Delivery

24 4 2 2 0,8,16 or 24 <= 4096 octets 32, 40 or 44 8

N(S) A PL Padding User data SIO
Type R
Routing Label

PL : Padding Length
N(S) : Send Sequence No.

Fig. 14 Tasks of SAAL and SAAL data frame layout.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

2.4 Examples of Broadband SS7

ATM is currently wide spread used for circuit and packet traffic applications.

AAL 1 trunks for classical speech transmission: Many telecommunication

operators utilize ATM for their switch-to-switch connection. AAL1 is a good choice
for classical A-law or -law codecs. The protocol architecture shows the control
plane with B-ISUP (Broadband ISUP) over SS7. The user plane is formed by AAL1
virtual channels. Note that multiple speech calls can be bundled into one AAL1
virtual channel.

UMTS Packet Interface Iu-PS : In UMTS packet data will be transported from
RNC (Radio Network Controller) to SGSN (Serving GPRS Support Node). The
control plane is formed by the UMTS specific application part RANAP (Radio
Access Network Application Part), which is used to establish and release packet
bearers for a user's PDP context. RANAP utilizes SCCP over MTP over ATM. The
user plane to transport the packet data is formed by IP over AAL5. The IP layer
routes between SGSN and RNC. The GTP-U protocol is here to distinguish
between the PDP context data of several users.

UMTS Circuit Switched Interface Iu-CS : Between RNC and MSC the circuit
switched traffic is transported on the Iu-CS interface. This interface again uses
RANAP as control plane protocol. The circuit oriented user data uses a Iu User
Plane (Iu UP) protocol that provides special support for the UMTS speech codecs
over AAL2/ATM. The calls within the AAL2 virtual channels can be set up and
released dynamically, therefore a network control plane protocol is needed. On Iu-
CS this bearer control function is provided by the AAL2 Signaling Protocol, which
can set up and release calls within AAL2 virtual channels.

34 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

B-ISDN with AAL1 trunking Iu-PS interface (UMTS)

Iu Packet Bearer

B-ISUP AAL1 speech trunks






Fig. 15 Examples of broadband SS7 1(2).

Iu-CS interface (UMTS)

RANAP AAL2 SP AAL2 speech channels




AAL2 SP : AAL type 2 signaling protocol

STC : Signaling Transport Converter

Fig. 16 Example of broadband SS7 2(2).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

36 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

3 SS7 over IP - Architecture

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.1 SIGTRAN Network Architecture

SS7 over IP is the general term to describe how SS7 based application protocols can
send their message over an IP based transport network. SS7 over IP is specified by
IETF (Internet Engineering Task Force). The responsible group within the IETF is
called SIGTRAN (Signaling Transport). The initial problem triggering the creation of
SIGTRAN was to enable classical TDM (Time Division Multiplexing) networks to be
connected to IP networks for voice transport.

To enable voice transmission over general transport systems a new network design
approach is necessary. This new concept is generally described by separation of
concern. This term means, that the network is divided into levels dealing with a very
restricted task. Three levels are typically required:

Transport Network Plane : The transport network plane deals with the transport
of bits only. Special tasks of the transport plane are to handle access related
things. The transport network can be homogeneous (one transport technology) or
heterogeneous (multiple transport technologies).

Network Control Plane : The network control plane has the responsibility to
control the transport network. In other words the network control plane shall handle
the logical set up of transport bearer services within the transport network plane for
circuit switched calls or packet sessions. The classical call control and session
management is implemented here. The control of the transport network should be
done in a bearer independent fashion, to enable easy exchange of the transport

Application & Service Plane : The services offered by the network control plane
together with the transport network plane are very basic (call/session). To enable
sophisticated user services possibly with user specific components or provider
specific features additional functionality is needed. This is what the application &
service plane gives us. These functionalities shall be combined here. Examples for
entities in this plane are SCP (Service Control Point) for intelligent network IN,
CSE (CAMEL Service Environment) for mobile IN, HLR (Home Location Register)
for GSM/UMTS subscriber data.

In this architecture there is signaling between the planes and within the planes.
SIGTRAN especially deals with the signaling exchanged within the network control
plane and between network control and transport network plane.

38 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

application server/
service data bases

Application/Service Plane

Network Control Plane

Transport Network Plane

Fig. 17 Network model for Separation Of Concern.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The functional model of SIGTRAN reflects the network model described above, but
considers network control and transport network plane only. The functional model is
composed out of three basic elements:

Signaling Gateway (SG) : The signaling gateway has the task to terminate one
signaling system and to relay the higher layer signaling message to another
signaling system. In case of SIGTRAN a SG will typically terminate either classical
or broadband SS7 and map it to SS7 over IP. The signaling can be forwarded from
a SG either towards other SGs or to a MGC (Media Gateway Controller).

Media Gateway (MG) : A MG is a pure transport network entity. It usually has

three tasks. First a MG can relay from one transport technology to another (for
example from PCM to ATM or IP, etc.). Second a MG can make a media format
conversion. This can be for instance a codec conversion (e.g. from A-law codec to
AMR codec of UMTS/GSM). Third a MG performs switching/routing functionality.
MGs next to pure routers and switches form the transport network control plane.

Media Gateway Controller (MGC) : The MG alone will of course not know which
type of transport service is needed for a certain application. To configure the
media stream bearer service in the MG is the task of the MGC. The MGC is in the
network control plane and can be considered as the logical part of a switch, MSC
or SGSN. In UMTS Release 4 also the name MSC Server and SGSN Server is
applied for the MGC. So the MGC performs call control and session management.
To map the logical control into physical bearer services there is signaling between
MGC and MG, but also between MGC and MGC. If the call/session signaling is
initially coming from a TDM network, the signaling for call control/session
management is also coming or going to the SG.

40 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

signaling signaling signaling


signaling signaling


signaling signaling

media stream

Fig. 18 SIGTRAN functional model.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.2 Implementation Scenarios for Connection Control

The following figures will gives some standardized examples (RFC 2719) about
possible implementations of the SIGTRAN functional model for the control of
connections or sessions. These scenarios should be considered as guidelines.

3.2.1 SG, MGC and MG in individual physical units

One possibility is to build for every function, SG, MGC and MG an individual
hardware device. This has the advantage of maximum flexibility, but the
disadvantage of enormous amount of signaling between MGC and MG should be
carefully analyzed.

In this scenario signaling transport over IP occurs possibly in three different places.
This is between SG and MGC, between MGC and MG and between SG and other
entities, like other SGs. The call media stream coming from a PCM timeslot (speech
trunk, CIC) is terminated by the MG and is converted to a voice over IP system (like
RTP = Real Time Protocol).

A typical call set up coming from classical SS7 could have the following appearance.

1. The IAM (Initial Address Message; ISUP) is received via classical SS7 in the SG.
The SG relays the IAM to be transported over IP to the MGC.
2. The MGC receives the IAM and will process it. As result of the processing the
MGC should send an instruction to the MG to receive the incoming CIC and relay
(switch) it to the outgoing real time stream over IP.
3. If the switching is done, the MG will tell the MGC. Then the MGC can send a new
IAM to the next switch (or MGC).
4. In case the MGC connects again to a switch in the TDM network, it will send the
new IAM to a SG. The SG will pack this new IAM in a classical SS7 MSU and
send it to the next switch.

42 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SS7 Signaling
Signaling Link Transport MSU(IAM)




Stream MG Stream MG

Fig. 19 Implementation scenario for SIGTRAN MG, MGC and SG as individual physical units.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.2.2 MG and MGC in a common MGU

More typical is the implementation that follows now. Because of the big amount of
signaling between MG and MGC with its strong timing requirements, it is better to
integrate MG and MGC. The combined device is usually named MGU (Media
Gateway Unit). Of course the signaling between MGC and MG is now internal and
its implementation is left to the vendor. It is even possible to tightly integrate MG and
MGC such that no longer any explicit signaling between them. This is very similar to
the classical switch architecture as we used to have it since 30 years.

The only signaling transport over IP that is left to have is between SG and MGU and
between SG and other SGs.

44 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SS7 Signaling
Signaling Link Transport



Media Media
Stream Stream

Fig. 20 Implementation scenario for SIGTRAN - MG and MGC combined in a MGU.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.2.3 Backhaul Mechanism

In the first two examples signaling and media stream data have been transported via
different transport systems. Especially with channel associated signaling this is
usually not the case, instead signaling and media stream share a physical medium.
For this case there exists an implementation scenario called backhaul mechanism.

The key point of backhauling is, that the physical media is terminated in the MG. So
the idea is to place the SG directly next to the MG in a MGU. Only the MGC is
external (but could also be integrated of course).

The task of the SG in the MGU is to separate the SS7 signaling from the physical line
(PCM), perform the signaling transport conversion to IP and send the signaling to the
MGC. Between MGC and MG one can again have signaling transport with SIGTRAN
or not.

46 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling MGC

Signaling Link Signaling

Media MGU Stream

Fig. 21 Implementation scenario for SIGTRAN - backhaul mechanism.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.2.4 Cross Connection of Signaling Links

Another implementation scenario dealing with the fact that in classical
telecommunication networks signaling and user data share the physical medium is to
deploy a cross connect in the MG.

Again the physical medium is terminated in the MG, but the signaling must now be
forwarded towards the external SG. This forwarding is done by the cross connect. On
the link between cross connect and SG the SS7 data is directly transported without
using SIGTRAN. SS7 over IP is used between SG and MGC and possibly between
SG and other SGs.

The cross connect scenario is also very suitable to be used when converting from
broadband (ATM) to IP. In this case the cross connect would simply terminate all
signaling virtual channels, whereas the MG terminates all virtual channels carrying
speech data.

48 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens





Signaling Link

MG Stream

Fig. 22 Implementation scenario for SIGTRAN - cross connection of SS7 links to the SG.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.3 Implementation Scenarios for data base access or

All examples before dealt with the question how to transport signaling for call control.
One of the reasons for the success of SS7 is that it is easily adapted to the needs for
applications that require remote data base access and intelligent network.

Also SIGTRAN can easily extend its SS7 signaling transport capabilities for data
base access and IN. Access to data bases (e.g. HLR) or IN (e.g. SCP) can come
either from a MGC or from outside the IP network. In the latter case the SS7
signaling messages are consumed by the SG and then transported via IP to the data
base or SCP and vice versa. If a MGC accesses a SCP or data base, this could be
done using SS7 signaling transport over IP or using protocols directly designed for

Another possibility is that a MGC needs access to an external (outside IP) data base
or SCP. In this case the SS7 messages for the corresponding communication is
transported between SG and MGC using SIGTRAN and the SG then handles the
communication over classical/broadband SS7 towards data base or SCP.

50 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SS7 Signaling
Signaling Link Transport Data Base


Media Media
Stream MG Stream

Fig. 23 Data base or SCP access using SS7 over IP.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.4 SIGTRAN Protocol Architecture

The SIGTRAN protocol architecture is designed for maximal variability and
extensibility. The basic architecture is formed by three general layers:

Transport Layer : The transport layer shall be a standard transport protocol that is
used in unmodified way. The requirements are very low level. To be exact, what
standard IP offers is enough. So the transport layer must provide an unreliable
datagram service, no sequence control and no reliability is requested.

Common Signaling Transport Layer : The common signaling transport layer

uses the raw transport layer services and enhances it with reliability and sequence
order control. In principle TCP could fulfill this, but when multiple signaling links
between the same endpoints are required TCP is not sufficient any more. Instead
SIGTRAN defines a new reliable transport protocols named SCTP (Stream
Control Transmission Protocol). SCTP serves signaling protocols with
transmission capabilities in a very general way.

SCN Adaptation Module : The users of SS7 over IP are the classical SS7 MTP
user protocols like ISUP, SCCP, BICC, etc. Of course nobody wants to make a
complete redesign of these protocols because of the modified transport
technology. Therefore user adaptation layers are placed on top of SCTP. These
adaptation modules will offer to the higher layer an emulated interface of a basic
transmission protocol. In the figure shown are two of them. M3UA (MTP level 3
User Adaptation) emulates MTP level 3 for MTP users. In contras to that SUA
(SCCP User Adaptation) offers the interface of SCCP to SCCP subsystems. In this
way one could implement emulations for arbitrary transport protocols.

On top of the SIGTRAN protocol stack the user protocols shall have the feeling to be
in a classical SS7 environment.

52 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


M3UA SUA Adaptation Layer for Higher Protocols

SCTP Common Signaling Transport Layer

IP Transport Layer

Fig. 24 SIGTRAN protocol architecture.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

As already explained, the adaptation layers provide the same higher layer interface
as the protocol they try to emulate.

Currently a lot of adaptation layers are defined:

M2UA (MTP level 2) : M2UA allows to have a MTP level 3 in an IP environment.

M2UA simulates a signaling link over IP. Of course several of these M2UAs can be
created on a SCTP, they will then be used by MTP level 3 as signaling link.

M3UA (MTP level 3) : M3UA simulates MTP level 3 for MTP users. It avoids the
overhead coming from M2UA simulation of signaling links. Indeed M3UA allows to
configure a SS7 network in an IP world.

SUA (SCCP) : The SCCP User Adaptation layer offers the services of SCCP to
SCCP subsystems. SUA can avoid the overhead coming from M3UA or M2UA.
SUA is especially suitable for all TCAP users (e.g. for data base access or
intelligent network) and RANAP in UMTS.

IUA (ISDN Q.921) : IUA allows users of Q.921 transport services to send its
messages over IP instead of Q.921. The most important higher layer in this case is
Q.931 (DSS.1) that is used for ISDN call control at the user-network interface.

V5UA (V5.2) : V5UA allows to transport to backhaul V5.2 message over IP. V5UA
uses IUA for this transport.

The user adaptation layers currently are defined by the following specifications:
M2UA (RFC 3331),
M3UA (RFC 3332),
SUA (internet draft),
IUA (RFC 3057),
V5UA (internet draft).

The SCTP protocol is specified in RFC 2960, whereas the SIGTRAN framework can
be found in RFC2719.

As these requests for comment may be updated it is always advisory to look to and look for the latest specification of the SIGTRAN group.

54 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Higher Layer Protocols Higher Layer Protocols

(Service User) (Service User)

Low Layer Protocol
Adaptation Layer
(Service Provider) (Service Provider Emulation)



Fig. 25 Adaptation layers on top of SCTP.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.5 Protocol Configuration Scenarios

Several different protocol configurations can be applied depending on which user
adaptation layer is used. We will ourselves in this document to the most important
ones - namely M2UA, M3UA and SUA.

3.5.1 Usage of M2UA

When using M2UA then MTP level 3 must be implemented not only in the classical
SS7 world, but in the IP network part too. Thus the IP nodes that contain a MTP user
part will occur as regular elements of a SS7 network.

In the present case the SG must terminate MTP level 1 and MTP level 2 of a SS7
signaling link. The SG will then put the contained MTP level 3 data into a M2UA data
part and send it over SCTP/IP. The MTP level 3 data part remains untouched.
Therefore the IP node that should get the message must terminate the MTP level 3
for itself. Hence all the MTP routing and network management functions are
applicable not only for true SS7 network elements, but for IP nodes that will receive
SS7 messages too.

The translation from MTP level 2 to M2UA and vice versa is done by a non-specified
nodal inter-working function NIF.

56 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



user part user part


NIF : Nodal Interworking Function

Fig. 26 Protocol architecture for M2UA usage.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.5.2 Usage of M3UA

If M3UA is used instead of M2UA the picture drastically changes. The SG terminates
not only MTP level 1 and 2 but also MTP level 3. It relays the SS7 user messages to
M3UA over SCTP/IP. So the destination of SS7 messages within the IP network is no
longer part of the SS7 network. Only the SG proves to be a true SS7 network
element. It is task of the SG to analyze the routing info in incoming SS7 messages
and forward the message to the correct MGC/SG or data base. There is no routing
within the IP network of MTP anymore, only IP routing is applicable within the

In the first figure there is no SCCP in the SG. This means no global title translation
GTT is available at the SS7 / IP boundary.

58 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



user part user part

NIF : Nodal Interworking Function

Fig. 27 Usage of M3UA for SS7 signaling message transport in IP - no global title translation in SG.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

If there should be a need for global title translation in the SG, SCCP must be
implemented in it. SCCP can use MTP level 3 and M3UA in the same way, because
both offer the same higher layer interface.

60 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



Subsystem Subsystem



NIF : Nodal Interworking Function

Fig. 28 Usage of M3UA for SS7 signaling message transport - with global title translation within SG.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

3.5.3 Usage of SUA

The last option that shall be presented is the usage of SUA. SUA avoids to use any
MTP relicts and transmits SCCP messages directly over IP. SUA is currently (3Q
2002) not approved as standard.

If SUA is used the SG would have to terminate MTP level 1,2 and 3 and SCCP. The
SG translates SCCP messages into SUA frames. This should also allow to have
signaling connection end-to-end between a true SS7 node and an IP based network

62 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



Subsystem Subsystem


Fig. 29 Usage of SUA for SCCP subsystem message transport.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

64 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.1 Logical Architecture of SCTP environment

The main protocol of SIGTRAN is SCTP (Stream Control Transmission Protocol). It
replaces TCP because of some drawbacks, which are:
TCP is stream (byte) oriented, whereas signaling usually comes in messages. So
if a signaling protocol uses TCP it would need its own message delineation
TCP supports only one byte stream between two end-points per connection.
Especially if one or more bytes are missing, TCP will stop the delivery until the
missing parts are successfully retransmitted. This means a single error blocks the
whole stream. For signaling purposes usually multiple streams are needed that
should not block each other.
TCP works with single endpoint addresses only. But to have transmission
redundancy it should be possible to have the data streams between two signaling
endpoints shared between multiple IP addresses (multi-homed IP hosts).

SCTP overcomes these limitations with the following features:

Multi-stream support : Instead of connection like TCP we have SCTP
associations that describe the relation between two SCTP endpoints. Within an
association SCTP supports multiple unidirectional data streams (so called inbound
and outbound streams). Different streams do not block each other, but messages
within one stream are sent in-sequence.
Message oriented : Instead of a byte stream oriented transmission SCTP will
pack higher layer messages in a frame to separate them. So the higher layer
protocols need not to define their own message delineation.
Multi-homed host support : A SCTP association can be spanned across multiple
endpoint addresses. This allows to use multi-homed hosts. So redundancy can be
provided, when one address pair fails, another address pair possibly can take
To identify the association, SCPT will use port numbers like TCP or UDP.

66 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


SCTP user SCTP user

Association ... ...

Streams ... ...

SCTP port port ... port port ... port SCTP port

Multihomed IP Addr. IP Addr. IP Addr. IP Addr. IP Addr. IP Addr.
IP Host
IP Addr. IP Addr. IP Addr. IP Addr. IP Addr. IP Addr.
L2/L1 L2/L1 ... L2/L1 L2/L1 L2/L1 ... L2/L1

Fig. 30 SCTP - basic principles.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

SCTP introduces a new concept as equivalent of TCP connections. This concept is

the SCTP Association. A SCTP Association describes the relation between two
SCTP endpoints for the transport of several unidirectional streams in both directions.
At least one unidirectional stream between the endpoints in each direction must be
present. Maximal 2E16 = 65536 unidirectional streams in each direction are possible.
With respect to one endpoint the unidirectional data streams are categorized as
inbound or outbound streams.

The SCTP association is spanned across all IP address appearances of each

endpoint. This allows to have several IP links for the purpose of redundancy.

To distinguish between different associations SCTP assigns local port numbers.

When a frame is sent within an association the corresponding source and destination
port numbers of SCTP are contained. With this and the source and destination IP
address the receiving endpoint can find out which association the frame belongs to.
One association uniquely corresponds to one SCTP user.

68 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


Outbound Inbound
Streams Streams
IP IP user

Inbound Outbound

Streams Streams

SCTP port SCTP port

Fig. 31 SCTP associations and related inbound and outbound streams.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.2 SCTP Data Transmission

SCTP defines a two-stage mechanism for the transmission of SCTP user and SCTP
control data. This mechanism needs the following objects:
SCTP chunks : A SCTP chunk is the smallest portion of data that can be
transmitted. Two categories of chunks are known - Data Chunks or Control
Chunks. Data chunks are used to carry SCTP user data, whereas control chunks
are used by SCTP to provide acknowledgement of data chunks and pure SCTP
SCTP Packets : SCTP will not transmit each chunk individually. Instead SCTP will
bundle multiple data chunks within one SCTP packet that will be send within one
IP datagram.

SCTP packets shall have a size that does not exceed the path MTU (Maximum
Transmission Unit). This guarantees that there will be no IP fragmentation on the
way. If a SCTP user message is longer than the path MTU, then it will be segmented
by SCTP into several data chunks such that a formed SCTP packet with such a
chunk is not larger than the path MTU. The same holds for control chunks.

70 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

User Message

SEND(association id, stream id, msg,, ...)


Chunk Chunk Chunk

SCTP Packets

SEND(packet, Destination IP Addr,...)

to IP layer

Fig. 32 SCTP data transport - data chunks, control chunks and SCTP packets.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The SCTP packet has a relatively simple format. It contains the following information
source port number : The source port number is the local SCTP port number of
the originator of the packet.
destination port number : The destination port number is the local SCTP port
number of the destination of the packet. The sender of the SCTP packet will get
the local port number of the other side during SCTP association set up.
verification tag : A verification tag is allocated at SCTP association establishment
by both endpoints. Typically both endpoints select its verification tag using a
random number generator. When sending a SCTP packet the originator has to
include the verification tag allocated by the destination. The main use of
verification tags is to detect stale packets from previously released associations
and to detect blind masquerade attacks.
checksum : SCTP protects its SCTP packets with an ADLER32 check sum which
calculated over the whole SCTP packet (of course with check sum bits set to 0).
This enables SCTP to detect bit errors.
chunks : As already explained, SCTP can bundle several chunks within one
SCTP packet. The chunks follow after check sum one after each other.

72 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

16 16

source port number destination port number

Verification Tag


Chunk #1


Chunk #N

Fig. 33 SCTP packet layout.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.3 SCTP Internal Functions

The SCTP protocol provides several internal functions to handle the transfer of SCTP
user data and to manage SCTP associations.

Association Start Up and Clear Down : This function deals with the management of
SCTP associations. It controls the procedures for establishment and release of
Sequenced Delivery : SCTP guarantees the in-sequence delivery of SCTP user
messages that are transported within the same SCTP data stream. A stream
sequence number is used within the data chunks for this purpose.
User Data Fragmentation : If a user data message is too long (larger than path
MTU), then it will be fragmented into multiple data chunks.
Acknowledgements and Congestion Avoidance : SCTP assigns a TSN
(Transmission Sequence Number) to each data chunk for acknowledgement and
retransmission purposes. Only positive acknowledgements are given. To trigger
retransmission a retransmission timer is used (like TCP). Furthermore if the
acknowledgement of data chunks last too long, SCTP will perform a so called slow
start to avoid congestion.
Chunk Bundling : This function collects several data and control chunks and
bundles them into one SCTP packet.
Packet Validation : Before the chunks within a SCTP packets are processed, the
SCTP packet will be validated. This includes a check of the verification tag and
consideration of the check sum of the SCTP packet.
Path Management : SCTP will observe whether a destination is reachable or not.
Therefore a heartbeat procedure is used, which will test the remote SCTP.

74 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SCTP user

Upper Layer Interface

Sequenced delivery within streams

User data fragmentation


Start Up Acknowledgements and Congestion Avoidance

Chunk Bundling
Clear Down
Packet Validation

Path Management

Network Layer Interface


Fig. 34 SCTP internal functions.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4 SCTP Association Management

4.4.1 SCTP Association Main States
The following figure provides a simplified state machine diagram for SCTP
associations. Two main states are known:

CLOSED : In the CLOSED state the associations is not existing. Hence there is no
way to exchange data chunks.

ESTABLISHED : In this state the association is successfully established and can

be used for the transport of SCTP user messages within data chunks.

To go from CLOSED to ESTABLISHED a association set up is needed. The

association set up is performed by an explicit SCTP signaling procedure which is
triggered either remotely or from the local SCTP user.

The transition from ESTABLISHED to CLOSED is triggered by either a graceful or

ungraceful shut down. A graceful shut down is done via an explicit signaling
procedure and can be triggered remotely or locally. An ungraceful shut down is the
result from a failure.

76 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

local or remote
association request CLOSED

local or remote abort

ESTABLISHED local or remote shutdown

Fig. 35 Simplified main state diagram of SCTP.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4.2 Association Start Up Procedure

The startup of an association is done with a so called four-way handshake. The four
way handshake is used to avoid unnecessary resource allocation when the
association cannot be set up. This is important as countermeasure against resource

The association set up is done in the following way:

1. The requestor A of the association sends an INIT chunk, which is a SCTP control
chunk. This INIT chunk contains the randomly selected verification tag TAG_A.
Furthermore the INIT chunk contains the advertised receiver window size, the
number of requested outbound streams, the maximum number of allowed
inbound streams and the initial TSN. Optionally the IP addresses or host names,
the supported address types can be included. The verification tag of the SCTP
packet header must be set to 0.

2. B receives the INIT chunk and will process the it. B shall not fixedly allocate
resources for the requested association. Instead B forms a TCB (Transfer Control
Block) and encodes this TCB with an internal electronic signature as state
cookie. This cookie together with the verification tag TAG_B of B, advertised
receiver window size, number of requested outbound streams, number of allowed
inbound streams, initial TSN is send as acknowledgement within an INIT ACK
chunk. Optional a list of IP addresses or host names can be specified too.

3. The originator A will now return the received state cookie. For this the COOKIE
ECHO message is used. The COOKIE ECHO chunk may be bundled with the
first data chunks.

4. When node B receives the COOKIE ECHO message and detects that the state
cookie inside is its own (using the electronic signature), it will respond with
COOKIE ACK. With this the association is successfully established.

78 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


T1_init INIT
(Initialisation Tag : Tag_A)

(Initialisation Tag : Tag_B, state cookie)


(state cookie)


Fig. 36 Message flow for association set up.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4.3 Graceful Association Shut Down

The graceful shut down of a SCTP association is typically initiated by the SCTP user,
but can also be triggered by SCTP under some misbehaving circumstances. The
graceful shut down waits with the release of the SCTP association until all
outstanding data chunks are sent and acknowledged.

1. In one SCTP endpoint the SCTP user will send a SHUTDOWN primitive to
SCTP. SCTP shall now send all outstanding data chunks to its peer. The
initiating endpoint shall wait until all of its data is acknowledged.

2. Now the initiator of the shut down will have to send the SHUTDOWN chunk. The
SHUTDOWN chunk contains the cumulative TSN for acknowledgement. This
cumulative TSN indicates to the receiver of the SHUTDOWN chunk, which data
chunks have to be retransmitted.

3. Now the receiver of the SHUTDOWN chunk transmits all its outstanding data
chunks. The initiating side that sent the SHUTDOWN must acknowledge each
data chunk immediately and bundle the acknowledgement with a SHUTDOWN

4. When all outstanding data chunks are delivered and acknowledged, the receiver
of the SHUTDOWN shall send a SHUTDOWN ACK chunk. The initiator that
receives the SHUTDOWN ACK must now send the SHUTDOWN COMPLETE

80 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


(cummulative TSN acknowledgements)

send outstanding data chunks

acknowledge outstanding data chunks bundled

with SHUTDOWN chunk



Fig. 37 Graceful shutdown of a SCTP association.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4.4 Ungraceful Shutdown

A ungraceful shutdown is usually the result of a failure. In this case the SCTP
endpoint that detects the fatal failure sends an ABORT chunk with an abort reason.

82 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


(abort reason)

Fig. 38 Ungraceful shutdown of a SCTP association.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4.5 Heartbeat Path Management

To test whether the remote endpoint of an association is still available the heartbeat
procedure is used. This procedure is triggered when for a certain time no
communication happened via the association.

The procedure is simply done in the following way. The node that wants to test its
remote peer, sends a HEARTBEAT chunk. The HEARTBEAT chunk contains
heartbeat information that is specific to the sender. Typically it includes time and
destination address info.

The node that receives the HEARTBEAT chunk must return the heartbeat information
in a HEARTBEAT ACK chunk, if the association is considered to be open.

84 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


(heartbeat information = time info|destination address)

(heartbeat information)

(heartbeat information = time info)

(heartbeat information = time info)

Fig. 39 Heartbeat path management.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.4.6 Detailed State Diagram of SCTP Associations

The full state diagram of a SCTP association is shown below. Still the two main
states are CLOSED and ESTABLISHED. But additional intermediate states are

First in case of the SCTP that initiates the association set up the following
intermediate states are defined:
COOKIE WAIT : The association assumes this state when a local SCTP user has
requested the set up of the association. The local SCTP has sent the INIT chunk
and waits for the state cookie from the SCPT peer coming within the INIT ACK
COOKIE ECHOED : When the INIT ACK with the state cookie is received, the
local SCTP will send the COOKIE ECHO chunk and returns the state cookie with
it. The initiating SCTP will leave this state when the COOKIE ACK is received.
Afterwards the association is ESTABLISHED.
If the SCTP is not the initiator of an association it receives the INIT chunk in state
CLOSED, returns the state cookie in the INIT ACK and remains in this state. Only
when the COOKIE ECHCO chunk with the originally created state cookie is received,
the responding SCTP will react. This is done by sending the COOKIE ACK chunk
and noting that the association is ESTABLISHED.

Also for shutdown procedures some intermediate states are defined. For the initiator
of a shutdown the following holds:
SHUTDOWN PENDING : This state is assumed when the local SCTP user has
requested the shutdown of the association. As long as there are still data chunks
left for transmission or outstanding for acknowledgement, this state is kept. The
initiating SCTP will send all remaining data and possibly retransmit data chunks.
When no more data chunks are outstanding for acknowledgement, the initiating
SCTP has to send the SHUTDOWN chunk.
SHUTDOWN SENT : After the initiating SCTP has sent the SHUTDOWN chunk it
assumes this state. Still the remote SCTP can sent data chunks, the initiating
SCTP immediately must acknowledge it bundled with a SHUTDOWN chunk. The
initiating SCTP can leave this state either when it receives a SHUTDOWN chunk
from its peer or when it receives a SHUTDOWN ACK chunk. In the latter case
SCTP has to response with SHUTDOWN COMPLETE chunk. If it receives a
SHUTDOWN it is immediately clear that the association is CLOSED, there is no
need for any further message.
If the SCTP is not the initiator of the shutdown, then the following intermediate states
are defined:
-SHUTDOWN RECEIVED : This state is entered, when SCTP receives a
SHUTDOWN chunk from its peer. The local SCTP shall acknowledge all received
data chunks and transmit all outstanding data chunk. Furthermore it shall wait until
all data chunks are outstanding (e.g. not acknowledged).

86 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SHUTDOWN ACK SENT : When no more data chunks are outstanding, the local
SCTP shall send a SHUTDOWN ACK chunk to the initiating SCTP. When
SHUTDOWN COMPLETE (or SHUTDOWN ACK) is received the association shall
be terminated.

INIT ACK delete association
CLOSED [Associate]


send DATA chunks
send DATA chunks
no more data
SENT no more data

delete association | SHUTDOWN COM delete association | SHUTDOWN COM

Fig. 40 Association state machine.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.5 SCTP Data Transmission and Acknowledgement

4.5.1 SCTP Data Chunk Layout
SCTP data chunks transport SCTP user data. One data chunk can transmit an entire
higher layer message or a fragment of a higher layer message. It is obviously not
possible to combine several higher layer messages into one data chunk.

The following information elements are required in a data chunk:

Chunk Type : The chunk type is a common information element for all SCTP
chunks. This field is always the first octet in each chunk. For a data chunk the
chunk type must be set to 0.
U-bit: The U (Unordered) bit is used to indicate out of order data. This means
when U=1, then this data chunk shall immediately be sent to the SCTP user out of
B-,E-bit : B-(Begin) bit and E-(End) bit are used to control fragmentation of higher
layer data. If B=1, then this chunk is the first segment of a higher layer message,
otherwise it is not. If E=1, then this chunk is the last segment of a higher layer
TSN (Transmission Sequence Number) : The TSN is used as data chunk
numbering for acknowledgements. The TSN must be strictly increasing from data
chunk to data chunk within the association. This already indicates, that
retransmission and acknowledgement is done per association, but not per stream.
Stream Identifier : The stream identifier assigns this data chunk to exactly one
unidirectional stream of the SCTP association.
Stream Sequence Number : The stream sequence number is a sequence
number of the higher layer data. It enables SCTP to guarantee the in-sequence
delivery of SCTP user data. Note that data chunks that transport fragments of the
same higher layer message must have the same stream sequence number, but
will have strictly sequential TSN.
Payload Protocol Identifier : The payload protocol identifier is not used by SCTP.
But during association set up the SCTP user can provide a value for this field. Only
the value 0 is reserved by SCTP to indicate, that there is no payload protocol
identifier provided.

88 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

8 5 1 1 1 16

Chunk Type 0 reserved U B E Length


Stream Identifier S Stream Sequence Number N

Payload Protocol Identifier

User Data

Fig. 41 Data chunk - frame layout.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.5.2 SCTP Data Acknowledgement

SCTP knows positive acknowledgements only, in other words no negative
acknowledgements are given. For positive acknowledgements SCTP provides the
SACK (Selective Acknowledgement) chunk. The use of the SACK chunk is
SACK can be used to make a positive acknowledgement of data chunks, also
when there are transmission gaps (TSN gaps),
SACK can be used to indicate the reception of duplicated data chunks (duplicate
SACK can be used to update the senders receiver window size (receiver window

These three tasks correspond to the following SACK frame format:

Chunk Type : The chunk type for SACK is d3.
Cumulative TSN Ack : The cumulative TSN field specifies the last correctly
received data chunk before a gap begins. In other words all data chunks up to and
including the cumulative TSN are positively acknowledged.
Advertised Receiver Window Credit : With this field the sender of the SACK will
indicate how much receiver buffer is left. This information is used for congestion
Number of gap ack. blocks : This field indicates how many blocks of TSNs shall
be acknowledged, because of gaps.
Number of duplicate TSNs : This field informs how many data chunks have been
received twice or more times.
Gap Ack Block #i Start --- Gap Ack Block #i End : These two elements contain
the TSN of the begin and the TSN of the end of consecutively received data
chunks that shall be positively acknowledged. The TSN for begin and start are
given as offset values relative to the cumulative TSN.
Duplicate TSN #i : This is the TSN of the data chunk received multiple times.

90 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

8 8 16

Chunk Type 3 reserved Chunk Length

Cummulative TSN Ack

Advertised Receiver Window Credit

Number of Gap Ack Blocks (N) Number of Duplicate TSNs (M)

Gap Ack Block #1 START Gap Ack Block #1 END

Gap Ack Block #N START Gap Ack Block #N END

Duplicate TSN 1

Duplicate TSN M

Fig. 42 SACK chunk -frame layout.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.5.3 Retransmission Mechanism

As already stated, there is no negative acknowledgement provided by SCTP. Instead
a timer mechanism is implemented to trigger retransmission. The timer for this
purpose is called T3_rtx (retransmission timer). The initial timer value is labeled
RTO (Retransmission Time Out). The RTO value is not fixed, but will be calculated
as explained later on.

One retransmission timer T3_rtx can must exist at least for each address pair within
an SCTP association. It is of course possible to implement one T3_rtx per data
chunk, but this will not be considered here.

The principle of the retransmission handling is shown in an example on the next

figure. It works in the following way:
1. Node A sends a data chunk with TSN=1. Together with the transmission of the
data chunk SCTP starts T3_rtx for the associated address pair with the currently
valid RTO. Node B is not required to immediately send the acknowledgement
(delayed acknowledgement). Instead in the example node A sends another
data chunk, now with TSN=2. The retransmission timer is not affected by this.
2. SCTP is required to send acknowledgements for at least every second data
chunk. Hence node B sends a SACK and sets the cumulative TSN to 2, because
TSN=2 was the last correctly received data chunk before a gap (e.g. data chunk
for TSN=3 has not been sent yet).
3. When node A receives the SACK it will check which data chunks are
acknowledged with it. Because all outstanding data chunks are positively
acknowledged, node A will stop retransmission timer T3_rtx.
4. Next node A sends a third data chunk (TSN=3), so again T3_rtx is started with
the current RTO.
5. But this time no SACK is received, maybe the packet has been lost. So T3_rtx
expires and this will trigger the retransmission of data chunk TSN=3. The timer
T3_rtx is restarted, but the value of RTO is doubled or set to a default value
RTO.MAX if the doubled value exceeds this limit.

For the data transmission SCTP defines the priority such that control chunks have
the highest priority, then retransmitted data chunks will follow. New data chunks have
the lowest possible priority.

92 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


T3_rtx DATA
(TSN = 1)
(TSN = 2)

(TSN Ack = 2, no gap blocks, no duplicates)

T3_rtx DATA
(TSN = 3)

(TSN = 3)

Fig. 43 Retransmission example 1(2).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The second part of the example is shown on the next figure, it deals with the situation
when not all outstanding data chunks are acknowledged with one SACK.

1. In the case we consider now node A will send three data chunks TSN=1, ,
TSN=3 immediately after each other. Of course node A has to start T3_rtx with
the currently valid RTO.
2. Node B processes the received information but possibly receives data chunk
TSN=3 a little bit later. Thus node B sends a SACK chunk with cumulative
TSN=2. So TSN=3 will not be acknowledged yet.
3. When node receives this SACK it will detect that TSN=1 and TSN=2 are correctly
received, but TSN=3 is still outstanding. Therefore node A will restart T3_rtx with
the still valid RTO.
4. When node B has also received data chunk TSN=3, it will acknowledge it with a
SACK. When node A receives this, it can stop T3_rtx, because there are no more
outstanding data chunks.

94 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


T3_rtx DATA
(TSN = 1)
(TSN = 2)
(TSN = 3)
(TSN Ack = 2, no gap blocks, no duplicates)

(TSN Ack = 3, no gap blocks, no duplicates)

Fig. 44 Retransmission handling 2(2).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.5.4 RTO Calculation

To avoid unnecessary retransmission the RTO value will be updated by SCTP
according to the current network status. Basis of the update is the measured round
trip time R. The round trip time is the interval between sending of a data chunk and
reception of the associated SACK. SCTP will perform such measurements in a
regular way with new data chunks.

For the calculation SCTP uses two state variables:

SRTT Smoothed Round Trip Time = averaged value of round trip time
RTTVAR Round Trip Time Variation = averaged variation of the round trip
time relative to the SRTT

Additionally SCTP needs some parameters that must be given by the configuration:
RTO.Max An upper limit for RTO (default is 60 seconds).
RTO.Min A lower limit for RTO (default is 1 second).
RTO.Initial Initial value for RTO before the first measurement (default is 3
RTO.Alpha Weighting value for smoothing of round trip time to calculate
SRTT (default is 0.125).
RTO.Beta Weighting value for smoothing of round trip time variation to
calculate RTTVAR (default is 0.25).

The mentioned default values are given in RFC 2960 (SCTP). The calculation is done
in the following way.

Initialization : Before the first measurement of R it is set : RTO = RTO.Initial.

First Measurement : SCTP sets the following values after the first measurement
of R:

Further Measurements : For any further measurement of R we will get:

RTTVAR = (1-RTO.Beta) * RTTVAR + RTO.Beta * |SRTT R|
SRTT = (1-RTO.Alpha) * SRTT + RTO.Alpha * R

With these formulas peaks in the measurement of the round trip time R are neglected
(low pass filtering).

96 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens


(TSN Ack = 2, no gap blocks, no duplicates)

RTO = RTO.Initial
1st measurement


further measurements


SRTT := (1-RTO.Alpha)*SRTT + RTO.Alpha*R


Fig. 45 RTO calculation based on round trip time measurement.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The figure on the next page shows an example of measured round trip time R (solid
line) and the corresponding SRTT (dashed line).

98 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



RTO.Min = <1000 ms RTO.Max = <60000 ms RTO.Initial = 3000 ms

RTO.Alpha = 0.125 RTO.Beta = 0.25

Fig. 46 RTO (dashed line) and corresponding measured round trip time R (solid line).

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

4.6 SCTP Congestion Avoidance

Like TCP also SCTP uses a slow start mechanism to avoid congestion and to test the
network congestion level with respect to the possible data rates. The congestion
avoidance is controlled by selective acknowledgements and retransmissions.

For slow start control SCTP needs the following three variables:
cwnd (Congestion Window) The value cwnd indicates how many
bytes can be sent to the other side. cwnd is limited by the
currently applicable advertised receiver window of the remote
ssthresh (Slow Start Threshold) This value indicates when slow start
ends and normal sending speed is allowed.
rwnd (Receiver Window) This value describes how much buffer
space (in bytes) is left in the remote SCTP for reception of data

The advertised receiver window is updated with each SACK. Initially the value of
cwnd is set to 2*MTU, the value of ssthresh is initialized as high as possible (typically
to the initial advertised receiver window).

The local SCTP can send as many data as indicated by the minimum of cwnd and
rwnd. If rwnd = 0 then only one data chunk may be sent to test whether there is a
change in the rwnd value.

To probe the current network congestion status SCTP updates the values of cwnd
depending on its current value:
cwnd <= ssthresh This is the slow start case. Here SCTP will increase the cwnd
with every received SACK. cwnd will be increased by minimum
of either 1) path MTU or 2) acknowledged bytes (SACK).
cwnd > ssthresh In this case no slow start is performed any more. Instead cwnd
will be increased by MTO each round trip time.
no data to send If the SCTP does not have to send data it will decrease it cwnd
in the following way. Each RTO SCTP will set cwnd to the
maximum of either cwnd / 2 or 2*MTU.

100 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

In case of packet loss or retransmission time out, SCTP will decrease the values of
cwnd and ssthresh to react upon changed congestion status:
T3_rtx expiry In case there is no SACK coming and T3_rtx expires it is highly
probable that there is congestion. Hence slow start is triggered.
SCTP simply sets ssthresh = max (cwnd/2, 2*MTU) and cwnd =
SACK indicates Because the SACK is coming early enough (before T3_rtx
packet loss (gaps) expires), there is no congestion. SCTP does not trigger slow
start. Instead is set cwnd = ssthresh and ssthresh = max
(cwnd/2, 2*MTU).

SACK with
packet loss

cwnd T3_rtx
expiry SACK with
packet loss no further
data chunks to send

2* MTU



T3_rtx expiry : ssthresh = max{ cwnd/2, 2*MTU} cwnd = MTU

SACK packet loss : ssthresh = max{ cwnd/2, 2*MTU} cwnd = ssthresh

Fig. 47 SCTP congestion avoidance -slow start.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

102 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

5 MTP level 3 User Adaptation

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.1 M3UA Network Architectures

The most interesting protocol for SIGTRAN is currently M3UA, which emulates MTP
level 3. M3UA is currently used in two scenarios:
interconnection of classical or broadband SS7 networks with MTP users in an IP
interconnection of MTP users within an IP network without involving classical or
broadband SS7.

M3UA can use TCP or SCTP (preferred) as signaling link. In case of SCTP one
SCTP association will play the role of a signaling link.

5.1.1 Interconnection of SS7 and IP Networks

For the interconnection of SS7 with IP networks the signaling gateway (SG) plays a
crucial role. It is responsible to terminate the SS7 protocols and is thus part of the
SS7 network and the IP network.

The MTP user parts that are located in the IP network domain are denoted as ASP
(Application Server Process). Several ASPs are bundled in an AS (Application
Server). The application server AS is a pure IP network element and has to terminate
M3UA. But the AS cannot be directly addressed from the SS7 network, moreover a
SS7 node that wants to send a message to an ASP must direct it to the SG. The SG
can then select the correct ASP.

Between SGs there may be links established for redundancy such that one SG can
takeover the tasks of another in case of failures in SS7 or IP network.

104 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens



SS7 SP application

MTP user MTP user

MTP level 3 MTP L3 M3UA M3UA

MTP level 1 MTP L1 IP IP

Fig. 48 M3UA network architecture for SS7 / IP interconnection.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.1.2 IP Server Processes

The second scenario is used to connect MTP users that are all located in the same
IP network. In this case the MTP users are called IPSP (IP Server Process). M3UA
is used here to serve the MTP users with a standard MTP level 3 interface. Of course
no signaling gateway SG is involved here.

Message transport between IPSPs over M3UA can utilize TCP or SCTP (preferred).
Again SCTP provides the analogue of a signaling link. Because the SCTP
associations can be considered as end-to-end signaling links, there is no need for a
higher layer routing in M3UA.

106 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SCTP association over IP


MTP user MTP user


Fig. 49 IP server processes.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.2 M3UA Routing in Signaling Gateways

When M3UA is used to interconnect SS7 and IP network, there must be a routing
functionality in the necessary signaling gateway SG. Note that M3UA itself does not
provide the routing functionality of MTP level 3. Especially there is not signaling
transfer capability provided by M3UA. (This is not necessary, because SCTP
associations can easily be configured end-to-end.)

The first thing that must be observed is, that application server processes (ASP)
cannot be addressed with signaling point codes, as they are not part of the SS7
network. Instead each message that shall go to a ASP must be routed to a
corresponding SG. So the SG represents a whole group of ASPs for the SS7
network. When a SS7 message is received in a SG, it is task of the SG to route the
message to the correct ASP via the associated SCTP association.

For this routing the SG utilizes the following information elements:

Network Appearance (NA) : A SG can be connected to several SS7 networks
(even with the same network indicator). For each network the SG will define a so
called network appearance value (32 bit). This is used to distinguish the routing of
message with different network originations.
Routing Key (RK) : The routing key is a set of certain SS7 message parameters.
It is used to filter messages and assign them to a certain Routing Context, which
will define the ASP to which the message shall go to. Which SS7 parameters in
which combinations can be used as routing key is implementation specific.
Examples for these are DPC, OPC, SLS, CIC, SIO, SSN in any combination.
Routing Context (RC) : The routing context is the index for the M3UA routing
table to find the associated ASP and the corresponding SCTP association.

Routing in the opposite direction is simpler, because when an ASP issues a SS7
message for a node in the SS7 network the corresponding M3UA data frame will
contain all needed SS7 routing information for the MSU that will be created by the

108 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

SCTP Association 1
SS7 Network A

DPC, OPC, SLS, Routing Context

MSU Network Appearance Data
SS7 Protocol Info

SCTP Association 2

SS7 Network B Signaling Gateway

SCTP Association 3

Fig. 50 M3UA - MSU conversion in the SG and M3UA routing parameter.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The MTP user data is transported by M3UA using the Data message. This message
contains the higher layer user data and the MTP level 3 protocol data. In detail we
have the following information elements:
Version : The version field indicates the M3UA version, which is currently H01.
Message Class / Message Type : These two fields indicate the M3UA frame type.
For the DATA message this is two time H01.
Network Appearance : This 32 bit value is an indicator for the source/destination
SS7 network of the signaling message.
Routing Context : The routing context is a 32 bit value and is usually an index for
the routing table in the SG. It is associated with an ASP and its corresponding
SCTP association.
DPC / OPC / SLS / NI / SI : These elements are the MTP protocol data used for
routing and message distribution. (NI = network indicator, SI = service indicator).
MP (Message Priority) : M3UA allows to assign different priorities to individual
MTP user protocol data : Within this field the signaling message from the MTP
level 3 user is contained.
Correlation ID : The correlation ID is used for failure messages. It allows to
indicate errors in DATA messages later on.

(The parameter formatting in M3UA follows the TLV format. This means first comes a
TAG, then the LENGTH and last the VALUE. So the tag field that occur in the
message layout simply identify the parameter.)

Note that in case of M3UA usage between two IPSPs, there is usually no routing
context needed. This field has significance for signaling gateways only.

110 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Version (H01) spare Message Class (H01) Message Type (H01)

Message Length
Tag (H0200 = Network Appearance) Length (d8)
Network Appearance

Tag (H0006 = Routing Context) Length (d8)

Routing Context

Tag (H0210 = Protocol Data) Length (variable)

reserved for future use OPC

reserved for future use DPC

SI (Service Indicator) NI (Network Indicator) MP (Message Priority) SLS

MTP-user Protocol Data

Tag (H0013 = Correlation ID) Length (d8)

Correlation ID

Fig. 51 M3UA DATA message frame layout.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.3 M3UA Routing Table and Dynamic Configuration

5.3.1 MIB Routing Table
M3UA has to maintain a routing table in the SG. The SIGTRAN group of IETF
proposed a basic layout of this table as part of the MIB (Management Information
Base) for SNMP administration.

The important part for routing administration is formed by the following tables:
Routing Table : The routing table contains the routing contexts. The routing
context value itself is used as index for this table.
Application Endpoint Table : This table contains a list of all configured
(dynamical or static) ASPs.
Signaling Point Endpoint Table : This table is a list of all configured M3UA
endpoints. This table allows also to find the associated SCTP connection.

If routing is performed, the SS7 protocol information from the MSU the routing key is
derived. The routing key is used to find the associated routing context in the routing
table. Now the routing context contains a reference to an entry in the application
endpoint table. So one can find the application with a reference to a signaling
endpoint. The signaling endpoint entry now gives the SCTP association.

112 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Endpoint Table
SI, NI, OPC, Routing
DPC, CIC/SSN Table App. ID
. ...
RoutingKey Routing
Routing Contex

SpEp Table
Application ID SpEp ID
... Association ID

. to SCTP

Fig. 52 Routing relevant tables in M3UA according to MIB specification.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.3.2 Dynamical Routing Key Management

M3UA allows to configure the routing data base either statically via O&M or
dynamically from the application server AS.

When an AS wants to register a new routing key, it has to issue the M3UA message
Registration Request. This message contains a local routing key identifier (Local
RK-ID) which is used as reference number for the Registration Request. The rest of
the parameters of the Registration Request describe one or several routing key
configurations. The SG shall send a Registration Response message which
contains a registration result for each requested routing key.

The deactivation of routing keys works with the message Deregistration Request
and Deregistration Response.

114 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling Application
Gateway Server

Registration Request
(Local RK-ID, Routing Key 1, ..., Routing Key N)

Registration Response
(List of [Registration Result, Local RK-ID, Routing Context])

Deregistration Request
(Routing Context)

Deregistration Response
(List of [Routing Context, Deregistration Status])

Fig. 53 Dynamic registration of routing keys.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.4 Application Sever Process Management

5.4.1 Application Server Process States
To handle the remote and local application server processes a state machine is
implemented for each ASP. The state machine deals with two things. First it
describes the availability of the peer M3UA, second the state deals with the
availability of the ASP itself. The state machine covers three different states:

ASP DOWN : In this state the remote M3UA is not available. This can either mean
that there is no SCTP association possible or the remote M3UA cannot be
activated. ASP DOWN is the initial state of an ASP.
ASP INACTIVE : When this state is entered, the remote M3UA is available. So
also a SCTP association to this M3UA must exist. But currently there is no traffic to
the ASP itself possible, hence no M3UA Data messages will be exchanged.
Reason for this can be, that the routing keys are not configured yet.
ASP ACTIVE : This state indicates that the remote M3UA is available and also the
ASP is available. So M3UA Data messages can be exchanged.

The transitions between the ASP states are indicated by explicit M3UA procedures
that will be explained later on.

DOWN INACTIVE If an ASP is activated in a application server, it will indicate

that it is up.
ACTIVE DOWN If an ASP is deactivated in the application server, it will
INACTIVE DOWN indicate that it is down.
INACTIVE ACTIVE If all routing keys for an ASP it can indicate to the SG that it
is active and ready for use.
ACTIVE INACTIVE If an ASP wants to remove itself from signaling traffic, it can
explicitly indicate this. On the other hand an ASP is also
deactivated, when another ASP takes over the traffic for the
old ASP (ASP Override).

116 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

ASP Active

ASP Override
ASP Active ASP Inactive

ASP Down ASP Inactive


ASP Down

Fig. 54 ASP state machine.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.4.2 Application Server States

SCTP will also maintain a state for the application server depending on the ASP
processes. SCTP defines the following AS states:

AS DOWN : The application server AS is unavailable. All ASPs of this AS are in

state ASP DOWN.
AS INACTIVE : The application server AS is available but no application traffic is
active. No ASP is in state ASP ACTIVE.
AS ACTIVE : The application server AS is available and at least on ASP is in state
AS PENDING : The last active ASP has entered state ASP DOWN or ASP
INACTIVE. This is an intermediate state to perform a graceful shutdown of an
application server.

The following transitions are known:

DOWN INACTIVE One ASP in the AS enters state ASP INACTIVE.
INACTIVE DOWN All ASPs in the AS enter state ASP DOWN.
INACTIVE ACTIVE One ASP in the AS enters state ASP ACTIVE.
ACTIVE PENDING Last active ASP in the AS enters either ASP DOWN or
ASP INACTIVE. SCTP shall start a recovery timer Tr and
queue all data for this AS.
PENDING ACTIVE When one ASP in the ASP becomes again ASP ACITVE
before the timer Tr expires. SCTP shall forward all queued
data to this ASP.
PENDING INACTIVE If the recovery timer Tr expires, no ASP is in state ASP
ACTIVE, but at least one ASP is in state ASP INACTIVE.
SCTP shall delete all queued data for this AS.
PENDING DOWN If the recovery timer Tr expires, no ASP is in state ASP
ACTIVE and all ASP are in state ASP DOWN. SCTP shall
delete all queued data for this AS.

When SCTP changes the (remote) state of an application server AS, it will send a
M3UA message NOTIFY, which contains the new state of the application server.

118 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

one ASP transfers to ACTIVE

AS Inactive AS Active

Tr expiry and at least



one ASP all ASP one ASP
trans to
trans to trans to trans to

AS Pending
AS Down
Tr expiry and no ASP (queueing)

Fig. 55 AS state machine.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

5.4.3 ASP Management Procedures

To make an ASP available a signaling procedure of M3UA is used. This procedure
has the task to inform SCTP about the availability of an ASP, to register and activate
the associated routing keys.

First we consider an ASP establishment for a single ASP (single routing key) with
dynamic key registration. In this case the procedure looks like the following.

1. The application server has first to indicate it availability on the level of M3UA. For
this the M3UA message ASP UP is used. Inside the AS provides an ASP
identifier and a free format info string.
2. The SG will acknowledge this ASP UP indication with ASP UP
ACKNOWLEDGEMENT. In this message again an info string can be provided
(typically different from the one in ASP UP).
3. Now the ASP is INACTIVE. It remains to register the keys. This is done with the
already known message Register Request and its response message Register
4. The last step is to activate the ASP with its registered routing keys. This
activation is done via the message ASP ACTIVE. This message brings the ASP
into state ASP ACTIVE for one established routing context. This ASP can work in
one of three traffic modes:
Override : The ASP takes over the traffic for the corresponding routing context.
This overrides earlier established ASPs for this context, in other words, the new
ASP switches off the older ASP.
Loadshare : The new ASP shares the signaling traffic with other active ASPs for
this context.
Broadcast : The new ASP will receive all the signaling messages of the context
whether ASPs receive these data or not.
5. The SG will now acknowledge the reception of the ASP ACTIVE message with
6. Now that an ASP is in state ASP ACTIVE, also the state of the application server
is synchronized to AS ACTIVE. Hence a notification message as status indication
is sent back to the AS.

120 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling Application
Gateway Server
(ASP identifier, info string)

ASP Up Acknowledgement
(info string)

Register Request
Register Response

ASP Active
(Traffic Mode Type, Routing Context, info string)

ASP Active Acknowledgement

(Traffic Mode Type, Routing Context, info string)

(Status Type : AS State Change, Status Info : AS ACTIVE, ASP- ID, RC)

Fig. 56 ASP establishment for a single routing key and no redundancy.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

Now let us look to the case, when one application server process registers several
routing keys.

1. Again the application server process starts by indicating its availability using ASP
Up message. The SG shall acknowledge with ASP Up Ack.
2. Next the ASP registers the routing contexts it wants to have. In this scenario the
ASP configures routing context 1 to routing context N in the Register Request
message. The SG acknowledges with Register Response.
3. Now each configured routing context must be explicitly activated. Thus we will
see N times the ASP Active message. For each routing context an individual
traffic mode must be specified. Of course for each ASP Active message there will
be a ASP Active Ack message as response from the SG.
4. For each routing context the application server state is now active. Hence the SG
shall send for each routing context one NOTIFY message to indicate the
successful state change.

122 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling Application
Gateway Server

ASP Up Acknowledgement

Register Request
(RC1, ... , RC N)
Register Response

ASP Active

(Traffic Mode Type, Routing Context 1, info string)

ASP Active Acknowledgement

ASP Active

(Traffic Mode Type, Routing Context N, info string)

ASP Active Acknowledgement

Notify (..., AS ACTIVE, RC 1)

Notify (..., AS ACTIVE, RC 1)

Fig. 57 ASP registration for multiple routing key registrations.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

In the last example a scenario with two ASPs will be shown. The ASPs will work in
load-sharing mode. For sake of simplicity the routing keys are assumed to be
statically administered in the SG.

1. First both application servers will indicate there availability.

2. There is no need to configure the routing key, because they already exist in the
SG. So both ASPs can immediately start to activate the routing key with ASP
Active messages. The traffic mode is both times set to Load-Sharing. The SG will
now distribute the signaling traffic for this routing key between the two ASPs.
3. Last the SG has to notify both ASPs about the state change concerning their
application servers. This is done using NOTIFY messages.

124 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling ASP 1 ASP 2


ASP Up Acknowledgement


ASP Up Acknowledgement

ASP Active (Load Sharing)

ASP Active Acknowledgement

ASP Active (Load Sharing)

ASP Active Acknowledgement

Notify (AS ACTIVE)

Notify (AS ACTIVE)

Fig. 58 Set up of two ASPs in load sharing mode.

2002 Siemens AG
Siemens SS 7 over IP (SIGTRAN)

The last message flow is about the override of an ASP. The case is triggered by the
removal of the first ASP. Now a second should take over the traffic of the first ASP.

1. The first ASP indicates that it is no longer available. This is done by sending the
M3UA message ASP Inactive. The SG will acknowledge with ASP Inactive
2. Now the SG will inform the second ASP about the AS state change. For this
again the Notify message is used. This message indicates, that the first AS has
the state AS PENDING, which means, that first AS will be shut down.
3. The second ASP can now trigger the override. With the message ASP Active
with traffic type OVERRIDE it will indicate, that it takes over the signaling traffic
from the first ASP. The SG will acknowledge.

126 Registernummer
2002 Siemens AG
SS 7 over IP (SIGTRAN) Siemens

Signaling ASP 1 ASP 2


ASP Inactive

ASP Inactive Acknowledgement

Notify ( AS-Pending)

ASP Active (Override)

ASP Active Acknowledgement

Fig. 59 Override from ASP1 to ASP2.

2002 Siemens AG