Table of contents

1 Introduction 1

2 Stream Control Transmission Protocol 13

3 SCCP/SUA 43

4 Layer 1-3 protocols 57

5 Extras 77
ii TeleScope,
c 2016
Chapter 1

Introduction

1 SS7 protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 SS7 key concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 SS7 signalling modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 MTPL3 signalling network . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 The need for SS7 transport over IP . . . . . . . . . . . . . . . . . . . . . . 6
6 SIGnalling TRANsport over IP . . . . . . . . . . . . . . . . . . . . . . . . 7
7 ASP association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8 ASP redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9 Routing Context and Routing Key . . . . . . . . . . . . . . . . . . . . . . 11
1 SS7 protocol stack

Signalling System number 7 is currently main signalling solution for mobile networks.

MTP – Message Transfer Part.

M3UA – MTP L3 User Adaptation.
M2UA – MTP L2 User Adaptation.
M2PA – MTP L2 Peer-to-Peer Adaptation.
SCCP – Signalling Connection Control Part.
SUA – SCCP User Adaptation.
TCAP – Transaction Capabilities Application Part.
MAP – Mobile Application Part.
CAP – CAMEL Application Part.
BSSAP – BSS Application Part.
RANAP – RAN Application Part.
DTAP – Direct Transfer Application Part.
ISUP – ISDN User Part.
BICC – Bearer Independent Call Control.
GCP – Gateway Control Protocol.

2 TeleScope,
c 2016
2 SS7 key concepts
SS7 key concepts
Signaling Route (SR)
Link Set (LS) -> SLS = 0
Signaling Link (SL) - > SLC = 0
SP-A SP-C
Signaling Link (SL) - > SLC = 1

Signaling Route Set (SRS) to Link Set (LS) -> SLS =1

SP-C: SP-B
- directly Terms
- via SP-B
LS Link Set
SP Signalling Point
SR Signalling Route
SRS Signalling Route Set
STP Signalling Transfer Point
SL Signalling Link
SLC Signalling Link Code
SLS Signalling Link Selection

Signalling in Mobile Networks 3

LS – Link Set
SP – Signalling Point
SR – Signalling Route
SRS – Signalling Route Set
STP – Signalling Transfer Point
SL – Signalling Link
SLC – Signalling Link Code
SLS – Signalling Link Selection

Notes

Chapter 1. Introduction 3
3 SS7 signalling modes

SS7 signalling modes

STP

Exchange D

Quasi-associated signaling mode

SP SP

Exchange A Exchange C

SP
Associated signaling mode
Voice link
Exchange B
Signaling link

Signalling in Mobile Networks 4

Notes

4 TeleScope,
c 2016
4 MTPL3 signalling network

MTL3 signalling network

Load Sharing

2-246

SLS=0xxx
2-6854
Load sharing between
2 Link Sets
SLS=1xxx 2-487

2-675

Load sharing between 8 Signaling Links

SL 0: SLS = x000 SL 4: SLS = x100

SL 1: SLS = x001 SL 5: SLS = x101
SL 2: SLS = x010 SL 6: SLS = x110
SL 3: SLS = x011 SL 7: SLS = x111

Signalling in Mobile Networks 5

Load sharing between 8 signalling links:

SL 0: SLS = x000
SL 1: SLS = x001
SL 2: SLS = x010
SL 3: SLS = x011
SL 4: SLS = x100
SL 5: SLS = x101
SL 6: SLS = x110
SL 7: SLS = x111

Notes

Chapter 1. Introduction 5
5 The need for SS7 transport over IP

Why do we need transport over IP for SS7 networks?

SS7 classical transport:

• is narrowband,
• requires complex configuration for getting high capacity,
• is based on TDM, technology with expensive handling,
• is connection-oriented and quick in identifying transmission problems.

SS7 broadband transport:

• is wideband but uses (expensive) ATM for transport,

• is connection-oriented and quick in identifying transmission problems.

Internet Protocol used as transport for SS7:

• is cheaper technology especially when expanding,

• can use modern high capacity transport networks such as Carrier Ethernet or MPLS,
• simplifies operator network design going for All-IP.

Challenges for SIGTRAN (SIGnalling TRANsport over IP):

• IP is unreliable network with no transmission error detection

• no retransmission nor reordering are provided,
• existing (at the time) transport protocols (TCP, UDP) are not suitable.

After successful SIGTRAN design and implementation, SCTP proved to be very suitable
protocol for EPS, where it is used as transport protocol for X2AP, S1AP, Cx or S6a
interfaces.

Notes

6 TeleScope,
c 2016
6 SIGnalling TRANsport over IP

SIGTRAN generic architecture

SIGTRAN protocols view, generic architecture and basic terms.

IPSP AS
IP
IPcloud
cloud
AS IPSP fully
fullymesh
mesh ASP
Dynamic
DynamicRouting
Routing
Key
Keyand
andContext
Context

Legacy
Legacy SG
SS7
SS7

Signalling in Mobile Networks 1

Signalling Gateway (SG) – signalling agent that receives/sends SCN native signalling at
the edge of the IP network. 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.
Signalling Gateway Process (SGP) – a process instance that uses M3UA to communicate
with other signalling processes. An ASP, an SGP, and an IPSP are all signalling processes.
Application Server (AS) – a logical entity serving a specific Routing Key. An example of an
Application Server is a virtual switch element handling all call processing for a signalling
relation, identified by an SS7 DPC/OPC. Another example is a virtual database element,
handling all HLR transactions for a particular SS7 SIO/DPC/OPC 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 Server Process (ASP) – 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

Chapter 1. Introduction 7
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.
IP Server Process (IPSP) – 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.
Routing Key (RK) – a Routing Key is essentially a set of SS7 parameters used to filter
SS7 messages.
Routing Context – a value that uniquely identifies a Routing Key. Routing Context values
are configured either using a configuration management interface, or by using the routing
key management procedures.
Fail-over – the capability to reroute signalling traffic as required to an alternate Applica-
tion 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.
Layer Management – nodal function that handles the inputs and outputs between the
M3UA layer and a local management entity.
Network Appearance – a M3UA local reference shared by SG and AS (typically an integer)
that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating
the specific SS7 network to which it belongs. It can be used to distinguish between
signalling traffic associated with different networks being sent between the SG and the
ASP over a common SCTP association. An example scenario is where an SG appears
as an element in multiple separate national SS7 networks and the same Signaling Point
Code value may be reused in different networks.
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.
Address Mapping Function (AMF) – capability to use transport (IP) addresses. Host –
the computing platform that the process (SGP, ASP or IPSP) is running on.
Stream – SCTP stream; a unidirectional logical channel established from one SCTP end-
point to another associated SCTP endpoint, within which all user messages are delivered
in-sequence except for those submitted

Notes

8 TeleScope,
c 2016
7 ASP association

Establishment of ASP connectivity

SIGTRAN nodes need to maintain long-lasting associations.

ASP A ASP B

Establish SCTP Association

ASP Up

ASP Up Ack

REGISTER REQ(LRC,RK)

REGISTER RESP (LRC, RK)

ASP Active

ASP Active Ack

NTFY (ASP Active)

Signalling in Mobile Networks 11

ASP State Maintenance (ASPSM) Messages

• ASP Up (ASPUP)
• ASP Down (ASPDN)
• Heartbeat (BEAT)
• ASP Up Acknowledgement (ASPUP ACK)
• ASP Down Acknowledgement (ASPDN ACK)
• Heartbeat Acknowledgement (BEAT ACK)

ASP Traffic Maintenance (ASPTM) Messages

• ASP Active (ASPAC)

• ASP Inactive (ASPIA)
• ASP Active Acknowledgement (ASPAC ACK)
• ASP Inactive Acknowledgement (ASPIA ACK)

Chapter 1. Introduction 9
3 8 ASP redundancy
ASP redundancy

portant Important
feature feature
for SIGTRAN is isthe
for SIGTRAN theimplementation of redundant
implementation of redundant ASPs. ASPs.

ASP may indicate which of the follwoing modes it wants to operate:

• Override
• Loadshare
• Broadcast
ASP may indicate which of the follwoing modes it wants to operate:
Within a Routing Context, Override, Loadshare Types and Broadcast cannot be mixed.
• Override
The Override value indicates that the ASP is operating in Override mode, and the ASP
wishes to take over all traffic for an Application Server (i.e., primary/backup operation),
overriding any currently active ASP in the AS.
• Loadshare
In Loadshare mode, the ASP wishes to share in the traffic distribution with any other
• Broadcast
currently active ASPs.
In Broadcast mode, the ASP wishes to receive the same traffic as any other cur- rently
active ASPs. When there are insufficient ASPs, the sender may immediately move the
Within ASP
a Routing
to Active. Context, Override, Loadshare Types and Broadcastcannot
mixed. The Override value indicates that the ASP is operating in Override
de, and the ASP wishes to take over all traffic for an Application Server (i.e.,
mary/backup operation), overriding any currently active ASP in the AS.
In Loadshare mode, the ASP wishes to share in the traffic distribution with any
er currently
10 active ASPs. TeleScope,
c 2016
49 Routing
Routing Context
Context andand RoutingKey
Routing Key
RoutingKey
Routing Keyconcept
concept was
was made
made to
to ultimately
ultimatelysupport
supportdynamic
dynamicrouting in in
routing SIGTRAN.
SIGTRAN.

The Routing Key is used to distribute messages from the SS7 network to a
specific Application Server. This key can be any combination of the following SS7
The Routing
routing Key is used
information, to distribute
depending messages
on which Usarfrom the SS7 network
Adaptation is will betoused:
a specific Appli-
cation Server. This key can be any combination of the following SS7 routing information,
depending on which Usar Adaptation is will be used: Examples of fields in Routing Key:
• Destination Point Code (DPC)

• •Originating
Network Indicator (NI) (OPC)
Point Code
• Service Indicator (SI)
• •Subsystem
Destinationnumber (SSN)
Point Code (DPC)
• •Global
Originating Point Code (OPC)
Title (GT)
• Subsystem number (SSN)
• Network Indicator (NI)
Routing Key Management (RKM) Messages
• Service Indicator (SI)
Routing Key Management (RKM) Messages:
• ...
• Registration Request (REG REQ)
• Registration
Routing ContextResponse (REG RSP)
uniqely identifies one Routing Key.
• Deregistration Request (DEREG REQ)
• Deregistration Response (DEREG RSP)

Chapter 1. Introduction 11
12 TeleScope,
c 2016
Chapter 2

Stream Control Transmission

Protocol

