Location Registration

Location Registration

DN987572Issue 10-0 en

# Nokia Siemens Networks 1 (53)

MSCDOCM14PDFCDMSC/HLR, Rel. M14.0, Product Documentation,v.3

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted inany form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners,and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2008. All rights reserved.

2 (53) # Nokia Siemens Networks DN987572Issue 10-0 en


Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Location Registration 91.1 Functional properties of location registration 91.2 Location registration procedures 131.2.1 Intra-MSC/VLR location update 161.2.2 Inter-MSC/VLR location update 171.2.3 Inter-PLMN location update 191.2.4 Location update in the HLR 201.2.5 Periodic location update 201.2.6 IMSI attach 211.3 Not-reachable MS 211.4 Location registration-related data in the VLR 221.5 Location registration-related data in the HLR 261.6 Location registration-related mobility measurements and charging 29

2 Location registration-related features 312.1 National roaming 312.1.1 Location updating 322.2 GSM restoration 332.3 Subscription-based network access 352.4 IN mobility management 382.5 Regional roaming 422.6 Network identity and time zone 462.7 Inter-system handover and UMTS changes in the MSC 472.8 Support of interaction with SGSN in MSC/VLR 512.9 Location update in pool area concept 52



Contents

List of tables

Table 1. Zone codes in MSC/VLR 44



List of figures

Figure 1. Network elements and interfaces involved in location registration in GSMand UMTS networks 10

Figure 2. Service blocks involved in location registration in the MSC/VLR 12

Figure 3. Service blocks involved in location registration in the HLR 13

Figure 4. UMTS Service Area 14

Figure 5. GSM Cells 14

Figure 6. Location update 16

Figure 7. Inter-MSC/VLR location update 18

Figure 8. VLR restoration in GSM Phase 2 34

Figure 9. Overview of the feature 36

Figure 10. IN mobility management architecture 40

Figure 11. Handover support 50



List of figures



Summary of changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes made between issues 10–0 and 9–2

Inter-MSC/VLR location update

Support of MAP SendIdentification between PLMNs has been added.

Regional roaming

Early regional roaming checking based on PLMN default zone codes tosave VLR-HLR/AUC signalling load has been added.

Inter-system handover and UMTS changes in the MSC

Access control optimisation for partial 2G/3G roaming agreementscenarios has been added.

Support of interaction with SGSN in MSC/VLR

MS Identity Reguest and alternative CS paging has been added to the Gsinterface procedures.

Location update in pool area concept

Section has been added to the document.


No changes in content, only editorial corrections done.



Summary of changes


Location registration procedures

Parameters for allowing and denying location updates between a GSMand a UMTS network removed.

MAP enquiry: retrieving subscriber data from the previous MSC/VLR

Topic moved from Section Location update in the HLR to Section Inter-MSC/VLR location update.

Subscriber parameters

Section updated.

VLR reset

Figure VLR restoration in GSM Phase 2 updated.



1 Location Registration

The Location Registration function class includes the functions in theMSC/VLR and the HLR, which are needed in the location update of a GSMor UMTS subscriber in the GSM or UMTS network.

In order to be able to route incoming calls, the PLMN keeps track of thelocation of the mobile station. Location information is stored in functionalunits called location registers. There are two types of location registers:

. the HLR, which contains permanent subscriber information and theaddress of the current VLR of the subscriber if it is known

. the VLR, where subscriber data is stored as long as the MS is withinthe area controlled by that particular VLR

This description covers circuit-switched side location registration.

1.1 Functional properties of location registration

Interfaces and protocols

The interfaces in the NSS are presented in the following figure. Interface Bbetween the MSC and the VLR is an internal interface.




Figure 1. Network elements and interfaces involved in location registration inGSM and UMTS networks

The network elements use the CCS, MAP, TCAP, and SCCP over MTPprotocol stacks for signalling with each other.

The BSSAP replaces the MAP and TCAP in the protocol stack in signallingover the A-interface (MSC/VLR–BSS).

Interaction with other functions and function groups

Location registration procedures interact with roaming checking (nationaland regional), authentication, ciphering and integrity protection, checkingof the equipment identity, re-allocation of the temporary mobile subscriberidentity, collection of traffic data, as well as with possible IN applications.

Location registration procedures are as follows:

MSC

VLR

VLR

EIR

B

B

D

F

G

HLRAUC

A

A‘

Iucs

UTRANR99MGW

MSC

Mc

UTRAN

MGW

BSS

BSS

A

Iucs

MS

MS

MS

MS



. IMSI attach/detach in the MSC/VLR

. normal and periodic location updating in the MSC/VLR

. retrieval of subscriber identity and authentication vectors from theprevious MSC/VLR

. location updating in the HLR. subscriber data retrieval from the HLR. location cancellation in the MSC/VLR

Architecture

The following service blocks take part in the implementation of locationregistration:

. AIASEB

The A-Interface Applications Service Block implements the BSSAP.

. AUCSEB

The Authentication Centre Service Block provides authenticationservices.

. CELSEB

The Cellular Network Service Block provides cellular networkmanagement.

. CNGSEB

The Charging Service Block provides charging services.

. EIRSEB

The Equipment Identity Register Service Block provides IMEIchecking services.

. HLRSEB

The Home Location Register Service Block includes the HLRdatabase and HLR application.

. MATSEB

The Mobile Application Part Service Block implements the MAP.

. MOSSEB

The General Mobile System Service Block provides routing analysisfor the IMSI.




. MTPSEB

The Message Transfer Part Service Block contains the MTP, SCCP,and TCAP implementation.

. TRDSEB

The Traffic Administration Service Block contains trafficadministration services.

. VLRSEB

The Visitor Location Register Service Block includes the VLRdatabase and VLR application.

The following figures represent the service blocks in the MSC/VLR and theHLR.

Figure 2. Service blocks involved in location registration in the MSC/VLR

MSC/VLR

BSSAP MAP

AIASEB MATSEB

MTPSEB

CELSEB CNGSEB

MOSSEB TRDSEB

VLRSEB



Figure 3. Service blocks involved in location registration in the HLR

1.2 Location registration procedures

Location registration enables the GSM or UMTS network to locate themobile subscribers in its own area and to route mobile-terminated callsefficiently.

HLR

MAP

CNGSEB TRDSEB

HLRSEB

MTPSEB

MATSEB

AUCSEB EIRSEB




Figure 4. UMTS Service Area

Figure 5. GSM Cells

Service Area (SAI)

Location Area (LAI)

Cell (CGI)

Location Area (LAI)



The GSM network is divided into an NSS and a BSS. The BSS is furtherdivided into location areas, which consist of several cells. Every cell has aunique CGI number, which the base stations broadcast continuously. In aUMTS network, there is a UTRAN, which is the equivalent to a BSS in aGSM network. Instead of the CGI, a UMTS core network uses the SAI,which identifies the service area. One or more cells form a service area,and one or more service areas make a location area.

The LAI number, where the mobile station resides, is stored in the memoryof the MS. The MS keeps listening to the signal from the base station, andcompares the LAI number to the one in its memory. If the LAI numbers donot match, the MS initiates a location updating in which the MS informs thecore network about its old location area and the BSC/RNC provides thecore network with the new location area of the MS.

The location information of a mobile subscriber is stored in the MSC/VLRand in the HLR. The MS informs the MSC/VLR about its own location area,and the MSC/VLR in turn informs the mobile subscriber's HLR that themobile station is now in its area.

