A Short History of Routing In Telco Networks

Routing is the process of selecting a path for traffic in a network or between or across multiple networks. Broadly, routing is performed in many types of networks, including circuit-switched networks, such as the public switched telephone network (PSTN), and computer networks, such as the Internet.

https://en.wikipedia.org/wiki/Routing

SS7: Routing Fixed Line Phone Calls On Digital Links

Back in the 80s, when SS7 networks were deployed for the first time their "killer application" was phone calls. Telephony networks of the the big telcos were becoming larger and larger and the "Channel Associated Signalling" (CAS) based SS5 used at that time began to show its weaknesses:

• fraud prone; CAS in-band signalling was exploited using cheap hand-held tone generators (a.k.a. "blue box")
• poor resource usage and allocation due to inefficient design

Enters the shiny, newly designed system: Signalling System No. 7; it featured:

• OSI model based network layers. At first, the following network layers were defined: Message Transfer Part 2 (MTP2), Message Transfer Part 3 (MTP3), Telephone User Part (TUP). Later on, when the complexity of the telephony applications increased more layers were added: ISUP, SCCP, TCAP, MAP, INAP;
• digital (binary) representation of the network messages, which were called "Message Signalling Units" (MSU)
• specialized network components and a comprehensive network topology: STP (Signalling Transfer Point), SSP (Service Switching Point), SCP (Service Control Point). Later on even more complex network components were developed and used: HLR (Home Location Register), VLR (Visited Location Register), SGSN, GGSN, GMSC, MSC aso.?Specialized network packets could be sent around the globe on dedicated digital links having a bandwidth between 64 kbps and 1.544 Mbps.

At the time when it was introduced, the main problem which was solved by the SS7 network was phone call set-up: "Calling Party (A) calls Called Party (B)". Both Calling Party (CgP) and Called Party (CdP) are represented using numbers (CgPN, CdPN) in a certain standardized format, one of the international standards for telephone numbers being ITU-T E.164.

Whenever a call is placed, the network of the caller has to:

1. find the network of the callee;
2. send signalling messages from the caller to the callee for announcing him that it is being called;
3. set-up the actual voice call;
4. terminate the call;

Steps listed above require sending specialized data packets, called "Message Signalling Units" (MSU) across SS7 network between its components. In order to communicate to each other, SS7 network components (like STP, SSP, SCP aso):

• are identified by point codes (PC), basically unique numerical addresses;
• store and use routing tables which indicate how to reach another point code over some physical link;

All MSUs sent by SS7 components contain:

• an "Originating Point Code" (OPC) showing which network component has sent the MSU;
• an "Destination Point Code" (DPC) showing which component should receive the MSU;

Point codes are numbers represented in binary format on a fixed number of bits:

• ITU-T point code is represented on 14 bits;
• ANSI point code is represented on 24 bits;

Based on who is allocating and maintaining them, point codes can be either international or local:

1. International point codes are maintained and allocated by an specialized organization like ITU-T (see List of International Point Codes). International point codes have an hierarchical prefix based structure that contains:

• (geographical) zone
• area/network
• signalling point

2. Local point codes are maintained and allocated within a certain country, telco aso;

Things Get Complicated: Number Portability, Telephony Services, Mobile Phones

Telephony network growth was facilitated by the introduction of digital SS7 networks. Growth also meant more and more new services being offered to customers; some of the new services were far more complex than any of the previous ones.

Regulators required telcos to offer their customers the possibility of re-using telephone numbers regardless of the operator which is currently providing telecommunication services. A new service was basically needed: "Number Portability".

Computerized switching and signalling systems made the human operator who assisted collect calls and toll free calls redundant and made possible services like toll free numbers, 800-numbers, calling cards on an much larger scale, at a much lower cost than before. However, from the signalling point of view, routing toll free calls was more complicated than routing the normal phone call.

And last but not least: mobile phones complicated things even further. Services based on 3GPP GSM standards have introduced a lot of new use cases in the SS7 networks:

• SIM based authentication and authorization of mobile phones;
• global mobility across multiple networks (roaming);
• pre-paid charging;
• short message service (SMS);
• data services (GPRS, UMTS);

More specialized components were needed in the SS7 networks in order to make the new services technically feasible and scalable at the global level:

• local number portability (LNP) databases;
• application servers for telephony services;
• core network components for mobile operators (HLR, VLR, MSC, GMSC, GSN aso), mobile number portablity (MNP).