1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 IPv4 packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 New features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 IPv6 basic header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 IPv6 QoS handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7 IP routing concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8 ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9 TCP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10 TCP packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11 UDP features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12 Stream Control Transmission Protocol . . . . . . . . . . . . . . . . . . . . 30
13 SCTP packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14 SCTP chunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15 SCTP DATA chunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16 SCTP association setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
17 SCTP INIT chunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
18 Selective acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . 37
19 SCTP dynamic configuration . . . . . . . . . . . . . . . . . . . . . . . . . 39
20 NAT for SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
21 Security considerations for SIGTRAN protocols . . . . . . . . . . . . . . . 41
22 SCTP authenticated chunks . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1 Principles

As the base for interconnection a protocol was created, called Internet Protocol, or IP.
Internet Protocol principles
Putting it into OSI model, IP is a network layer, layer 3, and as such it is responsible
for routing and switching of the packets. It also provides mechanisms for establishing,
maintaining and release connections betweene.g.
theTCP,
nodes (used by IP
UDP,
or higher layers).
DESIGN
OSPF, FTP, HTTP,
DNS ... unreliable network (no error control, or
retransmissions)
Application „equal” nodes

Presentation capable to operate with big damages

Services where packets are delivered on
Session individual basis using destination
Host-to- address
Transport Host

Network Internet Protocol

Data Link e.g. Ethernet, ATM

Access Network Frame Relay,
Physical GPRS

6 IP for Mobile Networks |

The generic principles of how IP operates are often referred to as Classical Model (Clas-
sical IP, CLIP). It assumes that communication between the nodes in the same logical
IP network will be done directly with the help of underlaying layer mechanisms, and
communication between nodes in different logical IP networks would require additional
equipment, namely a router. Main routing and switching mechanisms in IP, and definition
of IP logical network, are described later in this document.
The Internet Protocol does not provide a reliable communication facility. There are no
acknowledgements either end-to-end or hop-by-hop. There is no error control for data,
only a header checksum. There are no retransmissions. There is no flow control. Actually,
the flexibility and usability of IP proved to be in its extreme simplicity, which allows the
implementation of different type of protocols and services atop. On the other hand the
lack of proper quality of service handling is main issue to solve in modern IP networks.
IP separates lower layer(s), which is an access to the physical network, from upper layers,
which can be simplified as service layer. Network access is generic term for facilitating
connection between nodes, and may vary from simple solutions such as Ethernet networks,
through more complicated e.g. ATM, to complex systems such as UMTS. Upper layers
may also be complicated e.g. implementation of Web browsing requires usage of TCP
(layer 4), HTTP (layer 5), HTML (layer 6) and finally web browser (layer 7). It may also
includes all upper layers (4-7) in one application e.g. OSPF.

Notes

14 TeleScope,
c 2016
2 IPv4 packet

An IPv4 packet starts with 4-bit value version. In this chapter version 4 is discussed,
but version 6 is already being implemented, and described later. Those 2 are the only
standardised versions of Internet Protocol.
IPv4 packet

version IHL ToS total length

identification flags fragment offset
TTL protocol header checksum
source address
destination address
options padding

upper layer protocol data

fragmentation version (4, 6)

addressing upper layer protocol

10- 11 IP for Mobile Networks | 10

IHL, Internet Header Length, 4-bit value, provides the length of the packet header in
32-bit word, and it actually points to the beginning of the data. Minimum correct IHL
value is 5 (i.e. pure header, no options included).
Type of Service field (8 bits) indicates desired quality of service, and is separately described
in this document.
Total Length, 16 bits value, is the length of the packet, measured in bytes, including
header and data. This field allows the length of a datagram to be up to 65,535 octets
(64kB).
Fragmentation of the packet is one of the main IP functions. Fields Identification (16
bits), Flags (3 bits: reserved, ‘do not fragment’, ‘more fragments’), Fragment Offset (13
bits) are used to help assembling fragmented packets.
Time to Live (8 bits) indicates the maximum time the packet is allowed to remain in the
network. Every node processing the packet must decrease this value by at least 1 (initially
– by the time the node spent on processing this packet), and when it goes down to zero,
then the datagram must be destroyed.
Protocol (8 bits) indicates the next layer protocol used in the data portion of the packet.
The values for various protocols are controlled by IANA, and are available on-line from
http://www.iana.org .
Header Checksum (16 bits) is checksum calculated on the header only. Every time the

Chapter 2. Stream Control Transmission Protocol 15

header changes (e.g. time-to-live field), this value is recomputed.
Source and Destination Addresses are 32-bits fields as described in the following sections.
The IP uses Type of Service, Time to Live, Options, and Header Checksum as key
mechanisms in providing its service. When necessary, IP packet header is padded with
zeros to be a multiplication of 32-bits value.

Notes

16 TeleScope,
c 2016
3 Differentiated Services

There are number of concerns about IntServ, mainly on scalability issues. Traditional
RSVP protocol requires a state machine that houses timers for each session and a clas-
sifying mechanism in each router. This makes both memory and processing capacity
expensive, especially for a backbone router, where can be many of the sessions with
QoS inusers
individual IP and
– Differentiated
hosts. Services

DiffServ Domain
Host

R R
Interrior
Routers
R Host
R
Host Edge
Router R Edge
Router

DSCP CU

ToS Packet
Classification
IP Header

16 IP for Mobile Networks | 23

Due to the above-mentioned limitations of the IntServ model, the IETF created the new
model referred to as Differentiated Services (DiffServ).
Unlike IntServ, the goal in DiffServ is to create a set of ‘building blocks’ that provide
a foundation for building end-to-end services throughout the network. According to this
model network traffic is classified and conditioned at the entry to a network and assi-
gned to a different Per Hop Behavior (PHB) category. The DiffServ model uses a new
implementation of the IPv4 ToS header. DiffServ renames the eight-bit ToS field as the
DS field, with six bits available for current use (DCSP) and two reserved for future use
(CU).
The major and defined PHBs include:

• Expedited Forwarding (EF).

• Assured Forwarding (AF).
• Default Behavior (DH).

A DiffServ domain is a continuous set of nodes which support a common resource provi-

Chapter 2. Stream Control Transmission Protocol 17

sioning and PHB policy. Any node inside a DS domain that is non-DS compliant results
in unpredictable performance and loss of end-to-end QoS. DiffServ could be extended
across domains by Service Level Agreement (SLA) between them. A SLA defines rules
such as for traffic remarking, actions to be taken for out of profile traffic.
Within a DS domain, every packet must be sent with a DSCP field set. Therefore, the
node at the ingress edge of he DS domain must ensure that this field is set appropriately
in each packet. This is a part of the role of traffic conditioning. Such a role includes tasks
for: packet classifier, meter, marker, shaper and dropper.
Concluding, DifServ is a scalable technology to build large networks that can offer dif-
ferentiated services for various applications needs. The way DiffServ provides QoS for
specific stream of packets is sometimes referred to as ‘damage control’.

Notes

18 TeleScope,
c 2016
4 New features

IP version 6 (IPv6) is a newer version of the Internet Protocol, designed as the successor
to IP version 4. IPv4 is relatively old protocol, which showed several issues over the time,
causing IETF to work on improved version ot the IP. The main changes from IPv4 to
IPv6 are in:

• Addressing capabilities – address size increases from 32 bits to 128 bits, giving
much greater number of addressable nodes, more levels of addressing hierarchy,
and simpler auto-configuration of addresses. In Internet there is actually a situation
when range of available IPv4 addresses is very limited and shrinking.
• Scalability of multicast routing by adding a ”scope” field.
• A new type of address called an ”anycast address” is defined.
• Header format – some IPv4 header fields have been dropped or made optional,
to reduce cost of packet processing and to limit the bandwidth cost of the IPv6
header.
• Improved support for extensions and adding options in the future.
• Flow labelling capability is introduced to mark packets belonging to particular traffic
that requires special handling e.g. real time traffic.
• Authentication and privacy capabilities will be enhanced by extensions.

Actually, IPv5 was also defined, and it was even meant to replace IPv4. But it presented
the solution to rebuild IP completely, too much to make it in any way feasible to be
implemented with coexistence with IPv4. IPv6 is not fully backward compatible, but still
it was designed to work together with, or over IPv4. Version field, as designed, allows for
coexistence of IPv4 and IPv6 in the same network.

Notes

Chapter 2. Stream Control Transmission Protocol 19

5 IPv6 header IPv6 basic header

For IPv6 the main header was significantly revised.

version traffic class flow label

payload length next header hop limit

source address

destination address

IPv6 header contains the following mandatory fields:

• Version – 4 bits IP version (number = 6).

19-20
• Traffic class – 8 bits traffic class field. IP for Mobile Networks | 26

• Flow label – 20 bits flow label.

• Payload length – 16 bits value of length of the payload i.e. without IP header but
including extension headers.
• Next header – 8 bits selector to identify the type of header immediately following
the IPv6 header.
• Hop limit – 8 bits value decremented by 1 by each node that forwards the packet,
when reaches zero packet is discarded.
• Source address and destination addresses, 128 bit numbers.

Notes

20 TeleScope,
c 2016
6 IPv6 QoS handling

The design of IP version 6 took place during the advent of multimedia capable devices.
Hence, from the early beginning this protocol is designed to provide not only the ’best
effort’ treatment to user traffic. There are two fields in the IPv6 header: the Flow Label
and the Traffic Class field that may be used by a host to identify those packets for which
it requests special handling by IPv6 routers, such as non-default quality of service or
IPv6 QoSservice.
”real-time” support

1 - (224-1)
Priority Flow Label

Traffic Class Flow Label

1 - (220-1)

Bits 0 4 8 12 16 24 31
Version
Payload length Next header Hop limit
IPv6
Source address header

Destination address

24-25 IP for Mobile Networks | 36

The 8-bit Traffic Class field in the IPv6 header is intended for use by originating nodes
and/or forwarding routers to identify and distinguish between different classes or prio-
rities of IPv6 packets. Therefore, it should provide functionality similar to that of IPv4
Precedence and Type of Service fields. Initially, Traffic Class field was actually a 4-bit
Priority filed with well defined ranges specifying the priority of traffic for which the source
is providing congestion control, i.e., traffic that ”backs off” in response to congestion,
such as TCP traffic as well as priority of traffic that does not back off in response to
congestion, e.g., ”real-time” packets being sent at a constant rate.
The 20-bit Flow Label field (initially 24-bit) in the IPv6 header may be used by a source
to label those packets for which it requests special handling by the routers, such as non-
default quality of service or ”real-time” service. A flow is a sequence of packets sent from
a particular source to a particular (unicast or multicast) destination for which the source
desires special handling by the intervening routers. A flow is uniquely identified by the
combination of source address and nonzero 20-bit flow label. The new flow label must
be chosen (pseudo-) randomly and uniformly in the range 1 to 220 − 1.
The nature of the special handling might be conveyed to the routers by a control proto-

