Gateway Location Register Product Description V500

Roaming oaming Appli cations cations

Gateway teway Location Lo cation Regist gi ste er

This material describing Starhome is for general information purposes and may be modified by Starhome at any time without notice. This material is the proprietary and/or confidential information of Starhome, and may not be disclosed, copied or transferred to any third party without Starhome's prior express consent. Starhome, its logo and service names are registered trademarks or trademarks of Starhome GmbH. All other marks are the property of their respective holders. © Copyright 2002-2007 Starhome. All rights reserved.

Operator

February 2007

Gateway Location Register

Important Notice This document document is delivered subject to the following conditions conditions and restrictions: document contains proprietary proprietary and/or confidential information information * This document belonging to Starhome.

* Any unauthorized reproduction (electronic or mechanical), use, or

disclosure of this material, or any part thereof, is strictly prohibited. The contents of this document or any part thereof may be used solely for the purpose for which they are provided.

document is intended solely for the use use of entities expressly * This document authorized by Starhome.

* Material describing Starhome is for general information purposes and may be modified by Starhome at any time without notice.

purpose of illustration illustration and reference reference * The text and graphics are for the purpose

only. The specifications on which they are based are subject to change without notice.

* Corporate and individual names and data used in examples herein are fictitious unless otherwise noted.

information disclosed in this document document is disclosed disclosed on an “as “as is” * The information

basis, and Starhome shall not be liable for the accuracy or completeness thereof.

and the software described in in this guide are are furnished under * The system and

a license and may be used or copied only in accordance with the terms of this license.

Copyright ©2002-2007 Starhome. All rights reserved. All company and brand products and service names are trademarks or registered trademarks of their respective holders.

Document n ame Gateway Location Register Product Description V100.doc

Roaming Applications

Page 2

Proprietary and Confidential


Important Notice This document document is delivered subject to the following conditions conditions and restrictions: document contains proprietary proprietary and/or confidential information information * This document belonging to Starhome.

* Any unauthorized reproduction (electronic or mechanical), use, or

disclosure of this material, or any part thereof, is strictly prohibited. The contents of this document or any part thereof may be used solely for the purpose for which they are provided.

document is intended solely for the use use of entities expressly * This document authorized by Starhome.

* Material describing Starhome is for general information purposes and may be modified by Starhome at any time without notice.

purpose of illustration illustration and reference reference * The text and graphics are for the purpose

only. The specifications on which they are based are subject to change without notice.

* Corporate and individual names and data used in examples herein are fictitious unless otherwise noted.

information disclosed in this document document is disclosed disclosed on an “as “as is” * The information

basis, and Starhome shall not be liable for the accuracy or completeness thereof.

and the software described in in this guide are are furnished under * The system and

a license and may be used or copied only in accordance with the terms of this license.

Copyright ©2002-2007 Starhome. All rights reserved. All company and brand products and service names are trademarks or registered trademarks of their respective holders.

Document n ame Gateway Location Register Product Description V100.doc


Page 2



Table of Contents 1.

Introduction ...............................................................................................................................5

2.

Starhome’s Gateway Location Register ..............................................................................5

2.1

Overview .......................................................................................................................................5

2.2

Gateway Location Register.........................................................................................................5 Register .........................................................................................................5

2.3

IntelliGate™ Roaming SDP ........................................................................................................7 2.3.1 Platform .........................................................................................................................7 2.3.2 Mobile Network Interface ............................................................................................7 2.3.3 Roaming Common Building Blocks ..........................................................................7 2.3.4 Operator Benefits.........................................................................................................7 Benefits .........................................................................................................7

3.

GLR Functional Description ...................................................................................................8

3.1

Overview .......................................................................................................................................8

3.2

Service Node Architecture ..........................................................................................................8

3.3

Service Functionality ..................................................................................................................9 Functionality ..................................................................................................................9 3.3.1 Registration of subscribers changing VLR/SGSN within the Operator’s network..........................................................................................................................9 network..........................................................................................................................9 3.3.2 Handling of Other MAP Operations ........................................................................10

3.4

Leakage Identifier ......................................................................................................................11

4.

Intelligent Application...........................................................................................................14

4.1

Overview .....................................................................................................................................14

4.2