These new network components have to be addressable and routing based solely on point codes (PC) was no longer optimal in the SS7 networks. A new way of addressing new network entities and routing MSUs between them was required; this is how Signalling Connection Control Part (SCCP) protocol became an important layer in SS7 networks.

SCCP protocol defines its own addresses, which are denoted by:

• Calling Party Address (CgPA);
• Called Party Address (CdPA);

SCCP address introduces new modes of identifying an SS7 network component and also new procedures for routing in SS7 networks:

1. Addressing based on "Subsystem number (SSN)"

Subsystem number (SSN) identifies a certain application running on an SS7 node. There are globally standardized SSNs (e.g. for 3GPP core network applications like HLR, VLR, MSC aso)

2. Addressing based on "Global title"

Global titles are standardized numbers (addresses) which are reachable globally allowing routing messages across multiple networks. Several types of standard numbers can be used as global titles:

• International Mobile Subscriber Number (IMSI); standardized by ITU E.212
• Mobile Global Title (MGT); standardized by ITU E.214
• MSISDN (telephone number); standardized by ITU E.164

All these standard numbers have a prefix based structure, each prefix being formed of a certain number of digits:

• there are global country prefixes;
• and, within country prefixes, there are network (operator specific) prefixes.

This standard prefix structure allows routing messages to a certain country and then, within the country, to a certain network.

IMSI numbers (ITU E.212) have the MCC+MNC specific format:

MCC - MNC - MSIN

where the MCC, MNC have following structure:

• 3 digits Mobile Country Code (MCC)
• 2 or 3 digits Mobile Network Code (MNC)

MGT (ITU E.214) and MSISDN (ITU E.164) numbers use the CC+NDC prefix structure:

• 1 to 3 digits Country code (CC)
• 1 to 4 digits Network prefix / Area prefix (National Destination Code - NDC)

How is the SCCP address (usually a combination of global title and subsystem number) used instead of the already existent point code?

Each telco service use case has its own answer to this question; ITU-T standardized the usage of SCCP addresses in SCCP specifications.

One use case that requires using SCCP addresses is the authentication of SIMs in the 3GPP networks. Once a device using a SIM is turned on, it attaches to some radio network and it has to be authenticated before allowing it to use the services offered by the network. The piece of information which identifies the SIM in the network is an IMSI number.

Here is how SS7 signalling messages are routed in the 3GPP roaming registration use case. Authentication requests which contain IMSI data and were initiated by GSM/UMTS devices have to be sent from one telco network, where the device is connected to the radio (visited PLMN) to another telco network which actually owns the IMSI and has issued the SIM (home PLMN). A network component called Visited Location Register (VLR) receives the device's authentication request and has to send it to another network component called Home Location Register (HLR) which is either going to provide SIM credentials or reject the authentication.

Routing device's authentication requests based solely on point codes would require some routing tables which map ranges or prefixes of IMSIs to the point code of HLRs which provide authentication and authorization for the respective IMSI; this was deemed unfeasible and another routing technique was developed based on SCCP global titles.

The VLR component has to compute an called party address (SCCP CdPA) which identifies an HLR component capable of providing SIM credentials. VLR computes the called party address (CdPA) global title based on the SIM IMSI using 2 main approaches:

1. Global title contains the IMSI, an E.212 number (telcos in the U.S. use this approach)
2. Global title contains an Mobile Global Title (MGT), an E.214 number; for obtaining an MGT number from an IMSI number, the MCC+MNC prefix of the IMSI is replaced with a coresponding CC+NDC prefix. This approach is re-using MSISDN (telephone number) prefix-based routing tables.

The actual routing of the MSU carrying the authentication request, from the visited network, through inter-carrier networks to device's home network is based on the prefix of the CdPA's global title which is:

• either the MCC+MNC prefix of the IMSI;
• or the CC+NDC prefix of the MSISDN;

Once the authentication request MSU has reached its destination (home) network it is going to be received and processed accordingly by the HLR.

The called party address and calling party address of the reply sent by the HLR contain the MSISDN E.164 global titles of the VLR and respectively of the HLR. This reply is routed from the home network to the visited one using the same procedure described above.

See the SCCP standard for more details.

SIGTRAN takes over

At the end of the 90s IP networks became already a mature technology, reliable enough to be used for routing telco signalling.

A new IETF working group was established for developing and standardizing protocols that allow transporting and routing SS7 telco signalling over IP networks: SIGTRAN.

The working group has standardized a whole family of protocols:

