PCNSIG
Sigtran
Training Document
Sigtran
2 (37)
Legal notice
Intellectual Property Rights
All copyrights and intellectual property rights for Nokia Siemens Networks training documentation, product documentation and slide presentation material, all of which are forthwith known as Nokia Siemens Networks training material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of groups without the prior written agreement of Nokia Siemens Networks.
Indemnity
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products are given “as is” and all liability arising in connection with such hardware or software products shall be defined conclusively in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.
Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT
This document and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.
Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2013. All rights reserved.
Contents
3 (37)
Contents
1 Objectives ................................................................................. 4
2 Introduction............................................................................... 5
3 IP layer ....................................................................................... 7
4 Stream Control Transmission Protocol ................................ 10 4.1 SCTP functions ......................................................................... 11 4.2 SCTP messages ....................................................................... 12 4.3 SCTP procedures ..................................................................... 14 4.4 NSN implementation of SCTP .................................................. 22
5 SS7 MTP3 – User Adaptation Layer M3UA............................ 24 5.1 General ..................................................................................... 24 5.2 M3UA message structure ......................................................... 24 5.3 SIGTRAN monitoring with Wireshark ........................................ 27
6 Gr interface over IP signalling messages ............................. 29 6.1.1 SS7 over IP .............................................................................. 29 6.1.2 Example trace of Update GPRS Location Procedure
messages in SS7 over IP interface ........................................... 30
7 Glossary .................................................................................. 35
Sigtran
4 (37)
1 Objectives After this training session, the participants should be able to:
• Draw SIGTRAN protocol stack and explain the role of each layer
• Describe the function and structure of SCTP messages
• Monitor and explain SIGTRAN messages from signalling monitoring tool
(Wireshark)
Error! No text of specified style in document.
5 (37)
2 Introduction
Signaling Transport SIGTRAN is a Working Group in IETF, whose primary
purpose is to address the transport of packet-based PSTN signaling over IP
Networks, taking into account the functional and performance requirements of
PSTN signaling. SIGTRAN defines a framework for how different existing
signalling protocols can be transferred over IP, like SCCP ,ISUP and Q.921.
The IETF SIGTRAN protocols change the three lowest layers (Message
Transfer Part (MTP) layers 1-3) of narrowband SS7 signalling protocol stacks,
while the upper layers stay the same as with PCM based signalling. The main
enabling protocol for Internet Protocol (IP) -based signalling transfer is the
Stream Control Transmission Protocol (SCTP). This protocol was specifically
designed to support capabilities similar to those found in Message Transfer Part
(MTP), but on an unreliable IP transport.
The IETF SIGTRAN working group has defined multiple ways of integrating
(or adapting) the new SCTP signalling functionality with the existing SS7
architecture. Several user adaptation layers have been defined, for providing an
interface equivalent to Message Transfer Part Level 2 (MTP2), Message
Transfer Part Level 3 (MTP3) and Signalling Connection Control Part (SCCP).
The user adaptations fill in any missing functionality between the SCTP base
and the chosen interface.In Nokia SGSN, MTP3 User Adaptation Layer
(M3UA) is used. M3UA provides an interface that is compatible with MTP3. In
other words, M3UA supports MTP3 applications on top of SCTP and IP. As
integration is done at the SS7 network layer, it is possible to provide signalling
between IP- and PCM-based signalling nodes through Signalling Gateways.
Figure 1 SS7 and Iu control plane protocol stacks in NSN SGSNs shows the
SS7protocol stacks supported in NSN SGSN Release 3 (or later).
Sigtran
6 (37)
Figure 1 SS7 and Iu control plane protocol stacks in Nokia SGSNs
The SS7 over IP feature replaces the Message Transfer Part (MTP) 1_3 layers
with Internet Protocol (IP), SCTP and M3UA layers. This feature can be used in
several legacy SS7 interfaces in the SGSNs:
Gd interface with the Short Message Service Center (SMSC)
Ge interface with the Service Control Point (SCP)
Gf interface with the Equipment Identity Register (EIR)
Gr interface with the Home Location Register / Authentication Centre
(HLR/AUC)
Lg interface with the Gateway Mobile Location Center (GMLC), only in
NSN SGSN
Gs interface with the Mobile Services Switching Centre/Visitor Location
Register (MSC/VLR), only in NSN SGSN
Error! No text of specified style in document.
7 (37)
3 IP layer The Internet Protocol (IP) is the most widely used internetworking layer
protocol though it provides an unreliable, connectionless delivery service. IP is
unreliable because it does not guarantee the delivery of packets and is therefore
referred to as "best effort" system. The IP layer does not worry about packets
being lost, delayed, duplicated, and so on. It is up to the higher layers to deal
with those problems. In addition, the IP layer provides a connectionless service
since neither a physical nor virtual circuit is established between a sender and a
receiver. It provides a packet switched, datagram delivery service.
The main functions performed by the IP layer are:
Packaging transport layer PDUs (T-PDU) into IP packets.
Routing packets to the destination.
Fragmentation and reassembly (if necessary) based on the maximum
transfer unit (MTU) of the data link layer.
Datagram lifetime checking to remove packets that are lost.
Error control on the packet header.
Delivering packets to the appropriate higher layer at the receiver.
The basic unit of data transfer in an IP (Internet Protocol) environment is the
packet. Sometimes, the term datagram is used. A packet consists of a header and
data. The size of an IP packet varies between 20 octets and 65,535 octets in
length in IP version 4 (IPv4). This is the current version of IP, and it is to be
replaced by IPv6 in the near future. The format of an IPv4 packet is shown in
Figure 2. The fields of the header are described below as per RFC 791. The
number of bits reserved for each field is different. The first five rows (5 * 32
bits = 20 octets) are compulsory in every IP packet.
0 4 8 16 31
Version IHL Service Type Total Length
Identification Flags Fragmentation Offset
Time To Live Protocol Header Checksum
Source IP Address
Destination IP Address
IP Options Padding
Data
Figure 2 Basic Format of an IPv4 IP Datagram
Sigtran
8 (37)
A description of the IPv4 packet fields is presented in Table 1:
Table 1 Fields of the IP Diagram
Field Name Length in Bits
Description
Version 4 IP Version: IPv4 (=0100) in most cases but IPv6 (0110) is also defined.
IHL 4 Internet Header Length in 32 bit words. Most header fields are a fixed length, however IP Options and its corresponding padding vary, thus IHL is required. Minimum value is 5 (0101)
Service Type 8 Tells a host how to handle the datagram. Bits are used as follows;
0–2 Precedence
000 = Routine
001 = Priority
010 = Immediate
011 = Flash
100 = Flash Override
101 = CRITIC/ECP
110 = Internetwork Control
111 = Network Control
3 Delay. If set low delay is requested.
4 Throughput. If set indicates high throughput is requested.
5 Reliability. If set indicates that high reliability is requested.
6–7 Reserved for future use.
Total Length 16 Total Length, in octets, of datagram including the header. Since the field is 16 bits the maximum length is 2
16 octets, i.e. 65,535 octets.
Identification 16 Integer that uniquely identifies the datagram. Used to reassemble the datagram in case of fragmentation.
Flags 3 Controls fragmentation.
Bit 0 is reserved.
Bit 1 if set means “do not fragment”
Bit 2 if set means “last fragment”
Fragmentation Offset
13 Gives the location in multiples of 8 octets (i.e. N x 64 bits) at which a fragment fits into the original datagram.
Time To Live 8 Time To live: Notionally measured in seconds. This figure is decremented each time the header is processed and when it reaches zero the datagram is deleted. This stops undeliverable datagrams from clogging the inter-network. Usually set to 32 or 64.
Error! No text of specified style in document.
9 (37)
Field Name Length in Bits
Description
Protocol 8 Indicates the higher layer protocol (UDP, TCP, ICMP, etc) to which the IP packet is to be delivered. Each protocol has an Assigned Numbers (RFC 1700).
Header Checksum
16 This is a checksum for the datagram header, not the entire datagram. The checksum algorithm is defined in RFC 791.
Source Address
32 The IP address of the source. This address is unique throughout the entire inter-network except in special circumstances discussed later in this course.
Destination Address
32 The IP address of the intended destination. This address is also unique throughout the entire inter-network except in special circumstances discussed later in this course.
Options
Variable
Options must be fully supported by all IP implementations. However, individual datagrams need not carry Options Codes. Any given datagram may carry any number of Option Codes within the bounds of the maximum size of the datagram. An Options Code is a single octet which is interpreted as three fields;
Bit 0 = Copy. If set, this option code is copied to all fragments if the datagram is fragmented.
Bits 1–2 = Option Class. A value of 0 indicates datagram or Network control, value of 2 indicates debugging and measurement, with all other values reserved.
Bits 3–7 = Option Number. Several values are defined with the main ones as follows:
0 (with Class 0) = End of Option list
1 (with Class 0) = No Operation
2 (with Class 0) = Security and Handling restrictions (Mainly US Military applications).
3 (with Class 0) = Loose Source Routing. Used to route a datagram along a specific path.
4 (with Class 2) = Internet Timestamp. Used to record timestamps along the route.
Options 7 (with Class 0) = Record Route. Used to trace a route.
9 (with Class 0) = Strict Source Routing. Also used to route a datagram along a specified path.
Implementation Option Definitions are given in RFC 791.
Padding Variable A bunch of 0s to ensure that the header ends on a 32-bit boundary.
Sigtran
10 (37)
4 Stream Control Transmission Protocol Stream Control Transmission Protocol (SCTP) is an Internet Protocol
(IP)transport protocol which provides transport layer functions to many
Internet-based applications. The SCTP layer is between the SCTP user
adaptation layer(for example M3UA) and a connectionless packet network
service such as IP. SCTP is connection oriented, that is, it establishes a
connection between two endpoints (SCTP association) before transmitting the
user data. SCTP is specified in RFC 2960 and RFC 3309.
Basically, the SCTP offers a reliable transfer of user messages between
peerSCTP users. The following list explains the services the SCTP offers to its
users in more detail:
Multi-homing: each SCTP endpoint is known by multiple IP
addresses.Routing to one address is independent of all others and, if one
route becomes unavailable, another will be used.
.Multi-streaming capability: data is split into multiple streams, each
stream with independent sequenced delivery.
Reliable transport of user data - detecting when data is corrupt or out of
sequence.
Application-level fragmentation and multiplexing of user datagrams.
Initialisation procedure: based on cookies and used to prevent denial of
service attacks.
Appropriate congestion avoidance behaviour and resistance to flooding
and masquerade attacks.
Fast retransmission
Segmentation and bundling
Selective ACK
Initialisation procedure: based on cookies and used to prevent denial of
service attacks.
Error! No text of specified style in document.
11 (37)
4.1 SCTP functions
Association Start-up and Takedown
An association is initiated by a request from the SCTP user. A cookie
mechanism is employed during the initialization to provide protection against
security attacks. The cookie mechanism uses a four-way handshake, the last
two legs of which are allowed to carry user data for fast setup.
SCTP provides for graceful close (i.e., shutdown) of an active association on
request from the SCTP user. SCTP also allows ungraceful close (i.e., abort),
either on request from the user (ABORT primitive) or as a result of an error
condition detected within the SCTP layer.
Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user messages that
are to be delivered to the upper-layer protocol in order with respect to other
messages within the same stream. This is in contrast to its usage in TCP, where
it refers to a sequence of bytes.
The SCTP user can specify the number of streams to be supported by the
association at the association start-up time. This number is negotiated with the
remote end. User messages are associated with stream numbers. Internally,
SCTP assigns a stream sequence number to each message passed to it by the
SCTP user. On the receiving side, SCTP ensures that messages are delivered to
the SCTP user in sequence within a given stream. However, while one stream
may be blocked waiting for the next in-sequence user message, delivery from
other streams may proceed.
User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP packet
passed to the lower layer conforms to the path MTU. Upon receipt, fragments
are reassembled into complete messages before being passed to the SCTP user.
Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message. The TSN is independent of any stream
sequence number assigned at the stream level. The receiving end acknowledges
all TSNs received, even if there are gaps in the sequence. In this way, reliable
delivery is kept functionally separate from sequenced stream delivery.
Sigtran
12 (37)
The acknowledgement and congestion avoidance function is responsible for
packet retransmission when timely acknowledgement has not been received.
Packet retransmission is conditioned by congestion avoidance procedures
similar to those used for TCP.
Chunk Bundling
The SCTP packet delivered to the lower layer consists of a common header
followed by one or more chunks. Each chunk may contain either user data or
SCTP control information. The SCTP user has the option to request bundling
more than one user message into a single SCTP packet. The SCTP chunk
bundling function is responsible for assembling the complete SCTP packet and
disassembling it at the receiving end.
Packet Validation
A mandatory Verification Tag field and a 32-bit checksum field are included in
the SCTP common header. The Verification Tag value is chosen by each end of
the association during the association start-up. Packets received without the
expected Verification Tag value are discarded as protection against blind
masquerade attacks or stale SCTP packets from a previous association. The
checksum should be set by the sender of each SCTP packet to provide
additional protection against data corruption in the network. The receiver of an
SCTP packet with an invalid checksum silently discards the packet.
4.2 SCTP messages
The protocol data units (PDU) of SCTP are called SCTP packets. If SCTP runs
over IP, an SCTP packet forms the payload of an IP packet. An SCTP packet is
composed of a common header and chunks. Multiple chunks may be
multiplexed into one packet up to the Path-MTU size. A chunk may either
contain control information or user data.
The common header consists of 12 bytes. For the identification of an
association, SCTP uses the same port concept as TCP and UDP. For the
detection of transmission errors, each SCTP packet is protected by a 32-bit
checksum, which is more robust than the 16-bit checksum of TCP and UDP.
SCTP packets with an invalid checksum are silently discarded. The common
header also contains a 32-bit value called the verification tag. The verification
tag is association specific, and exchanged between the endpoints at the
association start-up. In all there are two tag values used in one association.
Error! No text of specified style in document.
13 (37)
Figure 3 SCTP protocol data unit
Each chunk begins with a chunk type field, which is used to distinguish data
chunks and different types of control chunks, followed by chunk specific flags
and a chunk length field (needed because chunks are of varying lengths). The
value field contains the actual chunk payload. So far there are 13 chunk types
defined for standard use.
Table 2 SCTP chunks types
ID Value Chunk Type Description
0 Payload Data (DATA) Used to deliver user data
1 Initiation (INIT) Used to initiate an SCTP association between two endpoints
2 Initiation Acknowledgement (INIT ACK)
Used to acknowledge the initiation of an SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk
3 Selective Acknowledgement (SACK)
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received sub sequences of DATA chunks as
Sigtran
14 (37)
represented by their TSNs.
4 Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association.
5 Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a HEARTBEAT chunk
6 Abort (ABORT) The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver the reason of the abort
7 Shutdown (SHUTDOWN) An endpoint in an association MUST use this chunk to initiate a graceful close of the association with its peer
8 Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk must be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process
9 Operation Error (ERROR) An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions
10 State Cookie (COOKIE ECHO) This chunk is used only during the initialisation of an association. It is sent by the initiator of an association to its peer to complete the initialisation process
11 Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialisation of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk
12 Reserved for Explicit Congestion Notification Echo (ECNE)
13 Reserved for Congestion Window Reduced (CWR)
14 Shutdown Complete (SHUTDOWN COMPLETE)
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process
15 TO 255
Reserved by IETF
4.3 SCTP procedures
Establishment of Normal Association
The initialisation process consists of the following steps:
An endpoint A first sends an INIT chunk to another endpoint B. In the
INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag
field. Tag_A should be a random number within the range of 1 to
Error! No text of specified style in document.
15 (37)
4294967295. After sending the INIT, "A" starts the T1-init timer and
enters the COOKIE-WAIT state.
B shall respond immediately with an INIT ACK chunk. The destination
IP address of the INIT ACK MUST be set to the source IP address of the
INIT to which this INIT ACK is responding. In the response, besides
filling in other parameters, B must set the Verification Tag field to
Tag_A, and also provide its own Verification Tag (Tag_B) in the Initiate
Tag field. Moreover, B must generate and send along a State Cookie with
the INIT ACK.
Upon receiving the INIT ACK from B, A shall stop the T1-init timer and
leave COOKIE-WAIT state. A will then send the State Cookie received
in the INIT ACK chunk in a COOKIE ECHO chunk, start the T1-cookie
timer, and enter the COOKIE-ECHOED state. The COOKIE ECHO
chunk can be bundled with any pending outbound DATA chunks, but it
must be the first chunk in the packet and until the COOKIE ACK is
returned the sender must not send any other packets to the peer.
Upon receiving the COOKIE ECHO chunk, Endpoint B will reply with a
COOKIE ACK chunk after moving to the ESTABLISHED state. A
COOKIE ACK chunk may be bundled with any pending DATA chunks
(and/or SACK chunks), but the COOKIE ACK chunk must be the first
chunk in the packet.
Upon receiving the COOKIE ACK, endpoint A will move from the
COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-
cookie timer.
An INIT or INIT ACK chunk must not be bundled with any other chunk. They
are the only chunks present in the SCTP packets that carry them.
Sigtran
16 (37)
Figure 4 Establishment of Normal Association
After receiving the first DATA chunk of an association the endpoint must
immediately respond with a SACK to acknowledge the DATA chunk.
Association Termination
Both sides may decide to terminate an SCTP association for a number of
reasons, and can do so practically at any time (provided they are in a state that is
not CLOSED. There is optionally a graceful shutdown, ensuring that no data is
lost, or a hard termination, not taking care of the peer.
Graceful Termination of an Association
Upon receiving the SHUTDOWN primitive from its upper layer user process,
an SCTP instance should stop accepting data from this process, and start
sending a SHUTDOWN chunk, as soon as all of its outstanding data has been
acknowledged. This process is secured by a T2_shutdown timer that repeats this
process, should the SHUTDOWN be lost.
At some point, the peer will receive the SHUTDOWN and reply by sending a
SHUTDOWN ACK chunk, as soon as all of its data has been acknowledged
(also secured by a timer).
When the first peer (that started the shutdown procedure) receives the
SHUTDOWN ACK, it will stop the timer, send a SHUTDOWN COMPLETE,
and remove all data still belonging to that association, and enter the CLOSED
state.
Error! No text of specified style in document.
17 (37)
The peer that receives this SHUTDOWN COMPLETE chunk may then also
remove all record of this association, and enter the CLOSED state. Should the
last SHUTDOWN COMPLETE message be lost, the peer will repeat sending
SHUTDOWN ACK chunks until an error counter that reports the other peer
unreachable has been exceeded.
Figure 5 Termination of the association
Aborting the Association
An endpoint may also decide to abort an existing association, taking into
account that data still in flight may not be acknowledged, by sending an
ABORT chunk to its peer endpoint. The sender must fill in the peer's
Verification Tag in the outbound packet and must not bundle any DATA chunk
with the ABORT.
The receiver of the ABORT does not reply, but validates the chunk, and
removes the association, if the ABORT contains the correct tag value. If so, it
also reports termination to its upper layer process.
Sigtran
18 (37)
Data Transfer
The user of SCTP may assign each datagram to one of several streams within
an association. When an association is set-up, the number of available streams
per direction is exchanged between the peer entities. Within each stream, SCTP
assigns independent Stream Sequence Numbers (SSN) to the user datagrams.
These numbers are used at the receiver to determine the sequence of delivery.
SCTP performs in-sequence delivery per stream (for all datagrams which are
not marked for out-of-order delivery). This mechanism avoids head-of-line
blocking between independent streams of datagrams within one association.
Figure 6 Structure of the DATA chunk
As already mentioned, SCTP allows for marking datagrams in order-of-arrival
delivery. This could be used for important messages that may by-pass others,
like the transaction abort messages of an application. If no sequence
maintenance is required, all datagrams could be marked accordingly.
Multiple DATA chunks committed for transmission may be bundled in a single
packet. Furthermore, DATA chunks being retransmitted may be bundled with
new DATA chunks, as long as the resulting packet size does not exceed the path
MTU.
Before an endpoint transmits a DATA chunk, if any received DATA chunks
have not been acknowledged (e.g., due to delayed ack), the sender should create
a SACK and bundle it with the outbound DATA chunk, as long as the size of
the final SCTP packet does not exceed the current MTU.
Error! No text of specified style in document.
19 (37)
Figure 7 SACK chunk structure
Detection of loss and duplication of DATA chunks is enabled by numbering all
data chunks in the sender with the so-called Transport Sequence Number
(TSN). The acknowledgements sent from the receiver to the sender are based on
these sequence numbers. Retransmissions are timer-controlled. The timer
duration is derived from continuous measurements of the round trip delay.
Whenever such a retransmission timer expires, (and congestion control allows
transmissions) all non-acknowledged data chunks are retransmitted and the
timer is started again, doubling its initial duration (like in TCP). When the
receiver detects one or more gaps in the sequence of data chunks, each received
SCTP packet is acknowledged by sending a Selective Acknowledgement
(SACK), which reports all gaps. The SACK is contained in a specific control
chunk. Whenever the sender receives four consecutive SACKs reporting the
same data chunk missing, this data chunk is immediately retransmitted (fast
retransmit).
Selective Acknowledgement
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk. The acknowledgement should be generated for at least every
second packet (not every second DATA chunk) received, and should be
generated within 200 ms of the arrival of any unacknowledged DATA chunk.
Sigtran
20 (37)
The acknowledgements carry all of the TSN numbers that have been received
by one side with them. That is, there is a so called Cumulative TSN Ack value,
that indicates all the data that has successfully been reassembled at the
receiver's side, and has either already been delivered to the receiving Upper
Layer Process, or may readily be delivered upon request.
Moreover, there are so-called Gap Blocks that indicate that segments of data
chunks have arrived, with some data chunks missing in between. Should some
data chunks have been lost in the course of transmission, they will either be
retransmitted after the transmission timer has expired, or after four SACK
chunks have reported gaps with the same data chunk missing. In the latter case,
the missing data is retransmitted via the Fast Retransmit mechanism.
Figure 8 Data transfer
Flow Control
SCTP uses an end-to-end window based flow and congestion control
mechanism similar to the one that is well known from TCP. The receiver of data
may control the rate at which the sender is sending by specifying an octet-based
window size (the so-called Receiver Window), and returning this value along
with all SACK chunks.
The sender itself keeps a variable known as Congestion Window (short:
Error! No text of specified style in document.
21 (37)
CWND) that controls the maximum number of outstanding bytes (i.e. bytes that
may be sent before they are acknowledged). Each received data chunk must be
acknowledged, and the receiver may wait a certain time (usually 200 ms) before
that is done. Should there be a larger number of SCTP packets with data
received within this period, every second SCTP packet containing data is to be
acknowledged at once by sending a SACK chunk back to the sender.
Slow Start and Congestion Avoidance
As in TCP, SCTP has two modes, Slow Start and Congestion Avoidance. The
mode is determined by a set of congestion control variables, and as already
mentioned, these are path specific. So, while the transmission to the primary
path may be in the Congestion Avoidance mode, the implementation may still
use Slow Start for the backup path(s).
For successfully delivered and acknowledged data the congestion window
variable (CWND) is steadily increased, and once it exceeds a certain boundary
(called Slow Start Threshold, SSTRESH), the mode changes from Slow Start to
Congestion Avoidance. Generally, in Slow Start, the CWND is increased faster
(roughly one MTU per received SACK chunk), and in Congestion Avoidance
mode, it is only increased by roughly one MTU per Round Trip Time (RTT).
Events that trigger retransmission (timeouts or fast retransmission) cause the
SSTHRESH to be cut down drastically, and reset the CWND (where a timeout
causes a new Slow Start with CWND=MTU, and a Fast Retransmit sets
CWND=SSTHRESH).
Path and Peer Monitoring
An SCTP instance monitors all transmission paths to the peer instance of an
association. To this end, HEARTBEAT chunks are sent over all paths that are
currently not used for the transmission of data chunks. Each HEARTBEAT
chunk has to be acknowledged by a HEARTBEAT-ACK chunk.
Each path is assigned a state: it is either active or inactive. A path is active if it
has been used in the recent past to transmit an (arbitrary) SCTP datagram,
which has been acknowledged by the peer. If transmissions on a certain path
seem to fail repeatedly, the path is regarded as inactive.
The number of events where heartbeats were not acknowledged within a certain
time, or retransmission events occurred, is counted on a per association basis,
and if a certain limit is exceeded (the value of which may be configurable), the
peer endpoint is considered unreachable, and the association will be terminated.
Sigtran
22 (37)
4.4 NSN implementation of SCTP
In the NSN implementation it is possible to use only one stream for data
messages. Management messages are always sent to stream 0. It is possible to
configure whether the data stream is 0 or 1 with an association set parameter.
However, it is recommended to use data stream 1. If stream 1 is used, the total
stream count for the association is 2 otherwise 1. Once the message traffic is
load shared between associations there is not much additional advantage of load
sharing to individual streams inside one association. Also the main emphasis in
load sharing is on balancing the CPU load in signalling units. That is why just
one data stream is enough.
Figure 9 Example of IP type SS7 signalling link
Error! No text of specified style in document.
23 (37)
Association set and associations
On the IP transport medium, each SS7 signalling link is associated with an
association set consisting of up to 32 SCTP associations. However, for ordered
messages, for which the SLS is used for load sharing, traffic is shared to a
maximum of 16 first activated ASPs (associations).
Nokia SCTP implementation in 3G SGSN
This is done similar to the DX world. There are two types of processes, running
on the 3G SGSN that handle the SS7 over IP traffic.
The Stream Control Transmission Protocol (SCTP) is processed on the CRP.
It takes care of the interface towards the IP layer and provides the M3UA layer
with streaming services.
The system is fault tolerant. Even if the CRP fails, the backup unit will take
over and a copy of the SCTP process running on this unit will take over the
tasks of the process in the failing unit.
The MTP3 User Adaptation layer is handled by the process tris7m3ua. This
process is located in the SS7 Unit, with the tris7nb process. It gives the SCCP
layer an alternative service provider for MTP3 services. SCCP routing decides,
which service provider is used for each message.
Sigtran
24 (37)
5 SS7 MTP3 – User Adaptation Layer M3UA
5.1 General
MTP3 User Adaptation Layer (M3UA) defines a protocol for supporting the
transport of any Message Transfer Part Level 3 (MTP3) user signalling over
Internet Protocol (IP) using the services of Stream Control Transmission
Protocol (SCTP). It handles the MTP level 3 functions and services in the IP
network.
M3UA sets up associations between signalling endpoints so that when one
association breaks up it does not stop all the traffic between the endpoints.
M3UA does network address translation and mapping for ongoing routing to the
final IP destination.
M3UAwas designed to support fault tolerance and loadsharing. Fault tolerance
is provided using many IP Server Processes (IPSPs) or M3UA instances, which
provide the services at the same time. If a local M3UA instance fails, the
Signalling Connection Control Part (SCCP) service provider and the remote
node (IPSP instance) diverts the traffic to the remaining active instances.
M3UA is specified in RFC 3332.
5.2 M3UA message structure
The basic overhead on SIGTRAN contains the following message headers: IP,
SCTP and M3UA.
1. The size of the IP header depends on what version of the IP stack is used,
IPv4 or IPv6. The length of the IPv4 header can vary between 20 to 60
bytes. 20 bytes is the length of the basic IP address in IPv4. The
remaining 40 bytes is the length of the option field. Options are not
commonly used on the IPv4. The length of the IPv6 header is 40 bytes +
options fields. Usually some of those option fields are included in the
message when it is using IPv6. (See chapter 3)
2. The SCTP header should contain a Common header, Chunk description
and Payload identifier. The length of the Common header is 3 dword. The
length of Chunk Description is 1 dword. The length of Payload identifier
is 4 dword. The total SCTP header size is 32 bytes. (See chapter 4)
Error! No text of specified style in document.
25 (37)
3. The size of the Common Message header of the M3UA is 16 bytes. The
Common message header exists in every M3UA message. (Figure 17)
Version (1 byte): supported M3UA version release 1.0
Message length (4 bytes): defines the length of the message in octets
including the common header.
Message Class (1 byte): indicates if the message is the
Management/Transfer/SS7 management/ASP state maintenance/ASP
traffic maintenance/Routing Key management related.
The following M3UA message types are defined: see table 3.
Figure 10 M3UA message structure (DATA message)
Sigtran
26 (37)
The Routing label of the MTP3 message is encoded to separate fields. The OPC
and DPC fields are both 4 bytes long and the rest of the routing label parameters
like SI, NI, Message Priority and SLS are encoded to 4 bytes. The total length
of the M3UA message header is 24 bytes in the Payload Data message.
Table 3 M3UA message types
Class Type Message Description
Management (0) 0 Error Used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
Management (0) 1 Notify Notification related to status change of an ASP.
Transfer (1) 1 DATA Contains MTP3 user protocol data.
SS7 management (2) 1 DUNA Destination Unavailable. Sent from SG to all concerned ASP to indicate that one or more SS7 destinations are unavailable. Also sent as a response to a message to unreachable destination.
SS7 management (2) 2 DAVA Destination Available. Sent from SG to all concerned ASP to indicate that one or more SS7 destinations are available. Also sent as a response to DAUD message if appropriate.
SS7 management (2) 3 DAUD Destination State Audit. MAY be sent to SG to audit unavailable destinations.
SS7 management (2) 4 SCON Signalling Congestion. May be sent from SG or in case IPSP-IPSP indicates congestion of one peer.
SS7 management (2) 5 DUPU Destination User Part Unavailable. Used by SG to inform ASP that the user part in SS7 network is not available.
SS7 management (2) 6 DRST Destination Restricted (optional)
ASP state maintenance (3) 1 ASPUP ASP up
ASP state maintenance (3) 2 ASPDN ASP down
ASP state maintenance (3) 3 BEAT Heartbeat (optional)
ASP state maintenance (3) 4 ASPUP ACK ASP up acknowledgement
ASP state maintenance (3) 5 ASPDN ACK ASP down acknowledgement
ASP state maintenance (3) 6 BEAT ACK Heartbeat acknowledgement
Error! No text of specified style in document.
27 (37)
ASP traffic maintenance (4) 1 ASPAC ASP active
ASP traffic maintenance (4) 2 ASPIA ASP inactive
ASP traffic maintenance (4) 3 ASPAC ACK ASP active acknowledgement
ASP traffic maintenance (4) 4 ASPIA ACK ASP inactive acknowledgement
Routing Key Management (9)
1 REG REQ Registration request. Sent by an ASP to indicate to a remote M3UA peer that it wishes to register one or more given Routing Keys with the remote peer. Typically, an ASP would send this message to an SGP, and expects to receive a REG RSP message in return with an associated Routing Context value.
Routing Key Management (9)
2 REG RSP Registration response
Routing Key Management (9)
3 DEREG REQ Deregistration request
Routing Key Management (9)
4 DEREG RSP Deregistration response
The common message header is followed by variable length parameters. When
more than one parameter is included in a message, the parameters may be in any
order except where explicitly mandated. All parameters are coded in a TAG-
LENGTH-VALUE format (ASN-1 like). TAG field (2 bytes) specifies the type
of the parameter (for instance Routing key/OPC/DPC/Service indicators). The
Length field (2 bytes) contains the size of the parameter in bytes including the
parameter tag.
OYI.
5.3 SIGTRAN monitoring with Wireshark
SIGTRAN messages can be captured by connecting a PC (with Ethereal
installed) to the ESB20. A IP address is provided to ESB20 for this purpose.
Sigtran
28 (37)
Figure 11 SIGTRAN message monitoring
Error! No text of specified style in document.
29 (37)
6 Gr interface over IP signalling messages
6.1.1 SS7 over IP
M3UA (SS7 MTP-3 User Adaption Layer) and SCTP (Stream Control
Transport Protocol) adapt the SS7 protocols to IP. SCTP refers to the Stream
Control Transmission Protocol developed by the SIGTRAN working group of
the IETF for the purpose of transporting various signaling protocols over IP
networks. M3UA refers to the SCCP adaptation layer "SS7 MTP3 – User
Adaptation Layer " also developed by the SIGTRAN working group of the
IETF. SGSN M3UA implementation is based on the RFC 3332.
Figure 12 Narrowband SS7 over IP Protocol Stack
Sigtran
30 (37)
6.1.2 Example trace of Update GPRS Location Procedure messages in SS7 over IP interface
MAP Update GPRS Location Procedure message
Error! No text of specified style in document.
31 (37)
Sigtran
32 (37)
MAP Insert Subscriber Data message
Error! No text of specified style in document.
33 (37)
Sigtran
34 (37)
Error! No text of specified style in document.
35 (37)
7 Glossary
Application
S
e
r
v
e
r
(
A logical entity serving a specific Routing Key. An example of an Application
Server is a virtual switch element that handles all call processing for a unique
range of PSTN trunks, identified by an SS7 SIO/DPC/OPC/CIC range. Another
example is a virtual database element handling all HLR transactions for a
particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of
one or more unique Application Server Processes, of which one or more is
normally actively processing traffic. Note that there is a 1:1 relationship
between an AS and a Routing Key.
Application
S
e
r
v
e
r
A process instance of an Application Server. An Application Server Process
serves as an active or backup process of an Application Server (e.g., part of a
distributed virtual switch or database). Examples of ASPs are processes (or
process instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP
endpoint and may be configured to process signalling traffic within more than
one Application Server.
Association An association refers to an SCTP association. The association provides the
transport for the delivery of MTP3-User protocol data units and M3UA
adaptation layer peer messages. An association is a virtual channel created
between the source port (source IP address) and the target port (target IP
address) of the CCSU (Common Channel Signalling Unit).
Association set A set of associations (1–32) which lead from a network element to the same
destination network element or the Application Server (AS) which used the SPC
and the NI as a routing key.
IP Server Process
(
I
A process instance of an IP-based application. An IPSP is essentially the same
as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually,
an IPSP does not use the services of a Signalling Gateway node.
Failover The capability to reroute signalling traffic as required to an alternate
Application Server Process, or group of ASPs, within an Application Server in
the event of failure or unavailability of a currently used Application Server
Process. Failover also applies upon the return to service of a previously
unavailable Application Server Process.
Host The computing platform that the process (SGP, ASP or IPSP) is running on.
Layer Manement Layer Management is a nodal function that handles the inputs and outputs
Sigtran
36 (37)
between the M3UA layer and a local management entity.
Linkset A number of signalling links that directly interconnect two signalling points,
which are used as a module.
MTP The Message Transfer Part of the SS7 protocol.
MTP3 MTP Level 3, the signalling network layer of SS7.
MTP3-User Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP,
TUP).
Network Appeara Identifies an SS7 network context for the purposes of logically separating the
signalling traffic between the SG and the Application Server Processes over a
common SCTP association. An example is where an SG is logically partitioned
to appear as an element in four separate national SS7 networks. A Network
Appearance implicitly defines the SS7 Point Code(s), the Network Indicator,
and the MTP3 protocol type/variant/version used within a specific SS7 network
partition.
Routing Key A Routing Key describes a set of SS7 parameters and parameter values that
uniquely define the range of signalling traffic to be handled by a particular
Application Server. Parameters within the Routing Key cannot extend across
more than a single Signalling Point Management Cluster.
Routing Context A value that uniquely identifies a Routing Key. Routing Context values are
either configured using a configuration management interface, or by using the
routing key management procedures defined in this document.
Signalling Gatway
P
r
A process instance of a Signalling Gateway. It serves as an active, backup,
load-sharing or broadcast process of a Signalling Gateway.
Signalling
G
a
t
e
w
a
y
(
S
An SG is a signalling agent that receives/sends SCN native signalling at the
edge of the IP network [11]. An SG appears to the SS7 network as an SS7
Signalling Point. An SG contains a set of one or more unique Signalling
Gateway Processes, of which one or more is normally actively processing
traffic. Where an SG contains more than one SGP, the SG is a logical entity
and the contained SGPs are assumed to be coordinated into a single
management view to the SS7 network and to the supported Application Servers
Error! No text of specified style in document.
37 (37)