Статья №1 UMTS/GSM

Citation preview

Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network

¨ KRAGSTERMAN PAR

Master’s Degree Project Stockholm, Sweden 2004-10-04

IR-SB-EX-0429

Proyecto fin de carrera

Título: Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network Autor: Pär Kragsterman Tutor: Rubén Echarri de Esteban Ponente UPM: Ana Belén García Hernando Ponente KTH: George Jöngren

Composición del tribunal

Presidente: Enrique Vázquez Gallo

Vocal: Manuel Álvarez-Campana Fernández-Corredor

Secretaria: Ana Belén García Hernando

Suplente: David Fernández Cambronero

Fecha de presentación: Calificación:

Universidad Politécnica de Madrid

Kungliga Tekniska Högskolan

Escuela Técnica Superior de Ingenieros de Telecomunicación

Proyecto fin de carrera

Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network

Pär Kragsterman Mayo 2004

Abstract / Keywords

Abstract The present document resolves in a joint manner the two GSM/UMTS network functions Mobile Number Portability (MNP) and Flexible Allocation (FA). MNP is the possibility for a subscriber of a service provider to change to a new service provider bringing his telephone number with him. FA on the other hand is the possibility for a network operator to allocate an arbitrary subscriber identifier (IMSI) and telephone number in any of its subscriber databases (HLR). The solution presented is the Signaling Relay Node (SRN). The SRN redirects all signaling messages in the operator network that needs to reach an own or foreign subscriber database based on the subscriber identifier or telephone number, therefore subject to MNP and/or FA, to its appropriate destination. This redirection is performed in all cases except when the incoming signaling message is a call routing information request (MAP SRI) for an exported or foreign telephone number, where the SRN replies directly to the requesting node providing routing information (SRI_ack) to the destination network. The SRN’s decision on where to reroute, is based on the incoming signaling message’s destination address (CdPA) from which it can deduct if the signaling message is subject to FA, MNP or both. All the traffic cases where the SRN is involved and the requirements of the node are presented. The requirements are specified on top of a base platform already able to provide hardware connectivity, necessary networking protocols (MTP, SCCP and MAP signaling), databases, provisioning and alarms by itself.

Keywords Flexible Allocation (FA), Mobile Number Portability (MNP), Signaling Relay Node (SRN), GSM, UMTS, redirect, reroute, SCCP, MAP, IMSI, MSISDN, HLR

1

Brief summary in Spanish

Brief Summary in Spanish Introducción La especificación de GSM/UMTS asigna un único Home Location Register (HLR) lógico a cada operadora de comunicaciones móviles GSM/UMTS. Obviamente, y debido al volumen de clientes que tienen las redes móviles es imposible encontrar una plataforma física que pueda contener al HLR lógico asignado a cada operadora móvil. Por ese motivo, se divide el HLR asignado a la operadora en varios nodos físicos. Esa división se hace mediante configuraciones estáticas en los nodos de la red móvil de forma que se asignan rangos de International Mobile Subscriber Identities (IMSI) a cada HLR físico. El HLR es la base de datos en la red que almacena la información del perfil de suscripción del cliente, cierta información dinámica como son los desvíos, la información sobre la ubicación del abonado (a nivel Visitor Location Register (VLR)) y el Mobile Station ISDN Number (MSISDN) del cliente (número público del cliente). Este nodo puede ser interrogado bien en base al IMSI o bien en base al MSISDN, por lo que se tienen que asignar rangos de MSISDNs por máquina física. Esta asignación también es estática. Al tener una relación estática entre rangos de IMSIs, rangos de MSISDNs y HLR físico, las operadoras móviles se encuentran ante el problema de que en los puntos de venta tienen que tener Subscriber Identity Modules (SIM) de todo tipo de combinaciones IMSI&MSISDN&HLR físico que se den en la red para cambios de SIMs a los clientes. Para las operadoras móviles esto es un problema logístico de primera magnitud que puede incidir en la satisfacción y en la calidad del servicio que ofrece el operador móvil, por lo que surge la necesidad de encontrar una forma de asignación flexible (FA) de los IMSIs y MSISDNs dentro de los HLRs físicos que tiene la operadora. Este problema se ve agravado con la introducción de la portabilidad numérica móvil (MNP) por la cual el operador móvil puede tener clientes en cualquier rango de numeración móvil dentro del dominio de portabilidad numérica. El MNP consiste en que un abonado de un proveedor de servicio de telefonía móvil pueda cambiar de proveedor de servicio sin cambiar de MSISDN. MNP ha surgido debido a legislación a nivel europeo y español con el fin de permitir que el abonado final se beneficie de las ventajas surgidas de la libre competencia entre operadores sin ningún perjuicio. El FA consiste en la posibilidad de registrar cualquier IMSI&MSISDN independientemente de su rango, en cualquier HLR físico en una red, lo que permite una mejorar sustancia en la gestión del stock de tarjetas SIM y de la capacidad de los HLRs. Tecnológicamente, las soluciones para MNP y FA están estrechamente relacionados. Si un operador quiere resolver uno de los dos problemas puede, sin mucho esfuerzo adicional, resolver los dos.

1

Brief summary in Spanish

El Signaling Relay Node (SRN) La solución presentada en el este documento se basa en el Signaling Relay Node (SRN). El SRN es un nodo que intercepta todos los mensajes MAP a nivel SCCP que van dirigidos hacia los HLRs físicos (propios o de otra red) con el Called Party Address (CdPA) rellenado con un MGT o MSISDN. La intercepción se hace vía reenrutamientos en los STPs del operador móvil. Una vez que el mensaje ha llegado al SRN, este comprueba que tipo de mensaje es y a base de esta comprobación toma una decisión sobre que va a hacer con el mensaje. Varios escenarios existe en cuanto los decisiones del SRN: •

• •

Mensaje MAP enrutado por MGT El SRN re-enruta el mensaje hacia su correspondiente HLR sin tocar el contenido del mensaje MAP ni el CgPA del nivel SCCP. Mensaje MAP enrutado por MSISDN importado o propio El SRN re-enruta el mensaje hacia su correspondiente HLR sin tocar el contenido del mensaje MAP ni el CgPA del nivel SCCP. Mensaje MAP enrutado por MSISDN exportado o no propio o Mensaje MAP Send Routing Info (SRI) El SRN contesta al UMSC con un SRI_ack incluyendo la información necesaria para el re-enrutamiento hacia la red de destino.

•

o Mensaje MAP Send Routing Info for Short Message (SRIfSM), Any Time Interrogation (ATI), Send Routing Info for Location (SRIfLCS) y SendIMSI El SRN re-enruta el mensaje hacia la red de destino sin tocar el contenido del mensaje MAP ni el CgPA del nivel SCCP. Mensaje MAP enrutado por MSISDN importado o propio, recibido en interconexión El SRN re-enruta el mensaje hacia su correspondiente HLR sin tocar el contenido del mensaje MAP ni el CgPA del nivel SCCP.

Especificación Técnica del SRN El SRN está basado en los siguientes módulos de software y hardware por encima de cuales se implementa la aplicación MNP/FA. Los módulos no se especifican más que esto como son muy dependientes del ambiente de implantación del operador. •

•

•

Un módulo software que proporciona las bases de datos, con un interfaz de provisioning. Un módulo software que proporciona el sistema de alarmas Un módulo software que proporciona la señalización MAP

2

Brief summary in Spanish

•

Una plataforma hardware y software por encima de cual opera el nodo SRN, que proporciona la señalización MTP y SCCP

La solución no toma en cuenta la replicación del nodo para proporcionar redundancia. Este documento luego proporciona todos los requisitos no funcionales, funcionales, de señalización, de alarmas y del sistema de provisioning del nodo SRN. En cuanto a los requisitos funcionales, el nodo se basa en un par de tablas en una base de datos. Las tablas son los siguientes. •

• • • • • • • • •

SUBSCRIBER Contiene el MSISDN, IMSI, HLR y el NRN asociado. Determina si un MSISDN o IMSI es un cliente propio o importado o no. HLRLOCATION Contiene los posibles HLRs y la información de enrutamiento asociado. NETWORK Contiene los posibles NRNs. TCAPERRORCODES Contiene los asociaciones entre el MAP operation code y Error Code a ser enviado en casos de que haya un error durante el procesamiento MAP. PARAMETERS Contiene los nombres y valores de los parámetros de configuración del nodo SRN. FLAGS Contiene los parámetro de configuración que se tratan como booleans. MSISDNNORMALIZATION Contiene los datos necesarios para normalizar un MSISDN. COMBINATION Contiene los datos necesarios para combinar un NRN y un MSISDN. MGTTRANSLATION Contiene los datos necesarios para traducir un MGT a un IMSI. LOCAL Contiene los hostnames del nodo SRN y otros parámetros particulares al nodo como por ejemplo el Global Title (GT).

Los procedimientos de búsqueda en las tablas SUBSCRIBER a partir del IMSI o MSISDN se describe en detalle. Esto también se hace para los procedimientos de combinación del NRN y MSISDN y la traducción del MGT a IMSI. En cuanto a los requisitos de procesamiento MAP se describe como actúa el nodo frente cada uno de los mensajes MAP que le puede llegar. Se especifica cuales son las estadísticas que llevará el nodo SRN. 3

Brief summary in Spanish

Se especifica cuales son las alarmas que hará saltar el nodo SRN. Finalmente se hace una especificación sobre que operaciones debe soportar el sistema de provisioning.

4

Foreword

Foreword This document supposes that the reader has basic knowledge on GSM/UMTS networks as well as the three networking protocols MTP, SCCP and MAP. A reader who has good knowledge of these technologies may not want to read the two initial chapters since these are aimed towards a less experienced audience. The present document is intended to serve as a public master thesis for the Telecommunication Engineering career at Universidad Politécnica de Madrid (UPM) in Madrid, Spain and the Master of Science in Electrical Engineering at Kungliga Tekniska Högskolan (KTH) in Stockholm, Sweden. The intention with this research is not to examine all possible solutions to Flexible Allocation (FA) and Mobile Number Portability (MNP) but to, from the point of view of a network operator similar to Vodafone Spain, present a solution. This research is based on an internal project at Vodafone Spain, which was lead by Nicolas Soria Luque, to which I also contributed. This project aimed to construct a similar node to the Signaling Relay Node (SRN) presented in this document but only resolving the FA functionality. The present document is an extended research on how to, in one node, combine the two functionalities FA and MNP. Classified information from the original project has either been replaced or extracted. Therefore, this document may contain information or choices which cannot be explained solely by the presented facts.

5

Contents

Contents 1

Introduction________________________________________ 10 1.1

Short background ____________________________________________ 10

1.2

Work done __________________________________________________ 11

1.3

Outline _____________________________________________________ 12

2

Introduction to GSM/UMTS networks __________________ 13 2.1

Simplified problem scenario____________________________________ 13

2.2

Network nodes _______________________________________________ 16 2.2.2 Node B and Radio Network Controller (RNC)___________________ 18 2.2.3 UMTS Mobile service Switching Center (UMSC) and Visitor Location Register (VLR) ___________________________________________ 19 2.2.4 Home Location Register (HLR) and Authentication Center (AuC) ___ 20 2.2.5 Signaling Transfer Point (STP)_______________________________ 21 2.2.6 Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) _________________________________________________ 22 2.2.7 Short Message Service Center (SMSC) ________________________ 23 2.2.8 Service Control Point (SCP) _________________________________ 23 2.2.9 Gateway Mobile Location Center (GMLC) _____________________ 24

2.3

Traffic cases _________________________________________________ 2.3.1 Normal Location Updating (LU) _____________________________ 2.3.2 GPRS Attach _____________________________________________ 2.3.3 Call to mobile subscriber ___________________________________ 2.3.4 Short message to a MS _____________________________________ 2.3.5 Intelligent Network (IN) request for subscriber information ________ 2.3.6 Location information request by a location application ____________ 2.3.7 Short message from a MS with policing based on subscriber IMSI ___

25 25 27 28 30 30 31 32

2.4

Protocol stack Signaling System number 7 (SS7)___________________ 2.4.2 MTP ___________________________________________________ 2.4.3 SCCP ___________________________________________________ 2.4.4 TCAP __________________________________________________ 2.4.5 MAP ___________________________________________________

33 34 34 36 36

3

Introduction to Mobile Number Portability (MNP) _______ 39 3.1 3.2

3.3

Reasons to introduce MNP_____________________________________ 39 MNP technical network specification ____________________________ 3.2.1 Indirect routing case: Consult the number range owner network _____ 3.2.2 Direct routing case: Consult the originating network ______________ 3.2.3 Signaling messages for MNP in call oriented cases _______________ 3.2.4 Signaling messages for MNP in not call oriented cases ____________

40 40 41 42 43

NRN assignments in Spain _____________________________________ 44

4

Introduction to Flexible Allocation (FA)_________________ 45

5

MNP/FA solution____________________________________ 47

6

Contents

5.1

FA requisites to a solution _____________________________________ 47

5.2

MNP requisites to a solution ___________________________________ 48

5.3

Joint requisites to a solution____________________________________ 49

6

The Signaling Relay Node (SRN) in action _______________ 50 6.1

Flexible Allocation (FA) only, for Location updates and Send Authentication Info (SAI) messages _____________________________ 50

6.2

Send Routing Info (SRI) containing an imported or own MSISDN____ 52

6.3

Send Routing Info (SRI) containing an exported or foreign MSISDN _ 53

6.4

Send Routing Info (SRI) containing an imported or own MSISDN from an interconnecting call ________________________________________ 55

6.5

Send Routing Info for Short Message (SRIfSM) containing an imported or own MSISDN _____________________________________________ 57

6.6

Send Routing Info for Short Message (SRIfSM) containing an exported or foreign MSISDN ___________________________________________ 59

6.7

Send Routing Info for Short Message (SRIfSM) containing an imported or own MSISDN received in interconnection ______________________ 60

6.8

Any Time Interrogation (ATI) containing an imported or own MSISDN ____________________________________________________________ 62

6.9

Any Time Interrogation (ATI) containing an exported or foreign MSISDN ____________________________________________________ 64

6.10

Any Time Interrogation (ATI) containing an imported or own MSISDN received in interconnection_____________________________________ 66

6.11

Send Routing Info for Location (SRIfLCS) containing an imported or own MSISDN ________________________________________________ 67

6.12

Send Routing Info for Location (SRIfLCS) containing an exported or foreign MSISDN _____________________________________________ 69

6.13

Send Routing Info for Location (SRIfLCS) containing an imported or own MSISDN received in interconnection ________________________ 71

6.14

SendIMSI containing an imported or own MSISDN________________ 73

6.15

SendIMSI containing an exported or foreign MSISDN _____________ 75

6.16

SendIMSI containing an imported or own MSISDN received in interconnection ______________________________________________ 76

7

The SRN technical specification _______________________ 79 7.1

Proposed solution ____________________________________________ 79

7.2

Non-functional requirements ___________________________________ 79

7.3

Functional requirements ______________________________________ 7.3.1 Service subscribers data ____________________________________ 7.3.1.1 SUBSCRIBER table _____________________________________ 7.3.1.2 Database search procedure ________________________________ 7.3.2 Service configuration data___________________________________

80 82 82 83 84

7

Contents

7.3.2.1 7.3.2.2 7.3.2.3 7.3.2.4 7.3.2.5 7.3.2.6 7.3.2.7 7.3.2.8 7.3.2.9 7.3.2.10 7.3.2.11

Configuration parameter tables _____________________________ HLRLOCATION table ___________________________________ NETWORK table _______________________________________ MSISDNNORMALIZATION table _________________________ MSISDN normalization procedure __________________________ COMBINATION table ___________________________________ Combination procedure___________________________________ MGTTRANSLATION table _______________________________ MGT-IMSI translation procedure ___________________________ TCAPERRORCODES table _____________________________ LOCAL table_________________________________________

85 86 86 87 88 89 90 91 92 92 93

7.4

Signaling____________________________________________________ 7.4.1 General _________________________________________________ 7.4.2 MAP processing __________________________________________ 7.4.2.1 MSISDN processing _____________________________________ 7.4.2.2 Foreign MSISDN SRI processing___________________________ 7.4.2.3 Foreign MSISDN non SRI processing _______________________ 7.4.2.4 MSISDN not found ______________________________________ 7.4.2.5 NRN – Database mismatch ________________________________ 7.4.2.6 IMSI processing ________________________________________ 7.4.2.7 IMSI not found _________________________________________

93 93 96 97 97 98 98 98 98 99

7.5

Statistics ___________________________________________________ 7.5.1 Counters _______________________________________________ 7.5.1.1 SS7 stack counters _____________________________________ 7.5.1.2 Operating system counters _______________________________ 7.5.1.3 Service logic counters ___________________________________

7.6

Alarms ____________________________________________________ 103 7.6.1 MNP/FA application alarms ________________________________ 103 7.6.2 SRN node alarms ________________________________________ 103

7.7

Provisioning system__________________________________________ 103 7.7.1 Provisioning system log ___________________________________ 104 7.7.2 Provisioning interface performance issues _____________________ 105

8

101 101 101 101 101

Conclusions and future work _________________________ 106 8.1

Conclusions ________________________________________________ 106

8.2

Future work ________________________________________________ 107

9

Definitions, abbreviations and symbols_________________ 108 9.1

Definitions _________________________________________________ 108

9.2

Abbreviations_______________________________________________ 109

9.3

Symbols ___________________________________________________ 112

10

References ________________________________________ 115

Appendix A ______________________________________________ 117 Update Location (UL) ______________________________________________ 117 GPRS Update Location (GPRS UL) __________________________________ 118

8

Contents

Send Routing Info (SRI) ____________________________________________ 120 Send Routing Info for Short Message (SRIfSM) ________________________ 122 Any Time Interrogation (ATI)_______________________________________ 124 Send Authentication Info (SAI) ______________________________________ 126 Send Routing Info acknowledgement (SRI_ack) ________________________ 128 Initial Address Message (IAM) ______________________________________ 129 Send Routing Info for Location (SRIfLCS) ____________________________ 130

Appendix B ______________________________________________ 135

9

1 Introduction

1

Introduction

1.1

Short Background

In the original Global System for Mobile Communications (GSM) specification there is only one subscriber database, also called the Home Location Register (HLR), assigned to every network operator. Obviously, due to the great initial growth of the GSM networks it soon became impossible to find a physical platform which could support the great number of subscribers. This extraordinary initial growth was the reason why the subscriber database had to be divided in various physical platforms. The division was done via static configurations where a certain range of subscribers were assigned to a specific physical subscriber database. The static assignment made sure that the rest of the network nodes easily would know where the information of a certain subscriber was stored. The subscriber database or HLR is the database which stores the subscriber profile information, certain dynamic information such as the call forwarding settings, the information about where the subscriber currently is located and its telephone number. The subscriber database may be interrogated about a subscriber based on both the subscribers telephone number and a special subscriber identifier called the International Mobile Subscriber Identity (IMSI). The static allocation of subscribers in the physical subscriber databases creates various problems for the network operators. One of the most costly problems that arises is the fact that every sales point of the network operator has to maintain a stock of Subscriber Identity Modules (SIM), commonly know as SIM cards, for every physical subscriber database in the operator network. Lets look at an example to explain this problem. •

A subscriber has lost his mobile phone including the SIM card. He addresses one of the operator sales points to get a new phone and more importantly a new SIM card with the same phone number as before. Since every SIM card has a unique subscriber identifier, the IMSI, which in turn is dependent on in which subscriber database the subscriber is allocated, the subscriber must be given a new SIM card which corresponds to its subscriber database. Therefore the sales point must maintain a stock of SIM cards for every possible subscriber database in the operator network.

The above situation becomes even more difficult since the introduction of the so called Mobile Number Portability (MNP). MNP is when a subscriber may change network operator without changing its telephone number. MNP has surged because of European and Spanish legislation. The goal of this legislation is to raise the level of competition between network operators by lowering the barrier for a subscriber to switch network operator. The fact that it is possible to bring ones telephone number along when switching network operator makes the situation with the statically assigned subscriber databases unstable since these new imported telephone numbers may be of any range and will not be covered by the default allocation. This thesis is aimed to resolve these two problems in a joint manner by introducing two new functionalities in the operator network. The first one is MNP which has already been described and the second one is called Flexible Allocation (FA). FA is, as the 10

1 Introduction

name indicates, a way to dynamically allocate subscribers in any subscriber database. FA allows any subscriber to be allocated in any subscriber database in order to allow these to be used more efficiently.

1.2

Work Done