• Stream Control Transmission Protocol (SCTP) an IP network transport protocol used for all SS7 based signalling protocols; SCTP is defined by IETF in RFC4960.
• adaption layers for message transfer SS7 protocols (M2UA, M3UA); M3UA is defined by IETF in RFC4666, and M2UA is defined by IETF in RFC3331
• adaptation layers for ISDN (IUA), SCCP (Signalling Connection Control Part User Adaptation Layer);

SCTP has become very fast the de facto transport layer for all telco signalling protocols. It features capabilities which combine the reliability of TCP with the message oriented operation of UDP. It also has built-in multi-homing and it can set-up redundant paths between peers. SCTP implementations provide standard event notification APIs which can be used to monitor the transport layer connectivity and congestion related states from the application layer.

The protocol stack adopted by the industry right away was: [IP, SCTP, M3UA] on top of which either ISUP or SCCP was used. Later on another protocol stack was used as well: [IP, SCTP, SUA], where SUA combines M3UA and SCCP in one networking layer.

One of the advantages brought by SIGTRAN was that the dedicated links were no longer needed for interconnecting two SS7 components or networks; once an IP network was available it could be used directly by SIGTRAN routers (STPs) or application servers which were capable by design to operate over IP networks. SS7 dedicated physical links between 2 network components were replaced by SCTP associations (connections) over IP networks. One IP network connection can be actually used for emulating multiple SS7 links and only the bandwidth of the that connection limits the number of emulated SS7 links.

From now on the SS7 components were addressable and reachable using an <IP address, SCTP port> tuple while all the "legacy" SS7 based routing remained available. IP packets, respectively SCTP data chunks "encapsulate" MSUs facilitating their transport across IP networks. Once an SIGTRAN IP packet reaches its destination, the SIGTRAN capable node will process the "encapsulated" MSU and route it accordingly based on point code, global title and subsystem number.

Unfortunately, since SIGTRAN is strongly coupled to SS7 and since there was no notion of human friendly "names" in SS7, the use of DNS names was never really standardized and thus used for SIGTRAN protocols.

SIGTRAN introduced in some of the adaptation layers (M3UA, SUA) the concepts of "Application Servers" (AS) and application high-availability modes (active/stand-by, active/active, load balancing). This offers the possibility of implementing complex, redundant application server architectures by routing (or load-balancing) an MSU to an end point based on its announced availability.

A New Hope: Session Initiation Protocol (SIP)

In year 2000, in an ever interconnected world, interacting from the Internet side in a programmable fashion with the PSTN and with phones was still rather cumbersome.

To make things even worse, there was no Internet standard that would facilitate the set-up of communication sessions between users. This need was covered by the Session Initiation Protocol (SIP) which is mainly defined by the IETF standard RFC3261.

SIP came up with new paradigms in terms of how devices set-up media sessions and communicate to each other:

• SIP can be used both on end devices (phones, conference bridges) and on specialized proxies, routers and servers;
• SIP can function either end-to-end between user devices or through specialized proxies and routers;
• SIP offers advanced media negotiation capabilities by means of SDP payloads;
• SIP is an transactional protocol and SIP transactions are processed by each and every device involved in the call set-up; however for increasing the robustness of the protocol, replies can be processed and routed without creating and storing a transaction state.
• SIP addresses, which are called SIP Uniform Resource Identifiers (URIs). SIP URIs are human friendly email-like addresses; for example, this is a SIP URI: "sip:[email protected]".
• SIP service discovery; namely, SIP standards specify how to use Internet's domain name system (DNS) for service discovery.

All of a sudden there is a telco protocol which does not enforce numbers for identifying network components and routing messages between them but allows for human readable addresses. However, most SIP based VoIP operators are interconnected with the PSTN and use E.164 numbers in the SIP URI for compatibility with plain old telephony services.

As its SS7 and SIGTRAN forefathers, SIP has to route from one network device to another the messages which set-up a media session and, since it is an IP based protocol it ultimately uses <IP address, port> tuples for sending and receiving messages. But how are the SIP URIs translated into IP addresses?

SIP makes use of 2 specialized services for translating SIP URIs into IP addresses:

• SIP registrar (an server entity which is defined by the SIP standard)
• domain name service (DNS)

A SIP registrar is, roughly speaking, a database server which stores tuples like <SIP URI, <IP address, port>> offering the possibility to look-up the IP addresses and port of a registered end device.

Usually, end-devices make themselves reachable in the SIP network like this:

1. Discover a SIP registrar using DNS.

2. Send REGISTER requests to the SIP registrar for registering their current IP address(es), transport protocol and transport port with an address-of-record (an SIP URI).

