152956_50a95_statya_1_umts_gsm

Solution for Mobile Number Portability and

Flexible Allocation in a GSM/UMTS Network

PAR KRAGSTERMAN

Master’s Degree ProjectStockholm, 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

1

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

Brief summary in Spanish

1

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.


2

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 re-enrutamientos 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


3

• 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.


4

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.

Foreword

5

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.

Contents

6

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 _________________________________________________ 25 2.3.1 Normal Location Updating (LU) _____________________________ 25 2.3.2 GPRS Attach _____________________________________________ 27 2.3.3 Call to mobile subscriber ___________________________________ 28 2.3.4 Short message to a MS _____________________________________ 30 2.3.5 Intelligent Network (IN) request for subscriber information ________ 30 2.3.6 Location information request by a location application ____________ 31 2.3.7 Short message from a MS with policing based on subscriber IMSI___ 32

2.4 Protocol stack Signaling System number 7 (SS7)___________________ 33 2.4.2 MTP ___________________________________________________ 34 2.4.3 SCCP___________________________________________________ 34 2.4.4 TCAP __________________________________________________ 36 2.4.5 MAP ___________________________________________________ 36

3 Introduction to Mobile Number Portability (MNP) _______ 39

3.1 Reasons to introduce MNP_____________________________________ 39

3.2 MNP technical network specification ____________________________ 40 3.2.1 Indirect routing case: Consult the number range owner network _____ 40 3.2.2 Direct routing case: Consult the originating network ______________ 41 3.2.3 Signaling messages for MNP in call oriented cases _______________ 42 3.2.4 Signaling messages for MNP in not call oriented cases ____________ 43

3.3 NRN assignments in Spain _____________________________________ 44

4 Introduction to Flexible Allocation (FA)_________________ 45

5 MNP/FA solution____________________________________ 47

Contents

7

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 ______________________________________ 80 7.3.1 Service subscribers data ____________________________________ 82

7.3.1.1 SUBSCRIBER table _____________________________________ 82 7.3.1.2 Database search procedure ________________________________ 83

7.3.2 Service configuration data___________________________________ 84

Contents

8

7.3.2.1 Configuration parameter tables_____________________________ 85 7.3.2.2 HLRLOCATION table ___________________________________ 86 7.3.2.3 NETWORK table _______________________________________ 86 7.3.2.4 MSISDNNORMALIZATION table _________________________ 87 7.3.2.5 MSISDN normalization procedure __________________________ 88 7.3.2.6 COMBINATION table ___________________________________ 89 7.3.2.7 Combination procedure___________________________________ 90 7.3.2.8 MGTTRANSLATION table _______________________________ 91 7.3.2.9 MGT-IMSI translation procedure ___________________________ 92 7.3.2.10 TCAPERRORCODES table _____________________________ 92 7.3.2.11 LOCAL table_________________________________________ 93

7.4 Signaling____________________________________________________ 93 7.4.1 General _________________________________________________ 93 7.4.2 MAP processing __________________________________________ 96

7.4.2.1 MSISDN processing _____________________________________ 97 7.4.2.2 Foreign MSISDN SRI processing___________________________ 97 7.4.2.3 Foreign MSISDN non SRI processing _______________________ 98 7.4.2.4 MSISDN not found ______________________________________ 98 7.4.2.5 NRN – Database mismatch ________________________________ 98 7.4.2.6 IMSI processing ________________________________________ 98 7.4.2.7 IMSI not found _________________________________________ 99

7.5 Statistics ___________________________________________________ 101 7.5.1 Counters _______________________________________________ 101

7.5.1.1 SS7 stack counters _____________________________________ 101 7.5.1.2 Operating system counters _______________________________ 101 7.5.1.3 Service logic counters ___________________________________ 101

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 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

Contents

9

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

1 Introduction

10

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

1 Introduction

11

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.

1 Introduction

12

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.

2 Introduction to GSM/UMTS networks

13

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.


14

STP

HLR 1

HLR 2

HLR n

. . .Static routing

decision

STPSTP

HLR 1HLR 1

HLR 2HLR 2

HLR nHLR n

. . .Static routing

decision

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.


15

HLR 1

HLR 2

HLR n

. . .Dynamic

routing decision

SRN

HLR 1HLR 1

HLR 2HLR 2

HLR nHLR n

. . .Dynamic

routing decision

SRNSRN

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.


16

HLR nDynamic routing decision

SRN

Another Network Operator

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

HLR nHLR nDynamic routing decision

SRNSRN

Another Network OperatorAnother Network Operator

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

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.


17

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.


18

MS

Node B

RNC

Node B

RNS

UMSC/VLR

HLR/AuC

NSS

SGSN

GMLC

SCP

SMSC

GGS N

STP

MSMS

Node BNode B

RNCRNC

Node BNode B

RNS

UMSC/VLRUMSC/VLR

HLR/AuCHLR/AuC

NSS

SGSNSGSN

GMLCGMLC

SCPSCP

SMSCSMSC

GGS NGGS N

STPSTP

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.


19

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.

NSSRNS

Node B RNC UMSC/VLRMS

Node B

Node B

NSSNSSRNSRNS

Node BNode B RNCRNC UMSC/VLRUMSC/VLRMSMS

Node B

Node B

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 circuit-switched 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


20

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 HLRRNCRNC UMSC/VLRUMSC/VLR HLRHLR

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.


21

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

HLR/AuCHLR/AuC

UMSC/VLRUMSC/VLR SGSNSGSN

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.


22

HLR

UMSC/VLR SGSN

STPRNC HLRHLR


STPSTPRNCRNC

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 HLRSGSNRNCRNC HLRHLRSGSNSGSN

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.


23

RNC SGSN External NetworkGGS NRNCRNC SGSNSGSN External NetworkExternal NetworkGGS NGGS N

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.

HLR/AuCSMSCUMSC/VLR HLR/AuCHLR/AuCSMSCSMSCUMSC/VLRUMSC/VLR

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.


24

• 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.

SCP HLR/AuC

UMSC/VLR SGSN

SMSC SCPSCP HLR/AuCHLR/AuC


SMSCSMSC

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.


25

GMLC External/Internallocation applications

HLR/AuC GMLCGMLC External/Internallocation applications

External/Internallocation applications

HLR/AuCHLR/AuC

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.


26

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.


27

RNC

UMSC/VLRY

UMSC/VLRX

HLR/AuC

RNC Node B

Node B

LAI=Y

LAI=X

MS

1. Location Updating request3.

Authentication

2. IMS I ↔ MGT

5. Store IMS I ↔ UMSC/VLR

7. Location cancellation

4. Subscriber information

request 6. Subscriber information

response

RNCRNC

UMSC/VLRY

UMSC/VLRY

UMSC/VLRX

UMSC/VLRX

HLR/AuCHLR/AuC

RNCRNC Node BNode B

Node BNode B

LAI=Y

LAI=X

MSMS

1. Location Updating request3.

Authentication

2. IMS I ↔ MGT

5. Store IMS I ↔ UMSC/VLR

7. Location cancellation

4. Subscriber information

request 6. Subscriber information

response

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.


28

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.

SGSN(new)

HLR

RNC B Node

MS

1. Attach Request

3. Update GPRS

Location

4. Insert Subscriber

Data

5. Attach Accept

2. IMS I ↔ MGT

SGSN(new)SGSN(new)

HLRHLR

RNCRNC B NodeB Node

MSMS

1. Attach Request

3. Update GPRS

Location

4. Insert Subscriber

Data

5. Attach Accept

2. IMS I ↔ MGT

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


29

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.

RNCUMSC UMSC/VLR

HLR

B Node

B Node

MS

B Node

1. MS ISDN

2. MS ISDN

3. IMS I

4. MS RN

4. MS RN

5.

6. MSRN ↔ IMS I7. IMS I → LAI

8. Page

8. Page

8. Page

9. Page response

10.

RNCRNCUMSCUMSC UMSC/VLRUMSC/VLR

HLRHLR

B NodeB Node

B NodeB Node

MSMS

B NodeB Node

1. MS ISDN

2. MS ISDN

3. IMS I

4. MS RN

4. MS RN

5.

6. MSRN ↔ IMS I7. IMS I → LAI

8. Page

8. Page

8. Page

9. Page response

10.

Figure 2.16 Call to MS


30

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.