Solutions to MNP have been implemented in many operator networks since legislation to support this functionality was passed in many European countries during 2000 and 2001. To the best of our knowledge, a few network operators also support FA. Since these two functionalities seen from a technical point of view are very similar this master thesis is aimed to resolve both in a joint manner something which in my knowledge has not been done before. The master thesis is based on an internal project at Vodafone Spain to implement the FA functionality in their network. I have thereafter continued the research to extend the solution by adding support for MNP as well. To be able to do this some of my sources [4], [6], [8], [20] are specifications of either MNP or FA functionality nodes or functionality specifications. As part of the team developing the FA functionality for Vodafone Spain we have studied the possible approaches to a solution. The steps of the Vodafone Spain project were 1. Define the problem 2. Isolate possible approaches to a solution 3. Deduce pros and cons of each approach 4. Choose the most appropriate approach to a solution 5. Study in-depth the chosen approach and deduce all possible traffic cases 6. Produce the node specification Once the FA functionality had reached this level of maturity I considered it an appropriate moment to fork of my own research of the dual MNP/FA functionality. The solution I present is sufficiently flexible to include all approaches considered by the internal Vodafone project and therefore does not contain much discussion concerning this choice. I wanted the solution to be sufficiently flexible to be of use for almost any network operator that would like to implement the two functionalities in my joint manner. My own work may be considered as a repetition of steps 1, 4, 5 and 6 but for the joint MNP/FA functionality. The main part of my work has been defining the problem when the two functionalities MNP and FA are presented as one, study what requirements this approach generates and finally propose a solution in the shape of a new network node.

11

1 Introduction

1.3

Outline

First of all the reader is introduced to all the GSM and Universal Mobile Telecommunications System (UMTS) nodes which will be of importance during the discussions in the rest of the document. This is the first part of Chapter 2 “Introduction to GSM/UMTS Networks” which is followed by an introduction to the traffic scenarios in which our solution will be implicated. The chapter ends with an introduction to the network protocols needed for the discussion of MNP and FA. Chapter 3 “Introduction to Mobile Number Portability (MNP)” and 4 “Introduction to Flexible Allocation (FA)” are detailed introductions to the MNP and FA functionalities. In these chapters, reasons to why they are implemented as well as their technical specifications are discussed. Chapter 5 “MNP/FA solution” look at the requirements of the two functionalities. At first, each one on its own and then the two of them together. Next we take a deeper look at the traffic cases in which our solution is implicated. Since we then have the basic knowledge of what the node is supposed to do we may examine its actions case by case. The requirements of the node tells us which these cases are. All of this is described in Chapter 6 “The Signaling Relay Node (SRN) in Action”. Finally Chapter 7 “The SRN technical specification”, specifies how our solution is implemented on top of a hardware and software platform.

12

2 Introduction to GSM/UMTS networks

2

Introduction to GSM/UMTS Networks

This first chapter will be quite general and aims to provide the basic technical foundations of Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) technologies. The chapter explains all the concepts needed to be able to follow the discussion through the rest of this thesis. Therefore, the present chapter should not be considered an overview of the GSM and UMTS technologies since information not relevant to the scope of this document is omitted. A reader already experienced with the GSM and UMTS technologies may skip ahead to the next chapter. Most of the nodes in the UMTS networks have the same or very similar functionality as their predecessors in GSM networks. Throughout the rest of this document when we talk about these nodes their UMTS name will be used even though we mean the concept node in both technologies. If we want to discuss a concept node for one technology in particular, their appropriate name will be used and the fact that the discussion only applies to one technology will be pointed out. First of all we take a simplified look at the whole problem scenario to provide some basic understanding of how a GSM/UMTS network works. Then we take a look at the nodes of the GSM/UMTS network. After that a couple of relevant traffic cases are discussed and finally we look at relevant network protocols. Since there are so many abbreviations in GSM/UMTS terminology a complete list of all abbreviations used in this document can be found in Chapter 9.2.

2.1

A Simplified Problem Scenario

First of all we will provide a very simple, easily understood and overlooking picture of the basic problematic scenarios omitting, without falsifying, most detail. First of all lets take a look at an operator network without and with the Flexible Allocation (FA) functionality. In any GSM/UMTS network there is a lot of signaling traffic which nowadays is totally separated from the regular voice traffic. The signaling is needed managing the calls and the subscribers, e.g. how to route a call to a mobile telephone which we do not know where it is. The signaling traffic is routed on its own routes and has its own routers. The routers know where to route the signaling traffic in every possible scenario which sometimes even include routing messages without an destination address. These messages are then routed based on what telephone number they are carrying and what type of service they provide. Without FA some signaling traffic within the network has to find the subscriber databases (which we will call Home Location Register (HLR) from now on) based on static defined routing. These static routing decisions are performed in the network signaling routers (which we will call Signaling Transfer Point (STP) from now on). The routing decision is based on either the subscribers telephone number or a specific subscriber identifier. Figure 2.1 illustrates this scenario. This static decision results in that a specific subscriber always has to be stored in a specific HLR.

13

2 Introduction to GSM/UMTS networks

Static routing decision

STP

HLR 1

HLR 2

... HLR n

Figure 2.1 The STP has to take a static routing decision when routing traffic to the HLRs in a network without FA.

One scenario requiring this signaling message routing is when a call has to be routed to a mobile telephone. The above presented message is necessary since the HLR is the only node in the network that knows where the mobile phone is. The above message is therefore the petition to the HLR asking it to provide the routing information to reach the mobile telephone. Once FA has been introduced into the same GSM/UMTS network the same decision will be taken dynamically by the new functionality. The new scenario is illustrated in Figure 2.2. The new FA functionality allows a specific subscriber to be stored in any of the available HLRs.

14

2 Introduction to GSM/UMTS networks

Dynamic routing decision

SRN

HLR 1

HLR 2

... HLR n

Figure 2.2 The FA functionality here shown as a node (SRN) takes a dynamic routing decision when routing signaling traffic to the HLRs in a network with FA.

Now lets take a look at the Mobile Number Portability (MNP) functionality which is closely related technically with FA even if it at a first glance might not seem that way. MNP allows the subscriber to bring his/her telephone number (which we will call Mobile Station Integrated Services Digital Network number (MSISDN) from now on) along when changing network operator, i.e. export the MSISDN. In the same way as FA decides to which HLR the signaling traffic shall be routed, the MNP functionality has to decide whether or not the MSISDN is an own or exported number. The introduction of MNP results in that some signaling for a mobile subscriber will depend on both the donor and the recipient network. Exactly what signaling this is will become clear in Chapter 6. We illustrate this in Figure 2.3.

15

2 Introduction to GSM/UMTS networks

Dynamic routing decision

HLR n

Signaling message from a network node, e.g. MAP SRI SRN

Another Network Operator

Figure 2.3 The MNP functionality here shown as a node (SRN) takes a dynamic decision whether or not the signaling message belongs to the own network of if the MSISDN which it concerns has been exported.

One scenario requiring this signaling message routing is for example when we want to send a short message to a mobile telephone which MSISDN has been exported to another network operator. The message which needs to reach the HLR, asks the HLR how to route the short message in order for it to finally reach the mobile telephone. Since the MSISDN may be exported and thus the HLR would be located in a foreign network, the MNP functionality may have to route this message directly towards an external network. Now when we have seen the basic problem scenario we should look at the network nodes which are involved in the signaling traffic which causes these situations. It is not very important to know every little detail about every node but rather what the different nodes do in a conceptual manner.

2.2

Network Nodes

GSM/UMTS networks are divided into two major subsystems. These are the Radio Network Subsystem (RNS) which is responsible for the radio communications with the Mobile Stations (MS) and the Network and Switching Subsystem (NSS) which includes the functions of switching traffic and signaling and also storing subscriber data. The GSM equivalent to the RNS is the Base Stations Subsystem (BSS). For the scope of this document we may say that the functionality and responsibility of the BSS are equivalent to those of the RNS.

16

2 Introduction to GSM/UMTS networks

Finally there is of course also the MS which consists of •

•

Mobile Equipment (ME) such as a hand portable or a vehicle mounted unit. Subscriber Identity Module (SIM), which contains the entire customer related information (identification, secret key for authentication, etc.)

Figure 2.4 shows a schematic view of a GSM/UMTS network. The nodes that we will discuss are shown in the figure. In the NSS only signaling links are marked to improve visibility.

17

2 Introduction to GSM/UMTS networks

HLR/AuC

SCP

GMLC STP

NSS

GGS N

UMSC/ VLR SGSN

SMSC

RNS RNC

Node B

Node B

MS

Figure 2.4 View of the GSM/UMTS network.

2.2.2 Node B and Radio Network Controller (RNC) Both the Node B and the RNC are parts of the RNS. This subsystem is responsible for the direct contact with the MS through the radio interface and is also in contact with the switches of the NSS through the RNC. The Node B is the node which is in direct contact with the MS through the radio interface.

18

2 Introduction to GSM/UMTS networks

The RNC is the node which is in contact with the switches of the NSS. For the scope of this document, we do not need to go into more details of how the Node B and RNC work as long as we have grasped the concept that the RNS is responsible for the transportation of traffic and signaling between the NSS and the MS. Figure 2.5 illustrates this concept. The nodes in the NSS will be discussed in the next chapter and on. The Base Transceiver Station (BTS) and the Base Station Controller (BSC) are the equivalent of the Node B and the RNC in GSM terminology. The BTS and the BSC together compose the BSS which is equivalent to the RNS in UMTS terminology. For the scope of this document we may say that the functionality and responsibility of the BSS is equivalent to those of the RNS.

Node B Node B

MS

RNC

Node B RNS

UMSC/ VLR NSS

Figure 2.5 The RNS is responsible for the transportation of traffic between the NSS and the MS.

2.2.3 UMTS Mobile Service Switching Center (UMSC) and Visitor Location Register (VLR) The UMSC is the first node we discuss within the NSS. The UMSC has a long list of responsibilities but we will only discuss a single one which is relevant to the scope of this document. The UMSC’s main function consists of coordinating the setting up of calls to and from the GSM/UMTS users. The UMSC has interfaces with the RNS on one side and with the rest of the NSS and other external networks on the other. Figure 2.6 illustrates the UMSC/VLR’s position in the network. The UMSC performs the telephony switching functions of the GSM/UMTS circuitswitched system, like the Service GPRS Support Node (SGSN, which we discuss in Chapter 2.2.6) switches the GSM/UMTS packet-switched traffic. The UMSC controls calls to and from other telephony and data systems, such as the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), Public Land Mobile Network (PLMN), Public Data Networks and possibly some private networks. The VLR is usually combined in the same piece of hardware as the UMSC. But even though they might be hosted in the same node they function logically as two separate entities and communicate with each other in exactly the same way as if they would have been physically separated. The VLR’s main functions is to record a subscribers presence in its Service Area (SA) and download the subscriber data from the HLR. This

19

2 Introduction to GSM/UMTS networks

activity is referred to as a Location Update (LU). The VLR contains all subscriber data required for call handling and other purposes for mobile subscribers currently located in the SA controlled by the VLR. A UMSC/VLR controls one or more Location Areas (LA) which consists of a group of RNSs each containing one or more Node Bs. The system uses the LAs to search for active subscribers (active MSs). An LA is part of the network in which an MS may move around without reporting its location to the network. One UMSC/VLR SA is made up of a number of LAs. The SA is the part of the network that is covered by one UMSC/VLR. When a MS is switched on, it is continually listening to what Location Area Identity (LAI) the nearest Node B reports. When the mobile station enters a new LA or UMSC/VLR SA, it recognizes a new LAI and will inform the VLR (which could but must not be a new VLR) of its new location. The VLR reports the MS’s change in location to the HLR and also requests and stores data about the MS. If the MS makes a call at another time, the VLR will then already have the information needed for that call setup.

RNC

UMSC/ VLR

HLR

Figure 2.6 A view of the UMSC/VLR’s position in the GSM/UMTS network.

2.2.4 Home Location Register (HLR) and Authentication Center (AuC) The HLR is the database responsible for storing subscriber data. These data include relevant subscriber information to the provisioning of telecommunications services and is always stored in the HLR independently of the current location of the MS. In addition the HLR includes information about the location of the MS. The HLR gets this information from the VLR and the SGSN. The HLR handles signaling transactions with both UMSC/VLR nodes and SGSNs, which either request information from the HLR or update the information contained within the HLR. The HLR also initiates transactions with VLRs to complete incoming calls and to update subscriber data. Figure 2.7 illustrates the HLR/AuC’s position in the network. The HLR contains three main types of data. 1. Non permanent data concerning the subscriber which the subscriber can modify, e.g. call forwarding settings. 2. Permanent data concerning the subscribers contracted services, e.g. data call settings.

20

2 Introduction to GSM/UMTS networks

3. Non permanent data concerning the subscribers location. These data specifies in which VLR and SGSN the subscriber is located at the moment. This documents aim to resolve an addressing issue that arises when one physical HLR no longer is sufficient for storing and serving the data of all subscribers in one GSM/UMTS network. But for now we will concentrate on the introduction to GSM/UMTS network nodes. The AuC is the database that manages security data for the authentication of subscribers. It also produces the data necessary for the encryption of the radio interface between the MS and the Node B. Within the encryption data an authentication triplet is contained. The AuC does not necessarily share the same piece of hardware as the HLR and may be located separately. The two nodes, in either case, function logically as two separate entities and communicate with each other in exactly the same way as if they would have been physically separated.

HLR/AuC

UMSC/ VLR

SGSN

Figure 2.7 A view of the HLR/AuC’s position in the GSM/UMTS network.

2.2.5 Signaling Transfer Point (STP) The NSS makes use of a signaling support network, at least partly external to GSM/UMTS, following the CCITT Signaling System nº7 (SS7) protocols. This signaling network enables cooperative interworking between NSS machines within one or several GSM networks. The STP is the switching equipment for all signaling traffic between nodes in the GSM/UMTS network. Figure 2.8 gives us a good picture of what the STP does and where it is located in the GSM/UMTS network. As you can see from Figure 2.8, earlier and later figures in this chapter are not taking the STP into account.

21

2 Introduction to GSM/UMTS networks

RNC

STP

UMSC/ VLR

HLR

SGSN

Figure 2.8 A view of the STP’s position in the GSM/UMTS network.

2.2.6 Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) The joint functionality of the SGSN and the GGSN is the equivalent to the UMSC/VLR but for General Packet Radio Service (GPRS) packet switched traffic. For the scope of this document this is all the we need to know about these two nodes. The Serving GPRS Support Node (SGSN) is a primary component in the GSM/UMTS network using GPRS. The SGSN’s main functions includes detecting and recording the presence of GPRS MSs in its Routing Area (RA) and forwarding incoming and outgoing IP packets addressed to/from a MS that is attached within the SGSN RA. In the same way as the UMSC/VLR, the SGSN needs to download the subscriber data from the HLR. The SGSN’s position in the GSM/UMTS network is shown in Figure 2.9.

RNC

SGSN

HLR

Figure 2.9 A view of the SGSN’s position in the GSM/UMTS network.

The GGSN is the gateway for data packet traffic between the GSM/UMTS network and external data packet networks, e.g. the Internet. Like the SGSN, the GGSN is a primary component in the GSM/UMTS network using GPRS. The SGSN’s position in the GSM/UMTS network is shown in Figure 2.10.

22

2 Introduction to GSM/UMTS networks

RNC

SGSN

GGS N

External Network

Figure 2.10 A view of the GGSN’s position in the GSM/UMTS network.

2.2.7 Short Message Service Center (SMSC) The SMSC is the central node in Short Message (SM) handling in the GSM/UMTS network. It’s main functions are. •

•

•

•

Receiving Mobile Originating Short Messages (MO-SM). Storing SMs until delivery is possible. Delivering Mobile Terminating Short Message (MT-SM). Sending confirmations to the originating MS.

For the delivery of a SM the SMSC receives the SM from the UMSC, contacts the HLR to find out in which VLR the MS is located and finally forwards the SM to the UMSC of that VLR. Figure 2.11 illustrates the SMSC’s signaling connections.

UMSC/ VLR

SMSC

HLR/AuC

Figure 2.11 A view of the SMSC’s position in the GSM/UMTS network.

2.2.8 Service Control Point (SCP) An intelligent network (IN) is a service-independent telecommunications network. That is, intelligence is taken out of the UMSCs and placed in computer nodes that are distributed throughout the network. This provides the network operator with the means to develop and control services more efficiently. New capabilities can be rapidly introduced into the network. The SCP is the functional entity and the source of call control within the IN. The SCP is responsible for the execution of IN services. Typical SCP functions are. •

Collection and output of statistics.

23

2 Introduction to GSM/UMTS networks •

•

•

•

•

Output of call reports. Customer control of data in SCP. Queuing of calls. Charging Data Output. Different IN interfaces towards a wide range of network elements, e.g. the HLR.

The last bullet in the list is the one we later on will be interested in when the SCP contacts the HLR. Figure 2.12 shows the SCP’s interfaces in the GSM/UMTS network.

SMSC

SCP

UMSC/ VLR

HLR/AuC

SGSN

Figure 2.12 A view of the SCP’s position in the GSM/UMTS network.

2.2.9 Gateway Mobile Location Center (GMLC) A GMLC is the node that interfaces with location applications which request GSM/UMTS Location Services for a specific subscriber. The GMLC can perform location application authorizations to check the validity of the requesting application. Figure 2.13 shows the GMLC’s position in the GSM/UMTS network. Typical GMLC functions are. •

•

•

Interface with location applications which may be both internal to the network operator as well as external. Authenticate the location applications. Query the HLR for the requested location information.

24

2 Introduction to GSM/UMTS networks

HLR/AuC

GMLC

External/Internal locati on applicati ons

Figure 2.13 A view of the GMLC’s position in the GSM/UMTS network.

2.3

Traffic cases

To get a better feeling for the functionality of the different nodes in the GSM/UMTS network, we will now take a look at a few different traffic cases where most of the above nodes are involved. Some of the situations causing these traffic cases are well known even to someone inexperienced in GSM/UMTS technology, others are buried deep inside the network infrastructure and never shows itself for the day to day subscriber. All of the traffic cases though have in common that they present the necessity to reach the HLR without knowing its address information. This phenomenon is what we will be treating further on in this document so pay close attention to these situations.

2.3.1 Normal Location Updating (LU) A roaming mobile subscriber, moves freely within the GSM/UMTS network. Because the network knows the location of the MS, it is possible for the mobile subscriber to receive a call wherever they are. To keep the system updated with the current subscriber location information, the MS must inform the system whenever it changes LA. A LA consists of one or more cells in which a MS can move around without needing to update the VLR on its location. A location area is controlled by one or more RNCs but by only one UMSC/VLR. A UMSC/VLR can control more than one LA. The RNC sends paging messages to the Node Bs defined within a certain LA. If the MS moves between cells belonging to different LAs, the network must be informed via a procedure called LU. There are really four different types of LUs but for the scope of this document we only need to grasp the concept of the normal LU. The Node B of every cell continuously transmits the LA identity into the air on a special broadcast channel. When the MS detects that the broadcast LA identity is different from the one stored in the SIM-card, it performs a LU. If the mobile subscriber is unknown to the UMSC/VLR, i.e. the broadcast LA belongs to a new UMSC/VLR SA, then the new UMSC/VLR must be updated with subscriber information. This subscriber information comes from the HLR. This location updating procedure is described in the following steps and shown in Figure 2.14.

25

2 Introduction to GSM/UMTS networks

1. The MS requests a LU to be carried out in the new UMSC/VLR. The International Mobile Subscriber Identity (IMSI) is used to identify the MS and is sent to the new UMSC/VLR by the MS. An International Mobile Equipment Identity (IMEI) check is also performed if supported by the network. 2. In the new UMSC/VLR, an analysis of the IMSI number is carried out. The result of this analysis is a modification of the IMSI to a Mobile Global Title (MGT) which is used to address the HLR. 3. The new UMSC/VLR requests the authentication triplets for the MS from the AuC by passing the request to the HLR which in turn knows how to route it to the AuC. 4. The new UMSC/VLR requests the subscriber information for the MS from the HLR. This message is called Update Location1 (UL) which later on will be important. 5. The HLR stores the address of the new UMSC/VLR. 6. The HLR sends the subscriber data to the new UMSC/VLR. 7. The HLR also orders the old serving UMSC/VLR to cancel all information for the subscriber because the mobile subscriber is now served by another UMSC/VLR. 8. When the new UMSC/VLR receives the information from the HLR, it sends a LU confirmation message to the MS. Note that the HLR is not informed if the mobile subscriber moves from one LA to another within the same UMSC/VLR SA.

1

Note the difference between the Location Updating (LU) procedure and the Update Location (UL) signaling message.

26

2 Introduction to GSM/UMTS networks 2. IMS I ↔ MGT

3. Authenticati on UMSC/ VLR 4. Y Subscriber informati on 6. request Subscriber informati on response

1. Location Updating request RNC

5. Store IMS I ↔ UMSC/ VLR

Node B

LAI=Y

MS

LAI=X

HLR/AuC 7. Location cancellati on

UMSC/ VLR X

RNC

Node B

Figure 2.14 Normal Location Updating. The MS moves from LAI=X to LAI=Y and registers therefore with UMSC/VLR Y.

2.3.2 GPRS Attach When GPRS is activated in a MS, the MS needs to locate itself in the GSM/UMTS network. This operation is called the GPRS attach. A variety of different types of GPRS attach, detach and also RA Updates exist but for the scope of this document we only need to know how the regular GPRS attach work and then just keep in mind that others exist. The GPRS attach procedure is described in the following steps and shown in Figure 2.15. 1. The MS sends an Attach Request to the SGSN including its IMSI to identify itself. Next the SGSN performs the authentication procedure. 2. In the SGSN, an analysis of the IMSI number is carried out. The result of this analysis is a modification of the IMSI to the MGT which is used to address the HLR. 3. The SGSN sends the GPRS Location data for the MS to the HLR.