The following figure gives an overview of the procedure.




Figure 6. Location update

When an MS changes its location area but remains under the control of thesame MSC/VLR, only the location information in the VLR needs to beupdated.

When an MS changes its location area so that it moves to the control areaof another MSC/VLR, the information in the HLR also needs to beupdated. As soon as this is done, the HLR cancels the subscriber's datafrom the previous VLR.

When the MS is turned on/off within the same location area, an IMSIattach/detach is performed. The mobile status (attached/detached) is thenupdated in the VLR.

1.2.1 Intra-MSC/VLR location update

In an intra-MSC/VLR location update, the mobile subscriber changes thelocation area, but remains in the same MSC/VLR.

MS BSS MSC/VLR AUC/HLR

Location Update Request

Request Subscriber Id .

Send Own Id.

HLR Update

Insert Subscriber Data

Ack

HLR Update Ack

Location Update Ack

Security checkings



The MS initiates the location update procedure by sending its TMSI orIMSI and old location area identity to the network. The BSC/RNC providesthe CGI/SAI to the MSC/VLR. The network may respond with anauthentication request, to which the MS answers by sending an (S)RES.The network may also ask for the IMEI of the MS. This may be followed byan IMEI checking towards the EIR. Ciphering and integrity protection onthe radio interface may be started, and the network may allocate a newTMSI for the subscriber.

1.2.2 Inter-MSC/VLR location update

In an inter-MSC/VLR location update, the mobile subscriber changes bothhis location area and the MSC/VLR area, but remains in the same PLMN.Location updating must also be done in the HLR because the subscriber isnot registered in the new VLR. The following figure gives an overall pictureof an inter-MSC/VLR location update:




Figure 7. Inter-MSC/VLR location update

The MS starts the location update by sending its TMSI and the old LAI tothe MSC/VLR. The BSC/RNC also sends the new CGI/SAI to the corenetwork. The MSC recognises the old LAI as the LAI of another VLR area.Since the mobile subscriber is unknown to the new VLR, the IMSI and theauthentication triplets/quintets must be fetched from the old VLR. This isdone in a MAP enquiry.

The subscriber's IMSI is requested from the old VLR, and an IMSI analysisis performed in order to find out the HLR address of the mobile station.

MSC/VLRnew

Channel Assignment

Location Update Request

Request SubscriberIdentity

Provide SubscriberIdentity

HLR Update

HLR Update Ack

Cancel Old Location

Location CancellingAccepted

Location Update Ack

MS BSS AUC/HLRMSC/VLRold

Insert Subscriber Data

Ack

Security checkings



The next step in the location update procedure involves sending the IMSIand the address information to the HLR. In response to this, the requiredsubscriber information is received from the HLR. The new location of theMS is stored in the HLR, the location update is acknowledged to the VLR,and a new TMSI is allocated to the mobile station.

As soon as the location updating is completed in the HLR, the HLRinitiates a 'cancel location' procedure towards the old VLR.

If new authentication sets are needed during location registration, they arerequested by a 'send authentication info' option before the location updatemessage is sent to the HLR.

MAP enquiry: retrieving subscriber data from the previous MSC/VLR

A MAP enquiry is made to obtain information of a mobile subscriber fromanother MSC/VLR.

When a mobile station roams from one VLR area to another with a TMSIallocated to it by the previous VLR, the new VLR must obtain the IMSI ofthe MS before the HLR can be updated. The IMSI is obtained byinterrogating the previous VLR if the two MSC/VLRs are within the samePLMN. In response to the interrogation, the VLR sends the IMSI of the MSto the new VLR. The authentication sets are also sent if they are requestedand they are available.

This functionality can be activated between different PLMNs as well, whichis useful when the VLR serves more than one home PLMNs (for example,2G and 3G networks are defined as two PLMNs).

If the MSC/VLR is not able to identify the mobile subscriber on the basis ofthe TMSI, the IMSI is requested from the MS itself.

1.2.3 Inter-PLMN location update

In an inter-PLMN location update, the mobile subscriber enters anothermobile network. Location updating must be done in the HLR.

The mobile station sends a normal location updating request with TMSI orIMSI and the old LAI to the MSC/VLR. The MSC recognises the old LAI asthe LAI of another PLMN.




The IMSI is analysed to obtain the HLR address, and a request forauthentication triplets/quintets may be sent to the AUC. Then the networkmay also ask for the IMEI of the MS, after which an IMEI checking mayhappen towards the EIR. As a result, ciphering and integrity protection onthe radio interface may be started, and the network may allocate a newTMSI to the mobile subscriber.

1.2.4 Location update in the HLR

In the HLR location update, the mobile subscriber's IMSI together with theMSC and VLR ISDN numbers are sent to the HLR. If the subscriber isallowed to roam in the area, the HLR responds by sending the subscriberinformation to the VLR. When the data is sent, the new location of the MSis stored in the HLR and the location update is acknowledged to the VLR.

Location updating in the HLR is followed by a 'cancel location' procedure inthe previous VLR.

Location cancellation

When a mobile station registers in a new VLR, the subscriber's data isdeleted from the previous VLR in a cancel location procedure. The HLRinitiates the procedure when it receives an 'update location' message froma VLR other than the one in which the MS was located at the time when itslocation information was last updated in the HLR database. The cancellocation procedure can also be initiated with MML commands, with those,for example, that are used for changing the area, or deleting the MS fromthe HLR.

1.2.5 Periodic location update

Periodic location updating is used to inform the network that the mobilestation is available; the network requires the mobile station to 'report in' atcertain time intervals. If there are no messages from the mobile station, thenetwork assumes that the MS is out of the coverage area or that it has notbeen turned on, and incoming calls to the MS are not paged. This savesradio resources.

The time interval for periodic location updating is defined in the basestation parameters. The time-out value is continuously broadcast, so whena mobile station enters the VLR area, it automatically knows how often ithas to report to the network. When the timer of the MS reaches the time-out value, the MS initiates a periodic location update. Every time locationupdating occurs, the MS and the VLR reset their timers.



In a periodic location update, the VLR area does not change, and locationupdating in the HLR is not needed.

1.2.6 IMSI attach

IMSI attach is an operation in which the MS becomes active (for example,when the mobile station has powered up). In this procedure, the VLRremoves the IMSI detach flag and resumes normal call handling for theMS. The IMSI attach information is stored in the VLR, and the HLR doesnot need to be updated. However, the update from the HLR is done incertain error conditions, such as after a VLR restart, or a VLR cleaning.

The use of the IMSI attach operation is defined in the base stationparameters.

1.3 Not-reachable MS

The following location management procedures can result in the fact thatan MS becomes not reachable:

. A regular IMSI detach has occurred.

. An implicit IMSI detach has occurred.

. A 'Purge MS' has occurred.

IMSI detach

A regular IMSI detach operation is an action by which an MS informs thePLMN that it has become inactive (for example, the MS has powereddown). On the basis of this information, calls coming to the MS can berejected without sending a paging message on the radio path. The IMSIdetach information is stored in the VLR.

The use of the IMSI detach operation is defined in the base stationparameters.




Implicit IMSI detach

An implicit IMSI detach operation is an action taken by the VLR when theMS has been inactive for too long a time. The time limit is defined in theVLR parameters. The procedure is initiated by an MTevent: when a call ora short message comes in, the VLR compares the last active date and thetime limit defined for the IMSI detach. If the time limit has been exceeded,the IMSI detach flag is set on. The implicit IMSI detach operation may alsobe activated by the operator.

