Need for Global Title

Translation in SS7
SS7 routing principles are interesting. Right from the origin of
design, the SS7 has seen lot of transformations. Still it is evolving on
demand and fulfilling the requirements. For example, SCCP (Signalling
Control and Connection Part) was not available in the initial design. When
the need for flexible and more robust routing evolved, SCCP was formed.
A problem arised when the point code within the national network was
used outside the network also by a different operator. In this case, the
differentiation cannot be made by the originating exchange and it is
confused. Thus SCCP was introduced for flexible analysis.

Till now, SCCP plays a major role in design of SS7 protocol

architecture. Global Title (GT) is one of the components that participate in
the SCCP activity. This document explores the exact need for GT in SCCP
and also the actual functioning of GT.

Simple defined Global Title (GT) is an address. But it is not an

address of a node in the SS7 network (DPC, SSN). Instead, it is an alias for
such an address that needs to be translated into an SS7 network address.
Before getting into GT analysis, let’s have a look into other user parts.

MTP – The MTP (Message Transfer Part) has a job that is limited to reliably
transferring messages over the links in a link set. That is, MTP only cares
about the address of the node at the other end of the links it is tending.
Therefore the only addressing the MTP requires is the SPC (Signalling Point
Code) of the node at the end of its links. MTP sees this address as the
Destination Point Code (DPC) of all messages it sends over the links. The
only concern MTP has for any other location in the network is to be able to
make use of the final destination of the message to help it pick out one
link set from all the available link sets as the best one to use for sending
the message. This is what MTP routing is all about.

ISUP – The ISUP (ISDN User Part) addressing is different. In normal Call
Control use, ISUP addresses a switch at the other end of its trunk
connections. For the SS7, this too means using a Destination Point Code
(DPC). But the switch ISUP talks to (which is the next switch in a circuit
being set up or torn down) is not necessarily (and really not likely) to be
located at the other end of its own SS7 links.

At this stage, SCCP was introduced to face the addressing issues. Like the
other User Parts, SCCP can, and does, make use of DPC. This address
alone can be used to get a message to
any node in the global SS7 network in the same way that a telephone
number can be used to address any telephone in the global telephone
network. But SCCP addressing needs to go beyond this method of
addressing. The reason is that at each DPC there is a “system” operating.
That system may be a Call Control application or a database or some
other program of some type.

The problem is that within that system there may be multiple

applications running. Thus a Signalling Point Code (which is addressed as
a Destination Point Code) may be the home of both a emergency number
Database and an 800 Number Database. Using the DPC as the SS7
address will get the message delivered to the “system” but it won’t get
the message delivered to the appropriate database application. For this
purpose, a separate identifier of a system within the system is required.
That identifier is the Subsystem Number (SSN). It may tempt to know
the reason for introducing SSN at this point. As each node has several
applications running within them, it becomes necessary for an originating
request to properly address that application.

In Global System for Mobile Communications (GSM) and Universal

Mobile Telecommunications System (UMTS), subsystem numbers may be
used between Public land mobile networks (PLMNs), in which case they
are taken from the globally standardized range (1 - 31) or the part of the
national network range (129 - 150) reserved for GSM/UMTS use between
PLMNs. For use within a PLMN, numbers are taken from the part of the
national network range (32 - 128 & 151 - 254) not reserved for GSM/UMTS
use between PLMNs.

ITU-T recommendation of SSN values

SSN
values 8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 0 SSN not known/Not used
1 0 0 0 0 0 0 0 1 SCCP Management
2 0 0 0 0 0 0 1 0 Reserved for ITUT allocation
3 0 0 0 0 0 0 1 1 ISUP
4 0 0 0 0 0 1 0 0 OMAP
5 0 0 0 0 0 1 0 1 MAP
6 0 0 0 0 0 1 1 0 HLR
7 0 0 0 0 0 1 1 1 VLR
8 0 0 0 0 1 0 0 0 MSC
9 0 0 0 0 1 0 0 1 EIR
10 0 0 0 0 1 0 1 0 AUC
11 0 0 0 0 1 0 1 1 ISUP
Reserved for International
12 0 0 0 0 1 1 0 0 use
Broadband ISDN edge-to-edge
13 0 0 0 0 1 1 0 1 application
14 0 0 0 0 1 1 1 0 TC test responder
15 0 0 0 0 1 1 1 1
Reserved for International
to use
31 0 0 0 1 1 1 1 1
32 0 0 1 0 0 0 0 0
to Reserved for National
 networks
254 1 1 1 1 1 1 1 0
255 1 1 1 1 1 1 1 1 Reserved for expansion of national and international SSN

3GPP recommendation of SSN values

