MSCDOCM14PDFCD MSC/HLR, Rel. M14.0, Product Documentation, v.

Location Registration

DN987572 Issue 10-0 en

# Nokia Siemens Networks

1 (53)

Location Registration

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia 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

DN987572 Issue 10-0 en

Contents

Contents
Contents 3 List of tables 4 List of figures 5 Summary of changes 7 1 1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.3 1.4 1.5 1.6 2 2.1 2.1.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Location Registration 9 Functional properties of location registration 9 Location registration procedures 13 Intra-MSC/VLR location update 16 Inter-MSC/VLR location update 17 Inter-PLMN location update 19 Location update in the HLR 20 Periodic location update 20 IMSI attach 21 Not-reachable MS 21 Location registration-related data in the VLR 22 Location registration-related data in the HLR 26 Location registration-related mobility measurements and charging Location registration-related features 31 National roaming 31 Location updating 32 GSM restoration 33 Subscription-based network access 35 IN mobility management 38 Regional roaming 42 Network identity and time zone 46 Inter-system handover and UMTS changes in the MSC Support of interaction with SGSN in MSC/VLR 51 Location update in pool area concept 52

29

47

DN987572 Issue 10-0 en

# Nokia Siemens Networks

3 (53)

Location Registration

List of tables Table 1. Zone codes in MSC/VLR 44

4 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

List of figures

List of figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Network elements and interfaces involved in location registration in GSM and UMTS networks 10 Service blocks involved in location registration in the MSC/VLR Service blocks involved in location registration in the HLR UMTS Service Area GSM Cells 14 16 18 34 14 13 12

Location update

Inter-MSC/VLR location update VLR restoration in GSM Phase 2 Overview of the feature 36

Figure 10. IN mobility management architecture Figure 11. Handover support 50

40

DN987572 Issue 10-0 en

# Nokia Siemens Networks

5 (53)

Location Registration

6 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Summary of changes

Summary of changes

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

Changes made between issues 100 and 92

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 to save 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 agreement scenarios has been added. Support of interaction with SGSN in MSC/VLR MS Identity Reguest and alternative CS paging has been added to the Gs interface procedures. Location update in pool area concept Section has been added to the document.

Changes made between issues 92 and 91

No changes in content, only editorial corrections done.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

7 (53)

Location Registration

Changes made between issues 91 and 90

Location registration procedures Parameters for allowing and denying location updates between a GSM and 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 InterMSC/VLR location update. Subscriber parameters Section updated. VLR reset Figure VLR restoration in GSM Phase 2 updated.

8 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

Location Registration
The Location Registration function class includes the functions in the MSC/VLR and the HLR, which are needed in the location update of a GSM or UMTS subscriber in the GSM or UMTS network. In order to be able to route incoming calls, the PLMN keeps track of the location of the mobile station. Location information is stored in functional units called location registers. There are two types of location registers:
.

the HLR, which contains permanent subscriber information and the address of the current VLR of the subscriber if it is known the VLR, where subscriber data is stored as long as the MS is within the 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 B between the MSC and the VLR is an internal interface.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

9 (53)

Location Registration

MS BSS A UTRAN Iu cs R99 MGW A A BSS MSC B VLR MS G D HLR AUC MGW Mc F EIR Iu cs UTRAN MS MS

VLR B MSC

Figure 1.

Network elements and interfaces involved in location registration in GSM and UMTS networks

The network elements use the CCS, MAP, TCAP, and SCCP over MTP protocol stacks for signalling with each other. The BSSAP replaces the MAP and TCAP in the protocol stack in signalling over the A-interface (MSC/VLRBSS). Interaction with other functions and function groups Location registration procedures interact with roaming checking (national and regional), authentication, ciphering and integrity protection, checking of the equipment identity, re-allocation of the temporary mobile subscriber identity, collection of traffic data, as well as with possible IN applications. Location registration procedures are as follows:

10 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

IMSI attach/detach in the MSC/VLR normal and periodic location updating in the MSC/VLR retrieval of subscriber identity and authentication vectors from the previous 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 location registration:
.

AIASEB The A-Interface Applications Service Block implements the BSSAP.

AUCSEB The Authentication Centre Service Block provides authentication services.

CELSEB The Cellular Network Service Block provides cellular network management.

CNGSEB The Charging Service Block provides charging services.

EIRSEB The Equipment Identity Register Service Block provides IMEI checking services.

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

MATSEB The Mobile Application Part Service Block implements the MAP.

MOSSEB The General Mobile System Service Block provides routing analysis for the IMSI.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

11 (53)

Location Registration

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

TRDSEB The Traffic Administration Service Block contains traffic administration services.

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

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

MSC/VLR

MOSSEB

TRDSEB

CELSEB

VLRSEB

CNGSEB

AIASEB

MATSEB

BSSAP

MTPSEB

MAP

Figure 2.

Service blocks involved in location registration in the MSC/VLR

12 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

HLR

CNGSEB

TRDSEB

AUCSEB

HLRSEB

EIRSEB

MATSEB

MTPSEB

MAP

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 the mobile subscribers in its own area and to route mobile-terminated calls efficiently.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

13 (53)

Location Registration

Location Area (LAI) Service Area (SAI)

Figure 4.

UMTS Service Area

Location Area (LAI)

Cell (CGI)

Figure 5.

GSM Cells

14 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

The GSM network is divided into an NSS and a BSS. The BSS is further divided into location areas, which consist of several cells. Every cell has a unique CGI number, which the base stations broadcast continuously. In a UMTS network, there is a UTRAN, which is the equivalent to a BSS in a GSM 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 memory of the MS. The MS keeps listening to the signal from the base station, and compares the LAI number to the one in its memory. If the LAI numbers do not match, the MS initiates a location updating in which the MS informs the core network about its old location area and the BSC/RNC provides the core network with the new location area of the MS. The location information of a mobile subscriber is stored in the MSC/VLR and 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 the mobile station is now in its area. The following figure gives an overview of the procedure.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

