50A95 Statya 1 Umts GSM

Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network
PAR KRAGSTERMAN
Masters Degree Project Stockholm, Sweden 2004-10-04
IR-SB-EX-0429
Proyecto fin de carrera
Ttulo: Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network Autor: Pr Kragsterman Tutor: Rubn Echarri de Esteban Ponente UPM: Ana Beln Garca Hernando Ponente KTH: George Jngren
Composicin del tribunal
Presidente: Enrique Vzquez Gallo
Vocal: Manuel lvarez-Campana Fernndez-Corredor
Secretaria: Ana Beln Garca Hernando
Suplente: David Fernndez Cambronero
Fecha de presentacin: Calificacin:
Universidad Politcnica de Madrid
Kungliga Tekniska Hgskolan
Escuela Tcnica Superior de Ingenieros de Telecomunicacin
Proyecto fin de carrera
Solution for Mobile Number Portability and Flexible Allocation in a GSM/UMTS Network
Pr Kragsterman Mayo 2004
Abstract / Keywords
Abstract
The present document resolves in a joint manner the two GSM/UMTS network functions Mobile Number Portability (MNP) and Flexible Allocation (FA). MNP is the possibility for a subscriber of a service provider to change to a new service provider bringing his telephone number with him. FA on the other hand is the possibility for a network operator to allocate an arbitrary subscriber identifier (IMSI) and telephone number in any of its subscriber databases (HLR). The solution presented is the Signaling Relay Node (SRN). The SRN redirects all signaling messages in the operator network that needs to reach an own or foreign subscriber database based on the subscriber identifier or telephone number, therefore subject to MNP and/or FA, to its appropriate destination. This redirection is performed in all cases except when the incoming signaling message is a call routing information request (MAP SRI) for an exported or foreign telephone number, where the SRN replies directly to the requesting node providing routing information (SRI_ack) to the destination network. The SRNs decision on where to reroute, is based on the incoming signaling messages 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
Brief Summary in Spanish

Introduccin
La especificacin de GSM/UMTS asigna un nico Home Location Register (HLR) lgico a cada operadora de comunicaciones mviles GSM/UMTS. Obviamente, y debido al volumen de clientes que tienen las redes mviles es imposible encontrar una plataforma fsica que pueda contener al HLR lgico asignado a cada operadora mvil. Por ese motivo, se divide el HLR asignado a la operadora en varios nodos fsicos. Esa divisin se hace mediante configuraciones estticas en los nodos de la red mvil de forma que se asignan rangos de International Mobile Subscriber Identities (IMSI) a cada HLR fsico. El HLR es la base de datos en la red que almacena la informacin del perfil de suscripcin del cliente, cierta informacin dinmica como son los desvos, la informacin sobre la ubicacin del abonado (a nivel Visitor Location Register (VLR)) y el Mobile Station ISDN Number (MSISDN) del cliente (nmero pblico 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 mquina fsica. Esta asignacin tambin es esttica. Al tener una relacin esttica entre rangos de IMSIs, rangos de MSISDNs y HLR fsico, las operadoras mviles 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 fsico que se den en la red para cambios de SIMs a los clientes. Para las operadoras mviles esto es un problema logstico de primera magnitud que puede incidir en la satisfaccin y en la calidad del servicio que ofrece el operador mvil, por lo que surge la necesidad de encontrar una forma de asignacin flexible (FA) de los IMSIs y MSISDNs dentro de los HLRs fsicos que tiene la operadora. Este problema se ve agravado con la introduccin de la portabilidad numrica mvil (MNP) por la cual el operador mvil puede tener clientes en cualquier rango de numeracin mvil dentro del dominio de portabilidad numrica. El MNP consiste en que un abonado de un proveedor de servicio de telefona mvil pueda cambiar de proveedor de servicio sin cambiar de MSISDN. MNP ha surgido debido a legislacin a nivel europeo y espaol con el fin de permitir que el abonado final se beneficie de las ventajas surgidas de la libre competencia entre operadores sin ningn perjuicio. El FA consiste en la posibilidad de registrar cualquier IMSI&MSISDN independientemente de su rango, en cualquier HLR fsico en una red, lo que permite una mejorar sustancia en la gestin del stock de tarjetas SIM y de la capacidad de los HLRs. Tecnolgicamente, las soluciones para MNP y FA estn estrechamente relacionados. Si un operador quiere resolver uno de los dos problemas puede, sin mucho esfuerzo adicional, resolver los dos.
El Signaling Relay Node (SRN)

La solucin 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 fsicos (propios o de otra red) con el Called Party Address (CdPA) rellenado con un MGT o MSISDN. La intercepcin se hace va reenrutamientos en los STPs del operador mvil. Una vez que el mensaje ha llegado al SRN, este comprueba que tipo de mensaje es y a base de esta comprobacin toma una decisin 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 informacin 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 interconexin El SRN re-enruta el mensaje hacia su correspondiente HLR sin tocar el contenido del mensaje MAP ni el CgPA del nivel SCCP.
Especificacin Tcnica del SRN

El SRN est basado en los siguientes mdulos de software y hardware por encima de cuales se implementa la aplicacin MNP/FA. Los mdulos no se especifican ms que esto como son muy dependientes del ambiente de implantacin del operador. Un mdulo software que proporciona las bases de datos, con un interfaz de provisioning. Un mdulo software que proporciona el sistema de alarmas Un mdulo software que proporciona la sealizacin MAP
Una plataforma hardware y software por encima de cual opera el nodo SRN, que proporciona la sealizacin MTP y SCCP
La solucin no toma en cuenta la replicacin del nodo para proporcionar redundancia. Este documento luego proporciona todos los requisitos no funcionales, funcionales, de sealizacin, 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 informacin 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 parmetros de configuracin del nodo SRN. FLAGS Contiene los parmetro de configuracin 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 parmetros particulares al nodo como por ejemplo el Global Title (GT).
Los procedimientos de bsqueda en las tablas SUBSCRIBER a partir del IMSI o MSISDN se describe en detalle. Esto tambin se hace para los procedimientos de combinacin del NRN y MSISDN y la traduccin del MGT a IMSI. En cuanto a los requisitos de procesamiento MAP se describe como acta el nodo frente cada uno de los mensajes MAP que le puede llegar. Se especifica cuales son las estadsticas que llevar el nodo SRN.
3
Se especifica cuales son las alarmas que har saltar el nodo SRN. Finalmente se hace una especificacin sobre que operaciones debe soportar el sistema de provisioning.
Foreword
Foreword
This document supposes that the reader has basic knowledge on GSM/UMTS networks as well as the three networking protocols MTP, SCCP and MAP. A reader who has good knowledge of these technologies may not want to read the two initial chapters since these are aimed towards a less experienced audience. The present document is intended to serve as a public master thesis for the Telecommunication Engineering career at Universidad Politcnica de Madrid (UPM) in Madrid, Spain and the Master of Science in Electrical Engineering at Kungliga Tekniska Hgskolan (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
Contents
1
1.1 1.2 1.3
Introduction________________________________________ 10
Short background ____________________________________________ 10 Work done __________________________________________________ 11 Outline _____________________________________________________ 12
2
2.1 2.2
Introduction to GSM/UMTS networks __________________ 13

Simplified problem scenario____________________________________ 13 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 Traffic cases _________________________________________________ 2.3.1 Normal Location Updating (LU) _____________________________ 2.3.2 GPRS Attach _____________________________________________ 2.3.3 Call to mobile subscriber ___________________________________ 2.3.4 Short message to a MS _____________________________________ 2.3.5 Intelligent Network (IN) request for subscriber information ________ 2.3.6 Location information request by a location application ____________ 2.3.7 Short message from a MS with policing based on subscriber IMSI ___ Protocol stack Signaling System number 7 (SS7)___________________ 2.4.2 MTP ___________________________________________________ 2.4.3 SCCP ___________________________________________________ 2.4.4 TCAP __________________________________________________ 2.4.5 MAP ___________________________________________________ 25 25 27 28 30 30 31 32 33 34 34 36 36
2.3
2.4
3
3.1 3.2
Introduction to Mobile Number Portability (MNP) _______ 39

Reasons to introduce MNP_____________________________________ 39 MNP technical network specification ____________________________ 3.2.1 Indirect routing case: Consult the number range owner network _____ 3.2.2 Direct routing case: Consult the originating network ______________ 3.2.3 Signaling messages for MNP in call oriented cases _______________ 3.2.4 Signaling messages for MNP in not call oriented cases ____________ 40 40 41 42 43
3.3
NRN assignments in Spain _____________________________________ 44
4 5
Introduction to Flexible Allocation (FA)_________________ 45 MNP/FA solution____________________________________ 47
Contents
5.1 5.2 5.3
FA requisites to a solution _____________________________________ 47 MNP requisites to a solution ___________________________________ 48 Joint requisites to a solution____________________________________ 49
6
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16
The Signaling Relay Node (SRN) in action _______________ 50

Flexible Allocation (FA) only, for Location updates and Send Authentication Info (SAI) messages _____________________________ 50 Send Routing Info (SRI) containing an imported or own MSISDN____ 52 Send Routing Info (SRI) containing an exported or foreign MSISDN _ 53 Send Routing Info (SRI) containing an imported or own MSISDN from an interconnecting call ________________________________________ 55 Send Routing Info for Short Message (SRIfSM) containing an imported or own MSISDN _____________________________________________ 57 Send Routing Info for Short Message (SRIfSM) containing an exported or foreign MSISDN ___________________________________________ 59 Send Routing Info for Short Message (SRIfSM) containing an imported or own MSISDN received in interconnection ______________________ 60 Any Time Interrogation (ATI) containing an imported or own MSISDN ____________________________________________________________ 62 Any Time Interrogation (ATI) containing an exported or foreign MSISDN ____________________________________________________ 64 Any Time Interrogation (ATI) containing an imported or own MSISDN received in interconnection_____________________________________ 66 Send Routing Info for Location (SRIfLCS) containing an imported or own MSISDN ________________________________________________ 67 Send Routing Info for Location (SRIfLCS) containing an exported or foreign MSISDN _____________________________________________ 69 Send Routing Info for Location (SRIfLCS) containing an imported or own MSISDN received in interconnection ________________________ 71 SendIMSI containing an imported or own MSISDN________________ 73 SendIMSI containing an exported or foreign MSISDN _____________ 75 SendIMSI containing an imported or own MSISDN received in interconnection ______________________________________________ 76
7
7.1 7.2 7.3
The SRN technical specification _______________________ 79

Proposed solution ____________________________________________ 79 Non-functional requirements ___________________________________ 79 Functional requirements ______________________________________ 7.3.1 Service subscribers data ____________________________________ 7.3.1.1 SUBSCRIBER table _____________________________________ 7.3.1.2 Database search procedure ________________________________ 7.3.2 Service configuration data___________________________________ 80 82 82 83 84
7
Contents
7.3.2.1 7.3.2.2 7.3.2.3 7.3.2.4 7.3.2.5 7.3.2.6 7.3.2.7 7.3.2.8 7.3.2.9 7.3.2.10 7.3.2.11 7.4
Configuration parameter tables _____________________________ HLRLOCATION table ___________________________________ NETWORK table _______________________________________ MSISDNNORMALIZATION table _________________________ MSISDN normalization procedure __________________________ COMBINATION table ___________________________________ Combination procedure___________________________________ MGTTRANSLATION table _______________________________ MGT-IMSI translation procedure ___________________________ TCAPERRORCODES table _____________________________ LOCAL table_________________________________________
85 86 86 87 88 89 90 91 92 92 93 93 93 96 97 97 98 98 98 98 99
Signaling____________________________________________________ 7.4.1 General _________________________________________________ 7.4.2 MAP processing __________________________________________ 7.4.2.1 MSISDN processing _____________________________________ 7.4.2.2 Foreign MSISDN SRI processing___________________________ 7.4.2.3 Foreign MSISDN non SRI processing _______________________ 7.4.2.4 MSISDN not found ______________________________________ 7.4.2.5 NRN Database mismatch ________________________________ 7.4.2.6 IMSI processing ________________________________________ 7.4.2.7 IMSI not found _________________________________________ Statistics ___________________________________________________ 7.5.1 Counters _______________________________________________ 7.5.1.1 SS7 stack counters _____________________________________ 7.5.1.2 Operating system counters _______________________________ 7.5.1.3 Service logic counters ___________________________________
7.5
101 101 101 101 101
7.6
Alarms ____________________________________________________ 103 7.6.1 MNP/FA application alarms ________________________________ 103 7.6.2 SRN node alarms ________________________________________ 103 Provisioning system__________________________________________ 103 7.7.1 Provisioning system log ___________________________________ 104 7.7.2 Provisioning interface performance issues _____________________ 105
7.7
8
8.1 8.2
Conclusions and future work _________________________ 106

Conclusions ________________________________________________ 106 Future work ________________________________________________ 107
9
9.1 9.2 9.3
Definitions, abbreviations and symbols_________________ 108

Definitions _________________________________________________ 108 Abbreviations_______________________________________________ 109 Symbols ___________________________________________________ 112
10
References ________________________________________ 115
Appendix A ______________________________________________ 117

Update Location (UL) ______________________________________________ 117 GPRS Update Location (GPRS UL) __________________________________ 118
Contents
Send Routing Info (SRI) ____________________________________________ 120 Send Routing Info for Short Message (SRIfSM) ________________________ 122 Any Time Interrogation (ATI)_______________________________________ 124 Send Authentication Info (SAI) ______________________________________ 126 Send Routing Info acknowledgement (SRI_ack) ________________________ 128 Initial Address Message (IAM) ______________________________________ 129 Send Routing Info for Location (SRIfLCS) ____________________________ 130
Appendix B ______________________________________________ 135
1 Introduction
1
1.1
Introduction
Short Background
In the original Global System for Mobile Communications (GSM) specification there is only one subscriber database, also called the Home Location Register (HLR), assigned to every network operator. Obviously, due to the great initial growth of the GSM networks it soon became impossible to find a physical platform which could support the great number of subscribers. This extraordinary initial growth was the reason why the subscriber database had to be divided in various physical platforms. The division was done via static configurations where a certain range of subscribers were assigned to a specific physical subscriber database. The static assignment made sure that the rest of the network nodes easily would know where the information of a certain subscriber was stored. The subscriber database or HLR is the database which stores the subscriber profile information, certain dynamic information such as the call forwarding settings, the information about where the subscriber currently is located and its telephone number. The subscriber database may be interrogated about a subscriber based on both the subscribers telephone number and a special subscriber identifier called the International Mobile Subscriber Identity (IMSI). The static allocation of subscribers in the physical subscriber databases creates various problems for the network operators. One of the most costly problems that arises is the fact that every sales point of the network operator has to maintain a stock of Subscriber Identity Modules (SIM), commonly know as SIM cards, for every physical subscriber database in the operator network. Lets look at an example to explain this problem. A subscriber has lost his mobile phone including the SIM card. He addresses one of the operator sales points to get a new phone and more importantly a new SIM card with the same phone number as before. Since every SIM card has a unique subscriber identifier, the IMSI, which in turn is dependent on in which subscriber database the subscriber is allocated, the subscriber must be given a new SIM card which corresponds to its subscriber database. Therefore the sales point must maintain a stock of SIM cards for every possible subscriber database in the operator network.
The above situation becomes even more difficult since the introduction of the so called Mobile Number Portability (MNP). MNP is when a subscriber may change network operator without changing its telephone number. MNP has surged because of European and Spanish legislation. The goal of this legislation is to raise the level of competition between network operators by lowering the barrier for a subscriber to switch network operator. The fact that it is possible to bring ones telephone number along when switching network operator makes the situation with the statically assigned subscriber databases unstable since these new imported telephone numbers may be of any range and will not be covered by the default allocation. This thesis is aimed to resolve these two problems in a joint manner by introducing two new functionalities in the operator network. The first one is MNP which has already been described and the second one is called Flexible Allocation (FA). FA is, as the
10
1 Introduction
name indicates, a way to dynamically allocate subscribers in any subscriber database. FA allows any subscriber to be allocated in any subscriber database in order to allow these to be used more efficiently.
1.2
Work Done
Solutions to MNP have been implemented in many operator networks since legislation to support this functionality was passed in many European countries during 2000 and 2001. To the best of our knowledge, a few network operators also support FA. Since these two functionalities seen from a technical point of view are very similar this master thesis is aimed to resolve both in a joint manner something which in my knowledge has not been done before. The master thesis is based on an internal project at Vodafone Spain to implement the FA functionality in their network. I have thereafter continued the research to extend the solution by adding support for MNP as well. To be able to do this some of my sources [4], [6], [8], [20] are specifications of either MNP or FA functionality nodes or functionality specifications. As part of the team developing the FA functionality for Vodafone Spain we have studied the possible approaches to a solution. The steps of the Vodafone Spain project were 1. Define the problem 2. Isolate possible approaches to a solution 3. Deduce pros and cons of each approach 4. Choose the most appropriate approach to a solution 5. Study in-depth the chosen approach and deduce all possible traffic cases 6. Produce the node specification Once the FA functionality had reached this level of maturity I considered it an appropriate moment to fork of my own research of the dual MNP/FA functionality. The solution I present is sufficiently flexible to include all approaches considered by the internal Vodafone project and therefore does not contain much discussion concerning this choice. I wanted the solution to be sufficiently flexible to be of use for almost any network operator that would like to implement the two functionalities in my joint manner. My own work may be considered as a repetition of steps 1, 4, 5 and 6 but for the joint MNP/FA functionality. The main part of my work has been defining the problem when the two functionalities MNP and FA are presented as one, study what requirements this approach generates and finally propose a solution in the shape of a new network node.
11
1 Introduction
1.3
Outline
First of all the reader is introduced to all the GSM and Universal Mobile Telecommunications System (UMTS) nodes which will be of importance during the discussions in the rest of the document. This is the first part of Chapter 2 Introduction to GSM/UMTS Networks which is followed by an introduction to the traffic scenarios in which our solution will be implicated. The chapter ends with an introduction to the network protocols needed for the discussion of MNP and FA. Chapter 3 Introduction to Mobile Number Portability (MNP) and 4 Introduction to Flexible Allocation (FA) are detailed introductions to the MNP and FA functionalities. In these chapters, reasons to why they are implemented as well as their technical specifications are discussed. Chapter 5 MNP/FA solution look at the requirements of the two functionalities. At first, each one on its own and then the two of them together. Next we take a deeper look at the traffic cases in which our solution is implicated. Since we then have the basic knowledge of what the node is supposed to do we may examine its actions case by case. The requirements of the node tells us which these cases are. All of this is described in Chapter 6 The Signaling Relay Node (SRN) in Action. Finally Chapter 7 The SRN technical specification, specifies how our solution is implemented on top of a hardware and software platform.
12
2 Introduction to GSM/UMTS networks
Introduction to GSM/UMTS Networks
This first chapter will be quite general and aims to provide the basic technical foundations of Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) technologies. The chapter explains all the concepts needed to be able to follow the discussion through the rest of this thesis. Therefore, the present chapter should not be considered an overview of the GSM and UMTS technologies since information not relevant to the scope of this document is omitted. A reader already experienced with the GSM and UMTS technologies may skip ahead to the next chapter. Most of the nodes in the UMTS networks have the same or very similar functionality as their predecessors in GSM networks. Throughout the rest of this document when we talk about these nodes their UMTS name will be used even though we mean the concept node in both technologies. If we want to discuss a concept node for one technology in particular, their appropriate name will be used and the fact that the discussion only applies to one technology will be pointed out. First of all we take a simplified look at the whole problem scenario to provide some basic understanding of how a GSM/UMTS network works. Then we take a look at the nodes of the GSM/UMTS network. After that a couple of relevant traffic cases are discussed and finally we look at relevant network protocols. Since there are so many abbreviations in GSM/UMTS terminology a complete list of all abbreviations used in this document can be found in Chapter 9.2.
2.1
A Simplified Problem Scenario
First of all we will provide a very simple, easily understood and overlooking picture of the basic problematic scenarios omitting, without falsifying, most detail. First of all lets take a look at an operator network without and with the Flexible Allocation (FA) functionality. In any GSM/UMTS network there is a lot of signaling traffic which nowadays is totally separated from the regular voice traffic. The signaling is needed managing the calls and the subscribers, e.g. how to route a call to a mobile telephone which we do not know where it is. The signaling traffic is routed on its own routes and has its own routers. The routers know where to route the signaling traffic in every possible scenario which sometimes even include routing messages without an destination address. These messages are then routed based on what telephone number they are carrying and what type of service they provide. Without FA some signaling traffic within the network has to find the subscriber databases (which we will call Home Location Register (HLR) from now on) based on static defined routing. These static routing decisions are performed in the network signaling routers (which we will call Signaling Transfer Point (STP) from now on). The routing decision is based on either the subscribers telephone number or a specific subscriber identifier. Figure 2.1 illustrates this scenario. This static decision results in that a specific subscriber always has to be stored in a specific HLR.
13
Static routing decision
HLR 1
STP
HLR 2
HLR n
Figure 2.1 The STP has to take a static routing decision when routing traffic to the HLRs in a network without FA.
One scenario requiring this signaling message routing is when a call has to be routed to a mobile telephone. The above presented message is necessary since the HLR is the only node in the network that knows where the mobile phone is. The above message is therefore the petition to the HLR asking it to provide the routing information to reach the mobile telephone. Once FA has been introduced into the same GSM/UMTS network the same decision will be taken dynamically by the new functionality. The new scenario is illustrated in Figure 2.2. The new FA functionality allows a specific subscriber to be stored in any of the available HLRs.
... ...
14
Dynamic routing decision
HLR 1
SRN
HLR 2
HLR n
Figure 2.2 The FA functionality here shown as a node (SRN) takes a dynamic routing decision when routing signaling traffic to the HLRs in a network with FA.
Now lets take a look at the Mobile Number Portability (MNP) functionality which is closely related technically with FA even if it at a first glance might not seem that way. MNP allows the subscriber to bring his/her telephone number (which we will call Mobile Station Integrated Services Digital Network number (MSISDN) from now on) along when changing network operator, i.e. export the MSISDN. In the same way as FA decides to which HLR the signaling traffic shall be routed, the MNP functionality has to decide whether or not the MSISDN is an own or exported number. The introduction of MNP results in that some signaling for a mobile subscriber will depend on both the donor and the recipient network. Exactly what signaling this is will become clear in Chapter 6. We illustrate this in Figure 2.3.
... ...
15
Dynamic routing decision Signaling message from a network node, e.g. MAP SRI SRN
HLR n
Another Network Operator
Figure 2.3 The MNP functionality here shown as a node (SRN) takes a dynamic decision whether or not the signaling message belongs to the own network of if the MSISDN which it concerns has been exported.
One scenario requiring this signaling message routing is for example when we want to send a short message to a mobile telephone which MSISDN has been exported to another network operator. The message which needs to reach the HLR, asks the HLR how to route the short message in order for it to finally reach the mobile telephone. Since the MSISDN may be exported and thus the HLR would be located in a foreign network, the MNP functionality may have to route this message directly towards an external network. Now when we have seen the basic problem scenario we should look at the network nodes which are involved in the signaling traffic which causes these situations. It is not very important to know every little detail about every node but rather what the different nodes do in a conceptual manner.
2.2
Network Nodes
GSM/UMTS networks are divided into two major subsystems. These are the Radio Network Subsystem (RNS) which is responsible for the radio communications with the Mobile Stations (MS) and the Network and Switching Subsystem (NSS) which includes the functions of switching traffic and signaling and also storing subscriber data. The GSM equivalent to the RNS is the Base Stations Subsystem (BSS). For the scope of this document we may say that the functionality and responsibility of the BSS are equivalent to those of the RNS.
16
Finally there is of course also the MS which consists of Mobile Equipment (ME) such as a hand portable or a vehicle mounted unit. Subscriber Identity Module (SIM), which contains the entire customer related information (identification, secret key for authentication, etc.)
Figure 2.4 shows a schematic view of a GSM/UMTS network. The nodes that we will discuss are shown in the figure. In the NSS only signaling links are marked to improve visibility.
17
HLR/AuC
SCP
GMLC STP
NSS
GGS N SGSN
UMSC/ VLR SMSC
RNS RNC
Node B
Node B
MS
Figure 2.4 View of the GSM/UMTS network.
2.2.2 Node B and Radio Network Controller (RNC)

Both the Node B and the RNC are parts of the RNS. This subsystem is responsible for the direct contact with the MS through the radio interface and is also in contact with the switches of the NSS through the RNC. The Node B is the node which is in direct contact with the MS through the radio interface.
18
The RNC is the node which is in contact with the switches of the NSS. For the scope of this document, we do not need to go into more details of how the Node B and RNC work as long as we have grasped the concept that the RNS is responsible for the transportation of traffic and signaling between the NSS and the MS. Figure 2.5 illustrates this concept. The nodes in the NSS will be discussed in the next chapter and on. The Base Transceiver Station (BTS) and the Base Station Controller (BSC) are the equivalent of the Node B and the RNC in GSM terminology. The BTS and the BSC together compose the BSS which is equivalent to the RNS in UMTS terminology. For the scope of this document we may say that the functionality and responsibility of the BSS is equivalent to those of the RNS.
Node B Node B
MS
Node B RNS
RNC
UMSC/ VLR NSS
Figure 2.5 The RNS is responsible for the transportation of traffic between the NSS and the MS.
2.2.3 UMTS Mobile Service Switching Center (UMSC) and Visitor Location Register (VLR)
The UMSC is the first node we discuss within the NSS. The UMSC has a long list of responsibilities but we will only discuss a single one which is relevant to the scope of this document. The UMSCs 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/VLRs position in the network. The UMSC performs the telephony switching functions of the GSM/UMTS circuitswitched system, like the Service GPRS Support Node (SGSN, which we discuss in Chapter 2.2.6) switches the GSM/UMTS packet-switched traffic. The UMSC controls calls to and from other telephony and data systems, such as the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), Public Land Mobile Network (PLMN), Public Data Networks and possibly some private networks. The VLR is usually combined in the same piece of hardware as the UMSC. But even though they might be hosted in the same node they function logically as two separate entities and communicate with each other in exactly the same way as if they would have been physically separated. The VLRs main functions is to record a subscribers presence in its Service Area (SA) and download the subscriber data from the HLR. This
19
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 MSs change in location to the HLR and also requests and stores data about the MS. If the MS makes a call at another time, the VLR will then already have the information needed for that call setup.
RNC
UMSC/ VLR
HLR
Figure 2.6 A view of the UMSC/VLRs 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/AuCs position in the network. The HLR contains three main types of data. 1. Non permanent data concerning the subscriber which the subscriber can modify, e.g. call forwarding settings. 2. Permanent data concerning the subscribers contracted services, e.g. data call settings.
20
3. Non permanent data concerning the subscribers location. These data specifies in which VLR and SGSN the subscriber is located at the moment. This documents aim to resolve an addressing issue that arises when one physical HLR no longer is sufficient for storing and serving the data of all subscribers in one GSM/UMTS network. But for now we will concentrate on the introduction to GSM/UMTS network nodes. The AuC is the database that manages security data for the authentication of subscribers. It also produces the data necessary for the encryption of the radio interface between the MS and the Node B. Within the encryption data an authentication triplet is contained. The AuC does not necessarily share the same piece of hardware as the HLR and may be located separately. The two nodes, in either case, function logically as two separate entities and communicate with each other in exactly the same way as if they would have been physically separated.
HLR/AuC
UMSC/ VLR
SGSN
Figure 2.7 A view of the HLR/AuCs 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 n7 (SS7) protocols. This signaling network enables cooperative interworking between NSS machines within one or several GSM networks. The STP is the switching equipment for all signaling traffic between nodes in the GSM/UMTS network. Figure 2.8 gives us a good picture of what the STP does and where it is located in the GSM/UMTS network. As you can see from Figure 2.8, earlier and later figures in this chapter are not taking the STP into account.
21
RNC
STP
HLR
UMSC/ VLR
SGSN
Figure 2.8 A view of the STPs 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 SGSNs 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 SGSNs position in the GSM/UMTS network is shown in Figure 2.9.
RNC
SGSN
HLR
Figure 2.9 A view of the SGSNs 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 SGSNs position in the GSM/UMTS network is shown in Figure 2.10.
22
RNC
SGSN
GGS N
External Network
Figure 2.10 A view of the GGSNs 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. Its 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 SMSCs signaling connections.
UMSC/ VLR
SMSC
HLR/AuC
Figure 2.11 A view of the SMSCs position in the GSM/UMTS network.
2.2.8 Service Control Point (SCP)