Chapter 2. Stream Control Transmission Protocol 21

col, such as a resource reservation protocol, or by information within the flow’s packets
themselves, e.g., in a hop-by-hop option.
All packets originating from a given source with the same destination must have the
same destination address, source address, priority, hop-by-hop options header contents
(if present), and routing header (if present). The intent is that a router can decide how
to route and process the packet by simply looking at the rest of the header.
IPv6 may be also the subject of both Differentiated Services and Integrated Services
operations. Nowadays, Traffic Class field can be superseded by the DS-filed, which allows
for smooth integration between IPv6 and DiffServ. One of the major elements that create
IntServ, which is RSVP, has been designed to work both with IPv4 and IPv6. However,
due to the variable number of headers in IPv6, efficient classification of IPv6 data packets
could be obtained using the Flow Label field of the IPv6 header.
Initially, different protocols were matched to various Priority values. For instance, FTP
and HTTP were concerned as attended bulk transfer and therefore receive Priority field
set to the value of 4.

Notes

22 TeleScope,
c 2016
7 IP routing concepts

Sending packets out into the Internet is to send them to the router. What does router
do to find a way towards packet’s destination?
Routing table example

62.233.150.4
10.1.99.2
if1: 212.7.10.1 62.233.150.0/24
if2: 10.1.99.1
212.7.10.0/24 R2

R1
10.0.0.0/8
R1 routing table:
62.233.150.10/30
DEST GATEWAY M
10.0.0.0 if2 1
62.233.150.0 10.1.99.2 2
R3
62.233.150.8 10.1.99.3 5
195.169.10.0 10.1.99.3 4 if1: 10.1.99.3
195.169.10.0/24
212.7.10.0 if1 1 if2: 195.169.10.3
ppp1: 62.233.150.9

51 IP for Mobile Networks | 3

The IP modules implemented in nodes use the addresses carried in the Internet header
to transmit packets towards their destinations. The selection of a path for transmission
is called routing, and machines involved in passing packets between hosts are called
routers. The principal rule in IP routing is that each node is responsible for determining
a neighbour that is closer to the packet destination than itself. It uses information in its
routing table to select the next hop, but is unable to find out whether the entire path
is available at the moment. As a consequence it is impossible to know which way each
packet will follow.
A routing table contains (at least) 3 important columns:

• Destination – expressed as an IP host or network address of the final destination

of the packets.
• Next hop – which is either IP address of another node, or local interface.
• Metric – parameter that describes how “far” is destination; it represents sum of
costs through packet path.

A node matches destination address in incoming packet to the most specific entry in the
routing table, and passes packet to the next node, or sends back information ‘destination
unreachable’ if entry was not found.
Special address 0.0.0.0 matches all destinations and is often used as default route.

Chapter 2. Stream Control Transmission Protocol 23

A routing table can be built in different ways:

• statically – routing entry are placed manually (by administrator), or

• dynamically – nodes and routers exchange routing information between them.

Metric parameter is mainly used in the second case: there may be several ways to get
to the same destination, so it is reasonable choice to use the closest one i.e. with the
smallest metric. Metric can be expressed by different measurable values: number of nodes
on the way to destination, capacity of the path, expected delay etc.
Routing in IP is generally based IP on hop-by-hop principle. Nodes do have a way to
force route by using IP Options e.g. Loose Route.
Autonomous systems
Autonomous System (AS) is a one IP network ”entity” that is under one routing policy
and usually under one administration. Typically AS is used by backbone operators or
big corporations, which have different Internet Service Providers. Public AS numbers are
controlled by IANA, Internet Authority for Numbering and Addressing.
Static routing concept
Static routing refers to the situation when routing tables are manipulated manually by
network administrator(s). On the advantages side:

• Operators have full control on packets path.

• Routers do not require additional software (licences).

Main disadvantages are:

• Routers do not react to network changes.

• Routes have to manually set by administrator, which is inconvenient in frequently
changing environment.

Source based routing

Source based routing is a particular version of static routing. It allows taking routing
decision based on the source of the packet rather than destination. This might be use-
ful for network administrators to route traffic differently for particular sub-networks or
interfaces.
Dynamic routing
Dynamic exchange of routing information is done by the means of routing protocols.
There are numerous – standard or proprietary – out of which most important ones (and
standard) are:

• Routing Information Protocol (RIP).

• Open Shortest Path First (OSPF).
• Border Gateway Protocol (BGP).

The routing protocols can be also divided into Interior or Exterior Gateway Protocols.
IGP is a protocol within an AS, such as RIP or OSPF. EGP are protocols, which connect
different AS and separating them, allowing using different routing policy, with BGP being
the main one.

24 TeleScope,
c 2016
8 ENUM

How a GT can be translated into DNS domain?

ENUM records allow:

• resolving E.164 Global Titles addresses

• into IP address or service

Special NAPTR resources have been defined for that purpose:

• x.x.x.x.e164.arpa
• x.x.x.x is converted E.164 number in international format

Conversion rules (example for +44-20-7946 0148)

• remove all characters with the exeption of the digits: “442079460148”

• reverse the order of the digits: “841064970244”
• put dots (‘.’) between each digit: “8.4.1.0.6.4.9.7.0.2.4.4”
• append the string “.e164.arpa” to the end
• interpret as domain name: “8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa”

Notes

Chapter 2. Stream Control Transmission Protocol 25

9 TCP functions

IP itself delivers means for addressing and packet fragmentation and transport. Reliable
host-to-host transmission requires layer-4 protocol – TCP.

The Transmission Control Protocol (TCP) is host-to-host protocol (IP protocol number
6) providing reliable process-to-process communication. TCP replaced NCP (Network
Control Protocol) that was the first approach to bi-directional communication between
computers. TCP is intended to perform the following tasks:

• Basic data transfer – the TCP is capable of transfer of bit stream in both directions.
Since the TCPs decides when to block and forward data, a push function is defined
for user to assure that data submitted to TCP is actually transmitted, and it should
be pushed through to the receiving user.
• Reliability – TCP is capable of recovering from data that is damaged, lost, dupli-
cated, or delivered out of order. Every octet that is transmitted has a sequence
number assigned, and requires a positive acknowledgment from the receiving si-
de. If it is not received within a timeout interval, the data is retransmitted. The
sequence numbers are used to correctly order segments, and to eliminate duplica-
tes. Checksum added to each segment transmitted is used to discover and discard
damaged packets.
• Flow control – TCP provides “window” mechanism for controlling the amount of
data sent by the sender. Every acknowledgment indicates an allowed number of
bytes that the sender may transmit before receiving further permission.
• Multiplexing – TCP allows for many processes to communicate simultaneously:
host address (IP) and port form a socket, and pair of sockets uniquely identifies
each connection. Some (standard) services have fixed sockets made known to the
public (e.g. ftp, http. . . ).
• Connections – combination of status, sockets, sequence numbers, and window si-
zes, is called a connection. TCP is responsible for establishing and closing of a
connection, and freeing the resources for other uses.
• Precedence and security – TCP allows users to indicate the security and precedence
of their communication (using IP header).

Notes

26 TeleScope,
c 2016
10 TCP packet
TCP packet

source port destination port

sequence number
acknowledgment number
U A P R S F
data
reserved R C S S Y I window
offset G K H T N N

checksum urgent pointer

options padding

data

Sequencing & ACK TCP Flags

Addressing Upper Layer Protocol

34-35 IP for Mobile Networks | 7

TCP header contains the following fields:

• Source port – 16-bit source port number.

• Destination port –16-bit destination port number.
• Sequence number – 32-bit number of the first data octet in this segment; exception
is when SYN is present then it signify initial sequence number (ISN).
• Acknowledgement number – 32-bit value of the next sequence number the ack-
nowledging side is expecting to receive.
• Data offset – 4-bit number of 32 bit words in the TCP header indicating where the
data begins.
• Control bits – 6 bits (flags).
• Window – 16-bit number of data octets which the acknowledging side will accept.
• Checksum – 16-bit checksum field is the 16 bit one’s complement of the one’s
complement sum of all 16 bit words in the header and text.

Port numbers below 1024 are reserved for standardised services such as FTP (21), HTTP
(80), SMTP (25), SSH (22).
Since TCP header is rather long the compression technique may be involved to make it
shorter: parameters that do not change during a connection are replaced by one context
value.

Chapter 2. Stream Control Transmission Protocol 27

11 UDP features

TCP is to provide reliable connection in IP networks, but there may be a possibility to

UDP packet
use unreliable protocol, with minimum protocol mechanisms. That is when UDP is used.

source port destination port

length checksum

data

Compression approach:
The User Datagram
IP source Protocol
and destination (UDP) is defined to make available a datagram mode of
addresses
packet-switched computer communication
UDP source and destination ports with IP used as the underlying protocol. UDP
is transaction oriented, and delivery and
can be used protection
duplicate to generateare not guaranteed,
single context ID which
is referred to as ”send & pray” concept.
AUDP checksum
simple UDP header contains: can be omitted

• Source port – 16-bit value indicating the port of the sending process, and may be
assumed to be the port to which a reply should be addressed in the absence of any
other information.
40 IP for Mobile Networks | 17
• Destination port – 16-bit value indicating port within the context of destination
address.
• Length – is the length (in octets, min. 8) of the datagram including the header and
the data.
• Checksum – 16-bit one’s complement of the one’s complement sum of a pseudo
header (source and destination address, protocol and length from IP header), the
UDP header, and the data.

UDP uses protocol number 17.

IP and UDP headers can be compressed, to reduce payloads when operating over low
speed lines such as dial-up modems, to 6 or fewer bytes (often 2 if UDP checksums are
disabled), followed by higher protocol header, e.g. by the Real-time Transport Protocol
(RTP) for network audio and video applications. It is done by defining a session context
as combination of:

• IP source and destination addresses.

• UDP source and destination ports.
• Optionally, higher layer protocol context identifier.

The compressed packet carries a small integer, called the session context identifier (CID),
to indicate in which session context that packet should be interpreted. The decompressing
processor will use the CID to index its table of stored session contexts directly.

28 TeleScope,
c 2016
UDP is often better solution than TCP e.g. for applications that do not require reliable
transfer or strict ordering.

Notes

Chapter 2. Stream Control Transmission Protocol 29

 Stream Control Transmission
12 Protocol Stream Control Transmission Protocol

association

Streams