If the IMSI is in 'detach' state (because of the IMSI detach or implicit IMSIdetach procedure), the incoming call establishment is interrupted; this wayan unnecessary circuit establishment from the gateway to the MSC/VLRand paging are avoided. A detach flag is set after the IMSI detach hasbeen completed, but the subscriber data is not deleted from the VLR.

The implicit IMSI detach is an optional feature in the network. The use ofthe feature is defined in the USE OF IMPLICIT IMSI DETACH parameter(VLR). The time limit is defined in the IMPLICIT IMSI DETACH TIMELIMIT parameter (VLR). The time must be longer than the periodiclocation updating time (defined in the BSC), but shorter than the loiteringtime.

Purge MS

A 'purge MS' is a request by which the VLR orders the HLR to delete themobile station's VLR address, so that any request for routing informationfor a mobile-terminated call will be treated as if the MS was not reachable.The operator can initiate this procedure with an MML command, but it isalso initiated if the MS has been inactive for too long (a VLR cleaning isperformed).

The cleaning parameters in the VLR are VLR CLEANING START TIME andTIME SUBSC. MAY LOITER BEFORE BEING DELETED FROM VLR.

1.4 Location registration-related data in the VLR


For every subscriber registered in the VLR, the VLR subscriber databasecontains the following data needed for location registration functions:

. cell global identity/service area identity

. mobility management location area identity



. IMSI detach flag

. IMEI (with software version)

. IMEI status

. authentication information

. last active date

. HLR address

. SGSN address

. zone code list

The cell global identity/service area identity shows the exact location of anMS within the PLMN. The mobility management location is the LAI wherethe MS made the latest location update. In GSM, the CGI and MM LAIcontain the same LAI, however, in UMTS, the SAI can refer to a LAI otherthan the MM LAI. This can happen when the user moves during an activePS session. The serving RNC remains the same during the PS sessioneven if the MS moves to another location or VLR area. If the MS initiates aCS call in the meantime, the SAI (real location) can be different from theMM LAI (the one under the serving RNC).

The VLR uses the MM LAI in the paging procedure, while it needs the SAIfor routing and positioning purposes. During a location update procedure,the MM LAI and the LAI part of the CGI/SAI are the same.

The VLR updates the MM LAI if it is received from the MSC and contains avalid LAI. The MSC decides whether the MM LAI can be sent to the VLR.This is always true during location registration procedures and in GSMradio access, in general. In UMTS, the MSC sends the MM LAI to the VLRonly if it is received from the MGW.

The VLR updates the CGI/SAI after every operation performed by the MS.This includes the following:

. location update

. IMSI attach

. IMSI detach

. mobile-originated call

. mobile-originated SM

. mobile-originated supplementary service operation




. response to paging

. after call release if the call lasted longer than 3 minutes

If there is an incoming call to a subscriber whose mobility managementlocation area is unknown (after a VLR reset, for example), the VLRapplication starts a search procedure. When the search has beensuccessfully completed, the new MM LAI is updated in the VLR database,if available.

The IMSI detach flag is updated after each location registration procedure,if necessary. If there is an incoming call to a subscriber who is in an 'IMSIdetached' state, the VLR application rejects the call.

The last active date (time stamp) is updated after every procedure whichindicates that the mobile station is in an active state (for example, locationupdating, a call, or a supplementary service operation).

The HLR address is fetched from the HLR during the location updatingprocedure. The address is used in subsequent procedures towards theHLR.

The SGSN index is not zero if the MS is GPRS-attached. In this case, theSGSN notifies the VLR about the location area changes, and the VLRinitiates the paging procedure through the SGSN.

For more information, see Support of interaction with SGSN in MSC/VLR.

The zone code list represents those zones (that is, group of location areas)where the user is allowed to roam.

For more information, see Regional roaming.

All location data is lost at the VLR restart. The network updates thelocation automatically when the mobile station is active (for example,location updating, a call, or a supplementary service operation), or when itresponds to the search procedure during an incoming call set-up.

The operator can handle the subscriber data in the VLR with thecommands of the Visiting Subscriber Identification Handling (MV)command group.

IMSI analysis

The IMSI number analysis service enables the operator to route thefollowing requests to the correct HLR:



. a request from a new mobile subscriber for location updating

. a request for authentication triplets/quintets for a new mobilesubscriber

. a 'restore data' request if subscriber data is lost in the VLR and thereis an incoming call to the subscriber

. a request for GSM restoration towards the HLR

The IMSI numbers that cannot be analysed are blocked by default, whichmeans that roaming is not allowed.

The IMSI analysis enables the VLR to find an address for contacting thesubscriber's HLR. After the first contact, the HLR sends a more specificHLR address, and this is stored in the VLR subscriber database.

VLR parameters

VLR parameters are used to control certain functions in the VLR. Theoperator can change and output the values of the parameters. Theparameters are handled with the commands of the VLR and PLMNParameter Handling (MX) command group.

The parameters are divided into PLMN-specific and VLR-specificparameters. The PLMN-specific parameters control those VLR functionswhich depend on the subscriber's HPLMN. The VLR-specific parametersare independent of the subscriber's HPLMN.

For more information on the VLR- and PLMN-specific parameters, seeParameter Management in EIR, HLR and VLR.

Security

The system provides the following security functions:

. ciphering, which ensures a secure transmission on the radio path

. TMSI, which makes it impossible to trace a subscriber by listening tothe radio path

. integrity protection (UMTS only)




. mutual authentication, which prevents unauthorised access to thenetwork; UMTS subscribers can also authorise the network (a UMTSsubscriber is a subscriber having a UMTS SIM card)

. IMEI checking, which is made to guarantee that the equipment isused only by its rightful owner. Another purpose of the IMEI checkingis to guarantee that only the type-approved mobile equipments canuse the network.

For more information on security-related issues, see Securitymanagement in AuC, EIR and VLR and Parameter management in EIR,HLR and VLR.

1.5 Location registration-related data in the HLR


The HLR database provides three information elements for locationregistration functions:

. the addresses of the MSC and the VLR in the area where the MS iscurrently located

. information about the service area of the MS

. information about how wide area the MS is allowed to roam in in thenetwork

The addresses are received in the location updating request. The servicearea is given to the subscriber when it is created in the HLR database, butthe operator can change it with MML commands.

If none of the subscriber basic services can be used in the VPLMN, thelocation registration is denied by the HLR.

Subscriber data in the HLR can be handled with the MML commands ofthe Home Subscriber Identification Handling (MI) command group.

HLR parameters

HLR parameters are used to control certain functional properties in theHLR. They are handled with the MML commands of the HLR and PLMNParameter Handling (MJ) command group.



The parameters can be divided into HLR-specific and PLMN-specificparameters. The PLMN-specific parameters control those HLR functionswhich depend on the PLMN (in some cases also on the VLR) in which thesubscriber is roaming. The HLR-specific parameters are generalparameters of the HLR: they are independent, for example, of the PLMN.

This section describes the use of the HLR parameters in location updatingprocedures. The point of view is functional: the parameters are describedas means of controlling certain functions. The names of the parametersare written in capital letters; the abbreviation 'PLMN' appearing in bracketsafter the parameter name means that the parameter is PLMN-specific, theabbreviation 'HLR', in turn, indicates an HLR-specific parameter.

PLMN description

A PLMN is specified in one of the following parameters:

. PLMN NAME (PLMN)

. PLMN INDEX (PLMN)