27

2 Introduction to GSM/UMTS networks

4. The HLR replies with the subscriber data related to GPRS. The subscriber data is then stored in the SGSN. 5. Finally the SGSN confirms the GPRS Attach with the MS. 2. IMS I ↔ MGT 5. Attach Accept 1. Attach Request 3. Update GPRS Location

SGSN (new)

RNC

4. Insert Subscriber Data

B Node

MS

HLR

Figure 2.15 GPRS Attach

2.3.3 Call to Mobile Subscriber There are may scenarios how a telephone call may be set up in a mobile network. The only part of the setup which interests us and is vital for the scope of this document is how the call finds and is routed to the mobile subscriber. Therefore we will only discuss this part of the setup and it may be generalized in the following way for our purposes. The following procedures for a call to a mobile subscriber are illustrated in Figure 2.16. 1. Any call entering the GSM/UMTS network from the PSTN/ISDN, from another PLMN or from a MS in the own mobile network, is routed to a UMSC. This UMSC (sometimes called the GMSC where the G stands for Gateway) receives an ISDN User Part (ISUP) Initial Address Message (IAM) indicating an incoming call. 2. The UMSC analyzes the MSISDN to find out which HLR the mobile subscriber is registered in. An authentication request is made to the AuC associated with this HLR and then the UMSC sends the MSISDN along with a request for routing information to this HLR. These messages are the Send Authentication Info (SAI) and Send Routing Info (SRI) which later on will be important. The serving UMSC/VLR address is stored in the HLR from location updating. The HLR contains the IMSI that is connected to this MSISDN number. 3. The HLR sends a request for a Mobile Station Roaming Number (MSRN) to the UMSC/VLR of the LA where the MS is located. Included in the message is the

28

2 Introduction to GSM/UMTS networks

called MS’s IMSI. The UMSC/VLR allocates a free MSRN and links it to the IMSI. 4. The MSRN is returned via the HLR to the UMSC. 5. The UMSC, by means of the MSRN, routes the call to the UMSC/VLR of the called MS. 6. When the UMSC/VLR receives the call, it uses the MSRN to retrieve the MS’s IMSI. The MSRN is then released. 7. Using the MS’s IMSI, the UMSC/VLR identifies the LA in which the MS is situated. 8. The MS is paged in all cells within this LA. 9. When the MS responds to the paging message, authentication, cipher mode setting, and an IMEI check are carried out if supported by the network. 10. If the authentication is confirmed and ciphering is successful, then the call is connected from the UMSC to the RNC and the Node B, where a traffic channel is selected on the air path.

8. Page

4. MS RN

HLR 2. MS ISDN

3. IMS I

9. Page response

4. MS RN

MS

B Node 10.

8. Page

1. MS ISDN 5. UMSC

UMSC/ VLR 6. MSRN ↔ IMS I 7. IMS I → LAI

RNC

B Node

8. Page

B Node

Figure 2.16 Call to MS

29

2 Introduction to GSM/UMTS networks

2.3.4 Short Message to a MS Once a short message has reached the SMSC it will be treated as a MT-SM. It is now the responsibility of the SMSC to deliver the SM to the MS. The following procedures for a MT-SM are illustrated in Figure 2.17. 1. The SMSC performs query with the HLR to locate the subscriber. This is done via the Send Routing Info for Short Message (SRIfSM) message which will be of importance later on. This message is routed on the MSISDN of the recipient. 2. The HLR checks where the subscriber is located (VLR address). Instead of sending a roaming number back to the UMSC (no speech channel is needed), the HLR sends back the VLR address to the UMSC. 3. The UMSC sends the MT-SM to the UMSC/VLR where the subscriber is roaming (input from the HLR). 4. The UMSC/VLR receives the MT-SM and analyses it. The UMSC/VLR terminates the MT-SM. The UMSC/VLR checks if the subscriber has subscription of the MT-SM service. If the MS is reachable, the MT-SM is sent to the MS. A SM-complete message is sent back to the SMSC. 2. SRIfS M_ack 1. SRIfS M (MS ISDN) SMSC

HLR/AuC

3. MT-S M

4. SM UMSC/ VLR

RNC

Node B

MS

Figure 2.17 Short message to a MS.

2.3.5 Intelligent Network (IN) Request for Subscriber Information The IN in an operators network provides a way to custom design advanced services outside the GSM/UMTS specification. This is done via functions which are executed by the SCP. When the logic in an IN function so requires the SCP may request subscriber state or location information at VLR level from the HLR. This scenario interest us since it involves reaching the HLR based on only subscriber information.

30

2 Introduction to GSM/UMTS networks

The following procedures are performed when an IN function, executed in the SCP, requests a subscribers location. An illustration is found in Figure 2.18. 1. The logic in an IN function needs to retrieve subscriber information it requests this from the HLR, which is the node that knows where the subscriber is located. This message is the Any Time Interrogation (ATI) Request which is important to the scope of this document. 2. The HLR in turn forwards the request to the VLR which know in exactly what LA and cell the MS is located and also controls the MS state information (in call, etc.). This is done via the Provide Subscriber Info Request. 3. The VLR responds to the HLR with the requested information in the Provide Subscriber Info Response. 4. Finally the HLR can respond to the SCP with the Any Time Interrogation Response. 3. Provi de Suscriber Info Response

HLR/AuC 4. Any Ti me Interrogati on Response

2. Provi de Suscriber Info Request

UMSC/ VLR

1. Any Ti me Interrogati on Request

SCP

Figure 2.18 IN request for subscriber information.

2.3.6 Location Information Request by a Location Application Since the introduction of the GMLC node in GSM/UMTS networks the possibility to physically locate a subscriber has increased. We will discuss a simple way to get a fairly good idea to where the subscriber is located. The below discussion can be found illustrated in Figure 2.19. There exists more than just one way to calculate the location of a subscriber. All of them though have in common the step where the HLR is contacted in the description below. 1. The GMLC receives a petition from an internal or external application regarding the location of a subscriber based on its MSISDN.

31

2 Introduction to GSM/UMTS networks

2. The GMLC sends a request to the HLR to find out in which UMSC/VLR the subscriber is located. This message is the Send Routing Info for Location (SRIfLCS) which will interest us later on. 3. The HLR replies with the information about the UMSC/VLR where the subscriber is located. 4. The GMLC requests the subscriber location from the UMSC/VLR. 5. The UMSC/VLR pages the MS to find out which RNC is in contact with the MS. 6. The UMSC/VLR asks the RNC to calculate the location of the MS 7. The RNC responds with the MS’s location. 8. The UMSC/VLR responds to the GMLC with the MS’s location. 9. Finally the GMLC can supply the internal or external application with the location of the subscriber MSISDN.

3. SRIfLCS_ack

9. 1. Internal or External 4. Provi de Application Subscriber Loc ation

GMLC

2. SRIfLCS (MS ISDN)

HLR/AuC

8. Provi de Subscriber Location ack

5. Page

6. Perform Location 7. response UMSC/ VLR

RNC

Node B

MS

Figure 2.19 Request for the location of a MS.

2.3.7 Short Message from a MS with Policing based on Subscriber IMSI The MO-SM provides the means to transfer a SM from a MS to a SMSC. This can be carried out either when the MS is idle or when a connection (such as speech or fax) already exists. For both successful and unsuccessful deliveries, the MS receives a delivery report.

32

2 Introduction to GSM/UMTS networks

This is not an GSM/UMTS standard scenario but one possible way to implement SM policing in an operator network. The scenario is presented to provide in an understandable way the use of the SendIMSI message. The following procedures where an SM is passed by a policing function executed in the SMSC could be the scenario just before the scenario presented in 2.3.4. This scenario is illustrated in Figure 2.20. 1. A subscriber wants to send a MO-SM. The MS sends along the SMSC address and the recipient MSISDN to the VLR. A subscription check is made in the VLR for the MO-SM service. 2. The VLR queries the HLR for the originating subscribers IMSI by sending it the SendIMSI message including the originating MS’s MSISDN. 3. The HLR replies with the IMSI of the originating MS. Now the VLR can determine that the originating MS really is a client of the network operator (for example to prevent fraud). 4. The VLR uses the SMSC address from the MO-SM message to determine to which UMSC (sometimes called the InterWorking MSC (IWMSC)) the SM needs to be forwarded. The message is finally forwarded to the UMSC. 5. This UMSC forwards the SM to the SMSC.

3. SendIMS I ack (IMS I) 1. MO-S M (MS ISDN) MS

2. SendIMS I (MS ISDN) Node B

RNC

UMSC/ VLR

HLR/AuC

4. FWD S M

5. FWD S M UMSC

SMSC

Figure 2.20 Short message from a MS with SM policing based on subscriber IMSI.

2.4

Protocol stack Signaling System number 7 (SS7)

SS7 is a common channel signaling system where the signaling information related to various user information channels is transferred in one separate signaling channel. The

33

2 Introduction to GSM/UMTS networks

combination of signaling points and their interconnecting signaling links form the SS7 signaling network. Basically, the SS7 can be subdivided into the following major parts. •

•

•

•

•

Message Transfer Part (MTP) Signaling Connection Control Part (SCCP) User Part (e.g ISUP) Transaction Capabilities Application Part (TCAP) Application Part (e.g. Mobile Application Part (MAP))

OMAP

MAP

INAP

ISUP

TCAP

SCCP MTP Figure 2.21 Protocol stack of SS7

An illustration of the SS7 protocol stack is found in Figure 2.21. The two protocols that really interest us in this stack are SCCP and MAP which will be examined more thoroughly than the others.

2.4.2 MTP The basic functions of MTP are. •

•

• •

Quick and error-free transmission of messages between exchanges (signaling points). Routing of messages to their destination signaling point. Distribution of messages to the appropriate user part within the destination signaling point. Rerouting of messages in case of signaling network failures (e.g. breakdown of signaling links or signaling transfer points.

2.4.3 SCCP The basic functions of SCCP are.

34

2 Introduction to GSM/UMTS networks

• • •

• •

Establishment and control of signaling connections (i.e. logical ‘end-to-end’ connections between signaling points via the common channel signaling links). Possibility of worldwide addressing for signaling points. SCCP possesses its own routing label. Connection-Oriented or Connection-Less message transfer. Additional functions for the transfer of messages between exchanges and other signaling points (e.g. databases). Combined with the MTP as the Network Service Part.

These basic functions admit SCCP to deliver the following services. •

• • •

Connection-Less services Provide the SCCP user with the ability to transfer signaling messages without the establishment of a signaling connection. Connection-Oriented services Signaling connections are established and controlled by the SCCP user. These kinds of connections are comparable with dialed telephone connections. Management functions Manage the status of the SCCP subsystems. Information about a change in the subsystem status is provided to other nodes. Functions for routing and address-translation. Provide a translation function, which is asked for Connection-Less and Connection-Oriented service.

The SCCP protocol has two separate ways of routing traffic. The called and calling party address contain the information necessary for the SCCP to indicate an originating node and a destination node. The SCCP user hands over to the SCCP a called party address and if required, a calling party address with every message to be transferred Connection-Less or with the request to setup a signaling connection. Two basic categories of addresses are distinguished. •

•

Global Title (GT) The GT is an address which cannot directly be used for routing in the signaling network. The GT translation function of the SCCP is required which transfers the GT to a Point Code (PC) and a SSN. The determined DPC can either be the destination point or a transfer point in the signaling network. The address translation is continued until the destination point is reached. Destination Point Code (DPC) DPC and SSN allow direct routing by the SCCP and MTP. The translation function of the SCCP is not required.

35

2 Introduction to GSM/UMTS networks

2.4.4 TCAP The basic functions of TCAP are. •

•

•

•

Provides end-to-end protocol between TC users. Interfaces SCCP and uses Connection-Less message transfer. Provides the means to exchange operations and replies via a dialogue. The TCAP is subdivided into Component Sublayer and Transaction Sublayer.

2.4.5 MAP The MAP defines the signaling functions which are concerned with information exchange related to the possibility for a mobile station to roam. MAP is used for. •

•

•

•

•

•

•

•

•

•

•

•

•

Call setup and termination Location update and cancellation Retrieval of mobile subscriber parameters in a call setup Location information Update of HLR and VLR mobile subscriber information Handover Information security Mobile station security Supplementary services Charging Fault recovery Support of Operation & Maintenance (O&M) procedures Short Message transfer

MAP makes use of services offered by SCCP, but only the Connection-Less classes are used since it operates on top of TCAP. The Application Entities (AE) defined for MAP consist of several Application Service Elements (ASE) and are addressed by SubSystem Numbers (SSN). The SSNs for MAP are. •

•

0000 0101

5

Reserved for MAP for future use

0000 0110

6

HLR

36

2 Introduction to GSM/UMTS networks

•

•

•

•

•

0000 0111

7

VLR

0000 1000

8

UMSC

0000 1001

9

EIR

0000 1010

10

AC

0000 1100

12

SMC (Ericsson), not specified in GSM/UMTS

MAP addressing differs depending on if the message is intra-Public Land Mobile Network (PLMN) or inter-PLMN. •

Intra-PLMN o SSN indicator = 1 (MAP SSN always included)

•

o GT or PC may be included Inter-PLMN Destination address. o SSN indicator = 1 (MAP SSN always included) o GT indicator = 0100 = 4 (includes Translation Type (TT), Numbering Plan (NP), Encoding Scheme and Nature of Address (NA)) Originating address o SSN indicator = 1 (MAP SSN always included) o Point Code indicator = 0 o GT indicator = 0001 = 1 (NA indicator only)

The table below shows the addressing used between our basic GSM/UMTS nodes. From \ To

HLR

Other Network E: GT

VLR

UMSC

EIR

-

-

-

I: PC / GT

-

-

T: MSISDN HLR

-

E: GT T: VLR number

37

2 Introduction to GSM/UMTS networks

VLR

I: PC / GT

I: PC / GT

E: GT

E: GT

T: IMSI / T: VLR number MSISDN / HLR number UMSC

I: PC / GT

I: PC / GT

I: PC / GT

I: PC / GT

E: GT

E: GT

E: GT

E: GT

T: MSISDN

T: VLR number T: UMSC number

T: EIR number

I: Intra-PLMN, E: Extra-PLMN, T: Address Type

38

3 Introduction to Mobile Number Portability (MNP)

3

Introduction to Mobile Number Portability (MNP)

Throughout the global telecommunications market, regulators are taking steps to increase competition among service providers. Mandating Mobile Number Portability (MNP) in Global Systems for Mobile communications (GSM) networks is a key part of this process. With MNP subscribers have the ability to change network operator whilst retaining their Mobile Station Integrated Services Digital Network number (MSISDN) for each service used in the new network. The move may, or may not, include a change in service provider. However, MNP implementation presents many challenges for GSM network operators. MNP is not service portability, i.e. if a service supported in the old network is not available on the new network then number porting mechanisms will not provide that service for the porting subscriber. Number porting involving GSM subscriptions does not include porting the International Mobile Subscriber Identity (IMSI). When porting to a GSM subscription a new SIM and IMSI are provided by the recipient network. The step to introduce MNP was taken in Spain in the year 2000. This chapter gives a description of the MNP implementation in Spain.

3.1

Reasons to Introduce MNP

As said earlier, regulators on the global telecommunication market are taking steps to increase competition among service providers. The idea behind this movement is to lower the barrier, for a subscriber, to switch service provider. To demonstrate this barrier we will discuss two examples. •

A company or organization that has been using the same service provider for a couple of years has a huge barrier when switching. The company or organization typically has printed much material such as employee cards, letter paper, envelopes, etc. including the company’s or employees phone number. The company might have vehicles and other equipment also showing contact phone numbers. In addition there is a value in having the same phone number for a long time so that people in general associates a number with a certain service or company. Good examples are. o 112 - Emergency number in the European Union.

•

o 1 800 CALL ATT – AT&T’s collect calling service in the United States. Changing a private mobile phone number is also a barrier for most people even if it is not as costly as in the corporate case above. Family and friend normally know your phone number by heart or keeps it in some sort of address book. Changing ones phone number generally creates communication problems at some point and most people therefore prefer not changing.

These are the typical cases legislators had in mind when they, by introducing MNP, tried to remove or at least lower the barrier to switch service provider.

39

3 Introduction to Mobile Number Portability (MNP)

3.2

MNP Technical Network Specification

The organization in Spain responsible for the MNP legislation is the Comisión del Mercado de las Telecomunicaciones (CMT). They published on June 8, 2000 a specification on how MNP was going to be implemented. This chapter summarizes the content of the specification. •

• • •

To be able to route a call to a ported number a Network Routing Number (NRN) is added in front of the MSISDN. The NRN tells the routing equipment which is the recipient network and how the call therefore shall be routed. The NRN + MSISDN must not be diallable to any other subscriber, the combination is for routing purposes only. No MSISDN may be ported to two different recipient network at any given moment. All network operators shall communicate if their solution for MNP is direct or indirect routing. Mobile Application Part (MAP) signaling will not be interchanged between network operators during the messaging associated with calls.

Even though it is up to the network operator to choose between direct or indirect routing, all network operators within the Spanish MNP domain have opted for direct routing [8] and therefore the focus will be on this option.

3.2.1 Indirect Routing Case: Consult the Number Range Owner Network In a case of indirect routing, the calls and MAP messages to MSISDNs originated in a network within the MNP domain will be routed to the number range owner network2 who owns the MSISDN. Figure 3.1 illustrates the call or MAP message routing procedure in a MNP domain with indirect routing. The calls and MAP messages originated outside the MNP domain will be received by one operator of the MNP domain. This operator now treats the call or MAP message as if it was originated in the own network when it propagates to other networks. If the MSISDN is a ported number, the number range owner network routes the call and MAP messages to the recipient network. With the indirect routing solution, a network operator is only obligated to maintain the MSISDNs exported from its own number ranges in its MNP database.

2

Number Range Owner Network: The network to which a certain number range has been assigned. For more definitions please see Chapter 9.1.

40

3 Introduction to Mobile Number Portability (MNP)

MNP Database

Number Range Owner Network

Reci pient Network

Originating Network

Figure 3.1 Indirect routing of a call or MAP message.

3.2.2 Direct routing case: Consult the originating network In a case of direct routing, the calls and MAP messages to MSISDNs originated in a network within the MNP domain will consult the MNP database in the originating network independently of the MSISDNs number range owner network. Figure 3.2 illustrates the call or MAP message routing procedure in a MNP domain with indirect routing. The calls and MAP messages originated outside the MNP domain will be received by one operator of the MNP domain. This operator now treats the call or MAP message as if it was originated in the own network when it propagates to other networks. Non digital (e.g. Nordic Mobile Telephone (NMT)) network operators will not be obligated to adopt the direct routing solution. This implies that calls originated in a non digital network the case of MNP will be indirect routing. With the direct routing solution, a network operator is obligated to maintain the MSISDNs exported from any network operator within the MNP domain in its MNP database.

41

3 Introduction to Mobile Number Portability (MNP)

MNP Database

Number Range Owner Network

Reci pient Network

Originating Network

Figure 3.2 Direct routing of a call or MAP message.

3.2.3 Signaling Messages for MNP in Call Oriented Cases For call oriented cases, when a MSISDN has been consulted and is not ported in the MNP database (consulted number), the signaling information between network operators shall be included in the ISDN User Part (ISUP) called party number parameter and coded in the following way. •

•

The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the NRN + MSISDN: Called party number = NRN + MSISDN, with the MSISDN made up of 9 digits.

The NRN for consulted and not ported MSISDNs have a 6 digit structure ABCDEF which is described below. Network operator code AB = 00 to 79, CDEF = 9999 Network operator code ABC = 800 to 999, DEF = 999 For call oriented cases, when a MSISDN has been consulted and is ported in the MNP database (ported number), the signaling information between network operators shall be included in the ISUP called party number parameter and coded in the following way. •

•

The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the NRN + MSISDN: Called party number = NRN + MSISDN, with the MSISDN made up of 9 digits.

The NRN for consulted and ported MSISDNs have a 6 digit structure ABCDEF which is described below.

42

3 Introduction to Mobile Number Portability (MNP)

Network operator code AB = 00 to 79, CDEF ≠ 9999

Network operator code ABC = 800 to 999, DEF ≠ 999

The digits AB[C] (AB from 00 to 79 or ABC from 800 to 999) indicates the recipient network operator code and identifies the network operator uniquely. The digits [C]DEF3 shall be freely defined be the recipient network operator, always respecting that [C]DEF ≠ [9]999 In case of error, for both consulted numbers and ported numbers, the release cause to be employed is 0000001 (1 decimal) Number not assigned / Portability error. If an MSISDN has not been consulted there is no change to the interchange of signaling between network operators.

3.2.4 Signaling Messages for MNP in Non Call Oriented Cases For non call oriented cases, when a MSISDN has been consulted and is not ported in the MNP database (consulted number), it is necessary that the querying network includes the signaling information between operators, within the Signaling Connection Control Part (SCCP) parameter Called Party Address (CdPA), with the following codification. •

•

The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the CC + NRN + MSISDN, with the MSISDN made up of 9 digits.

The NRN for consulted and not ported MSISDNs have a 6 digit structure ABCDEF which is described below. Network operator code AB = 00 to 79, CDEF = 9999 Network operator code ABC = 800 to 999, DEF = 999 For not call oriented cases, when a MSISDN has been consulted and is ported in the MNP database (ported number), it is necessary that the interrogating network includes the signaling information between operators, within the SCCP parameter CdPA, with the following codification. •

•

The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the CC + NRN + MSISDN, with the MSISDN made up of 9 digits.

3

Possible use for these three or four digits could be to mark subscribers as for example “pre-paid” or “post-paid” and in this way extract statistics.

43

3 Introduction to Mobile Number Portability (MNP)

The NRN for consulted and ported MSISDNs have a 6 digit structure ABCDEF which is described below. Network operator code AB = 00 to 79, CDEF ≠ 9999

Network operator code ABC = 800 to 999, DEF ≠ 999

If an MSISDN has not been consulted there is no change to the interchange of signaling between network operators. The network operator which detects a portability error in the not call oriented signaling message, shall reject the message.

3.3

NRN assignments in Spain

As of 27-01-2004 the following NRN assignments exist in Spain within the MNP domain. NRN

State

Date

Network Operator

70 xxxx

Assigned

07-09-2000

TELEFÓNICA MÓVILES ESPAÑA, S.A.U. (Moviline)

71 xxxx

Assigned

07-09-2000

TELEFÓNICA MÓVILES ESPAÑA, S.A.U. (Movistar)

72 xxxx

Assigned

07-09-2000

VODAFONE ESPAÑA, S.A.

73 xxxx

Assigned

07-09-2000

RETEVISIÓN MÓVIL, S.A.

74 xxxx

Assigned

07-09-2000

XFERA MÓVILES, S.A.

44

4 Introduction to Flexible Allocation (FA)

4

Introduction to Flexible Allocation (FA)

When Global System for Mobile Communications (GSM) was designed, the designers could not imagine the incredible expansion this technology would go through during its early years. One of its basic thoughts was that the processing and storage capacity of the Home Location Register (HLR) would increase gradually with time and at a similar rate as the use of the networks. Now two decades later we can see that the use of the Public Land Mobile Networks (PLMN) has grown at a much faster rate than the capacity of the HLRs which lately has been following Moore’s law, doubling its capacity every 18 months. These facts has lead to that the HLR nowadays cannot consist in only one piece of hardware but rather various physical nodes which together form one logical HLR. Implementing the HLR this way creates an addressing problem when it comes to directing signaling traffic to one of many physical HLRs. Most network operators (all Spanish network operators) solved this problem, when it first appeared, by statically link together a range of Mobile Station Integrated Services Digital Network numbers (MSISDN), a range of International Mobile Subscriber Identities (IMSI) with a physical HLR. Figure 4.1 illustrates the MSISDN – IMSI – HLR relationship.

Range of MS ISDN 1 Range of IMS I 1 HLR 1

Range of MS ISDN 2 Range of IMS I 2 HLR 2

...

Range of MS ISDN n Range of IMS I n HLR n

Figure 4.1 Illustration of the MSISDN – IMSI – HLR relationship.

This solution creates a situation where when a node has a need to communicate with a physical HLR it can use either the IMSI or the MSISDN for routing purposes. As you can imagine this solution during the first couple of years worked quite fine but after a while started to present problems and inefficiencies such as. 45

4 Introduction to Flexible Allocation (FA)

•

•

•

Need for subscriber migrations between physical HLRs. To not misuse the resources of the physical HLRs they are assigned MSISDN exceeding their capacity. When the network operator subscriber base grows, sooner or later the physical HLR fils up to maximum storage or processing capacity and subscriber migrations will need to take place. Another scenario also causing subscriber migration is the allocation of imported MSISDNs. These imported MSISDNs are a result of the earlier described Mobile Number Portability (MNP). Inefficient use of storage capacity in physical HLRs due to subscribers changing their Subscriber Identity Module (SIM) and therefore their IMSI. The new IMSI will of course be associated with the MSISDN of the subscriber and both the new IMSI and MSISDN already belongs to a HLR through their ranges. This causes the old IMSI to become unused in the HLR. Complex logistic situation to supply new SIMs to a network operators sales points. When a subscriber for an arbitrary reason needs to get a new SIM, the subscriber normally addresses a sales point of the network operator. The sales point supplies the subscriber with a new SIM with an IMSI of the correct range depending on the HLR to which the subscribers MSISDN belong. To be able to supply such a SIM all sales points needs to maintain one stock of SIMs for every HLR in the operator network. The network operator has to choose the amount of SIMs in stock considering the following two situations. o A large stock will always have a SIM available for the subscriber that needs a replacement but on the other hand creates larger upfront production costs. o A smaller stock may present the subscriber with a situation where he/she cannot get a replacement SIM momentarily. This situation creates customer dissatisfaction and costs when it comes to getting the new SIM to the subscriber, e.g. contracting a messenger service to deliver the new SIM.

This is where FA comes into the picture. To be able to resolve the above presented problems we need to end the relationship between the HLR, the IMSI and the MSISDN. FA administers MSISDN and IMSI relationship providing network operators the ability to allocate a SIM in a flexible way in any physical HLR without considering the existing attachment between MSISDN ranges, IMSI ranges and HLRs.

46

5 MNP/FA solution

5

MNP/FA solution

Once we have grasped the concepts of Mobile Number Portability (MNP), Flexible Allocation (FA) and the architecture of a modern Global System for Mobile Communications / Universal Mobile Telecommunications System (GSM/UMTS) network, we can easily understand that the two problems are closely related and that we should be able to resolve both of them in a joint manner.

5.1

FA requirements to a Solution

To resolve FA we need to be able to reroute those Mobile Application Part (MAP) messages which need to reach the Home Location Register (HLR) based on either Mobile Station Integrated Services Digital Network number (MSISDN) or International Mobile Subscriber Identity (IMSI). The rerouting is needed since the MAP messages no longer can depend on the static link between MSISDNs, IMSIs and the HLR. The MAP messages subject to this situation are4. •

•

•

•

Update Location (UL) [5], [10] This is the MAP request sent by the UMTS Mobile service Switching Center (UMSC) / Visitor Location Register (VLR) to the HLR mentioned in point four in Chapter 2.3.1. The UL is routed to the HLR based on an analysis of the IMSI which is translated to a Mobile Global Title (MGT). The UL advices the HLR that the Mobile Station (MS) is now registered in this UMSC/VLR and requests the subscriber data to be stored in the UMSC/VLR. Appendix A contains an example UL message. GPRS Update Location (GPRS UL) [10] This is the MAP request sent by the Service GPRS Support Node (SGSN) to the HLR mentioned in point three in Chapter 2.3.2. The GPRS UL is routed to the HLR based on an analysis of the IMSI which is translated to a MGT. The GPRS UL advices the HLR that the MS is now registered in this SGSN and requests the subscriber data to be stored in the SGSN. Appendix A contains an example GPRS UL message. Send Routing Info (SRI) [10] This is the MAP request sent by the UMSC/VLR to the HLR mentioned in point two in Chapter 2.3.3. The SRI is routed to the HLR based on an analysis of the MSISDN. The SRI requests a Mobile Station Roaming Number (MSRN) which may be considered a temporary telephone number to be able to route the call to the MS current location. Appendix A contains an example SRI message. Send Routing Info for Short Message (SRIfSM) [10] This is the MAP request sent by the Short Message Service Center (SMSC) to the HLR mentioned in point one in Chapter 2.3.4. The SRIfSM is routed to the HLR based on an analysis of the MSISDN. The SRIfSM requests the IMSI of

4

There are a few more situations where this situation arises. The interested reader can find a complete list of these in [11] “Mobile Application Part (MAP) specification”, 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC), chapter 6.1.3.3 “The Home Location Register (HLR)”.