Service Profiles...........................................................................................................................14 Profiles ...........................................................................................................................14 4.2.1 Country Profile ...........................................................................................................14 4.2.2 Network Profile ...........................................................................................................14

4.3

Web Provisioning Interface ......................................................................................................14 4.3.1 WEB Provisioning Screen Shots ..............................................................................15

5.

GLR Platform ............................................................................................................................17

6.

GLR Reporting Tools ..............................................................................................................19

6.1

GLR Reports Snapshots ...........................................................................................................20

7.

Summary ...................................................................................................................................22


Page 3



Figure 1: Conceptual GLR Architecture .............................................................................................6 Figure 2: Service Node Concept ..........................................................................................................8 Figure 3: Second and Further Location Updating Procedure in the Network ...........................10 Figure 4: Leakage Identifier Signaling Flow ....................................................................................11 Figure 5: Provisioning: Configuration Screen .................................................................................15 Figure 6: Provisioning: Actual Inbound Roaming Distribution....................................................16

Abbreviations


HLR

Home Location Register

HPMN

Home Public Mobile Network

HS

Handset

GLR


MS

Mobile Station

MSC

Mobile Switching Center

PLMN

Public Land Mobile Network

SGSN

Serving GPRS Support Node

SRM

Signaling Relay Module

UL

Update Location

VLR

Visited Location Register

VPMN

Visited Public Mobile Network

Page 4



1.

Introduction As the mobile telecom market becomes more and more competitive, mobile network operators are looking for revenue assurance by enlarging their inbound roaming revenue while lowering their cost. The inbound market provides the VPMN operator the majority of total roaming revenue, therefore the control of number of inbound roamers become more and more crucial. To help enable operators lower cost and optimize inbound roaming traffic Starhome provides its Gateway Location Register (GLR) product.

2.

Starhom e’s Gateway Location Regi st er

2.1

Overview Starhome’s solution for inbound management is based on the functionality of the 3GPP Gateway Location Register Node – GLR (3GPP 29.120 & 23.119). The GLR provides the VPMN the ability to significantly reduce the amount of signaling messages sent to its signaling provider, towards other HPMNs, therefore reducing its expenses. This eventually provides the ability to take control of the inbound roamers activities within the network. In addition it provides a set of tools enabling the inbound roamer to register in the network, regardless of other decisions made by the HPMN.

2.2

Gateway Locati on Register The GLR is a node between the VLR and/or SGSN and the HLR, which may be used to optimize the location updating and the handling of subscriber profile data across network boundaries. When a subscriber is roaming, the GLR functions as the HLR towards the VLR and SGSN in the visited network, and as the VLR and SGSN towards the HLR in the home network. Figure 1 below depicts the conceptual architecture of the Gateway Location Register.


Page 5



Figure 1: Conceptual GLR Architecture


Page 6



2.3

Intell iGate™ Roamin g SDP The IntelliGate TM Roaming Service Delivery Platform (RSDP) is designed to efficiently provide multiple roaming services. The modular design, together with common building blocks, facilitates rapid deployment and delivery of voice and data roaming applications. Based on independent distributed process architecture, the IntelliGate offers maximum scalability, enhanced fault tolerance and optimal performance. The IntelliGate platform architecture is comprised of the following layers:

2.3.1

Platform * Based on a Telco-grade cabinet * Standard software infrastructure – Java and C++ languages, Linux operating systems

* Monitoring – uses standard HPoV and other technologies * Billing – utilizes standard tools and interface supporting TAP and other standards

2.3.2

Mobile Network Interface A variety of external interfaces support any voice or data mobile application including: SS#7 MAP, IN, ISUP protocols and variants, IP protocols, Mobile Data, SMS protocols, MMS protocols, OSA and management tools.

2.3.3

Roaming Common Building Blocks This layer provides the common software building blocks required for the delivery and deployment of any roaming application including: trigger analysis, data covering, subscriber data and visit management.

2.3.4

Operator Benefits * Field proven platform with more than 75 installations world wide * Enables quick deployment of new roaming services resulting in faster ROI * Dozens of existing applications for VHE, roaming optimization and infotainment

* Provides low risk integration with mobile networks using existing validated interfaces

* Optimizes network costs – by leveraging common service resources to deploy new services


Page 7



3.