The Stream Control Transmission Protocol (SCTP) provides reliable transfer of user
messages between SCTP peers, using special context called an association. SCTP provides
the means for using a list of transport addresses (i.e., multiple IP addresses) through which
Signalling in Mobile Networks 5
SCTP endpoint can be reached and from which it will originate SCTP packets. Functions
of SCTP can be summarized in the following groups.
Association start-up and takedown function is responsible for creating association. An
association is initiated by a request from the SCTP user, which employs a cookie me-
chanism to provide protection against security attacks. SCTP provides for graceful close
(i.e., shutdown) and ungraceful close (i.e., abort).
Sequenced Delivery is assured within Streams. Stream in SCTP refers to a sequence of
messages of the upper-layer protocols. At start up, SCTP specifies the number (nego-
tiated at the endpoint) of streams to be supported by the association. 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. If one
stream is blocked waiting for next in-sequence message, delivery from other streams may
proceed. SCTP also allows bypassing the sequenced delivery service, so messages are
delivered as soon as they are received.
User Data Fragmentation is used by SCTP fragment user messages to ensure that the
SCTP packet passed to the lower layer conforms to the path MTU. On reception, frag-
ments are reassembled.
Acknowledgement and Congestion Avoidance function is responsible for packet retrans-
mission when timely acknowledgement has not been received. SCTP assigns a Transmis-
sion Sequence Number (TSN) to each message. The TSN is independent of any stream
sequence number assigned at the stream level. The receiving endpoint 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.
Chunk Bundling function is described in the next unit.

30 TeleScope,
c 2016
Packet Validation function acts against data corruption or attacks trials. A mandatory Ve-
rification 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 association
start up. Packets received without the expected Verification Tag value (masquerade at-
tack or stale packets) or with incorrect checksum (data corruption in the network) are
discarded.
The SCTP path management function chooses the destination transport address for
outgoing packets based on the SCTP user’s instructions and the current reachability
status (checked with heartbeats) of the destination (one or more addresses). The path
management function reports the eligible set of local transport addresses to the far end
during association startup, and the transport addresses returned from the far end to the
SCTP user.

Notes

Chapter 2. Stream Control Transmission Protocol 31

13 SCTP packet
SCTP packet

source port destination port

verification tag

checksum

chunk #1

chunk #2

chunk #...

Signalling in Mobile Networks 6

SCTP common header contains:

• Source port and destination port – 16-bit numbers.

• Verification tag – 32-bit value used to validate packet.
• Checksum – 32-bit value calculated by Adler-32 algorithm.

SCTP provides mechanisms for transferring different streams within one association.
Messages are sent within chunks.

Notes

32 TeleScope,
c 2016
14 SCTP chunk SCTP chunk

Chunk Bundling function is responsible for assembly of the complete SCTP packet and
its disassembly at the receiving end.

chunk type chunk flags chunk length

chunk data

The SCTP packet as delivered to the lower layer consists of a common header followed
by one or more chunks (containing either user data or SCTP control information). The
SCTP user has the option to request bundling of more than one user messages into a
single SCTP packet. Each chunk is composed of the following fields:

• Chunk type – 8-bit value identifying what data is carried inside the chunk.
Signalling in Mobile Networks 7
• Chunk flags – 8 bits set depending on type of chunk.
• Chunk length – 16-bit value representing size of chunk with chunk type, flags,
length, and value fields.
• Chunk value – usage and format depends on type.

The following chunk types are defined (ID, Chunk Type) as mandatory:
0 - Payload Data (DATA).
1 - Initiation (INIT).
2 - Initiation Acknowledgement (INIT ACK).
3 - Selective Acknowledgement (SACK).
4 - Heartbeat Request (HEARTBEAT).
5 - Heartbeat Acknowledgement (HEARTBEATACK).
6 - Abort (ABORT).
7 - Shutdown (SHUTDOWN).
8 - Shutdown Acknowledgement (SHUTDOWN ACK).
9 - Operation Error (ERROR).
10 - State Cookie (COOKIE ECHO).
11 - Cookie Acknowledgement (COOKIE ACK).
12 - Reserved for Explicit Congestion Notification Echo (ECNE).
13 - Reserved for Congestion Window Reduced (CWR).
14 - Shutdown Complete (SHUTDOWN COMPLETE).

Chapter 2. Stream Control Transmission Protocol 33

15 SCTP DATA chunk SCTP DATA chunk

chunk type DATA

type = 0 reserved U B E length

transmission sequence number (TSN)

stream identifier stream sequence number

payload protocol identifier

user/application data

Payload chunk (type = 0) contains:

Signalling in Mobile Networks 8
• U bits – (U)nordered bit, if set to ’1’, indicates that there is no Stream Sequence
Number (and must be ignored).
• B and E bits – (B)egining and (E)nding bits, signifying first and last fragment of
the message.
• TSN.
• Stream identifier – 16-bit value.
• Stream Sequence Number (SSN) – 16-bit value.
• Payload protocol identifier – 32-bit value representing an application (or upper
layer) specified protocol identifier. This value is passed to SCTP by its upper layer
and sent to its peer.

Chunk data organisation represents common approach to options and extensions in diffe-
rent protocols (PPP, IPv6) i.e. fixed-size type and length followed by variable-size data.

Notes

34 TeleScope,
c 2016
 type = 1 flags length

initiate tag

16 Advertised Receiver Window Credit

SCTP association setup
number of outbound streams number of inbound streams
There can be only one association between hosts – how is it setup in terms of number
initial TSN
of streams and security?
optional parameters

CLOSED CLOSED
INIT: init tag=(A)1
COOKIE-WAIT
INIT ACK: verification tag=(A)1, init tag=(Z)1000, cookie=(Z)5555

COOKIE ECHO: cookie=(Z)5555

COOKIE ECHOEDCOOKIE ACK: ESTABLISHED

ESTABLISHED DATA: init tsn=(A)40, stream=0, sseq=1

Signalling in Mobile Networks 9

The initialisation process consists of the following steps:

1. ”A” sends an INIT chunk to ”Z”, providing its Verification Tag (Tag A) in the
Initiate Tag field. After sending the INIT, ”A” starts the T1-init timer and enters
the COOKIE-WAIT state.
2. ”Z” shall respond immediately with an INIT ACK chunk. ”Z” must set the Verifi-
cation Tag field to Tag A, and also provide its own Verification Tag (Tag Z) in the
Initiate Tag field. Moreover, ”Z” MUST generate and send along with the INIT
ACK a State Cookie.
3. Upon reception of the INIT ACK from ”Z”, ”A” shall leave COOKIE-WAIT state,
and send the State Cookie received in the INIT ACK chunk in a COOKIE ECHO
chunk, and enter the COOKIE-ECHOED state.
4. Upon reception of the COOKIE ECHO chunk, Endpoint ”Z” will reply with a
COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED
state.
5. Upon reception of the COOKIE ACK, endpoint ”A” will move from the COOKIE-
ECHOED state to the ESTABLISHED state.

Overall SCTP has more overhead information related to headers than TCP. The gain
resulting from using SCTP comes when used with multiple streams.

Notes

Chapter 2. Stream Control Transmission Protocol 35

17 SCTP INIT chunk

Association setup
type = 1 flags length

initiate tag

Advertised Receiver Window Credit

number of outbound streams number of inbound streams

initial TSN

optional parameters

CLOSED CLOSED
INIT: init tag=(A)1
COOKIE-WAIT
INIT ACK: verification tag=(A)1, init tag=(Z)1000, cookie=(Z)5555
The INIT chunk contains the following parameters:
COOKIE ECHO: cookie=(Z)5555
• Initiate
COOKIETag.
ECHOEDCOOKIE ACK: ESTABLISHED
• Advertised Receiver Window Credit.
ESTABLISHED DATA: init tsn=(A)40, stream=0, sseq=1
• number of Outbound Streams.
• number of Inbound Streams.
Signalling in Mobile Networks 9
• initial TSN.
• Supported Address Types (optional).
• IPv4 Address (optional).
• IPv6 Address (optional).
• Cookie Preservative (optional).

Notes

36 TeleScope,
c 2016
18 Selective acknowledgement

SCTP acknowledgements differ from standard TCP ones. Another type of chunk, SACK,
is used to send information of missing and duplicate TSNs (it exists in TCP as an option).
SCTP selective acknowledgment
chunk type SACK

type = 3 flags length

Cumulative TSN Acknowledgement

Advertised Receiver Window Credit

Number of Gap ACK Blocks (n) Number of Duplicate TSNs (m)

Gap ACK Block #1 Start Gap ACK Block #1 End

Gap ACK Block #n Start Gap ACK Block #n End

TSN #1 TSN #2

TSN #m

TSN=41 TSN=41 TSN=42 missing TSN=44 TSN=45 missing TSN=47

Cumulative ACK = 42, number of ACK blocks = 2, Block 1: start=2 end=3, Block 2: start=end=5

Signalling in Mobile Networks 10

Selective Acknowledgement (SACK) chunk is sent to:

• Acknowledge received DATA chunks.

• Inform of gaps in the received sequences of DATA chunks.

The SACK contains the Cumulative TSN Acknowledgement value, which is the last TSN
received before the first missing TSN. This parameter therefore confirms the reception
of all TSNs less than or equal to its value.
The SACK contains zero or more Gap Acknowledge Blocks. Each Gap Ack Block ack-
nowledges a sequence of TSNs received following a break in received TSNs. Start end
End of the Gap Block represents offset value from Cumulative TSN. All DATA chunks
with TSNs greater than or equal to:
Cumulative TSN Ack + Gap Ack Block Start
and less than or equal to:
Cumulative TSN Ack + Gap Ack Block End
of each Gap Ack Block are assumed to have been received correctly.
SACK may contain also number of Duplicate TSNs. If there are duplicates to report,
their TSNs are listed after Gap Block section.

Chapter 2. Stream Control Transmission Protocol 37

Cumulative TSN Acknowledgement value resembles Acknowledgement value in TCP. The
big difference comes with gap blocks and duplicates included.

Notes

38 TeleScope,
c 2016
19 SCTP dynamic configuration

To fullfil requirements of more demanding fault-tolerant applications, dynamic re confi-

guration for SCTP was introduced.
This extension permits:

• to dynamically add an IP address to an association,

• to dynamically remove an IP address from an association,
• to request to set the primary address the peer will use when sending to an endpoint

Extensions to SCTP:

• new chunk types – Address Configuration Change Chunk (ASCONF), Address Con-
figuration Acknowledgment Chunk (ASCONF-ACK)
• new parameters – Add IP Address, Delete IP Address, Set Primary IP Address,
Error Coue Indication, Success Indication, Adaptation Layer Indication, Supported
Extenions Parameter
• new error causes – Request to Delete Last Remaining IP Address, Operation Refu-
sed Due to Resource Shortage, Request to Delete Source IP Address, Association
Aborted Due to Illegal ASCONF-ACK, Request Refused – No Authorisation

Notes

Chapter 2. Stream Control Transmission Protocol 39

20 NAT for SCTP

