== 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 <> ==== 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 <>. ==== 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 <>. 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 <>. ===== MTP2 User Adaptation (M2UA) M2UA is specified in <>. 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 <>. 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 Primary Address SCTP has the concept of "primary address" in an association. The primary address is a remote address selected from those announced by the peer, and it is the "active" one chosen to transmit user data. The other remote addresses, that are not used, are kept as backups. They are in general only used to transmit user data whenever the SCTP implementation decides to change the primary address, be it due to user policy configuration change or due to the previous primary link becoming unusable. Only confirmed remote addresses (through HEARTBEAT mechanism) are electable to be used as primary address. By default, the Linux kernel SCTP stack implementation will probably take the first remote address provided at connect() time in order to start the initial handshake, and continue with next provided remote addresses if the first one fails to confirm the handshake. The remote address which successfully confirmed the handshake is then used as a primary address (since it's likely the only confirmed so far), and will be kept until the link is considered down. Some deployment setups may have requirements on preferred links to be used when transmitting data (eg. network setups with primary and secondary paths). This can be accomplished by explicitly notifying the kernel to use one of the remote addresses through the SCTP_PRIMARY_ADDR sockopt, plus monitoring the address availability changes on the socket and re-enforcing the primary address when it becomes available again. This is supported in the Osmocom SIGTRAN stack by using the `primary` parameter in one of the `remote-ip` commands under the `asp` node: ---- cs7 instance 0 asp my-asp 2905 0 m3ua remote-ip 10.11.12.13 remote-ip 16.17.18.19 primary <1> ... ---- <1> Use 16.17.18.19 as primary address for the SCTP association. User data will be in general transmitted over this path. ==== SCTP Peer Primary Address The SCTP extension ASCONF (RFC5061) allows, when negotiated and supported by both peers, to dynamically announce to the peer the addition or deletion of IP addresses to the association. It also allows one peer announcing to the other peer the desired IP address it should be using as a primary address when sending data to it. In the Linux kernel SCTP stack, this is accomplished by setting the sockopt SCTP_SET_PEER_PRIMARY_ADDR, which will trigger an ASCONF SCTP message to the peer with the provided local IP address. This is supported in the Osmocom SIGTRAN stack by using the `primary` parameter in one of the `local-ip` commands under the `asp` node: ---- cs7 instance 0 asp my-asp 2905 0 m3ua local-ip 10.11.12.13 local-ip 16.17.18.19 primary <1> ... ---- <1> Announce 16.17.18.19 to the peer as the primary address to be used when transmitting user data to us. In order to be able to use this feature, the SCTP association peer must support the ASCONF extension. The extension support is negotiation during the INIT handshake of the association. Furthermore, for ASCONF features to work properly, the assoc also needs to announce/use the AUTH extension, as per RFC5061 section 4.2.7. Otherwise, the peer receiving an SCTP INIT with `ExtensionFeatures=ASCONF,ASCONF_ACK`` but without AUTH, will reject the association with an ABORT since it's not complying with specifications (this behavior can be tweaked through sysctl "net.sctp.addip_noauth_enable"). As of the time of writing this documentation (linux 6.4.12) and since basically ever, those extensions are runtime-disabled by default. They can be enabled per socket using the kernel sockopts SCTP_ASCONF_SUPPORTED and SCTP_AUTH_SUPPORTED, and that's what the Osmocom stack is currently doing for all SCTP sockets. However, those sockopts are farily new (linux v5.4), which means user running older kernels will see in the logs setting those sockopts fail, but connection will keep ongoing, simply without those features available (so setting `primary` in the configuration won't have any effect here). On those older kernels, if this feature is still desired, it can be used by means of enabling the SCTP extensions in all socket system-wide through sysctl: ---- net.sctp.auth_enable=1 net.sctp.addip_enable=1 ---- ==== SCTP INIT Parameters Several SCTP INIT parameters can be configured through VTY, which will be passed to the Linux Kernel SCTP stack and used whenever an association is being established. On the client side (see <>), the parameters are configured in the `asp` node: ---- cs7 instance 0 asp my-asp 2905 0 m3ua sctp-role client sctp-param init num-ostreams 250 <1> sctp-param init max-instreams 300 <2> sctp-param init max-attempts 3 <3> sctp-param init timeout 10000 <4> ... ---- <1> The number of streams from the server to the client. This value is transmitted during SCTP INIT ACK packet. <2> Announce to the server that a maximum of up to 300 inbound SCTP streams are supported. This value is transmitted during SCTP INIT packet. <3> Initial SCTP handshake will be attempted 3 times before considering the connection failed. <4> Retransmit an SCTP INIT message after 10000 ms if no answer is received. On the server side (see <>), the parameters are configured in the `listen` node: ---- cs7 instance 0 asp my-asp 2905 0 m3ua sctp-role server listen m3ua 2905 sctp-param init num-ostreams 250 <1> sctp-param init max-instreams 300 <2> ... ---- <1> Announce to the server that up to 250 outbound SCTP streams (server to client) may be requested. This value is transmitted during SCTP INIT packet, and should be equal or lower to the `max-instreams` value received from the client during SCTP INIT packet. <2> Announce to the server that a maximum of up to 300 inbound SCTP streams are supported. This value is transmitted during SCTP INIT ACK packet. [[sctp_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.