GLR Func tio nal Descript ion

3.1

Overview The GLR solution is based on SS7 network. As handsets of all types adhere to the GSM standard in regards to the basic network selection process, this solution is completely handset independent. The GLR intercepts all MAP traffic sent from Operator’s VLR/SGSN to the Home networks, whenever an inbound roamer turns the HS on, enters the network or moves from one VLR/SGSN to another. The solution is comprised of an IntelliGate-based application integrated to Operator’s network as a Signaling Relay.

3.2

Servi ce Node Archi tectur e The IntelliGate is connected in a parallel mode, functioning as a standard Service Node platform. As the IntelliGate controls the outgoing and incoming MAP traffic, the GMSC/GSTP of Operator routes the international MAP traffic to the IntelliGate Roaming SDP prior to sending it to the international STP. This traffic is then sent to the STP for further processing.

Figure 2: Service Node Concept


Page 8



3.3

Service Function ality Once a subscriber selects an Operator’s network, the GLR starts to optimize the signaling traffic and keep the subscriber in the Operator’s network. Upon receiving the U pdateLocation , the GLR checks the IMSI attempting the registration, and operates in accordance with the following operation modes:

* 1st time registration in Operator’s network; subscriber arrives from HPMN or from another network (from the same or different country)

* Registration of subscribers changing VLR/SGSN within Operator’s network

In addition, the GLR maintains other relevant MAP messages between HLR and VLR/SGSN per each specific IMSI, such as MT Calls, SMS MO&MT, USSD and other subscriber related services, and manages the VLR/SGSN addressing in front of the HPMN, all the above according 3GPP recommendations.

3.3.1

Registr ation of subs cribers c hanging VLR/SGSN with in th e Operator’s n etwork As the IntelliGate functions as a standard GLR, it controls all location updates generated by the inbound roamers. When the IntelliGate receives an updateLocation message from a newly visited VLR/SGSN, it stores the subscriber information for the user (i.e., at second or further location update to the IntelliGate). The IntelliGate stores the new VLR Number and new serving MSC Number included in the received message. Thereafter, the IntelliGate initiates insertSubscriberData procedure and Cancel Location procedure, based on the most updated subscriber data (stored from previous update procedure). Following these procedures, the IntelliGate replies to updateLocation message from the VLR. When these events have concluded, the subscriber will have successfully changed its location, and the HLR will not be updated. With this operation, the IntelliGate avoids a possible network redirection to happen. In addition, the IntelliGate performs other GLR MAP procedures such as VLR/SGSN subscriber location management, and activates the GLR functionality, as specified in the 3GPP recommendations for Gateway Location Register.


Page 9



Figure 7 depicts the call flow of the second and further updateLocation Procedures in the Network:

Figure 3: Second and Further Location Updating Procedure in the Network

3.3.2

Handling of Other MAP Operations The IntelliGate will continue to maintain other MAP operations. The IntelliGate will route the relevant messages towards the active VLR/SGSN and on the other side to the HLR. Starhome’s GLR ALSO supports other MAP procedures to maintain full MAP standard and service continuity. The following procedures are supported in the GLR functionality:

* * * * * * * * *

Location Updating Procedures Unsupported Services Procedures Restoration of subscriber data in a new VLR CAMEL Phases Interaction support Short Message Service Retrieval of routing information procedures Packet Switched Service Procedures Regional Restriction Procedures Recovery and Restoration Procedures


Page 10



3.4

Leakage Identifi er The cell Leakage Identifier is an optional report, integrated with the GLR solution, which provides the VPMN the ability to identify from which location the inbound roamers are leaving its network to the benefit of one of the competing networks in country. This report provides resolution per Cell ID within a specific VLR the inbound roamer left from and the exact MSC number of the competing network. The Cell Leakage Identifier is based on several signaling messages flow which allows the GLR service to identify the leakage scenario and collect information accordingly. The VPMN can collect information on real-time or on history basis in order to be able to optimize its network radio coverage based on the results of this reports. The results of Cell Leakage Identifier are provided in Business Objects report generation tool. The following flow describes the logic of Cell Leakage Identifier functionality:

Figure 4: Leakage Identifier Signaling Flow


Page 11



The following report is generated as an output of the Leakage Identifier:


Page 12




Page 13



4.