. PLMN COUNTRY AND NETWORK CODES

The PLMN INDEX parameter is the index of the PLMN entry; it is createdautomatically in connection with a new PLMN entry.

Both HPLMN and VPLMN defaults are available in the PLMN-specific file.When a new entry is defined, the operator has to decide whether it getsVPLMN or HPLMN defaults as its initial values.

The PLMN COUNTRY AND NETWORK CODES parameter defines the PLMN(or VLR) of the entry. This is a key parameter, used for searching thePLMN-specific parameters in the file. The parameter can be as specific asnecessary to enable the managing of the country PLMN parameters andeven VLR-specific parameters. If a VLR of an older release does notsupport certain functions in an HLR upgrading, a VLR-specific parametercan be used to screen the sending of data to the VLR associated with thenew function.

Mobility management in location registration

Update location

When the HLR receives an 'update location' message from the currentVLR of the subscriber, the HLR checks whether the subscriber has aservice defined in the ROAMING NOT ALLOWED FOR SUBSCRIBER WITHCERTAIN SERVICES (PLMN) parameter. If the subscriber has this kind of




a service, the HLR prevents access to the network by sending a negativeacknowledgement and the error code 'roaming not allowed'. When themobile station receives the error code, it does not try to gain access to thenetwork again.

Note that even if the parameter was VLR-specific, the access to the wholePLMN is denied because of the error code. The subscriber's VLR andMSC addresses are defined as 'unknown' in the HLR.

If the 'update location' operation succeeds and there are short messageswaiting for the MS in the SMSC, the HLR alerts the SMSCs, informingthem that the MS is reachable. Because the MS may need time to get intoa state in which it can receive short messages, the operator can delay thesending of the alert message with the DELAY OF SENDING ALERTSparameter.

The networks from which a subscriber is allowed to make location updatescan be specified when creating subscriber data in the HLR. The networksare specified in the SERVICE AREA OF PRIMARY MSISDN parameter in theMIC command. The area can be one of the following:

ALL the whole GSM network

OWN the own national network

NAT all national networks

INT the own national network and all internationalnetworks

Insert subscriber data

The MAP level and version needed in the 'insert subscriber data' operationare defined in the MAP LEVEL (PLMN) and MAP VERSION (PLMN)parameters. Those supplementary services which must not be transferredto the VLR are screened out from the 'insert subscriber data' message inthe NOT ALLOWED SUPPLEMENTARY SERVICE (PLMN) parameter. Theservice interactions are not checked in the HLR.

Note that the responsibility for the use of this parameter is the operator's.

The principle of the basic services is the same: the services defined in theNOT ALLOWED BASIC SERVICE (PLMN) parameter as forbidden are notsent to the VLR in the 'insert subscriber data' operation. If all basicservices of a subscriber belong to forbidden services, 'update location' isnegatively acknowledged, and the 'roaming not allowed' error code isgenerated. Also, 'cancel location' is sent to the old VLR, and the VLRaddress is defined as 'unknown' in the HLR.



Note that since the service interactions are not checked in the HLR, theresponsibility for the use of this parameter is the operator's.

1.6 Location registration-related mobilitymeasurements and charging

The user can handle location registration-related mobility measurementswith the MML commands of the GSM Measurement Handling (TP)command group.

Mobility measurements and charging in the VLR

In the VLR, there are counters implemented for the following:

. location updates of the home subscribers within the VLR area

. location updates of the home subscribers within the VLR areabetween HPLMNs

. location updates of the home subscribers from one VLR area toanother within one PLMN

. location updates of the roaming subscribers within the VLR area

. location updates of the roaming subscribers within the VLR areabetween HPLMNs

. location updates of the roaming subscribers from one VLR area toanother

. periodic location updates

. IMSI attach

. IMSI detach

. arriving visitors

. departing visitors

. GPRS initiated location updates

. registered subscribers per LA

. registered home subscribers per HLR address

. registered roaming subscribers per PLMN name

The same counters are implemented for normal and telemetricsubscribers.




Charging records of location updates can be created in the VLR. Acharging record can also be created during a location update, for example,when the MSC or CGI/SAI changes. The amount of charging datadecreases when unnecessary toll tickets (such as those caused byperiodic location updates) are not used.

Mobility measurements in the HLR

In the HLR, there are counters implemented for the following:

. location updates of the home subscribers to other PLMNs

. location updates of the home subscribers from another PLMN backto the HPLMN

. the total number of location updates of home subscribers

. registered subscribers in each VLR

. GPRS location registration

. registered subscribers per SGSN



2 Location registration-related features

Features that are affected by or have an effect on location registration arepresented briefly below. More detailed information can be found in thedescriptions of the respective features.

2.1 National roaming

National roaming is a service which enables a mobile station of a givenPLMN to obtain services from another PLMN in the same country on alocation area basis, with automatic return to the HPLMN when this ispossible.

The main functional property of national roaming in the network subsystemis that it can prevent location updates in certain areas (groups of locationareas) of subscribers from other networks, while allowing it in other parts ofthe network.

National roaming allows the operator to differentiate in a certain nationalnetwork between areas where roaming from neighbouring networks isallowed and where it is denied.

The basic assumption is that when a subscriber roams from the samecountry but from another network, the normal condition is not allowed. Thismeans that if this feature is used, the default setting concerning a case thatrestricts roaming; the cause is 'national roaming restricted'. If thesubscriber of another network is explicitly allowed to roam in a particularlocation area, location updating is accepted.

This feature is based on LA information, 'national roaming allowed', whichdefines whether subscribers from other national networks are allowed toroam into a particular location area.

Operators in the same country can define areas where roaming betweentheir networks is allowed, and others where it is restricted.



Location registration-related features

For more information on national roaming, see Feature 124: NationalRoaming, Feature description.

It cannot be guaranteed that this feature functions in GSM Phase 1 mobilestations.

2.1.1 Location updating

National roaming conditions are checked at location updating. If the mobilestation's PLMN information has been defined as 'home country and visitorPLMN', a national roaming check is made. For this purpose, location areashave information of MNC and of the national networks from which roamingis allowed.

If the MNC defined for a particular location area does not correspond to theMNC in the IMSI, location updating is rejected because of the nationalroaming restriction.

If the MNC has been defined for the location area in question, locationupdating is accepted.

The national roaming restriction indication to the mobile station dependson what GSM specification the MS supports. The GSM Phase 1specification does not include national roaming definitions.

The specification phase of a mobile station is indicated in the revision levelfield of the MS classmark. The national roaming restriction is signalled tophase 1 mobile stations in a 'location area not allowed' error code; forphase 2 mobile stations the error code is 'Roaming not allowed in thislocation area'.

If the location updating is rejected and the error code is 'Roaming notallowed', the MS starts the initial access procedure.

Note

Because the error code 'location area not allowed' is not intended to beused in this context, some of the mobile stations supporting the phase 1specification may behave in an unpredictable way. Therefore, checkingthe function of phase 1 mobile stations in this respect is recommendedbefore the feature is activated.



The handling of user information in the network depends on what theupdate status of the subscriber in the VLR was at the moment when thelocation updating of the MS was rejected.

Mobile subscriber known to the VLR

In this case, national roaming was allowed at the time when the previouslocation updating occurred. Later, when location updating is attemptedagain, roaming is not allowed any more, and the national roamingrestriction is effective. In this case, the user status in the VLR is defined sothat the originated attempts are not allowed.

Mobile subscriber not known to the VLR