15 (53)

Location Registration

MS

BSS

MSC/VLR

AUC/HLR

Location Update Request Request Subscriber Id . Send Own Id.

Security checkings
HLR Update Insert Subscriber Data Ack HLR Update Ack Location Update Ack

Figure 6.

Location update

When an MS changes its location area but remains under the control of the same MSC/VLR, only the location information in the VLR needs to be updated. When an MS changes its location area so that it moves to the control area of another MSC/VLR, the information in the HLR also needs to be updated. As soon as this is done, the HLR cancels the subscriber's data from the previous VLR. When the MS is turned on/off within the same location area, an IMSI attach/detach is performed. The mobile status (attached/detached) is then updated in the VLR.

1.2.1

Intra-MSC/VLR location update

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

16 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

The MS initiates the location update procedure by sending its TMSI or IMSI and old location area identity to the network. The BSC/RNC provides the CGI/SAI to the MSC/VLR. The network may respond with an authentication 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 by an IMEI checking towards the EIR. Ciphering and integrity protection on the radio interface may be started, and the network may allocate a new TMSI for the subscriber.

1.2.2

Inter-MSC/VLR location update

In an inter-MSC/VLR location update, the mobile subscriber changes both his 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 is not registered in the new VLR. The following figure gives an overall picture of an inter-MSC/VLR location update:

DN987572 Issue 10-0 en

# Nokia Siemens Networks

17 (53)

Location Registration

MS

BSS

MSC/VLRnew

MSC/VLRold

AUC/HLR

Channel Assignment Location Update Request Request Subscriber Identity Provide Subscriber Identity

Security checkings

HLR Update Insert Subscriber Data Ack HLR Update Ack Location Update Ack Cancel Old Location Location Cancelling Accepted

Figure 7.

Inter-MSC/VLR location update

The MS starts the location update by sending its TMSI and the old LAI to the MSC/VLR. The BSC/RNC also sends the new CGI/SAI to the core network. 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 the authentication triplets/quintets must be fetched from the old VLR. This is done in a MAP enquiry. The subscriber's IMSI is requested from the old VLR, and an IMSI analysis is performed in order to find out the HLR address of the mobile station.

18 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

The next step in the location update procedure involves sending the IMSI and the address information to the HLR. In response to this, the required subscriber information is received from the HLR. The new location of the MS 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 HLR initiates a 'cancel location' procedure towards the old VLR. If new authentication sets are needed during location registration, they are requested by a 'send authentication info' option before the location update message 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 from another MSC/VLR. When a mobile station roams from one VLR area to another with a TMSI allocated to it by the previous VLR, the new VLR must obtain the IMSI of the MS before the HLR can be updated. The IMSI is obtained by interrogating the previous VLR if the two MSC/VLRs are within the same PLMN. In response to the interrogation, the VLR sends the IMSI of the MS to the new VLR. The authentication sets are also sent if they are requested and they are available. This functionality can be activated between different PLMNs as well, which is 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 of the 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 another mobile network. Location updating must be done in the HLR. The mobile station sends a normal location updating request with TMSI or IMSI and the old LAI to the MSC/VLR. The MSC recognises the old LAI as the LAI of another PLMN.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

19 (53)

Location Registration

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

1.2.4

Location update in the HLR

In the HLR location update, the mobile subscriber's IMSI together with the MSC and VLR ISDN numbers are sent to the HLR. If the subscriber is allowed to roam in the area, the HLR responds by sending the subscriber information to the VLR. When the data is sent, the new location of the MS is 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 in the previous VLR. Location cancellation When a mobile station registers in a new VLR, the subscriber's data is deleted from the previous VLR in a cancel location procedure. The HLR initiates the procedure when it receives an 'update location' message from a VLR other than the one in which the MS was located at the time when its location information was last updated in the HLR database. The cancel location procedure can also be initiated with MML commands, with those, for example, that are used for changing the area, or deleting the MS from the HLR.

1.2.5

Periodic location update

Periodic location updating is used to inform the network that the mobile station is available; the network requires the mobile station to 'report in' at certain time intervals. If there are no messages from the mobile station, the network assumes that the MS is out of the coverage area or that it has not been turned on, and incoming calls to the MS are not paged. This saves radio resources. The time interval for periodic location updating is defined in the base station parameters. The time-out value is continuously broadcast, so when a mobile station enters the VLR area, it automatically knows how often it has to report to the network. When the timer of the MS reaches the timeout value, the MS initiates a periodic location update. Every time location updating occurs, the MS and the VLR reset their timers.

20 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

In a periodic location update, the VLR area does not change, and location updating 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 VLR removes the IMSI detach flag and resumes normal call handling for the MS. The IMSI attach information is stored in the VLR, and the HLR does not need to be updated. However, the update from the HLR is done in certain error conditions, such as after a VLR restart, or a VLR cleaning. The use of the IMSI attach operation is defined in the base station parameters.

1.3

Not-reachable MS
The following location management procedures can result in the fact that an 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 the PLMN that it has become inactive (for example, the MS has powered down). On the basis of this information, calls coming to the MS can be rejected without sending a paging message on the radio path. The IMSI detach information is stored in the VLR. The use of the IMSI detach operation is defined in the base station parameters.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

21 (53)

Location Registration