With growing SCTP usage the need for NAT solution is growing as well.
NAT for SCTP cannot be the same as for TCP:

• single point traversal or multiple NAT in single path – looding profit of multihoming,
• multipoint traversal – unnecessary for single-homed association,
• checksum in SCTP is calculated over entire packet,
• NAT (or NATs) needs to recognise all packets for the same association.

SCTP specific variant of NAT:

• uses different internal and external VTags,

• requires single-homed association setup first,
• allows extending to multihome by ACONF chunk.

Extensions to SCTP:

• M-bit in ABORT and ERROR chunks to indicate chunks introduced by middle box,
• new error causes: VTag and Port Number Collision, Missing State, Port Number
Collision,
• new parameters: Disable, Restart, VTags.

Notes

40 TeleScope,
c 2016
21 Security considerations for SIGTRAN protocols

SCTP provides resistance against:

• blind Denial of Service Attack such as:

– flooding,
– masquerade
– improper monopolization of service
• SIGTRAN nodes using IPSec have to implement ESP and IKE
• TLS can be used to protect SCTP protocol data

Notes

Chapter 2. Stream Control Transmission Protocol 41

22 SCTP authenticated chunks

SCTP Authenticated Chunks allow extended security for SCTP itself.

This extension permits:

• permits to send and receive authenticated chunks,

• requires establishment of an Association Shared Keys.

Extensions to SCTP:

• new chunk type – Authentication Chunk (AUTH)

• new parameters – Random Parameter, Chunk List Parameter, Requested HMAC
Algoritm Parameter
• new error cause – Requested HMAC Algorithm Parameter

Notes

42 TeleScope,
c 2016
Chapter 3

SCCP/SUA

1 SCCP basics and routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2 SCCP Functional structure . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 SCCP Connection-Oriented service . . . . . . . . . . . . . . . . . . . . . . 46
4 SCCP message parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 SCCP address component . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Global Title translation – routing . . . . . . . . . . . . . . . . . . . . . . . 49
7 SCCP Connection-Less service . . . . . . . . . . . . . . . . . . . . . . . . 50
8 SUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9 SUA and SCCP – examples . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1 SCCP basics and routing
SCCP routing
Circuit-related vs Non-circuit related signaling

Traffic Traffic Traffic

control control control

ISUP ISUP ISUP

MTP3 MTP3 MTP3

SCCP routing
Application Application
SCCP user SCCP user
SCCP SCCP SCCP

MTP3 MTP3 MTP3

Signalling in Mobile Networks 7

Signalling Connection Control Part:

• Primarily provides transfer capability for non-circuit-related signalling

• Can handle circuit-related signalling
• Provides connectionless (CL) and connection-oriented (CO) network capabilities
• Extends addressing capabilities of the SS7 network on global basis

Notes

44 TeleScope,
c 2016
2 SCCP Functional structure
Functional structure of SCCP

BSSAP RANAP SCCP Users TCAP BSSAP RANAP

SCCP

SCOP SCLP
SCOC SCLC
SCMOP

SCOR SCLR

MTP

Signalling in Mobile Networks 8

SCCP Management Messages:

• Subsystem Allowed (SSA)

• Subsystem Prohibited (SSP)
• Subsystem Status Test (SST)
• Subsystem Out-of-service request (SOR)
• Subsystem Out-of-service Grant (SOG)
• SCCP/Subsystem Congested (SSC)
• Subsystem Backup Routing (SBR)
• Subsystem Normal Routing (SNR)
• Subsystem Routing Test (SRT)

Chapter 3. SCCP/SUA 45
3 SCCP Connection-Oriented service
Connection establish – CO service

Node Node Node

A B C
Dest: called address
Allocation Source ref „R1”
of „R1” CR msg
Dest: called address
„R2” allocated Source ref „R2”
„R1” stored CR msg

„R3”
CC msg allocate
d
„R2” stored
„R4” Dest ref „R2”
allocate Source ref „R3”
CC msg
d
„R3” stored
Storage Dest ref „R1”
of „R4” Source ref „R4”

Signalling in Mobile Networks 10

Message Type Protocol Class

CR Connection Request 2 and 3
CC Connection Confirm 2 and 3
CREF Connection Refused 2 and 3
RLSD Released 2 and 3
RLC Release Complete 2 and 3
DT1 Data Form 1 2
DT2 Data Form 2 3
AK Data Ackonwledgement 3
ED Expedited Data 3
EA Expedited Data Ack. 3
RSR Reset Request 3
RSC Reset Confirm 3
ERR Protocol Data Unit Error 2 and 3
IT Inactivity Test 2 and 3

46 TeleScope,
c 2016
4 SCCP message parameters
SCCP message parameters

DPC
Parameter 1
OPC
Value Parameter 2
SLS
Parameter 3
MTP Routing Label

Pointer to 1 Parameter n Message type code

Pointer to 2
Pointer to n Mandatory fixed part
Pointers
Pointer to
Parameter 1 Mandatory variable part
optional
Parameter 2
Parameter 1 Optional part
Parameter 2
Parameter n Parameter n
Length ind.
End of opt.
Value
parameters

Signalling in Mobile Networks 12

Notes

Chapter 3. SCCP/SUA 47
5 SCCP address component
SCCP address component

Bit 1: SPC included (1) or not (0)

Bit 2: SSN included (1) or not (0)
Bits 6,5,4,3: full GT included or not
Bit 7: routing indicator, route on SSN or GT
Bit 8: reserved for national use
Address Length
Address indicators
Usually TT = 0 Signaling Point Code
Translation Type
Global Title
NP=1 for E.164 Numbering Plan
NP=6 for IMSI SCCP Subsystem
NP=7 for E.214 Encoding Scheme Number
Nature of Address
ES=0 BCD, odd no of dig
ES=1 BCD, even no of dig. Address
Information
Indicates User Part
NA=3 for national e.g. BSSAP
NP=4 for international BCD encoded address digits

Signalling in Mobile Networks 13

SCCP Subsystem Numbers (examples):

SSN = 0 unknown/not specified
SSN = 1 SCCP management messages
SSN = 6 MAP in the HLR
SSN = 8 MAP in the MSC
SSN = 9 MAP in the EIR
SSN = 10 MAP in the AUC
SSN = 12 SMS-SC
SSN = 142 RANAP
SSN = 146 CAP
SSN = 149 MAP in the SGSN
SSN = 251 SSF in the IN
SSN = 252 SCF in the IN
SSN = 254 BSSAP

48 TeleScope,
c 2016
6 Global Title translation – routing

Global Title translation - routing

TT NP NA NS GTRC GTRC PSP SSP
0 1 4 42 1 1 2-105 2-107
0 7 4 42 1 2 2-205 2-207
0 1 4 44 2 3 2-305 2-307
0 7 4 44 2 4 OWNSP
0 1 4 49 211 3
0 7 4 49 3
0 1 4 50 4
0 7 4 50 4

AI = 49 211 546 578 MTP Transfer

NA = 4 DPC 2-305
NP = 1
TT = 0 GTRC Global Title Routing Case
NS Number Series
PSP Primary Signaling Point
SSP Secondary Signaling point
OWNSP Own Signaling Point

Signalling in Mobile Networks 16

GTRC – Global Title Routing Case

NS – Number Series
PSP – Primary Signaling Point
SSP – Secondary Signaling point
OWNSP – Own Signaling Point

Chapter 3. SCCP/SUA 49
7 SCCP Connection-Less service

Transfer of signalling message - CL

Node Called Node Called Node Called Node

A address: B address: C address: D
SSN + GT SSN + GT SSN+SPC

GT translation
indicates „B”
UDT msg

GT translation
indicates „C”
UDT msg

GT translation
indicates
termination in
„D” UDT msg

No translation
SSN used to
deliver sig. msg

Signalling in Mobile Networks 17

GTT in CL service - example
SP A STP B SP C

MSC VLR STP HLR

SSN = 7 SSN = 8 SSN = 6

UDT msg

SCCP: called party address

AI => routing based on GT UDT msg
GT= 49211345678
SSN=6
SCCP: called party address
calling party address
AI => routing based on SSN
AI => routing based on SSN
PC=A GT= 49211345678
SSN=8 SSN=6
calling party address
MTP-3 : DPC = B, OPC = A AI => routing based on SSN
PC=A
SSN=8

MTP-3 : DPC = C, OPC = B

Signalling in Mobile Networks 18

50 TeleScope,
c 2016
Chapter 3. SCCP/SUA 51
8 SCCP User Adaptation SUA

SCCP User Adaptation.

SG
SP NIF SP

SCCP SCCP SUA SUA

MTP-3 MTP-3
SCTP/IP SCTP/IP
MTP-2 MTP-2

MTP-1 MTP-1

Services Provided by the SUA Layer

• SCCP Protocol Class Support

Signalling in Mobile Networks 22
• Native Management Functions
• Interworking with SCCP Network Management Functions
• Support for the management between the SGP and ASP.
• Relay function

Signalling Network Management (SNM) Messages

• Destination State Audit (DAUD)

• Destination Unavailable (DUNA)
• Destination Available (DAVA)
• Signalling Congestion (SCON)
• Destination User Part Unavailable (DUPU)
• Destination Restricted (DRST)

SUA Management Messages

• Error (ERR)
• Notify (NTFY)

Connectionless (CL) Messages

• Connectionless Data Transfer (CLDT)

52 TeleScope,
c 2016
 • Connectionless Data Response (CLDR)

Connection-Oriented (CO) Messages

• Connection Request (CORE)

• Connection Acknowledge (COAK)
• Connection Refused (COREF)
• Release Request (RELRE)
• Release Complete (RELCO)
• Reset Confirm (RESCO)
• Reset Request (RESRE)
• Connection Oriented Data Transfer (CODT)
• Connection Oriented Data Acknowledge (CODA)
• Connection Oriented Error (COERR)
• Inactivity Test (COIT)

Chapter 3. SCCP/SUA 53
9 SUA and SCCP – examples

Establishment of SUA activity.

Establishment of SUA connectivity
ASP-a1 ASP-a2 SG SEP
(Primary) Backup)
Establish SCTP Association
Estab. SCTP Asso
Align SS7 link
ASP Up
ASP Up Ack
ASP Up
ASP Up Ack
ASP Active
ASP Active Ack
NTFY (ASP Active)
NTFY (ASP Active)
SSA
SSA
DAVA
CLDT
UDT

Signalling in Mobile Networks 26

SEP (successful) and ASP (unsuccessful) failovers.
SEP (successful) and ASP (unsuccessful) failovers
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
SSP
DUNA
DAUD
SST

after some time elapses