The user information is not obtained from the HLR.

2.2 GSM restoration

The GSM restoration feature includes the procedures needed for ensuringthe integrity of data in the location registers after the reset of the wholenetwork element.

Restoration procedures are defined for the HLR and the VLR.

For more information on GSM restoration, see Feature 226: GSMRestoration, Feature Description.

VLR reset

When the VLR is restarted, all data in the subscriber database of the VLRis lost. After the VLR is restarted, it functions normally: the same way inwhich it functions when the subscriber is not identified in the VLR.

In case of location update or IMSI attach, the data is received from theHLR in the normal location registration procedure.

When the 'provide roaming number' request concerns an unidentifiedsubscriber, the VLR no longer sends the 'send parameters' request like inMAP Phase 1. This is replaced with a 'restore data' operation. Theoperation is very similar to a location update operation.




Figure 8. VLR restoration in GSM Phase 2

If the subscriber tries to originate a call or makes a supplementary servicecontrol request, the VLR performs an implicit location update, that is, theVLR notifies the HLR and downloads the subscriber's data if theIMPLICIT_LOC_UP system configuration parameter is active. Then theoriginal operation continues normally. If the implicit location update featureis not active, the VLR returns the 'unidentified subscriber' error code. Thismakes the MS initiate the location registration request. The HLR handlesthe 'send parameters' and the 'update location' requests normally.

The network starts the restoration procedures automatically after the resetof the VLR.

HLR reset

After the reset of the HLR, the HLR reloads all data from the back-up, andinforms all VLRs involved by sending them a 'reset' message.

GMSC VMSC MS

1. Send_Routing_Information

2. Provide_Roaming_Number

8. Page MS

5. Provide_Roaming_Number_Ack (MSRN)

6. Send_Routing_Info_Ack (MSRN)

7. IAM

3. Restore_Data

4. Restore_Data_Ack

Subscriber Data Transfer

Normal Call Completion

HLR



To prevent the loss of supplementary service information at the restart, an'SS check required' indication is set in the HLR. Information about thepossible loss of data is transferred to the VLR in reply to the locationregistration request. The VLR sends it to the MSC at call establishment,and the MSC forwards it to the MS.

When the VLR receives the reset message from the HLR, it sets a resetindicator concerning all the subscribers of that particular HLR. Theindicator is checked every time a subscriber originates a call or makes asupplementary service control operation. The location registration isinitiated if the reset occurred after the previous location registration of thesubscriber.

The network starts the restoration procedures automatically after the resetof the HLR.

Restrictions

The GSM specification introduces parameters called restorationindicators, which indicate whether the consistency of subscriber data hasbeen confirmed. The indication of the confirmation is not implemented asspecial parameters in the subscriber data, but in a more efficient way byusing reset counters. The functional properties are the same.

The consistency of data between the HLR and the VLR cannot beguaranteed in all cases if administrative commands are given during therestoration procedure.

2.3 Subscription-based network access

Subscription-based network access is a feature which enables theoperator to prevent or allow roaming in certain VLR areas.

The feature is based on roaming profiles defined by the operator. Themaximum number of different profiles is 99. Each subscriber can beassociated with one profile.

When the subscriber tries to register in a VLR for the first time, thesubscribers's roaming profile - if the subscriber has one - is checked fromthe HLR. If the VLR has been defined as 'not allowed' in the subscriber'sroaming profile, the registration is rejected, and the subscriber cannotroam in that particular VLR area.




This feature also applies to the GPRS network, that is, the VLR in thiscontext can be considered as a 'VLR' in the SGSN, the VLR address beingthe SGSN address.

For more information on subscription-based network access, see Feature541: Subscription-Based Network Access, Feature description andFeature 857: Support of General Packet Radio Service, Featuredescription.

Properties

Figure 9. Overview of the feature

HLR

IMSI

Subscriber Data

VLR Address

VLR Address Analysis

RP Index PLMN Index

Roaming Profile Analysis

Location UpdateRequest

PLMN 0 PLMN 1

RP 1

RP 2

99

allowed

not allowed

not allowed

allowed

AllowedNot Allowed

ContinueNormally

...1499

...

...

...

NegativeResponse



When an MS roams in a new VLR area, the new VLR initiates a locationupdate towards the HLR. If the network operator has given a roamingprofile index to the subscriber, a roaming profile analysis is performed inthe HLR. The service area of the subscriber is analysed before theroaming profile. If the parameter prevents roaming, the roaming profile isnot analysed.

The VLR address, received in the location update request, is analysed toget a PLMN index. The roaming profile analysis can be made when boththe roaming profile index and the PLMN index are known. If the result ofthe analysis is 'not allowed', the location update is refused. The operatorcan decide what error code is generated at the refusal: it can be either'roaming not allowed' (this is the default) or 'unknown subscriber.' If theresult of the roaming profile analysis is 'allowed,' the location updatecontinues in the normal way.

The roaming profile analysis is based on a roaming profile table, whichconsists of 99 different roaming profiles. A profile is based on PLMNindexes. They are allocated to all branches in a VLR address analysis. Inevery roaming profile, each PLMN index has a status, which is either'allowed' or 'not allowed.' The roaming profile analysis is very flexiblebecause there is no check between it and the VLR address analysis. Theoperator can define a status for indexes which have not yet been allocatedto a VLR address analysis branch. For example, if the operator wants theroaming profile to allow roaming in the VLR(s) of just one particular VLRaddress analysis branch, all PLMN indexes in the roaming profile exceptfor one are defined as 'not allowed'. When new branches are created (newindexes are taken into use), they automatically obtain the same status.When creating a new branch to a VLR address analysis, however, thesettings for that PLMN index in all roaming profiles must always bechecked, and updated if necessary.

When the operator defines a roaming profile index for a subscriber, thecancel location procedure towards the present VLR is initiated. Changes inthe roaming profile table do not initiate the cancel location procedure.

The operator can deactivate the feature with an MML. After thedeactivation, no roaming profile analysis is made even if there areassociations with the roaming profile in the subscriber data; all VLRs areconsidered 'allowed'.

If the checking of the roaming profile status fails, roaming is allowed.




Note

When the subscriber roams in another VLR area during a call, the newlocation is not updated in the HLR until the subscriber has finished thecall. This means that the subscriber may be using the networkresources of a VLR area in which that particular subscriber is notallowed to roam.

Capacity

The roaming profile analysis affects the performance of the locationupdate procedure to some extent. It also causes some additional systemload in the HLR network element.

Interaction

For the VLR address analysis, this feature is dependent on Feature 585:HLR Parameter Management. For more information, see GSMMeasurement Handling (TP).

When the Support of the GPRS feature is available in the HLR, thesubscription-based network access is applicable also to the GPRSnetwork. The PLMN index of the GPRS subscriber is determined on thebasis of the SGSN address. For more information, see Feature 857:Support of General Packet Radio Service, Feature description.

2.4 IN mobility management

The IN MM feature is one of Nokia's non-call-related IN functions. In thisfeature, the IN concepts and architecture are applied to the MMtransactions, that is, location registration procedures.

An MM state model provides the operator with TDPs, at which the controlof the location registration procedure can be moved to an external SCP inthe IN. The SCP can then decide, for example, on the basis of the locationof the subscriber, whether the location registration is accepted or not.

The trigger detection point in intra-VLR location registration is conditional,depending on the type of the location update: normal or periodic locationupdate or IMSI attach. This cuts down the amount of visits to the SCP, thusenabling the SCP to serve more customers.