An intelligent network (IN) is a service-independent telecommunications network. That is, intelligence is taken out of the UMSCs and placed in computer nodes that are distributed throughout the network. This provides the network operator with the means to develop and control services more efficiently. New capabilities can be rapidly introduced into the network. The SCP is the functional entity and the source of call control within the IN. The SCP is responsible for the execution of IN services. Typical SCP functions are.
Collection and output of statistics.
23
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 SCPs interfaces in the GSM/UMTS network.
SMSC
SCP
HLR/AuC
UMSC/ VLR
SGSN
Figure 2.12 A view of the SCPs 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 GMLCs position in the GSM/UMTS network. Typical GMLC functions are. Interface with location applications which may be both internal to the network operator as well as external. Authenticate the location applications. Query the HLR for the requested location information.
24
HLR/AuC
GMLC
External/Internal locati on applicati ons
Figure 2.13 A view of the GMLCs position in the GSM/UMTS network.
2.3
Traffic cases
To get a better feeling for the functionality of the different nodes in the GSM/UMTS network, we will now take a look at a few different traffic cases where most of the above nodes are involved. Some of the situations causing these traffic cases are well known even to someone inexperienced in GSM/UMTS technology, others are buried deep inside the network infrastructure and never shows itself for the day to day subscriber. All of the traffic cases though have in common that they present the necessity to reach the HLR without knowing its address information. This phenomenon is what we will be treating further on in this document so pay close attention to these situations.
2.3.1 Normal Location Updating (LU)

A roaming mobile subscriber, moves freely within the GSM/UMTS network. Because the network knows the location of the MS, it is possible for the mobile subscriber to receive a call wherever they are. To keep the system updated with the current subscriber location information, the MS must inform the system whenever it changes LA. A LA consists of one or more cells in which a MS can move around without needing to update the VLR on its location. A location area is controlled by one or more RNCs but by only one UMSC/VLR. A UMSC/VLR can control more than one LA. The RNC sends paging messages to the Node Bs defined within a certain LA. If the MS moves between cells belonging to different LAs, the network must be informed via a procedure called LU. There are really four different types of LUs but for the scope of this document we only need to grasp the concept of the normal LU. The Node B of every cell continuously transmits the LA identity into the air on a special broadcast channel. When the MS detects that the broadcast LA identity is different from the one stored in the SIM-card, it performs a LU. If the mobile subscriber is unknown to the UMSC/VLR, i.e. the broadcast LA belongs to a new UMSC/VLR SA, then the new UMSC/VLR must be updated with subscriber information. This subscriber information comes from the HLR. This location updating procedure is described in the following steps and shown in Figure 2.14.
25
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.
Note the difference between the Location Updating (LU) procedure and the Update Location (UL) signaling message.
26
2. IMS I MGT
3. Authenticati on UMSC/ VLR 4. Y Subscriber informati on 6. request Subscriber informati on response
1. Location Updating request RNC Node B
LAI=Y LAI=X
MS
5. Store IMS I UMSC/ VLR
HLR/AuC 7. Location cancellati on
UMSC/ VLR X
RNC
Node B
Figure 2.14 Normal Location Updating. The MS moves from LAI=X to LAI=Y and registers therefore with UMSC/VLR Y.
2.3.2 GPRS Attach

When GPRS is activated in a MS, the MS needs to locate itself in the GSM/UMTS network. This operation is called the GPRS attach. A variety of different types of GPRS attach, detach and also RA Updates exist but for the scope of this document we only need to know how the regular GPRS attach work and then just keep in mind that others exist. The GPRS attach procedure is described in the following steps and shown in Figure 2.15. 1. The MS sends an Attach Request to the SGSN including its IMSI to identify itself. Next the SGSN performs the authentication procedure. 2. In the SGSN, an analysis of the IMSI number is carried out. The result of this analysis is a modification of the IMSI to the MGT which is used to address the HLR. 3. The SGSN sends the GPRS Location data for the MS to the HLR.
27
4. The HLR replies with the subscriber data related to GPRS. The subscriber data is then stored in the SGSN. 5. Finally the SGSN confirms the GPRS Attach with the MS.
2. IMS I MGT 5. Attach Accept 1. Attach Request 3. Update GPRS Location
SGSN (new) 4. Insert Subscriber Data
RNC
B Node
MS
HLR
Figure 2.15 GPRS Attach
2.3.3 Call to Mobile Subscriber

There are may scenarios how a telephone call may be set up in a mobile network. The only part of the setup which interests us and is vital for the scope of this document is how the call finds and is routed to the mobile subscriber. Therefore we will only discuss this part of the setup and it may be generalized in the following way for our purposes. The following procedures for a call to a mobile subscriber are illustrated in Figure 2.16. 1. Any call entering the GSM/UMTS network from the PSTN/ISDN, from another PLMN or from a MS in the own mobile network, is routed to a UMSC. This UMSC (sometimes called the GMSC where the G stands for Gateway) receives an ISDN User Part (ISUP) Initial Address Message (IAM) indicating an incoming call. 2. The UMSC analyzes the MSISDN to find out which HLR the mobile subscriber is registered in. An authentication request is made to the AuC associated with this HLR and then the UMSC sends the MSISDN along with a request for routing information to this HLR. These messages are the Send Authentication Info (SAI) and Send Routing Info (SRI) which later on will be important. The serving UMSC/VLR address is stored in the HLR from location updating. The HLR contains the IMSI that is connected to this MSISDN number. 3. The HLR sends a request for a Mobile Station Roaming Number (MSRN) to the UMSC/VLR of the LA where the MS is located. Included in the message is the
28
called MSs 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 MSs IMSI. The MSRN is then released. 7. Using the MSs IMSI, the UMSC/VLR identifies the LA in which the MS is situated. 8. The MS is paged in all cells within this LA. 9. When the MS responds to the paging message, authentication, cipher mode setting, and an IMEI check are carried out if supported by the network. 10. If the authentication is confirmed and ciphering is successful, then the call is connected from the UMSC to the RNC and the Node B, where a traffic channel is selected on the air path.
8. Page
4. MS RN
HLR 2. MS ISDN 3. IMS I
4. MS RN B Node 10.
9. Page response MS
1. MS ISDN 5. UMSC UMSC/ VLR 6. MSRN IMS I 7. IMS I LAI RNC B Node
8. Page
8. Page
B Node
Figure 2.16 Call to MS
29
2.3.4 Short Message to a MS

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