Implicit IMSI detach An implicit IMSI detach operation is an action taken by the VLR when the MS has been inactive for too long a time. The time limit is defined in the VLR parameters. The procedure is initiated by an MT event: when a call or a short message comes in, the VLR compares the last active date and the time 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 also be activated by the operator. If the IMSI is in 'detach' state (because of the IMSI detach or implicit IMSI detach procedure), the incoming call establishment is interrupted; this way an unnecessary circuit establishment from the gateway to the MSC/VLR and paging are avoided. A detach flag is set after the IMSI detach has been completed, but the subscriber data is not deleted from the VLR. The implicit IMSI detach is an optional feature in the network. The use of the feature is defined in the USE OF IMPLICIT IMSI DETACH parameter (VLR). The time limit is defined in the IMPLICIT IMSI DETACH TIME LIMIT parameter (VLR). The time must be longer than the periodic location updating time (defined in the BSC), but shorter than the loitering time. Purge MS A 'purge MS' is a request by which the VLR orders the HLR to delete the mobile station's VLR address, so that any request for routing information for 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 is also initiated if the MS has been inactive for too long (a VLR cleaning is performed). The cleaning parameters in the VLR are VLR CLEANING START TIME and TIME SUBSC. MAY LOITER BEFORE BEING DELETED FROM VLR.

1.4

Location registration-related data in the VLR

Subscriber parameters For every subscriber registered in the VLR, the VLR subscriber database contains the following data needed for location registration functions:
.

cell global identity/service area identity mobility management location area identity

22 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

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 an MS within the PLMN. The mobility management location is the LAI where the MS made the latest location update. In GSM, the CGI and MM LAI contain the same LAI, however, in UMTS, the SAI can refer to a LAI other than the MM LAI. This can happen when the user moves during an active PS session. The serving RNC remains the same during the PS session even if the MS moves to another location or VLR area. If the MS initiates a CS call in the meantime, the SAI (real location) can be different from the MM LAI (the one under the serving RNC). The VLR uses the MM LAI in the paging procedure, while it needs the SAI for 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 a valid LAI. The MSC decides whether the MM LAI can be sent to the VLR. This is always true during location registration procedures and in GSM radio access, in general. In UMTS, the MSC sends the MM LAI to the VLR only 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

DN987572 Issue 10-0 en

# Nokia Siemens Networks

23 (53)

Location Registration

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 management location area is unknown (after a VLR reset, for example), the VLR application starts a search procedure. When the search has been successfully 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 'IMSI detached' state, the VLR application rejects the call. The last active date (time stamp) is updated after every procedure which indicates that the mobile station is in an active state (for example, location updating, a call, or a supplementary service operation). The HLR address is fetched from the HLR during the location updating procedure. The address is used in subsequent procedures towards the HLR. The SGSN index is not zero if the MS is GPRS-attached. In this case, the SGSN notifies the VLR about the location area changes, and the VLR initiates 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 the location automatically when the mobile station is active (for example, location updating, a call, or a supplementary service operation), or when it responds to the search procedure during an incoming call set-up. The operator can handle the subscriber data in the VLR with the commands of the Visiting Subscriber Identification Handling (MV) command group.

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

24 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

a request from a new mobile subscriber for location updating a request for authentication triplets/quintets for a new mobile subscriber a 'restore data' request if subscriber data is lost in the VLR and there is 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, which means that roaming is not allowed. The IMSI analysis enables the VLR to find an address for contacting the subscriber's HLR. After the first contact, the HLR sends a more specific HLR address, and this is stored in the VLR subscriber database. VLR parameters VLR parameters are used to control certain functions in the VLR. The operator can change and output the values of the parameters. The parameters are handled with the commands of the VLR and PLMN Parameter Handling (MX) command group. The parameters are divided into PLMN-specific and VLR-specific parameters. The PLMN-specific parameters control those VLR functions which depend on the subscriber's HPLMN. The VLR-specific parameters are independent of the subscriber's HPLMN. For more information on the VLR- and PLMN-specific parameters, see Parameter 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 to the radio path integrity protection (UMTS only)

DN987572 Issue 10-0 en

# Nokia Siemens Networks

25 (53)

Location Registration

mutual authentication, which prevents unauthorised access to the network; UMTS subscribers can also authorise the network (a UMTS subscriber is a subscriber having a UMTS SIM card) IMEI checking, which is made to guarantee that the equipment is used only by its rightful owner. Another purpose of the IMEI checking is to guarantee that only the type-approved mobile equipments can use the network.

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

1.5

Location registration-related data in the HLR

Subscriber parameters The HLR database provides three information elements for location registration functions:
.

the addresses of the MSC and the VLR in the area where the MS is currently located information about the service area of the MS information about how wide area the MS is allowed to roam in in the network

The addresses are received in the location updating request. The service area is given to the subscriber when it is created in the HLR database, but the operator can change it with MML commands. If none of the subscriber basic services can be used in the VPLMN, the location registration is denied by the HLR. Subscriber data in the HLR can be handled with the MML commands of the Home Subscriber Identification Handling (MI) command group. HLR parameters HLR parameters are used to control certain functional properties in the HLR. They are handled with the MML commands of the HLR and PLMN Parameter Handling (MJ) command group.

26 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

The parameters can be divided into HLR-specific and PLMN-specific parameters. The PLMN-specific parameters control those HLR functions which depend on the PLMN (in some cases also on the VLR) in which the subscriber is roaming. The HLR-specific parameters are general parameters of the HLR: they are independent, for example, of the PLMN. This section describes the use of the HLR parameters in location updating procedures. The point of view is functional: the parameters are described as means of controlling certain functions. The names of the parameters are written in capital letters; the abbreviation 'PLMN' appearing in brackets after the parameter name means that the parameter is PLMN-specific, the abbreviation '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 created automatically 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 gets VPLMN 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 the PLMN-specific parameters in the file. The parameter can be as specific as necessary to enable the managing of the country PLMN parameters and even VLR-specific parameters. If a VLR of an older release does not support certain functions in an HLR upgrading, a VLR-specific parameter can be used to screen the sending of data to the VLR associated with the new function. Mobility management in location registration

Update location
When the HLR receives an 'update location' message from the current VLR of the subscriber, the HLR checks whether the subscriber has a service defined in the ROAMING NOT ALLOWED FOR SUBSCRIBER WITH CERTAIN SERVICES (PLMN) parameter. If the subscriber has this kind of

DN987572 Issue 10-0 en

# Nokia Siemens Networks

27 (53)

Location Registration