Charging data can be collected from location updating procedures.Initiated by location registration, the SCP can send charging information tothe SSP, which will forward it to the billing center. This enables, forexample, location-dependent charging.

Gapping is a new service which gives better control over the SCP load. Ifthe SCP is heavily loaded, it can ask the SSP to limit the number of contactattempts for a certain service.

Statistical information about location updates rejected by the SCP areadded to the trace report. For more information on IN MM, see Feature742: IN Mobility Management, Feature Description.

CAMEL (Customised Applications for Mobile network Enhanced Logic) isan IN architecture within GSM.

CAMEL provides mechanisms to support services independently of theserving network. With CAMEL, it is possible to offer Operator-SpecificServices (OSS), that is, intelligent network services, for the subscriberwhile he is roaming outside the home PLMN. Subscribers can use theoperator-specific services they are accustomed to also when roaming inother networks.

In CAMEL Phase 3, a notification is sent to the CSE when the VPLMN hascompleted the processing of any of the following mobility managementevents:

. Location updated in the same VLR service area

. Location updated in another VLR service area

. IMSI attach

. MS-initiated IMSI detach

. Network-initiated IMSI detach

For more information on CAMEL Phase 3, see Feature 1159: CAMELPhase 3 Call Unrelated Parts, Feature Description.

Functionality of the feature

IN MM services can be offered to different subscriber types as follows:




. Subscriber-specific services to the home subscribers. The servicesare provisioned in the subscriber data.

. Network-specific services to all roaming subscribers on a PLMNbasis. The services are provisioned in the PLMN-specific file in theVLR. Offering the network services to the home subscribers must beavoided if there is a risk of overloading the network elements.

The IN MM architecture consists of the HLR, the VLR, and the SCP. TheSCP includes an MM-SCF and a service logic program for the MMservices.

An MM-SSF carries out the handling of detection points in the networkelements. The MM-SSF exists both in the HLR and in the VLR.

The protocol between the MM-SSF and the MM-SCF is Core INAP,modified for the MM requirements. Between the HLR and the VLR, theprotocol is MAP version 2, extended with the IN mobility managementsubscriber data.

Figure 10. IN mobility management architecture

Capacity

The IN MM feature increases the memory consumption of the HLRdatabase by two Bytes per subscriber and that of the VLR database byone Byte per subscriber.

SCP

SSPMSC

INAP

MAPVLR

SSPHLR

INAP

MM-SSF

MM-SSF

MM-SCF



The load increase within one transaction might be considerable iftriggering takes place. Therefore, it is assumed that these services areintended only for special subscribers, not for all subscribers.

There is a specific timer parameter (SCP_AVAILABILITY_TIMER) in theVLR and in the HLR which determines the maximum waiting time of thefirst response from the SCP. The value of this parameter can be adjustedby the operator, but the default is that the waiting time is as short aspossible to avoid overload in case the MM-SCF does not respond.

The use of transaction types in the intra-VLR LocUp DP, cuts down theamount of SCP triggering. The same happens if the Regional Roaming(Zone Codes) feature is used together with IN mobility management. This,in turn, increases the service capacity of the system.

The use of the call gapping process prevents the SCP overload.

Feature interworking

MT USSD: the MM-SCF may use the USSD functionality to interact withthe subscriber. This functionality, however, is independent of the locationregistration and it may be carried out as a separate transaction in the A-interface.

The MM-SCF may use standard MAP signalling to interrogate or changethe subscriber data in the HLR.

Regional Roaming (Zone Codes)

The Regional Roaming (Zone Codes) feature is needed if a location-basedtriggering condition is used. The operator may define on a zone basiswhether triggering is allowed within the zone. If the subscriber is allowed toroam within the zone, and triggering is allowed within the zone, and the DPis met, the InitialDP is sent to the SCP. Otherwise, the location registrationcontinues normally according to the zone code table.

Operational view

In unsuccessful location registration attempts, a specific 'ReleaseCallcause' is added to the trace report both in the HLR and in the VMSC toindicate that the SCP rejected the location registration.

Statistical information is also collected of gapped SCP visits.




Restriction

Because of a risk of overload, the PLMN-specific LocUp detection pointshould not be set for home-PLMN subscribers.

Also, because of the possible risk of overload, the intra-VLR LocUpdetection point should not be encountered in the periodic locationregistration transactions. No IN CDR is produced of periodic locationregistration.

To avoid congestion in the IN-network, this feature should not be providedfor all subscribers.

The FCI operation can be used only towards the SSP/MSC/VLR. It cannotbe used within the location registration TDP in the HLR, for example.

2.5 Regional roaming

Regional roaming (zone code) allows the network operator to controlsubscriber roaming. This means that the operator can define the locationareas where an individual subscriber can have the service.

The meaning of zones is defined in the VLR by the operator. These zonesare shown as zone codes for the subscriber's database in the HLR. Theoperator defines the location areas belonging to the zones where roamingis allowed or not, and the location areas where IN MM triggering is allowedor not during the location update. If the subscriber does not have any zonecodes in the HLR or those zone codes are not accepted (for example, theuse of regional roaming is denied for roaming subscribers), the operatorcan define a default zone code list with the PLMN parameters in the VLR.The operator can configure the VLR so that if zone codes from the HLRare not accepted, the VLR checks the default zone codes before fetchingany authentication vectors from the AuC or starting the location updatetowards the HLR. If the default zones restrict roaming, the VLR saves thesignalling towards the AuC and HLR.

The roaming area can be a single location area, several location areas, orthe whole PLMN. Also, the roaming area can be scattered: for example,the subscriber may have a roaming area that consists of 10 roaming areasaround the 10 largest cities, while his roaming in scarcely populated areasis forbidden.



A subscriber who has only a limited access to the PLMN receives an errormessage when he tries to roam to a location area which is not provided forhim. For more information on regional roaming, see Feature 805: RegionalRoaming, Feature Description.

Function in the HLR

The operator can define up to ten zone codes for the subscriber. Thesezone codes are stored in the subscriber's database as permanent data.

The zone codes are stored in the database in the same order as they aregiven by the operator. The subscriber's zone codes are transferred to theVLR in the same order. The sending of zone codes can be defined as a notallowed service in the PLMN parameters. This means that the operatorcan define for the VLRs where the zone codes are sent.

If not all the zone codes of the subscriber are known by the VLR, a locationupdate is acknowledged to the HLR with the information that the MSC areais restricted. In this case, the HLR sets the msc_area_restricted flag torestricted and the HLR functions as if the subscriber could not be reached.

Function in the MSC/VLR

The operator creates the interpretation of the zones in the MSC/VLR, thatis, the operator creates the zones and assigns one or more location areas(in the corresponding MSC/VLR area) to them.

The zones can deny or allow roaming and/or deny or allow IN MMtriggering during the location update. The operator can define what kind ofcause value is sent to the MS when the location update is denied byregional roaming.

If there is at least one zone that allows roaming, roaming is allowed. Ifnone of the subscriber's zones apply to the MSC/VLR area, roaming isdenied. If there is at least one zone that denies the IN MM triggering, the INMM triggering is not done during the location update. The checking of theIN is done only if the location update is allowed to the current location area.If the IN denies roaming to the current location area, the location update isdenied.

If the subscriber does not get any zones from the HLR, the zone codes areread from the PLMN parameters. This is very useful for roamingsubscribers and solutions where most of the subscribers do not need anyzone codes.