Intelligent Appli cation

4.1

Overview The GLR solution is controlled by an application and user-friendly provisioning tool enabling Operator to configure the behavior of the solution - in accordance with its marketing and technical strategies - those using the signaling sophisticated mechanisms to act as a standard GLR platform.

4.2

Servi ce Prof iles

4.2.1

Country Profile Operator will be able to configure, per home country, whether to activate or deactivate the Gateway Location Manager Service. When deactivating the service for a certain country, the application will relay all registration attempts. Operator will also be able to apply different profiles to different countries.

4.2.2

Network Profile Operator is able to configure, per visited network, whether to activate or deactivate the Gateway Location Register Service. When deactivating the application for a certain network, the application will accept all registration attempts, regardless of any pre-configured decision parameters. Operator is also able to apply different profiles to different networks.

4.3

Web Prov isi oni ng Interface The GLR service is equipped with Starhome’s standard web provisioning tool, which allows online control and reporting capabilities related specifically to this service.


Page 14



4.3.1

WEB Provi sioni ng Screen Shots

Figure 5: Provisioning: Configuration Screen


Page 15



Figure 6: Provisioning: Actual Inbound Roaming Distribution


Page 16



5.

GLR Platform The GLR platform is designed as a high availability platform. The platform is offered in Dual-Node or Quad-Node clustering architecture based on the customer requirements and its network load. The GLR is operated as Active-Active node while working in load sharing. In addition the GLR can be operated in Host-Standby architecture in addition to the standard load sharing across the nodes. The GLR platform consists the following main elements: MTP & SCCP SS7 stacks – Ulticom’s based product that operates in loadsharing clustering mode between the platforms

* Front End Process (FEP) – a process which provides enhanced STP and SCCP GW capabilities, for example: SCCP Called Party routing decisions SCCP Calling Party routing decisions MAP Operation Code routing decisions etc. GLR – the GLR application process that is deployed across the platforms * in dual process structure or quad process structure for enhanced loadsharing capabilities * MAP and TCAP Libreries ▪ ▪ ▪

The following architecture shows the GLR solution in Dual-Node solution


Page 17



The following architecture shows the GLR solution in Quad-Node solution, while signaling activities and GLR application activities are shredded between the platforms.

Due to the modular architecture of the GLR it can be configure to address:

* Higher capacity needs by multiplying the clusters deployed (8 Nodes, 12 Nodes etc.) * Geographical redundancy solution between sites for a single operator solutions, group operator solution or signaling provider solution.


Page 18



6.

GLR Repo rtin g Tools The GLR service is equipped with an optional reporting tool based on Business Objects. The reporting tool provides the customer the ability to generate history based reports that provide information about the inbound roamers activities in the networks. The following reports are included:

* Inbound roaming distribution - The report shows the current

distribution of roamers per HPMN and the rate of success registration attempts out of total attempts. The report can be filtered per Home Country / Home Network / All and per Date (Day/Week/Month/Year) The report generation can be in Table / Graph * Number of Update Location GSM - Counts the total number of GSM LU’s during a period of time. The report can be filtered per Home Network / All and per Date (Day/Week/Month/Year) The report generation can be in Table / Graph * Number of Update Location GSM sent to HLR / Managed locally by GLR The report can be filtered per Home Network / All and per Date (Day/Week/Month/Year) The report generation can be in Table / Graph * Leakage Identifier Report [Optional] The report provides information about leakage of inbound roamers from the VPMN, on Cell ID resolution to a competing or neighboring network The report can be filtered per Home Network / All and per Date (Day/Week/Month/Year) The report generation can be in Table / Graph ▪

▪

▪

▪

▪

▪

▪

▪

▪


Page 19



6.1

GLR Reports Snapsho ts


Page 20




Page 21



7.

GLR Call Flows

7.1

Location Registration

7.1.1

1st Loc ation updating procedure in the VPMN

1. When the GLR receives an Update Location message from a VLR and does not hold the subscriber’s information for the user (i.e. at first location updating to the GLR), the GLR: * Stores the VLR Number and serving MSC Number included in the received message, and Sends an Update Location message to the HLR with the GLR Number as VLR Number , and as MSC Number . 2. The HLR stores the GLR Number from received message as respectively VLR Number and serving MSC Number. Thereafter the HLR initiates insert subscriber data procedure and cancel location procedure. 3. When the GLR receives Insert Subscriber Data message from the HLR, the GLR stores the subscriber’s information in the message and transport it to the VLR. 4. After these procedures, the HLR replies to an Update Location message from the GLR and the GLR transports the response to the VLR.