SMSC HLR/AuC

UMSC/VLR RNC Node B MS

1. SRIfS M (MS ISDN)

2.SRIfS M_ack

3. MT-S M

4. SM

SMSCSMSC HLR/AuCHLR/AuC

UMSC/VLRUMSC/VLR RNCRNC Node BNode B MSMS

1. SRIfS M (MS ISDN)

2.SRIfS M_ack

3. MT-S M

4. SM

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.


31

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.

SCP

UMSC/VLRHLR/AuC

1. Any Time Interrogation

Request

2. Provide Suscriber

Info Request

3. Provide Suscriber Info

Response


Response

SCPSCP

UMSC/VLRUMSC/VLRHLR/AuCHLR/AuC


Request

2. Provide Suscriber

Info Request

3. Provide Suscriber Info

Response


Response

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.


32

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.

GMLC

UMSC/VLR

HLR/AuC

RNC Node B

1.

MS

5. Page

Internal or ExternalApplication

9.

2. SRIfLCS

(MS ISDN)

3. SRIfLCS_ack

4. Provide Subscriber Location

7. response

6. Perform Location

8. Provide Subscriber

Location ack

GMLCGMLC

UMSC/VLRUMSC/VLR

HLR/AuCHLR/AuC

RNCRNC Node BNode B

1.

MSMS

5. Page



9.

2. SRIfLCS

(MS ISDN)

3. SRIfLCS_ack

4. Provide Subscriber Location

7. response

6. Perform Location

8. Provide Subscriber

Location ack

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.


33

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.

SMSCUMSC

HLR/AuCUMSC/VLRRNCNode B

5. FWD S M

MS

2. SendIMS I(MS ISDN)

3. SendIMS Iack (IMS I)

4. FWD S M

1. MO-S M (MS ISDN)

SMSCSMSCUMSCUMSC

HLR/AuCHLR/AuCUMSC/VLRUMSC/VLRRNCRNCNode BNode B

5. FWD S M

MSMS

2. SendIMS I(MS ISDN)

3. SendIMS Iack (IMS I)

4. FWD S M

1. MO-S M (MS ISDN)

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


34

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))

MTP

SCCP

TCAP

OMAP MAP INAP ISUP

MTP

SCCP

TCAP

OMAP MAP INAP ISUP

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.


35

• 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.


36

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


37

• 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 GT indicator = 0100 = 4 (includes Translation Type (TT), Numbering Plan (NP), Encoding Scheme and Nature of Address (NA))

Originating address


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 VLR UMSC EIR

Other Network E: GT

T: MSISDN

- - -

HLR - I: PC / GT

E: GT

T: VLR number

- -


38

VLR I: PC / GT

E: GT

T: IMSI / MSISDN / HLR number

I: PC / GT

E: GT

T: VLR number

UMSC I: PC / GT

E: GT

T: MSISDN

I: PC / GT

E: GT

T: VLR number

I: PC / GT

E: GT

T: UMSC number

I: PC / GT

E: GT

T: EIR number

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

3 Introduction to Mobile Number Portability (MNP)

39

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.


40

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.


41

Originating Network

Number Range Owner Network Recipient Network

MNPDatabase

Originating NetworkOriginating Network

Number Range Owner NetworkNumber Range Owner Network Recipient NetworkRecipient Network

MNPDatabase

MNPDatabase

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.


42

Originating Network

Number Range Owner Network Recipient NetworkMNP

Database

Originating NetworkOriginating Network

Number Range Owner NetworkNumber Range Owner Network Recipient NetworkRecipient NetworkMNP

DatabaseMNP

Database

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.


• 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.


43

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.


• 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.


• 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.


44

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.

4 Introduction to Flexible Allocation (FA)

45

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.

HLR 1

HLR 2

HLR n

Range of MS ISDN 1Range of IMS I 1


Range of MS ISDN nRange of IMS I n

. . .

HLR 1HLR 1

HLR 2HLR 2

HLR nHLR n



Range of MS ISDN nRange of IMS I 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.

4 Introduction to Flexible Allocation (FA)

46

• 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.

5 MNP/FA solution

47

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)”.

5 MNP/FA solution

48

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

5 MNP/FA solution

49

• SendIMSI

5.3 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.

6 The Signaling Relay Node (SRN) in action

50

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 8 Numbering Plan 9 Nature of Address


51

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 11 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.


52

UMSC or SGSN STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

5.

UMSC or SGSNUMSC or SGSN STPSTP SRNSRN

HLR 1HLR 1 HLR nHLR n

1. 2.

. . .

4.

3.

5.

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 NP NA NS New GT

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


53

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.

UMSC STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

5.

UMSCUMSC STPSTP SRNSRN


1. 2.

. . .

4.

3.

5.

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.


54

1. A petition is received by the UMSC/VLR.


SCCP TT NP NA NS

CgPA 0 1 4 UMSC

CdPA 0 1 4 MSISDN


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


55

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

UMSC STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

5.

External Network



1. 2.

. . .

4.

3.

5.

External NetworkExternal 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

21 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].


56

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


SCCP TT NP NA NS

CgPA 0 1 4 UMSC

CdPA 0 1 11225 MSISDN


TT NP NA NS New GT

0 1 112 MSISDN SRN


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.


57

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.

External Network

UMSC STP SRN

HLR 1 HLR n

1.

2.

. . .

4.

3.

5.




1.

2.

. . .

4.

3.

5.

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.


58

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


TT NP NA NS New GT

0 1 4 MSISDN SRN


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.


59

SMSC STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

5.

SMSCSMSC STPSTP SRNSRN


1. 2.

. . .

4.

3.

5.

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


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


60

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

SMSC STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

External Network

SMSCSMSC STPSTP SRNSRN


1. 2.

. . .

4.

3.


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.


61

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



TT NP NA NS New GT

0 1 126 CC+NRN+MSISDN SRN


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.


62

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.

External Network

UMSC STP SRN

HLR 1 HLR n

1.

2.

. . .

4.

3.

5.

1.




1.

2.

. . .

4.

3.

5.

1.

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


63

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


TT NP NA NS New GT

0 1 4 MSISDN SRN


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.


64

STP SRN

HLR 1 HLR n

1.

2.

. . .

4.

3.

5.

SCP STPSTP SRNSRN


1.

2.

. . .

4.

3.

5.

SCPSCP

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


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


65

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


STP SRN

HLR 1 HLR n

2.

. . .

4.

3.

External Network

1.

SCP STPSTP SRNSRN


2.

. . .

4.

3.


1.

SCPSCP

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.


66

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


2. In the STP the following GTT is specified.

TT NP NA NS New GT



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.


67

External Network

STP SRN

HLR 1 HLR n

. . .

3.

2.

4.

1.


STPSTP SRNSRN


. . .

3.

2.

4.

1.

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).


68

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


TT NP NA NS New GT

0 1 4 MSISDN SRN


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.


69

Internal/externalLocation application

STP SRN

HLR 1 HLR n

1.

2.

. . .

4.

3.

5.

GMLC



STPSTP SRNSRN


1.

2.

. . .

4.

3.

5.

GMLCGMLC

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


70

CdPA 0 1 4 MSISDN


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


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.


71

STP SRN

HLR 1 HLR n

2.

. . .

4.

3.

External Network

1.

GMLC


1.

STPSTP SRNSRN


2.

. . .

4.

3.


1.

GMLCGMLC



1.

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.


72

SCCP TT NP NA NS

CgPA 0 1 4 GLMC41


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

TT NP NA NS New GT



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.


73

External Network

STP SRN

HLR 1 HLR n

. . .

3.

2.

4.

1.


STPSTP SRNSRN


. . .

3.

2.

4.

1.

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.


74

SCCP TT NP NA NS

CgPA 0 1 4 VLR

CdPA 0 1 4 MSISDN


TT NP NA NS New GT

0 1 4 MSISDN SRN


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.


75

VLR STP SRN

HLR 1 HLR n

1. 2.

. . .

4.

3.

5.

VLRVLR STPSTP SRNSRN


1. 2.

. . .

4.

3.

5.

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


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


76

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


STP SRN

HLR 1 HLR n

2.

. . .

4.

3.

External Network

UMSC/VLR

1.

STPSTP SRNSRN


2.

. . .

4.

3.


UMSC/VLRUMSC/VLR

1.

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.


77

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