In general, SIP entities can discover each others IP addresses by means of specialized DNS look-ups:

• SRV look-ups;
• NAPTR look-ups;

The following IETF RFCs describe in detail SRV, NAPTR and how SIP uses them:

• Session Initiation Protocol (SIP): Locating SIP Servers
• A DNS RR for specifying the location of services (DNS SRV)
• The Naming Authority Pointer (NAPTR) DNS Resource Record

Once the IP address of the peer is known, SIP network elements can exchange SIP messages using transport protocols like UDP, TCP, SCTP over IP.

There are major differences between SS7/SIGTRAN and SIP when it comes to transaction reply routing or in-dialog message routing.

In SS7/SIGTRAN, the transaction layer (TCAP) is totally decoupled from the layers that provide the routing services (MTP3/M3UA and SCCP); that is why each and every SS7/SIGTRAN application has to define:

• how transaction responses are routed back to the network element which initiated the transaction;
• how in-dialog messages are routed between network elements;

The SIP standard defines itself how replies are routed. In general, when transaction state is available, the reply is routed back to the request sender. However, all SIP requests contain a special message header, called "Via", which is generated by SIP entities while routing the request. Its content has to copied in responses and used when responses are routed back.

Routing a response without stored transaction state comes down to:

1. remove the top most "Via" header (which should contain the URI of the processing node)

2. get the next hop from the current top most "Via" header;

3. send the response to the next hop;

SIP also offers a mechanism for stateful routing of in-dialog messages by using 2 special message headers called "Record-Route" and "Route". "Record-Route" header field is used in the transaction which initiates a dialog for "recording" the proxies, servers which have forwarded the message. "Route" header field is used for enforcing routing of a request through the listed set of proxies.

The Empire Strikes Back: IMS, Diameter, LTE

Once SIP gained traction and became a known protocol, 3GPP started standardizing an architectural framework for using SIP in large telco networks: "IP Multimedia Subsytem" (IMS).

One of the main integration points between SIP protocol and 3GPP (3G, 4G, 5G) based networks is the authentication and authorization of the SIP terminals for allowing them to use available services. Traditionally, devices authenticate themselves in 3GPP networks by using information stored on a SIM. IMS supports:

1. The classical USIM (Universal SIM) application; in this case the identity used for authentication is represented by the "International Mobile Subscriber Identity" (IMSI number).

2. The special ISIM (IMS SIM) application; in this case the identity used for authentication is called "IP Multimedia Private Identity" (IMPI) and it is represented by a "Network Access Identifier" as defined in the IETF standard The Network Access Identifier. An NAI has the format: 'user@realm', where the realm is usually represented by a DNS domain name.

The protocol used for carrying authentication, authorization and accounting messages in IMS (and LTE) networks is called Diameter and it is defined also by IETF, the main document being Diameter Base Protocol.

The authorization and authentication use case in IMS can be described shortly like this:

• a SIP terminal attaches to a network (which can belong to the operator which has issued the SIM/IMSI of that terminal or to another operator).
• the SIP terminal tries to register itself by sending a "REGISTER" SIP message which contains its credentials.
• the core network of the operator has to route the "REGISTER" message to the home network of the terminal; the REGISTER is forwarded through a series of "Call Session Control Function" (CSCF) proxies using SIP routing
• once the "REGISTER" message is received in the home network the I/S-CSCF proxys will initiate a series of diameter transactions for authenticating the terminal and for authorizing it to use the network.

How are diameter messages routed?

Diameter routes messages based on destination realms; destination realms are either pre-configured as defaults for certain messages or built based on the network access identifier (NAI) present in an User-Name Attribute-Value Pair (AVP).

A diameter node uses two tables for routing messages:

• a peer table which contains <diameter peer, TCP/SCTP connection> tuples; these tuples indicate which TCP/SCTP connection should be first established and than used to access next hop peer;
• a realm routing table which contains <diameter peer, realm> tuples indicating through which diameter peer a realm is accessible;

These tables can be configured manually or, as with SIP, diameter nodes can also use NAPTR and SRV DNS look-ups for dynamically discovering diameter peers in a realm (network domain).

Back to IMS, in case of ISIM application diameter nodes route the messages based on the realm of the IMPI.

However in case of simple USIM application the CSCF proxies and diameter nodes can build the NAI by using:

• the IMSI;
• the special "ims.mcc*.mnc*.3gppnetwork.org" realm (which is actually a valid DNS domain);