Page 22



7.1.2

Second and further Location Updating pro cedure in the VPMN

5. When the GLR receives an Update Location message from newly visited VLR and holds the subscriber information for the user (i.e. at second or further location updating to the GLR), the GLR stores the new VLR Number and new serving MSC Number included in the received message. 6. Thereafter the GLR initiates insert subscriber data procedure and cancel location procedure. 7. After these procedures, the GLR replies to an Update Location message from the VLR.

7.1.3

LMSI Handl ing The LMSI is a Local Mobile Station Identity that the VLR allocates to each IMSI. The VLR can send the LMSI within the updateLocation message towards the HLR side. As the GLR handles several VLRs within the VPMN and there might be a case, in which 2 VLRs allocated the same LMSI number (each one to a different IMSI), the GLR will need to manage this. This section refers only to the interaction of VLR. SGSN will not use LMSI. 8. On location updating the VLR creates and allocates the LMSI number (denote LMSIv) for the user and sends it to the GLR in Update Location message. 9. When the GLR receives the message, it creates and allocates another LMSI number (denote LMSIg) and associates LMSIg with received LMSIv. 10. The GLR notifies LMSIg to the HLR sending updateLocation message. (only on first registration) 11. The GLR, on receipt of a message, shall translate the LMSIg to LMSIv and send it to the associated VLR.


Page 23



7.1.4

Unsupport ed Servic es Procedure The procedure can be used to handle the case where the VLR does not support the full set of services required by the user. 1. When the GLR receives the insertSubscriberData Acknowledge message indicating “Service Not Supported”, it initiates the location updating procedure toward the HLR. 2. The HLR takes some appropriate reaction (e.g. initiates service substitution or roaming restriction etc.) and determines whether to accept the location updating request or not for the user. The HLR generates a new profile (i.e. the profile after service substitution), which must be forwarded by the GLR to the VLR. 3. The GLR must also maintain a copy of the actual service profile for the subscriber (i.e. the profile before service substitution). This profile shall be used in each new Location Updating procedure.

7.1.5

Restor ation of subs criber data in a new VLR 1. When the user returns to an MSC/SGSN area that is not restricted due to regional subscription or an area that supports the services subscribed, the GLR identifies the need to notify the HLR of the return.


Page 24



2. Therefore the location updating procedure is initiated toward the HLR for this handling.

7.1.6

CAMEL Phases Interaction suppo rt This section refers to the case where the subscriber IMSI is valid and the subscriber has indication of CAMEL service (i.e. O-CSI, SS-CSI etc.) In case the IMSI has no CAMEL records from previous received insertSubscriberData messages this section is not relevant and should be skipped. It is possible that all the VLRs within a VPLMN do not support the same phase of CAMEL. This could happen in the case of an incremental upgrade of these VLRs within the VPLMN. In this case, it is possible that the HLR may receive frequent changes of the CAMEL supported phase information in the updateLocation request message from the GLR. The effect is that the HLR would perceive the GLR as a VLR that changes its CAMEL supported phase. 1. When the GLR receives the updateLocation request message from the subscriber, the GLR checks that the CAMEL supported phase it previously


Page 25



received for that subscriber matches the CAMEL supported phase carried by updateLocation request message. 2. If a difference is detected, the GLR sends restoreData (updateLocation in 3GPP reference [16]) to the HLR indicating the relevant CAMEL phase in order to obtain the proper CAMEL subscription information that corresponds to the current VLR. 3. In order to perform this scenario, the CAMEL supported phase information needs to be added to the ‘IMSI record in GLR’ table.

MS

VLR

Location update req.

GLR

U date Location VLR number

Store the received CAMEL

HLR

Compare the CAMEL Supported phase between that held in the GLR and newly received in the

Supported phase information Restore Data GLR number Insert Sub. Data CAMEL sub. Info. Insert Sub. Data ack

U date Location

Insert Sub. Data CAMEL sub. Info.

