37
PCNSIG Sigtran Training Document

03b Sigtran

  • Upload
    touaiti

  • View
    49

  • Download
    0

Embed Size (px)

DESCRIPTION

sigtran

Citation preview

Page 1: 03b Sigtran

PCNSIG

Sigtran

Training Document

Page 2: 03b Sigtran

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.

Page 3: 03b Sigtran

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

Page 4: 03b Sigtran

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)

Page 5: 03b Sigtran

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

Page 6: 03b Sigtran

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

Page 7: 03b Sigtran

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

Page 8: 03b Sigtran

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.

Page 9: 03b Sigtran

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.

Page 10: 03b Sigtran

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.

Page 11: 03b Sigtran

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.

Page 12: 03b Sigtran

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.

Page 13: 03b Sigtran

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

Page 14: 03b Sigtran

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

Page 15: 03b Sigtran

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.

Page 16: 03b Sigtran

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.

Page 17: 03b Sigtran

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.

Page 18: 03b Sigtran

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.

Page 19: 03b Sigtran

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.

Page 20: 03b Sigtran

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:

Page 21: 03b Sigtran

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.

Page 22: 03b Sigtran

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

Page 23: 03b Sigtran

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.

Page 24: 03b Sigtran

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)

Page 25: 03b Sigtran

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)

Page 26: 03b Sigtran

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

Page 27: 03b Sigtran

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.

Page 28: 03b Sigtran

Sigtran

28 (37)

Figure 11 SIGTRAN message monitoring

Page 29: 03b Sigtran

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

Page 30: 03b Sigtran

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

Page 31: 03b Sigtran

Error! No text of specified style in document.

31 (37)

Page 32: 03b Sigtran

Sigtran

32 (37)

MAP Insert Subscriber Data message

Page 33: 03b Sigtran

Error! No text of specified style in document.

33 (37)

Page 34: 03b Sigtran

Sigtran

34 (37)

Page 35: 03b Sigtran

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

Page 36: 03b Sigtran

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

Page 37: 03b Sigtran

Error! No text of specified style in document.

37 (37)