47

5 MNP/FA solution

•

•

•

•

the MS receiving the Short Message and the Global Title (GT) of the UMSC where the MS currently is located. Appendix A contains an example SRIfSM message. Any Time Interrogation (ATI) [10] This is a MAP request sent by the Service Control Point (SCP) to the HLR interrogating it for subscriber information mentioned in point one in Chapter 2.3.5. The ATI is routed to the HLR based on an analysis of the MSISDN. Appendix A contains an example ATI message. Send Authentication Info (SAI) [10] This is the MAP request sent by any node that needs to authenticate the MS mentioned for example in point three in Chapter 2.3.1. The request is sent to the Authentication Center (AuC) but is always routed via the HLR. The SAI is routed to the HLR based on an analysis of the IMSI, which is translated to a MGT. Appendix A contains an example SAI message. Send Routing Info for Location (SRIfLCS) [11] This is the MAP request sent by the GMLC to the HLR interrogating it for subscriber location information mentioned in point two in Chapter 2.3.6. The SRIfLCS is routed to the HLR based on an analysis of the MSISDN. Appendix A contains an example SRIfLCS message. SendIMSI [11] This is the MAP (v2 only) message sent by the VLR to the HLR interrogating it for a subscribers IMSI based on its MSISDN mentioned in point two in Chapter 2.3.7. The SendIMSI is routed to the HLR based on an analysis of the MSISDN.

As seen above all these messages are using either the MSISDN or the IMSI/MGT to find out which is their statically linked HLR. Therefore what we need to add is an additional functionality of dynamic routing based on IMSI/MGT or MSISDN. This new functionality must be placed in one of the existing nodes where the message already passes by (Signaling Transfer Point (STP) or HLR) or in a new node which will capture the message before it gets to the HLR.

5.2

MNP requirements to a Solution

To resolve MNP we need to be able to intercept those MAP messages sent to the HLR (e.g. the SRI message) to verify if the MSISDN is a ported number or not. This new functionality must be placed in one of the existing nodes where the message already passes by (STP and HLR) or in a new node which will capture the message before it gets to the HLR. The MAP messages subject to this situation are. •

•

•

•

SRI SRIfSM ATI SRIfLCS

48

5 MNP/FA solution

•

5.3

SendIMSI

Joint requirements to a Solution

As seen in Chapter 5.1 and 5.2, to satisfy both FA and MNP, we need to implement a new functionality that can intercept the MAP messages. These messages can then be rerouted towards its corresponding HLR passing by the STP. The STP is really the node which takes the decision where to send the MAP message, since all SCCP signaling messages in the operator network passes by here. This node though only has capacity of analyzing the messages up to the Signaling Connection Control Part (SCCP) level and not any higher. The new functionality could be added directly to this node but it would be a matter of totally rewriting the node interior and also probably changing its hardware.5 Many network operators have more than one provider of hardware [16]6, an internal STP development would therefore multiply its cost and risk by the number of hardware providers involved. Another factor which will be of importance when choosing how the new functionality will be implemented is that the network operators have many other systems which interact with the actual GSM/UMTS network, e.g. the provisioning system. Since the newly implemented functionality will have to interact with these systems too, these systems may need to be reconfigured, updated or even replaced which in turn creates extra costs and risks. Due to the above circumstances we are looking at inserting a new node in the operator network which will take care of our FA and MNP. This new node shall then have all MAP messages related to FA or MNP directed to it and somehow modify these so that when they are sent back to the STP they are routed correctly. The STP will have to be reconfigured to reroute all MAP messages related to FA or MNP. More on this later. As commented in the Foreword, this is one of the points in the documents where the decision taken cannot solely be explained by the presented facts but is also a result of the original project circumstances. The above presented facts are merely generalizations of the real reasons every network operator would have to base their decision on.

5

Hardware vendors sometimes have these upgrades available for this functionality. The reasons for not choosing these solutions are normally that the costs and risks in changing provisioning systems are multiples of those for the development of custom made nodes. 6 This fact may be deduced by examining a large number of IR21s from the world’s network operators. The IR21 is the standardized public document every network operator shares to describe its internal structure.

49

6 The Signaling Relay Node (SRN) in action

6

The Signaling Relay Node (SRN) in Action

As described in chapter 5, the implementation of Mobile Number Portability (MNP) and Flexible Allocation (FA) affects all Mobile Application Part (MAP) messages which pretend reaching a determined Home Location Register (HLR) based on the International Mobile Subscriber Identity (IMSI) / Mobile Global Title (MGT) or the Mobile Station Integrated Services Digital Network number (MSISDN). To resolve this, a new node is introduced which intercepts (by rerouting in the Signaling Transfer Point (STP)) these MAP messages. We will call this new node the Signaling Relay Node (SRN). The SRN analyses the message and decides what to do with each one. First of all we will examine the cases where the SRN has to act as relay for the MAP messages. Its actuation depends on whether the message is routed based on IMSI/MGT or MSISDN and in the latter case if the MSISDN has been ported or not.

6.1 Flexible Allocation (FA) only, for Location Updates and Send Authentication Info (SAI) Messages The message at Signaling Connection Control Part (SCCP) level contains a Called Party Address (CdPA) containing a MGT. This means that it is a MAP message (Update Location (UL), General Packet Radio Service Update Location (GPRS UL) or SAI) subject to FA only and shall be treated as described below. The procedure is also illustrated in Figure 6.1. As a reminder we will first discuss what the different protocols and messages are used for. The SCCP protocol is the protocol responsible for the transfer of signaling messages with the ability to address globally. The MAP protocol is responsible for the information exchange related to the possibility for a mobile station to roam. The MAP message UL is used when the mobile station wants to update its location in the Visitor Location Register (VLR) and is sent from the VLR to the HLR asking for subscriber data. The MAP message GPRS UL is used when the mobile station wants to update its location in the Service GPRS Support Node (SGSN) and is sent from the SGSN to the HLR asking for the subscriber data. Finally the MAP message SAI is used when the VLR (or any other node) needs to authenticate the Mobile Station (MS) and is sent by the VLR to the Authentication Center (AuC) via the HLR asking it to send the authentication triplets. 1. A petition is received by the UMTS Mobile service Switching Center (UMSC)/VLR or the SGSN where the analysis of the IMSI takes place. The output of the analysis is the MGT. 2. The UMSC or the SGSN constructs the MAP message (UL, GPRS UL or SAI) with the following parameters at the SCCP level. SCCP

TT7

NP8

NA9

NS

7

Translation Type Numbering Plan 9 Nature of Address 8

50

6 The Signaling Relay Node (SRN) in action

CgPA10

011

112

413

UMSC/SGSN

CdPA

014

715

416

MGT

3. This message gets to the STP in which the following Global Title Translation (GTT) is specified. TT

NP

NA

NS

Æ

New GT

0

7

4

MGT

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains the IMSI-HLR relation. By doing this the SRN conceives the GT of the appropriate HLR. The message is finally send to the HLR with the following SCCP parameters. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC/SGSN17

CdPA

0

1

4

HLR

5. The HLR realizes its normal processing of the received MAP message and since the CgPA has been conserved containing the UMSC´s GT, the HLR sends the MAP reply message directly to the UMSC (via the STP of course), without passing by the SRN.

10

Calling Party Address TT are set to 0 for both CgPA and CdPA since we want to use regular SCCP translations. 12 NP of the CgPA is set to 1 since it is a Global Title (GT) part of the E.164 number series. 13 NA is set to 4 since both CgPA and CdPA are in international format. 14 TT are set to 0 for both CgPA and CdPA since we want to use regular SCCP translations. 15 NP of the CdPA is set to 7 since the message is routed on a MGT part of the E.214 number series. 16 NA is set to 4 since both CgPA and CdPA are in international format. 17 The CgPA of this message is left pointing at the UMSC/SGSN since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRN’s presence. 11

51

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

5.

4. 1.

3.

2. UMSC or SGSN

STP

SRN

Figure 6.1 CdPA contains a MGT, the MAP message is subject to FA.

6.2 Send Routing Info (SRI) Containing an Imported or Own MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.2. The MAP message SRI is used when a call has reached a UMSC. The UMSC sends the SRI message to the HLR asking it for the Mobile Station Roaming Number (MSRN) which is necessary to rout the call. 1. A petition is received by the UMSC/VLR. 2. The UMSC constructs the MAP message SRI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

118

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

18

NP

NA

NS

Æ

New GT

NP of the CdPA is set to 1 since the message is routed on a MSISDN part of the E.164 number series.

52

6 The Signaling Relay Node (SRN) in action

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

1

4

HLR

5. The HLR treats the SRI message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an Send Routing Info acknowledgement (SRI_ack) via the STP.

... HLR 1

HLR n

5.

4. 1.

3.

2. UMSC

STP

SRN

Figure 6.2 Call to an imported or own MSISDN.

6.3 Send Routing Info (SRI) Containing an Exported or Foreign MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRI message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.3.

53

6 The Signaling Relay Node (SRN) in action

1. A petition is received by the UMSC/VLR. 2. The UMSC constructs the MAP message SRI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has been ported or is foreign the conceived NRN is not our own. The SRN answers the UMSC with an SRI_ack (the message the HLR normally would return) indicating the following parameters at the SCCP level. Appendix A contains an example of an SRI_ack message. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SRN19

CdPA

0

1

4

UMSC

And the following data in the SRI_ack MAP message. MAP

IMSI

NP

NA

MSRN

SRI_ack

*20

1

12621

NRN+MSISDN

19

This field could really be set to anything that suits the network operator. The choice to set it to the GT of the SRN is merely an GSM/UMTS orthodox decision. Since the message is closing a transaction it could just as well be set to for example a fictitious GT or even an fictitious IMSI. Another reason though for setting it to the GT of the SRN is that it helps when troubleshooting since we then easily can identify the originating node. 20 Since it is an exported or foreign MSISDN the IMSI does not show up in the SRN database. This parameter may include any number or even be empty. In Spain though it has been decided between the network operators in the MNP domain that this parameter shall be filled with a special predefined IMSI based on which operator the MSISDN belongs to. This decision was takes so that the operators could use this parameter for billing purposes. The possible IMSIs are. • 21401 99999 99999 – Vodafone • 21403 99999 99999 – Amena • 21404 99999 99999 – Xfera

54

6 The Signaling Relay Node (SRN) in action

5. The UMSC now routes the call towards it new destination in another operator network depending on the MAP data (including the NRN of the recipient network) received in the SRI_ack message. The data in the IAM ISUP message follows. An example IAM message can be found in Appendix A. ISUP

NP

NA

Address Signal

CdPN22

1

12623

NRN+MSISDN

... HLR 1

HLR n

4. 1.

2. UMSC

3. STP

SRN

5.

External Network

Figure 6.3 Call to an exported or foreign MSISDN.

6.4 Send Routing Info (SRI) Containing an Imported or Own MSISDN from an Interconnecting Call The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also • 21407 99999 99999 – Movistar NA is set to 126 to indicate that the MSISDN has been consulted and that an NRN has been added in front of the MSISDN. 22 CdPN = Called Party Number 23 NA is set to 126 to indicate that the MSISDN has been consulted and that an NRN has been added in front of the MSISDN. This is how the interface between network operators was specified in [6]. 21

55

6 The Signaling Relay Node (SRN) in action

subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRI message which contains a MSISDN that is imported or own and the call was received in interconnection. The procedure is also illustrated in Figure 6.4. 1. An Initial Address Message (IAM) message is received by the UMSC/VLR interconnecting to an external network. The IAM message contains the following Called Party Number (CdPN) parameters. ISUP

NP

NA

Address Signal

CdPN

1

12624

NRN+MSISDN

2. The UMSC constructs the MAP message SRI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

1

11225

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

112

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

1

4

HLR

24

NA is set to 126 to indicate that the MSISDN has been consulted and that an NRN has been added in front of the MSISDN. This is how the interface between network operators was specified in [6]. 25 In Spain it has been decided between the network operators in the MNP domain that the NA of this message shall be set to 112. This is done so that the SRN can detect when there is a MNP error. If this message gets to the SRN and when the MNP consulting is done it results that the MSISDN is exported or not own, we have detected a MNP error and an alarm must be generated.

56

6 The Signaling Relay Node (SRN) in action

5. The HLR treats the SRI message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an SRI_ack via the STP.

... HLR 1

HLR n

5.

4. 2. UMSC

3. STP

SRN

1.

External Network

Figure 6.4 Call to an imported or own MSISDN where the call was received in interconnection.

6.5 Send Routing Info for Short Message (SRIfSM) Containing an Imported or Own MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.5. The MAP message SRIfSM is used when the Short Message (SM) is routed to its destination MS. The Short Message Service Center (SMSC) sends the SRIfSM to the HLR asking it for the VLR address where the MS is currently located. The SMSC is the node where the SM is stored temporarily until delivery is possible. 1. A Forward Short Message MAP message is received by the SMSC.

57

6 The Signaling Relay Node (SRN) in action

2. The SMSC constructs the SRIfSM MAP message with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SMSC

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SMSC26

CdPA

0

1

4

HLR