a service, the HLR prevents access to the network by sending a negative acknowledgement and the error code 'roaming not allowed'. When the mobile station receives the error code, it does not try to gain access to the network again. Note that even if the parameter was VLR-specific, the access to the whole PLMN is denied because of the error code. The subscriber's VLR and MSC addresses are defined as 'unknown' in the HLR. If the 'update location' operation succeeds and there are short messages waiting for the MS in the SMSC, the HLR alerts the SMSCs, informing them that the MS is reachable. Because the MS may need time to get into a state in which it can receive short messages, the operator can delay the sending of the alert message with the DELAY OF SENDING ALERTS parameter. The networks from which a subscriber is allowed to make location updates can be specified when creating subscriber data in the HLR. The networks are specified in the SERVICE AREA OF PRIMARY MSISDN parameter in the MIC command. The area can be one of the following: ALL OWN NAT INT the whole GSM network the own national network all national networks the own national network and all international networks

Insert subscriber data

The MAP level and version needed in the 'insert subscriber data' operation are defined in the MAP LEVEL (PLMN) and MAP VERSION (PLMN) parameters. Those supplementary services which must not be transferred to the VLR are screened out from the 'insert subscriber data' message in the NOT ALLOWED SUPPLEMENTARY SERVICE (PLMN) parameter. The service 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 the NOT ALLOWED BASIC SERVICE (PLMN) parameter as forbidden are not sent to the VLR in the 'insert subscriber data' operation. If all basic services of a subscriber belong to forbidden services, 'update location' is negatively acknowledged, and the 'roaming not allowed' error code is generated. Also, 'cancel location' is sent to the old VLR, and the VLR address is defined as 'unknown' in the HLR.

28 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location Registration

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

1.6

Location registration-related mobility measurements and charging

The user can handle location registration-related mobility measurements with 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 area between HPLMNs location updates of the home subscribers from one VLR area to another within one PLMN location updates of the roaming subscribers within the VLR area location updates of the roaming subscribers within the VLR area between HPLMNs location updates of the roaming subscribers from one VLR area to another 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 telemetric subscribers.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

29 (53)

Location Registration