Insert Sub. Data ack Restore Data

Location update conf.

7.2

Short Message Service The support of Short Message Service is relevant only to Mobile Terminated SMS sent to inbound roamers. The GLR shall control the MTForwardSM messages sent to MSC or the SGSN. Note :

The following section describes the required functionality related to the GLR. For 3GPP specific SMS scenarios handling, refer to reference [16].

7.2.1

Functionality of th e GLR 1. When receiving a short message from the SMS-GMSC the GLR is responsible for the following operations: * Retrieve the MSC / SGSN Number from the identity of the recipient MS;

o

*

Transferring the short message to the MSC / SGSN. 2. Other MAP messages related to the SMS service shall be relayed to the far end.


Page 26



•

Specific SMS scenarios related to GLR functionality

Description: 1. The following scenarios provide information about the MNRF, MNRG and MCEF flags, with interaction of GLR and MS reach-ability. 2. The GLR shall have only the MNRF and the MNRG for the MessageWaiting. The GLR does not have other datum for the Message-Waiting service element. o

MS Not-Reachable Set Flag

Required Functionality: The MNRG and MNRF in the GLR are set in the following way: 1. When the GLR identifies that a response message to MTForwardSM is having an error cause equal to ‘ Absent Subscriber’. o

a.

The MNRF flag is set when the MTForwardSM was sent to a VLR

o

b.

The MNRG flag is set when the MTForwardSM was sent to a SGSN o

MS No-Reachable Clear Flag

Required Functionality: The MNRG and MNRF in the GLR are cleared in the following way: 1. When the GLR that a response message to MTForwardSM is having an error cause equal to ‘ MS Memory Capacity Exceeded’. o

a.

The MNRF flag is cleared when the MTForwardSM was sent to a VLR

o

b.

The MNRG flag is cleared when the MTForwardSM was sent to a SGSN

o

2. The GLR Receives a readyForSM message from the VLR indicating MS is reachable and available for receiving MT Short Message. The following 2 flows depict the scenario of MNRF/MNRG Clear by the GLR:

SC

SMSGMSC

HLR

GLR

MSC

VLR

SGSN

MS

ReadyForSM

ReadyForSM alertServiceCentre ServiceCentreAler

Figure 7: The alert procedure when the MS becomes reachable, MNRF is set


Page 27



SC

SMSGMSC

HLR

GLR

MSC

VLR

SGSN

MS

ReadyForSM


Figure 8: The alert procedure when the MS becomes reachable, MNRG is set 3. When the GLR receives updateLocation or updateGPRSLocation the GLR shall invoke readyForSM to the HLR if and only if MNRF or MNRG is set.

SC

SMSIWMSC

HLR

GLR

MSC

VLR

SGSN

MS

LA Update

UpdateLocation


Figure 9: Alert procedure; GLR receives UpdateLocation, MNRF or MNRG is set

SC

SMSIWMSC

HLR

GLR

MSC

VLR

SGSN

MS

RA Update

UpdateGprsLocation


Figure 10: Alert procedure; GLR receives Upd ateGPRSLocation, MNRF or MNRG is set 

Packet Switched Service Procedures

Description:


Page 28



1. The GLR shall handle only MAP signaling messages related to GPRS. 2. All GTP signaling messages shall be handled directly between the GGSN and the SGSN. o

a. The SGSN Address (IP Address) within the updateGPRSLocation message is not translated and maintained as originally sent by the SGSN (changed and modified by GLR in 3GPP reference [16]). Only SGSN Number (Global Title) is translated to the GLR Number. •

GPRS Attach Procedure

Required Functionality: This shall be handles as the GSM updateLocation and cancelLocation handling. For the specific procedure requirements refer to section Error! Reference source not found.. 

Regional Restriction Procedure

Description: In the case that GLR is introduced, during second and subsequent location updating, there is no interaction between the GLR and the HLR. However, the regional restriction service needs the location updating procedure towards the HLR. •

MS Enters a Restricted Area