5. The HLR treats the SRIfSM message just the same way as if it would have come directly from the SMSC. Finally it replies to the SMSC with an Send Routing Info for Short Message acknowledgement (SRIfSM_ack) via the STP.

26

The CgPA of this message is left pointing at the SMSC since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRN’s presence.

58

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

5.

4. 1.

2.

3.

SMSC

STP

SRN

Figure 6.5 Sending of and SM to an imported or own MSISDN.

6.6 Send Routing Info for Short Message (SRIfSM) Containing an Exported or Foreign MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.6. 1. A Forward Short Message MAP message is received by the SMSC. 2. The SMSC constructs the SRIfSM MAP message with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SMSC

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP

59

6 The Signaling Relay Node (SRN) in action

message to. Since the MSISDN has been ported or is foreign the conceived NRN is not our own. The SRN forwards the SRIfSM message directly towards the external network in which the message will get to the correct HLR including the following SCCP parameters. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SMSC

CdPA

0

1

12627

CC+NRN+MSISDN28

... HLR 1

1.

2. SMSC

HLR n

3. STP

SRN

4.

External Network

Figure 6.6 Sending of and SM to an exported or foreign MSISDN.

6.7 Send Routing Info for Short Message (SRIfSM) Containing an Imported or Own MSISDN Received in Interconnection The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also

27

The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field. 28 As explained earlier the SRIfSM message is forwarded with the CdPA parameter NS set to Country Code (CC) of the MSISDN concatenated with the NRN and the national part of the MSISDN.

60

6 The Signaling Relay Node (SRN) in action

subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is imported or own which has been received in interconnection with an external network. The procedure is also illustrated in Figure 6.7. 1. A Forward Short Message MAP message is received by the UMSC. With the following parameters at the SCCP level. As seen in Figure 6.7 the described interconnection route is via the UMSC which is also the how the interconnection is described in orthodox GSM/UMTS contexts. Since STPs became the central part of routing signaling in the GSM/UMTS networks, network operators often interconnect their STPs directly. This is shown as the grayish “1.” in Figure 6.7. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC29

CdPA

0

1

12630

CC+NRN+MSISDN

2. The UMSC forwards the SRIfSM MAP message with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

UMSC

CdPA

0

1

126

CC+NRN+MSISDN

3. This message gets to the STP in which the following GTT is specified. Æ

TT

NP

NA

NS

0

1

126

CC+NRN+MSISDN Æ

New GT SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

29 This field containing the originating UMSC is interesting since we could, not part of the scope of this document though, use it to set up a centralized SMS policing in the SRN just by filtering messages on this field. 30 The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field.

61

6 The Signaling Relay Node (SRN) in action

CgPA

0

1

4

UMSC

CdPA

0

1

4

HLR

5. The HLR treats the SRIfSM message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an SRIfSM_ack via the STP.

... HLR 1

HLR n

5.

4. 3.

2. UMSC

STP

SRN

1. 1.

External Network

Figure 6.7 Sending of an SM to an imported or own MSISDN where the SRIfSM message is received in interconnection.

6.8 Any Time Interrogation (ATI) Containing an Imported or Own MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a ATI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.8. The MAP message ATI is used when an Intelligent Network (IN) service needs information about a subscriber. The IN node Service Control Point (SCP) sends the ATI

62

6 The Signaling Relay Node (SRN) in action

message to the HLR asking it for subscriber information. The SCP is the node which is responsible for the execution of IN services, e.g. Collect Call. 1. An IN service executing in the SCP needs current subscriber location or status information. 2. The SCP constructs the MAP message ATI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SCP

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SCP31

CdPA

0

1

4

HLR

5. The HLR treats the ATI32 message just the same way as if it would have come directly from the SCP. Finally it replies to the SCP with an ATI_response via the STP.

31

