Download pdf - Gateway Location Register Product Description V500

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

Roaming Applications

Gateway Location Register


Roaming Applications Page 2 Proprietary and Confidential

Important Notice This document is delivered subject to the following conditions and restrictions:

* This document contains proprietary and/or confidential information 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.

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

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

* The text and graphics are for the purpose of illustration and reference 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.

* The information disclosed in this document is disclosed on an “as is” basis, and Starhome shall not be liable for the accuracy or completeness thereof.

* The system and the software described in this guide are furnished under 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 name Gateway Location Register Product Description V100.doc



Table of Contents 1. Introduction ...............................................................................................................................5

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

2.1 Overview .......................................................................................................................................5

2.2 Gateway Location 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

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

3.1 Overview .......................................................................................................................................8

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

3.3 Service Functionality ..................................................................................................................9 3.3.1 Registration of subscribers changing VLR/SGSN within the Operator’s

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



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 Gateway Location Register

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



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. Starhome’s Gateway Location Register

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



Figure 1: Conceptual GLR Architecture



2.3 IntelliGate™ Roaming SDP The IntelliGateTM 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



3. GLR Functional Description

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 Service Node Architecture 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



3.3 Service Functionality 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 UpdateLocation, 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 Registration of subscribers changing VLR/SGSN within the Operator’s network 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.



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



3.4 Leakage Identifier 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



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





4. Intelligent Application

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

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



4.3.1 WEB Provisioning Screen Shots

Figure 5: Provisioning: Configuration Screen



Figure 6: Provisioning: Actual Inbound Roaming Distribution



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 load-sharing 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 load-sharing capabilities

* MAP and TCAP Libreries

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



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.



6. GLR Reporting 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



6.1 GLR Reports Snapshots





7. GLR Call Flows

7.1 Location Registration

7.1.1 1st Location 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.



7.1.2 Second and further Location Updating procedure 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 Handling 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.



7.1.4 Unsupported Services 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 Restoration of subscriber 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.



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

7.1.6 CAMEL Phases Interaction support 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



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

Location update req.Update Location

Restore Data

Compare the CAMEL Supported

phase between that held in the

GLR and newly received in the

MAP LU If difference is

Insert Sub. DataCAMEL sub. Info.

Location update conf.

GLR number

VLR number

CAMEL sub. Info.

Store the received CAMEL

Supported phase information

Insert Sub. Data

Insert Sub. Data ackInsert Sub. Data ack

Restore Data Update Location

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



• 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 Message-Waiting. 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 SMS-GMSC HLR GLR MSC VLR SGSN MS

alertServiceCentre

ReadyForSM

ServiceCentreAlert

ReadyForSM

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



SC SMS-GMSC HLR GLR MSC VLR SGSN MS

alertServiceCentre

ReadyForSM

ServiceCentreAlert

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

IWMSC HLR GLR MSC VLR SGSN MS

alertServiceCentre

UpdateLocation

ServiceCentreAlert

ReadyForSM

LA Update

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

SC SMS-

IWMSC HLR GLR MSC VLR SGSN MS

alertServiceCentre

UpdateGprsLocation

ServiceCentreAlert

ReadyForSM

RA Update

Figure 10: Alert procedure; GLR receives UpdateGPRSLocation, MNRF or MNRG is set

Packet Switched Service Procedures Description:



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.



GLR HLR

1. Update Locationor Update GPRS Location 2. Update Location

or Update GPRS Location

3. Insert Subscriber Data(Zone Code List)

Second andFurtherLocationUpdating

12. Update Location ack orUpdate GPRS Location ack

(Rejected)

Visited NW Home NW

Store Zone Code List


Aware of whole newMSC area restricted

old VLR/old SGSN

new VLR/new SGSN

5. Update Location orUpdate GPRS Location


7. Insert Subscriber Data ack(MSC area restricted)

“the MSC area restricted flag” is set

First LocationUpdating

9. Insert Subscriber Data

10. Insert Subscriber Data ack(MSC area restricted)

Identifies restricted andDecides to initiate UL

8. Update Location orUpdate GPRS Location

11. Update Location ack orUpdate 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”.



GLR HLR

8. Update Location ack

Visited NW Home NW

Aware of Not wholenew MSC area

restricted

VLROLD VLRNEW

1. Update Location


3. Insert Subscriber Data ack

“the MSC area restricted flag” is cleared

4. Update Location




Identifies No more restrictedand Decides to initiate UL

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

Figure 12: Regional Restriction Procedure (MS leaves 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 the 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



* 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

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.

GLR HLR

Visited NW Home NW

VLR

1. Provide Roaming Number

2. MTForwardSM [Type 0]

3. MTForwardSM positive ack

6. Provide Roaming Number ack





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

HLR


Visited NW

VLR

Restart

GLR

3. Update Location

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



Home NW



2. Reset (GLR No, HLR id List(*))

The VLR received Mobile Originated Activity/Location Updating Request Or Mobile Terminated Request

3. Update Location


Mark subscriber records for all affected users

Identify this registrationcomes form affected user

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



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

HLR



2. Restore Data

Visited NW Home NW

VLR

Restart


4. Restore Data ack


GLR



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

o * Authentication Information Retrieval procedure

o * Subscriber Data management procedure

o * Supplementary services procedures

o * Purge MS Procedure

o * Subscriber and Equipment Trace

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



network as much as possible, while following the 3GPP recommendations for Gateway Location register.