Required Functionality: 1. The GLR shall store the Zone Code List sent by the HLR in the insertSubscriberData message. 2. On the location updates the GLR sends its stored Zone Code list to the VLR and/or SGSN. 3. The GLR stores also the MSC area restricted flag and/or the SGSN area restricted flag. These flags are set “False” if the location updating procedure executed successfully. 4. When the GLR receives the insertSubscriberData Acknowledge message indicating “MSC area restricted” or “SGSN area restricted” and the MSC/SGSN area restricted flag is set as “False”, the GLR initiates the location updating procedure toward the HLR. 5. In addition, the GLR sets the MSC/SGSN area restricted flag “True”. 6. Also, the HLR sets the MSC/SGSN area restricted flag “True”, and the location updating for the IMSI is rejected. 7. These flags contribute to the “MS Not Reachable” state for handling of terminating traffic (i.e. mobile terminated call and mobile terminated SMS and so on) in the HLR.


Page 29



Visited NW old VLR/ old SGSN

Home NW GLR

new VLR/ new SGSN 1. Update Location or Update GPRS Location

HLR 2. Update Location or Update GPRS Location 3. Insert Subscriber Data (Zone Code List)

Store Zone Code List

First Location Updating

4. Insert Subscriber Data (Zone Code List)

5. Update Location or Update GPRS Location Second and Further Location Updating

6. Insert Subscriber Data (Zone Code List) Aware of whole new MSC area restricted

7. Insert Subscriber Data ack (MSC area restricted) Identifies restricted and Decides to initiate UL

8. Update Location or Update GPRS Location 9. Insert Subscriber Data 10. Insert Subscriber Data ack (MSC area restricted) “the MSC area restricted flag” is set

12. Update Location ack or Update GPRS Location ack (Rejected)

11. Update Location ack or Update GPRS Location ack (Rejected)

Figure 11: Regional Restriction Procedure (MS Enters a restricted Area) •

MS Leave the Restricted Area

Required Functionality: 1. When the GLR receives the insertSubscriberData ACK message indicating “MSC/SGSN area restricted” and the MSC/SGSN area restricted flag is set as “True”, The GLR rejects the location updating procedure for the IMSI. No interaction with the HLR is needed. 2. When the user returns to an MSC area that is not restricted due to regional subscription, i.e., when the GLR receives the insertSubscriberData ACK message NOT indicating “MSC/SGSN area restricted” and the MSC/SGSN area restricted flag is set as “True”, the GLR initiates the location updating procedure toward the HLR. 3. In addition, the GLR sets the “MSC/SGSN area restricted” flag “False”.


Page 30



Visited NW VLROLD

Home NW

VLRNEW

GLR

HLR

The Regional Restriction Procedure was initiated on location updating In the previously visited VLR

1. Update Location 2. Insert Subscriber Data (Zone Code List) Aware of Not whole new MSC area restricted

3. Insert Subscriber Data ack Identifies No more restricted and Decides to initiate UL

4. Update Location 5. Insert Subscriber Data 6. Insert Subscriber Data ack “the MSC area restricted flag” is cleared

8. Update Location ack


Figure 12: Regional Restriction Procedure (MS l eaves the restricted area)



Recovery and Restoration Procedures •

GLR Failure/Restart

The StarHome GLR should conform to the section 7.6.1 of the document [16]. o

VLR/SGSN number retrieve for unknown IMSI

On receiving of provideRoamingNumber or MTForwardSM for which t he iMSI is not found neither in the server memory nor in the persistent storage, the GLR should send MTForwardSM with ‘SMS Type 0’ to each one of the network VLRs/SGSNs (only in case of initial MTForwardSM sent to SGSN). The GLR should start sending ‘SMS type 0” to the VLR corresponding to the GLR GT received in the SCCP called address of the PRN/MT_FSM. Based on the MTForwardSM response the GLR should determine the VLR in which the subscriber is attached. This is achieved by the response to the ‘SMS Type 0’ message. *


Positive response – Subscriber is attached

Page 31



* Negative response (i.e. Absent Subscriber) – Subscriber is not in this VLR area. By receiving the Positive response, the GLR should update the VLR/SGSN number in its Memory and in the persistent storage and relay the provideRoamingNumber or initial MTForwardSMto the VLR/SGSN. The ISD information remains missing. By receiving a new UL/UL_GPRS from the same subscriber, The GLR shall do the following •

Initiate a RESTORE_DATA session to the HLR

•

Update the ISD information and HLR_number parameter

•

Forward the ISD message to the new VLR/SGSN