For example, suppose that the IMSI is 310-170-123456789 (MCC=310 USA, MNC=170 Sprint); then, the NAI (also called Private User Identity in 3GPP standards) used for authentication is: [email protected]

A diameter router receiving a diameter request message with an User-Name AVP having the value "[email protected]" will route the message to the "ims.mcc310.mnc170.3gppnetwork.org" realm by using the following algorithm:

1. Look-up in the realm routing table the entry having the realm "ims.mcc310.mnc170.3gppnetwork.org" and get the respective diameter peer. The respective entry can be either statically configured or dynamically discovered using DNS SRV and DNS NAPTR lookups. If there is no such entry use the diameter peer of the realm routing table's default entry.

2. Use the peer table to get the TCP or SCTP connection which can be used to communicate with the diameter peer returned by step 1.

Once the message is received by a peer in the destination realm it will be routed to an application server, based on the message type and the IMSI. One of the most commonly used application server in the IMS network is the Home Subscriber Server (HSS).

Diameter router nodes deployed in telco core networks maintain realm routing tables for known MCC and MNC prefixes. These tables can be used for:

• inter-operator routing;
• routing within the same core network; in this case, usually for load balancing the traffic across multiple HSS servers;

Long-Term Evolution (LTE) standards have modified the telco core network topology and decoupled some of signalling plane functionality into a stand-alone component: the Mobility Management Entity (MME). Similar to IMS USIM use case, MME component uses the Diameter protocol to route the authentication and authorization messages to and communicate with the Home Subscriber Server (HSS).

Data! Data! Data!

In year 2000, with the advent of GPRS networks data was already available on mobile devices. Performant smartphones with better and better screen resolution introduced new use cases for mobile data:

• HD video streaming
• audio and video conferencing
• GPS based navigation apps

The demand for more and more data led to scaling and optimizations of the telco networks in order to offer more bandwidth and a higher quality of service.

How is the data session set-up and how are data packets routed in 3GPP networks?

Network devices need first to reach an IP router which can route IP packets with data to and from a wireless device. In order to get to an IP router data packets are routed through telecommunication core networks, namely through so called packet gateways:

• Serving GPRS support node (SGSN) / Serving Packet Gateway (S-GW)
• Gateway GPRS support node (GGSN) / Packet Gateway (P-GW)

Traditionally the functionality of telecommunication networks is split into:

• control plane
• user (data) plane

Control plane deals with authentication, authorization, accounting and from a more general perspective, allocating or deallocating resources.

Authentication and authorization for data services is performed by the following control plane components:

• SGSN (2G/3G), MME (4G) in the visited network;
• HLR (2G/3G), HSS (4G) in the home network;

The routing of authentication and authorization packets between the visited network (SGSN, MME) and the home network (HLR/HSS) is done using sigtran (2G/3G) or diameter (4G) as described above.

In order to use data services a network device has to reach an GGSN/PGW. There is no static one-to-one mapping between a network device and its "corresponding" GGSN/PGW but rather a dynamic one based on DNS service discovery. Each and every network device stores in its configuration a so called "Access Point Name" (APN); an APN is a domain name (either fully qualified or not). When data session is set-up the device will send the APN to its home network, where the APN is resolved to an GGSN/PGW IP address using DNS NAPTR and SRV records. See 3GPP TS 23.003 "Numbering, addressing and identification" for more details.

After discovering the GGSN/PGW the network device will ask it to set-up an IP tunnel; this is done using a protocol called GTP-C which is built upon the UDP transport layer and thus uses normal IP routing.

More about IP tunneling in the next section...

User plane deals with routing the actual voice packets or data packets to and from the network devices.

Wireless network devices do not have a "fixed" point of attachment to the network and after a radio handover devices may also change their IP network connection. Standard IP routing does not cover this kind of use cases and another protocol has to be employed in order to reliably deliver IP packets after such a handover: IP tunneling. There are several ways of tunneling IP packets: IP in IP, IP over UDP, IP over TCP aso.

In telecommunication networks, IP packets are tunneled between packet gateways using the GTP-U protocol: IP packets are encapsulated by the sender in UDP datagrams and decapsulated by the receiver which also forwards the IP packet further.

This tunneling mechanism enables the network devices to use in visited networks an IP address which was allocated in its home network; even if the network prefix of the "home" IP address is different from the network prefix of the visited networks, IP packets sent or received by the network device reach their destination since they are routed through the IP tunnel between the network device and its home network.

Both the control plane (GTP-C) and the user plane (GTP-U) of the GTP protocol are described in 3GPP TS 29.060 "GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaces".