Need For Global Title Translation

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 0 1 2 3 4 5 6 7 8 9 10 11

8 0 0 0 0 0 0 0 0 0 0 0 0

7 0 0 0 0 0 0 0 0 0 0 0 0

6 0 0 0 0 0 0 0 0 0 0 0 0

5 0 0 0 0 0 0 0 0 0 0 0 0

4 0 0 0 0 0 0 0 0 1 1 1 1

3 0 0 0 0 1 1 1 1 0 0 0 0

2 0 0 1 1 0 0 1 1 0 0 1 1

1 0 1 0 1 0 1 0 1 0 1 0 1

12

0

0

0

0

1

1

0

0

13 14 15

0 0 0

0 0 0

0 0 0

0 0 0

1 1 1

1 1 1

0 1 1

1 0 1

0 0

to 0 0 0 1 to

31 32

SSN not known/Not used SCCP Management Reserved for ITUT allocation ISUP OMAP MAP HLR VLR MSC EIR AUC ISUP Reserved for International use Broadband ISDN edge-to-edge application TC test responder Reserved for International use

1 0

1 0

1 0

1 0

1 0 Reserved for National

networks 254 255

1 1

1 1

1 1

6 7 8 9 10 250 251 252 253 254 142 143 145 146 147 148 149 150 15

0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 0

0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0

0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0

1 1

1 1

1 1

1 1

0 1

Reserved for expansion of national and international SSN

3GPP recommendation of SSN values 0 0 1 1 0 HLR 0 0 1 1 1 VLR 0 1 0 0 0 MSC 0 1 0 0 1 EIR 0 1 0 1 0 AUC 1 1 0 1 0 BSC 1 1 0 1 1 MSC 1 1 1 0 0 SMLC 1 1 1 0 1 BSS O&M 1 1 1 1 0 BSSAP 0 1 1 1 0 RANAP 0 1 1 1 1 RNSAP 1 0 0 0 1 GMLC 1 0 0 1 0 CAP 1 0 0 1 1 gsmSCF 1 0 1 0 0 SIWF 1 0 1 0 1 SGSN 1 0 1 1 0 GGSN 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 2-1042

SPID HLR4

SPSTATE

BROADCAST STATUS SCCPSTATE

ALLOWED

CON

ALLOWED

SSN

SP 2-1065

SUBSYSTEMSTATE SST

6

ALLOWED

SPID

SPSTATE

MSC4 SSN

YES BROADCAST STATUS SCCPSTATE

ALLOWED

CON

ALLOWED

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. [email protected]