398 lines
16 KiB
Plaintext
398 lines
16 KiB
Plaintext
== Signaling Networks: SS7 and SIGTRAN
|
|
|
|
Classic digital telephony networks (whether wired or wireless) use the
|
|
ITU-T SS7 (Signaling System 7) to exchange signaling information
|
|
between network elements.
|
|
|
|
Most of the ETSI/3GPP interfaces in the GSM and UMTS network are also
|
|
based on top of [parts of] SS7. This includes, among others, the
|
|
following interfaces:
|
|
|
|
* _A_ interface between BSC and MSC
|
|
* _IuCS_ interface between RNC (or HNB-GW) and MSC
|
|
* _IuPS_ interface between RNC (or HNB-GW) and SGSN
|
|
|
|
NOTE: This does not include the A-bis interface between BTS and BSC.
|
|
While Abis traditionally is spoken over the same physical TDM circuits
|
|
as SS7, the protocol stack from L2 upwards is quite different (Abis
|
|
uses LAPD, while SS7 uses MTP)!
|
|
|
|
=== Physical Layer
|
|
|
|
The traditional physical layer of SS7 is based on TDM (time division
|
|
multiplex) links of the PDH/SDH family, as they were common in ISDN
|
|
networks. Some people may know their smallest incarnation as
|
|
so-called E1/T1 links. It can run either on individual 64kBps
|
|
timeslots of such a link, or on entire 2Mbps/1.5MBps E1/T1 links.
|
|
|
|
There are also specifications for SS7 over ATM, though it is unclear
|
|
to the author if this is actually still used anywhere.
|
|
|
|
On top of the Physical Layer is the Message Transfer Part (MTP).
|
|
|
|
=== Message Transfer Part (MTP)
|
|
|
|
MTP is the lower layer of the SS7 protocol stack. It is comprised of
|
|
two sub-layers, called MTP2 and MTP3.
|
|
|
|
Nodes in a MTP network are addressed by their unique PC (Point Code).
|
|
|
|
A _MTP Routing Label_ is in the MTP header and indicates the
|
|
_Originationg Point Code_ (OPC) as well as the _Destination Point
|
|
Code_ (DPC) and the _Service Indicator Octet_ (SIO). The SIO is used
|
|
to de-multiplex between different upper-layer protocol such as ISUP,
|
|
TUP or SCCP.
|
|
|
|
Routing is performed by means of routers with routing tables, similar
|
|
to routing is performed in IP networks. Even the concept of a _point
|
|
code mask_ analogous to the _netmask_ exists.
|
|
|
|
Routers are connected with one another over one or more _Link Sets_,
|
|
each comprised of one or multiple _Links_. Multiple Links in a
|
|
Linkset exist both for load sharing as well as for fail over purposes.
|
|
|
|
==== Point Codes
|
|
|
|
The length of point codes depends on the particular MTP dialect that
|
|
is used. In the 1980s, when international telephony signaling
|
|
networks were established, most countries had their own national
|
|
dialects with certain specifics.
|
|
|
|
Today, mostly the ITU and ANSI variants survive. The ITU variant uses
|
|
14bit point codes, while the ANSI variant uses 24 bit point code
|
|
length.
|
|
|
|
Point Codes can be represented either as unsigned integers, or
|
|
grouped. Unfortunately there is no standard as to their
|
|
representation. In ITU networks, the _3.8.3_ notation is commonly
|
|
used, i.e. one decimal for the first 3 bits, followed by one decimal
|
|
for the center 8 bits, followed by another decimal for the final 3
|
|
bits.
|
|
|
|
Example:: The Point Code *1.5.3* (in 3.8.3 notation) is 1*2^11^ + 5*2^3^ + 3 = *2091 decimal*.
|
|
|
|
=== Higher-Layer Protocols
|
|
|
|
There are various higher-layer protocols used on top of MTP3, such as
|
|
TUP, ISUP, BICC as well as SCCP. Those protocols exist side-by-side
|
|
on top of MTP3, similar to e.g. ICMP, TCP and UDP existing
|
|
side-by-side on top of IP.
|
|
|
|
In the context of cellular networks, SCCP is the most relevant part.
|
|
|
|
=== Signaling Connection Control Part (SCCP)
|
|
|
|
SCCP runs on top of MTP3 and creates something like an overlay network
|
|
on top of it. SCCP communication can e.g. span multiple different
|
|
isolated MTP networks, each with their own MTP dialect and addressing.
|
|
|
|
SCCP provides both connectionless (datagram) and connection-oriented
|
|
services. Both are used in the context of cellular networks.
|
|
|
|
==== SCCP Addresses
|
|
|
|
SCCP Addresses are quite complex. This is due to the fact that it is
|
|
not simply one address format, but in fact a choice of one or multiple
|
|
different types of addresses.
|
|
|
|
SCCP Addresses exist as _Calling Party_ and _Called Party_ addresses.
|
|
In the context of connectionless datagram services, the sender is
|
|
always the Calling Party, and the receiver the Called Party. In
|
|
connection-oriented SCCP, they resemble the initiator and recipient of
|
|
the connection.
|
|
|
|
.SCCP Address Parts
|
|
[options="header",cols="10%,20%,70%"]
|
|
|====
|
|
|Acronym|Name|Description
|
|
|SSN|Sub-System Number|Describes a given application such as e.g. a
|
|
GSM MSC, BSC or HLR. Can be compared to port
|
|
numbers on the Internet
|
|
|PC|Point Code |The Point Code of the underlying MTP network
|
|
|GT|Global Title |What most people would call a "phone number".
|
|
However, Global Titles come in many different
|
|
numbering plans, and only one of them (E.164)
|
|
resembles actual phone numbers.
|
|
|RI|Routing Indicator |Determines if message shall be routed on PC+SSN
|
|
or on GT basis
|
|
|====
|
|
|
|
==== Global Titles
|
|
|
|
A Global Title is a (typically) globally unique address in the global
|
|
telephony network. The body of the Global Title consists of a series
|
|
of BCD-encoded digits similar to what everyone knows as phone numbers.
|
|
|
|
A GT is however not only the digits of the "phone number", but also
|
|
some other equally important information, such as the _Numbering Plan_
|
|
as well as the _Nature of Address Indication_.
|
|
|
|
.Global Title Parts
|
|
[options="header",cols="10%,20%,70%"]
|
|
|====
|
|
|Acronym|Name|Description
|
|
|GTI|Global Title Indicator|Determines the GT Format. Ranges from no
|
|
GT (0) to GT+TT+NP+ES+NAI (4)
|
|
|NAI|Nature of Address Indicator|Exists in GTI=1 and is sort of a mixture of TON + NPI
|
|
|TT|Translation Type |Used as a look-up key in Global Title Translation Tables
|
|
|NP|Numbering Plan |Indicates ITU Numbering Plan, such as E.164, E.212, E.214
|
|
|ES|Encoding Scheme |Just a peculiar way to indicate the length of the digits
|
|
|- |Signals |The actual "phone number digits"
|
|
|====
|
|
|
|
For more information about SCCP Addresses and Global Titles, please
|
|
refer to <<itu-t-q713>>
|
|
|
|
|
|
==== Global Title Translation (GTT)
|
|
|
|
Global Title Translation is a process of re-writing the Global Title
|
|
on-the-fly while a signaling message passes a STP.
|
|
|
|
Basically, a SCCP message is first transported by MTP3 on the MTP
|
|
level to the Destination Point Code indicated in the MTP Routing
|
|
Label. This process uses MTP routing and is transparent to SCCP.
|
|
|
|
Once the SCCP message arrives at the MTP End-Node identified by the
|
|
Destination Point Code, the message is handed up to the local SCCP
|
|
stack, which then may implement Global Title Translation.
|
|
|
|
The input to the GTT process is
|
|
|
|
* the destination address of the SCCP message
|
|
* a local list/database of Global Title Translation Rules
|
|
|
|
The successful output of he GTT includes
|
|
|
|
* A new Routing Indicator
|
|
* The Destination Point Code to which the message is forwarded on MTP
|
|
level
|
|
* a Sub-system Number (if RI is set to "Route on SSN")
|
|
* a new Global Title (if RI is set to "Route on GT"), e.g. with translated digits.
|
|
|
|
Between sender and recipient of a signaling message, there can be many
|
|
instances of Global Title Translation (up to 15 as per the hop
|
|
counter).
|
|
|
|
For more information on Global Title Translation, please refer to
|
|
<<itu-t-q714>>.
|
|
|
|
|
|
==== Peculiarities of Connection Oriented SCCP
|
|
|
|
Interestingly, Connection-Oriented SCCP messages carry SCCP Addresses
|
|
*only during connection establishment*. All data messages during
|
|
an ongoing connection do not contain a Called or Calling Party
|
|
Address. Instead, they are routed only by the MTP label, which is
|
|
constructed from point code information saved at the time the
|
|
connection is established.
|
|
|
|
This means that connection-oriented SCCP can not be routed across MTP
|
|
network boundaries the same way as connectionless SCCP messages.
|
|
Instead, an STP would have to perform _connection coupling_, which is
|
|
basically the equivalent of an application-level proxy between two
|
|
SCCP connections, each over one of the two MTP networks.
|
|
|
|
This is probably mostly of theoretical relevance, as
|
|
connection-oriented SCCP is primarily used between RAN and CN of
|
|
cellular network inside one operator, i.e. not across multiple MTP
|
|
networks.
|
|
|
|
=== SIGTRAN - SS7 over IP Networks
|
|
|
|
At some point, IP based networks became more dominant than classic
|
|
ISDN networks, and 3GPP as well as IETF were working out methods in
|
|
which telecom signaling traffic can be adapted over IP based
|
|
networks.
|
|
|
|
Initially, only the edge of the network (i.e. the applications talking
|
|
to the network, such as HLR or MSC) were attached to the existing old
|
|
SS7 backbone by means as SUA and M3UA. Over time, even the links of
|
|
the actual network backbone networks became more and more IP based.
|
|
|
|
In order to replace existing TDM-based SS7 links/linksets with SIGTRAN,
|
|
the M2UA or M2PA variants are used as a kind of drop-in replacement
|
|
for physical links.
|
|
|
|
All SIGTRAN share that while they use IP, they don't use TCP or UDP
|
|
but operate over a (then) newly-introduced Layer 4 transport protocol
|
|
on top of IP: SCTP (Stream Control Transmission Protocol).
|
|
|
|
Despite first being specified in October 2000 as IETF RFC 2960, it
|
|
took a long time until solid implementations of SCTP ended up in
|
|
general-purpose operating systems. SCTP is not used much outside the
|
|
context of SIGTRAN, which means implementations often suffer from bugs,
|
|
and many parts of the public Internet do not carry SCTP traffic due to
|
|
restrictive firewalls and/or ignorant network administrators.
|
|
|
|
==== SIGTRAN Concepts / Terminology
|
|
|
|
Like every protocol or technology, SIGTRAN brings with it its own
|
|
terminology and concepts. This section tries to briefly introduce
|
|
them. For more information, please see the related IETF RFCs.
|
|
|
|
===== Signaling Gateway (SG)
|
|
|
|
The Signaling Gateway (SG) interconnects the SS7 network with external
|
|
applications. It translates (parts of) the SS7 protocol stack into an
|
|
IP based SIGTRAN protocol stack. Which parts at which level of the
|
|
protocol stack are translated to what depends on the specific SIGTRAN
|
|
dialect.
|
|
|
|
A SG is traditionally attached to the TDM-Based SS7 network and offers
|
|
SIGTRAN/IP based applications a way to remotely attach to the SS7
|
|
network.
|
|
|
|
A SG typically has STP functionality built-in, but it is not
|
|
mandatory.
|
|
|
|
===== Application Server (AS)
|
|
|
|
An Application Server is basically a logical entity representing one
|
|
particular external application (from the SS7 point of view) which is
|
|
interfaced with the SS7 network by means of one of the SIGTRAN
|
|
protocols.
|
|
|
|
An Application Server can have one or more Application Server Processes
|
|
associated with it. This functionality can be used for load-balancing or
|
|
fail-over scenarios.
|
|
|
|
===== Application Server Process (ASP)
|
|
|
|
An Application Server Process represents one particular SCTP
|
|
connection used for SIGTRAN signaling between an external application
|
|
(e.g. a BSC) and the Signaling Gateway (SG).
|
|
|
|
One Application Server Process can route traffic for multiple
|
|
Application Servers. In order to differentiate traffic for different
|
|
Application Servers, the Routing Context header is used.
|
|
|
|
==== SIGTRAN variants / stackings
|
|
|
|
SIGTRAN is the name of an IETF working group, which has released an
|
|
entire group of different protocol specifications. So rather than one
|
|
way of transporting classic telecom signaling over IP, there are now
|
|
half a dozen different ones, and all can claim to be an official IETF
|
|
standard.
|
|
|
|
FIXME: Overview picture comparing the different stackings
|
|
|
|
===== MTP3 User Adaptation (M3UA)
|
|
|
|
M3UA basically "chops off" everything up to and including the MTP3
|
|
protocol layer of the SS7 protocol stack and replaces it with a stack
|
|
comprised of M3UA over SCTP over IP.
|
|
|
|
M3UA is specified in <<ietf-rfc4666>>.
|
|
|
|
M3UA is the SIGTRAN variant chosen by 3GPP for A, IuCs and IuPS
|
|
interfaces over IP.
|
|
|
|
===== SCCP User Adaptation (SUA)
|
|
|
|
SUA basically "chops off" everything up to and including the SCCP
|
|
protocol layer of the SS7 protocol stack and replaces it with a stack
|
|
comprised of SUA over SCTP over IP.
|
|
|
|
This means that SUA can only be used for SCCP based signaling, but not
|
|
for other SS7 protocols like e.g. TUP and ISUP.
|
|
|
|
SUA is specified in <<ietf-rfc3868>>.
|
|
|
|
===== MTP2 User Adaptation (M2UA)
|
|
|
|
M2UA is specified in <<ietf-rfc3331>>.
|
|
|
|
NOTE: M2UA is not supported in Osmocom SIGTRAN up to this point. Let
|
|
us know if we can implement it for you!
|
|
|
|
===== MTP2-User Peer-to-Peer Adaptation (M2PA)
|
|
|
|
M2PA is specified in <<ietf-rfc4165>>.
|
|
|
|
NOTE: M2PA is not supported in Osmocom SIGTRAN up to this point. Let
|
|
us know if we can implement it for you!
|
|
|
|
|
|
==== SIGTRAN security
|
|
|
|
There simply is none. There are some hints that TLS shall be used
|
|
over SCTP in order to provide authenticity and/or confidentiality for
|
|
SIGTRAN, but this is not widely used.
|
|
|
|
As telecom signaling is not generally carried over public networks,
|
|
private networks/links by means of MPLS, VLANs or VPNs such as IPsec
|
|
are often used to isolate and/or secure SIGTRAN.
|
|
|
|
Under no circumstances should you use unsecured SIGTRAN with
|
|
production data over the public internet!
|
|
|
|
==== IPv6 support
|
|
|
|
SCTP (and thus all the higher layer protocols of the various SIGTRAN
|
|
stackings) operates on top of both IPv4 and IPv6. As the entire
|
|
underlying IP transport is transparent to the SS7/SCCP applications,
|
|
there is no restriction on whether to use SIGTRAN over IPv4 or IPv6.
|
|
|
|
==== SCTP multi-homing in SIGTRAN
|
|
|
|
SCTP, unlike more traditional IP L4 protocols (TCP, UDP) doesn't work
|
|
based on a _connection_ between source IP:port and Destination IP:port.
|
|
|
|
Instead, SCTP creates _associations_ between two endpoints, both of which
|
|
can have any number of IP addresses. This means that in case of
|
|
network outage, traffic can continue to flow through any of the IP
|
|
addresses of that association.
|
|
|
|
The Linux kernel by default advertises all IP addresses of the local
|
|
system to the peer. This can be seen when inspecting the SCTP INIT
|
|
chunk e.g. in wireshark. While this may be a reasonable default in some
|
|
use cases, it is not always the best idea. Imagine addresses of
|
|
internal/private IP networks, for example local bridge devices between
|
|
lxc or docker containers, or local VMs. Such addresses have no
|
|
significance beyond the local machine.
|
|
|
|
Subsequently, libosmo-sigtran allows the user to explicitly select which
|
|
local IP addresses shall be used in SCTP multi-homing for the SIGTRAN
|
|
associations it manages. The user can achieve this by specifying
|
|
multiple `local-ip` VTY commands within one `asp` (SCTP client role) or
|
|
within one `listen m3ua 2905` (SCTP server role).
|
|
|
|
==== SCTP role
|
|
|
|
The _SCTP role_ defines which of the two L4 protocol roles SCTP assumes:
|
|
|
|
* The _SCTP server_ role binds to a local port and handles incoming
|
|
connections from clients
|
|
* The _SCTP client_ role connects to a remote SCTP sever.
|
|
|
|
==== M3UA/SUA role
|
|
|
|
The _M3UA role_ (or _SUA role_) determines which role a given peer of a
|
|
M3UA connection implements. 3GPP specifies the following role:
|
|
|
|
* _SGP_ (Signaling Gateway): The entity connected to the larger SS7
|
|
network
|
|
* _ASP_ (Application Server Process): A client application that connects
|
|
to the SGW to talk to the SS7 network
|
|
* _IPSP_ (IP Server Process): M3UA in point-to-point mode
|
|
|
|
Osmocom (libosmo-sigtran) implements both the SGP and ASP roles, but not
|
|
the IPSP role.
|
|
|
|
==== Traffic Modes in SIGTRAN
|
|
|
|
Whenever an AS consists of multiple ASPs, the traffic mode expresses how
|
|
messages are distributed between those ASPs.
|
|
|
|
* _Override_: There is always one active ASP and multiple hot standby
|
|
ASPs. If the active ASP fails, one of the remaining ASPs will become
|
|
the new active ASP.
|
|
* _Loadshare_: The messages will be distributed between the different
|
|
ASPs in a way to distribute the load among them. Details are
|
|
implementation specific.
|
|
* _Broadcast_: A copy of every incoming signaling message is sent to
|
|
_all_ the ASPs in broadcast traffic mode.
|
|
|
|
Osmocom (libosmo-sigtran) implements all above-mentioned traffic modes.
|