Visited NW

Home NW

VLR

GLR

HLR 1. Provide Roaming Number

2. MTForwardSM [Type 0] 3. MTForwardSM positive ack 4. Provide Roaming Number 5. Provide Roaming Number ack

6. Provide Roaming Number ack

Figure 13: VLR/SGSN number Retrieve for unknown IMSI

•

HLR Restart/Failure

Description: In the case of HLR restart when the GLR receives a Reset message from a HLR, it marks all subscriber records for which the HLR Number matches the HLR Number received in the Reset message and relay the Reset message to the associated VLR. Required Functionality: 1. When the HLR restart occurs and the GLR receives a Reset message, the GLR identifies affected users by received HLR number and sets the indicator (“LSIC”) “not confirmed” for the users. * If the HLR included an HLR –ID list [MCC+MNC+MSIN] in the Reset message, then only those subscriber records for which the leading digits of the IMSI match one of the HLR-IDs in the HLR-ID list will be marked.


Page 32



o

* If the HLR does not includes an HLR-ID list in the Reset message, the GLR shall add this information when the data shall be the MCC+MNC of the invoking HLR (converting the CC+NDC to MCC+MNC) 2. The GLR sends R eset messages to the VLR/SGSN where the affected users are roaming. The Reset message includes the GLR number as HLR number and HLR-ID list if the GLR receives it from the HLR. Receiving VLR/SGSN may regard the users as affected by HLR number or HLR-ID list (if present). 3. When the affected user accesses the network, the VLR/SGSN initiates an updateLocation procedure to the GLR. If the GLR identifies that the indicator (“LSIC”) set to “not confirmed” for the user, it relays the message to the HLR. 4. When the HLR receives the updateLocation message, it initiates the insertSubscriberData procedure. During the procedure the GLR relays the messages between the serving node and HLR transparently. 5. When the VLR/SGSN receives the updateLocation ACK message, the restoration procedure is completed. 6. The GLR sets the “LSIC” to “Comfirmed” Visited NW

Home NW GLR

VLR

HLR Restart 1. Reset (HLR No, HLR id List(*))

Mark subscriber records for all affected users 2. Reset (GLR No, HLR id List(*)) The VLR received Mobile Originated Activity/Location Updating Request Or Mobile Terminated Request

3. Update Location Identify this registration comes form affected user 3. Update Location 4. Insert Subscriber Data

4. Insert Subscriber Data

4. Insert Subscriber Data ack

4. Insert Subscriber Data ack



(*) This parameter is optionally provided by HLR

Figure 14: HLR Reset •

VLR Failure/Restart

Description: In the case of VLR restart, the VLR retrieves subscriber data from the GLR to recover its database.


Page 33



Required Functionality: 1. When the VLR receives provideRoamingNumber message, it identifies that no IMSI record exists and creates a skeleton IMSI record and returns the provideRoamingNumber ACK message with MSRN to the HLR via the GLR. The GLR only relays these messages. 2. The VLR also sends the restoreDat a message to the GLR when it identifies that no IMSI record exists in order to recover subscriber record for the IMSI. 3. The GLR that receives the message initiates insert subscriber procedure to the VLR. 4. The recovery of IMSI record in the VLR is completed after it receives restoreData ACK message. Visited NW

Home NW

VLR

GLR

HLR

Restart 1. Provide Roaming Number 1. Provide Roaming Number ack

1. Provide Roaming Number 1. Provide Roaming Number ack

2. Restore Data 3. Insert Subscriber Data 3. Insert Subscriber Data ack 4. Restore Data ack

Figure 15: VLR Reset o

Other MAP Procedures

The following MAP procedures shall be handled by the GLR when only the Address Translation and Message Relaying functions are active (no specific session handling is required):

8.

o

*

Authentication Information Retrieval procedure

o

*

Subscriber Data management procedure

o

*

Supplementary services procedures

o

*

Purge MS Procedure

o

*

Subscriber and Equipment Trace

Summary Starhome’s Gateway Location Register service provides a comprehensive and flexible set of tools allowing the visited mobile network operator to control its inbound roaming community in the best optimized way while reducing signaling costs. The service activates operations to keep the visitor in the


Page 34


Gateway Location Register Product Description V500

Recommend Documents