Charging records of location updates can be created in the VLR. A charging record can also be created during a location update, for example, when the MSC or CGI/SAI changes. The amount of charging data decreases when unnecessary toll tickets (such as those caused by periodic 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 back to the HPLMN the total number of location updates of home subscribers registered subscribers in each VLR GPRS location registration registered subscribers per SGSN

30 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

2
2.1

Location registration-related features

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

National roaming
National roaming is a service which enables a mobile station of a given PLMN to obtain services from another PLMN in the same country on a location area basis, with automatic return to the HPLMN when this is possible. The main functional property of national roaming in the network subsystem is that it can prevent location updates in certain areas (groups of location areas) of subscribers from other networks, while allowing it in other parts of the network. National roaming allows the operator to differentiate in a certain national network between areas where roaming from neighbouring networks is allowed and where it is denied. The basic assumption is that when a subscriber roams from the same country but from another network, the normal condition is not allowed. This means that if this feature is used, the default setting concerning a case that restricts roaming; the cause is 'national roaming restricted'. If the subscriber of another network is explicitly allowed to roam in a particular location area, location updating is accepted. This feature is based on LA information, 'national roaming allowed', which defines whether subscribers from other national networks are allowed to roam into a particular location area. Operators in the same country can define areas where roaming between their networks is allowed, and others where it is restricted.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

31 (53)

Location Registration

For more information on national roaming, see Feature 124: National Roaming, Feature description. It cannot be guaranteed that this feature functions in GSM Phase 1 mobile stations.

2.1.1

Location updating
National roaming conditions are checked at location updating. If the mobile station's PLMN information has been defined as 'home country and visitor PLMN', a national roaming check is made. For this purpose, location areas have information of MNC and of the national networks from which roaming is allowed. If the MNC defined for a particular location area does not correspond to the MNC in the IMSI, location updating is rejected because of the national roaming restriction. If the MNC has been defined for the location area in question, location updating is accepted. The national roaming restriction indication to the mobile station depends on what GSM specification the MS supports. The GSM Phase 1 specification does not include national roaming definitions. The specification phase of a mobile station is indicated in the revision level field of the MS classmark. The national roaming restriction is signalled to phase 1 mobile stations in a 'location area not allowed' error code; for phase 2 mobile stations the error code is 'Roaming not allowed in this location area'. If the location updating is rejected and the error code is 'Roaming not allowed', the MS starts the initial access procedure.

Note
Because the error code 'location area not allowed' is not intended to be used in this context, some of the mobile stations supporting the phase 1 specification may behave in an unpredictable way. Therefore, checking the function of phase 1 mobile stations in this respect is recommended before the feature is activated.

32 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

The handling of user information in the network depends on what the update status of the subscriber in the VLR was at the moment when the location updating of the MS was rejected. Mobile subscriber known to the VLR In this case, national roaming was allowed at the time when the previous location updating occurred. Later, when location updating is attempted again, roaming is not allowed any more, and the national roaming restriction is effective. In this case, the user status in the VLR is defined so that 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 ensuring the integrity of data in the location registers after the reset of the whole network element. Restoration procedures are defined for the HLR and the VLR. For more information on GSM restoration, see Feature 226: GSM Restoration, Feature Description. VLR reset When the VLR is restarted, all data in the subscriber database of the VLR is lost. After the VLR is restarted, it functions normally: the same way in which it functions when the subscriber is not identified in the VLR. In case of location update or IMSI attach, the data is received from the HLR in the normal location registration procedure. When the 'provide roaming number' request concerns an unidentified subscriber, the VLR no longer sends the 'send parameters' request like in MAP Phase 1. This is replaced with a 'restore data' operation. The operation is very similar to a location update operation.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

33 (53)

Location Registration

GMSC

VMSC

HLR

MS

1. Send_Routing_Information 2. Provide_Roaming_Number 3. Restore_Data

Subscriber Data Transfer 4. Restore_Data_Ack 5. Provide_Roaming_Number_Ack (MSRN) 6. Send_Routing_Info_Ack (MSRN) 7. IAM 8. Page MS

Normal Call Completion

Figure 8.

VLR restoration in GSM Phase 2

If the subscriber tries to originate a call or makes a supplementary service control request, the VLR performs an implicit location update, that is, the VLR notifies the HLR and downloads the subscriber's data if the IMPLICIT_LOC_UP system configuration parameter is active. Then the original operation continues normally. If the implicit location update feature is not active, the VLR returns the 'unidentified subscriber' error code. This makes the MS initiate the location registration request. The HLR handles the 'send parameters' and the 'update location' requests normally. The network starts the restoration procedures automatically after the reset of the VLR. HLR reset After the reset of the HLR, the HLR reloads all data from the back-up, and informs all VLRs involved by sending them a 'reset' message.

34 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

To prevent the loss of supplementary service information at the restart, an 'SS check required' indication is set in the HLR. Information about the possible loss of data is transferred to the VLR in reply to the location registration 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 reset indicator concerning all the subscribers of that particular HLR. The indicator is checked every time a subscriber originates a call or makes a supplementary service control operation. The location registration is initiated if the reset occurred after the previous location registration of the subscriber. The network starts the restoration procedures automatically after the reset of the HLR. Restrictions The GSM specification introduces parameters called restoration indicators, which indicate whether the consistency of subscriber data has been confirmed. The indication of the confirmation is not implemented as special parameters in the subscriber data, but in a more efficient way by using reset counters. The functional properties are the same. The consistency of data between the HLR and the VLR cannot be guaranteed in all cases if administrative commands are given during the restoration procedure.

2.3

Subscription-based network access

Subscription-based network access is a feature which enables the operator to prevent or allow roaming in certain VLR areas. The feature is based on roaming profiles defined by the operator. The maximum number of different profiles is 99. Each subscriber can be associated with one profile. When the subscriber tries to register in a VLR for the first time, the subscribers's roaming profile - if the subscriber has one - is checked from the HLR. If the VLR has been defined as 'not allowed' in the subscriber's roaming profile, the registration is rejected, and the subscriber cannot roam in that particular VLR area.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

35 (53)

Location Registration

This feature also applies to the GPRS network, that is, the VLR in this context can be considered as a 'VLR' in the SGSN, the VLR address being the SGSN address. For more information on subscription-based network access, see Feature 541: Subscription-Based Network Access, Feature description and Feature 857: Support of General Packet Radio Service, Feature description. Properties

HLR Location Update Request IMSI VLR Address

Subscriber Data

VLR Address Analysis

RP Index

PLMN Index

Roaming Profile Analysis PLMN 0 RP 1 allowed PLMN 1 not allowed allowed

...

...1499

RP 2 not allowed

...

99

Negative Response

Not Allowed

...

Allowed

Continue Normally

Figure 9.

Overview of the feature

36 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

When an MS roams in a new VLR area, the new VLR initiates a location update towards the HLR. If the network operator has given a roaming profile index to the subscriber, a roaming profile analysis is performed in the HLR. The service area of the subscriber is analysed before the roaming profile. If the parameter prevents roaming, the roaming profile is not analysed. The VLR address, received in the location update request, is analysed to get a PLMN index. The roaming profile analysis can be made when both the roaming profile index and the PLMN index are known. If the result of the analysis is 'not allowed', the location update is refused. The operator can decide what error code is generated at the refusal: it can be either 'roaming not allowed' (this is the default) or 'unknown subscriber.' If the result of the roaming profile analysis is 'allowed,' the location update continues in the normal way. The roaming profile analysis is based on a roaming profile table, which consists of 99 different roaming profiles. A profile is based on PLMN indexes. They are allocated to all branches in a VLR address analysis. In every roaming profile, each PLMN index has a status, which is either 'allowed' or 'not allowed.' The roaming profile analysis is very flexible because there is no check between it and the VLR address analysis. The operator can define a status for indexes which have not yet been allocated to a VLR address analysis branch. For example, if the operator wants the roaming profile to allow roaming in the VLR(s) of just one particular VLR address analysis branch, all PLMN indexes in the roaming profile except for one are defined as 'not allowed'. When new branches are created (new indexes are taken into use), they automatically obtain the same status. When creating a new branch to a VLR address analysis, however, the settings for that PLMN index in all roaming profiles must always be checked, and updated if necessary. When the operator defines a roaming profile index for a subscriber, the cancel location procedure towards the present VLR is initiated. Changes in the roaming profile table do not initiate the cancel location procedure. The operator can deactivate the feature with an MML. After the deactivation, no roaming profile analysis is made even if there are associations with the roaming profile in the subscriber data; all VLRs are considered 'allowed'. If the checking of the roaming profile status fails, roaming is allowed.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

37 (53)

Location Registration

Note
When the subscriber roams in another VLR area during a call, the new location is not updated in the HLR until the subscriber has finished the call. This means that the subscriber may be using the network resources of a VLR area in which that particular subscriber is not allowed to roam.

Capacity The roaming profile analysis affects the performance of the location update procedure to some extent. It also causes some additional system load 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 GSM Measurement Handling (TP). When the Support of the GPRS feature is available in the HLR, the subscription-based network access is applicable also to the GPRS network. The PLMN index of the GPRS subscriber is determined on the basis 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 this feature, the IN concepts and architecture are applied to the MM transactions, that is, location registration procedures. An MM state model provides the operator with TDPs, at which the control of the location registration procedure can be moved to an external SCP in the IN. The SCP can then decide, for example, on the basis of the location of 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 location update or IMSI attach. This cuts down the amount of visits to the SCP, thus enabling the SCP to serve more customers.

38 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

Charging data can be collected from location updating procedures. Initiated by location registration, the SCP can send charging information to the SSP, which will forward it to the billing center. This enables, for example, location-dependent charging. Gapping is a new service which gives better control over the SCP load. If the SCP is heavily loaded, it can ask the SSP to limit the number of contact attempts for a certain service. Statistical information about location updates rejected by the SCP are added to the trace report. For more information on IN MM, see Feature 742: IN Mobility Management, Feature Description. CAMEL (Customised Applications for Mobile network Enhanced Logic) is an IN architecture within GSM. CAMEL provides mechanisms to support services independently of the serving network. With CAMEL, it is possible to offer Operator-Specific Services (OSS), that is, intelligent network services, for the subscriber while he is roaming outside the home PLMN. Subscribers can use the operator-specific services they are accustomed to also when roaming in other networks. In CAMEL Phase 3, a notification is sent to the CSE when the VPLMN has completed the processing of any of the following mobility management events:
.

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: CAMEL Phase 3 Call Unrelated Parts, Feature Description. Functionality of the feature IN MM services can be offered to different subscriber types as follows:

DN987572 Issue 10-0 en

# Nokia Siemens Networks

39 (53)

Location Registration

Subscriber-specific services to the home subscribers. The services are provisioned in the subscriber data. Network-specific services to all roaming subscribers on a PLMN basis. The services are provisioned in the PLMN-specific file in the VLR. Offering the network services to the home subscribers must be avoided if there is a risk of overloading the network elements.

The IN MM architecture consists of the HLR, the VLR, and the SCP. The SCP includes an MM-SCF and a service logic program for the MM services. An MM-SSF carries out the handling of detection points in the network elements. 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, the protocol is MAP version 2, extended with the IN mobility management subscriber data.

SCP MM-SCF

INAP

INAP

MSC

SSP VLR MM-SSF

HLR

SSP MM-SSF

MAP

Figure 10.

IN mobility management architecture

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

40 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

The load increase within one transaction might be considerable if triggering takes place. Therefore, it is assumed that these services are intended only for special subscribers, not for all subscribers. There is a specific timer parameter (SCP_AVAILABILITY_TIMER) in the VLR and in the HLR which determines the maximum waiting time of the first response from the SCP. The value of this parameter can be adjusted by the operator, but the default is that the waiting time is as short as possible to avoid overload in case the MM-SCF does not respond. The use of transaction types in the intra-VLR LocUp DP, cuts down the amount 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 with the subscriber. This functionality, however, is independent of the location registration and it may be carried out as a separate transaction in the Ainterface. The MM-SCF may use standard MAP signalling to interrogate or change the subscriber data in the HLR.

Regional Roaming (Zone Codes)

The Regional Roaming (Zone Codes) feature is needed if a location-based triggering condition is used. The operator may define on a zone basis whether triggering is allowed within the zone. If the subscriber is allowed to roam within the zone, and triggering is allowed within the zone, and the DP is met, the InitialDP is sent to the SCP. Otherwise, the location registration continues normally according to the zone code table. Operational view In unsuccessful location registration attempts, a specific 'ReleaseCall cause' is added to the trace report both in the HLR and in the VMSC to indicate that the SCP rejected the location registration. Statistical information is also collected of gapped SCP visits.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

41 (53)

Location Registration

Restriction Because of a risk of overload, the PLMN-specific LocUp detection point should not be set for home-PLMN subscribers. Also, because of the possible risk of overload, the intra-VLR LocUp detection point should not be encountered in the periodic location registration transactions. No IN CDR is produced of periodic location registration. To avoid congestion in the IN-network, this feature should not be provided for all subscribers. The FCI operation can be used only towards the SSP/MSC/VLR. It cannot be used within the location registration TDP in the HLR, for example.

2.5

Regional roaming
Regional roaming (zone code) allows the network operator to control subscriber roaming. This means that the operator can define the location areas where an individual subscriber can have the service. The meaning of zones is defined in the VLR by the operator. These zones are shown as zone codes for the subscriber's database in the HLR. The operator defines the location areas belonging to the zones where roaming is allowed or not, and the location areas where IN MM triggering is allowed or not during the location update. If the subscriber does not have any zone codes in the HLR or those zone codes are not accepted (for example, the use of regional roaming is denied for roaming subscribers), the operator can 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 HLR are not accepted, the VLR checks the default zone codes before fetching any authentication vectors from the AuC or starting the location update towards the HLR. If the default zones restrict roaming, the VLR saves the signalling towards the AuC and HLR. The roaming area can be a single location area, several location areas, or the whole PLMN. Also, the roaming area can be scattered: for example, the subscriber may have a roaming area that consists of 10 roaming areas around the 10 largest cities, while his roaming in scarcely populated areas is forbidden.

42 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

A subscriber who has only a limited access to the PLMN receives an error message when he tries to roam to a location area which is not provided for him. For more information on regional roaming, see Feature 805: Regional Roaming, Feature Description. Function in the HLR The operator can define up to ten zone codes for the subscriber. These zone 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 are given by the operator. The subscriber's zone codes are transferred to the VLR in the same order. The sending of zone codes can be defined as a not allowed service in the PLMN parameters. This means that the operator can 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 location update is acknowledged to the HLR with the information that the MSC area is restricted. In this case, the HLR sets the msc_area_restricted flag to restricted 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, that is, 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 MM triggering during the location update. The operator can define what kind of cause value is sent to the MS when the location update is denied by regional roaming. If there is at least one zone that allows roaming, roaming is allowed. If none of the subscriber's zones apply to the MSC/VLR area, roaming is denied. If there is at least one zone that denies the IN MM triggering, the IN MM triggering is not done during the location update. The checking of the IN 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 is denied. If the subscriber does not get any zones from the HLR, the zone codes are read from the PLMN parameters. This is very useful for roaming subscribers and solutions where most of the subscribers do not need any zone codes.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

43 (53)

Location Registration

If there are zone codes neither in the subscriber's database nor in the PLMN parameters, roaming is allowed to all location areas and the IN MM triggering is done as defined in the PLMN parameters when the location update occurs. The operator can view the location areas of a particular zone, the interpretation of the zone (allowing or denying zone), and the zones that are assigned to the subscriber.

Note
The same zone can have a different interpretation in different MSC/VLR areas. This can be used if the operator wants to grant the subscriber a roaming area which extends to several MSC/VLR areas. He can then define the same zone in both MSC/VLRs so that it includes the needed location areas in the corresponding MSC/VLR. The operator can also assign several zones, each of which is defined only in one MSC/VLR. Thus the total roaming area is the areas granted by individual zones together.

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

Table 1.

Zone codes in MSC/VLR Location area 2 ... Location area n

Location area 1
Zone Code 1 Roaming allowed IN trigg. denied Zone Code 21 included= Y ... Zone Code 8867 included= Y included= Y

included= Y

included= N

included= Y

included= N

included= N

included= N

Location update in the MSC/VLR When the subscriber tries to do a location update for the first time in the MSC/VLR area, his zone codes are fetched from the HLR and stored among other subscriber information in the VLR. The location area is then checked against the subscriber's zone codes.

44 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

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

IN MM triggering during the location update is not done if the location is not allowed to the current location area. If the location update is not allowed by the zone codes or IN MM triggering during the location update is denied, the IN MM triggering is 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 fetched from 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 subscriber information is not deleted from the MSC/VLR but mobile-originated and mobile-terminated traffic (for example, call and SM) are prevented. The 'IMSI detach' mode is removed when the subscriber makes a successful location update. If not all the zone codes of the subscriber are known by the VLR, the location update is acknowledged to the HLR with the cause msc_area_restricted and the VLR sets an 'IMSI detach' mode for that subscriber, that is, the subscriber information is not deleted from the MSC/ VLR but mobile-originated and mobile-terminated traffic (for example, call and SM) are prevented. In the HLR, the msc_area_restricted flag is set to restricted and all MT traffic is denied to the subscriber. If the IMSI Detached flag is set because the called subscriber is not allowed to roam into the current location area, the 'Absent Subscriber' error message is returned to the HLR if there is an attempt to transfer MT traffic to the subscriber. Capacity This feature is applicable to all subscribers, even simultaneously. However, the great number of regional subscribers affects the number of unsuccessful location update requests and thus increases the load in the network. The memory consumption in the HOSTEL database is 22 b/subscriber/pair of HLR unit. The memory consumption in the VISION database is 21 b/ subscriber/pair of VLR unit.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

45 (53)

Location Registration

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

Feature 526: Charging Based on Home Area facilitates the regionality and controls the charging. However, it is the operator's responsibility to design the roaming and charging areas effectively. With the SAM parameter the operator can restrict roaming outside the HPLMN. If roaming is allowed (according to the SAM), the default is that a subscriber without any zones provided has a full access to the network. For more information, see Feature 526: Charging Based on Home Area, Feature Description.
This feature is needed in Feature 742: IN Mobility Management, phase 2, if the triggering condition for location is used. The functionality uses the zone code table, where the operator may define whether the triggering is allowed 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. The maximum number of zones per subscriber is 10 in the HLR database because only the zone code part of the RSZI is stored in the HLR database. Regional roaming does not prevent a handover to a forbidden location area. The subscriber can have service during a handover, even if he moves to a forbidden location area. For example, if the subscriber makes a call and moves to a forbidden area and a handover occurs, the call continues normally. After the call, the mobile station performs a location update request which is subsequently denied. After a stand-alone insert or restore data operation, GSM restoration, and deleting the zone codes in the HLR, it is not possible to get the MS out of service before the next location update.

2.6

Network identity and time zone

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

46 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

This enhances international/national roaming by permitting an accurate indication of network names that are either newer than the mobile station or have changed their name since the mobile station was sold or its software updated. Also, an MS supporting NITZ can set its clock automatically to local time and take daylight-saving times into account. Furthermore, the realisation of the MS can be simplified because there is no more need to keep the clock running when the mobile station is in the power-off state. For more information on NITZ, see Feature 1005: Network Identity and Time Zone Support, Feature Description. Properties This feature makes it possible for a serving PLMN to transfer its current identity, universal time, daylight-saving time, and local time zone to the MSs, 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 zone information can be transferred from the serving PLMN to the MS in the following 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 the VLR unit. Restrictions The 7-bit SMS coding scheme is used instead of UCS2 and 8-bit SMS coding.

2.7

Inter-system handover and UMTS changes in the MSC

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

DN987572 Issue 10-0 en

# Nokia Siemens Networks

47 (53)

Location Registration

The feature provides support for handovers from GSM to UMTS, and vice versa, and for intra-UMTS inter-MSC relocation. Also, the necessary changes in the MSC for the support of UMTS are implemented in this feature. For more information, see Feature 1260: Inter-system Handover and UMTS Changes in MSC, Feature Description. Equivalent PLMN In PLMN-specific parameters, the operator can specify a set of PLMN identities which are sent to the mobile equipment in location updating. The mobile equipment stores this list of 'equivalent PLMNs'. The stored list consists of a list of equivalent PLMNs as downloaded by the network and the PLMN code of the network that downloaded the list. All PLMNs in the stored list are regarded as equivalent to each other for PLMN selection and cell selection/re-selection. This functionality provides clear benefits for the operators who have a different PLMN code in their UMTS and GSM radio access networks, and/or have a shared network with another operator, and/or operate networks also in other countries. Additionally, the operator may use this feature to make the users registered in their network to prefer their partners' networks when the coverage of their own network is not available. Equivalent PLMN Functionality is a useful tool for enabling seamless cell re-selection among cells belonging to different PLMNs. This includes network sharing cases, as well. In other words, the operators own core network can send the shared networks PLMN code as an equivalent PLMN to its subscribers, which makes cell selection seamless when the operators own subscriber moves between the shared and the operators own coverage areas. The Equivalent PLMN Functionality can also be used to keep international inbound roamers in the shared network when they move outside of the operators own network coverage area. Otherwise, an international inbound roamer may select other operators' 3G PLMN. The Equivalent PLMN Functionality has no impact on handovers because the UE does not select a new target cell for handovers but it is done by the SRNC using neighbour lists. Access control Access parameters are implemented in the VLR. With these parameters the operator can control the subscribers' access to the network by giving access rights for a UMTS/GSM type subscriber to the UMTS/GSM radio network. This can be done on a PLMN or IMSI range basis. The subscriber

48 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

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 this information and access right parameters, the VLR can accept or reject the MM connection establishment or location updating procedure accordingly. If the subscriber type is unknown and the currently used access network is restricted for both user types, the VLR rejects the location update without retrieving authentication vectors from the AuC. Cause codes, used if the VLR rejects the MM connection establishment or location updating, can be set by the operator for each access right parameter separately. If a separate cause code is not defined, the default values are used. The VLR sends the access right parameters also to the MSC. The MSC uses these parameters to allow or reject the inter-system handovers for the served subscriber. The operator can use the commands of the VLR and PLMN Parameter Handling command group (MX) to display and modify VLR-specific and PLMN-specific parameters. For each PLMN, the operator can define the following 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 the help of this feature, and with other UMTS features.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

49 (53)

Location Registration

Inter MSC Inter PLMN

InterSystem RNC < > BSC R99 IntraSystem RNC < > RNC InterSystem RNC -> BSC R98 BSC R98/R99 < > BSC R98/99 BSC R98 -> UMTS

Intra MSC Inter PLMN Intra PLMN

Intra PLMN

supported

not possible

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 able to make Intra-UMTS/Inter-system handovers, the following requirements are 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 per Multimedia gateway Signalling requirements for the Gs interface Charging and Statistics support Access and handover control

50 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

2.8

Support of interaction with SGSN in MSC/VLR

The support of this feature is realised by supporting a standard Gs interface in the MSC/VLR. If the Gs interface is supported by the SGSN and the MSC/VLR and thus a subscriber-specific association can be established between the CS and the GPRS network, the following benefits are gained when a class A or B GPRS MS is used (class C MSs cannot be simultaneously IMSI- and GPRS-attached):
.

It is possible to make combined LA/RA updates in a PLMN that supports both the CS and the GPRS functionality, and thus save radio resources. Since the RA is a subset of only one LA, the changing of the LA of the GPRS MS also changes the RA. A combined LA/RA update request first goes to the SGSN, where the RA of the IMSI is updated. The SGSN delivers the LA update request further to the MSC/VLR via the Gs interface. It is possible to make a combined IMSI/GPRS attach or combined IMSI/ GPRS detach, and thus save radio resources. The combined request first goes to the SGSN that delivers the IMSI attach or detach request to the MSC/ VLR via the Gs interface. It is possible to make a circuit-switched (CS) paging request via the SGSN (paging co-ordination). This is an important feature, especially for those class B MSs that are capable of monitoring only one paging channel at a time (for example, in network operation mode III, they revert to the class C mode of operation). An additional benefit is that the paging request is performed in a smaller area if it goes via the SGSN. Although the CS paging request goes via the SGSN, the paging response comes to the MSC on its ordinary route, via the A interface, and the CS connection establishment continues in the usual manner. The MT SMS and MT USSD paging also go via the SGSN. The paging procedure is supervised in the MSC by a paging timer. The SGSN may also send the unreachable MS a message before the paging timer expires. It is possible in those cases when the SGSN knows that the subscriber is absent. The MSC can repeat the paging via the A interface if it fails via SGSN (for example, SGSN is not available, MS is in GPRS-detached state, IMSI is unknown in SGSN, or there is an address error).

DN987572 Issue 10-0 en

# Nokia Siemens Networks

51 (53)

Location Registration

The Gs interface also suppresses the periodic location updates of the GPRS-attached MSs in the VLR because the VLR relies on the periodic routing area updates in the SGSN. The VLR does not perform security checkings (authentication and IMEI checking) when the location update request comes through the GS interface because it relies on the security procedures of SGSN. The IMEI (with software version) that the SGSN sends is accepted and stored to the VLR database optionally. If the VLR does not receive the IMEI, the VLR can ask it from the SGSN at the end of the location update with the MS Information Request procedure. For more information, see 3GPP Technical Specification 29.018, General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification.

This feature is not supported at the system level in 3G, however, it is supported in the 2G system and 3G circuit switched core network. For more information, see Feature 881: Support of Interaction with SGSN in MSC/VLR, Feature Description.

2.9

Location update in pool area concept

Features Multipoint A Interface and Multipoint Iu Interface in MSC server concept introduce a concept where BSC or RNC can be connected to several MSC/MSSs. The area that is served by one or more MSC/MSS in parallel forms a pool area. Within a pool area the MS can roam without changing the serving CN node. The NRI identifies an individual MSS serving within one pool area. The NRI is part of the temporary identity TMSI, which the serving MSS assigns to 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, Feature Description and Feature 1449: Multipoint Iu Interface in MSC server concept, Feature Description. Location update An MS performs location area updates, in which the serving MSS may change. In these procedures, the new MSS requests MS-specific parameters from the old MSS.

52 (53)

# Nokia Siemens Networks

DN987572 Issue 10-0 en

Location registration-related features

The new MSS uses the old LA together with the NRI to derive the signalling address of the old MSS from its own configuration data. If the network contains nodes that cannot derive the old MSS from the LAI and the 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 the NRIs has not been configured) do not have the information of multiple MSSs serving an LA. These nodes can therefore contact only one MSS per LA. This one node is referred to as the default node. A default node that supports this feature derives the NRI from the TMSI. The default node forwards the request to the correct MSS in the old pool area. The correct MSS responds by sending the MS-specific parameters directly to the new MSS. 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 defined per LA.

DN987572 Issue 10-0 en

# Nokia Siemens Networks

53 (53)