The IN in an operators network provides a way to custom design advanced services outside the GSM/UMTS specification. This is done via functions which are executed by the SCP. When the logic in an IN function so requires the SCP may request subscriber state or location information at VLR level from the HLR. This scenario interest us since it involves reaching the HLR based on only subscriber information.
30
The following procedures are performed when an IN function, executed in the SCP, requests a subscribers location. An illustration is found in Figure 2.18. 1. The logic in an IN function needs to retrieve subscriber information it requests this from the HLR, which is the node that knows where the subscriber is located. This message is the Any Time Interrogation (ATI) Request which is important to the scope of this document. 2. The HLR in turn forwards the request to the VLR which know in exactly what LA and cell the MS is located and also controls the MS state information (in call, etc.). This is done via the Provide Subscriber Info Request. 3. The VLR responds to the HLR with the requested information in the Provide Subscriber Info Response. 4. Finally the HLR can respond to the SCP with the Any Time Interrogation Response.
3. Provi de Suscriber Info Response 2. Provi de Suscriber Info Request
HLR/AuC 4. Any Ti me Interrogati on Response
UMSC/ VLR
1. Any Ti me Interrogati on Request
SCP
Figure 2.18 IN request for subscriber information.
2.3.6 Location Information Request by a Location Application

Since the introduction of the GMLC node in GSM/UMTS networks the possibility to physically locate a subscriber has increased. We will discuss a simple way to get a fairly good idea to where the subscriber is located. The below discussion can be found illustrated in Figure 2.19. There exists more than just one way to calculate the location of a subscriber. All of them though have in common the step where the HLR is contacted in the description below. 1. The GMLC receives a petition from an internal or external application regarding the location of a subscriber based on its MSISDN.
31
2. 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 MSs location. 8. The UMSC/VLR responds to the GMLC with the MSs location. 9. Finally the GMLC can supply the internal or external application with the location of the subscriber MSISDN.
3. SRIfLCS_ack 2. SRIfLCS (MS ISDN)
9. 1. Internal or External 4. Provi de Application Subscriber Loc ation GMLC
HLR/AuC
8. Provi de Subscriber Location ack 6. Perform Location 7. response
5. Page
UMSC/ VLR
RNC
Node B
MS
Figure 2.19 Request for the location of a MS.
2.3.7 Short Message from a MS with Policing based on Subscriber IMSI

The MO-SM provides the means to transfer a SM from a MS to a SMSC. This can be carried out either when the MS is idle or when a connection (such as speech or fax) already exists. For both successful and unsuccessful deliveries, the MS receives a delivery report.
32
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 MSs MSISDN. 3. The HLR replies with the IMSI of the originating MS. Now the VLR can determine that the originating MS really is a client of the network operator (for example to prevent fraud). 4. The VLR uses the SMSC address from the MO-SM message to determine to which UMSC (sometimes called the InterWorking MSC (IWMSC)) the SM needs to be forwarded. The message is finally forwarded to the UMSC. 5. This UMSC forwards the SM to the SMSC.
3. SendIMS I ack (IMS I) 1. MO-S M (MS ISDN) MS Node B RNC UMSC/ VLR 4. FWD S M 2. SendIMS I (MS ISDN) HLR/AuC
5. FWD S M UMSC SMSC
Figure 2.20 Short message from a MS with SM policing based on subscriber IMSI.
2.4
Protocol stack Signaling System number 7 (SS7)
SS7 is a common channel signaling system where the signaling information related to various user information channels is transferred in one separate signaling channel. The
33
combination of signaling points and their interconnecting signaling links form the SS7 signaling network. Basically, the SS7 can be subdivided into the following major parts. Message Transfer Part (MTP) Signaling Connection Control Part (SCCP) User Part (e.g ISUP) Transaction Capabilities Application Part (TCAP) Application Part (e.g. Mobile Application Part (MAP))
OMAP
MAP TCAP
INAP
ISUP
SCCP MTP
Figure 2.21 Protocol stack of SS7
An illustration of the SS7 protocol stack is found in Figure 2.21. The two protocols that really interest us in this stack are SCCP and MAP which will be examined more thoroughly than the others.
2.4.2 MTP
The basic functions of MTP are. Quick and error-free transmission of messages between exchanges (signaling points). Routing of messages to their destination signaling point. Distribution of messages to the appropriate user part within the destination signaling point. Rerouting of messages in case of signaling network failures (e.g. breakdown of signaling links or signaling transfer points.
2.4.3 SCCP
The basic functions of SCCP are.
34
Establishment and control of signaling connections (i.e. logical end-to-end connections between signaling points via the common channel signaling links). Possibility of worldwide addressing for signaling points. SCCP possesses its own routing label. Connection-Oriented or Connection-Less message transfer. Additional functions for the transfer of messages between exchanges and other signaling points (e.g. databases). Combined with the MTP as the Network Service Part.
These basic functions admit SCCP to deliver the following services. Connection-Less services Provide the SCCP user with the ability to transfer signaling messages without the establishment of a signaling connection. Connection-Oriented services Signaling connections are established and controlled by the SCCP user. These kinds of connections are comparable with dialed telephone connections. Management functions Manage the status of the SCCP subsystems. Information about a change in the subsystem status is provided to other nodes. Functions for routing and address-translation. Provide a translation function, which is asked for Connection-Less and Connection-Oriented service.
The SCCP protocol has two separate ways of routing traffic. The called and calling party address contain the information necessary for the SCCP to indicate an originating node and a destination node. The SCCP user hands over to the SCCP a called party address and if required, a calling party address with every message to be transferred Connection-Less or with the request to setup a signaling connection. Two basic categories of addresses are distinguished. Global Title (GT) The GT is an address which cannot directly be used for routing in the signaling network. The GT translation function of the SCCP is required which transfers the GT to a Point Code (PC) and a SSN. The determined DPC can either be the destination point or a transfer point in the signaling network. The address translation is continued until the destination point is reached. Destination Point Code (DPC) DPC and SSN allow direct routing by the SCCP and MTP. The translation function of the SCCP is not required.
35
2.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 0000 0110 5 6 Reserved for MAP for future use HLR
36
0000 0111 0000 1000 0000 1001 0000 1010 0000 1100
7 8 9 10 12
VLR UMSC EIR AC SMC (Ericsson), not specified in GSM/UMTS
MAP addressing differs depending on if the message is intra-Public Land Mobile Network (PLMN) or inter-PLMN. Intra-PLMN o SSN indicator = 1 (MAP SSN always included) o GT or PC may be included Inter-PLMN Destination address. o SSN indicator = 1 (MAP SSN always included) o GT indicator = 0100 = 4 (includes Translation Type (TT), Numbering Plan (NP), Encoding Scheme and Nature of Address (NA)) Originating address o SSN indicator = 1 (MAP SSN always included) o Point Code indicator = 0 o GT indicator = 0001 = 1 (NA indicator only) The table below shows the addressing used between our basic GSM/UMTS nodes. From \ To HLR VLR UMSC EIR -
Other Network E: GT T: MSISDN HLR -
I: PC / GT E: GT T: VLR number
37
VLR
I: PC / GT E: GT
I: PC / GT E: GT
T: IMSI / T: VLR number MSISDN / HLR number UMSC I: PC / GT E: GT T: MSISDN I: PC / GT E: GT I: PC / GT E: GT I: PC / GT E: GT T: EIR number
T: VLR number T: UMSC number
I: Intra-PLMN, E: Extra-PLMN, T: Address Type
38
3 Introduction to Mobile Number Portability (MNP)
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 companys 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&Ts collect calling service in the United States. Changing a private mobile phone number is also a barrier for most people even if it is not as costly as in the corporate case above. Family and friend normally know your phone number by heart or keeps it in some sort of address book. Changing ones phone number generally creates communication problems at some point and most people therefore prefer not changing.
These are the typical cases legislators had in mind when they, by introducing MNP, tried to remove or at least lower the barrier to switch service provider.
39
3.2
MNP Technical Network Specification
The organization in Spain responsible for the MNP legislation is the Comisin 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.
Number Range Owner Network: The network to which a certain number range has been assigned. For more definitions please see Chapter 9.1.
40
MNP Database
Number Range Owner Network
Reci pient Network
Originating Network
Figure 3.1 Indirect routing of a call or MAP message.
3.2.2 Direct routing case: Consult the originating network

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

For call oriented cases, when a MSISDN has been consulted and is not ported in the MNP database (consulted number), the signaling information between network operators shall be included in the ISDN User Part (ISUP) called party number parameter and coded in the following way. The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the NRN + MSISDN: Called party number = NRN + MSISDN, with the MSISDN made up of 9 digits.
The NRN for consulted and not ported MSISDNs have a 6 digit structure ABCDEF which is described below. Network operator code AB = 00 to 79, CDEF = 9999 Network operator code ABC = 800 to 999, DEF = 999 For call oriented cases, when a MSISDN has been consulted and is ported in the MNP database (ported number), the signaling information between network operators shall be included in the ISUP called party number parameter and coded in the following way. The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the NRN + MSISDN: Called party number = NRN + MSISDN, with the MSISDN made up of 9 digits.
The NRN for consulted and ported MSISDNs have a 6 digit structure ABCDEF which is described below.
42
Network operator code AB = 00 to 79, CDEF 9999 Network operator code ABC = 800 to 999, DEF 999 The digits AB[C] (AB from 00 to 79 or ABC from 800 to 999) indicates the recipient network operator code and identifies the network operator uniquely. The digits [C]DEF3 shall be freely defined be the recipient network operator, always respecting that [C]DEF [9]999 In case of error, for both consulted numbers and ported numbers, the release cause to be employed is 0000001 (1 decimal) Number not assigned / Portability error. If an MSISDN has not been consulted there is no change to the interchange of signaling between network operators.
3.2.4 Signaling Messages for MNP in Non Call Oriented Cases

For non call oriented cases, when a MSISDN has been consulted and is not ported in the MNP database (consulted number), it is necessary that the querying network includes the signaling information between operators, within the Signaling Connection Control Part (SCCP) parameter Called Party Address (CdPA), with the following codification. The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the CC + NRN + MSISDN, with the MSISDN made up of 9 digits.
The NRN for consulted and not ported MSISDNs have a 6 digit structure ABCDEF which is described below. Network operator code AB = 00 to 79, CDEF = 9999 Network operator code ABC = 800 to 999, DEF = 999 For not call oriented cases, when a MSISDN has been consulted and is ported in the MNP database (ported number), it is necessary that the interrogating network includes the signaling information between operators, within the SCCP parameter CdPA, with the following codification. The directions Nature of Address (NA) value: NA = 1111110 (126 decimal). This indicates the presence of a consulted MSISDN and is composed of: NRN + MSISDN. Concatenation of the CC + NRN + MSISDN, with the MSISDN made up of 9 digits.
Possible use for these three or four digits could be to mark subscribers as for example pre-paid or post-paid and in this way extract statistics.
43
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 70 xxxx State Assigned Date 07-09-2000 Network Operator TELEFNICA MVILES ESPAA, S.A.U. (Moviline) TELEFNICA MVILES ESPAA, S.A.U. (Movistar) VODAFONE ESPAA, S.A. RETEVISIN MVIL, S.A. XFERA MVILES, S.A.
71 xxxx
Assigned
07-09-2000
72 xxxx 73 xxxx 74 xxxx
Assigned Assigned Assigned
07-09-2000 07-09-2000 07-09-2000
44
4 Introduction to Flexible Allocation (FA)
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 Moores law, doubling its capacity every 18 months. These facts has lead to that the HLR nowadays cannot consist in only one piece of hardware but rather various physical nodes which together form one logical HLR. Implementing the HLR this way creates an addressing problem when it comes to directing signaling traffic to one of many physical HLRs. Most network operators (all Spanish network operators) solved this problem, when it first appeared, by statically link together a range of Mobile Station Integrated Services Digital Network numbers (MSISDN), a range of International Mobile Subscriber Identities (IMSI) with a physical HLR. Figure 4.1 illustrates the MSISDN IMSI HLR relationship.
Range of MS ISDN 1 Range of IMS I 1 HLR 1
Range of MS ISDN 2 Range of IMS I 2 HLR 2
... ...
Range of MS ISDN n Range of IMS I n HLR n
Figure 4.1 Illustration of the MSISDN IMSI HLR relationship.
This solution creates a situation where when a node has a need to communicate with a physical HLR it can use either the IMSI or the MSISDN for routing purposes. As you can imagine this solution during the first couple of years worked quite fine but after a while started to present problems and inefficiencies such as.
45
4 Introduction to Flexible Allocation (FA)
Need for subscriber migrations between physical HLRs. To not misuse the resources of the physical HLRs they are assigned MSISDN exceeding their capacity. When the network operator subscriber base grows, sooner or later the physical HLR fils up to maximum storage or processing capacity and subscriber migrations will need to take place. Another scenario also causing subscriber migration is the allocation of imported MSISDNs. These imported MSISDNs are a result of the earlier described Mobile Number Portability (MNP). Inefficient use of storage capacity in physical HLRs due to subscribers changing their Subscriber Identity Module (SIM) and therefore their IMSI. The new IMSI will of course be associated with the MSISDN of the subscriber and both the new IMSI and MSISDN already belongs to a HLR through their ranges. This causes the old IMSI to become unused in the HLR. Complex logistic situation to supply new SIMs to a network operators sales points. When a subscriber for an arbitrary reason needs to get a new SIM, the subscriber normally addresses a sales point of the network operator. The sales point supplies the subscriber with a new SIM with an IMSI of the correct range depending on the HLR to which the subscribers MSISDN belong. To be able to supply such a SIM all sales points needs to maintain one stock of SIMs for every HLR in the operator network. The network operator has to choose the amount of SIMs in stock considering the following two situations. o A large stock will always have a SIM available for the subscriber that needs a replacement but on the other hand creates larger upfront production costs. o A smaller stock may present the subscriber with a situation where he/she cannot get a replacement SIM momentarily. This situation creates customer dissatisfaction and costs when it comes to getting the new SIM to the subscriber, e.g. contracting a messenger service to deliver the new SIM.
This is where FA comes into the picture. To be able to resolve the above presented problems we need to end the relationship between the HLR, the IMSI and the MSISDN. FA administers MSISDN and IMSI relationship providing network operators the ability to allocate a SIM in a flexible way in any physical HLR without considering the existing attachment between MSISDN ranges, IMSI ranges and HLRs.
46
5 MNP/FA solution
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
There are a few more situations where this situation arises. The interested reader can find a complete list of these in [11] Mobile Application Part (MAP) specification, 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC), chapter 6.1.3.3 The Home Location Register (HLR).
47
5 MNP/FA solution
the MS receiving the Short Message and the Global Title (GT) of the UMSC where the MS currently is located. Appendix A contains an example SRIfSM message. Any Time Interrogation (ATI) [10] This is a MAP request sent by the Service Control Point (SCP) to the HLR interrogating it for subscriber information mentioned in point one in Chapter 2.3.5. The ATI is routed to the HLR based on an analysis of the MSISDN. Appendix A contains an example ATI message. Send Authentication Info (SAI) [10] This is the MAP request sent by any node that needs to authenticate the MS mentioned for example in point three in Chapter 2.3.1. The request is sent to the Authentication Center (AuC) but is always routed via the HLR. The SAI is routed to the HLR based on an analysis of the IMSI, which is translated to a MGT. Appendix A contains an example SAI message. Send Routing Info for Location (SRIfLCS) [11] This is the MAP request sent by the GMLC to the HLR interrogating it for subscriber location information mentioned in point two in Chapter 2.3.6. The SRIfLCS is routed to the HLR based on an analysis of the MSISDN. Appendix A contains an example SRIfLCS message. SendIMSI [11] This is the MAP (v2 only) message sent by the VLR to the HLR interrogating it for a subscribers IMSI based on its MSISDN mentioned in point two in Chapter 2.3.7. The SendIMSI is routed to the HLR based on an analysis of the MSISDN.
As seen above all these messages are using either the MSISDN or the IMSI/MGT to find out which is their statically linked HLR. Therefore what we need to add is an additional functionality of dynamic routing based on IMSI/MGT or MSISDN. This new functionality must be placed in one of the existing nodes where the message already passes by (Signaling Transfer Point (STP) or HLR) or in a new node which will capture the message before it gets to the HLR.
5.2
MNP requirements to a Solution
To resolve MNP we need to be able to intercept those MAP messages sent to the HLR (e.g. the SRI message) to verify if the MSISDN is a ported number or not. This new functionality must be placed in one of the existing nodes where the message already passes by (STP and HLR) or in a new node which will capture the message before it gets to the HLR. The MAP messages subject to this situation are. SRI SRIfSM ATI SRIfLCS
48
5 MNP/FA solution
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.
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 worlds network operators. The IR21 is the standardized public document every network operator shares to describe its internal structure.
49
6 The Signaling Relay Node (SRN) in action
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 8
Translation Type Numbering Plan 9 Nature of Address
50
CgPA10 CdPA
011 014
112 715
413 416
UMSC/SGSN MGT
3. This message gets to the STP in which the following Global Title Translation (GTT) is specified. TT 0 NP 7 NA 4 NS MGT New GT 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 CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS UMSC/SGSN17 HLR
5. The HLR realizes its normal processing of the received MAP message and since the CgPA has been conserved containing the UMSCs GT, the HLR sends the MAP reply message directly to the UMSC (via the STP of course), without passing by the SRN.
Calling Party Address TT are set to 0 for both CgPA and CdPA since we want to use regular SCCP translations. 12 NP of the CgPA is set to 1 since it is a Global Title (GT) part of the E.164 number series. 13 NA is set to 4 since both CgPA and CdPA are in international format. 14 TT are set to 0 for both CgPA and CdPA since we want to use regular SCCP translations. 15 NP of the CdPA is set to 7 since the message is routed on a MGT part of the E.214 number series. 16 NA is set to 4 since both CgPA and CdPA are in international format. 17 The CgPA of this message is left pointing at the UMSC/SGSN since we want the HLR to respond directly to this node. In this way the no other node then the STP is conscious about the SRNs presence.
11
10
51
...
HLR 1 5. HLR n
4. 1. UMSC or SGSN 2. STP 3. SRN
Figure 6.1 CdPA contains a MGT, the MAP message is subject to FA.
6.2 Send Routing Info (SRI) Containing an Imported or Own MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.2. The MAP message SRI is used when a call has reached a UMSC. The UMSC sends the SRI message to the HLR asking it for the Mobile Station Roaming Number (MSRN) which is necessary to rout the call. 1. A petition is received by the UMSC/VLR. 2. The UMSC constructs the MAP message SRI with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 118 NA 4 4 NS UMSC 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.
52
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS UMSC HLR
5. The HLR treats the SRI message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an Send Routing Info acknowledgement (SRI_ack) via the STP.
...
HLR 1 5. HLR n
4. 1. UMSC 2. STP 3. SRN
Figure 6.2 Call to an imported or own MSISDN.
6.3 Send Routing Info (SRI) Containing an Exported or Foreign MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRI message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.3.
53
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS UMSC MSISDN
3. This message gets to the STP in which the following GTT is specified. TT 0 NP 1 NA 4 NS MSISDN New GT SRN
4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has 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 CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SRN19 UMSC
And the following data in the SRI_ack MAP message. MAP SRI_ack IMSI *20 NP 1 NA 12621 MSRN NRN+MSISDN
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
19
54
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 CdPN22 NP 1 NA 12623 Address Signal NRN+MSISDN
...
HLR 1 HLR n
4. 1. UMSC 5. 2. STP 3. SRN
External Network
Figure 6.3 Call to an exported or foreign MSISDN.
6.4 Send Routing Info (SRI) Containing an Imported or Own MSISDN from an Interconnecting Call
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also
21407 99999 99999 Movistar NA is set to 126 to indicate that the MSISDN has been consulted and that an NRN has been added in front of the MSISDN. 22 CdPN = Called Party Number 23 NA is set to 126 to indicate that the MSISDN has been consulted and that an NRN has been added in front of the MSISDN. This is how the interface between network operators was specified in [6].
21
55
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 CdPN NP 1 NA 12624 Address Signal NRN+MSISDN
2. The UMSC constructs the MAP message SRI with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 11225 NS UMSC MSISDN
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS UMSC HLR
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.
24
56
5. The HLR treats the SRI message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an SRI_ack via the STP.
...
HLR 1 5. HLR n
4. 2. UMSC STP 3. SRN
1.
External Network
Figure 6.4 Call to an imported or own MSISDN where the call was received in interconnection.
6.5 Send Routing Info for Short Message (SRIfSM) Containing an Imported or Own MSISDN
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.5. The MAP message SRIfSM is used when the Short Message (SM) is routed to its destination MS. The Short Message Service Center (SMSC) sends the SRIfSM to the HLR asking it for the VLR address where the MS is currently located. The SMSC is the node where the SM is stored temporarily until delivery is possible. 1. A Forward Short Message MAP message is received by the SMSC.
57
2. The SMSC constructs the SRIfSM MAP message with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SMSC MSISDN
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SMSC26 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.
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 SRNs presence.
26
58
...
HLR 1 5. HLR n
4. 1. SMSC 2. STP 3. SRN
Figure 6.5 Sending of and SM to an imported or own MSISDN.
6.6 Send Routing Info for Short Message (SRIfSM) Containing an Exported or Foreign MSISDN
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.6. 1. A Forward Short Message MAP message is received by the SMSC. 2. The SMSC constructs the SRIfSM MAP message with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SMSC MSISDN
4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP
59
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12627 NS SMSC CC+NRN+MSISDN28
...
HLR 1 HLR n
1. SMSC
2. STP
3. SRN 4.
External Network
Figure 6.6 Sending of and SM to an exported or foreign MSISDN.
6.7 Send Routing Info for Short Message (SRIfSM) Containing an Imported or Own MSISDN Received in Interconnection
The 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.
27
60
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12630 NS UMSC29 CC+NRN+MSISDN
2. The UMSC forwards the SRIfSM MAP message with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 126 NS UMSC CC+NRN+MSISDN
3. This message gets to the STP in which the following GTT is specified. TT 0 NP 1 NA 126 NS CC+NRN+MSISDN New GT SRN
4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards its corresponding HLR with the following parameters at the SCCP level. SCCP TT NP NA NS
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.
29
61
CgPA CdPA
0 0
1 1
4 4
UMSC HLR
5. The HLR treats the SRIfSM message just the same way as if it would have come directly from the UMSC. Finally it replies to the UMSC with an SRIfSM_ack via the STP.
...
HLR 1 5. HLR n
4. 2. UMSC STP 1. 1. 3. SRN
External Network
Figure 6.7 Sending of an SM to an imported or own MSISDN where the SRIfSM message is received in interconnection.
6.8 Any Time Interrogation (ATI) Containing an Imported or Own MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a ATI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.8. The MAP message ATI is used when an Intelligent Network (IN) service needs information about a subscriber. The IN node Service Control Point (SCP) sends the ATI
62
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SCP MSISDN
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SCP31 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.
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 SRNs 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 Orgnica 5/1992, de regulacin del tratamiento automatizado de los datos de carcter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.
31
63
...
HLR 1 5. HLR n
1. 4. 2. SCP STP 3. SRN
Figure 6.8 An IN service interrogating the HLR about an imported or own MSISDN.
6.9 Any Time Interrogation (ATI) Containing an Exported or Foreign MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfSM message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.9. 1. An IN service executing in the SCP needs current subscriber location or status information. 2. The SCP constructs the MAP message ATI with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SCP MSISDN
4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN
64
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12633 NS SMSC CC+NRN+MSISDN34
...
HLR 1 HLR n
1.
2. SCP STP
3. SRN 4.
External Network
Figure 6.9 An IN service interrogating the HLR about an exported or foreign MSISDN.
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.
33
65
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12636 NS SCP35 CC+NRN+MSISDN
2. In the STP the following GTT is specified. TT 0 NP 1 NA 126 NS CC+NRN+MSISDN New GT SRN
3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS SCP 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.
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.
35
66
...
HLR 1 4. HLR n
3. 2. STP 1. SRN
External Network
Figure 6.10 An IN service interrogating the HLR about an exported or foreign MSISDN where the ATI message is received in interconnection.
6.11 Send Routing Info for Location (SRIfLCS) Containing an Imported or Own MSISDN
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfLCS message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.11. The MAP message SRIfLCS is used when a location application needs to pin down the location of the subscriber. The Gateway Mobile Location Center (GMLC), which has received the petition from the location application, sends the SRIfLCS to the HLR asking it for the address of the VLR where the subscriber is currently located. The GMLC is the gatekeeper and interface for any location application that would like to use the GSM/UMTS positioning service. 1. A location application requests location information about a subscriber to the GMLC. This interface is based upon Internet Protocol (IP) and Hyper Text Transfer Protocol (HTTP).
67
2. The GMLC constructs the SRIfLCS MAP message with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS GMLC MSISDN
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS GMLC37 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.
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 SRNs 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 Orgnica 5/1992, de regulacin del tratamiento automatizado de los datos de carcter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.
37
68
...
HLR 1 5. HLR n
4. 2. GMLC STP 3. SRN
1.
Internal/external Location applicati on
Figure 6.11 A location application interrogates the HLR via the GMLC about an imported or own MSISDN.
6.12 Send Routing Info for Location (SRIfLCS) Containing an Exported or Foreign MSISDN
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SRIfLCS message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.12. 1. A location application requests location information about a subscriber to the GMLC. This interface is based upon IP and HTTP. 2. The GMLC constructs the SRIfLCS MAP message with the following parameters at the SCCP level. SCCP CgPA TT 0 NP 1 NA 4 NS GMLC
69
CdPA
MSISDN
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12639 NS GMLC CC+NRN+MSISDN40
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.
39
70
...
HLR 1 HLR n
1.
2. GMLC STP
3. SRN 4.
1.
Internal/external Location applicati on
External Network
Figure 6.12 A location application interrogates the HLR via the GMLC about an exported or foreign MSISDN.
6.13 Send Routing Info for Location (SRIfLCS) Containing an Imported or Own MSISDN Received in Interconnection
The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for an SRIfLCS message which contains a MSISDN that is imported or own which has been received in interconnection with an external network. The procedure is also illustrated in Figure 6.13. 1. An SRIfLCS MAP message is received by the STP in interconnection. With the following parameters at the SCCP level.
71
SCCP CgPA CdPA
TT 0 0
NP 1 1
NA 4 12642
NS GLMC41 CC+NRN+MSISDN
2. In the STP the following Global Title Translation (GTT) is specified. TT 0 NP 1 NA 126 NS CC+NRN+MSISDN New GT SRN
3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS GMLC 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.
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.
41
72
...
HLR 1 4. HLR n
3. 2. STP 1. SRN
External Network
Figure 6.13 A location application interrogates the HLR via the GMLC about an imported or own MSISDN where the SRIfLCS message is received in interconnection.
6.14 SendIMSI Containing an Imported or Own MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SendIMSI message which contains a MSISDN that is imported or own. The procedure is also illustrated in Figure 6.14. The MAP message SendIMSI is used when the VLR for some reason needs to translate a subscribers MSISDN to his/her IMSI. In the example case presented in Chapter 2.3.7 the VLR sent the SendIMSI message to the HLR in order to be able to police the sending of and Mobile Originated SM (MO-SM). 1. The VLR receives a petition where it needs to find out the subscriber IMSI based on its MSISDN. 2. The VLR constructs the MAP message SendIMSI with the following parameters at the SCCP level.
73
SCCP CgPA CdPA
TT 0 0
NP 1 1
NA 4 4
NS VLR MSISDN
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 its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS VLR43 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.
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 SRNs 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 Orgnica 5/1992, de regulacin del tratamiento automatizado de los datos de carcter personal. (B.O.E. 31-10-1992)) prohibits the response by the HLR to this request.
43
74
...
HLR 1 5. HLR n
4. 1. VLR 2. STP 3. SRN
Figure 6.14 A VLR interrogating the HLR for an IMSI based on an imported or own MSISDN.
6.15 SendIMSI Containing an Exported or Foreign MSISDN