ASP Inactive
ASP Inactive ACK
NTFY (AS Pending)
NTFY (AS Pending)
after some time elapses (i.e., timeout).
SSP
SST
NTFY (AS Inactive)
NTFY (AS Inactive)

Signalling in Mobile Networks 27

54 TeleScope,
c 2016
Chapter 3. SCCP/SUA 55
56 TeleScope,
c 2016
Chapter 4

Layer 1-3 protocols

1 Classical and broadband transport . . . . . . . . . . . . . . . . . . . . . . 58

2 Layered structure of MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3 MPT L1 – Signalling Data Link . . . . . . . . . . . . . . . . . . . . . . . . 60
4 High Speed Signalling Link . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 MPTL2 – Signalling Link Functions . . . . . . . . . . . . . . . . . . . . . . 62
6 MTP L2 – Signal Unit Types . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Service Information Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8 M2UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9 M2PA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10 MTP L3 functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
11 MTP3 – Routing Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
12 MTP L3 – Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13 MTP3 – Load sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
14 M3 User Adaptation – M3UA . . . . . . . . . . . . . . . . . . . . . . . . . 73
15 ISDN Q.921 User Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . 75
1Classical and broadband transport
Classical and broadband transport

SS7 Users

MTP-3 MTP 3b

SSCF SSCS

SSCOP
SAAL
MTP-2 AAL5 - CPCS
AAL-5
AAL5 - SAR

ATM

MTP-1 G. 804

Signalling in Mobile Networks 3

Notes

58 TeleScope,
c 2016
2 Layered structure of MTP
Layered Structure of MTP

Level 3 Signaling Network Functions

Signaling message handling: Signaling network management:
Message discrimination Signaling link management
SS7 Users Message Routing Network control
Message distribution

Level 2 Signaling Link Functions

MTP-3 Signal unit delimitation Sequence numbers Initial alignment
Signal unit alignment Error correction LSSU messages
Error detection Buffer functions Congestion indication
Acknowledgements Signaling terminal to level 3
MTP-2 Link monitoring

MTP-1 Level 1 Signaling Data Link

Interface to transmission equipment (can be digital or analogue):
- digital: 64 kbps channel (or 2 Mbps) over PCM line
- analogue: minimum 4.8 kbps

Signalling in Mobile Networks 4

Notes

Chapter 4. Layer 1-3 protocols 59

3 MPT L1 – Signalling Data Link
Level 1 Signalling Data Link (MTP 1)

PCM Frame n

0 1 . 16 . 31 0 1 . 16 . 31 0 1 . 16 . 31 0 1 . 16 . 31

64 kbps

High Speed Signaling Link (HSL)

PCM Frame n

0 16 31 0 16 31 0 16 31 0 16 31

~ 2 Mbps

Signalling in Mobile Networks 5

Notes

60 TeleScope,
c 2016
4 High Speed Signalling Link
High Speed Signalling Link (HSL)

SS7 Users

MTP-3 MTP 3b

SSCF SSCS
SSCOP
SAAL
MTP-2 AAL5 - CPCS
AAL-5
AAL5 - SAR

ATM

MTP-1 G. 804

Signalling in Mobile Networks 6

Notes

Chapter 4. Layer 1-3 protocols 61

5 MPTL2 – Signalling Link Functions
MPTL2 – Signalling Link Functions

MTP-3

Receive Supervision Transmit

buffer buffer

Sequence number Re-transmission Sequence number

check buffer generation

Checksum
verification
MTP-2
Checksum
Message length
generation
check

Bit de-stuffing Bit stuffing

Flag detection Flag attachement

MTP-1

Signalling in Mobile Networks 11

Notes

62 TeleScope,
c 2016
6 MTP L2 – Signal Unit Types

MTP2 – Signal Unit Types

F B
F CK SIF SIO LI I FSN I BSN F MSU
B B
8 16 8n, n>2 8 2 6 1 7 1 7 8

F B
F CK SF LI I FSN I BSN F LSSU
B B
8 16 8 or 16 2 6 1 7 1 7 8

F B
F CK LI I FSN I BSN F FISU
B B
8 16 2 6 1 7 1 7 8

Signalling in Mobile Networks 7

BIB Backward Indicator Bit

BSN Backward Sequence Number
CK Check bits
F Flag
FIB Forward Indicator Bit
FSN Forward Sequence Number
LI Length Indicator
SF Status Field
SIF Signaling Information Field
SIO Service Information Octet
CK – Check bits
Used in error detection process
Checksum generated at the transmitting end and recalculated at the receiving end
Results then are compared at the bit level
Error Correction Fields
BSN field (7 bits) – acknowledges correct reception of a signal unit

Chapter 4. Layer 1-3 protocols 63

BIB field (1 bit) – positive acknowledgement if the BIB value is the same as the one in
the recently received signal unit, otherwise negative acknowledgement
FSN field (7 bits) – assists in detection of out-of-sequence signal units
FIB field (1 bit) – if its value is identical to the one in the previous unit – the signal unit
has been sent for the fist time, otherwise the received signal unit is a retransmitted one
Length Indicator
Indicates the number of octets between the LI and the CK fields:
LI > 2 MSU
LI=1 or 2 LSSU
LI=0 FISU
If SIF is greater than 62 octets, then LI = 63.

Notes

64 TeleScope,
c 2016
7 Service Information Octet
Service Information Fields

SIF is used to associate the signalling message with a specific User Part.

Sub-service field

Service indicator
Network Spare bits
indicator

NI bits
00 International Number
01 Spare (for international use only)
10 National network
Signalling in Mobile Networks 9
11 Reserved for national use
Spare bits
If NI=00 and 01: reserved, always 00
If NI=10 and 11: spare for national use
SI octet (selected)
0000 Signaling Network Management
0001 Signaling Nework Testing and Maintenance
0011 SCCP
0101 ISUP
1100 Q.2630
1101 BICC
1110 GCP/H.248
Service Information Field (SIF)
Conveys user information (upper layer protocol messages) and routing information.
Routing label is used at the MTP 3 lavel and has different formats depending on the
MTP user.
SIF size:

• greater or equal to 3 octets

• not greater than 273 octects (4095 octets on ATM based MTP links)

Chapter 4. Layer 1-3 protocols 65

 MTPL2 User Adaptation
8 M2UA

MTPL2 User Adaptation.

SP MGC
SG
ISUP ISUP
MTP-3 NIF MTP-3
MTP-2 MTP-2 M2UA M2UA
MTP-1 MTP-1 SCTP/IP SCTP/IP

M2UA messages:

Signalling in Mobile Networks

• DATA 13
• ESTABLISH (REQ, CFM)
• RELEASE (REQ, IND)
• STATE (REQ, IND, CFM)
• CONGESTION IND
• RETRIEVAL (REQ, CFM, IND)
• ASP (Up, Down, Active, Inactive) / HEARTBEAT
• ERROR / NTFY

M2UA specific parameters include:

• Link Key
• Protocol Data 1 and 2 (TTC)
• State Request and Event
• Congestion Status
• Discard Status
• Sequence Number
• Signalling Data Terminal (SDT) Identifier
• Signalling Data Link (SDL) Identifier
• ...

66 TeleScope,
c 2016
9 MTPL2 Peer-to-peer Adaptation M2PA

MTPL2 Peer-to-Peer Adaptation.

SP SG SP

SCCP SCCP
SCCP
MTP-3 MTP-3
MTP-3

MTP-2 MTP-2 M2PA M2PA

MTP-1 MTP-1 SCTP/IP SCTP/IP

M2PA provides MTP2 functionality that is not provided by M2UA/SCTP. Together M2PA
and SCTP provide in
Signalling functionality similar to that of MTP2. SCTP provides reliable,
Mobile Networks 15 sequ-
enced delivery of messages.
M2PA functionality includes:

• Data retrieval to support the MTP3 changeover procedure

• Reporting of link status changes to MTP3
• Processor outage procedure
• Link alignment procedure

Differences between M2UA and M2PA

• M2PA: IPSP processes MTP3/MTP2 primitives.

M2UA: MGC transports MTP3/MTP2 primitives between the SG’s MTP2 and the
MGC’s MTP3 (via the NIF) for processing.
• M2PA: SG-IPSP connection is an SS7 link.
M2UA: SG-MGC connection is not an SS7 link. It is an extension of MTP to a
remote entity.
• M2PA: SG is an SS7 node with a point code.
M2UA: SG is not an SS7 node and has no point code.
• M2PA: SG can have upper SS7 layers, e.g., SCCP.
M2UA: SG does not have upper SS7 layers since it has no MTP3.
• M2PA: relies on MTP3 for management procedures.
M2UA: uses M2UA management procedures.

Chapter 4. Layer 1-3 protocols 67

10 MTP L3 functions
MTP3 - Signalling Network Functions

SCCP
ISUP

TUP
User Parts

MTP-3

Signaling Network Management Signaling Message Handling

Message
Distribution
Message Flow
Managementl
Signaling
Resource

Network
Control

Control
Policing

Terminating
Transfer

Message Message
Link set (LS) indication Routing Discrimnation

SL SL SL SL SL SL

MTP-1

Signalling in Mobile Networks 14

Responsible for reliable handling of incoming and outgoing signaling messages exchanged
between signaling points. Logically split into:

• Signalling Message Handling (traffic handling) responsible for routing of messages

towards appropriate links and local distribution within the node
• Signaling Network Management responsible for controlling the message flow, es-
tablishing and restoring signaling resources, moving traffic to alternative links or
routes in case of link failures, verifying and restricting the use of the signaling
network resources by external users (operators).

Signalling network management

Network flow control:

• Link congestion
• Transfer controlled procedure
• User part unavailability

Network control:

• Transfer prohibited procedure

68 TeleScope,
c 2016
 • Transfer restricted procedure
• Transfer allowed procedure
• Rerouting of signaling traffic

Signaling resource management:

• Link management procedure

• Processor outage procedure
• Management inhibitng procedure
• Signaling link testing

Policing:

• STP policing
• SNM policing
• Enhanced STP policing
• Enhanced STP policing

Accounting

Notes

Chapter 4. Layer 1-3 protocols 69

11 MTP3 – Routing Labels
MTP3 – Routing Lables

F B
F CK SIF SIO LI I FSN I BSN F
B B

Label type A:
MTP management Management Information SLC OPC DPC
messages

Label type B:
Signaling Information CIC OPC DPC
TUP messages SLS

Label type C:
ISUP messages Signaling Information CIC SLS OPC DPC

Label type D:
SCCP messages Signaling Information SLS OPC DPC

Signalling in Mobile Networks 15

SLC – Signaling Link Code

OPC – Originating Point Code
DPC – Destination Point Code
SLS – Signaling Link Selection
CIC – Circuit Identification Code

Notes

70 TeleScope,
c 2016
12 MTP L3 – Routing Tables