2. In the STP the following GTT is specified.

TT NP NA NS New GT



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.


78

External Network

STP SRN

HLR 1 HLR n

. . .

3.

2.

4.

1.


STPSTP SRNSRN


. . .

3.

2.

4.

1.

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.

7 The SRN technical specification

79


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.

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

[Req 5] 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.


80

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 Dist. Typ. Size (bytes/bits)

TPS with 1 link

TPS with * links

TPS at 40% Capacity

UL49 *% */* * * *

GPRS UL50 *% */* * * *

SRI51 *% */* * * *

SRIfSM52 *% */* * * *

ATI53 *% */* * * *

SAI54 *% */* * * *

SRIfLCS55 *% */* * * *

SendIMSI *% */* * * *

Weighted Average

100% */* * * *

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 50 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


81

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.


82

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.


83

IMSI Alternate Key CHAR(20) The IMSI of the subscribers SIM-card. 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


84

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.


85

[Req 22] The Service configuration data will be able to be added, deleted, and modified in run-time without having to restart the application.

7.3.2.1 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 The value to insert into the numberPortabilityStatus parameter (section 7.4.2.2)

Positive or zero Integer

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


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


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


[Req 25] 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),


86

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).

7.3.2.2 HLRLOCATION table

[Req 26] The GT and Point Code / SubSystem Number (PC/SSN) of the HLRs in the network shall be contained in the HLRLOCATION table.

HLRLOCATION


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 NETWORK table

[Req 30] The network ID’s and their routing numbers shall be contained in the NETWORK table.

NETWORK



87

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.

[Req 31] 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 MSISDNNORMALIZATION table

[Req 34] The table MSISDNNORMALIZATION shall be used in order to normalize the MSISDN.


88

MSISDNNORMALIZATION


ISDNNoA Key INTEGER The ISDN Nature of Address Indicator

DeleteAdd1 Attribute CHAR(20) A comma separated pair of prefixes to delete and add.

...

DeleteAdd5 Attribute CHAR(20) A comma separated pair of prefixes to delete and add.

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 D/A3 D/A4 D/A5

4 (International) 34R,34 0034R,34 34,34 - -


89

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) 33610513304, it would not be possible to normalize the address.

• If the incoming MSISDN was (national) 729999610513304, 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 COMBINATION table

[Req 35] The COMBINATION table shall be used to combine a NRN and an MSISDN.

COMBINATION


ISDNNoA Key INTEGER The ISDN NoA Indicator

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


90

ModifiedNoA Attribute INTEGER The output NoA (If ModifyNoA is TRUE)

DeleteAdd1 Attribute CHAR(20) A comma separated pair of prefixes to delete and add

...

DeleteAdd5 Attribute CHAR(20) A comma separated pair of prefixes to delete and add

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.


91

• 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 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 MGTTRANSLATION table

[Req 36] The table MGTTRANSLATION shall be used in order to translate the MGT into an IMSI.

MGTTRANSLATION


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


92

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


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).


93

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


HostName Key CHAR (20) Hostname of the node

GlobalTitle Attribute CHAR(30) Contains the GT of the node

7.4 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.


94

[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.

• MAP

[Req 45] 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.


95

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.


Routing Indicator 0 (Route On Global Title)

Global Title Indicator 100 (TT, NP, ES and NoA)


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


96

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 TBCD representation of the destination GT

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


Routing Indicator 1 (Route On Point Code)

Global Title Indicator 000 (No Global Title)


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.


97

7.4.2.1 MSISDN processing

[Req 52] 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.


98

[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] Relayed messages shall be routed on GT always.

7.4.2.4 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



7.4.2.6 IMSI processing

[Req 75] 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.


99

[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




100

MAP

MGT?NO YES

NORMALIZE(MS ISDN)

TRANSLATE(MGT -> IMS I)

NONormalizationpossible?

YES

SENDERROR

DB S EARCH (MS ISDN)

MS ISDNtype?

OWN

SENDERROR

OTHER

HLR RELAY FOREIGN

NRNpresent?

SENDERROR

YESNO

SRImessage?

RELAY TO OTHER NET

NOYES

SRI RESPONS E

NOTranslationpossible?

YES

SENDERROR

DB S EARCH (IMS I)

IMS Itype?

OWN

SENDERROR

OTHER

HLR RELAY

FOREIGN

10.4.2

10.3.2.5 10.3.2.9

10.3.1.2 10.3.1.2

10.4.2.5

10.4.2.2 10.4.2.3

10.4.2.4 10.4.2.7

MAPMAP

MGT?NO YES

NORMALIZE(MS ISDN)

TRANSLATE(MGT -> IMS I)

NONormalizationpossible?

Normalizationpossible?

YES

SENDERROR

DB S EARCH (MS ISDN)

MS ISDNtype?

MS ISDNtype?

OWN

SENDERROR

OTHER

HLR RELAY FOREIGN

NRNpresent?

NRNpresent?

SENDERROR

YESNO

SRImessage?

SRImessage?

RELAY TO OTHER NET

NOYES

SRI RESPONS E

NOTranslationpossible?

Translationpossible?

YES

SENDERROR

DB S EARCH (IMS I)

IMS Itype?IMS Itype?

OWN

SENDERROR

OTHER

HLR RELAY

FOREIGN

10.4.2

10.3.2.5 10.3.2.9

10.3.1.2 10.3.1.2

10.4.2.5

10.4.2.2 10.4.2.3

10.4.2.4 10.4.2.7

Figure 7.1 Visual MAP processing description.


101

7.5 Statistics

7.5.1 Counters

7.5.1.1 SS7 stack counters

[Req 82] The SS7 counters provided for each signaling link shall be

• Number of Message Signal Units (MSU) sent

• Number of MSU received

• 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

7.5.1.2 Operating system counters

[Req 83] The operating system counters provided shall be.

• CPU Idle Time

• Unused memory

• Disk Free Space

7.5.1.3 Service logic counters

[Req 84] 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


102

• 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


103

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.

• MNP/FA application not available

• Alarms related to signaling links, route sets, etc.

• Hardware alarms

7.7 Provisioning system [Req 89] The MNP/FA server shall provide two provisioning interfaces.

• Read/Write interfaces


104

• Read only interfaces

[Req 90] The operations that provisioning clients will be able to perform on a read/write interface will be.

• 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.

[Req 91] 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.


105

[Req 96] The following events in the provisioning system shall be logged.

• All operations which result in a database modification.

[Req 97] 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.

8 Conclusions and future work

106

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.

8 Conclusions and future work

107

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.

9 Definitions, abbreviations and symbols

108


9.1 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.


109

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


110

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


111

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


112

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)


113

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)


114

Radio link, both voice and signaling traffic

Voice traffic link

Signaling traffic link

External Network

Internal or External Application

10 References

115

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

10 References

116

[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

Appendix A

117

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 |

Appendix A

118

|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 | |00000001 |Application Context |Network Loc Upd | |00000011 |Version |Version3 | |3 Component Portion | |01101100 |Tag |(APPL C [12]) | |10000000 |Length |EOC-encoded | |3.1 Invoke | |10100001 |Tag |(CONT C [1]) | |00101010 |Length |42 | |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 | |00000010 |Operation Code |Update Location | |3.1.3 Parameter Sequence | |00110000 |Tag |(UNIV C Sequence (of)) | |00100010 |Length |34 | |3.1.3.1 IMSI | |00000100 |Tag |(UNIV P OctetString) | |00001000 |Length |8 | |**b60*** |MCC + MNC + MSIN |214010000000012 | |1111---- |FILLER |15 | |3.1.3.2 Network Node Number | |10000001 |Tag |(CONT P [1]) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |Network Node Number |34607002953 | |1111---- |Filler |15 | |3.1.3.3 VLR Number | |00000100 |Tag |(UNIV P OctetString) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |VLR Address Signals |34607002953 | |1111---- |Filler |15 | |3.1.3.4 VLR Capability | |10100110 |Tag |(CONT C [6]) | |00000100 |Length |4 | |3.1.3.4.1 Supported Camel Phases | |10000000 |Tag |(CONT P [0]) | |00000010 |Length |2 | |00000110 |UnusedBits |6 | |1------- |Phase1 |Yes | |-0------ |Phase2 |No | |--000000 |Filler |0 | |***B2*** |3 Length |EOC | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |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| |

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 |

Appendix A

119

|**b14*** |Originating Point Code |3007 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0110---- |Signalling Link Selection |6 | |00001001 |SCCP Message Type |9 | |----0000 |Protocol Class |Class 0 | |0000---- |Message Handling |No special options | |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 | |-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 | |0111---- |Numbering Plan |ISDN/Mobile (Rec. E.214) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b60*** |Called Address Signals |346070000000036 | |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 | |10010101 |Subsystem number |SGSN | |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 |34607002966 | |0000---- |Filler |0 | |Data parameter | |01001100 |Parameter length |76 | |**B76*** |Data |62 4a 48 02 1d 00 6b 1e 28 1c 06 ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) | |Begin | |01100010 |Tag |(APPL C [2]) | |01001010 |Length |74 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) | |00000010 |Length |2 | |***B2*** |Orig Trans ID |7424 | |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 | |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 | |00100000 |Application Context |GPRS Location Update | |00000011 |Version |Version3 | |3 Component Portion | |01101100 |Tag |(APPL C [12]) | |00100100 |Length |36 | |3.1 Invoke | |10100001 |Tag |(CONT C [1]) | |00100010 |Length |34 | |3.1.1 Invoke ID |

Appendix A

120

|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 | |00010111 |Operation Code |Update GPRS Location | |3.1.3 Parameter Sequence | |00110000 |Tag |(UNIV C Sequence (of)) | |00011010 |Length |26 | |3.1.3.1 IMSI | |00000100 |Tag |(UNIV P OctetString) | |00001000 |Length |8 | |**b60*** |MCC + MNC + MSIN |214010000000036 | |1111---- |FILLER |15 | |3.1.3.2 SGSN Number | |00000100 |Tag |(UNIV P OctetString) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |SGSN Number |34607002966 | |1111---- |Filler |15 | |3.1.3.3 SGSN Address | |00000100 |Tag |(UNIV P OctetString) | |00000101 |Length |5 | |00------ |Address Type |IPv4 Address | |--000100 |Address Length |4 | |***B4*** |SGSN Address |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]) |

Appendix A

121

|00000011 |Length |3 | |***B3*** |Orig Trans ID |15269898 | |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 | |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 | |00000101 |Application Context |Loc Info Retrieval | |00000011 |Version |Version3 | |3 Component Portion | |01101100 |Tag |(APPL C [12]) | |10000000 |Length |EOC-encoded | |3.1 Invoke | |10100001 |Tag |(CONT C [1]) | |01011101 |Length |93 | |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 | |00010110 |Operation Code |Send Routing Info | |3.1.3 Parameter Sequence | |00110000 |Tag |(UNIV C Sequence (of)) | |01010101 |Length |85 | |3.1.3.1 MS Isdn Address Number | |10000000 |Tag |(CONT P [0]) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |MS ISDN Address Signals |34607000014 | |1111---- |Filler |15 | |3.1.3.2 Interrogation Type | |10000011 |Tag |(CONT P [3]) | |00000001 |Length |1 | |00000000 |Interrogation Type |Basic call | |3.1.3.3 Gmsc Address | |10000110 |Tag |(CONT P [6]) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |GMSC Address Signals |34607002950 | |1111---- |Filler |15 | |3.1.3.4 Call Reference Number | |10000111 |Tag |(CONT P [7]) | |00000101 |Length |5 | |***B5*** |Call Reference Number |00 02 01 00 01 | |3.1.3.5 Network Signal Info | |10101010 |Tag |(CONT C [10]) | |00001010 |Length |10 | |3.1.3.5.1 Protocol Id | |00001010 |Tag |(UNIV P Enumerated) | |00000001 |Length |1 | |00000100 |Protocol Id |Ets-300102-1 | |3.1.3.5.2 Signal Info | |00000100 |Tag |(UNIV P OctetString) | |00000101 |Length |5 | |***B5*** |Signal Info |04 03 80 90 a3 | |3.1.3.6 Camel Info | |10101011 |Tag |(CONT C [11]) | |00000100 |Length |4 | |3.1.3.6.1 Supported Camel Phases |

Appendix A

122

|00000011 |Tag |(UNIV P BitString) | |00000010 |Length |2 | |00000110 |UnusedBits |6 | |1------- |Phase1 |Yes | |-1------ |Phase2 |Yes | |--000000 |Filler |0 | |3.1.3.7 Extension Container | |10101101 |Tag |(CONT C [13]) | |00100101 |Length |37 | |3.1.3.7.1 Private Extension List | |10100000 |Tag |(CONT C [0]) | |00100011 |Length |35 | |3.1.3.7.1.1 Private Extension | |00110000 |Tag |(UNIV C Sequence (of)) | |00100001 |Length |33 | |3.1.3.7.1.1.1 Extension1 ID | |00000110 |Tag |(UNIV P Obj Identifier) | |00001001 |Length |9 | |***B9*** |ID |2a 86 3a 00 89 61 3a 01 00 | |3.1.3.7.1.1.2 Unknown Parameter | |10100100 |Tag |(CONT C [4]) | |00010100 |Length |20 | |**B20*** |Contents |30 03 81 01 06 30 03 81 01 07 30 ...| |***B2*** |3 Length |EOC | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |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| | | | | | | | | | | | | | | |

Send Routing Info for Short Message (SRIfSM) CT (1) - Protocol Level Display (16) 08/25/03 13:20:01 367 ms Link: STP51<10<SMSC137 BSN: 34 BIB: 1 FSN: 39 FIB: 0 LI: 63 SI: SCCP SSF: NN/R DPC: STP51 OPC: SMSC137 SLS: 10 MT: UDT Protocol Class: Class 0 Message Handling: No special options Pointer to Called Address: 3 octets Pointer to Calling Address: 14 octets Pointer to Data: 25 octets Called Party Address Length: 11 octets Routing Indicator: Routing based on global title Global title indicator: Tran Type, Num Plan, Encoding Scheme, Addr Ind SSN Indicator: Address contains a Subsystem Number Point Code Indicator: Address does not contain a Signalling Point Code Subsystem Number: HLR Home Location Register Translation Type: Translation Type Not Used Encoding Scheme: BCD, odd number of digits Numbering Plan: ISDN/Telephony Nature of Address Indicator: International number Address Information: 34610513316h Calling Party Address Length: 11 octets Routing Indicator: Routing based on global title Global title indicator: Tran Type, Num Plan, Encoding Scheme, Addr Ind SSN Indicator: Address contains a Subsystem Number Point Code Indicator: Address does not contain a Signalling Point Code Subsystem Number: MSC Mobile Switching Centre Translation Type: Translation Type Not Used Encoding Scheme: BCD, odd number of digits Numbering Plan: ISDN/Telephony Nature of Address Indicator: International number Address Information: 34607003137h Data Length: 73 octets MT: Begin Length: 71 octets Originating Transaction ID Tag Length: 4 octets Transaction Id: d2d10a00h Dialogue Portion Tag Length: 30 octets External Tag Length: 28 octets Object Identifier Tag Length: 7 octets Dialogue-as-ID ccitt recommendation q 773 as(1) dialoguePDU version1(1) Single ASN.1 Type Tag Length: 17 octets Dialogue Request Tag Length: 15 octets Protocol Version Tag Length: 2 octets Unused Bits: 7 Version 1: Supported Application Context Name Tag

Appendix A

123

Length: 9 octets Object Identifier Tag Length: 7 octets Application Context Name ccitt identified organisation etsi mobile domain gsm Network ac_id ac : shortMsgGateway version 2 Component Portion Tag Length: 31 octets Invoke Length: 29 octets Invoke Id Tag Length: 1 octet Invoke Id: 0 dec, 0 hex Operation Code Tag: Local Operation Code Length: 1 octet Operation: Send Routing Information For Short Message Sequence Tag Length: 21 octets MS ISDN Tag Length: 7 octets Numbering Plan Indicator: ISDN/Telephony number plan Nature of Address: International number ISDN Address Digits: 34610513316f SM_RP_PRI Tag Length: 1 octet SM_RP_PRI Value: FALSE Service Centre Address Tag Length: 7 octets Numbering Plan Indicator: ISDN/Telephony number plan Nature of Address: International number Address Digits: 34607003137f Hex SU (111 octets): a2 27 3f c3 27 42 1c a1 09 00 03 0e 19 0b 12 06 00 11 04 43 16 50 31 13 06 0b 12 08 00 11 04 43 06 07 30 31 07 49 62 47 48 04 d2 d1 0a 00 6b 1e 28 1c 06 07 00 11 86 05 01 01 01 a0 11 60 0f 80 02 07 80 a1 09 06 07 04 00 00 01 00 14 02 6c 1f a1 1d 02 01 00 02 01 2d 30 15 80 07 91 43 16 50 31 13 f6 81 01 00 82 07 91 43 06 07 30 31 f7 1 | 1|0100010 | BIB = 1, BSN = 34 2 | 0|0100111 | FIB = 0, FSN = 39 3 | 00|111111 | Length Indicator : MSU, LI = 63 octets 4 | 1100|0011 | Service Indicator = SCCP, SSF = Reserved 5 | 0010 0111 | DPC : 551 dec, 0227 hex 6 | 01|000010 | 7 | 0001 1100 | OPC : 1137 dec, 0471 hex 8 | 1010|0001 | SLS : 10 dec, A hex 9 F | 0000 1001 | MT = Unitdata (UDT) 10 F | 0000 0000 | Protocol Class = class 0 11 V | 0000 0011 | Pointer to Called Party Address Parameter = 3 12 V | 0000 1110 | Pointer to Calling Party Address Parameter = 14 13 V | 0001 1001 | Pointer to Data Parameter = 25 14 V | 0000 1011 | LI of Called Party Address parameter = 11 octet(s) 15 V | 0001 0010 | Addr Ind: Route=GT; GT=TT&NP&ES&NoA; PC=N; SSN=Y 16 V | 0000 0110 | Subsystem Number = 6 HLR Home Location Register 17 V | 0000 0000 | Translation Type = 0 Translation Type Not Used 18 V | 0001|0001 | Numbering Plan & Encoding Scheme 19 V | 0|0000100 | Nature of Address Indicator 20 V | 0100|0011 | Address Signal 21 V | 0001|0110 | Address Signal 22 V | 0101|0000 | Address Signal 23 V | 0011|0001 | Address Signal 24 V | 0001|0011 | Address Signal 25 V | 0000|0110 | Address Signal 26 V | 0000 1011 | LI of Calling Party Address parameter = 11 octet(s) 27 V | 0001 0010 | Addr Ind: Route=GT; GT=TT&NP&ES&NoA; PC=N; SSN=Y 28 V | 0000 1000 | Subsystem Number = 8 MSC Mobile Switching Centre 29 V | 0000 0000 | Translation Type = 0 Translation Type Not Used 30 V | 0001|0001 | Numbering Plan & Encoding Scheme 31 V | 0|0000100 | Nature of Address Indicator 32 V | 0100|0011 | Address Signal 33 V | 0000|0110 | Address Signal 34 V | 0000|0111 | Address Signal 35 V | 0011|0000 | Address Signal 36 V | 0011|0001 | Address Signal 37 V | 0000|0111 | Address Signal 38 V | 0100 1001 | LI of Data parameter = 73 octet(s) 39 M | 0110 0010 | TCAP Message Type = Begin 40 M | 0|1000111 | Total TCAP Message length = 71 octet(s) 41 M | 0100 1000 | Originating Transaction ID tag 42 M | 0|0000100 | Originating Transaction ID length = 4 octet(s) 43 M | 1101 0010 | Transaction ID = D2D10A00 hex 44 M | 1101 0001 | Transaction ID 45 M | 0000 1010 | Transaction ID 46 M | 0000 0000 | Transaction ID 47 M | 0110 1011 | Dialogue tag 48 M | 0|0011110 | Dialogue length = 30 octet(s) 49 M | 0010 1000 | External tag 50 M | 0|0011100 | External length = 28 octet(s) 51 M | 0000 0110 | Object Identifier tag 52 M | 0|0000111 | Object Identifier length = 7 octet(s) 53 M | 0000 0000 | Dialogue-as-ID value ccitt 54 M | 0001 0001 | Dialogue-as-ID value q 55 M | 1000 0110 | Dialogue-as-ID value 773 56 M | 0000 0101 | Dialogue-as-ID value 57 M | 0000 0001 | Dialogue-as-ID value as 58 M | 0000 0001 | Dialogue-as-ID value DialoguePDU 59 M | 0000 0001 | Dialogue-as-ID value version 1 60 M | 1010 0000 | Single-ASN.1-type tag 61 M | 0|0010001 | Single-ASN.1-type length = 17 octet(s)

Appendix A

124

62 M | 0110 0000 | Dialogue Request (AARQ-apdu) tag 63 M | 0|0001111 | Dialogue Request (AARQ-apdu) length = 15 octet(s) 64 O | 1000 0000 | Protocol Version tag 65 O | 0|0000010 | Protocol Version length = 2 octet(s) 66 O | 0000 0111 | Protocol Version 67 O | 1000 0000 | Protocol Version 68 M | 1010 0001 | Application Context Name tag 69 M | 0|0001001 | Application Context Name length = 9 octet(s) 70 M | 0000 0110 | Object Identifier tag 71 M | 0|0000111 | Object Identifier length = 7 octet(s) 72 M | 0000 0100 | Application Context Name ccitt identified organisation 73 M | 0000 0000 | Application Context Name etsi 74 M | 0000 0000 | Application Context Name mobile domain 75 M | 0000 0001 | Application Context Name GSM Network 76 M | 0000 0000 | Application Context Name AC 77 M | 0001 0100 | Application Context Name shortMsgGateway 78 M | 0000 0010 | Application Context Name version 2 79 M | 0110 1100 | Component Portion tag 80 M | 0|0011111 | Component Portion length = 31 octet(s) 81 M | 1010 0001 | Component Type Tag = Invoke 82 M | 0|0011101 | Component length = 29 octet(s) 83 M | 0000 0010 | Invoke ID tag 84 M | 0|0000001 | Invoke ID length = 1 octet(s) 85 M | 0000 0000 | Invoke ID = 0 dec, 00 hex 86 M | 0000 0010 | Local Operation Code tag 87 M | 0|0000001 | Local Operation Code length = 1 octet(s) 88 F | 0010 1101 | Operation Code = Send Routing Info for Short Message 89 M | 0011 0000 | Sequence Tag 90 M | 0001 0101 | Sequence length = 21 octet(s) 91 M | 1000 0000 | MS ISDN Tag 92 M | 0000 0111 | MS ISDN length = 7 octet(s) 93 M | 1001|0001 | International number, ISDN/telephony number plan 94 M | 0100|0011 | MS ISDN Digits = 34610513316 95 M | 0001|0110 | MS ISDN Digits 96 M | 0101|0000 | MS ISDN Digits 97 M | 0011|0001 | MS ISDN Digits 98 M | 0001|0011 | MS ISDN Digits 99 M | 1111|0110 | MS ISDN Digits 100 M | 1000 0001 | SM RP PRI Tag 101 M | 0000 0001 | SM RP PRI length = 1 octet(s) 102 M | 0000 0000 | SM RP PRI = FALSE 103 M | 1000 0010 | Service Centre Address Tag 104 M | 0000 0111 | Service Centre Address length = 7 octet(s) 105 M | 1001|0001 | International number, ISDN/telephony number plan 106 M | 0100|0011 | Service Centre Address Digits = 34607003137 107 M | 0000|0110 | Service Centre Address Digits 108 M | 0000|0111 | Service Centre Address Digits 109 M | 0011|0000 | Service Centre Address Digits 110 M | 0011|0001 | Service Centre Address Digits 111 M | 1111|0111 | Service Centre Address Digits

Any Time Interrogation (ATI) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |13:48:16,975,994 1:A (Rx):7 MSU UDT BEG Any Time Interrogati 3001 151 13575260 | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1110000 |Backward Sequence Number |112 | |1------- |Backward Indicator Bit |1 | |-0101100 |Forward Sequence Number |44 | |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 |3001 | |**b14*** |Originating Point Code |151 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0001---- |Signalling Link Selection |1 | |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 | |00000110 |Subsystem number |HLR | |00000001 |Translation Type |- unknown / undefined - | |----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 |

Appendix A

125

|--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |10010011 |Subsystem number |gsmSCF | |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 | |1------- |Spare |- unknown / undefined - | |**b44*** |Calling Address Signals |34607001910 | |0000---- |Filler |0 | |Data parameter | |01100111 |Parameter length |103 | |**B103** |Data |62 65 48 04 00 cf 24 5c 6b 80 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]) | |01100101 |Length |101 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) | |00000100 |Length |4 | |***B4*** |Orig Trans ID |13575260 | |2 DialoguePortion | |01101011 |Tag |(APPL C [11]) | |10000000 |Length |EOC-encoded | |2.1 DialogueExternal | |00101000 |Tag |(UNIV C External) | |10000000 |Length |EOC-encoded | |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]) | |10000000 |Length |EOC-encoded | |2.1.2.1 DialogueRequest | |01100000 |Tag |(APPL C [0]) | |10000000 |Length |EOC-encoded | |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]) | |10000000 |Length |EOC-encoded | |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 | |00011101 |Application Context |AnyTime Info Enquiry | |00000011 |Version |Version3 | |***B2*** |2 Length |EOC | |2.1.2.1.3 User Info | |10111110 |Tag |(CONT C [30]) | |00001111 |Length |15 | |2.1.2.1.3.1 User Info External | |00101000 |Tag |(UNIV C External) | |00001101 |Length |13 | |2.1.2.1.3.1.1 User Info 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 | |00000001 |Common Component ID |AS-ID | |00000001 |AS-ID Branch |Map-Dialogue PDU | |00000001 |AS Version |1 | |2.1.2.1.3.1.2 User Info single ASN1 | |10100000 |Tag |(CONT C [0]) | |00000010 |Length |2 | |2.1.2.1.3.1.2.1 MAP-open | |10100000 |Tag |(CONT C [0]) | |00000000 |Length |0 | |***B2*** |2 Length |EOC | |***B2*** |2 Length |EOC | |***B2*** |2 Length |EOC | |***B2*** |2 Length |EOC | |3 Component Portion | |01101100 |Tag |(APPL C [12]) | |00100010 |Length |34 | |3.1 Invoke | |10100001 |Tag |(CONT C [1]) | |00100000 |Length |32 | |3.1.1 Invoke ID |

Appendix A

126

|00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |00000000 |Invoke ID value |0 | |3.1.2 Local Operation | |00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |01000111 |Operation Code |Any Time Interrogation | |3.1.3 Parameter Sequence | |00110000 |Tag |(UNIV C Sequence (of)) | |00011000 |Length |24 | |3.1.3.1 Subscriber Identity Constr | |10100000 |Tag |(CONT C [0]) | |00001001 |Length |9 | |3.1.3.1.1 MS Isdn Address Number | |10000001 |Tag |(CONT P [1]) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |MS ISDN Address Signals |34607000014 | |1111---- |Filler |15 | |3.1.3.2 Requested Info | |10100001 |Tag |(CONT C [1]) | |00000010 |Length |2 | |3.1.3.2.1 Location Information | |10000000 |Tag |(CONT P [0]) | |00000000 |Length |0 | |3.1.3.3 GSM Scf Address | |10000011 |Tag |(CONT P [3]) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |Gsm Scf Address |34607001910 | |1111---- |Filler |15 |

Send Authentication Info (SAI) +---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |12:58:05 PM,796,904 1:F (Rx):15 MTP-L2 MSU SCCP UDT MAP err BEG | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-0000111 |Backward Sequence Number |7 | |1------- |Backward Indicator Bit |1 | |-0000111 |Forward Sequence Number |7 | |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 |152 | |**b14*** |Originating Point Code |131 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |1001---- |Signalling Link Selection |9 | |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.163/E.164) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Called Address Signals |`34607000111` | |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.163/E.164) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |`34607002170` | |0000---- |Filler |0 | |Data parameter | |01000011 |Parameter length |67 | |**B67*** |Data |62 41 48 04 1e 00 01 05 6b 1e 28... | |E-GSM 09.02 (MAP) Version 5.3.0 (MAP) BEG (= Begin) |

Appendix A

127

|--> 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| | | | | | | |

Appendix A

128

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]) |

Appendix A

129

|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 | |00000101 |Application Context |Loc Info Retrieval | |00000011 |Version |Version3 | |2.1.2.1.3 ResultType | |10100010 |Tag |(CONT C [2]) | |00000011 |Length |3 | |2.1.2.1.3.1 Associate-Result | |00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |00000000 |Associate Result |Accepted | |2.1.2.1.4 ResultSourceDiagnostic | |10100011 |Tag |(CONT C [3]) | |00000101 |Length |5 | |2.1.2.1.4.1 DialogueServiceUser | |10100001 |Tag |(CONT C [1]) | |00000011 |Length |3 | |2.1.2.1.4.1.1 Dialogue Service User Value | |00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |00000000 |Dialogue Service User |Null | |3 Component Portion | |01101100 |Tag |(APPL C [12]) | |10000000 |Length |EOC-encoded | |3.1 Return Result Last | |10100010 |Tag |(CONT C [2]) | |00011111 |Length |31 | |3.1.1 Invoke ID | |00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |00000001 |Invoke ID value |1 | |3.1.2 Return Result Sequence | |00110000 |Tag |(UNIV C Sequence (of)) | |00011010 |Length |26 | |3.1.2.1 Local Operation | |00000010 |Tag |(UNIV P Integer) | |00000001 |Length |1 | |00010110 |Operation Code |Send Routing Info | |3.1.2.2 Send Routing Info Res (v3) | |10100011 |Tag |(CONT C [3]) | |10000000 |Length |EOC-encoded | |3.1.2.3 IMSI | |10001001 |Tag |(CONT P [9]) | |00001000 |Length |8 | |**b60*** |MCC + MNC + MSIN |214010000000014 | |1111---- |FILLER |15 | |3.1.2.4 Roaming Number | |00000100 |Tag |(UNIV P OctetString) | |00000111 |Length |7 | |1------- |Extension Indicator |No Extension | |-001---- |Nature of Address |International number | |----0001 |Numbering Plan Indicator |ISDN Telephony No plan (E.164) | |**b44*** |Roaming Address Signals |34607158032 | |1111---- |Filler |15 | |**b16*** |3.1.2.4 Length |EOC | |**b16*** |3 Length |EOC | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |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| | |

Initial Address Message (IAM) 17:20:54 014 ms Link: STP51<0<MSC107A BSN: 82 BIB: 1 FSN: 78 FIB: 1 LI: 63 SI: ISUP SSF: NN/R DPC: MAD103A OPC: MSC107A SLS: 8 CIC: 568 MT: IAM Nature of Connection Indicators Satellite Indicator: No satellite circuit in the connection Continuity Check Indicator: Not required Echo control Device Indicator: Outgoing half echo device included Forward Call Indicators National/International Call Indicator: National call End to End Method Indicator: No end-to-end method Interworking Indicator: No interworking encountered End to End Information Indicator: No end-to-end info available ISDN User Part Indicator: ISUP used all the way ISDN User Part Preference Indicator: ISUP not needed all the way ISDN Access Indicator: Originating access ISDN SCCP Method Indicator: No indication Calling Party's Category: Ordinary calling subscriber Transmission Medium Requirement: Speech

Appendix A

130

Pointer to Called Party Number: 2 octets Pointer to Optional Part: 12 octets Called Party Number Length: 10 octets Nature of Address Indicator: National (significant) number Odd/Even Indicator: Even number of address signals Numbering Plan Indicator: ISDN/Telephony Internal Network Number Indicator: Routing to INN not allowed Address Signal: c03100936627082f User Service Information Id Length: 3 octets Information Transfer Capability: Speech Coding Standard: CCITT standard Information Transfer Rate: 64 kbit/s Transfer Mode: Circuit mode Extension Indicator: Layer 1 Information User Information Layer 1 Protocol Id Recommendation : Rec. G.711 A-law Location Number Id Length: 10 octets Nature of Address Indicator: International number Odd/Even Indicator: Odd Screening Indicator: Network provided Numbering Plan Indicator: ISDN/Telephony Internal Network Number Indicator: Routing to INN not allowed Presentation Restriction Indicator: Presentation allowed Address Signal: 6071710416653 Generic Number Id Length: 8 octets Number Qualifier Indicator: Additional calling party number Nature of Address Indicator: National (significant) number Odd/Even Indicator: Odd Screening Indicator: Network provided Numbering Plan Indicator: ISDN/Telephony NI Indicator: Complete Presentation Restriction Indicator: Presentation allowed Address Signal: 610513304 Calling Party Number Id Length: 7 octets Nature of Address Indicator: National (significant) num Odd/Even Indicator: Odd Screening Indicator: Network provided Numbering Plan Indicator: ISDN/Telephony NI Indicator: Complete Presentation Restriction Indicator: Presentation allowed Address Signal: 610513304 Parameter Compatibility Information Id Length: 2 octets Upgraded Parameter: Location number Transit at Intermediate Exchange Indicator: Transit interpretation Release Call Indicator: Do not release call Send Notification Indicator: Do not send notification Discard Message Indicator: Do not discard message Discard Parameter Indicator: Do not discard parameter Pass on not possible Indicator: Discard parameter Extension Indicator: No extension End of Optional Parameters

Send Routing Info for Location (SRIfLCS)

Appendix A

131

+---------+---------------------------------------------+------------------------------------+---------------------------------+------------------+---------------------------+

|BITMASK |ID Name |Comment or Value |Value |BITMASK (1,2 bytes)|BITMASK (1 to 3 bytes) |

+---------+---------------------------------------------+------------------------------------+---------------------------------+------------------+---------------------------+

|12:11:11,546,517 1:C (Rx):15 MTP-L2 MSU SCCP UDT MAP BEG |

|MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) |

|Message Signal Unit |

|-1000100 |Backward Sequence Number |68 |68 |-1000100 |-1000100 |

|1------- |Backward Indicator Bit |1 |1 |1------- |1------- |

|-0010110 |Forward Sequence Number |22 |22 |-0010110 |-0010110 |

|1------- |Forward Indicator Bit |1 |1 |1------- |1------- |

|--111111 |Length Indicator |63 |63 |--111111 |--111111 |

|00------ |Spare |0 |0 |00------ |00------ |

|----0011 |Service Indicator |SCCP |3 |----0011 |----0011 |

|--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) |0 |--00---- |--00---- |

|11------ |Sub-Service: Network Ind |National message 1 |3 |11------ |11------ |

|**b14*** |Destination Point Code |3001 |3001 |--001011 10111001 |--001011 10111001 |

|**b14*** |Originating Point Code |152 |152 |**b12*** 00------ |----0000 00100110 00------ |

|ITU-T White Book SCCP (SCCP) UDT (= Unitdata) |

|Unitdata |

|1001---- |Signalling Link Selection |9 |9 |1001---- |1001---- |

|00001001 |SCCP Message Type |9 |9 |00001001 |00001001 |

|----0000 |Protocol Class |Class 0 |0 |----0000 |----0000 |

|1000---- |Message Handling |Return message on error |8 |1000---- |1000---- |

|00000011 |Pointer to parameter |3 |3 |00000011 |00000011 |



|Called address parameter |

|00001011 |Parameter Length |11 |11 |00001011 |00001011 |

|-------0 |Point Code Indicator |PC absent |0 |-------0 |-------0 |

|------1- |Subsystem No. Indicator |SSN present |1 |------1- |------1- |

|--0100-- |Global Title Indicator |Has transln,n-plan,code,natur |4 |--0100-- |--0100-- |

|-0------ |Routing Indicator |Route on Global Title |0 |-0------ |-0------ |

|0------- |For national use |0 |0 |0------- |0------- |

|00000110 |Subsystem number |HLR |6 |00000110 |00000110 |

|00000000 |Translation Type |Not used |0 |00000000 |00000000 |

|----0001 |Encoding Scheme |BCD, odd number of digits |1 |----0001 |----0001 |

|0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) |1 |0001---- |0001---- |

|-0000100 |Nat. of Address Indicator |International number |4 |-0000100 |-0000100 |

|1------- |Spare |- unknown / undefined - |1 |1------- |1------- |

|**b44*** |Called Address Signals |34607000037 |34607000037 |**b36*** 01000011 |**b28*** 00000110 01000011 |

|0000---- |Filler |0 |0 |0000---- |0000---- |

|Calling address parameter |

|00001011 |Parameter Length |11 |11 |00001011 |00001011 |

|-------0 |Point Code Indicator |PC absent |0 |-------0 |-------0 |

|------1- |Subsystem No. Indicator |SSN present |1 |------1- |------1- |

|--0100-- |Global Title Indicator |Has transln,n-plan,code,natur |4 |--0100-- |--0100-- |

|-0------ |Routing Indicator |Route on Global Title |0 |-0------ |-0------ |

|0------- |For national use |0 |0 |0------- |0------- |

|10010001 |Subsystem number |- unknown / undefined - |145 |10010001 |10010001 |

|00000000 |Translation Type |Not used |0 |00000000 |00000000 |

|----0001 |Encoding Scheme |BCD, odd number of digits |1 |----0001 |----0001 |

|0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) |1 |0001---- |0001---- |

Appendix A

132

|-0000100 |Nat. of Address Indicator |International number |4 |-0000100 |-0000100 |

|1------- |Spare |- unknown / undefined - |1 |1------- |1------- |

|**b44*** |Calling Address Signals |34607003990 |34607003990 |**b36*** 01000011 |**b28*** 00000110 01000011 |

|0000---- |Filler |0 |0 |0000---- |0000---- |

|Data parameter |

|01100011 |Parameter length |99 |99 |01100011 |01100011 |

|**B99*** |Data |62 61 48 04 00 be 00 00 6b 80 28 ...|62 61 48 04 00 be 00 00 6b 80 28 |01100010 **B98** |01100010 01100001 **B97** |

|E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) |

|--> DECODING ERROR: Parameter error (at position 26 hex) |

|Begin |

|01100010 |Tag |(APPL C [2]) |'62'H |01100010 |01100010 |

|01100001 |Length |97 |'48'H |01100001 |01100001 |

|1 Origination Transaction ID |

|01001000 |Tag |(APPL P [8]) |'48'H |01001000 |01001000 |

|00000100 |Length |4 |'00'H |00000100 |00000100 |

|***B4*** |Orig Trans ID |12451840 |12451840 |00000000 ***B3** |00000000 10111110 ***B2** |

|2 DialoguePortion |

|01101011 |Tag |(APPL C [11]) |'6b'H |01101011 |01101011 |

|10000000 |Length |EOC-encoded |'28'H |10000000 |10000000 |

|2.1 DialogueExternal |

|00101000 |Tag |(UNIV C External) |'28'H |00101000 |00101000 |


|2.1.1 DialogueObjectID |

|00000110 |Tag |(UNIV P Obj Identifier) |'06'H |00000110 |00000110 |

|00000111 |Length |7 |'00'H |00000111 |00000111 |

|00000000 |Authority |CCITT Recommendation |0 |00000000 |00000000 |

|00010001 |Name Form |q |17 |00010001 |00010001 |

|10000110 |Rec Number |7 |134 |10000110 |10000110 |

|00000101 |Rec Number |73 |5 |00000101 |00000101 |

|00000001 |AS |1 |1 |00000001 |00000001 |

|00000001 |Dialog-AS |Dialogue PDU |1 |00000001 |00000001 |

|00000001 |Version |1 |1 |00000001 |00000001 |

|2.1.2 DialoguesingleASN1 |

|10100000 |Tag |(CONT C [0]) |'a0'H |10100000 |10100000 |


|2.1.2.1 DialogueRequest |

|01100000 |Tag |(APPL C [0]) |'60'H |01100000 |01100000 |


|2.1.2.1.1 Protocol Version |

|10000000 |Tag |(CONT P [0]) |'80'H |10000000 |10000000 |

|00000010 |Length |2 |'07'H |00000010 |00000010 |

|00000111 |UnusedBits |7 |7 |00000111 |00000111 |

|1------- |Version 1 |Yes |1 |1------- |1------- |

|-0000000 |Filler |0 |0 |-0000000 |-0000000 |

|2.1.2.1.2 Application Context Name |

|10100001 |Tag |(CONT C [1]) |'a1'H |10100001 |10100001 |


|2.1.2.1.2.1 ACN Object Id |


|00000111 |Length |7 |'04'H |00000111 |00000111 |

|0000---- |ObjId |CCITT |0 |0000---- |0000---- |

|----0100 |Organization |Identified-organization |4 |----0100 |----0100 |

Appendix A

133

|00000000 | |ETSI |0 |00000000 |00000000 |

|00000000 |Domain |Mobile Domain |0 |00000000 |00000000 |

|00000001 |Mobile Subdomain |GSM-Network |1 |00000001 |00000001 |

|00000000 |Common Component ID |AC-ID |0 |00000000 |00000000 |

|00100101 |Application Context |- unknown / undefined - |37 |00100101 |00100101 |

|00000011 |Version |Version3 |3 |00000011 |00000011 |

|***B2*** |2 Length |EOC |'0000'H |00000000 00000000 |00000000 00000000 |

|2.1.2.1.3 User Info |

|10111110 |Tag |(CONT C [30]) |'be'H |10111110 |10111110 |

|00001111 |Length |15 |'28'H |00001111 |00001111 |

|2.1.2.1.3.1 User Info External |

|00101000 |Tag |(UNIV C External) |'28'H |00101000 |00101000 |

|00001101 |Length |13 |'06'H |00001101 |00001101 |

|2.1.2.1.3.1.1 User Info Object ID |


|00000111 |Length |7 |'04'H |00000111 |00000111 |

|0000---- |ObjId |CCITT |0 |0000---- |0000---- |

|----0100 |Organization |Identified-organization |4 |----0100 |----0100 |

|00000000 | |ETSI |0 |00000000 |00000000 |

|00000000 |Domain |Mobile Domain |0 |00000000 |00000000 |

|00000001 |Mobile Subdomain |GSM-Network |1 |00000001 |00000001 |

|00000001 |Common Component ID |AS-ID |1 |00000001 |00000001 |

|00000001 |AS-ID Branch |Map-Dialogue PDU |1 |00000001 |00000001 |

|00000001 |AS Version |1 |1 |00000001 |00000001 |

|2.1.2.1.3.1.2 User Info single ASN1 |

|10100000 |Tag |(CONT C [0]) |'a0'H |10100000 |10100000 |

|00000010 |Length |2 |'a0'H |00000010 |00000010 |

|2.1.2.1.3.1.2.1 MAP-open |

|10100000 |Tag |(CONT C [0]) |'a0'H |10100000 |10100000 |

|00000000 |Length |0 |'00'H |00000000 |00000000 |

|***B2*** |2 Length |EOC |'0000'H |00000000 00000000 |00000000 00000000 |

|***B2*** |2 Length |EOC |'0000'H |00000000 00000000 |00000000 00000000 |

|***B2*** |2 Length |EOC |'0000'H |00000000 00000000 |00000000 00000000 |

|***B2*** |2 Length |EOC |'0000'H |00000000 00000000 |00000000 00000000 |

|3 Component Portion |

|01101100 |Tag |(APPL C [12]) |'6c'H |01101100 |01101100 |

|00011110 |Length |30 |'a1'H |00011110 |00011110 |

|3.1 Invoke |

|10100001 |Tag |(CONT C [1]) |'a1'H |10100001 |10100001 |

|00011100 |Length |28 |'02'H |00011100 |00011100 |

|3.1.1 Invoke ID |

|00000010 |Tag |(UNIV P Integer) |'02'H |00000010 |00000010 |

|00000001 |Length |1 |'00'H |00000001 |00000001 |

|00000000 |Invoke ID value |0 |0 |00000000 |00000000 |

|3.1.2 Local Operation |

|00000010 |Tag |(UNIV P Integer) |'02'H |00000010 |00000010 |

|00000001 |Length |1 |'55'H |00000001 |00000001 |

|01010101 |Operation Code |- unknown / undefined - |85 |01010101 |01010101 |

|3.1.3 Parameter Sequence |

|00110000 |Tag |(UNIV C Sequence (of)) |'30'H |00110000 |00110000 |

|00010100 |Length |20 |'80'H |00010100 |00010100 |

|3.1.3.1 Unknown Parameter |

Appendix A

134

|10000000 |Tag |(CONT P [0]) |'80'H |10000000 |10000000 |

|00000111 |Length |7 |'91'H |00000111 |00000111 |

|***B7*** |Contents |91 43 06 07 30 99 f0 |91 43 06 07 30 99 f0 |10010001 ***B6** |10010001 01000011 ***B5** |

|3.1.3.2 Unknown Parameter |

|10100001 |Tag |(CONT C [1]) |'a1'H |10100001 |10100001 |

|00001001 |Length |9 |'81'H |00001001 |00001001 |

|***B9*** |Contents |81 07 91 43 06 07 00 30 f7 |81 07 91 43 06 07 00 30 f7 |10000001 ***B8** |10000001 00000111 ***B7** |

Appendix B

135

Appendix B This appendix is an example implementation of the SRN node by a fictitious network operator. The network operator has today 10 million clients and the country where it operates has a population of 40 million and a 10 population growth prediction of 2,5 million.

[Req 3] The subscriber table will allow at least 50 million entries as long as the rest of the tables are of negligible size in comparison. The database size is constrained by the 8 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.

• 400 kbps for each connection from a client to the server.

[Req 5] The SRN application will be able to handle a maximum of 4000 messages of 129 byte length per second with 128 links loaded to full capacity and using 80% of the CPU load of the host machine.

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 128 links loaded to full capacity, and the typical transaction rate with the links loaded to only 40% capacity.

Message Dist. Typ. Size (bytes/bits)

TPS with 1 link

TPS with 128 links

TPS at 40% Capacity

UL 9% 130/1040 62 7877 3151

GPRS UL 5% 120/960 67 8533 3413

SRI 27% 120/960 67 8533 3413

SRIfSM 39% 140/1120 57 7314 2926

ATI 5% 150/1200 53 6827 2731

SAI 10% 110/880 73 9309 3724

SRIfLCS 2% 130/1040 62 7877 3151

SendIMSI 3% 120/960 67 8533 3413

Weighted Average

100% 129/1035 62 7913 3165

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

Appendix B

136

[Req 6] The following list summarizes the different tables that will exist in the system and the maximum number of entries.

Table Depth Description

SUBSCRIBER 50 000 000 Contains the MSISDN, IMSI, HLR and the associated NRN. Determines if an MSISDN or IMSI is an imported or own subscriber or not.

HLRLOCATION 1 000 Contains the possible HLRs and routing data associated.

NETWORK 1 000 Contains the possible NRNs.

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.

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

MGTTRANSLATION 128 Contains the data necessary to translate an MGT to an IMSI.

Appendix B

137

LOCAL 50 Contains the hostnames of the SRN and particular parameters associated, like the Global Title

[Req 99] The log shall have a fixed size of 400 MB58.

[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 200 000 operation/hour

58 10 year log of 400 000 ported numbers per year which generates 100 byte log events results in a 400 MB log.

Budget

138

Budget This chapter calculates a total cost estimate for the research and development of this master thesis. The budget is one of the requirements on a proyecto fin de carrera presented by Universidad Politécnica de Madrid.

Man hours The total time invested in this master thesis was 6 man months which can be divided into the following categories.

Category Task Hours

Theoretical Preparation Study of GSM/UMTS literature on the MNP and FA subjects

150

Team work on the internal Vodafone project

150

Development of SRN node model

Problem definition 60

Deduction and research of traffic cases

160

SRN node definition 120

Composition of master thesis document

composition 400

Total man hours 1040

The cost for this time may be calculated by multiplying these hours by an hourly professional pay of 60 €. In this way the cost for man hours is

• 62400 €

Material costs The material used to produce this master thesis can be found in the table below.

Material Time of usage Price Time of amortization

Cost

PC (including monitor, keyboard, mouse)

6 months 1000 € 4 years 125 €

Microsoft Windows 2000

6 months 300 € 3 years 50 €

Budget

139

Microsoft Office 2000 6 months 480 € 3 years 80 €

Printer 6 months 240 € 6 years 20 €

Office material and binding

100 € 100 €

Total material cost 375 €

Total cost Total cost for man hours 62400 €

Total material cost 375 €

Subtotal 62775 €

VAT (16 %) 10044 €

Total cost 72819 €

The cost estimate of the presented master thesis adds up to SEVENTYTWO THOUSAND EIGHT HUNDRED NINETEEN euros.

Madrid, April 2004

Pär Kragsterman

152956_50a95_statya_1_umts_gsm

Documents

kungliga tekniska

ley orgnica

3gpp organizational

signalling

orig trans

loc info retrieval

backward indicator

forward indicator