The message at SCCP level contains a CdPA containing a MSISDN. This means that it is a MAP message subject to MNP and once consulted in the MNP database it is also subject to FA if the MSISDN is own or imported. At this point it is up to the SRN to discover what to do with every message depending on type. Below we discuss the procedure for a SendIMSI message which contains a MSISDN that is exported or foreign. The procedure is also illustrated in Figure 6.15. 1. The VLR receives a petition where it needs to find out the subscriber IMSI based on its MSISDN. 2. The VLR constructs the MAP message SendIMSI with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS VLR MSISDN
4. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP
75
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12645 NS VLR CC+NRN+MSISDN46
...
HLR 1 HLR n
1. UMSC/ VLR
2. STP
3. SRN 4.
External Network
Figure 6.15 A VLR interrogating the HLR for an IMSI based on an exported or foreign MSISDN.
6.16 SendIMSI Containing an Imported or Own MSISDN Received in Interconnection

The 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.
45
76
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 CgPA CdPA TT 0 0 NP 1 1 NA 4 12648 NS VLR47 CC+NRN+MSISDN
2. In the STP the following GTT is specified. TT 0 NP 1 NA 126 NS CC+NRN+MSISDN New GT SRN
3. The SRN node analyses at SCCP level and consults a table in its SUBSCRIBER database which contains all the MSISDNs which have been ported in this MNP domain (due to the fact that direct routing is used). By doing this the SRN conceives the NRN of the appropriate network operator to pass the MAP message to. Since the MSISDN has not been ported the conceived NRN is our own. The SRN now initiates the FA consulting and finally sends the message towards its corresponding HLR with the following parameters at the SCCP level. SCCP CgPA CdPA TT 0 0 NP 1 1 NA 4 4 NS VLR 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.
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.
47
77
...
HLR 1 4. HLR n
3. 2. STP 1. SRN
External Network
Figure 6.16 VLR interrogating the HLR for an IMSI based on an imported or own MSISDN where the SendIMSI message is received in interconnection.
78
7 The SRN technical specification
7
7.1
The SRN technical specification

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
The SRN application will be developed on a MTP and SCCP capable platform running a suitable operating system. In the field, the SRN application will run on a MTP and SCCP capable platform running on a suitable operating system. 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. 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 1] [Req 2] [Req 3]
[Req 4]
[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.
79
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 UL49 Dist. *% Typ. Size
(bytes/bits)
TPS with
1 link
TPS with * TPS at 40%

links Capacity
*/* */* */* */* */* */* */* */* */*
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
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
The following list summarizes the different tables that will exist in the system and the maximum number of entries. Table Depth Description
[Req 6]
49 50
Update Location General Packet Radio Service Update Location 51 Send Routing Info 52 Send Routing Info for Short Message 53 Any Time Interrogation 54 Send Authentication Info 55 Send Routing Info for Location
80
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. Contains the possible HLRs and routing data associated. Contains the possible Network Routing Numbers (NRN). Contains the association between MAP operation code and Error Code to be sent in case there is an error during MAP processing. Contains configuration parameter names and their values. Contains configuration parameters that are treated as Boolean. Contains the data necessary to normalize an MSISDN.
HLRLOCATION
NETWORK
TCAPERRORCODES
200
PARAMETERS
200
FLAGS
200
MSISDNNORMALIZATION 128
81
COMBINATION
128
Contains the data necessary to combine a NRN and an MSISDN. Contains the data necessary to translate an Mobile Global Title (MGT) to an IMSI. Contains the hostnames of the SRN and particular parameters associated, like the Global Title (GT)
MGTTRANSLATION
128
LOCAL
50
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 Comisin 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 MSISDN Key/Attribute Key Type CHAR(20) Description A subscriber MSISDN or range. If the MSISDN is a range, it should end with the * character.
82
IMSI
Alternate Key
CHAR(20)
The IMSI of the subscribers SIMcard. If the IMSI is a range, it should end with the * character. If the MSISDN is exported or foreign this field should be set to the * character. The descriptive name of the HLR holding the subscriber. The HLR address information is stored in the HLRLOCATION table. The descriptive name of the subscription network operator. The entry has to exist in the NETWORK table.
HLRName
Attribute
CHAR(10)
NetworkID
Attribute
CHAR(10)
[Req 8] [Req 9]
If the NetworkID value starts with a character other than alphanumeric, or it is an empty string, it shall be treated as not provisioned. If the HLRName value starts with a character other than alphanumeric, or it is an empty string, it shall be treated as not provisioned. Database search procedure 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. An entry of the table when searching for MSISDNs shall be matched if. The normalized MSISDN is equal to the entrys MSISDN. The normalized MSISDN, truncated from the back end followed by *, is equal to the entrys MSISDN. The entry with maximum MSISDN length shall be used, in case several lengths produce a match. The
7.3.1.2 [Req 10]
[Req 11]
83
truncation lengths applied in the search shall range from the MSISDN length to 0. [Req 12] [Req 13] If there is no matching MSISDN, the procedure shall return MSISDN not found, else [Req 15] to [Req 20] applies. An entry of the table when searching for IMSIs shall be matched if. The IMSI is equal to the entrys IMSI. The IMSI, , truncated from the back end followed by *, is equal to the entrys 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] [Req 15]
If there is no matching IMSI, the procedure shall return IMSI not found, else [Req 15] to [Req 20] applies. 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). 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. 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). 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. 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. If other error occurs that avoids the normalized MSISDN or IMSI to be searched in the database or one of the matched entrys fields to be retrieved, the procedure shall return Execution Error.
[Req 16]
[Req 17]
[Req 18]
[Req 19]
[Req 20]
7.3.2 Service configuration data

[Req 21] Service configuration data are configuration data related to the MNP/FA application that may affect the service logic behavior.
84
[Req 22]
The Service configuration data will be able to be added, deleted, and modified in run-time without having to restart the application. Configuration parameter tables These tables will have two columns representing the key (name) and the value of the parameters The MNP/FA application will have the following configurable parameters held in the table of PARAMETERS. PARAMETERS Parameter NPSValue56 Description Assumed Format
7.3.2.1 [Req 23] [Req 24]
Positive or zero The value to insert Integer into the numberPortabilitySt atus parameter (section 7.4.2.2) Default error code to Positive or zero Integer be sent in case of database mismatch detection during MAP processing (section 7.4.2).
DefaultDBMismatchError
DefaultMSISDNNotFoundError Default error code to Positive or zero Integer be sent in case of MSISDN not found during MAP processing (section 7.4.2). DefaultIMSINotFoundError Default error code to Positive or zero Integer 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
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),
56
85
Parameter name EnableNPS
Description 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 [Req 26]
HLRLOCATION table The GT and Point Code / SubSystem Number (PC/SSN) of the HLRs in the network shall be contained in the HLRLOCATION table. HLRLOCATION Field Name Name Key/Attribute Key Type CHAR(10) Description A descriptive name of the HLR. A flag to indicate if routing must be performed on GT or not. The SCCP GT of the HLR. The PC of the HLR.
RouteOnGT
Attribute
CHAR(1)
GlobalTitle PC [Req 27] [Req 28] [Req 29]
Attribute Attribute
CHAR(20) SHORT INTEGER
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. If the GlobalTitle value starts with a non-numeric character, or is an empty string, it shall be treated as not provisioned. If the PC value is lower than 0 or greater than 16383, it shall be treated as not provisioned.. NETWORK table The network IDs and their routing numbers shall be contained in the NETWORK table. NETWORK Field Name Key/Attribute Type Description
7.3.2.3 [Req 30]
86
NetworkID
Key
CHAR(10)
The textual description of the network operator. The NRN of the operator. If this is FALSE, then the NRN shall be treated as if it was an empty string during the address combination procedure. IMSI to be returned in the response to the SRI. Indicates if the NRN is own.
NRN UseNRN
Alternate Key Attribute
CHAR(20) CHAR(1)
IMSI
Attribute
CHAR(20)
OwnNetwork [Req 31]
Attribute
CHAR(1)
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] [Req 33]
If the IMSI value starts with a non-numeric character, or is an empty string, it shall be treated as not provisioned. If the NRN value starts with a non-alphanumeric (non-hexadecimal) character, it shall be treated as an empty string. The UseNRN flag shall be interpreted as TRUE if its value is 1, t, T, y or Y, else it shall be interpreted as FALSE. If the UseNRN flag is FALSE, then the NRN shall be treated as an empty string in the address combination procedure, otherwise the value of the NRN will be used in the combination procedure.
7.3.2.4 [Req 34]
MSISDNNORMALIZATION table The table MSISDNNORMALIZATION shall be used in order to normalize the MSISDN.
87
MSISDNNORMALIZATION Field Name ISDNNoA Key/Attribute Key Type INTEGER Description The ISDN Nature of Address Indicator A comma separated pair of prefixes to delete and add.
DeleteAdd1
Attribute
CHAR(20)
... 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 4 (International) D/A1 D/A2 D/A3 D/A4 D/A5 34,34 -
34R,34 0034R,34
88
3 (national)
R,34
0,34
,34
Now suppose that a valid NRN is 729999. If the incoming MSISDN was (International) 34729999610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 34610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 0034610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (International) 33610513304, it would not be possible to normalize the address. If the incoming MSISDN was (national) 729999610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (national) 0610513304, the resulting normalized address would be 34610513304. If the incoming MSISDN was (national) 610513304, the resulting normalized address would be 34610513304.
Note that in the national case it is always possible to normalize the address because there is a default behavior. If an empty NRN is provisioned in the NETWORK table, then it shall not be considered for this normalization procedure. 7.3.2.6 [Req 35] COMBINATION table The COMBINATION table shall be used to combine a NRN and an MSISDN. COMBINATION Field Name ISDNNoA ModifyNoA Key/Attribute Key Attribute Type INTEGER BOOLEAN Description The ISDN NoA Indicator Specifies whether the NoA must be modified in case of successful combination.
89
ModifiedNoA
Attribute
INTEGER
The output NoA (If ModifyNoA is TRUE) A comma separated pair of prefixes to delete and add
DeleteAdd1
Attribute
CHAR(20)
... 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) 0 (unknown) ,34R
0034,34R 34,34R ,34R
Now suppose that the NRN to insert is 729999.
90
If the incoming Address is (International) 34610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (International) 33610513304, it would not be possible to combine NRN and Address. If the incoming Address is (national) 729999610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 0034610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 34610513304, the resulting combined address would be 34729999610513304. If the incoming Address is (unknown) 610513304, the resulting combined address would be 34729999610513304.
If the NRN to insert is provisioned in the NETWORK table as an empty string, then it shall not be used in this combination procedure. In addition, the NRN shall be treated as an empty string for this combination procedure if the UseNRN flag is FALSE. 7.3.2.8 [Req 36] MGTTRANSLATION table The table MGTTRANSLATION shall be used in order to translate the MGT into an IMSI. MGTTRANSLATION Field Name MGT Key/Attribute Key Type CHAR(20) Description The MGT of the MGT-IMSI translation pair The IMSI of the MGT-IMSI translation pair
IMSI
Attribute
CHAR(20)
This table is used to translate the incoming MGT (input Address) into the IMSI (output Address) which is used at key in the SUBSCRIBER table. The MGT of the input Address is used to index the table. The only attribute is the corresponding IMSI translation
91
7.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 34607 34622 IMSI 21401 21404
Now suppose that the MGT to translate is 346070000011111. The digits matching the MGT entry (34607) are removed and replaced by the digits of the matching IMSI entry (21401) 7.3.2.10 TCAPERRORCODES table [Req 37] The TCAPERRORCODES table shall contain the error code to be sent for certain situations and for certain operation codes, during MAP processing. TCAPERRORCODES Field Name OperationCode DBMismatchError Key/Attribute Key Attribute Type INTEGER INTEGER Description The operation code. The error to be sent when an inconsistency is detected between the network received MAP signaling and the database contents (MAP processing).
92
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 22 (Send Routing Info) 45 (Send Routing Info for SM) 58 (SendIMSI) 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 Field Name HostName GlobalTitle Key/Attribute Key Attribute Type CHAR (20) CHAR(30) Description Hostname of the node Contains the GT of the node DBMismatchError 34 (SystemFailure) 34 (SystemFailure) NotFoundError 1 1
1 (UnknownSubscriber) 1
7.4
Signaling
7.4.1 General
[Req 39] [Req 40] [Req 41] [Req 42] The SRN node shall be physically connected to the Signaling System number 7 (SS7) network with G.703 links. The SRN nodes shall be compliant with MTP and SCCP White Book International Telecommunication Union (ITU) Recommendations. The MNP/FA application shall be registered at the SCCP level of the SS7 stack. The MNP/FA application shall process Unit Data Message (UDT) and Extended Unit Data Message (XUDT) SCCP messages and discard others.
93
[Req 43] [Req 44]
The processing applied to an input SCCP message shall be determined depending on the SSN carried in the SCCP Called Party Address (CdPA). Possible processing types will be referred to throughout the document as. MAP
[Req 45]
The following configuration of SSNs is proposed. SSN 6 146 Processing MAP CAMEL57 Comments Globally standardized HLR SSN 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. 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 Routing Indicator Global Title Indicator SSN Indicator Point Code Indicator SSN PC Translation Type Content (binary) 0 (Route On Global Title) 100 (TT, NP, ES, NA) 1 (SSN Present) 0 (Point Code Not present) SSN contained in the SCCP CgPA of the incoming message. Not Present The translation type of response messages for MAP is 0x00.
[Req 47]
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.
57
94
Numbering Plan
Numbering Plan contained in the SCCP CgPA or 0001 (E.164) if it was not present. 0001: odd number of global title digits 0002: even number of global title digits
Encoding Scheme
Nature of Address Indicator Global Title
0000100 (International) 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. If a relayed message must be routed on GT, the SCCP CdPA shall be formatted according to the following table. Field Routing Indicator Global Title Indicator SSN Indicator Point Code Indicator SSN PC Translation Type Numbering Plan Content (binary) 0 (Route On Global Title) 100 (TT, NP, ES and NoA) 1 (SSN Present) 0 (Point Code Not Present) The SSN contained in the CdPN of the input message. Not Present The translation type of relayed messages for MAP and CAP is 0x00. Numbering Plan contained in the SCCP CdPA or 0001 (E.164) if it was not present. 0001: odd number of global title digits 0002: even number of global title digits
[Req 49]
Encoding Scheme
95
Nature Of Address Indicator
If the GT is obtained from an HLRLOCATION, it shall have value 0000100 (International). If the GT is the result of combining an MSISDN and a NRN, the value shall be determined by the Combination procedure (section 7.3.2.7).
Global Title [Req 50]
TBCD representation of the destination GT
If a relayed message must be routed on PC and SSN, the SCCP CdPA shall be formatted according to the following table. Field Routing Indicator Global Title Indicator SSN Indicator Point Code Indicator SSN PC Translation Type Numbering Plan Encoding Scheme Nature Of Address Indicator Global Title Content (binary) 1 (Route On Point Code) 000 (No Global Title) 1 (SSN Present) 1 (Point Code Present) The SSN contained in the CdPN of the input message. Destination Point Code Not Present Not Present Not Present Not Present Not Present
7.4.2 MAP processing

The requirements in this section must be observed in strict order; the previous requirements of the section might determine the conditions for the current one. The MAP processing is illustrated in Figure 7.1. [Req 51] If the CdPA of the incoming SCCP message contains an MSISDN 7.4.2.1 to 7.4.2.5 apply. On the other hand if the CdPA contains an MGT 7.4.2.6 to 7.4.2.7 apply.
96
7.4.2.1 [Req 52]
MSISDN processing The called MSISDN shall be the normalized SCCP CdPA. The MSISDN normalization procedure is explained in 7.3.2.5. Note that this procedure shall extract the NRN, if it is present.
[Req 53]
If the SCCP CdPA contains a NRN, but it does not belong to the own network (the OwnNetwork field associated to it in the Network table has value FALSE), the MNP/FA application shall continue processing as specified in 7.4.2.5, else it shall continue processing as in the next requirement. The normalized MSISDN shall be searched in the database, using the procedure described in 7.3.1.2. If the database search procedure returns Own Subscriber, the input message shall be relayed to the returned HLR location. Relayed messages shall be routed on GT or PC depending on the RouteOnGT field value defined for the HLR location. 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. 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. 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. Foreign MSISDN SRI processing 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. The MNP/FA shall encode a TCAP End message with a TCAP Result-Last in the SCCP output message. The TCAP Result-Last shall carry the response to the SRI. The SRI Response shall always contain the MSRN and IMSI parameters. The IMSI shall be the one returned by the MSISDN search procedure.
[Req 54] [Req 55] [Req 56] [Req 57]
[Req 58]
[Req 59]
7.4.2.2 [Req 60]
[Req 61] [Req 62] [Req 63] [Req 64]
97
[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. If the EnableNPS flag is FALSE, the numberPortabilityStatus parameter shall not be present in the response. 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. Foreign MSISDN non SRI processing 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. 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 66] [Req 67]
7.4.2.3 [Req 68]
[Req 69]
[Req 70] 7.4.2.4 [Req 71] [Req 72]
Relayed messages shall be routed on GT always. MSISDN not found The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message. The error code contained in the TCAP Error shall be determined from the service configuration data. NRN Database mismatch The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message. The error code contained in the TCAP Error shall be determined from the service configuration data. IMSI processing The called IMSI shall be the translated MGT contained in the SCCP CdPA of the incoming message. The MGT-IMSI translation procedure is explained in 7.3.2.9.
7.4.2.5 [Req 73] [Req 74]
7.4.2.6 [Req 75]
[Req 76]
The called IMSI shall be searched in the database, using the procedure described in 7.3.1.2.
98
[Req 77] [Req 78] [Req 79]
If the database search procedure returns Own Subscriber, the input message shall be relayed to the returned HLR location. Relayed messages shall be routed on GT or PC depending on the RouteOnGT field value defined for the HLR location. 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. IMSI not found The MNP/FA shall encode a TCAP End message with a TCAP Error in the SCCP output message. The error code contained in the TCAP Error shall be determined from the service configuration data.
7.4.2.7 [Req 80] [Req 81]
99
10.4.2 MAP
NO 10.3.2.5 NORMALIZE (MS ISDN)
MGT?
YES 10.3.2.9 TRANSLATE (MGT -> IMS I)
YES
Nor malization possible?
NO SEND ERROR
YES
Translation possible?
NO SEND ERROR
10.3.1.2 DB S EARCH (MS ISDN)
10.3.1.2 DB S EARCH (IMS I)
OWN HLR RELAY
MS ISDN type?
OTHER 10.4.2.4 SEND ERROR
OWN HLR RELAY
IMS I type?
FOREIGN OTHER 10.4.2.7 SEND ERROR
FOREIGN
NO
NRN present?
YES 10.4.2.5 SEND ERROR
YES 10.4.2.2 SRI RESPONS E
SRI message?
NO 10.4.2.3 RELAY TO OTHER NET
Figure 7.1 Visual MAP processing description.
100
7.5
Statistics
7.5.1 Counters
7.5.1.1 [Req 82] SS7 stack counters The SS7 counters provided for each signaling link shall be 7.5.1.2 [Req 83] Number of 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
Operating system counters The operating system counters provided shall be. CPU Idle Time Unused memory Disk Free Space
7.5.1.3 [Req 84]
Service logic counters The service logic counters provided shall be: SCCP UDT Messages received MAP Messages received UL Messages received GPRS UL Messages received SRI Messages received SRIfSM Messages received SAI Messages received
101
ATI Messages received SRIfLCS Messages received Other MAP messages received MAP Messages Discarded: decode error MAP Messages Discarded: DB error MAP Messages Discarded: other error SRI Messages for Own subscriber SRI Messages for Foreign subscriber SRIfSM Messages for Own subscriber SRIfSM Messages for Foreign subscriber ATI Messages for Own subscriber ATI Messages for Foreign subscriber SRIfLCS for Own subscriber SRIfLCS for Foreign subscriber SendIMSI for Own subscriber SendIMSI for Foreign subscriber Other MAP Messages for Own subscriber Other MAP Messages for Foreign subscriber MAP Messages with MSISDN not found MAP Messages with DB mismatch detected MAP Messages with IMSI not found MAP Messages sent out MAP Messages send failure SCCP UDT Messages sent out SCCP UDT Messages send failure
102
7.6
Alarms
The MNP/FA shall raise alarms. 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.
[Req 85] [Req 86]
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
The MNP/FA server shall provide two provisioning interfaces. Read/Write interfaces
[Req 89]
103
[Req 90]
Read only interfaces
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. The error code will contain a value from the constants defined in the provisioning interface. 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.
[Req 93] [Req 94]
7.7.1 Provisioning system log

The logging system will typically be used for extracting statistics. [Req 95] The provisioning system shall write a log.
104
[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] [Req 99]
The logged events shall be written to disk immediately. 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 Average Response Time per Operation Peak Transaction Rate Value 200 ms *operation/hour
[Req 102] These performance characteristics shall be confirmed in controlled conditions in the test-bed, using a LAN with sufficient bandwidth to perform the test. [Req 103] An operation as used here includes a call to either a Create, Delete, Modify, or Search operations of the provision interface. The ModifyKey method counts as two operations due to the fact that it requires both Create (new entry) and Delete (old entry) operations. [Req 104] The transaction rate may be limited by the quality of the Transport Control Protocol / Internet Protocol (TCP/IP) network. The performance is guaranteed for the field machine only if the bandwidth requirement of [Req 4]is available.
105
8 Conclusions and future work
8
8.1
Conclusions and Future Work

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 operators home country. The problem is basically that most countries do not allow personal data to be shared with third parties without the subscribers previous consent. This would be the case if the HLR replied to for example a Send Routing Info for Location (SRIfLCS) message received in interconnection and thereby causing the sharing of personal information (the subscribers position) with a third party (the interconnecting network operator). To prevent this situation to appear altogether we could filter these messages directly in the SRN node but with the negative effect that we would not be able to support certain cross operator services (e.g. cross operator positioning). A better solution would be to introduce a filtering function in the SRN node that would provide a per subscriber allow/deny relay decision.
106
8 Conclusions and future work
8.2
Future Work
The SRN node could be extended with additional features. For example an filtering feature based on source address (usually called policing) could easily be added and is mentioned in footnotes 29, 35, 41, and 47. Such a feature could for example provide a way for the network operator to choose from which sources (network operators) Short Messages (SM) would be allowed. This policing feature would preferably base itself on another table in the database containing the fields Allowed source SubSystem Number (SSN)
which would contain all source nodes allowed to address a certain SSN. Another feature already commented under Conclusions is the one where the SRN node filters certain relay decision based on whether or not the subscriber previously has consented this action. This feature would also typically be based on another table in the database which would include all subscriber MSISDNs allowing a certain cross operator feature. For example MSISDN Allowed MAP message to relay when received in interconnection
would be a good choice of fields in this table. This feature would allow the network operator to control that no cross operator services will take place without the subscribers previous consent. For example lets take a look at the situation in Figure 2.19 where the SRN would see to it that message number 2 never would get to the HLR and therefore cutting the chain which would result in an unlawful event. A network operator willing to implement the presented SRN node would of course have to start out by defining its own production environment. Once all implicated systems (provisioning, alarms, etc.) are known the design would have to be further specified to fit the requirements of these new circumstances. When implementing the SRN node it may be necessary to add support for proprietary messages, e.g. the Retrieve message in the Ericsson proprietary protocol CS1+. Also when implementing the provisioning system I think it would be advisable to implement an IP based interface to prepare the node for an all Internet Protocol (IP) environment.
107
9 Definitions, abbreviations and symbols
9
9.1
Definitions, abbreviations and symbols

Definitions
Consulted Number: An MSISDN already consulted in any network operators MNP database. Direct Routing: A network operators number portability database contains all the ported numbers in the MNP domain. Then it is possible for the originating network to directly route a call (and other signaling affected by MNP) towards the recipient network. to avoid routing the messages through the number range owner network. Donor Network The holder of the number range to which a ported number belongs. Foreign Number: An MSISDN which is contained within a number range owned by another network operator in the MNP domain which has not been ported. Global Title: A form of SCCP addressing in the signaling network. The GT is composed of Translation Type and Address Digits. The GT is an address, defined in the ITU recommendations Q.711 to Q.716, which uniquely identifies a node or an application running on a node. Indirect Routing: A network operators number portability database contains only the exported numbers from the number ranges which the network operator owns in the MNP domain. Then the originating network has to route a call (and other signaling affected by MNP) towards the number range owner network which in turn will know if the MSISDN is a (ex)ported number. International Mobile Subscriber Identity: The IMSI uniquely identifies a GSM subscription (a SIM). It is composed of MCC, MNC and MSIN and is specified in the E.212 numbering plan. Mobile Number Portability Domain: All the number ranges which have been assigned to network operators which may export and import numbers between each other. Network Operator: A GSM/UMTS PLMN operator Network Routing Number: This number is concatenated with the MSISDN and conveyed in the ISUP parameter called party number and the SCCP parameter Called Party Address. The number is used to force a ported call into the recipient network for call processing treatment or to force MAP signaling for at ported number into the recipient network for further treatment. Number Range: A range of MSISDNs assigned to a service provider. In Spain the authority that assigns the number ranges is the Comisin del Mercado de las Telecomunicaciones (CMT). Number Range Owner Network: The network to which the number range containing the ported number has been assigned.
108
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: Comisin del Mercado de las Telecomunicaciones DPC: Destination Point Code FA: Flexible Allocation GGSN: Gateway GPRS Support Node GMLC: Gateway Mobile Location Center GPRS: General Packet Radio Service GPRS UL: GPRS Update Location
109
GSM: Global System for Mobile communication GT: Global Title GTT: Global Title Translation HLR: Home Location Register HTTP: Hyper Text Transfer Protocol IAM: Initial Address Message IMEI: International Mobile Equipment Identity IMSI: International Mobile Subscriber Identity IN: Intelligent Network IP: Internet Protocol ISDN: Integrated Services Digital Network ISUP: ISDN User Part ITU: International Telecommunication Union IWMSC: InterWorking Mobile service Switching Center LA: Location Area LU: Location Updating MAP: Mobile Application Part MCC: Mobile Country Code ME: Mobile Equipment MGT: Mobile Global Title MNC: Mobile Network Code MNP: Mobile Number Portability MO-SM: Mobile Originated Short Message MS: Mobile Station MSC: Mobile service Switching Center MSIN: Mobile Subscriber Identity Number MSISDN: Mobile Station ISDN number
110
MSRN: Mobile Station Roaming Number MSU: Message Signal Unit MT-SM: Mobile Terminating Short Message MTP: Message Transfer Part NA: Nature of Address (SCCP) NMT: Nordic Mobile Telephone NoA: Nature Of Address (ISUP) NP: Numbering Plan NRN: Network Routing Number NSS: Network and Switching Subsystem OPC: Originating Point Code PC: Point Code PLMN: Public Land Mobile Network PSTN: Public Switched Telephony Network RA: Routing Area RNC: Radio Network Controller RNS: Radio Network Subsystem SA: Service Area SAI: Send Authentication Info SCP: Service Control Point SCCP: Signaling Connection Control Part SendIMSI_ack: SendIMSI acknowledgement SGSN: Service GPRS Support Node SIM: Subscriber Identity Module SM: Short Message SMSC: Short Message Service Center SRI: Send Routing Info
111
SRI_ack: Send Routing Info acknowledgement SRIfLCS: Send Routing Info for Location SRIfLCS_ack: Send Routing Info for Location acknowledgement SRIfSM: Send Routing Info for Short Message SRIfSM_ack: Send Routing Info for Short Message acknowledgement SRN: Signaling Relay Node SS7: Signaling System number 7 SSN: SubSystem Number STP: Signaling Transfer Point TBCD: Telephony Binary Coded Decimal TCAP: Transaction Capabilities Application Part TCP: Transport Control Protocol TT: Translation Type UDT: Unit Data Message UL: Update Location UMSC: UMTS Mobile service Switching Center UMTS: Universal Mobile Telecommunications System VLR: Visitor Location Register XUDT: Extended Unit Data Message
9.3
Symbols
The following symbols and their meanings apply for the entire document.
Node B
Radio Network Controller (RNC)
112
UMTS Mobile service Switching Center (UMSC) and Visitor Location Register (VLR)
Home Location Register (HLR) and Authentication Center (AuC)
Signaling Transfer Point (STP)
Service GPRS Support Node (SGSN)
Gateway GPRS Support Node (GGSN)
Short Message Service Center (SMSC)
Service Control Point (SCP)
Gateway Mobile Location Center (GMLC)
Mobile Station (MS)
113
Radio link, both voice and signaling traffic
Voice traffic link
Signaling traffic link
External Network
Internal or External Application
114
10 References
10 References
[1] MOULY, Michel and PAUTET, Marie-Bernadette, The GSM System for Mobile Communications, A comprehensive overview of the European Digital Cellular Systems, 1992, ISBN 2-9507190-0-7 GPRS System Survey, 1999, Ericsson Radio Systems AB, Internal reference: 038 02-108 876 Rev B UMTS System Description, 2000, Nortel Networks, Internal reference: UMT/TRD/CN/0003 01.03/EN Number Portability For GSM- To GSM Networks In FNR, 2001, Ericsson, Internal reference: 4/155 17-ANT 307 01/7 Uen B GSM MSC/VLR Operation, Student Text, 1998, Ericsson Radio Systems AB, Internal reference: EN/LZT 123 3976 R6A Especificacin Tcnica de la Solucin de Red para la Conservacin de Numeracin en la Redes Telefnicas Pblicas Mviles, Versin 1.0, 2000, Comisin del Mercado de las Telecomunicaciones (CMT) http://www.cmt.es/cmt/document/decisiones/2000/RE-00-06-08-08.pdf Mobile Number Portability, 2000, Network Interoperability Consultative Committee, Internal reference: ND1208:2000/03 Especificacin tcnica de portabilidad de mvil, 2000, Airtel Mvil S.A., Internal reference: IC0/ES/023-00 UMTS02 Packet Core Validation Detailed Test Plan for VODAFONE (Part 1), 2002, Nortel Networks Introduccin al Sistema de Sealizacin N 7, 2000, Vodafone, Internal Vodafone course material, Teacher: RODRGUEZ, Carlos Mobile Application Part (MAP) specification, 2004, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC), Internal reference: 3GPP TS 29.002 CCS#7 Network Survey, 1997, Siemens, Siemens training course material, Teacher: Siemens Training Service Cdigos de operador de portabilidad, Updated: 27-01-2004, CMT http://www.cmt.es/cmt/centro_info/numeracion/content.html SORIA LUQUE, Nicols, Proyecto Una sola SIM Flexible Allocation, Anlisis de soluciones, 2003, Vodafone, Internal reference: IC0/IN/008-03 BALLESTEROS HERRAIZ, Beatriz, PAZOS SOUTO, Begoa and VAZQUEZ GONZALEZ, ngel, Configuracin de portabilidad mvil en nodos de red, Versin 1, 2000, Airtel, Internal reference: IC0/NT/004-00
[2] [3] [4] [5] [6]
[7] [8] [9] [10] [11]
[12] [13] [14] [15]
115
10 References
[16] [17] [18] [19]
GSMworld IR21 database, https://infocentre.gsm.org/ (requires membership login) Feature Description SCP R9.1, 2001, Ericsson, Ericsson training course material, Teacher: Ericsson Spain Training Service ALMENAR BELENGUER, Pedro, Descripcin de CAMEL fase 2, Versin 1, 2000, Airtel, Internal reference: ID0/IN/003-00 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 Chris Dulya, Service Relay Node and Mobile Number Portability, System Requirements Specification, 2003, Sema Group sae, Internal reference: OPI.MNP.SRS.v3.5
[20]
116
Appendix A
Appendix A
Update Location (UL)
+---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |11:07:05,404,816 1:A (Rx):16 MAP BEG Update Location | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1000111 |Backward Sequence Number |71 | |1------- |Backward Indicator Bit |1 | |-0010100 |Forward Sequence Number |20 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |3009 | |**b14*** |Originating Point Code |3001 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0111---- |Signalling Link Selection |7 | |00001001 |SCCP Message Type |9 | |----0001 |Protocol Class |Class 1 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00010000 |Pointer to parameter |16 | |00011011 |Pointer to parameter |27 | |Called address parameter | |00001101 |Parameter Length |13 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-1------ |Routing Indicator |Route on DPC + Subsystem No. | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0111---- |Numbering Plan |ISDN/Mobile (Rec. E.214) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b60*** |Called Address Signals |346700000000012 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000111 |Subsystem number |VLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002953 | |0000---- |Filler |0 | |Data parameter | |01010111 |Parameter length |87 | |**B87*** |Data |62 55 48 03 ab 00 ff 6b 1e 28 1c ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) | |Begin | |01100010 |Tag |(APPL C [2]) | |01010101 |Length |85 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) | |00000011 |Length |3 | |***B3*** |Orig Trans ID |11206911 | |2 DialoguePortion | |01101011 |Tag |(APPL C [11]) | |00011110 |Length |30 | |2.1 DialogueExternal | |00101000 |Tag |(UNIV C External) | |00011100 |Length |28 | |2.1.1 DialogueObjectID | |00000110 |Tag |(UNIV P Obj Identifier) | |00000111 |Length |7 | |00000000 |Authority |CCITT Recommendation | |00010001 |Name Form |q | |10000110 |Rec Number |7 | |00000101 |Rec Number |73 | |00000001 |AS |1 | |00000001 |Dialog-AS |Dialogue PDU | |00000001 |Version |1 | |2.1.2 DialoguesingleASN1 | |10100000 |Tag |(CONT C [0]) | |00010001 |Length |17 | |2.1.2.1 DialogueRequest | |01100000 |Tag |(APPL C [0]) | |00001111 |Length |15 | |2.1.2.1.1 Protocol Version |
117
Appendix A
|10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000001 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Invoke |10100001 |Tag |00101010 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00000010 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00100010 |Length |3.1.3.1 IMSI |00000100 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.3.2 Network Node Number |10000001 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |Network Node Number |1111---- |Filler |3.1.3.3 VLR Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |VLR Address Signals |1111---- |Filler |3.1.3.4 VLR Capability |10100110 |Tag |00000100 |Length |3.1.3.4.1 Supported Camel Phases |10000000 |Tag |00000010 |Length |00000110 |UnusedBits |1------- |Phase1 |-0------ |Phase2 |--000000 |Filler |***B2*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |c7|94|3f|c3|c1|4b|ee|72|09|81|03|10|1b|0d|52|06| |10 |00|71|04|43|76|00|00|00|00|10|02|0b|12|07|00|11| |20 |04|43|06|07|20|59|03|57|62|55|48|03|ab|00|ff|6b| |30 |1e|28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f| |40 |80|02|07|80|a1|09|06|07|04|00|00|01|00|01|03|6c| |50 |80|a1|2a|02|01|01|02|01|02|30|22|04|08|12|04|01| |60 |00|00|00|10|f2|81|07|91|43|06|07|20|59|f3|04|07| |70 |91|43|06|07|20|59|f3|a6|04|80|02|06|80|00|00| |
|(CONT P [0]) |2 |7 |Yes |0 |(CONT C [1]) |9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Network Loc Upd |Version3 |(APPL C [12]) |EOC-encoded |(CONT C [1]) |42 |(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Update Location |(UNIV C Sequence (of)) |34 |(UNIV P OctetString) |8 |214010000000012 |15 |(CONT P [1]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002953 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002953 |15 |(CONT C [6]) |4 |(CONT P [0]) |2 |6 |Yes |No |0 |EOC
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
GPRS Update Location (GPRS UL)

+---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |14:01:51,989,729 1:B (Tx):4 MSU UDT BEG Update GPRS Location 151 3007 7424 | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-0011011 |Backward Sequence Number |27 | |1------- |Backward Indicator Bit |1 | |-0010100 |Forward Sequence Number |20 | |0------- |Forward Indicator Bit |0 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |151 |
118
Appendix A
|**b14*** |Originating Point Code |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) |Unitdata |0110---- |Signalling Link Selection |00001001 |SCCP Message Type |----0000 |Protocol Class |0000---- |Message Handling |00000011 |Pointer to parameter |00010000 |Pointer to parameter |00011011 |Pointer to parameter |Called address parameter |00001101 |Parameter Length |-------0 |Point Code Indicator |------1- |Subsystem No. Indicator |--0100-- |Global Title Indicator |-0------ |Routing Indicator |0------- |For national use |00000110 |Subsystem number |00000000 |Translation Type |----0001 |Encoding Scheme |0111---- |Numbering Plan |-0000100 |Nat. of Address Indicator |0------- |Spare |**b60*** |Called Address Signals |0000---- |Filler |Calling address parameter |00001011 |Parameter Length |-------0 |Point Code Indicator |------1- |Subsystem No. Indicator |--0100-- |Global Title Indicator |-0------ |Routing Indicator |0------- |For national use |10010101 |Subsystem number |00000000 |Translation Type |----0001 |Encoding Scheme |0001---- |Numbering Plan |-0000100 |Nat. of Address Indicator |0------- |Spare |**b44*** |Calling Address Signals |0000---- |Filler |Data parameter |01001100 |Parameter length |**B76*** |Data |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) |Begin |01100010 |Tag |01001010 |Length |1 Origination Transaction ID |01001000 |Tag |00000010 |Length |***B2*** |Orig Trans ID |2 DialoguePortion |01101011 |Tag |00011110 |Length |2.1 DialogueExternal |00101000 |Tag |00011100 |Length |2.1.1 DialogueObjectID |00000110 |Tag |00000111 |Length |00000000 |Authority |00010001 |Name Form |10000110 |Rec Number |00000101 |Rec Number |00000001 |AS |00000001 |Dialog-AS |00000001 |Version |2.1.2 DialoguesingleASN1 |10100000 |Tag |00010001 |Length |2.1.2.1 DialogueRequest |01100000 |Tag |00001111 |Length |2.1.2.1.1 Protocol Version |10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00100000 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |00100100 |Length |3.1 Invoke |10100001 |Tag |00100010 |Length |3.1.1 Invoke ID
|3007
| | | |6 | |9 | |Class 0 | |No special options | |3 | |16 | |27 | | |13 | |PC absent | |SSN present | |Has transln,n-plan,code,natur | |Route on Global Title | |0 | |HLR | |Not used | |BCD, odd number of digits | |ISDN/Mobile (Rec. E.214) | |International number | |0 | |346070000000036 | |0 | | |11 | |PC absent | |SSN present | |Has transln,n-plan,code,natur | |Route on Global Title | |0 | |SGSN | |Not used | |BCD, odd number of digits | |ISDN/Telephony (E.164/E.163) | |International number | |0 | |34607002966 | |0 | | |76 | |62 4a 48 02 1d 00 6b 1e 28 1c 06 ...| | | |(APPL C [2]) | |74 | | |(APPL P [8]) | |2 | |7424 | | |(APPL C [11]) | |30 | | |(UNIV C External) | |28 | | |(UNIV P Obj Identifier) | |7 | |CCITT Recommendation | |q | |7 | |73 | |1 | |Dialogue PDU | |1 | | |(CONT C [0]) | |17 | | |(APPL C [0]) | |15 | | |(CONT P [0]) | |2 | |7 | |Yes | |0 | | |(CONT C [1]) | |9 | | |(UNIV P Obj Identifier) | |7 | |CCITT | |Identified-organization | |ETSI | |Mobile Domain | |GSM-Network | |AC-ID | |GPRS Location Update | |Version3 | | |(APPL C [12]) | |36 | | |(CONT C [1]) | |34 | |
119
Appendix A
|00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00010111 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00011010 |Length |3.1.3.1 IMSI |00000100 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.3.2 SGSN Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |SGSN Number |1111---- |Filler |3.1.3.3 SGSN Address |00000100 |Tag |00000101 |Length |00------ |Address Type |--000100 |Address Length |***B4*** |SGSN Address
|(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Update GPRS Location |(UNIV C Sequence (of)) |26 |(UNIV P OctetString) |8 |214010000000036 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002966 |15 |(UNIV P OctetString) |5 |IPv4 Address |4 |ac 14 33 02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Send Routing Info (SRI)

+---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |13:13:20,457,564 1:B (Rx):3 MTP-L2 MSU SCCP UDT MAP BEG | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1101101 |Backward Sequence Number |109 | |1------- |Backward Indicator Bit |1 | |-0101001 |Forward Sequence Number |41 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--00---- |Sub-Service: Priority |Spare/priority 0 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |151 | |**b14*** |Originating Point Code |3000 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0101---- |Signalling Link Selection |5 | |00001001 |SCCP Message Type |9 | |----0001 |Protocol Class |Class 1 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00001110 |Pointer to parameter |14 | |00011001 |Pointer to parameter |25 | |Called address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Called Address Signals |34607000014 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00001000 |Subsystem number |MSC | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002950 | |0000---- |Filler |0 | |Data parameter | |10001011 |Parameter length |139 | |**B139** |Data |62 81 88 48 03 e9 00 0a 6b 1e 28 ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) BEG (= Begin) | |--> DECODING ERROR: IE not allowed (at position 26 hex) | |Begin | |01100010 |Tag |(APPL C [2]) | |***B2*** |Length |136 | |1 Origination Transaction ID | |01001000 |Tag |(APPL P [8]) |
120
Appendix A
|00000011 |Length |***B3*** |Orig Trans ID |2 DialoguePortion |01101011 |Tag |00011110 |Length |2.1 DialogueExternal |00101000 |Tag |00011100 |Length |2.1.1 DialogueObjectID |00000110 |Tag |00000111 |Length |00000000 |Authority |00010001 |Name Form |10000110 |Rec Number |00000101 |Rec Number |00000001 |AS |00000001 |Dialog-AS |00000001 |Version |2.1.2 DialoguesingleASN1 |10100000 |Tag |00010001 |Length |2.1.2.1 DialogueRequest |01100000 |Tag |00001111 |Length |2.1.2.1.1 Protocol Version |10000000 |Tag |00000010 |Length |00000111 |UnusedBits |1------- |Version 1 |-0000000 |Filler |2.1.2.1.2 Application Context Name |10100001 |Tag |00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000101 |Application Context |00000011 |Version |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Invoke |10100001 |Tag |01011101 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |00010110 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |01010101 |Length |3.1.3.1 MS Isdn Address Number |10000000 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |MS ISDN Address Signals |1111---- |Filler |3.1.3.2 Interrogation Type |10000011 |Tag |00000001 |Length |00000000 |Interrogation Type |3.1.3.3 Gmsc Address |10000110 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |GMSC Address Signals |1111---- |Filler |3.1.3.4 Call Reference Number |10000111 |Tag |00000101 |Length |***B5*** |Call Reference Number |3.1.3.5 Network Signal Info |10101010 |Tag |00001010 |Length |3.1.3.5.1 Protocol Id |00001010 |Tag |00000001 |Length |00000100 |Protocol Id |3.1.3.5.2 Signal Info |00000100 |Tag |00000101 |Length |***B5*** |Signal Info |3.1.3.6 Camel Info |10101011 |Tag |00000100 |Length |3.1.3.6.1 Supported Camel Phases
|3 |15269898 |(APPL C [11]) |30 |(UNIV C External) |28 |(UNIV P Obj Identifier) |7 |CCITT Recommendation |q |7 |73 |1 |Dialogue PDU |1 |(CONT C [0]) |17 |(APPL C [0]) |15 |(CONT P [0]) |2 |7 |Yes |0 |(CONT C [1]) |9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Loc Info Retrieval |Version3 |(APPL C [12]) |EOC-encoded |(CONT C [1]) |93 |(UNIV P Integer) |1 |1 |(UNIV P Integer) |1 |Send Routing Info |(UNIV C Sequence (of)) |85 |(CONT P [0]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607000014 |15 |(CONT P [3]) |1 |Basic call |(CONT P [6]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607002950 |15 |(CONT P [7]) |5 |00 02 01 00 01 |(CONT C [10]) |10 |(UNIV P Enumerated) |1 |Ets-300102-1 |(UNIV P OctetString) |5 |04 03 80 90 a3 |(CONT C [11]) |4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
121
Appendix A
|00000011 |Tag |00000010 |Length |00000110 |UnusedBits |1------- |Phase1 |-1------ |Phase2 |--000000 |Filler |3.1.3.7 Extension Container |10101101 |Tag |00100101 |Length |3.1.3.7.1 Private Extension List |10100000 |Tag |00100011 |Length |3.1.3.7.1.1 Private Extension |00110000 |Tag |00100001 |Length |3.1.3.7.1.1.1 Extension1 ID |00000110 |Tag |00001001 |Length |***B9*** |ID |3.1.3.7.1.1.2 Unknown Parameter |10100100 |Tag |00010100 |Length |**B20*** |Contents |***B2*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |ed|a9|3f|c3|97|00|ee|52|09|81|03|0e|19|0b|12|06| |10 |00|11|04|43|06|07|00|10|04|0b|12|08|00|11|04|43| |20 |06|07|20|59|00|8b|62|81|88|48|03|e9|00|0a|6b|1e| |30 |28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f|80| |40 |02|07|80|a1|09|06|07|04|00|00|01|00|05|03|6c|80| |50 |a1|5d|02|01|01|02|01|16|30|55|80|07|91|43|06|07| |60 |00|10|f4|83|01|00|86|07|91|43|06|07|20|59|f0|87| |70 |05|00|02|01|00|01|aa|0a|0a|01|04|04|05|04|03|80| |80 |90|a3|ab|04|03|02|06|c0|ad|25|a0|23|30|21|06|09| |90 |2a|86|3a|00|89|61|3a|01|00|a4|14|30|03|81|01|06| |A0 |30|03|81|01|07|30|03|81|01|08|30|03|81|01|0a|00| |B0 |00| | | | | | | | | | | | | | | |
|(UNIV P BitString) |2 |6 |Yes |Yes |0 |(CONT |37 |(CONT |35 |(UNIV |33 |(UNIV |9 |2a 86 |(CONT |20 |30 03 |EOC
| | | | | | | C [13]) | | | C [0]) | | | C Sequence (of)) | | | P Obj Identifier) | | 3a 00 89 61 3a 01 00 | | C [4]) | | 81 01 06 30 03 81 01 07 30 ...| |
Send Routing Info for Short Message (SRIfSM)

CT (1) - Protocol Level Display (16) 08/25/03 13:20:01 367 ms Link: STP51<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
122
Appendix A
Length: 9 octets Object Identifier Tag Length: 7 octets Application Context Name ccitt identified organisation mobile domain gsm Network ac_id ac : shortMsgGateway 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 43 16 50 31 13 06 0b 12 08 00 11 04 43 06 62 47 48 04 d2 d1 0a 00 6b 1e 28 1c 06 07 01 01 a0 11 60 0f 80 02 07 80 a1 09 06 07 14 02 6c 1f a1 1d 02 01 00 02 01 2d 30 15 50 31 13 f6 81 01 00 82 07 91 43 06 07 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1|0100010 0|0100111 00|111111 1100|0011 0010 0111 01|000010 0001 1100 1010|0001 0000 1001 0000 0000 0000 0011 0000 1110 0001 1001 0000 1011 0001 0010 0000 0110 0000 0000 0001|0001 0|0000100 0100|0011 0001|0110 0101|0000 0011|0001 0001|0011 0000|0110 0000 1011 0001 0010 0000 1000 0000 0000 0001|0001 0|0000100 0100|0011 0000|0110 0000|0111 0011|0000 0011|0001 0000|0111 0100 1001 0110 0010 0|1000111 0100 1000 0|0000100 1101 0010 1101 0001 0000 1010 0000 0000 0110 1011 0|0011110 0010 1000 0|0011100 0000 0110 0|0000111 0000 0000 0001 0001 1000 0110 0000 0101 0000 0001 0000 0001 0000 0001 1010 0000 0|0010001 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
etsi version 2
12 07 00 04 80 31
06 30 11 00 07 f7
00 31 86 00 91
11 07 05 01 43
04 49 01 00 16
BIB = 1, BSN = 34 FIB = 0, FSN = 39 Length Indicator : MSU, LI = 63 octets Service Indicator = SCCP, SSF = Reserved DPC : 551 dec, 0227 hex OPC : 1137 dec, 0471 hex SLS : 10 dec, A hex MT = Unitdata (UDT) Protocol Class = class 0 Pointer to Called Party Address Parameter = 3 Pointer to Calling Party Address Parameter = 14 Pointer to Data Parameter = 25 LI of Called Party Address parameter = 11 octet(s) Addr Ind: Route=GT; GT=TT&NP&ES&NoA; PC=N; SSN=Y Subsystem Number = 6 HLR Home Location Register Translation Type = 0 Translation Type Not Used Numbering Plan & Encoding Scheme Nature of Address Indicator Address Signal Address Signal Address Signal Address Signal Address Signal Address Signal LI of Calling Party Address parameter = 11 octet(s) Addr Ind: Route=GT; GT=TT&NP&ES&NoA; PC=N; SSN=Y Subsystem Number = 8 MSC Mobile Switching Centre Translation Type = 0 Translation Type Not Used Numbering Plan & Encoding Scheme Nature of Address Indicator Address Signal Address Signal Address Signal Address Signal Address Signal Address Signal LI of Data parameter = 73 octet(s) TCAP Message Type = Begin Total TCAP Message length = 71 octet(s) Originating Transaction ID tag Originating Transaction ID length = 4 octet(s) Transaction ID = D2D10A00 hex Transaction ID Transaction ID Transaction ID Dialogue tag Dialogue length = 30 octet(s) External tag External length = 28 octet(s) Object Identifier tag Object Identifier length = 7 octet(s) Dialogue-as-ID value ccitt Dialogue-as-ID value q Dialogue-as-ID value 773 Dialogue-as-ID value Dialogue-as-ID value as Dialogue-as-ID value DialoguePDU Dialogue-as-ID value version 1 Single-ASN.1-type tag Single-ASN.1-type length = 17 octet(s)
F F V V V V V V V V V V V V V V V V V V V V V V V V V V V V M M M M M M M M M M M M M M M M M M M M M M M
123
Appendix A
62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
M M O O O O M M M M M M M M M M M M M M M M M M M M F M M M M M M M M M M M M M M M M M M M M M M M
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
0110 0000 0|0001111 1000 0000 0|0000010 0000 0111 1000 0000 1010 0001 0|0001001 0000 0110 0|0000111 0000 0100 0000 0000 0000 0000 0000 0001 0000 0000 0001 0100 0000 0010 0110 1100 0|0011111 1010 0001 0|0011101 0000 0010 0|0000001 0000 0000 0000 0010 0|0000001 0010 1101 0011 0000 0001 0101 1000 0000 0000 0111 1001|0001 0100|0011 0001|0110 0101|0000 0011|0001 0001|0011 1111|0110 1000 0001 0000 0001 0000 0000 1000 0010 0000 0111 1001|0001 0100|0011 0000|0110 0000|0111 0011|0000 0011|0001 1111|0111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Dialogue Request (AARQ-apdu) tag Dialogue Request (AARQ-apdu) length = 15 octet(s) Protocol Version tag Protocol Version length = 2 octet(s) Protocol Version Protocol Version Application Context Name tag Application Context Name length = 9 octet(s) Object Identifier tag Object Identifier length = 7 octet(s) Application Context Name ccitt identified organisation Application Context Name etsi Application Context Name mobile domain Application Context Name GSM Network Application Context Name AC Application Context Name shortMsgGateway Application Context Name version 2 Component Portion tag Component Portion length = 31 octet(s) Component Type Tag = Invoke Component length = 29 octet(s) Invoke ID tag Invoke ID length = 1 octet(s) Invoke ID = 0 dec, 00 hex Local Operation Code tag Local Operation Code length = 1 octet(s) Operation Code = Send Routing Info for Short Message Sequence Tag Sequence length = 21 octet(s) MS ISDN Tag MS ISDN length = 7 octet(s) International number, ISDN/telephony number plan MS ISDN Digits = 34610513316 MS ISDN Digits MS ISDN Digits MS ISDN Digits MS ISDN Digits MS ISDN Digits SM RP PRI Tag SM RP PRI length = 1 octet(s) SM RP PRI = FALSE Service Centre Address Tag Service Centre Address length = 7 octet(s) International number, ISDN/telephony number plan Service Centre Address Digits = 34607003137 Service Centre Address Digits Service Centre Address Digits Service Centre Address Digits Service Centre Address Digits 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 |
124
Appendix A
|--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 |
125
Appendix A
|00000010 |Tag |00000001 |Length |00000000 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |01000111 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00011000 |Length |3.1.3.1 Subscriber Identity Constr |10100000 |Tag |00001001 |Length |3.1.3.1.1 MS Isdn Address Number |10000001 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |MS ISDN Address Signals |1111---- |Filler |3.1.3.2 Requested Info |10100001 |Tag |00000010 |Length |3.1.3.2.1 Location Information |10000000 |Tag |00000000 |Length |3.1.3.3 GSM Scf Address |10000011 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |Gsm Scf Address |1111---- |Filler
|(UNIV P Integer) |1 |0 |(UNIV P Integer) |1 |Any Time Interrogation |(UNIV C Sequence (of)) |24 |(CONT C [0]) |9 |(CONT P [1]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607000014 |15 |(CONT C [1]) |2 |(CONT P [0]) |0 |(CONT P [3]) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607001910 |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) |
126
Appendix A
|--> DECODING ERROR: Parameter error (at position 26 hex) |--> DECODING ERROR: IE not allowed (at position 5A hex) |--> DECODING ERROR: IE not allowed (at position 64 hex) |--> DECODING ERROR: IE not allowed (at position 67 hex) |---v--- DECODING ERROR: Parameter error ---v--|Begin |01100010 |Tag |(APPL C [2]) |01000001 |Length |65 |1 Origination Transaction ID |01001000 |Tag |(APPL P [8]) |00000100 |Length |4 |***B4*** |Orig Trans ID |503316741 |2 Dialogue Portion |01101011 |Tag |(APPL C [11]) |00011110 |Length |30 |2.1 Dialogue External |00101000 |Tag |(UNIV C External) |00011100 |Length |28 |2.1.1 Dialogue Object ID |00000110 |Tag |(UNIV P Obj Identifier) |00000111 |Length |7 |00000000 |Authority |CCITT Recommendation |00010001 |Name Form |q |10000110 |Rec Number |7 |00000101 |Rec Number |73 |00000001 |AS |1 |00000001 |Dialog-AS |Dialogue PDU |00000001 |Version |1 |2.1.2 Dialogue single ASN1 |10100000 |Tag |(CONT C [0]) |00010001 |Length |17 |2.1.2.1 Dialogue Request |01100000 |Tag |(APPL C [0]) |00001111 |Length |15 |2.1.2.1.1 Protocol Version |10000000 |Tag |(CONT P [0]) |00000010 |Length |2 |00000111 |UnusedBits |7 |1------- |Version 1 |Yes |-0000000 |Filler |0 |2.1.2.1.2 Application Context Name |10100001 |Tag |(CONT C [1]) |00001001 |Length |9 |2.1.2.1.2.1 ACN Object ID |00000110 |Tag |(UNIV P Obj Identifier) |00000111 |Length |7 |0000---- |ObjId |CCITT |----0100 |Organization |Identified-organization |00000000 | |ETSI |00000000 |Domain |Mobile Domain |00000001 |Mobile Subdomain |GSM-Network |00000000 |Common Component ID |AC-ID |00001110 |Application Context |Info Retrieval |00000011 |Version |- unknown / undefined |3 Component Portion |01101100 |Tag |(APPL C [12]) |00011001 |Length |25 |3.1 Invoke |10100001 |Tag |(CONT C [1]) |00010111 |Length |23 |3.1.1 Invoke ID |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00000001 |Invoke ID value |1 |3.1.2 Local Operation |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00111000 |Operation Code |Send Authentication Info |3.1.3 Parameter Sequence |00110000 |Tag |(UNIV C Sequence (of)) |00001111 |Length |15 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.1 Unknown Parameter |10000000 |Tag |(CONT P [0]) |00001000 |Length |8 |***B8*** |Contents |12 04 01 03 00 00 50 f2 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.2 Integer |00000010 |Tag |(UNIV P Integer) |00000001 |Length |1 |00000001 |Integer Value |1 |---v--- DECODING ERROR: IE not allowed ---v--|3.1.3.3 Unknown Parameter |10000001 |Tag |(CONT P [1]) |00000000 |Length |0 +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |87|87|3f|c3|98|c0|20|90|09|81|03|0e|19|0b|12|06| |10 |00|11|04|43|06|07|00|11|01|0b|12|07|00|11|04|43| |20 |06|07|20|71|00|43|62|41|48|04|1e|00|01|05|6b|1e| |30 |28|1c|06|07|00|11|86|05|01|01|01|a0|11|60|0f|80| |40 |02|07|80|a1|09|06|07|04|00|00|01|00|0e|03|6c|19| |50 |a1|17|02|01|01|02|01|38|30|0f|80|08|12|04|01|03| |60 |00|00|50|f2|02|01|01|81|00| | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
127
Appendix A
Send Routing Info acknowledgement (SRI_ack)

+---------+---------------------------------------------+------------------------------------+ |BITMASK |ID Name |Comment or Value | +---------+---------------------------------------------+------------------------------------+ |13:13:20,615,575 1:B (Rx):7 MTP-L2 MSU SCCP UDT MAP END | |MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) | |Message Signal Unit | |-1011011 |Backward Sequence Number |91 | |1------- |Backward Indicator Bit |1 | |-0100000 |Forward Sequence Number |32 | |1------- |Forward Indicator Bit |1 | |--111111 |Length Indicator |63 | |00------ |Spare |0 | |----0011 |Service Indicator |SCCP | |--10---- |Sub-Service: Priority |priority 2 (U.S.A. only) | |11------ |Sub-Service: Network Ind |National message 1 | |**b14*** |Destination Point Code |3000 | |**b14*** |Originating Point Code |3001 | |ITU-T White Book SCCP (SCCP) UDT (= Unitdata) | |Unitdata | |0011---- |Signalling Link Selection |3 | |00001001 |SCCP Message Type |9 | |----0000 |Protocol Class |Class 0 | |1000---- |Message Handling |Return message on error | |00000011 |Pointer to parameter |3 | |00001110 |Pointer to parameter |14 | |00011001 |Pointer to parameter |25 | |Called address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-1------ |Routing Indicator |Route on DPC + Subsystem No. | |0------- |For national use |0 | |00001000 |Subsystem number |MSC | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Called Address Signals |34607002950 | |0000---- |Filler |0 | |Calling address parameter | |00001011 |Parameter Length |11 | |-------0 |Point Code Indicator |PC absent | |------1- |Subsystem No. Indicator |SSN present | |--0100-- |Global Title Indicator |Has transln,n-plan,code,natur | |-0------ |Routing Indicator |Route on Global Title | |0------- |For national use |0 | |00000110 |Subsystem number |HLR | |00000000 |Translation Type |Not used | |----0001 |Encoding Scheme |BCD, odd number of digits | |0001---- |Numbering Plan |ISDN/Telephony (E.164/E.163) | |-0000100 |Nat. of Address Indicator |International number | |0------- |Spare |0 | |**b44*** |Calling Address Signals |34607002954 | |0000---- |Filler |0 | |Data parameter | |01011000 |Parameter length |88 | |**B88*** |Data |64 56 49 03 e9 00 0a 6b 2a 28 28 ...| |E-GSM 09.02 (MAP) Version 6.4.0 (MAP) END (= End) | |End | |01100100 |Tag |(APPL C [4]) | |01010110 |Length |86 | |1 Destination Transaction ID | |01001001 |Tag |(APPL P [9]) | |00000011 |Length |3 | |***B3*** |Dest Trans ID |15269898 | |2 DialoguePortion | |01101011 |Tag |(APPL C [11]) | |00101010 |Length |42 | |2.1 DialogueExternal | |00101000 |Tag |(UNIV C External) | |00101000 |Length |40 | |2.1.1 DialogueObjectID | |00000110 |Tag |(UNIV P Obj Identifier) | |00000111 |Length |7 | |00000000 |Authority |CCITT Recommendation | |00010001 |Name Form |q | |10000110 |Rec Number |7 | |00000101 |Rec Number |73 | |00000001 |AS |1 | |00000001 |Dialog-AS |Dialogue PDU | |00000001 |Version |1 | |2.1.2 DialoguesingleASN1 | |10100000 |Tag |(CONT C [0]) | |00011101 |Length |29 | |2.1.2.1 DialogueResponse | |01100001 |Tag |(APPL C [1]) | |00011011 |Length |27 | |2.1.2.1.1 Protocol Version | |10000000 |Tag |(CONT P [0]) | |00000010 |Length |2 | |00000111 |UnusedBits |7 | |1------- |Version 1 |Yes | |-0000000 |Filler |0 | |2.1.2.1.2 Application Context Name | |10100001 |Tag |(CONT C [1]) |
128
Appendix A
|00001001 |Length |2.1.2.1.2.1 ACN Object Id |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00000101 |Application Context |00000011 |Version |2.1.2.1.3 ResultType |10100010 |Tag |00000011 |Length |2.1.2.1.3.1 Associate-Result |00000010 |Tag |00000001 |Length |00000000 |Associate Result |2.1.2.1.4 ResultSourceDiagnostic |10100011 |Tag |00000101 |Length |2.1.2.1.4.1 DialogueServiceUser |10100001 |Tag |00000011 |Length |2.1.2.1.4.1.1 Dialogue Service User Value |00000010 |Tag |00000001 |Length |00000000 |Dialogue Service User |3 Component Portion |01101100 |Tag |10000000 |Length |3.1 Return Result Last |10100010 |Tag |00011111 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000001 |Invoke ID value |3.1.2 Return Result Sequence |00110000 |Tag |00011010 |Length |3.1.2.1 Local Operation |00000010 |Tag |00000001 |Length |00010110 |Operation Code |3.1.2.2 Send Routing Info Res (v3) |10100011 |Tag |10000000 |Length |3.1.2.3 IMSI |10001001 |Tag |00001000 |Length |**b60*** |MCC + MNC + MSIN |1111---- |FILLER |3.1.2.4 Roaming Number |00000100 |Tag |00000111 |Length |1------- |Extension Indicator |-001---- |Nature of Address |----0001 |Numbering Plan Indicator |**b44*** |Roaming Address Signals |1111---- |Filler |**b16*** |3.1.2.4 Length |**b16*** |3 Length +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F | +----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |db|a0|3f|e3|b8|4b|ee|32|09|80|03|0e|19|0b|52|08| |10 |00|11|04|43|06|07|20|59|00|0b|12|06|00|11|04|43| |20 |06|07|20|59|04|58|64|56|49|03|e9|00|0a|6b|2a|28| |30 |28|06|07|00|11|86|05|01|01|01|a0|1d|61|1b|80|02| |40 |07|80|a1|09|06|07|04|00|00|01|00|05|03|a2|03|02| |50 |01|00|a3|05|a1|03|02|01|00|6c|80|a2|1f|02|01|01| |60 |30|1a|02|01|16|a3|80|89|08|12|04|01|00|00|00|10| |70 |f4|04|07|91|43|06|17|85|30|f2|00|00|00|00| | |
|9 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AC-ID |Loc Info Retrieval |Version3 |(CONT C [2]) |3 |(UNIV P Integer) |1 |Accepted |(CONT C [3]) |5 |(CONT C [1]) |3 |(UNIV P Integer) |1 |Null |(APPL C [12]) |EOC-encoded |(CONT C [2]) |31 |(UNIV P Integer) |1 |1 |(UNIV C Sequence (of)) |26 |(UNIV P Integer) |1 |Send Routing Info |(CONT C [3]) |EOC-encoded |(CONT P [9]) |8 |214010000000014 |15 |(UNIV P OctetString) |7 |No Extension |International number |ISDN Telephony No plan (E.164) |34607158032 |15 |EOC |EOC
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Initial Address Message (IAM)

17:20:54 014 ms Link: STP51<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
129
Appendix A
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)
130
+---------+---------------------------------------------+------------------------------------+---------------------------------+------------------+---------------------------+ |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 | |00001110 |Pointer to parameter |14 |14 |00001110 |00001110 | |00011001 |Pointer to parameter |25 |25 |00011001 |00011001 | |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
131
|-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 | |10000000 |Length |EOC-encoded |'06'H |10000000 |10000000 | |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 | |10000000 |Length |EOC-encoded |'60'H |10000000 |10000000 | |2.1.2.1 DialogueRequest | |01100000 |Tag |(APPL C [0]) |'60'H |01100000 |01100000 | |10000000 |Length |EOC-encoded |'80'H |10000000 |10000000 | |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 | |10000000 |Length |EOC-encoded |'06'H |10000000 |10000000 | |2.1.2.1.2.1 ACN Object Id | |00000110 |Tag |(UNIV P Obj Identifier) |'06'H |00000110 |00000110 | |00000111 |Length |7 |'04'H |00000111 |00000111 | |0000---- |ObjId |CCITT |0 |0000---|0000---| |----0100 |Organization |Identified-organization |4 |----0100 |----0100 |
Appendix A
132
|ETSI |Mobile Domain |GSM-Network |AC-ID |- unknown / undefined |Version3 |EOC |(CONT C [30]) |15 |(UNIV C External) |13 |(UNIV P Obj Identifier) |7 |CCITT |Identified-organization |ETSI |Mobile Domain |GSM-Network |AS-ID |Map-Dialogue PDU |1 |(CONT C [0]) |2 |(CONT C [0]) |0 |EOC |EOC |EOC |EOC |(APPL C [12]) |30 |(CONT C [1]) |28 |(UNIV P Integer) |1 |0 |(UNIV P Integer) |1 |- unknown / undefined |(UNIV C Sequence (of)) |20 |'6c'H |'a1'H |'a1'H |'02'H |'02'H |'00'H |0 |'02'H |'55'H |85 |'30'H |'80'H |'a0'H |'00'H |'0000'H |'0000'H |'0000'H |'0000'H |'a0'H |'a0'H |'06'H |'04'H |0 |4 |0 |0 |1 |1 |1 |1 |00000110 |00000111 |0000---|----0100 |00000000 |00000000 |00000001 |00000001 |00000001 |00000001 |10100000 |00000010 |10100000 |00000000 |00000000 |00000000 |00000000 |00000000 |01101100 |00011110 |10100001 |00011100 |00000010 |00000001 |00000000 |00000010 |00000001 |01010101 |00110000 |00010100 |'28'H |'06'H |00101000 |00001101 |'be'H |'28'H |10111110 |00001111
|0 |0 |1 |0 |37 |3 |'0000'H
|00000000 |00000000 |00000001 |00000000 |00100101 |00000011 |00000000 00000000
|00000000 |00000000 |00000001 |00000000 |00100101 |00000011 |00000000 00000000 |10111110 |00001111 |00101000 |00001101 |00000110 |00000111 |0000---|----0100 |00000000 |00000000 |00000001 |00000001 |00000001 |00000001 |10100000 |00000010
00000000 00000000 00000000 00000000
|10100000 |00000000 |00000000 |00000000 |00000000 |00000000 |01101100 |00011110 |10100001 |00011100 |00000010 |00000001 |00000000 |00000010 |00000001 |01010101 |00110000 |00010100
|00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000000 |Common Component ID |00100101 |Application Context |00000011 |Version |***B2*** |2 Length |2.1.2.1.3 User Info |10111110 |Tag |00001111 |Length |2.1.2.1.3.1 User Info External |00101000 |Tag |00001101 |Length |2.1.2.1.3.1.1 User Info Object ID |00000110 |Tag |00000111 |Length |0000---- |ObjId |----0100 |Organization |00000000 | |00000000 |Domain |00000001 |Mobile Subdomain |00000001 |Common Component ID |00000001 |AS-ID Branch |00000001 |AS Version |2.1.2.1.3.1.2 User Info single ASN1 |10100000 |Tag |00000010 |Length |2.1.2.1.3.1.2.1 MAP-open |10100000 |Tag |00000000 |Length |***B2*** |2 Length |***B2*** |2 Length |***B2*** |2 Length |***B2*** |2 Length |3 Component Portion |01101100 |Tag |00011110 |Length |3.1 Invoke |10100001 |Tag |00011100 |Length |3.1.1 Invoke ID |00000010 |Tag |00000001 |Length |00000000 |Invoke ID value |3.1.2 Local Operation |00000010 |Tag |00000001 |Length |01010101 |Operation Code |3.1.3 Parameter Sequence |00110000 |Tag |00010100 |Length |3.1.3.1 Unknown Parameter
00000000 00000000 00000000 00000000
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Appendix A
133
|10000000 |Tag |00000111 |Length |***B7*** |Contents |3.1.3.2 Unknown Parameter |10100001 |Tag |00001001 |Length |***B9*** |Contents |(CONT C [1]) |9 |81 07 91 43 06 07 00 30 f7 |'a1'H |'81'H |81 07 91 43 06 07 00 30 f7 |10100001 |00001001 |10000001
|(CONT P [0]) |7 |91 43 06 07 30 99 f0
|'80'H |'91'H |91 43 06 07 30 99 f0
|10000000 |00000111 |10010001
|10000000 |00000111 ***B6** |10010001 01000011 |10100001 |00001001 ***B8** |10000001 00000111
| | ***B5** | | | | ***B7** |
Appendix A
134
Appendix B
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. The bandwidth requirements for the SRN application at the peak transaction rate of the provisioning interface will be.
[Req 4]
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 GPRS UL SRI SRIfSM ATI SAI SRIfLCS SendIMSI Weighted Average
9% 5% 27% 39% 5% 10% 2% 3% 100%
130/1040 120/960 120/960 140/1120 150/1200 110/880 130/1040 120/960 129/1035
62 67 67 57 53 73 62 67 62
7877 8533 8533 7314 6827 9309 7877 8533 7913
3151 3413 3413 2926 2731 3724 3151 3413 3165
Assuming the SRN application receives messages with the distribution given in the table, the average message length would be 129 bytes.
135
Appendix B
[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. Contains the possible HLRs and routing data associated. Contains the possible NRNs. Contains the association between MAP operation code and Error Code to be sent in case there is an error during MAP processing. Contains configuration parameter names and their values. Contains configuration parameters that are treated as Boolean. Contains the data necessary to normalize an MSISDN. Contains the data necessary to combine a NRN and an MSISDN. Contains the data necessary to translate an MGT to an IMSI.
HLRLOCATION
1 000
NETWORK TCAPERRORCODES
1 000 200
PARAMETERS
200
FLAGS
200
MSISDNNORMALIZATION 128
COMBINATION
128
MGTTRANSLATION
128
136
Appendix B
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 Peak Transaction Rate
200 ms 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.
137
Budget
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 Politcnica 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 Team work on the internal Vodafone project
150
150 60 160 120 400

1040
Development of SRN node model
Problem definition Deduction and research of traffic cases SRN node definition
Composition of master thesis document

Total man hours
composition
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) Microsoft Windows 2000
6 months 6 months
1000 300
4 years 3 years
125 50
138
Budget
Microsoft Office 2000 Printer Office material and binding

Total material cost
6 months 6 months
480 240 100
3 years 6 years
80 20 100
375
Total cost
Total cost for man hours Total material cost Subtotal VAT (16 %)
Total cost
62400 375 62775 10044

72819
The cost estimate of the presented master thesis adds up to SEVENTYTWO THOUSAND EIGHT HUNDRED NINETEEN euros.
Madrid, April 2004
Pr Kragsterman
139

50A95 Statya 1 Umts GSM

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

50A95 Statya 1 Umts GSM

Caricato da

Copyright:

Formati disponibili

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

Masters Degree Project Stockholm, Sweden 2004-10-04

Proyecto fin de carrera

Composicin del tribunal

Presidente: Enrique Vzquez Gallo

Vocal: Manuel lvarez-Campana Fernndez-Corredor

Secretaria: Ana Beln Garca Hernando

Suplente: David Fernndez Cambronero

Fecha de presentacin: Calificacin:

Universidad Politcnica de Madrid

Kungliga Tekniska Hgskolan

Escuela Tcnica Superior de Ingenieros de Telecomunicacin

Proyecto fin de carrera

Pr Kragsterman Mayo 2004

Brief summary in Spanish

Brief Summary in Spanish

Brief summary in Spanish

El Signaling Relay Node (SRN)

Especificacin Tcnica del SRN

Brief summary in Spanish

Brief summary in Spanish

Introduction to GSM/UMTS networks __________________ 13

Introduction to Mobile Number Portability (MNP) _______ 39

NRN assignments in Spain _____________________________________ 44

Introduction to Flexible Allocation (FA)_________________ 45 MNP/FA solution____________________________________ 47

5.1 5.2 5.3

The Signaling Relay Node (SRN) in action _______________ 50

The SRN technical specification _______________________ 79

101 101 101 101 101

Conclusions and future work _________________________ 106

Definitions, abbreviations and symbols_________________ 108

References ________________________________________ 115

Appendix A ______________________________________________ 117

Appendix B ______________________________________________ 135

2 Introduction to GSM/UMTS networks

Introduction to GSM/UMTS Networks

A Simplified Problem Scenario

2 Introduction to GSM/UMTS networks

Static routing decision

2 Introduction to GSM/UMTS networks

Dynamic routing decision

2 Introduction to GSM/UMTS networks

Another Network Operator

2 Introduction to GSM/UMTS networks

2 Introduction to GSM/UMTS networks

UMSC/ VLR SMSC

Figure 2.4 View of the GSM/UMTS network.

2.2.2 Node B and Radio Network Controller (RNC)

2 Introduction to GSM/UMTS networks

UMSC/ VLR NSS

2 Introduction to GSM/UMTS networks

Figure 2.6 A view of the UMSC/VLRs position in the GSM/UMTS network.

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

2 Introduction to GSM/UMTS networks

Figure 2.7 A view of the HLR/AuCs position in the GSM/UMTS network.

2.2.5 Signaling Transfer Point (STP)

2 Introduction to GSM/UMTS networks

Figure 2.8 A view of the STPs position in the GSM/UMTS network.

Figure 2.9 A view of the SGSNs position in the GSM/UMTS network.

2 Introduction to GSM/UMTS networks

Figure 2.10 A view of the GGSNs position in the GSM/UMTS network.

2.2.7 Short Message Service Center (SMSC)

Introduction to Flexible Allocation (FA)_ 45 MNP/FA solution____________________ 47