6 0 0 0 0 0 1 1 0 HLR
7 0 0 0 0 0 1 1 1 VLR
8 0 0 0 0 1 0 0 0 MSC
9 0 0 0 0 1 0 0 1 EIR
10 0 0 0 0 1 0 1 0 AUC
250 1 1 1 1 1 0 1 0 BSC
251 1 1 1 1 1 0 1 1 MSC
252 1 1 1 1 1 1 0 0 SMLC
253 1 1 1 1 1 1 0 1 BSS O&M
254 1 1 1 1 1 1 1 0 BSSAP
142 1 0 0 0 1 1 1 0 RANAP
143 1 0 0 0 1 1 1 1 RNSAP
145 1 0 0 1 0 0 0 1 GMLC
146 1 0 0 1 0 0 1 0 CAP
147 1 0 0 1 0 0 1 1 gsmSCF
148 1 0 0 1 0 1 0 0 SIWF
149 1 0 0 1 0 1 0 1 SGSN
150 1 0 0 1 0 1 1 0 GGSN
15 0 0 0 0 1 1 1 1 INAP

Thus a switch handling several features need SSN for specific addressing
to an application.

Example case:

Still many networks do not have a stand-alone HLR and the HLR is
still co-located with VLR of a MSC with good capacity. In this case, the
MSC node has to serve as MSC (for routing calls), HLR (to have permanent
subscriber info), and VLR (to have temporary subscriber info). This MSC
will have SSN values 6, 7 & 8 defined in all neighbour nodes to have ease
of access to different applications like HLR, VLR & MSC respectively. For
nodes having EIR functionality SSN 9 is also added. For stand-alone HLR
nodes only SSN 6 is defined by neighbouring nodes which means, only
HLR related queries of queries of HLR nature are accepted from this node.
It can also be described as, the queries from SSN 6 (HLR node) addressing
SSN 6 (MSC node) will be responded only if the MSC has SSN value If the
node sends VLR queries (for example), they will be rejected. Thus SSN is
an application identifier. Sample printout from a network with MSC4 –
MSC/VLR, HLR4 – Stand-alone HLR and the printout node is MSC3 –
MSC/VLR.
SP SPID SPSTATE BROADCAST STATUS SCCPSTATE

2-1042 HLR4 ALLOWED CON ALLOWED

 SSN SUBSYSTEMSTATE SST

6 ALLOWED YES

SP SPID SPSTATE BROADCAST STATUS SCCPSTATE

2-1065 MSC4 ALLOWED CON ALLOWED

SSN SUBSYSTEMSTATE SST

7 ALLOWED YES

8 ALLOWED YES

Let us return to original track of Global titles. Another special feature

of SCCP is addressing the remote nodes with a special address apart from
the DPCs. Every day, new services are deployed into the SS7 network
around the world. Some of them are proprietary and are, therefore,
accessible only to the switches in the same proprietary network. Others
are intended to be offered to other networks for a fee. So, here is the
problem. If a service becomes universally available, does that mean that
every switch on the planet needs to add the location (DPC) and identifier
(SSN) to its SS7 routing table? Obviously if that were the case new
services would spread slowly; and each switch would have to maintain
huge tables of routing information.

A better answer is to keep that information at a much more limited

number of locations in the network (such as STPs) and allow the switches
to identify their requests for information without identifying where, or from
what applications the information can be retrieved. That means that when
a switch wants a translation, it need only identify the nature of the
translation needed (for example, emergency number 112 or 911 to actual
contact number based on location) and send the request to a location
whose routing table tells it where such translations can be performed. A
single location in the routing table of the switch (such a location as an
STP) may serve to provide 911 Number translations, 800 (toll free)
number translations, Credit Card validation, etc. Even the first location
which receives the request does not have to maintain a routing table of all
locations on the globe. Instead, it may have a table which indicates that
all requests in several similar categories should be sent to one location
while requests in other categories can be sent somewhere else. All of this
is possible because, with Global Title requests, the originator of the
request does not need to know where or what application can
provide the answer to the request.

Global Title has even more uses. For example, the STP maybe able to send
Dialed Digit translation requests to either of two databases at two
different database nodes. The receipt of a Prohibited signal (indicating the
database is unavailable) from the SCCP at one of the database locations
can tell the STP to change its lookup to another Global Title Table. The
translation there, in turn, can result in address information used to send
queries to the backup location. As an alias addressing mechanism, Global
Title can obviate the need for ubiquitous ponderous routing tables. It can
also hide network assets and provide greater control for conditional
rerouting requirements.

For more info on fields read the source document by ss8 networks.
Thanks to ss8 networks.

Ramanathan Sundaram.
xpotentialram@gmail.com