MTP3 – Routing Tables

Assignment procedures for signalling point codes are described in ITU-T standard Q.708

2-5654
F
2-246

2-6854

2-5436
2-675

Routing records in 2-6854

Destination LS Priority
2-5654 2-5654 1
2-246 2
2-246 2-246 1
2-5654 2
2-5436 2-246 1
2-675 2

Signalling in Mobile Networks 16

National numbers for SPC’s are at operator decision and own plan. International ones are
coordinated at ITU-T, with the initial structure of: continent-country-poi- e.g. 2-120-2-
Europe-Poland-TPSA.
The special orle of GMSC is to interface national (operator’s) and international network,
and do all necessary screeneing of incoming messages.

Notes

Chapter 4. Layer 1-3 protocols 71

13 MTP3 – Load sharing
MTP3 – Load sharing

2-246

SLS=0xxx
2-6854
Load sharing between
2-5436 2 Link Sets
SLS=1xxx

2-675

Load sharing between 8 Signaling Links

SL 0: SLS = x000 SL 4: SLS = x100

SL 1: SLS = x001 SL 5: SLS = x101
SL 2: SLS = x010 SL 6: SLS = x110
SL 3: SLS = x011 SL 7: SLS = x111

Signalling in Mobile Networks 17

Notes

72 TeleScope,
c 2016
14MTPL3 User AdaptationM3 User Adaptation – M3UA
Mostly used protocol from SIGTRAN family.

SP SG SP

SCCP NIF/SCCP/… SCCP

MTP-3 MTP-3 M3UA M3UA

MTP-2 MTP-2
SCTP/IP SCTP/IP
MTP-1 MTP-1

The M3UA Layer at an ASP or IPSP provides the equivalent set of primitives at its upper
Signalling
layer to in Mobile Networks
the MTP3-Users 10
as provided by the MTP Level 3 to its local MTP3-Users at an
SS7 SEP. In this way, the ISUP and/or SCCP layer at an ASP or IPSP is unaware that
the expected MTP3 services are offered remotely from an MTP3 Layer at an SGP, and
not by a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that its
local users are actually remote user parts over M3UA. In effect, the M3UA extends access
to the MTP3 layer services to a remote IP-based application. The M3UA layer does not
itself provide the MTP3 services. However, in the case where an ASP is connected to
more than one SG, the M3UA layer at an ASP should maintain the status of configured
SS7 destinations and route messages according to the availability and congestion status
of the routes to these destinations via each SG.
The M3UA layer may also be used for point-to-point signalling between two IP Server
Processes (IPSPs). In this case, the M3UA layer provides the same set of primitives
and services at its upper layer as the MTP3. However, in this case the expected MTP3
services are not offered remotely from an SGP. The MTP3 services are provided, but the
procedures to support these services are a subset of the MTP3 procedures, due to the
simplified point-to-point nature of the IPSP-to-IPSP relationship.
Management (MGMT) Messages

• Error (ERR)
• Notify (NTFY)

Transfer Messages

• Payload Data (DATA)

Chapter 4. Layer 1-3 protocols 73

SS7 Signalling Network Management (SSNM) Messages

• Destination Unavailable (DUNA)

• Destination Available (DAVA)
• Destination State Audit (DAUD)
• Signalling Congestion (SCON)
• Destination User Part Unavailable (DUPU)
• Destination Restricted (DRST)

Redundancy
Redundancy on M3UA level can be realised in 3 ways:

• Different M3UA routes – equivalent to MTPL3 routes, can be used together

• SCTP multihoming
– different addresses belong to different physical boards
– different addresses are handled thru different IP networks
• IP redundancy – addresses are routed via redundant networks (redundant switched,
routers, links)

Notes

74 TeleScope,
c 2016
1520 ISDN Q.921 User Adaptation
ISDN Q.921 User Adaptation
IUA is protocol #5 for SCTP protocol field.
IUA is protocol #5 for SCTP protocol field.

Services Provided by the SUA Layer

• SCCPBoundary
Q.921/Q.931 Protocol Class Support
Primitives Transport (QPTM) messages:

• Native
• Data Management
(Request, Functions
Indication)
• Interworking
• Unit with SCCP
Data (Request, Network Management Functions
Indication)
• Establish (Request, Confirm, Indication)
• Support for the management between the SGP and ASP.
• Release (Request, Confirm, Indication)
• Relay function
Management (MGMT) Messages:
Q.921/Q.931 Boundary Primitives Transport (QPTM) messages:
• Error (ERR)
• Data (Request, Indication)
• Notify (NTFY)
• Unit
• TEI DataRequest
Status (Request, Indication)

• Establish
• TEI (Request, Confirm, Indication)
Status Confirm
• TEI Status Indication
• Release (Request, Confirm, Indication)
• TEI Query Request
ASP State Maintenance (ASPSM) Messages

• ASP Up (ASPUP) Notes

• ASP Down (ASPDN)

• Heartbeat (BEAT)

• ASP Up Acknowledgement (ASPUP ACK)

• ASP Down Acknowledgement (ASPDN ACK)

• Heartbeat Acknowledgement (BEAT ACK)

- 90- CHAPTER 4. USER ADAPTATIONS

Chapter 4. Layer 1-3 protocols 75

76 TeleScope,
c 2016
Chapter 5

Extras

1 MSC server and Media Gateway . . . . . . . . . . . . . . . . . . . . . . . 78

2 Call setup (split architecture) . . . . . . . . . . . . . . . . . . . . . . . . . 80
3 TCAP structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4 TCAP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5 TCAP message – example . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6 TCAP message exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7 MAP – context and coding . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8 General MAP structure (fitting TCAP) . . . . . . . . . . . . . . . . . . . . 87
9 TCAP/MAP example – GPRS Attach . . . . . . . . . . . . . . . . . . . . 88
10 ISUP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
11 BICC introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12 BICC specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
13 H248 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
14 Media Gateway connection model . . . . . . . . . . . . . . . . . . . . . . 95
15 H.248/MEGACO protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
16 H.248 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
1 MSC server and Media Gateway

The Mobile-services Switching Centre (MSC) performs all necessary functions in order
to handle the circuit switched services to and from the mobile stations. When needed,
the MSC can be implemented in two different entities: the MSC Server, handling only
signalling, and the CS-MGW, handling user’s data. A MSC Server and a CS-MGW make
MSC server and Media Gateway
up the full functionality of a MSC.

Applications & Services

Nc
External Networks

MSC Server GMSC Server

PSTN/ISDN
GSM RAN HLR PLMN

Mc Mc
Internet
Nb LANs

UTRAN MGW MGW

2G Networks - Extended Course 15

The MSC Server mainly comprises the call control (CC) and mobility control parts of
a MSC. The MSC Server is responsible for the control of mobile originated and mobile
terminated CC CS Domain calls. It terminates the user-network signalling and translates
it into the relevant network – network signalling. The MSC Server also contains a VLR
to hold the mobile subscriber’s service data and CAMEL related data.
The MSC Server controls the parts of the call state that pertain to connection control
for media channels in a CS-MGW. The Circuit Switched - Media Gateway Function (CS-
MGW) is PSTN/PLMN transport termination point for a defined network and interfaces
UTRAN with the core network over Iu. A CS-MGW may terminate bearer channels from
a switched circuit network and media streams from a packet network (e.g., RTP streams
in an IP network). Over Iu, the CS-MGW may support media conversion, bearer control
and payload processing (e.g. codec, echo canceller, conference bridge) for support of
different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP based).
The CS-MGW interacts with MSC server and GMSC server for resource control.
The CS-MGW will be provisioned with the necessary resources for supporting UMTS/GSM
transport media. Further tailoring (i.e packages) of the H.248 may be required to support

78 TeleScope,
c 2016
additional codecs and framing protocols, etc. The CS-MGW bearer control and payload
processing capabilities will also need to support mobile specific functions such as SRNS
relocation/handover and anchoring.
Interfaces: The GMSC server and MSC servers are connected to the media gateway via the
Mc reference point. The H.248 protocol together with 3GPP specific extensions/packages
shall be used over the Mc interface. The MSC servers and GMSC servers are connected
with the Nc reference point. There may be a number of call control transit nodes between
the MSC server and GMSC server in the Nc reference point. Any suitable call control
protocol may be used over the Nc interface (e.g. BICC). The MGWs are connected with
the Nb reference point. The bearer control signalling and transport are carried over the
Nb interface.

Notes

Chapter 5. Extras 79
2 Call setup (split architecture)

Split of MSC into MSC Server and Media Gateway brought many changes to signalling
Call setup – split architecture
part of CS.

➄
MSC MSC
S.1 ➂ ➆ S.2
➆ ➄
 
  ➁ ① ➃
 ➄


 ➅
RNC MGw 1 MGw 2
  ➅

2G Networks - Extended Course 5

In case of outgoing call in UMTS, the number dialled by the user Ê reaches MSC Server.
(Assuming, based on HLR subscription information that the user is allowed to complete
such a call), MSC Server request Ë radio bearer (and may choose specific codec for the
call). Ì MSC server 1 selects MGw (MGw1) and asks it to allocate resources for this call
towards RNC. Allocated resorce identifier Í is sent via MSC server to RNS, which sets
up bearer Î toward given address. Success Ï is reported to MSC server to continue with
the call.
Based on B-number MSC S.1 selects MGw1 and À requests resources for onward con-
nection. Allocated Á resource address and identifier is passed on  with IAM message to
next MSC S.2. MSC S.2 requests à resource for handling the call from MSC S.1/MGw1,
which is forwarded Ä to MGw1 via MSC S.2 and MSC S.1. Then the bearer is setup Å
in forward direction. When acknowledged Å MSC S.2 can continue with call.
Specific BICC-related capabilities

• Delayed call setup

– IAM messages are exchanged and parameters negotiated BEFORE bearer se-
tup
– Bearer route optimisation or bearer redirection possible

• Flexible bearer handling

80 TeleScope,
c 2016
 – Transcoder Free Operation
– Tandem Free Operation
• Forward or backward bearer setup

– Forward: bearer is setup in direction of call setup

– Backward: bearer is setup in the opposite direction than call setup

Notes

Chapter 5. Extras 81
3 TCAP structure

TCAP structure
Dialogue
MAP (TC-User) MAP (TC-User)
Dialogue Component
Primitive Primitive

TCAP TCAP

Component Sublayer Component Sublayer

Transaction Sublayer Transaction Transaction Sublayer

SCCP

Signalling in Mobile Networks 4

Dialogue Handling:

• Structured dialogue (allows several flows of components to co-exist between two

TC users, a distinction between dialogues is made with the use of dialog identifiers)
• Unstructured dialogue (not used in GSM or WCDMA systems)