If there are zone codes neither in the subscriber's database nor in thePLMN parameters, roaming is allowed to all location areas and the IN MMtriggering is done as defined in the PLMN parameters when the locationupdate occurs.

The operator can view the location areas of a particular zone, theinterpretation of the zone (allowing or denying zone), and the zones thatare assigned to the subscriber.

Note

The same zone can have a different interpretation in different MSC/VLRareas. This can be used if the operator wants to grant the subscriber aroaming area which extends to several MSC/VLR areas. He can thendefine the same zone in both MSC/VLRs so that it includes the neededlocation areas in the corresponding MSC/VLR. The operator can alsoassign several zones, each of which is defined only in one MSC/VLR.Thus the total roaming area is the areas granted by individual zonestogether.

The table below represents the zone codes in the MSC/VLR.

Table 1. Zone codes in MSC/VLR

Location area 1 Location area 2 ... Location area n

Zone Code 1

Roaming allowedIN trigg. denied

included= Y included= Y included= N

Zone Code 21

included= Y included= Y included= N

...

Zone Code 8867

included= Y included= N included= N

Location update in the MSC/VLR

When the subscriber tries to do a location update for the first time in theMSC/VLR area, his zone codes are fetched from the HLR and storedamong other subscriber information in the VLR. The location area is thenchecked against the subscriber's zone codes.



The checking starts from the first zone code that can be found from thesubscriber. When the MSC/VLR finds a zone which has the attemptedlocation area defined, the zone's interpretation is checked:

. IN MM triggering during the location update is not done if the locationis not allowed to the current location area.

. If the location update is not allowed by the zone codes or IN MMtriggering during the location update is denied, the IN MM triggeringis not carried out.

. If the zone allows roaming, the location update is successful; if not,an error message is the result.

If the subscriber is known to the MSC/VLR, his zone codes are fetchedfrom the database of the MSC/VLR. If the subscriber is known to the MSC/VLR, but the location update is not allowed by the zone codes, the MSC/VLR sets an 'IMSI detach' mode for that subscriber, that is, the subscriberinformation is not deleted from the MSC/VLR but mobile-originated andmobile-terminated traffic (for example, call and SM) are prevented. The'IMSI detach' mode is removed when the subscriber makes a successfullocation update.

If not all the zone codes of the subscriber are known by the VLR, thelocation update is acknowledged to the HLR with the causemsc_area_restricted and the VLR sets an 'IMSI detach' mode for thatsubscriber, that is, the subscriber information is not deleted from the MSC/VLR but mobile-originated and mobile-terminated traffic (for example, calland SM) are prevented. In the HLR, the msc_area_restricted flag is set torestricted and all MT traffic is denied to the subscriber.

If the IMSI Detached flag is set because the called subscriber is notallowed to roam into the current location area, the 'Absent Subscriber' errormessage is returned to the HLR if there is an attempt to transfer MT trafficto the subscriber.

Capacity

This feature is applicable to all subscribers, even simultaneously.However, the great number of regional subscribers affects the number ofunsuccessful location update requests and thus increases the load in thenetwork.

The memory consumption in the HOSTEL database is 22 b/subscriber/pairof HLR unit. The memory consumption in the VISION database is 21 b/subscriber/pair of VLR unit.




Feature interworking

The feature can be used together with Feature 541: Subscription-BasedNetwork Access. By using the Subscription-Based Network Accessfeature the operator can define the not allowed VLRs in the HLR. For moreinformation, see Feature 541: Subscription-Based Network Access,Feature Description.

Feature 526: Charging Based on Home Area facilitates the regionality andcontrols the charging. However, it is the operator's responsibility to designthe roaming and charging areas effectively. With the SAM parameter theoperator can restrict roaming outside the HPLMN. If roaming is allowed(according to the SAM), the default is that a subscriber without any zonesprovided has a full access to the network. For more information, seeFeature 526: Charging Based on Home Area, Feature Description.

This feature is needed in Feature 742: IN Mobility Management, phase 2, ifthe triggering condition for location is used. The functionality uses the zonecode table, where the operator may define whether the triggering isallowed or denied per zone basis. For more information, see Feature 742:IN Mobility Management, Feature Description.

Restrictions

The maximum number of supported zone codes in one VLR is 500. Themaximum number of zones per subscriber is 10 in the HLR databasebecause only the zone code part of the RSZI is stored in the HLRdatabase. Regional roaming does not prevent a handover to a forbiddenlocation area. The subscriber can have service during a handover, even ifhe moves to a forbidden location area. For example, if the subscribermakes a call and moves to a forbidden area and a handover occurs, thecall continues normally. After the call, the mobile station performs alocation update request which is subsequently denied. After a stand-aloneinsert or restore data operation, GSM restoration, and deleting the zonecodes in the HLR, it is not possible to get the MS out of service before thenext location update.

2.6 Network identity and time zone

With the Network Identity and Time Zone feature, the operator can transferthe network name, universal time, date, and time zone to the mobilestation, for example, when the MS registers to the network.



This enhances international/national roaming by permitting an accurateindication of network names that are either newer than the mobile stationor have changed their name since the mobile station was sold or itssoftware updated. Also, an MS supporting NITZ can set its clockautomatically to local time and take daylight-saving times into account.

Furthermore, the realisation of the MS can be simplified because there isno more need to keep the clock running when the mobile station is in thepower-off state. For more information on NITZ, see Feature 1005: NetworkIdentity and Time Zone Support, Feature Description.

Properties

This feature makes it possible for a serving PLMN to transfer its currentidentity, universal time, daylight-saving time, and local time zone to theMSs, and for phase 2 mobile stations to store and use this information.Each one of these elements is optional.

The network name, time, daylight saving time, and local time zoneinformation can be transferred from the serving PLMN to the MS in thefollowing situations:

. during an inter-VLR location update procedure

. during an IMSI attach procedure

. during a normal location update procedure

. during a periodic location update procedure

Capacity

The feature has a very minor effect on the load of the BTS unit and theVLR unit.

Restrictions

The 7-bit SMS coding scheme is used instead of UCS2 and 8-bit SMScoding.

2.7 Inter-system handover and UMTS changes in theMSC

This feature is needed to ensure a successful migration to 3G and offers awide range of high quality services for 2G and/or 3G subscribers.




The feature provides support for handovers from GSM to UMTS, and viceversa, and for intra-UMTS inter-MSC relocation. Also, the necessarychanges in the MSC for the support of UMTS are implemented in thisfeature.

For more information, see Feature 1260: Inter-system Handover andUMTS Changes in MSC, Feature Description.

Equivalent PLMN

In PLMN-specific parameters, the operator can specify a set of PLMNidentities which are sent to the mobile equipment in location updating. Themobile equipment stores this list of 'equivalent PLMNs'. The stored listconsists of a list of equivalent PLMNs as downloaded by the network andthe PLMN code of the network that downloaded the list. All PLMNs in thestored list are regarded as equivalent to each other for PLMN selectionand cell selection/re-selection. This functionality provides clear benefits forthe operators who have a different PLMN code in their UMTS and GSMradio access networks, and/or have a shared network with anotheroperator, and/or operate networks also in other countries. Additionally, theoperator may use this feature to make the users registered in their networkto prefer their partners' networks when the coverage of their own networkis not available.