The CgPA of this message is left pointing at the SCP since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRN’s presence. 32 The ATI message must only be replied to by the HLR if it is an imported or own MSISDN. This is because at least in Spain the legislation on automatic personal data treatment (Ley Orgánica 5/1992, de regulación del tratamiento automatizado de los datos de carácter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.

63

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

5.

1. 4. 3.

2. SCP

STP

SRN

Figure 6.8 An IN service interrogating the HLR about an imported or own MSISDN.

6.9 Any Time Interrogation (ATI) Containing an Exported or Foreign MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.9. 1. An IN service executing in the SCP needs current subscriber location or status information. 2. The SCP constructs the MAP message ATI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SCP

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN

64

6 The Signaling Relay Node (SRN) in action

conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has been ported or is foreign the conceived NRN is not our own. The SRN forwards the ATI message directly towards the external network in which the message will get to the correct HLR including the following SCCP parameters. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SMSC

CdPA

0

1

12633

CC+NRN+MSISDN34

... HLR 1

HLR n

1.

2. SCP

3. STP

SRN

4.

External Network

Figure 6.9 An IN service interrogating the HLR about an exported or foreign MSISDN.

33

The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field. 34 As explained earlier the SRIfSM message is forwarded with the CdPA parameter NS set to Country Code (CC) of the MSISDN concatenated with the NRN and the national part of the MSISDN.

65

6 The Signaling Relay Node (SRN) in action

6.10 Any Time Interrogation (ATI) Containing an Imported or Own MSISDN Received in Interconnection The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for an ATI message which contains a MSISDN that is imported or own which has been received in interconnection with an external network. The procedure is also illustrated in Figure 6.10. 1. An ATI MAP message is received by the STP in interconnection. With the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SCP35

CdPA

0

1

12636

CC+NRN+MSISDN

2. In the STP the following GTT is specified. Æ

TT

NP

NA

NS

0

1

126

CC+NRN+MSISDN Æ

New GT SRN

3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

SCP

CdPA

0

1

4

HLR

4. The HLR treats the ATI message just the same way as if it would have come directly from the SCP. Finally it replies to the SCP with an ATI_ack via the STP.

35 This field containing the originating SCP is interesting since we could, not part of the scope of this document though, use it to set up a centralized CAMEL policing in the SRN just by filtering messages on this field. 36 The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field.

66

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

4.

3. 2. STP

SRN

1.

External Network

Figure 6.10 An IN service interrogating the HLR about an exported or foreign MSISDN where the ATI message is received in interconnection.

6.11 Send Routing Info for Location (SRIfLCS) Containing an Imported or Own MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfLCS message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.11. The MAP message SRIfLCS is used when a location application needs to pin down the location of the subscriber. The Gateway Mobile Location Center (GMLC), which has received the petition from the location application, sends the SRIfLCS to the HLR asking it for the address of the VLR where the subscriber is currently located. The GMLC is the gatekeeper and interface for any location application that would like to use the GSM/UMTS positioning service. 1. A location application requests location information about a subscriber to the GMLC. This interface is based upon Internet Protocol (IP) and Hyper Text Transfer Protocol (HTTP).

67

6 The Signaling Relay Node (SRN) in action

2. The GMLC constructs the SRIfLCS MAP message with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

GMLC

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

GMLC37

CdPA

0

1

4

HLR

5. The HLR treats the SRIfLCS38 message just the same way as if it would have come directly from the GMLC. Finally it replies to the GMLC with an Send Routing Info for Location acknowledgement (SRIfLCS_ack) via the STP.

37

The CgPA of this message is left pointing at the GMLC since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRN’s presence. 38 The SRIfLCS message must only be replied to by the HLR if it is an imported or own MSISDN. This is because at least in Spain the legislation on automatic personal data treatment (Ley Orgánica 5/1992, de regulación del tratamiento automatizado de los datos de carácter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.

68

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

5.

4. 2. GMLC

3. STP

SRN

1.

Internal/external Location applicati on

Figure 6.11 A location application interrogates the HLR via the GMLC about an imported or own MSISDN.

6.12 Send Routing Info for Location (SRIfLCS) Containing an Exported or Foreign MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfLCS message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.12. 1. A location application requests location information about a subscriber to the GMLC. This interface is based upon IP and HTTP. 2. The GMLC constructs the SRIfLCS MAP message with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

GMLC

69

6 The Signaling Relay Node (SRN) in action

0

CdPA

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has been ported or is foreign the conceived NRN is not our own. The SRN forwards the SRIfLCS message directly towards the external network in which the message will get to the correct HLR including the following SCCP parameters. SCCP

TT

NP

NA

NS

CgPA

0

1

4

GMLC

CdPA

0

1

12639

CC+NRN+MSISDN40

39

The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field. 40 As explained earlier the SRIfLCS message is forwarded with the CdPA parameter NS set to Country Code (CC) of the MSISDN concatenated with the NRN and the national part of the MSISDN.

70

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

1.

2. GMLC

3. STP

SRN

4.

1.

Internal/external Location applicati on

External Network

Figure 6.12 A location application interrogates the HLR via the GMLC about an exported or foreign MSISDN.

6.13 Send Routing Info for Location (SRIfLCS) Containing an Imported or Own MSISDN Received in Interconnection The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for an SRIfLCS message which contains a MSISDN that is imported or own which has been received in interconnection with an external network. The procedure is also illustrated in Figure 6.13. 1. An SRIfLCS MAP message is received by the STP in interconnection. With the following parameters at the SCCP level.

71

6 The Signaling Relay Node (SRN) in action

SCCP

TT

NP

NA

NS

CgPA

0

1

4

GLMC41

CdPA

0

1

12642

CC+NRN+MSISDN

2. In the STP the following Global Title Translation (GTT) is specified. Æ

TT

NP

NA

NS

0

1

126

CC+NRN+MSISDN Æ

New GT SRN

3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

GMLC

CdPA

0

1

4

HLR

4. The HLR treats the SRIfLCS message just the same way as if it would have come directly from the GMLC. Finally it replies to the GMLC with an SRIfLCS_ack via the STP.

41 This field containing the originating GMLC is interesting since we could, not part of the scope of this document though, use it to set up a centralized localization policing in the SRN just by filtering messages on this field. 42 The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field.

72

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

4.

3. 2. STP

SRN

1.

External Network

Figure 6.13 A location application interrogates the HLR via the GMLC about an imported or own MSISDN where the SRIfLCS message is received in interconnection.

6.14 SendIMSI Containing an Imported or Own MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SendIMSI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.14. The MAP message SendIMSI is used when the VLR for some reason needs to translate a subscribers MSISDN to his/her IMSI. In the example case presented in Chapter 2.3.7 the VLR sent the SendIMSI message to the HLR in order to be able to police the sending of and Mobile Originated SM (MO-SM). 1. The VLR receives a petition where it needs to find out the subscriber IMSI based on its MSISDN. 2. The VLR constructs the MAP message SendIMSI with the following parameters at the SCCP level.

73

6 The Signaling Relay Node (SRN) in action

SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR43

CdPA

0

1

4

HLR

5. The HLR treats the SendIMSI44 message just the same way as if it would have come directly from the VLR. Finally it replies to the VLR with an Send IMSI acknowledgement (SendIMSI_ack) via the STP.

43

The CgPA of this message is left pointing at the VLR since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRN’s presence. 44 The SendIMSI message must only be replied to by the HLR if it is an imported or own MSISDN. This is because at least in Spain the legislation on automatic personal data treatment (Ley Orgánica 5/1992, de regulación del tratamiento automatizado de los datos de carácter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.

74

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

5.

4. 1.

3.

2. VLR

STP

SRN

Figure 6.14 A VLR interrogating the HLR for an IMSI based on an imported or own MSISDN.

6.15 SendIMSI Containing an Exported or Foreign MSISDN The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SendIMSI message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.15. 1. The VLR receives a petition where it needs to find out the subscriber IMSI based on its MSISDN. 2. The VLR constructs the MAP message SendIMSI with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR

CdPA

0

1

4

MSISDN

3. This message gets to the STP in which the following GTT is specified. TT

NP

NA

NS

Æ

New GT

0

1

4

MSISDN

Æ

SRN

4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP

75

6 The Signaling Relay Node (SRN) in action

message to. Since the MSISDN has been ported or is foreign the conceived NRN is not our own. The SRN forwards the SendIMSI message directly towards the external network in which the message will get to the correct HLR including the following SCCP parameters. SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR

CdPA

0

1

12645

CC+NRN+MSISDN46

... HLR 1

1.

2. UMSC/ VLR

HLR n

3. STP

SRN

4.

External Network

Figure 6.15 A VLR interrogating the HLR for an IMSI based on an exported or foreign MSISDN.

6.16 SendIMSI Containing an Imported or Own MSISDN Received in Interconnection The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also

45

The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field. 46 As explained earlier the SendIMSI message is forwarded with the CdPA parameter NS set to Country Code (CC) of the MSISDN concatenated with the NRN and the national part of the MSISDN.

76

6 The Signaling Relay Node (SRN) in action

subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for an SendIMSI message which contains a MSISDN that is imported or own which has been received in interconnection with an external network. The procedure is also illustrated in Figure 6.16. 1. An SendIMSI MAP message is received by the STP in interconnection. With the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR47

CdPA

0

1

12648

CC+NRN+MSISDN

2. In the STP the following GTT is specified. Æ

TT

NP

NA

NS

0

1

126

CC+NRN+MSISDN Æ

New GT SRN

3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards it’s corresponding HLR with the following parameters at the SCCP level. SCCP

TT

NP

NA

NS

CgPA

0

1

4

VLR

CdPA

0

1

4

HLR

4. The HLR treats the SendIMSI message just the same way as if it would have come directly from the VLR. Finally it replies to the VLR with an SendIMSI_ack via the STP.

47 This field containing the originating VLR is interesting since we could, not part of the scope of this document though, use it to set up a centralized policing in the SRN just by filtering messages on this field. 48 The NA is set to 126 to indicate that the MSISDN has been consulted and that the CC+NRN+MSISDN are all contained in the NS field.

77

6 The Signaling Relay Node (SRN) in action

... HLR 1

HLR n

4.

3. 2. STP

SRN

1.

External Network

Figure 6.16 VLR interrogating the HLR for an IMSI based on an imported or own MSISDN where the SendIMSI message is received in interconnection.

78

7 The SRN technical specification

7

The SRN technical specification

7.1

Proposed solution

The proposed solution is based on the following software and hardware modules, which would manage the subscriber database as well as other tables needed for the management and configuration of the application. •

•

•

•

A database module, with a suitable provisioning interface. An alarm system module. A Mobile Application Part (MAP) signaling module. A Message Transfer Part (MTP) and Signaling Connection Control Part (SCCP) signaling module/platform on top of which the Signaling Relay Node (SRN) node operates.

This chapter contains the proposed technical specification of the Mobile Number Portability / Flexible Allocation (MNP/FA) node which operates on top of these base modules. The solution does not take into account the replication of the application to provide a redundant solution. This whole chapter can be thought of as a template which has to be filled with adequate data for a network operator. Every time the data is missing it is replaced with the ‘*’ character. Appendix B gives an example where the data has been filled in for a fictitious network operator.

7.2

Non-functional requirements

[Req 1]

The SRN application will be developed on a MTP and SCCP capable platform running a suitable operating system.

[Req 2]

In the field, the SRN application will run on a MTP and SCCP capable platform running on a suitable operating system.

[Req 3]

The SUBSCRIBER table will allow at least * million entries as long as the rest of the tables are of negligible size in comparison. The database size is constrained by the * Gb memory available in the host machine.

[Req 4]

The bandwidth requirements for the SRN application at the peak transaction rate of the provisioning interface will be. •

[Req 5]

* kbps for each connection from a client to the server.

The SRN application will be able to handle a maximum of * messages of * byte length per second with * links loaded to full capacity and using 80% of the CPU load of the host machine.

79

7 The SRN technical specification

The following table summarizes, as a function of message type, the distribution of the message types in the operator network (may of course be different depending on network operator), the maximum transaction rate possible per link, the maximum transaction rate with * links loaded to full capacity, and the typical transaction rate with the links loaded to only 40% capacity. Message

Typ. Size

TPS with

TPS with * TPS at 40%

(bytes/bits)

1 link

links

Capacity

*%

*/*

*

*

*

GPRS UL50 *%

*/*

*

*

*

SRI51

*%

*/*

*

*

*

SRIfSM52

*%

*/*

*

*

*

ATI53

*%

*/*

*

*

*

SAI54

*%

*/*

*

*

*

SRIfLCS55

*%

*/*

*

*

*

SendIMSI

*%

*/*

*

*

*

Weighted Average

100%

*/*

*

*

*

UL49

Dist.

Assuming the SRN application receives messages with the distribution given in the table, the average message length would be * bytes.

7.3

Functional requirements

[Req 6]

The following list summarizes the different tables that will exist in the system and the maximum number of entries. Table

Depth

Description

49

Update Location General Packet Radio Service Update Location 51 Send Routing Info 52 Send Routing Info for Short Message 53 Any Time Interrogation 54 Send Authentication Info 55 Send Routing Info for Location 50

80

7 The SRN technical specification

SUBSCRIBER

*

Contains the Mobile Subscriber Integrated Services Digital Network number (MSISDN), International Mobile Subscriber Identity (IMSI), Home Location Register (HLR) and the associated network operator. Determines if an MSISDN or IMSI is an imported or own subscriber or not.

HLRLOCATION

*

Contains the possible HLRs and routing data associated.

NETWORK

*

Contains the possible Network Routing Numbers (NRN).

TCAPERRORCODES

200

Contains the association between MAP operation code and Error Code to be sent in case there is an error during MAP processing.

PARAMETERS

200

Contains configuration parameter names and their values.

FLAGS

200

Contains configuration parameters that are treated as Boolean.

MSISDNNORMALIZATION 128

Contains the data necessary to normalize an MSISDN.

81

7 The SRN technical specification

COMBINATION

128

Contains the data necessary to combine a NRN and an MSISDN.

MGTTRANSLATION

128

Contains the data necessary to translate an Mobile Global Title (MGT) to an IMSI.

LOCAL

50

Contains the hostnames of the SRN and particular parameters associated, like the Global Title (GT)

7.3.1 Service subscribers data 7.3.1.1

SUBSCRIBER table In the SUBSCRIBER table all the MSISDN ranges with their corresponding IMSI range would be inserted when they are assigned by the authority (in Spain the Comisión del Mercado de las Telecomunicaciones (CMT)). Every time an MSISDN is ported between two network operators in the MNP domain, a new entry would be necessary in this table.

[Req 7]

The subscriber profiles would be contained in the SUBSCRIBER table. SUBSCRIBER Field Name

Key/Attribute

Type

Description

MSISDN

Key

CHAR(20)

A subscriber MSISDN or range. If the MSISDN is a range, it should end with the ‘*’ character.

82

7 The SRN technical specification

IMSI

Alternate Key

CHAR(20)

The IMSI of the subscribers SIMcard. If the IMSI is a range, it should end with the ‘*’ character. If the MSISDN is exported or foreign this field should be set to the ‘*’ character.

HLRName

Attribute

CHAR(10)

The descriptive name of the HLR holding the subscriber. The HLR address information is stored in the HLRLOCATION table.

NetworkID

Attribute

CHAR(10)

The descriptive name of the subscription network operator. The entry has to exist in the NETWORK table.

[Req 8]

If the NetworkID value starts with a character other than alphanumeric, or it is an empty string, it shall be treated as not provisioned.

[Req 9]

If the HLRName value starts with a character other than alphanumeric, or it is an empty string, it shall be treated as not provisioned.

7.3.1.2

Database search procedure

[Req 10]

The database search procedure shall be applied to the normalized MSISDN or to the IMSI which has been translated from the incoming MGT, during MAP processing, section 7.4.2.

[Req 11]

An entry of the table when searching for MSISDNs shall be matched if. • •

The normalized MSISDN is equal to the entry’s MSISDN. The normalized MSISDN, truncated from the back end followed by ‘*’, is equal to the entry’s MSISDN. The entry with maximum MSISDN length shall be used, in case several lengths produce a match. The

83

7 The SRN technical specification

truncation lengths applied in the search shall range from the MSISDN length to 0. [Req 12]

If there is no matching MSISDN, the procedure shall return ‘MSISDN not found’, else [Req 15] to [Req 20] applies.

[Req 13]

An entry of the table when searching for IMSIs shall be matched if. •

•

The IMSI is equal to the entry’s IMSI. The IMSI, , truncated from the back end followed by ‘*’, is equal to the entry’s IMSI. The entry with maximum IMSI length shall be used, in case several lengths produce a match. The truncation lengths applied in the search shall range from the IMSI length to 1.

[Req 14]

If there is no matching IMSI, the procedure shall return ‘IMSI not found’, else [Req 15] to [Req 20] applies.

[Req 15]

If the HLRName field value of the entry starts with an alphanumeric character and matches an entry in the HLRLOCATION table, the procedure shall return ‘Own Subscriber’, plus the data associated to the matched HLR (if called from MAP processing).

[Req 16]

If the HLRName field value of the entry starts with an alphanumeric character but does not match an entry in the HLRLOCATION table, the procedure shall return ‘Provisioning Error’.

[Req 17]

If the HLRName field value of the entry does not start with an alphanumeric character, the NetworkID field value starts with an alphanumeric character and matches an entry in the NETWORK Table, the procedure shall return ‘Foreign Subscriber’, along with the data associated to the matched NetworkID (IMSI and NRN).

[Req 18]

If the HLRName field value of the entry does not start with an alphanumeric character, the NetworkID field value starts with an alphanumeric character and does not match an entry in the Networks Table, the procedure shall return ‘Provisioning Error’.

[Req 19]

If the HLRName field value does not start with an alphanumeric character and the NetworkID does not start with an alphanumeric, the procedure shall return ‘Provisioning Error’.

[Req 20]

If other error occurs that avoids the normalized MSISDN or IMSI to be searched in the database or one of the matched entry’s fields to be retrieved, the procedure shall return ‘Execution Error’.

7.3.2 Service configuration data [Req 21]

Service configuration data are configuration data related to the MNP/FA application that may affect the service logic behavior.

84

7 The SRN technical specification

[Req 22]

7.3.2.1

The Service configuration data will be able to be added, deleted, and modified in run-time without having to restart the application. Configuration parameter tables

[Req 23]

These tables will have two columns representing the key (name) and the value of the parameters

[Req 24]

The MNP/FA application will have the following configurable parameters held in the table of PARAMETERS. PARAMETERS Parameter

Description

Assumed Format

NPSValue56

Positive or zero The value to insert Integer into the numberPortabilitySt atus parameter (section 7.4.2.2)

DefaultDBMismatchError

Default error code to Positive or zero Integer be sent in case of database mismatch detection during MAP processing (section 7.4.2).

DefaultMSISDNNotFoundError Default error code to Positive or zero Integer be sent in case of MSISDN not found during MAP processing (section 7.4.2). DefaultIMSINotFoundError

[Req 25]

Default error code to Positive or zero Integer be sent in case of IMSI not found during MAP processing (section 7.4.2).

The MNP/FA application will have the following configurable parameters held in the table of FLAGS. FLAGS

56

The NPS parameter is currently not used between Spanish operators and it is an optional parameter according to [11] “Mobile Application Part (MAP) specification”, 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC),

85

7 The SRN technical specification

7.3.2.2 [Req 26]

Parameter name

Description

EnableNPS

A flag to indicate whether to enable or disable the inclusion of the numberPortabilityStatus parameter in the response to SRI (section 7.4.2.2).

HLRLOCATION table The GT and Point Code / SubSystem Number (PC/SSN) of the HLRs in the network shall be contained in the HLRLOCATION table. HLRLOCATION Field Name

Key/Attribute

Type

Description

Name

Key

CHAR(10)

A descriptive name of the HLR.

RouteOnGT

Attribute

CHAR(1)

A flag to indicate if routing must be performed on GT or not.

GlobalTitle

Attribute

CHAR(20)

The SCCP GT of the HLR.

PC

Attribute

SHORT INTEGER

The PC of the HLR.

[Req 27]

The RouteOnGT flag shall be interpreted as TRUE if its value is ‘1’, ‘t’, ‘T’, ‘y’ or ‘Y’, else it shall be treated as FALSE.

[Req 28]

If the GlobalTitle value starts with a non-numeric character, or is an empty string, it shall be treated as not provisioned.

[Req 29]

If the PC value is lower than 0 or greater than 16383, it shall be treated as not provisioned..

7.3.2.3 [Req 30]

NETWORK table The network ID’s and their routing numbers shall be contained in the NETWORK table. NETWORK Field Name

Key/Attribute

Type

Description

86

7 The SRN technical specification

[Req 31]

NetworkID

Key

CHAR(10)

The textual description of the network operator.

NRN

Alternate Key

CHAR(20)

The NRN of the operator.

UseNRN

Attribute

CHAR(1)

If this is FALSE, then the NRN shall be treated as if it was an empty string during the address combination procedure.

IMSI

Attribute

CHAR(20)

IMSI to be returned in the response to the SRI.

OwnNetwork

Attribute

CHAR(1)

Indicates if the NRN is own.

The OwnNetwork flag shall be interpreted as TRUE if its value is ‘1’, ‘t’, ‘T’, ‘y’ or ‘Y’, else it shall be interpreted as FALSE. The reason to introduce the OwnNetwork field is to accommodate to a possible scenario where the own network operator would have several NRNs, for example one for Global System for Mobile Communications (GSM) and other for Universal Mobile Telecommunication System (UMTS), or if NRNs of other operators should be treated in the same way as the own NRN.

[Req 32]

If the IMSI value starts with a non-numeric character, or is an empty string, it shall be treated as not provisioned.

[Req 33]

If the NRN value starts with a non-alphanumeric (non-hexadecimal) character, it shall be treated as an empty string. The UseNRN flag shall be interpreted as TRUE if its value is ‘1’, ‘t’, ‘T’, ‘y’ or ‘Y’, else it shall be interpreted as FALSE. If the UseNRN flag is FALSE, then the NRN shall be treated as an empty string in the address combination procedure, otherwise the value of the NRN will be used in the combination procedure.

7.3.2.4 [Req 34]

MSISDNNORMALIZATION table The table MSISDNNORMALIZATION shall be used in order to normalize the MSISDN.

87

7 The SRN technical specification

MSISDNNORMALIZATION Field Name

Key/Attribute

Type

Description

ISDNNoA

Key

INTEGER

The ISDN Nature of Address Indicator

DeleteAdd1

Attribute

CHAR(20)

A comma separated pair of prefixes to delete and add.

Attribute

CHAR(20)

A comma separated pair of prefixes to delete and add.

... DeleteAdd5

The table is indexed by the ISDN Nature Of Address indicator (NoA), that must be present with every MSISDN address in the MAP protocol. Each attribute is a list of comma separated pair of prefixes. 7.3.2.5

MSISDN normalization procedure An MSISDN is normalized by first obtaining the entry corresponding to its NoA. The list of prefix pair attributes is followed until the beginning of the Address is matched with the first prefix in the pair (delete prefix). The matched prefix is then deleted and the second prefix of the pair is added (add prefix). Both delete and add prefixes can be empty. If the delete prefix is empty, the pair represents the default behavior for an NoA (no match needs to be done). If there is no delete prefix match or default behavior, it will not be possible to normalize the MSISDN. The wildcard ‘R’ can be present in the delete prefix, meaning a match with any NRN configured in the NETWORK table. Here is an example. Suppose the following configuration. ISDNNoA

D/A1

D/A2

4 (International)

34R,34 0034R,34

D/A3 D/A4 D/A5 34,34 -

-

88

7 The SRN technical specification

3 (national)

R,34

0,34

,34

-

-

Now suppose that a valid NRN is 729999. •

• • • • • •

If the incoming MSISDN was (International) 34729999610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 34610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 0034610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 33610513304, it would not be possible to normalize the address. If the incoming MSISDN was (national) 729999610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (national) 0610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (national) 610513304, the resulting normalized address would be 34610513304.

Note that in the national case it is always possible to normalize the address because there is a default behavior. If an empty NRN is provisioned in the NETWORK table, then it shall not be considered for this normalization procedure. 7.3.2.6 [Req 35]

COMBINATION table The COMBINATION table shall be used to combine a NRN and an MSISDN. COMBINATION Field Name

Key/Attribute

Type

Description

ISDNNoA

Key

INTEGER

The ISDN NoA Indicator

ModifyNoA

Attribute

BOOLEAN

Specifies whether the NoA must be modified in case of successful combination.

89

7 The SRN technical specification

ModifiedNoA

Attribute

INTEGER

The output NoA (If ModifyNoA is TRUE)

DeleteAdd1

Attribute

CHAR(20)

A comma separated pair of prefixes to delete and add

Attribute

CHAR(20)

A comma separated pair of prefixes to delete and add

... DeleteAdd5

This table is used to combine the NRN and the MSISDN or Called Party Number (CdPN, input Address) in another address (output Address). The resulting output NoA may also be modified. The ISDN NoA of the input Address is used to index the table. Each attribute is a comma separated pair of prefixes. 7.3.2.7

Combination procedure The first step is to obtain the entry corresponding to the input address NoA. The list of prefix pairs is then followed until the beginning of the address is matched with the first prefix in the pair (delete prefix). The prefix is then deleted and the second prefix of the pair is added (add prefix). If the delete prefix is empty, the pair represents the default behavior for a NoA. The wildcard ‘R’ can be present in the add prefix, meaning that the NRN must be inserted at that position. Here is an example. Suppose the following configuration (ModifyNoA=TRUE, ModifiedNoA=4). ISDNNoA

D/A1

D/A2

D/A3

D/A4

D/A5

4 (International) 34,34R

-

-

-

-

3 (national)

,34R

-

-

-

-

0 (unknown)

0034,34R 34,34R ,34R

-

-

Now suppose that the NRN to insert is 729999.

90

7 The SRN technical specification

• • • • • •

If the incoming Address is (International) 34610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (International) 33610513304, it would not be possible to combine NRN and Address. If the incoming Address is (national) 729999610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 0034610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 34610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 610513304, the resulting combined address would be 34729999610513304.

If the NRN to insert is provisioned in the NETWORK table as an empty string, then it shall not be used in this combination procedure. In addition, the NRN shall be treated as an empty string for this combination procedure if the UseNRN flag is FALSE. 7.3.2.8 [Req 36]

MGTTRANSLATION table The table MGTTRANSLATION shall be used in order to translate the MGT into an IMSI. MGTTRANSLATION Field Name

Key/Attribute

Type

Description

MGT

Key

CHAR(20)

The MGT of the MGT-IMSI translation pair

IMSI

Attribute

CHAR(20)

The IMSI of the MGT-IMSI translation pair

This table is used to translate the incoming MGT (input Address) into the IMSI (output Address) which is used at key in the SUBSCRIBER table. The MGT of the input Address is used to index the table. The only attribute is the corresponding IMSI translation

91

7 The SRN technical specification

7.3.2.9

MGT-IMSI translation procedure The first step is to obtain the entry corresponding to the input address MGT. This entry is the one where the starting digits of the input address MGT match the MGT in the entry. If more that one entry matches in the above rule the longest MGT entry shall be considered as the matching one. If there is no matching MGT, it will not be possible to translate it. Once the entry corresponding to the input address is found the matching MGT entry digits are replaced by the matching IMSI digits in the input address MGT. In this way the output address IMSI is produced. Here is an example. Suppose the following configuration. MGT

IMSI

34607

21401

34622

21404

Now suppose that the MGT to translate is 346070000011111. The digits matching the MGT entry (34607) are removed and replaced by the digits of the matching IMSI entry (21401) 7.3.2.10 TCAPERRORCODES table [Req 37]

The TCAPERRORCODES table shall contain the error code to be sent for certain situations and for certain operation codes, during MAP processing. TCAPERRORCODES Field Name

Key/Attribute

Type

Description

OperationCode

Key

INTEGER

The operation code.

DBMismatchError

Attribute

INTEGER

The error to be sent when an inconsistency is detected between the network received MAP signaling and the database contents (MAP processing).

92

7 The SRN technical specification

NotFoundError

Attribute

INTEGER

The error to be sent if the MSISDN or IMSI is not found in the database (MAP processing).

The configuration parameters DefaultDBMismatchError and DefaultMSISDNNotFoundError would contain the error codes to be used in case an operation code is not defined. Example. OperationCode

DBMismatchError

NotFoundError

22 (Send Routing Info)

34 (SystemFailure)

1

45 (Send Routing Info for SM)

34 (SystemFailure)

1

58 (SendIMSI)

1 (UnknownSubscriber) 1

7.3.2.11 LOCAL table [Req 38]

The LOCAL table shall be used for defining the GT of each node. The nodes are identified by their hostnames. LOCAL

7.4

Field Name

Key/Attribute

Type

Description

HostName

Key

CHAR (20)

Hostname of the node

GlobalTitle

Attribute

CHAR(30)

Contains the GT of the node

Signaling

7.4.1 General [Req 39]

The SRN node shall be physically connected to the Signaling System number 7 (SS7) network with G.703 links.

[Req 40]

The SRN nodes shall be compliant with MTP and SCCP White Book International Telecommunication Union (ITU) Recommendations.

[Req 41]

The MNP/FA application shall be registered at the SCCP level of the SS7 stack.

[Req 42]

The MNP/FA application shall process Unit Data Message (UDT) and Extended Unit Data Message (XUDT) SCCP messages and discard others.

93

7 The SRN technical specification

[Req 43]

The processing applied to an input SCCP message shall be determined depending on the SSN carried in the SCCP Called Party Address (CdPA).

[Req 44]

Possible processing types will be referred to throughout the document as.

[Req 45]

•

MAP

The following configuration of SSNs is proposed. SSN

Processing

Comments

6

MAP

Globally standardized HLR SSN

146

CAMEL57

CAP SSN defined in 3GPP TS 23.003 (Release 5)

[Req 46]

The MTP level Destination Point Code (DPC) of all SCCP messages sent by the MNP/FA application (relayed or not) shall be the MTP level Originating Point Code (OPC) of the originating input message.

[Req 47]

The Calling Party Address (CgPA) of the outgoing SCCP message sent to the originator as a response (not relayed) to an incoming CAMEL Application Part (CAP) message will be copied from the CgPA received. The CgPA of the outgoing SCCP message sent to the originator as a response (not relayed) to an incoming MAP message, will be formatted according to the following table. Field

Content (binary)

Routing Indicator

0 (Route On Global Title)

Global Title Indicator

100 (TT, NP, ES, NA)

SSN Indicator

1 (SSN Present)

Point Code Indicator

0 (Point Code Not present)

SSN

SSN contained in the SCCP CgPA of the incoming message.

PC

Not Present

Translation Type

The translation type of response messages for MAP is 0x00.

57

Customized Applications for Mobile network Enhanced Logic (CAMEL) processing will not be necessary in the SRN node since we will only relay CAMEL messages (e.g. the ATI message). However we need to define the SSN to allow the host to receive these messages for relaying.

94

7 The SRN technical specification

Numbering Plan

Numbering Plan contained in the SCCP CgPA or 0001 (E.164) if it was not present.

Encoding Scheme

0001: odd number of global title digits 0002: even number of global title digits

Nature of Address Indicator

0000100 (International)

Global Title

Telephony Binary Coded Decimal (TBCD) representation of the GT configured for the own node.

[Req 48]

Messages relayed from the MNP/FA to other nodes shall be routed on [PC+SSN] or [GT], depending on the RouteOnGT field value of the HLRLOCATION table entries.

[Req 49]

If a relayed message must be routed on GT, the SCCP CdPA shall be formatted according to the following table. Field

Content (binary)

Routing Indicator

0 (Route On Global Title)

Global Title Indicator

100 (TT, NP, ES and NoA)

SSN Indicator

1 (SSN Present)

Point Code Indicator

0 (Point Code Not Present)

SSN

The SSN contained in the CdPN of the input message.

PC

Not Present

Translation Type

The translation type of relayed messages for MAP and CAP is 0x00.

Numbering Plan

Numbering Plan contained in the SCCP CdPA or 0001 (E.164) if it was not present.

Encoding Scheme

0001: odd number of global title digits 0002: even number of global title digits

95

7 The SRN technical specification

Nature Of Address Indicator

If the GT is obtained from an HLRLOCATION, it shall have value 0000100 (International). If the GT is the result of combining an MSISDN and a NRN, the value shall be determined by the Combination procedure (section 7.3.2.7).

Global Title [Req 50]

TBCD representation of the destination GT

If a relayed message must be routed on PC and SSN, the SCCP CdPA shall be formatted according to the following table. Field

Content (binary)

Routing Indicator

1 (Route On Point Code)

Global Title Indicator

000 (No Global Title)

SSN Indicator

1 (SSN Present)

Point Code Indicator

1 (Point Code Present)

SSN

The SSN contained in the CdPN of the input message.

PC

Destination Point Code

Translation Type

Not Present

Numbering Plan

Not Present

Encoding Scheme

Not Present

Nature Of Address Indicator

Not Present

Global Title

Not Present

7.4.2 MAP processing The requirements in this section must be observed in strict order; the previous requirements of the section might determine the conditions for the current one. The MAP processing is illustrated in Figure 7.1. [Req 51]

If the CdPA of the incoming SCCP message contains an MSISDN 7.4.2.1 to 7.4.2.5 apply. On the other hand if the CdPA contains an MGT 7.4.2.6 to 7.4.2.7 apply.

96

7 The SRN technical specification

7.4.2.1 [Req 52]

MSISDN processing The called MSISDN shall be the normalized SCCP CdPA. The MSISDN normalization procedure is explained in 7.3.2.5. Note that this procedure shall extract the NRN, if it is present.

[Req 53]

If the SCCP CdPA contains a NRN, but it does not belong to the own network (the OwnNetwork field associated to it in the Network table has value FALSE), the MNP/FA application shall continue processing as specified in 7.4.2.5, else it shall continue processing as in the next requirement.

[Req 54]

The normalized MSISDN shall be searched in the database, using the procedure described in 7.3.1.2.

[Req 55]

If the database search procedure returns ‘Own Subscriber’, the input message shall be relayed to the returned HLR location.

[Req 56]

Relayed messages shall be routed on GT or PC depending on the RouteOnGT field value defined for the HLR location.

[Req 57]

If the database search procedure returns ‘Foreign Subscriber’ and the input message is carrying a MAP SRI operation, the MNP/FA application shall continue processing as specified in 7.4.2.2, else it shall continue processing the message as in the next requirement.

[Req 58]

If the database search procedure returns ‘Foreign Subscriber’ and the input message is NOT carrying a MAP SRI operation, the MNP/FA application shall continue processing as specified in 7.4.2.3, else it shall continue processing the message as in the next requirement.

[Req 59]

If the database search procedure returns other value than ‘Own Subscriber’ or ‘Foreign Subscriber’, the MNP/FA application shall continue processing the message as specified in 7.4.2.4.

7.4.2.2

Foreign MSISDN SRI processing

[Req 60]

If a NRN was present in the SCCP CdPA GT, the application shall continue processing as in 7.4.2.5, else it shall continue processing as in the next requirement.

[Req 61]

The MNP/FA shall encode a TCAP End message with a TCAP Result-Last in the SCCP output message.

[Req 62]

The TCAP Result-Last shall carry the response to the SRI.

[Req 63]

The SRI Response shall always contain the MSRN and IMSI parameters.

[Req 64]

The IMSI shall be the one returned by the MSISDN search procedure.

97

7 The SRN technical specification

[Req 65]

The MSRN shall be the combination of the NRN returned by the search procedure and the normalized MSISDN. This address combination procedure is described in 7.3.2.7.

[Req 66]

If the EnableNPS flag is FALSE, the numberPortabilityStatus parameter shall not be present in the response.

[Req 67]

If the EnableNPS flag is TRUE, the numberPortabilityStatus parameter shall also be included in the response and shall have the value determined by the parameter NPSValue.

7.4.2.3

Foreign MSISDN non SRI processing

[Req 68]

If a NRN was present in the SCCP CdPA GT, the application shall continue processing as in 7.4.2.5, else it shall continue processing as in the next requirement.

[Req 69]

The input message shall be relayed to the Subscription Network by combining the NRN derived from the database and the normalized MSISDN in the GT of the SCCP CdPA The address combination procedure is described in 7.3.2.7.

[Req 70] 7.4.2.4

Relayed messages shall be routed on GT always. MSISDN not found

[Req 71]

The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message.

[Req 72]

The error code contained in the TCAP Error shall be determined from the service configuration data.

7.4.2.5

NRN – Database mismatch

[Req 73]

The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message.

[Req 74]

The error code contained in the TCAP Error shall be determined from the service configuration data.

7.4.2.6 [Req 75]

IMSI processing The called IMSI shall be the translated MGT contained in the SCCP CdPA of the incoming message. The MGT-IMSI translation procedure is explained in 7.3.2.9.

[Req 76]

The called IMSI shall be searched in the database, using the procedure described in 7.3.1.2.

98

7 The SRN technical specification

[Req 77]

If the database search procedure returns ‘Own Subscriber’, the input message shall be relayed to the returned HLR location.

[Req 78]

Relayed messages shall be routed on GT or PC depending on the RouteOnGT field value defined for the HLR location.

[Req 79]

If the database search procedure returns ‘Foreign Subscriber’, the SRN application shall continue processing the message as specified in 7.4.2.7, else it shall continue processing as specified in 7.4.2.7 also.

7.4.2.7

IMSI not found

[Req 80]

The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message.

[Req 81]

The error code contained in the TCAP Error shall be determined from the service configuration data.

99

7 The SRN technical specification

10.4.2 MAP

NO

MGT?

YES

10.3.2.5 NORMALIZE (MS ISDN)

YES

Nor malization possible?

10.3.2.9 TRANSLATE (MGT -> IMS I)

NO

YES

Translation possible?

NO

SEND ERROR

SEND ERROR

10.3.1.2 DB S EARCH (MS ISDN)

OWN

HLR RELAY

NO

MS ISDN type?

FOREIGN

NRN present?

10.3.1.2 DB S EARCH (IMS I)

OTHER 10.4.2.4 SEND ERROR

OWN

HLR RELAY

IMS I type?

FOREIGN OTHER 10.4.2.7 SEND ERROR

YES 10.4.2.5 SEND ERROR

YES 10.4.2.2 SRI RESPONS E

SRI message?

NO 10.4.2.3 RELAY TO OTHER NET

Figure 7.1 Visual MAP processing description.

100

7 The SRN technical specification

7.5

Statistics

7.5.1 Counters 7.5.1.1 [Req 82]

SS7 stack counters The SS7 counters provided for each signaling link shall be •

•

•

•

•

•

•

• 7.5.1.2 [Req 83]

Number of octets transmitted Number of octets received Number of seconds of link availability Number of seconds of link unavailability Number of seconds of link in error Number of seconds of link congestion

The operating system counters provided shall be. •

•

[Req 84]

Number of MSU received

Operating system counters

•

7.5.1.3

Number of Message Signal Units (MSU) sent

CPU Idle Time Unused memory Disk Free Space

Service logic counters The service logic counters provided shall be: •

•

•

•

•

•

•

SCCP UDT Messages received MAP Messages received UL Messages received GPRS UL Messages received SRI Messages received SRIfSM Messages received SAI Messages received

101

7 The SRN technical specification

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

ATI Messages received SRIfLCS Messages received Other MAP messages received MAP Messages Discarded: decode error MAP Messages Discarded: DB error MAP Messages Discarded: other error SRI Messages for Own subscriber SRI Messages for Foreign subscriber SRIfSM Messages for Own subscriber SRIfSM Messages for Foreign subscriber ATI Messages for Own subscriber ATI Messages for Foreign subscriber SRIfLCS for Own subscriber SRIfLCS for Foreign subscriber SendIMSI for Own subscriber SendIMSI for Foreign subscriber Other MAP Messages for Own subscriber Other MAP Messages for Foreign subscriber MAP Messages with MSISDN not found MAP Messages with DB mismatch detected MAP Messages with IMSI not found MAP Messages sent out MAP Messages send failure SCCP UDT Messages sent out SCCP UDT Messages send failure

102

7 The SRN technical specification

7.6

Alarms

[Req 85]

The MNP/FA shall raise alarms.

[Req 86]

The alarms raised will be forwarded to the alarm module mentioned in 7.1 which in turn shall interface with the network operators alarm system.

7.6.1 MNP/FA application alarms [Req 87]

The alarms raised by the MNP/FA application will at least be the following. •

• • • • •

•

•

Unable to send SS7 message towards a point code Threshold alarms, including high or low number of messages received MNP database inconsistency detected. A NRN is received while the MSISDN is Foreign Inbound Message Discarded. The application log would describe the reason for discard (for example, unable to extract information from an SRI). HLR not provisioned. The HLR configured for the MSISDN or IMSI does not exist MSISDN not found in database. IMSI not found in database. Received signaling related to an exported subscriber, while the EnableMNP flag is FALSE.

7.6.2 SRN node alarms [Req 88]

The alarms raised by the SRN node are very dependent on the platform on top of which the node is implemented. The alarms below are merely categories of the necessary alarms. •

•

•

7.7

MNP/FA application not available Alarms related to signaling links, route sets, etc. Hardware alarms

Provisioning system

[Req 89]

The MNP/FA server shall provide two provisioning interfaces. •

Read/Write interfaces

103

7 The SRN technical specification

• [Req 90]

The operations that provisioning clients will be able to perform on a read/write interface will be. •

• • •

•

[Req 91]

Read only interfaces

Create - Provision a new entry. This operation must take all of the fields in as parameters, and should raise an exception to indicate failure of the operation. Delete - Remove an entry. This operation needs only the key of table/interface as a parameter, and should raise an exception to indicate failure of the operation. Modify - Modify an entry. This operation must take all of the fields in the as parameters, and should raise an exception to indicate failure of the operation. ModifyKey – This operation will modify the key of an entry. It takes as parameters the old key (as registered into the database) and the new key, and should raise an exception to indicate failure of the operation. Search - Look up (verify) an entry. This operation needs only the key as a parameter, and should return the values of all of the fields of the entry or raise an exception to indicate failure of the operation.

The operations that provisioning clients will be able to perform on a read only interface will be. •

Search - Look up (verify) an entry. This operation needs only the key as a parameter, and should return the values of all of the fields of the entry or raise an exception to indicate failure of the operation.

[Req 92]

In case of error during an operation, an exception shall be raised. The operation error exception will contain a detailed error message that will include the error code and a textual description.

[Req 93]

The error code will contain a value from the constants defined in the provisioning interface.

[Req 94]

The error message string will contain a detailed description about the error that occurred (that, at least, includes the name of platform in which the fault has occurred). The constant ‘ERROR’ will be used if there is no appropriately defined constant error value.

7.7.1 Provisioning system log The logging system will typically be used for extracting statistics. [Req 95]

The provisioning system shall write a log.

104

7 The SRN technical specification

[Req 96]

[Req 97]

The following events in the provisioning system shall be logged. •

All operations which result in a database modification.

Each logged event shall contain the following information. •

•

•

•

Date and time Affected database(s) Operation Complete database entry before and after modification

[Req 98]

The logged events shall be written to disk immediately.

[Req 99]

The log shall have a fixed size of * MB.

[Req 100] Once the log is full the “round robin” principle is used to overwrite old logged events.

7.7.2 Provisioning interface performance issues [Req 101] The guaranteed performance of the server is summarized in the following table. Item

Value

Average Response Time per Operation

200 ms

Peak Transaction Rate

*operation/hour

[Req 102] These performance characteristics shall be confirmed in controlled conditions in the test-bed, using a LAN with sufficient bandwidth to perform the test. [Req 103] An operation as used here includes a call to either a Create, Delete, Modify, or Search operations of the provision interface. The ModifyKey method counts as two operations due to the fact that it requires both Create (new entry) and Delete (old entry) operations. [Req 104] The transaction rate may be limited by the quality of the Transport Control Protocol / Internet Protocol (TCP/IP) network. The performance is guaranteed for the field machine only if the bandwidth requirement of [Req 4]is available.

105

8 Conclusions and future work

8

Conclusions and Future Work

8.1

Conclusions

Almost all decisions taken in this research had to do with the design of the node interior. The design which is finally presented in Chapter 7 “The SRN technical specification” is, as I see it, a thoroughly studied set of requirements, procedures and tables describing the functionality node. Of course, as in any design case, there are alternatives which may suit a real implementation better because of local circumstances which cannot be foreseen. I consider the presented solution a good starting point for anyone who would like to implement the Mobile Number Portability / Flexible Allocation (MNP/FA) functionality. Database design are always tough decisions to make since everything very quickly starts to depend on them. One of the most studied ones was whether the ranges of International Mobile Subscriber Identities (IMSI) and Mobile Station Integrated Services Digital Network numbers (MSISDN) should go in the same table as ported numbers or if they should be separated into their own table. The final decision on the matter, as we have seen, was that they should go together in the same table because of two reasons. 1. Ranges are inserted very sporadically into the SUBSCRIBER table. When, for the first time, the node is taken into production it will be configured with the known MNP domain ranges and thereafter all ported numbers (if any). The only time thereafter when ranges will be inserted is when the local MNP authority assigns new number ranges. This is for most countries a quite rare event. 2. The main work of the Signaling Relay Node (SRN) node is to look up entries in its SUBSCRIBER table. The additional entries that the ranges result in are insignificant compared to all the ported numbers. By adding the ranges to the same table as the ported numbers we should win some processing time on each search since we only need to search in a single table. As pointed out in footnotes 32, 38 and 44 the reply from the Home Location Register (HLR) to some Mobile Application Part (MAP) messages for which the SRN node supports relay may be unlawful if not consented by the subscriber. The unlawfulness of such a relay depends on the legislation on automatic data treatment in the network operator’s home country. The problem is basically that most countries do not allow personal data to be shared with third parties without the subscribers previous consent. This would be the case if the HLR replied to for example a Send Routing Info for Location (SRIfLCS) message received in interconnection and thereby causing the sharing of personal information (the subscribers position) with a third party (the interconnecting network operator). To prevent this situation to appear altogether we could filter these messages directly in the SRN node but with the negative effect that we would not be able to support certain cross operator services (e.g. cross operator positioning). A better solution would be to introduce a filtering function in the SRN node that would provide a per subscriber allow/deny relay decision.

106

8 Conclusions and future work

8.2

Future Work

The SRN node could be extended with additional features. For example an filtering feature based on source address (usually called “policing”) could easily be added and is mentioned in footnotes 29, 35, 41, and 47. Such a feature could for example provide a way for the network operator to choose from which sources (network operators) Short Messages (SM) would be allowed. This policing feature would preferably base itself on another table in the database containing the fields •

•

Allowed source SubSystem Number (SSN)

which would contain all source nodes allowed to address a certain SSN. Another feature already commented under Conclusions is the one where the SRN node filters certain relay decision based on whether or not the subscriber previously has consented this action. This feature would also typically be based on another table in the database which would include all subscriber MSISDNs allowing a certain cross operator feature. For example •

•

MSISDN Allowed MAP message to relay when received in interconnection

would be a good choice of fields in this table. This feature would allow the network operator to control that no cross operator services will take place without the subscribers previous consent. For example lets take a look at the situation in Figure 2.19 where the SRN would see to it that message number 2 never would get to the HLR and therefore cutting the chain which would result in an unlawful event. A network operator willing to implement the presented SRN node would of course have to start out by defining its own production environment. Once all implicated systems (provisioning, alarms, etc.) are known the design would have to be further specified to fit the requirements of these new circumstances. When implementing the SRN node it may be necessary to add support for proprietary messages, e.g. the Retrieve message in the Ericsson proprietary protocol CS1+. Also when implementing the provisioning system I think it would be advisable to implement an IP based interface to prepare the node for an all Internet Protocol (IP) environment.

107

9 Definitions, abbreviations and symbols

9 9.1

Definitions, abbreviations and symbols Definitions

Consulted Number: An MSISDN already consulted in any network operators MNP database. Direct Routing: A network operators number portability database contains all the ported numbers in the MNP domain. Then it is possible for the originating network to directly route a call (and other signaling affected by MNP) towards the recipient network. to avoid routing the messages through the number range owner network. Donor Network The holder of the number range to which a ported number belongs. Foreign Number: An MSISDN which is contained within a number range owned by another network operator in the MNP domain which has not been ported. Global Title: A form of SCCP addressing in the signaling network. The GT is composed of Translation Type and Address Digits. The GT is an address, defined in the ITU recommendations Q.711 to Q.716, which uniquely identifies a node or an application running on a node. Indirect Routing: A network operators number portability database contains only the exported numbers from the number ranges which the network operator owns in the MNP domain. Then the originating network has to route a call (and other signaling affected by MNP) towards the number range owner network which in turn will know if the MSISDN is a (ex)ported number. International Mobile Subscriber Identity: The IMSI uniquely identifies a GSM subscription (a SIM). It is composed of MCC, MNC and MSIN and is specified in the E.212 numbering plan. Mobile Number Portability Domain: All the number ranges which have been assigned to network operators which may export and import numbers between each other. Network Operator: A GSM/UMTS PLMN operator Network Routing Number: This number is concatenated with the MSISDN and conveyed in the ISUP parameter called party number and the SCCP parameter Called Party Address. The number is used to force a ported call into the recipient network for call processing treatment or to force MAP signaling for at ported number into the recipient network for further treatment. Number Range: A range of MSISDNs assigned to a service provider. In Spain the authority that assigns the number ranges is the “Comisión del Mercado de las Telecomunicaciones” (CMT). Number Range Owner Network: The network to which the number range containing the ported number has been assigned.

108

9 Definitions, abbreviations and symbols

Originating Network: The network where the calling party is located. Ported Call: A call to a ported number. Ported Number: An MSISDN that was initially served by a service provider, that now is served by another service provider while still is being used by the same subscriber and the number range is still assigned to the initial service provider. Recipient Network: The network that receives the ported number and serves it. Subscriber: User of a mobile phone responsible for payment of the subscription account.

9.2

Abbreviations

For the purposes of the present document, the following abbreviations apply. AE: Application Entities ASE: Application Service Elements ATI: Any Time Interrogation AuC: Authentication Center BSC: Base Station Controller BSS: Base Station Subsystem BTS: Base Transceiver Station CAMEL: Customized Applications for Mobile network Enhanced Logic CAP: CAMEL Application Part CC: Country Code CdPA: Called Party Address CgPA: Calling Party Address CMT: “Comisión del Mercado de las Telecomunicaciones” DPC: Destination Point Code FA: Flexible Allocation GGSN: Gateway GPRS Support Node GMLC: Gateway Mobile Location Center GPRS: General Packet Radio Service GPRS UL: GPRS Update Location

109

9 Definitions, abbreviations and symbols

GSM: Global System for Mobile communication GT: Global Title GTT: Global Title Translation HLR: Home Location Register HTTP: Hyper Text Transfer Protocol IAM: Initial Address Message IMEI: International Mobile Equipment Identity IMSI: International Mobile Subscriber Identity IN: Intelligent Network IP: Internet Protocol ISDN: Integrated Services Digital Network ISUP: ISDN User Part ITU: International Telecommunication Union IWMSC: InterWorking Mobile service Switching Center LA: Location Area LU: Location Updating MAP: Mobile Application Part MCC: Mobile Country Code ME: Mobile Equipment MGT: Mobile Global Title MNC: Mobile Network Code MNP: Mobile Number Portability MO-SM: Mobile Originated Short Message MS: Mobile Station MSC: Mobile service Switching Center MSIN: Mobile Subscriber Identity Number MSISDN: Mobile Station ISDN number

110

9 Definitions, abbreviations and symbols

MSRN: Mobile Station Roaming Number MSU: Message Signal Unit MT-SM: Mobile Terminating Short Message MTP: Message Transfer Part NA: Nature of Address (SCCP) NMT: Nordic Mobile Telephone NoA: Nature Of Address (ISUP) NP: Numbering Plan NRN: Network Routing Number NSS: Network and Switching Subsystem OPC: Originating Point Code PC: Point Code PLMN: Public Land Mobile Network PSTN: Public Switched Telephony Network RA: Routing Area RNC: Radio Network Controller RNS: Radio Network Subsystem SA: Service Area SAI: Send Authentication Info SCP: Service Control Point SCCP: Signaling Connection Control Part SendIMSI_ack: SendIMSI acknowledgement SGSN: Service GPRS Support Node SIM: Subscriber Identity Module SM: Short Message SMSC: Short Message Service Center SRI: Send Routing Info

111

9 Definitions, abbreviations and symbols

SRI_ack: Send Routing Info acknowledgement SRIfLCS: Send Routing Info for Location SRIfLCS_ack: Send Routing Info for Location acknowledgement SRIfSM: Send Routing Info for Short Message SRIfSM_ack: Send Routing Info for Short Message acknowledgement SRN: Signaling Relay Node SS7: Signaling System number 7 SSN: SubSystem Number STP: Signaling Transfer Point TBCD: Telephony Binary Coded Decimal TCAP: Transaction Capabilities Application Part TCP: Transport Control Protocol TT: Translation Type UDT: Unit Data Message UL: Update Location UMSC: UMTS Mobile service Switching Center UMTS: Universal Mobile Telecommunications System VLR: Visitor Location Register XUDT: Extended Unit Data Message

9.3

Symbols

The following symbols and their meanings apply for the entire document.

Node B

Radio Network Controller (RNC)

112

9 Definitions, abbreviations and symbols

UMTS Mobile service Switching Center (UMSC) and Visitor Location Register (VLR)

Home Location Register (HLR) and Authentication Center (AuC)

Signaling Transfer Point (STP)

Service GPRS Support Node (SGSN)

Gateway GPRS Support Node (GGSN)

Short Message Service Center (SMSC)

Service Control Point (SCP)

Gateway Mobile Location Center (GMLC)

Mobile Station (MS)

113

9 Definitions, abbreviations and symbols

Radio link, both voice and signaling traffic

Voice traffic link

Signaling traffic link

External Network

Internal or External Application

114

10 References

10 References [1]

MOULY, Michel and PAUTET, Marie-Bernadette, “The GSM System for Mobile Communications, A comprehensive overview of the European Digital Cellular Systems”, 1992, ISBN 2-9507190-0-7

[2]

“GPRS System Survey”, 1999, Ericsson Radio Systems AB, Internal reference: 038 02-108 876 Rev B

[3]

“UMTS System Description”, 2000, Nortel Networks, Internal reference: UMT/TRD/CN/0003 01.03/EN

[4]

“Number Portability For GSM- To GSM Networks In FNR”, 2001, Ericsson, Internal reference: 4/155 17-ANT 307 01/7 Uen B

[5]

“GSM MSC/VLR Operation, Student Text”, 1998, Ericsson Radio Systems AB, Internal reference: EN/LZT 123 3976 R6A

[6]

“Especificación Técnica de la Solución de Red para la Conservación de Numeración en la Redes Telefónicas Públicas Móviles, Versión 1.0”, 2000, Comisión del Mercado de las Telecomunicaciones (CMT) http://www.cmt.es/cmt/document/decisiones/2000/RE-00-06-08-08.pdf

[7]

“Mobile Number Portability”, 2000, Network Interoperability Consultative Committee, Internal reference: ND1208:2000/03

[8]

“Especificación técnica de portabilidad de móvil”, 2000, Airtel Móvil S.A., Internal reference: IC0/ES/023-00

[9]

“UMTS02” Packet Core Validation Detailed Test Plan for VODAFONE (Part 1), 2002, Nortel Networks

[10]

“Introducción al Sistema de Señalización Nº 7”, 2000, Vodafone, Internal Vodafone course material, Teacher: RODRÍGUEZ, Carlos

[11]

“Mobile Application Part (MAP) specification”, 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC), Internal reference: 3GPP TS 29.002

[12]

“CCS#7 Network Survey”, 1997, Siemens, Siemens training course material, Teacher: Siemens Training Service

[13]

“Códigos de operador de portabilidad”, Updated: 27-01-2004, CMT http://www.cmt.es/cmt/centro_info/numeracion/content.html

[14]

SORIA LUQUE, Nicolás, “Proyecto ‘Una sola SIM’ – Flexible Allocation, Análisis de soluciones”, 2003, Vodafone, Internal reference: IC0/IN/008-03

[15]

BALLESTEROS HERRAIZ, Beatriz, PAZOS SOUTO, Begoña and VAZQUEZ GONZALEZ, Ángel, “Configuración de portabilidad móvil en nodos de red, Versión 1”, 2000, Airtel, Internal reference: IC0/NT/004-00

115

10 References

[16]

GSMworld IR21 database, https://infocentre.gsm.org/ (requires membership login)

[17]

“Feature Description SCP R9.1”, 2001, Ericsson, Ericsson training course material, Teacher: Ericsson Spain Training Service

[18]

ALMENAR BELENGUER, Pedro, “Descripción de CAMEL fase 2, Versión 1”, 2000, Airtel, Internal reference: ID0/IN/003-00

[19]

“GAS FS/Ses SURVEY GSM900/1800(R9.1) & UMTS(CN2.0)V-State”, Chapter: “Handling of Mobile Positioning in HLR”, 2001, Ericsson, Internal reference: EN/LZN 716 0011 R1B

[20]

Chris Dulya, “Service Relay Node and Mobile Number Portability, System Requirements Specification”, 2003, Sema Group sae, Internal reference: OPI.MNP.SRS.v3.5

116

Appendix A

Appendix A Update Location (UL) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |11:07:05,404,816 1:A (Rx):16 MAP BEG Update Location | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1000111 |Backward Sequence Number |71 | |1------- |Backward Indicator Bit |1 | |-0010100 |Forward Sequence Number |20 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |3009 | |**b14*** |Originating Point Code |3001 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0111---- |Signalling Link Selection |7 | |00001001 |SCCP Message Type |9 | |----0001 |Protocol Class |Class 1 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00010000 |Pointer to parameter |16 | |00011011 |Pointer to parameter |27 | |Called address parameter | |00001101 |Parameter Length |13 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-1------ |Routing Indicator |Route on DPC + Subsystem No. | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0111---- |Numbering Plan |ISDN/Mobile (Rec. E.214) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b60*** |Called Address Signals |346700000000012 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000111 |Subsystem number |VLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002953 | |0000---- |Filler |0 | |Data parameter | |01010111 |Parameter length |87 | |**B87*** |Data |62 55 48 03 ab 00 ff 6b 1e 28 1c ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) | |Begin | |01100010 |Tag |(APPL C [2]) | |01010101 |Length |85 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) | |00000011 |Length |3 | |***B3*** |Orig Trans ID |11206911 | |2 DialoguePortion | |01101011 |Tag |(APPL C [11]) | |00011110 |Length |30 | |2.1 DialogueExternal | |00101000 |Tag |(UNIV C External) | |00011100 |Length |28 | |2.1.1 DialogueObjectID | |00000110 |Tag |(UNIV P Obj Identifier) | |00000111 |Length |7 | |00000000 |Authority |CCITT Recommendation | |00010001 |Name Form |q | |10000110 |Rec Number |7 | |00000101 |Rec Number |73 | |00000001 |AS |1 | |00000001 |Dialog-AS |Dialogue PDU | |00000001 |Version |1 | |2.1.2 DialoguesingleASN1 | |10100000 |Tag |(CONT C [0]) | |00010001 |Length |17 | |2.1.2.1 DialogueRequest | |01100000 |Tag |(APPL C [0]) | |00001111 |Length |15 | |2.1.2.1.1 Protocol Version |

117

Appendix A

|10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000001 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Invoke |10100001 |Tag |00101010 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00000010 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00100010 |Length |3.1.3.1 IMSI |00000100 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.3.2 Network Node Number |10000001 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |Network Node Number |1111---- |Filler |3.1.3.3 VLR Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |VLR Address Signals |1111---- |Filler |3.1.3.4 VLR Capability |10100110 |Tag |00000100 |Length |3.1.3.4.1 Supported Camel Phases |10000000 |Tag |00000010 |Length |00000110 |UnusedBits |1------- |Phase1 |-0------ |Phase2 |--000000 |Filler |***B2*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |c7|94|3f|c3|c1|4b|ee|72|09|81|03|10|1b|0d|52|06| |10 |00|71|04|43|76|00|00|00|00|10|02|0b|12|07|00|11| |20 |04|43|06|07|20|59|03|57|62|55|48|03|ab|00|ff|6b| |30 |1e|28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f| |40 |80|02|07|80|a1|09|06|07|04|00|00|01|00|01|03|6c| |50 |80|a1|2a|02|01|01|02|01|02|30|22|04|08|12|04|01| |60 |00|00|00|10|f2|81|07|91|43|06|07|20|59|f3|04|07| |70 |91|43|06|07|20|59|f3|a6|04|80|02|06|80|00|00| |

|(CONT P [0]) |2 |7 |Yes |0 |(CONT C [1]) |9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Network Loc Upd |Version3 |(APPL C [12]) |EOC-encoded |(CONT C [1]) |42 |(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Update Location |(UNIV C Sequence (of)) |34 |(UNIV P OctetString) |8 |214010000000012 |15 |(CONT P [1]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002953 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002953 |15 |(CONT C [6]) |4 |(CONT P [0]) |2 |6 |Yes |No |0 |EOC

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

GPRS Update Location (GPRS UL) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |14:01:51,989,729 1:B (Tx):4 MSU UDT BEG Update GPRS Location 151 3007 7424 | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-0011011 |Backward Sequence Number |27 | |1------- |Backward Indicator Bit |1 | |-0010100 |Forward Sequence Number |20 | |0------- |Forward Indicator Bit |0 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |151 |

118

Appendix A

|**b14*** |Originating Point Code |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) |Unitdata |0110---- |Signalling Link Selection |00001001 |SCCP Message Type |----0000 |Protocol Class |0000---- |Message Handling |00000011 |Pointer to parameter |00010000 |Pointer to parameter |00011011 |Pointer to parameter |Called address parameter |00001101 |Parameter Length |-------0 |Point Code Indicator |------1- |Subsystem No. Indicator |--0100-- |Global Title Indicator |-0------ |Routing Indicator |0------- |For national use |00000110 |Subsystem number |00000000 |Translation Type |----0001 |Encoding Scheme |0111---- |Numbering Plan |-0000100 |Nat. of Address Indicator |0------- |Spare |**b60*** |Called Address Signals |0000---- |Filler |Calling address parameter |00001011 |Parameter Length |-------0 |Point Code Indicator |------1- |Subsystem No. Indicator |--0100-- |Global Title Indicator |-0------ |Routing Indicator |0------- |For national use |10010101 |Subsystem number |00000000 |Translation Type |----0001 |Encoding Scheme |0001---- |Numbering Plan |-0000100 |Nat. of Address Indicator |0------- |Spare |**b44*** |Calling Address Signals |0000---- |Filler |Data parameter |01001100 |Parameter length |**B76*** |Data |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) |Begin |01100010 |Tag |01001010 |Length |1 Origination Transaction ID |01001000 |Tag |00000010 |Length |***B2*** |Orig Trans ID |2 DialoguePortion |01101011 |Tag |00011110 |Length |2.1 DialogueExternal |00101000 |Tag |00011100 |Length |2.1.1 DialogueObjectID |00000110 |Tag |00000111 |Length |00000000 |Authority |00010001 |Name Form |10000110 |Rec Number |00000101 |Rec Number |00000001 |AS |00000001 |Dialog-AS |00000001 |Version |2.1.2 DialoguesingleASN1 |10100000 |Tag |00010001 |Length |2.1.2.1 DialogueRequest |01100000 |Tag |00001111 |Length |2.1.2.1.1 Protocol Version |10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00100000 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |00100100 |Length |3.1 Invoke |10100001 |Tag |00100010 |Length |3.1.1 Invoke ID

|3007

| | | |6 | |9 | |Class 0 | |No special options | |3 | |16 | |27 | | |13 | |PC absent | |SSN present | |Has transln,n-plan,code,natur | |Route on Global Title | |0 | |HLR | |Not used | |BCD, odd number of digits | |ISDN/Mobile (Rec. E.214) | |International number | |0 | |346070000000036 | |0 | | |11 | |PC absent | |SSN present | |Has transln,n-plan,code,natur | |Route on Global Title | |0 | |SGSN | |Not used | |BCD, odd number of digits | |ISDN/Telephony (E.164/E.163) | |International number | |0 | |34607002966 | |0 | | |76 | |62 4a 48 02 1d 00 6b 1e 28 1c 06 ...| | | |(APPL C [2]) | |74 | | |(APPL P [8]) | |2 | |7424 | | |(APPL C [11]) | |30 | | |(UNIV C External) | |28 | | |(UNIV P Obj Identifier) | |7 | |CCITT Recommendation | |q | |7 | |73 | |1 | |Dialogue PDU | |1 | | |(CONT C [0]) | |17 | | |(APPL C [0]) | |15 | | |(CONT P [0]) | |2 | |7 | |Yes | |0 | | |(CONT C [1]) | |9 | | |(UNIV P Obj Identifier) | |7 | |CCITT | |Identified-organization | |ETSI | |Mobile Domain | |GSM-Network | |AC-ID | |GPRS Location Update | |Version3 | | |(APPL C [12]) | |36 | | |(CONT C [1]) | |34 | |

119

Appendix A

|00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00010111 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00011010 |Length |3.1.3.1 IMSI |00000100 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.3.2 SGSN Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |SGSN Number |1111---- |Filler |3.1.3.3 SGSN Address |00000100 |Tag |00000101 |Length |00------ |Address Type |--000100 |Address Length |***B4*** |SGSN Address

|(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Update GPRS Location |(UNIV C Sequence (of)) |26 |(UNIV P OctetString) |8 |214010000000036 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002966 |15 |(UNIV P OctetString) |5 |IPv4 Address |4 |ac 14 33 02

| | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Send Routing Info (SRI) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |13:13:20,457,564 1:B (Rx):3 MTP-L2 MSU SCCP UDT MAP BEG | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1101101 |Backward Sequence Number |109 | |1------- |Backward Indicator Bit |1 | |-0101001 |Forward Sequence Number |41 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |151 | |**b14*** |Originating Point Code |3000 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0101---- |Signalling Link Selection |5 | |00001001 |SCCP Message Type |9 | |----0001 |Protocol Class |Class 1 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00001110 |Pointer to parameter |14 | |00011001 |Pointer to parameter |25 | |Called address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Called Address Signals |34607000014 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00001000 |Subsystem number |MSC | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002950 | |0000---- |Filler |0 | |Data parameter | |10001011 |Parameter length |139 | |**B139** |Data |62 81 88 48 03 e9 00 0a 6b 1e 28 ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) | |--> DECODING ERROR: IE not allowed (at position 26 hex) | |Begin | |01100010 |Tag |(APPL C [2]) | |***B2*** |Length |136 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) |

120

Appendix A

|00000011 |Length |***B3*** |Orig Trans ID |2 DialoguePortion |01101011 |Tag |00011110 |Length |2.1 DialogueExternal |00101000 |Tag |00011100 |Length |2.1.1 DialogueObjectID |00000110 |Tag |00000111 |Length |00000000 |Authority |00010001 |Name Form |10000110 |Rec Number |00000101 |Rec Number |00000001 |AS |00000001 |Dialog-AS |00000001 |Version |2.1.2 DialoguesingleASN1 |10100000 |Tag |00010001 |Length |2.1.2.1 DialogueRequest |01100000 |Tag |00001111 |Length |2.1.2.1.1 Protocol Version |10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000101 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Invoke |10100001 |Tag |01011101 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00010110 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |01010101 |Length |3.1.3.1 MS Isdn Address Number |10000000 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |MS ISDN Address Signals |1111---- |Filler |3.1.3.2 Interrogation Type |10000011 |Tag |00000001 |Length |00000000 |Interrogation Type |3.1.3.3 Gmsc Address |10000110 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |GMSC Address Signals |1111---- |Filler |3.1.3.4 Call Reference Number |10000111 |Tag |00000101 |Length |***B5*** |Call Reference Number |3.1.3.5 Network Signal Info |10101010 |Tag |00001010 |Length |3.1.3.5.1 Protocol Id |00001010 |Tag |00000001 |Length |00000100 |Protocol Id |3.1.3.5.2 Signal Info |00000100 |Tag |00000101 |Length |***B5*** |Signal Info |3.1.3.6 Camel Info |10101011 |Tag |00000100 |Length |3.1.3.6.1 Supported Camel Phases

|3 |15269898 |(APPL C [11]) |30 |(UNIV C External) |28 |(UNIV P Obj Identifier) |7 |CCITT Recommendation |q |7 |73 |1 |Dialogue PDU |1 |(CONT C [0]) |17 |(APPL C [0]) |15 |(CONT P [0]) |2 |7 |Yes |0 |(CONT C [1]) |9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Loc Info Retrieval |Version3 |(APPL C [12]) |EOC-encoded |(CONT C [1]) |93 |(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Send Routing Info |(UNIV C Sequence (of)) |85 |(CONT P [0]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607000014 |15 |(CONT P [3]) |1 |Basic call |(CONT P [6]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002950 |15 |(CONT P [7]) |5 |00 02 01 00 01 |(CONT C [10]) |10 |(UNIV P Enumerated) |1 |Ets-300102-1 |(UNIV P OctetString) |5 |04 03 80 90 a3 |(CONT C [11]) |4

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

121

Appendix A

|00000011 |Tag |00000010 |Length |00000110 |UnusedBits |1------- |Phase1 |-1------ |Phase2 |--000000 |Filler |3.1.3.7 Extension Container |10101101 |Tag |00100101 |Length |3.1.3.7.1 Private Extension List |10100000 |Tag |00100011 |Length |3.1.3.7.1.1 Private Extension |00110000 |Tag |00100001 |Length |3.1.3.7.1.1.1 Extension1 ID |00000110 |Tag |00001001 |Length |***B9*** |ID |3.1.3.7.1.1.2 Unknown Parameter |10100100 |Tag |00010100 |Length |**B20*** |Contents |***B2*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |ed|a9|3f|c3|97|00|ee|52|09|81|03|0e|19|0b|12|06| |10 |00|11|04|43|06|07|00|10|04|0b|12|08|00|11|04|43| |20 |06|07|20|59|00|8b|62|81|88|48|03|e9|00|0a|6b|1e| |30 |28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f|80| |40 |02|07|80|a1|09|06|07|04|00|00|01|00|05|03|6c|80| |50 |a1|5d|02|01|01|02|01|16|30|55|80|07|91|43|06|07| |60 |00|10|f4|83|01|00|86|07|91|43|06|07|20|59|f0|87| |70 |05|00|02|01|00|01|aa|0a|0a|01|04|04|05|04|03|80| |80 |90|a3|ab|04|03|02|06|c0|ad|25|a0|23|30|21|06|09| |90 |2a|86|3a|00|89|61|3a|01|00|a4|14|30|03|81|01|06| |A0 |30|03|81|01|07|30|03|81|01|08|30|03|81|01|0a|00| |B0 |00| | | | | | | | | | | | | | | |

|(UNIV P BitString) |2 |6 |Yes |Yes |0 |(CONT |37 |(CONT |35 |(UNIV |33 |(UNIV |9 |2a 86 |(CONT |20 |30 03 |EOC

| | | | | | | C [13]) | | | C [0]) | | | C Sequence (of)) | | | P Obj Identifier) | | 3a 00 89 61 3a 01 00 | | C [4]) | | 81 01 06 30 03 81 01 07 30 ...| |

Send Routing Info for Short Message (SRIfSM) CT (1) - Protocol Level Display (16) 08/25/03 13:20:01 367 ms Link: STP51 DECODING ERROR: Parameter error (at position 26 hex) |--> DECODING ERROR: IE not allowed (at position 5A hex) |--> DECODING ERROR: IE not allowed (at position 64 hex) |--> DECODING ERROR: IE not allowed (at position 67 hex) |---v--- DECODING ERROR: Parameter error ---v--|Begin |01100010 |Tag |(APPL C [2]) |01000001 |Length |65 |1 Origination Transaction ID |01001000 |Tag |(APPL P [8]) |00000100 |Length |4 |***B4*** |Orig Trans ID |503316741 |2 Dialogue Portion |01101011 |Tag |(APPL C [11]) |00011110 |Length |30 |2.1 Dialogue External |00101000 |Tag |(UNIV C External) |00011100 |Length |28 |2.1.1 Dialogue Object ID |00000110 |Tag |(UNIV P Obj Identifier) |00000111 |Length |7 |00000000 |Authority |CCITT Recommendation |00010001 |Name Form |q |10000110 |Rec Number |7 |00000101 |Rec Number |73 |00000001 |AS |1 |00000001 |Dialog-AS |Dialogue PDU |00000001 |Version |1 |2.1.2 Dialogue single ASN1 |10100000 |Tag |(CONT C [0]) |00010001 |Length |17 |2.1.2.1 Dialogue Request |01100000 |Tag |(APPL C [0]) |00001111 |Length |15 |2.1.2.1.1 Protocol Version |10000000 |Tag |(CONT P [0]) |00000010 |Length |2 |00000111 |UnusedBits |7 |1------- |Version 1 |Yes |-0000000 |Filler |0 |2.1.2.1.2 Application Context Name |10100001 |Tag |(CONT C [1]) |00001001 |Length |9 |2.1.2.1.2.1 ACN Object ID |00000110 |Tag |(UNIV P Obj Identifier) |00000111 |Length |7 |0000---- |ObjId |CCITT |----0100 |Organization |Identified-organization |00000000 | |ETSI |00000000 |Domain |Mobile Domain |00000001 |Mobile Subdomain |GSM-Network |00000000 |Common Component ID |AC-ID |00001110 |Application Context |Info Retrieval |00000011 |Version |- unknown / undefined |3 Component Portion |01101100 |Tag |(APPL C [12]) |00011001 |Length |25 |3.1 Invoke |10100001 |Tag |(CONT C [1]) |00010111 |Length |23 |3.1.1 Invoke ID |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00000001 |Invoke ID value |1 |3.1.2 Local Operation |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00111000 |Operation Code |Send Authentication Info |3.1.3 Parameter Sequence |00110000 |Tag |(UNIV C Sequence (of)) |00001111 |Length |15 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.1 Unknown Parameter |10000000 |Tag |(CONT P [0]) |00001000 |Length |8 |***B8*** |Contents |12 04 01 03 00 00 50 f2 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.2 Integer |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00000001 |Integer Value |1 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.3 Unknown Parameter |10000001 |Tag |(CONT P [1]) |00000000 |Length |0 +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |87|87|3f|c3|98|c0|20|90|09|81|03|0e|19|0b|12|06| |10 |00|11|04|43|06|07|00|11|01|0b|12|07|00|11|04|43| |20 |06|07|20|71|00|43|62|41|48|04|1e|00|01|05|6b|1e| |30 |28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f|80| |40 |02|07|80|a1|09|06|07|04|00|00|01|00|0e|03|6c|19| |50 |a1|17|02|01|01|02|01|38|30|0f|80|08|12|04|01|03| |60 |00|00|50|f2|02|01|01|81|00| | | | | | | |

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

127

Appendix A

Send Routing Info acknowledgement (SRI_ack) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |13:13:20,615,575 1:B (Rx):7 MTP-L2 MSU SCCP UDT MAP END | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1011011 |Backward Sequence Number |91 | |1------- |Backward Indicator Bit |1 | |-0100000 |Forward Sequence Number |32 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--10---- |Sub-Service: Priority |priority 2 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |3000 | |**b14*** |Originating Point Code |3001 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0011---- |Signalling Link Selection |3 | |00001001 |SCCP Message Type |9 | |----0000 |Protocol Class |Class 0 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00001110 |Pointer to parameter |14 | |00011001 |Pointer to parameter |25 | |Called address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-1------ |Routing Indicator |Route on DPC + Subsystem No. | |0------- |For national use |0 | |00001000 |Subsystem number |MSC | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Called Address Signals |34607002950 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002954 | |0000---- |Filler |0 | |Data parameter | |01011000 |Parameter length |88 | |**B88*** |Data |64 56 49 03 e9 00 0a 6b 2a 28 28 ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) END (= End) | |End | |01100100 |Tag |(APPL C [4]) | |01010110 |Length |86 | |1 Destination Transaction ID | |01001001 |Tag |(APPL P [9]) | |00000011 |Length |3 | |***B3*** |Dest Trans ID |15269898 | |2 DialoguePortion | |01101011 |Tag |(APPL C [11]) | |00101010 |Length |42 | |2.1 DialogueExternal | |00101000 |Tag |(UNIV C External) | |00101000 |Length |40 | |2.1.1 DialogueObjectID | |00000110 |Tag |(UNIV P Obj Identifier) | |00000111 |Length |7 | |00000000 |Authority |CCITT Recommendation | |00010001 |Name Form |q | |10000110 |Rec Number |7 | |00000101 |Rec Number |73 | |00000001 |AS |1 | |00000001 |Dialog-AS |Dialogue PDU | |00000001 |Version |1 | |2.1.2 DialoguesingleASN1 | |10100000 |Tag |(CONT C [0]) | |00011101 |Length |29 | |2.1.2.1 DialogueResponse | |01100001 |Tag |(APPL C [1]) | |00011011 |Length |27 | |2.1.2.1.1 Protocol Version | |10000000 |Tag |(CONT P [0]) | |00000010 |Length |2 | |00000111 |UnusedBits |7 | |1------- |Version 1 |Yes | |-0000000 |Filler |0 | |2.1.2.1.2 Application Context Name | |10100001 |Tag |(CONT C [1]) |

128

Appendix A

|00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000101 |Application Context |00000011 |Version |2.1.2.1.3 ResultType |10100010 |Tag |00000011 |Length |2.1.2.1.3.1 Associate-Result |00000010 |Tag |00000001 |Length |00000000 |Associate Result |2.1.2.1.4 ResultSourceDiagnostic |10100011 |Tag |00000101 |Length |2.1.2.1.4.1 DialogueServiceUser |10100001 |Tag |00000011 |Length |2.1.2.1.4.1.1 Dialogue Service User Value |00000010 |Tag |00000001 |Length |00000000 |Dialogue Service User |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Return Result Last |10100010 |Tag |00011111 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Return Result Sequence |00110000 |Tag |00011010 |Length |3.1.2.1 Local Operation |00000010 |Tag |00000001 |Length |00010110 |Operation Code |3.1.2.2 Send Routing Info Res (v3) |10100011 |Tag |10000000 |Length |3.1.2.3 IMSI |10001001 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.2.4 Roaming Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |Roaming Address Signals |1111---- |Filler |**b16*** |3.1.2.4 Length |**b16*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |db|a0|3f|e3|b8|4b|ee|32|09|80|03|0e|19|0b|52|08| |10 |00|11|04|43|06|07|20|59|00|0b|12|06|00|11|04|43| |20 |06|07|20|59|04|58|64|56|49|03|e9|00|0a|6b|2a|28| |30 |28|06|07|00|11|86|05|01|01|01|a0|1d|61|1b|80|02| |40 |07|80|a1|09|06|07|04|00|00|01|00|05|03|a2|03|02| |50 |01|00|a3|05|a1|03|02|01|00|6c|80|a2|1f|02|01|01| |60 |30|1a|02|01|16|a3|80|89|08|12|04|01|00|00|00|10| |70 |f4|04|07|91|43|06|17|85|30|f2|00|00|00|00| | |

|9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Loc Info Retrieval |Version3 |(CONT C [2]) |3 |(UNIV P Integer) |1 |Accepted |(CONT C [3]) |5 |(CONT C [1]) |3 |(UNIV P Integer) |1 |Null |(APPL C [12]) |EOC-encoded |(CONT C [2]) |31 |(UNIV P Integer) |1 |1 |(UNIV C Sequence (of)) |26 |(UNIV P Integer) |1 |Send Routing Info |(CONT C [3]) |EOC-encoded |(CONT P [9]) |8 |214010000000014 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607158032 |15 |EOC |EOC

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Initial Address Message (IAM) 17:20:54 014 ms Link: STP51