Component handling – provides four classes of operation for structured dialogs:

• Class 1: Both success and failure are reported

• Class 2: Only failure is reported
• Class 3: Only success is reported
• Class 4: Neither success nor failure is reported

82 TeleScope,
c 2016
4 TCAP messages TCAP messages

There are 5 TCAP messages.

There are five TCAP messages:

Originating Transation ID
Dialogue Portion
- Begin Component Portion
Originating Transation ID
Destination Transaction ID
- Continue Dialogue Portion
Component Portion

Destiantion Transation ID
- End Dialogue Portion
Component Portion

- Abort Destiantion Transation ID

Abort reason

Dialogue Portion
- Unidirectional Component Portion

Signalling in Mobile Networks 6

Notes

Chapter 5. Extras 83
5 TCAP message – example
TCAP message - example
Tag Message type (e.g. BEGIN)
Length Message length
Tag Originating transaction ID
Length ID length
Value ID
Dialogue portion

Tag Dialogue portion

Length Dialogue portion length
TCAP Message

Value Dialogue

Tag Component portion

Length Component portion length
Component portion

Component type (e.g. Invoke)

Component length
First component

Invoke ID
ID
Length

Signalling in Mobile Networks 9

Notes

84 TeleScope,
c 2016
6 TCAP message exchange
TCAP message exchange

Node Node
B A

Begin Dialogue Invoke #1 Invoke #2 Invoke #3

transaction request User op. User op. User op.

Continue Dialogue Invoke #4 Error #2

transaction response User op. User op.

Continue Result #4
transaction User op.

End Result #3 Result #1

transaction User op. User op.

Signalling in Mobile Networks 10

Notes

Chapter 5. Extras 85
7 MAP – context and coding
Application context name

04 hex

00 hex

00 hex GSM/WCDMA application

context name „object”

01 hex

00 hex

Application context e.g. Location updating

MAP protocol version e.g. MAP V3

Signalling in Mobile Networks 15

Example MAP definition:

sendAuthenticationInfo OPERATION
ARGUMENT
sendAuthenticationInfoArg OCTET STRING ( SIZE (3 .. 8 ) )
RESULT
sendAuthenticationInfoRes SEQUENCE SIZE (1 .. 5 ) OF
SEQUENCE {
rand OCTET STRING ( SIZE (16 ) ),
sres OCTET STRING ( SIZE (4 ) ),
kc OCTET STRING ( SIZE (8 ) ),
... }
ERRORS {
-- systemFailure -- localValue : 34,
-- dataMissing -- localValue : 35,
-- unexpectedDataValue -- localValue : 36,
-- unknownSubscriber -- localValue : 1
}
::= localValue : 56

86 TeleScope,
c 2016
8 General MAP structure (fitting TCAP)
General MAP structure (fitting TCAP)

Tag Component type (e.g. Invoke)

Length Component length

Invoke ID
Length
ID
Operation code
Length
e.g. Send Parameters

e.g. IMSI

Signalling in Mobile Networks 17

Notes

Chapter 5. Extras 87
9 TCAP/MAP example – GPRS Attach
TCAP/MAP procedure example

SGSN HLR
Dialogue Invoke#1
Begin

Request Send Authentication Info

(MAP V3) IMSI, request = authen data

Dialogue Result#1

End
Request Send Authentication Info
(V3 acc) RAND, SRES, Kc

Dialogue Invoke#1
Begin

Request Update GPRS Location

(MAP V3) IMSI, SGSN addr

Continue Dialogue Invoke#2

Request Insert GPRS Subscriber Data
(V3 acc.) MSISDN, IMSI, APN, SMS, CAMEL
Continue

Result#2

Result#1
End

Update GPRS Location

HLR addr.

Signalling in Mobile Networks 18

Notes

88 TeleScope,
c 2016
10 ISUP messages

Example of call setup is presented in figure ??.

ISUP call setup

MSC TSC
MS

IAM
dials number

ACM
IAM

ANM
ANM
connected

disconnects REL
REL

Example ISUP messages:

• IAM (Initial Address Message)

• SAM (Subsequent Address Message)
• ACM (Address Complete Message)
• CPG (Call Progress Message)
• ANM (Answer Message)
• REL (Release Message)
• RLC (Release Complete Message)
• CON (Connect Message)
• COT (Continuity)
• CFN (Confusion)
• PAM (Pass-along)
• BLO (Blocking)
• UBL (Unblocking)

ISUP message structure.

Message:

Chapter 5. Extras 89
 • CIC (12-bit Circuit Identification Code, MTP3 SIF label C)
• 8-bit message type
• mandatory fixed part
• mandatory variable part
• optional part

Parameters examples:

• called party number

• calling party number
• nature of connection
• forward call indicators
• transmission medium requirement
• location number
• message compatibility information
• parameter compatibility information
• free phone indicators

90 TeleScope,
c 2016
11 BICC introduction

BICC – Bearer Independent Call Control.

• Result of separation of call and bearer control

• Adaptation of ISUP
– all ISUP services supported
– most of ISUP messages and parameters are inherited
– not supported messages: BLO, BLA, UBL, UBA, CCR, LPA, OLM, PAM,
UPA, UPT
– not peer-to-peer compatible with ISUP
– defines new features, messages and parameters
• Capability sets

– CS1 – Q.1901
– CS2 – Q.1902

BICC functional model.

• Call Service Function

– Call Instance Code
• Call Bearer Control signalling

– GCP – large generic protocol

– Q.1950 – GCP packages that meets BICC needs
• Bearer Interwork Function

– Bearer Control Unit (subset of BIWF)

∗ Bearer Control Function

Chapter 5. Extras 91
12 BICC specifics

BICC Specific Features.

BICC specific features:

• Bearer setup
– forward connect: in the direction of call setup (IAM)
– backward connect: in the opposite direction of call setup
– fast or delayed
– notification
• Idle bearer reuse
• Bearer redirection
• Codec negotiations
• BICC tunnelling
• New APM – Application Transport Message

BICC Specific Information Elements.

• BCU identifier
– MGw unique identifier
• BIWF Address
– bearer node address used for routing
• Bearer Network Connection characteristics (BNCchar)
– bearer type: AAL1, AAL2, RTP/IP etc.
• Bearer Network Connection Identifier (BNC-ID)
– bearer “address” associated with CIC
• Bearer Application Transport
– BICC tunnelling
– New APM – Application Transport Message

BICC Specific Capabilities.

• Delayed call setup

– IAM messages are exchanged and parameters negotiated BEFORE bearer se-
tup
– Bearer route optimisation or bearer redirection possible
• Flexible bearer handling

92 TeleScope,
c 2016
 – Transcoder Free Operation
– Tandem Free Operation
• Forward or backward bearer setup

– Forward: bearer is setup in direction of call setup

– Backward: bearer is setup in the opposite direction than call setup

Notes

Chapter 5. Extras 93
13 H248 introduction

Standards for Gateway Control Protocol (3GPP)

• H.248 by ITU-T
• MEGACO (RFC3015) by IETF

Media Gateway Controller

• master in control layer

• MSC Server typically

Media Gateway

• slave in transport layer

• implements Virtual Gateways

Connection Model

• terminations
• contexts
• streams

Notes

94 TeleScope,
c 2016
14 Media Gateway connection model

The connection model for media gateways defines relationship between contexts, termi-
nations and streams, together with their parameters.
MGw Connection Model

Termination ROOT

Context Termination
SCN Bearer
Channel

Termination
*
Termination
RTP Stream SCN Bearer
Channel

Context NULL Context

Termination
Termination
* SCN Bearer
RTP Stream Channel

Context

Termination Termination

RTP Stream
* SCN Bearer
Channel

30

Terminations:

• Logical representation of resource

– bearers (TDM, ATM, IP)
– codec’s
– echo cancellers
– announcements
• Physical
– created via other provisional method
– cannot be destroyed or created on-demand
– e.g. TDM line
• Ephemeral
– created and destroyed on-demand
– deleted ceases to exists
– e.g. ATM VC

Chapter 5. Extras 95
 • ROOT termination
– entire MGw

Context:

• association between terminations

• termination belongs to exactly one context
• NULL Context
– idle physical resources
• attributes
– Context ID, Priority
– Topology: isolate, oneway, bothway

Stream:

• call or data stream

• terminates or originates in termination

Notes

96 TeleScope,
c 2016
15 H.248/MEGACO protocol

Commands:

• MGC to MGw

– ADD
– MOVE
– SUBSTRACT
– MODIFY
– AUDITVALUE
– SERVICECHANGE
• MGw to MGC

– NOTIFY
– SERVICECHANGE

Commands parameters:

• Descriptors

– termination descriptors
– context descriptors
– basic or structured
• Packages

– additional functionality
– added as H.248 Annexes
• Wildcards

– ALL
– CHOOSE

Termination ID:

• Binary or text coded

• Text Encoding

– arbitrary string
– for ALL, $ for CHOOSE
• Binary Encoding

– wildcarding
– 3 bits for access: TDM, non-TDM, ROOT
– for TDM

Chapter 5. Extras 97
 ∗ 3bits transport, 21 bits system nr, individual
– non-TDM
∗ 29 bits ephemeral individual

Descriptors:

• Media: Termination State + Local Control + Local + Remote

• Termination State
– ServiceState: InService, Out-of-service, Test
– EventBufferControl
• Local Control
– Mode: send-only, receive-only send/receive, inactive
– ReserveGroup: true, false
– ReserveValue
– stream specific from package
• Local
– describes streams received by MGw
• Remote

– describes streams transmitted by MGw

• Events
– EventName
– SteamID
– KeepActive: true, false
• Signals

– Name
– StreamID
– SignalType: on/off, timeout, brief
– Duration
– NotifyCompletion
– KeepActive
• Observed Events
– RequestID
– Event

98 TeleScope,
c 2016
16 H.248 Annexes

H.248 Annexes contain extensions to H.248 protocol (or references to them). They are
used to simplify description of controller and media gateway capabilities.
H.248 Annexes contain complete extensions:

• Additional functionality put in groups

• Packages may extend other packages
• Packages come in versions
• Examples
– E.1 – Generic Package
– E.2 – Base Root Package
– E.13 – TDM Circuit Package
– C.3 – General Bearer Properties (BIR, NSAP)
– H.248.7 – Generic Announcements Package
– 3GPP TS 29.232 – 3GUP (user plane) Package
– Q.1950 A.3 – Bearer Characteristics Package

MGw profile:

• Set of features and capabilities

• Negotiated at MGw registration
– SERVICECHANGE command
– ROOT termination
• Contains (among others)
– identification
– naming conventions
– transport
– encoding
– supported packages
– security
– procedures

Chapter 5. Extras 99