Equivalent PLMN Functionality is a useful tool for enabling seamless cellre-selection among cells belonging to different PLMNs. This includesnetwork sharing cases, as well. In other words, the operators’ own corenetwork can send the shared networks’ PLMN code as an equivalentPLMN to its subscribers, which makes cell selection seamless when theoperator’s own subscriber moves between the shared and the operator’sown coverage areas.

The Equivalent PLMN Functionality can also be used to keep internationalinbound roamers in the shared network when they move outside of theoperators’ own network coverage area. Otherwise, an internationalinbound roamer may select other operators' 3G PLMN.

The Equivalent PLMN Functionality has no impact on handovers becausethe UE does not select a new target cell for handovers but it is done by theSRNC using neighbour lists.

Access control

Access parameters are implemented in the VLR. With these parametersthe operator can control the subscribers' access to the network by givingaccess rights for a UMTS/GSM type subscriber to the UMTS/GSM radionetwork. This can be done on a PLMN or IMSI range basis. The subscriber



type (UMTS/GSM) is derived by the VLR based on authentication vectors.The radio access information is sent by the MSC to the VLR. Based on thisinformation and access right parameters, the VLR can accept or reject theMM connection establishment or location updating procedure accordingly.If the subscriber type is unknown and the currently used access network isrestricted for both user types, the VLR rejects the location update withoutretrieving authentication vectors from the AuC. Cause codes, used if theVLR rejects the MM connection establishment or location updating, can beset by the operator for each access right parameter separately. If aseparate cause code is not defined, the default values are used.

The VLR sends the access right parameters also to the MSC. The MSCuses these parameters to allow or reject the inter-system handovers forthe served subscriber.

The operator can use the commands of the VLR and PLMN ParameterHandling command group (MX) to display and modify VLR-specific andPLMN-specific parameters. For each PLMN, the operator can define thefollowing access right parameters:

. GSM subscriber allowed to BSS

. GSM subscriber allowed to UTRAN

. UMTS subscriber allowed to BSS

. UMTS subscriber allowed to UTRAN

Each parameter can have the following values: TRUE or FALSE.

The figure below shows the types of handovers that are supported with thehelp of this feature, and with other UMTS features.




Figure 11. Handover support

Changes in the MSC for the support of UMTS

To be able to connect the UMTS radio network to the MSC and to be ableto make Intra-UMTS/Inter-system handovers, the following requirementsare set to the MSC:

. Security Requirements due to inter-system handover

. Key handling in basic and subsequent inter-MSC handovers

. BSSMAP R99 implementation in the A interface

. RANAP implementation in the MAP E interface

. MAP phase 3 implementation in the E interface

. Requirements coming from the support for Multiple RNCs perMultimedia gateway

. Signalling requirements for the Gs interface

. Charging and Statistics support

. Access and handover control

InterSystemRNC < > BSC R99

IntraSystemRNC < > RNC

InterSystemRNC -> BSC R98

Inter MSC Intra MSC

Inter PLMN Intra PLMN Inter PLMN Intra PLMN

supported not possible

BSC R98/R99 < >BSC R98/99

BSC R98 -> UMTS



2.8 Support of interaction with SGSN in MSC/VLR

The support of this feature is realised by supporting a standard Gsinterface in the MSC/VLR.

If the Gs interface is supported by the SGSN and the MSC/VLR and thus asubscriber-specific association can be established between the CS andthe GPRS network, the following benefits are gained when a class A or BGPRS MS is used (class C MSs cannot be simultaneously IMSI- andGPRS-attached):

. It is possible to make combined LA/RA updates in a PLMN thatsupports both the CS and the GPRS functionality, and thus saveradio resources. Since the RA is a subset of only one LA, thechanging of the LA of the GPRS MS also changes the RA. Acombined LA/RA update request first goes to the SGSN, where theRA of the IMSI is updated. The SGSN delivers the LA updaterequest further to the MSC/VLR via the Gs interface.

. It is possible to make a combined IMSI/GPRS attach or combinedIMSI/ GPRS detach, and thus save radio resources. The combinedrequest first goes to the SGSN that delivers the IMSI attach ordetach request to the MSC/ VLR via the Gs interface.

. It is possible to make a circuit-switched (CS) paging request via theSGSN (paging co-ordination). This is an important feature,especially for those class B MSs that are capable of monitoring onlyone paging channel at a time (for example, in network operationmode III, they revert to the class C mode of operation). An additionalbenefit is that the paging request is performed in a smaller area if itgoes via the SGSN. Although the CS paging request goes via theSGSN, the paging response comes to the MSC on its ordinary route,via the A interface, and the CS connection establishment continuesin the usual manner. The MT SMS and MT USSD paging also go viathe SGSN. The paging procedure is supervised in the MSC by apaging timer. The SGSN may also send the unreachable MS amessage before the paging timer expires. It is possible in thosecases when the SGSN knows that the subscriber is absent. TheMSC can repeat the paging via the A interface if it fails via SGSN (forexample, SGSN is not available, MS is in GPRS-detached state,IMSI is unknown in SGSN, or there is an address error).




. The Gs interface also suppresses the periodic location updates ofthe GPRS-attached MSs in the VLR because the VLR relies on theperiodic routing area updates in the SGSN.

. The VLR does not perform security checkings (authentication andIMEI checking) when the location update request comes through theGS interface because it relies on the security procedures of SGSN.The IMEI (with software version) that the SGSN sends is acceptedand stored to the VLR database optionally. If the VLR does notreceive the IMEI, the VLR can ask it from the SGSN at the end of thelocation update with the MS Information Request procedure.

For more information, see 3GPP Technical Specification 29.018,General Packet Radio Service (GPRS); Serving GPRS SupportNode (SGSN) - Visitors Location Register (VLR); Gs interface layer3 specification.

This feature is not supported at the system level in 3G, however, it issupported in the 2G system and 3G circuit switched core network.

For more information, see Feature 881: Support of Interaction with SGSNin MSC/VLR, Feature Description.

2.9 Location update in pool area concept

Features Multipoint A Interface and Multipoint Iu Interface in MSC serverconcept introduce a concept where BSC or RNC can be connected toseveral MSC/MSSs. The area that is served by one or more MSC/MSS inparallel forms a pool area. Within a pool area the MS can roam withoutchanging the serving CN node.

The NRI identifies an individual MSS serving within one pool area. TheNRI is part of the temporary identity TMSI, which the serving MSS assignsto the MS. From the NRI, the BSC or the RNC knows towards which MSC/MSS the MS is directed.

For more information, see Feature 1564: Multipoint A Interface, FeatureDescription and Feature 1449: Multipoint Iu Interface in MSC serverconcept, Feature Description.

Location update

An MS performs location area updates, in which the serving MSS maychange. In these procedures, the new MSS requests MS-specificparameters from the old MSS.



The new MSS uses the old LA together with the NRI to derive thesignalling address of the old MSS from its own configuration data. If thenetwork contains nodes that cannot derive the old MSS from the LAI andthe NRI, a default MSS for each LA is used.

Default MSS and backwards compatibility

The MSSs that can derive the old MSS only from the LAI (for example,because they do not support this feature, or detailed information about theNRIs has not been configured) do not have the information of multipleMSSs serving an LA. These nodes can therefore contact only one MSSper LA. This one node is referred to as the default node. A default nodethat supports this feature derives the NRI from the TMSI. The default nodeforwards the request to the correct MSS in the old pool area. The correctMSS responds by sending the MS-specific parameters directly to the newMSS.

More than one MSS serving the pool area can be used as a default node.This decreases the load on a single node. The default node can be definedper LA.




Documents

Location Registration