Parameter Management in EIR, HLR, And VLR

8/18/2019 Parameter Management in EIR, HLR, And VLR

1/33

Open Mobile Softswitch, Rel.

M16.1, Product

Documentation, version 3

Parameter Management in EIR, HLR, and

VLR

DN985071

Issue 8-0-0

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of

its products and services. We would like to encourage you as our customers and users to join

us in working towards a cleaner, safer environment. Please recycle product packaging and

follow the recommendations for power use and proper disposal of our products and their compo-

nents.

If you should have questions regarding our Environmental Policy or any of the environmental

services we offer, please contact us at Nokia Siemens Networks for any additional information.


2/33

2 DN985071

Issue 8-0-0

Parameter Management in EIR, HLR, and VLR

Id:0900d805808d3ca9

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

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, 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 respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013/4/20. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources

of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle

this product and only after having carefully read the safety information applicable to this

product.

The safety information is provided in the Safety Information section in the “Legal, Safety

and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder

andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch

geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,

Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-

satzes.


3/33

DN985071

Issue 8-0-0

3


Id:0900d805808d3ca9

Table of ContentsThis document has 33 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 Parameter management in EIR, HLR, and VLR . . . . . . . . . . . . . . . . . . . 7

1.1 EIR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 HLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 VLR parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Recommendations for VLR parameter values. . . . . . . . . . . . . . . . . . . . 10

1.5 Recommendations for PLMN parameter values . . . . . . . . . . . . . . . . . . 17

2 Managing HLR and PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1 Adding a PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Modifying PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3 Creating not allowed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Deleting not allowed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 Modifying HLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Starting GSM restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Modifying subscriber categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Managing VLR and PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Modifying VLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Adding a PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Modifying PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4 Modifying the call transfer observation parameters. . . . . . . . . . . . . . . . 32

4.5 Setting and interrogating the fraud handling parameters. . . . . . . . . . . . 32

5 Managing VLRU-UTPFIL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 33


4/33

4 DN985071

Issue 8-0-0


Id:0900d805808d3ca9


5/33

DN985071

Issue 8-0-0

5

Parameter Management in EIR, HLR, and VLR Summary of changes

Id:0900d805808d42ef

Summary of changes

Changes made between issues 8-0-0 and 7-0-1

Section Recommendations for VLR parameter values has been updated. The followingVLR parameters have been added to the document:

SECURITY KEY LIFETIME 2G, SECURITY KEY LIFETIME 3G, FORCE AUTHENTI-

CATION WHEN SGSAP PAGE RESPONSE IS FROM DIFFERENT LA, AMR WB SUB-

SCRIPTION, PLMN SPECIFIC SS, MAX AGE OF LOCATION IN PREPAGE,

SEARCH_OPTIMIZATION, MME SEARCH FOR MME SUBSCRIBERS, PSI PAGING

OVER SGS INTERFACE, PSI PAGING ON LOCATION REQUEST, RDELAYSI, RDE-

LAYCLO

Section Recommendations for PLMN parameter values have been updated. The follow-

ing PLMN parameters have been added to the document:

NO RESPONSE EFFECT, CAMEL DATA NEGOTIATION TABLE, SUPPORT OF LOC-

ALISED SERVICE AREA, LONG FORWARDED-TO NUMBER SUPPORTED, ALLOW

ALWAYS HANDOVER TO 3G, ALLOW ALWAYS HANDOVER TO 2G, ANY TIME

INTERROGATION DELAY TIME, REJECT CAUSE FOR UDL REJECTION,

REDIRECT SUBSCRIBERS TO TEST MSS

The descriptions of the following PLMN parameters have been updated:

TMSI ALLOCATION, SUPPORT OF BOR, USAGE OF PLMN SPECIFIC SS 253, LA

BASED IN-MM TRIGGERING IN USE, INTELLIGENT NETWORK MOBILE ORIGI-

NATED SMS

Changes made between issues 7-0-1 and 7-0

Section VLR parameters has been updated.The following VLR parameters have been added to the document:

AUTH RETRY WITH NEW TRIPLET, ALLOW CCBS WHEN UDUB, NUMBER OF

SIMULTANEOUS CALL TRANSFERS, DEFAULT ACTION FOR CALL TRANSFER

INVOCATIONS, CDR ON LOCATION UPDATE, VLR TRAFFIC CONTROL PRIORI-

TIES, VLR LEVEL USSD BARRING LIST, IMSI ANALYSIS FAILURE REJECT CAUSE

CODE, SUPER-CHARGER PARAMETERS, VLR BACKUP PARAMETERS

The descriptions of the following VLR parameters have been updated:

EMERGENCY CALL, ALLOW LOCATION UPDATE WHILE SCP UNAVAILABLE, LOI-

TERING and VLR CLEANING START TIME, INTER VLR LU DETECTION

The following PLMN parameters have been added to the document:SUPPORTED CAMEL PHASE, PSI PAGING, FRAUD OBSERVATION AND LIMITA-

TION, REGIONAL ROAMING, ZONE CODES, EXACT MS CATEGORY USAGE,

TRIGGER SM TO NTMS, CS/PS COORDINATION REQUIRED, PRE-PAGING SUP-

PORTED, IGNORE CLIR FROM HLR, ACCESS RESTRICTION BY BS30, NBR OF

FETCHED VECTORS IF NONE AVAIL, EIR ADDRESS, EQUAL ACCESS, NITZ

PARAMETERS, PLMN SPECIFIC USSD BARRING LIST, TRACE ACTIVATION

PARAMETER, SUPER-CHARGER PARAMETERS, REPORTING INSTANCES

ALLOWED, PLMN SPECIFIC SUPPLEMENTARY SERVICE HANDLING

The descriptions of the following PLMN parameters have been updated:

MSRN GROUP, MSRN LIFETIME, BLACK LIST EFFECT, ADVICE OF CHARGE

PARAMETERS, IMEI STATUS CHECK FROM EIR IN CASE OF..., TMSI ALLOCA-


6/33

6 DN985071

Issue 8-0-0


Id:0900d805808d42ef

Summary of changes

TION, IMEI CHECKING, INTELLIGENT NETWORK MOBILITY MANAGEMENT,

INTER-PLMN HANDOVER AGREEMENT, EQUIVALENT PLMNS, LOCATION

REQUEST

Changes made between issues 7-0 and 6-0

The company and product names have been changed according to the official Nokia

Siemens Networks portfolio naming.

Changes made between issues 6–0 and 5–2

EIR parameters

More detailed information has been added on the 15th digit.

HLR parameters

The HLR functions can also depend on the PLMN (or even the GMSC) which sends a

routing inquiry to the HLR.

Modifying HLR parameters

You can delete or deactivate the subscribers from the HLR.

Recommendations for VLR parameter values

The printout of the MXO command has been updated due to the changes in the execution

printout of the command description.

Recommendations for PLMN parameter values

The printout of the MXP command has been updated due to the changes in the execution


Changes made between issues 5–2 and 5–1

VLR parameters

The VLR-specific parameters and the PLMN-specific parameters have been modified.

The UTPFIL parameter group has been introduced.

Instructions on managing VLRU-UTPFIL parameters have been added.

Recommendations for VLR parameter values

The printout of the MXO command has been updated due to the changes in the execution


Recommendations for PLMN parameter values

The printout of the MXP command has been updated due to the changes in the execution

printout of the command description.Changes made between issues 5–1 and 5–0

Managing VLR and PLMN parameters

The following parameters have been added to the MXM command due to Feature 1433:

Terminal Management Support:

• INTER PLMN LOCATION UPDATE (INPLU)

• NEW VISITOR AND PREVIOUS LAI IS ZERO (NVLAI)

• ROAMING STATUS (RSTAT)

• MOBILE STATION CLASSMARK (MCLASS)


7/33

DN985071

Issue 8-0-0

7

Parameter Management in EIR, HLR, and VLR Parameter management in EIR, HLR, and VLR

Id:0900d805808d42f1

1 Parameter management in EIR, HLR, and VLR

1.1 EIR parametersThe EIR-specific parameters define the dependency between the three EIR lists and

they interact with the VLR-specific parameters. One of the EIR parameters is used when

dealing with IMEI checking and the rest apply when new IMEIs are entered to the EIR

database.

The EIR is maintained in each network to check the mobile equipment identities used in

the network. The data, meaning the IMEIs, each of which represent one mobile station,

is stored in three lists: the black, grey, and white lists.

You can define the default color to be used when the equipment is unknown (IMEI is not

found on any list). In practice, it means the color that is returned to the VLR when the

checked IMEI cannot be found on any list. On the basis of the color that is returned to

the VLR, the VLR-specific parameters define the actions that follow.

You can define two kinds of dependencies between the EIR lists: the white list status

and the black and grey list correlation. The white list status defines the white list as

optional or obligatory. When the white list is set obligatory, the IMEI cannot be entered

to any other list if it is not on the white list first. You can set the correlation between black

and grey lists on or off. When the correlation is off, the IMEI can be entered on the black

or grey list even if it is already on the other list.

g The dependency is checked only when an IMEI is entered on a list. This means that afteryou have set the dependencies, the restrictions are valid when inserting new IMEIs. Not

all the existing IMEIs, which have been inserted into the EIR database earlier, necessar-

ily agree with the current list dependencies because they have been possibly insertedunder different restrictions.

In the Nokia Siemens Networks solution the IMEI consists of 14 digits. When referring

to the 'three last digits', for example, it means that you take the three last digits of the 14

digits of the IMEI. The last one, the 15th digit is always 0 as defined in the 3GPP TS

23.003.

You can also see the 15th digit used, for example in the labels of the mobile station, but

then it is a 'Check Digit'. The Check Digit is not a part of the IMEI number and it is not

transmitted over the air interface by the mobile station at IMEI check occasions. The

Check Digit is a means of verifying the actual (14-digit) IMEI number against possible

typing errors and it is relevant only when inserting new IMEI numbers to the EIR data-

base.

To display and change the EIR parameters use the MEP command.

For more information on security-related issues, see Security Management in AUC, EIR,

and VLR .

1.2 HLR parameters

The HLR parameters affect the function of the HLR as a whole and they affect all the

HLR subscribers.

There are two main types of parameters:

• fixed type parameters (MJ command group)


8/33

8 DN985071

Issue 8-0-0


Id:0900d805808d42f1

Parameter management in EIR, HLR, and VLR

• variable type parameters (UTP_H4MX file, DF command group)

Fixed type parameters

The fixed type parameters are divided into HLR-specific and PLMN-specific parameters.

The PLMN-specific parameters control HLR functions which depend on the PLMN (or

even on the VLR or SGSN) where the subscriber is roaming or which depend on the

PLMN (or even the GMSS) which sends a routing inquiry to the HLR. The parameters

also define if the HLR handles the PLMN as a home PLMN or not. The PLMN-specific

parameters mean how the HLR operates with other networks. With the PLMN-specific

parameters you can handle the following operations:

• transferring subscriber data when the updating of subscriber data fails

• defining denied services and roaming limitations (that is, not allowed basic services

including GPRS services, supplementary services, and roaming not allowed for sub-

scribers with certain services)

• defining the highest possible CAMEL phase supported towards the PLMN.

The HLR-specific parameters are general parameters of the HLR, that is, they do not

depend on, for example, the PLMN. These parameters define the HLR actions in more

detail and they affect all subscribers in the HLR.

For more information on managing parameters, see section Managing HLR and PLMN

parameters.

For more information on subscriber management, see Subscriber Management in HLR,

AUC, and VLR .

Variable type parameters

The UTP_H4MX file manages the parameters of variable type. You can change and

print out the UTP_H4MX data with the commands of the DF command group. These

parameters are used if more complex functionalities are needed. Usually some

operator-dependent data is needed for defining the functionality.

With variable type parameters you can modify and output the parameter. Each parameter is activated by setting certain

data into the first free UTP_H4MX record. The parameter is deactivated by setting the

data '00' into the UTP_H4MX record. The file number of UTP_H4MX is 5AC001F. The

main copy of UTP_H4MX is stored in the CM. The system takes care of distributing

UTP_H4MX to all HLRU pairs.

The structure of the UTP_H4MX record is the following:

CM-0 FILE N:O 05AC001F RECORD N:O 00000000SS SS PP PP DD DD DD DD

where:

SS SS defines in which operation the parameter is active

PP PP identifies the parameter

DD DD DD DD identifies the data related to the parameter

For more information, see section Modifying subscriber categories.


9/33

DN985071

Issue 8-0-0

9


Id:0900d805808d42f1

1.3 VLR parameters

The VLR parameters are used to control certain functionality in the VLR. You can

change the values of the VLR and PLMN Parameter Handling, MX Command Group.

The parameters are divided into PLMN-specific and VLR-specific parameters. This

means that you can differentiate home and visitor subscribers with different PLMN-

specific parameters. For example, you might want to use authentication more often with

visitor subscribers than with home subscribers.

The parameter values are stored in the related parameter files. The VLR-specific param-

eter file is called VLR General Parameter file. Some additional VLR-specific parameters

are stored in the UTPFIL. The PLMN-specific file is called the PLMN-specific Parameter

File for VLR.

VLR-specific parameters

The VLR-specific parameters are general parameters of the VLR, meaning that they do

not depend on the subscriber's HPLMN. You can modify the parameters with the MXM command and display the actual settings with the MXO command. With the VLR-specific

parameters you can handle:

• general VLR operations (for example, VLR cleaning, triplet/quintet record, and

deregistration)

• security operations (for example, the use of authentication and IMEI checking, or

security key lifetime)

• the use of TMSI paging and searching

• the support of supplementary services, teleservices, and bearer services

• NITZ parameters

•

default access right reject cause codes • VLR traffic control priorities

• Super-Charger parameters

• VLR Backup parameters

PLMN-specific parameters

The PLMN-specific parameters control VLR functions which depend on the subscriber's

HPLMN. You can modify the parameters with the MXN command and display the actual

settings with the MXP command. With the PLMN-specific parameters you can handle:

• roaming status

• IMEI checking and IMEI status checking parameters

• TMSI allocation frequency parameters • MSRN life time

• traffic termination handling

• authentication and ciphering parameters

• Advice of Charge parameters

• Equal Access parameters

• Intelligent Network parameters

• NITZ parameters

• inter-PLMN handover agreement list

• equivalent PLMN list

•

UMTS integrity parameters • default access right reject cause codes


10/33

10 DN985071

Issue 8-0-0


Id:0900d805808d42f1


• access rights to GSM/UMTS radio network

• Regional Roaming parameters

• Trace activation

•Intelligent Network Mobility Management

• Multiple Equipment Identity Registers

• Super-Charger parameters

• Pre-paging

• PLMN-specific supplementary services

UTPFIL parameters

The UTP_S3MX file contains the customer-specific parameters in the VLRU. You can

change and print out the UTP_S3MX data with the commands of the Memory File Han-

dling, DF command group. These parameters are used when more complex functional-

ities are needed. Usually some operator-dependent data is needed for defining the

functionality.Each parameter is activated by setting certain data into the first free UTP_S3MX record.

The parameter is deactivated by setting the data '00 00 00…' into the UTP_S3MX

record. The file number of UTP_S3MX is 5AC001E. The main copy of UTP_S3MX is

stored in the CM. The system takes care of distributing UTP_S3MX to all VLRU pairs.

The structure of the UTP_S3MX record is the following:

CM-0 FILE N:O 05AC001F RECORD N:O 00000000

SS SS PP PP DD DD DD DD

where:

SS SS defines in which process family the parameter is active

PP PP identifies the parameter DD DD DD DD defines the data related to the parameter

For more information on VLR and PLMN parameters, see sections Managing VLR and

PLMN parameters, Recommendations for VLR parameter values, Recommendations

for PLMN parameter values, and Managing VLRU-UTPFIL parameters.

1.4 Recommendations for VLR parameter values

To display the current parameter values, use the MXO command.

The execution printout of the MXO command is:

VLR PARAMETERS

1) TMSI: USED

2) IMPLICIT IMSI DETACH: USED

3) AUTHENTICATION: USED

4) AUTHENT RETRY: USED

5) TMSI AUTHENT RETRY: NOT USED

6) AUTH RETRY WITH NEW TRIPLET: NOT USED

7) SECURITY KEY LIFETIME 2G: 360 MIN

7) SECURITY KEY LIFETIME 3G: 360 MIN

8) EMERGENCY CALL: AUTHENT NOT USED IMEI CHECKING NOT USED

9) ALLOW CCBS WHEN UDUB: YES

ALLOW CCBS WHEN CFB ACTIVE: NO


11/33

DN985071

Issue 8-0-0

11


Id:0900d805808d42f1

10) ALLOW LOCATION UPDATE WHILE SCP UNAVAILABLE: YES

ALLOW GAPPING IN IN-MM: NO

ALLOW SHORT MESSAGE TRANSFER WHILE SCP UNAVAILABLE: YES

ALLOW GAPPING IN IN-SMS: NO

11) NUMBER OF SIMULTANEOUS CALL TRANSFERS: 5

ALLOW CALL TRANSFERS WHEN MAX EXCEEDED: YES

12) TRAFFIC TERMINATION ON TERM REQUEST: MOC, MTC, SS AND SMS TERMINATED

13) DEFAULT ACTION FOR CALL TRANSFER INVOCATIONS: REPORT AND REJECT

14) FORCE AUTHENTICATION WHEN SGSAP PAGE RESPONSE IS FROM DIFFERENT LA: YES

-----------------------------------------------------------------------

TIME LIMITS

15) LOITERING: 002 DAYS 00 HRS.

2) IMPLICIT DEREGISTRATION: 012 HRS. 30 MIN.

16) CALL WAITING: 00 MIN. 30 SEC.

INCOMING CALL COMPLETION RESPONSE: 04 MIN. 20 SEC.

TMSI FREEZING 02 DAYS-----------------------------------------------------------------------

15) VLR CLEANING START TIME: 04:12

17) MTMS LIST GATHERING START TIME: 03:12

INTER PLMN LU DETECTION: NO

18) INTER VLR LU DETECTION: NO

ROAMING STATUS: HOME

MS CLASSMARK PHASE 2

19) TRIPLETS: MIN=2

20) QUINTETS: MIN=0

21) CDR ON LOCATION UPDATE: DISABLED

-----------------------------------------------------------------------22) VLR TRAFFIC CONTROL PRIORITIES

MOBILE ORIGINATED CALL 100

MOBILE TERMINATED CALL 95

MOBILE ORIGINATED SHORT MESSAGE 100

MOBILE TERMINATED SHORT MESSAGE 95

INTRA VLR LOCATION UPDATE 75

INTER VLR LOCATION UPDATE 50

PRIORITY MODE CPU LEVEL 85%

-----------------------------------------------------------------------

23) SUPPORTED SUPPLEMENTARY SERVICES

LINE IDENTIFICATION: CLIP COLP

CALL FORWARDING: CFU CFB CFNA

CALL OFFERING: CT

CALL COMPLETION: CW HOLD CCBS

MULTIPARTY: MPTY

COMMUNITY OF INTEREST: CUG

CHARGING: AOCI

CALL RESTRICTION: BAOC BOIC

NOKIA SIEMENS SPECIFIC SERV: CTR CA HB PNI RDI

ADDITIONAL INFO TRANSF: UUS1 UUS2 UUS3

LOCATION SERVICES: LCSPC

MULTICALL: MC

ENHANCED MLPP: EMLPPAMR WB SUBSCRIPTION: NO


12/33

12 DN985071

Issue 8-0-0


Id:0900d805808d42f1


PLMN SPECIFIC SS: SS253

-----------------------------------------------------------------------

24) SUPPORTED TELESERVICES

SPEECH TRANSMISSION: T11

SHORT MESSAGE: T21 T22

FACSIMILE TRANSMISSION: T61 T62

-----------------------------------------------------------------------

25) SUPPORTED BEARER SERVICES

DATA C.D.A: B11 B12 B14 B15

DATA C.D.S: B1A B1C

-----------------------------------------------------------------------

26) OPERATOR DETERMINED BARRINGS SUPPORTED

-----------------------------------------------------------------------

27) VLR LEVEL USSD BARRING LIST

LIST EFFECT: WHITE LIST-----------------------------------------------------------------------

28) PAGE AND SEARCH

LIMIT FOR SIMULTANEOUS SEARCHES: 100

NUMBER OF SEARCH REPETITIONS: 2

SEARCH RESPONSE WAITING TIME: 1000 MSEC.

TMSI PAGE REPETITION IN MT CALL: USED

TMSI PAGE REPETITION IN MT SMS: USED

TMSI PAGE REPETITION IN MT USSD: USED

TMSI PAGE REPETITION IN MT LR: USED

29) MAX AGE OF LOCATION IN PREPAGE: 30 SEC.

SEARCH_OPTIMIZATION: USED30) MME SEARCH FOR MME SUBSCRIBERS: NOT USED

31) PSI PAGING OVER SGS INTERFACE: CSC

31) PSI PAGING ON LOCATION REQUEST: NOT USED

-----------------------------------------------------------------------

NITZ PARAMETERS

ALLOW SENDING TIME INFORMATION: YES

ALLOW SENDING NITZ INFORMATION DURING LOCATION UPDATE: YES

IN WHICH NUMBER OF EVENT

ALLOW SENDING NITZ INFORMATION DURING INTRA-VLR LU: 10

ALLOW SENDING NITZ INFORMATION DURING IMSI ATTACH: 10

ALLOW SENDING NITZ INFORMATION DURING PERIODIC LU: 10

FULL 3G NETWORK NAME: MIDDLEEARTH

SHORT 3G NETWORK NAME: MIDEARTH

-----------------------------------------------------------------------

DEFAULT REJECT CAUSE CODES

TO GSM TO UMTS

GSM SUBSCRIBER NO CELL

UMTS SUBSCRIBER (USIM) NO NO

-----------------------------------------------------------------------

IMSI ANALYSIS FAILURE REJECT CAUSE CODE IN GSM NETWORK : PLMN

IMSI ANALYSIS FAILURE REJECT CAUSE CODE IN UMTS NETWORK : PLMN

-----------------------------------------------------------------------32) SUPER-CHARGER PARAMETERS


13/33

DN985071

Issue 8-0-0

13


Id:0900d805808d42f1

INFORM PREVIOUS NETWORK ENTITY IFNOSI

HANDLING MTC FOR PASSIVE SUBS REJECT

VLR UPDATE COUNTER 033

WELCOME SM CRITERION 99 DAYS 23 HRS.

-----------------------------------------------------------------------

ADVANCED DB MANAGEMENT PARAMETERS

TARGET DB FILL RATIO 95%

-----------------------------------------------------------------------

33)VLR BACKUP PARAMETERS

UPDATE INTERVAL : 60 MIN

CONNECTION ALLOWED IN UNITS : 0, 1

CONNECTION DENIED IN UNITS : 2, 3, 4, 5, 6, 7, 8, 9

-----------------------------------------------------------------------34)

MT RE-ROUTING DELAYS

MT RE-ROUTING DELAY TIMER AT MAP SI: 50 (500 MSEC)

MT RE-ROUTING DELAY TIMER AT MAP CLO: 0 (0 MSEC)

COMMAND EXECUTED

Follow the below recommendations when setting VLR parameter values.

1) TMSI

Use TMSI because

• it increases the network capacity. Four TMSIs fit in one page message over the radio

path. Only two IMSIs or one IMSI and two TMSIs fit in a one-page message.

• it is safer to send TMSI than IMSI over the radio path.

• it reduces signaling between the VLR and the HLR. It means that the subscriber's

triplets/quintets can be fetched from the old VLR, not from the HLR.

The VLR starts the implicit TMSI allocation when the subscriber identifies with IMSI, but

the network uses TMSI (not in the location update of a new subscriber). TMSI sending

to the MS and TMSI removing from the MS should be ciphered. TMSI removing from the

MS is done by sending IMSI which should be ciphered.

The MSS/VLR will never initiate page messages over the radio path with unconfirmed

TMSI.

2) IMPLICIT IMSI DETACH

Use the Implicit IMSI detach and set the deregistration time so that it is longer than twice

the periodic location update interval. The detached state means that the subscriber is

not paged from the network. This decreases the radio network load.

The subscribers are set in detached state when they have been inactive (not even

periodic location updates) longer than allowed (deregistration time value) and get a

mobile-terminated call, short message or USSD. When the Implicit IMSI detach is

USED, the attach/detach operation must be on in the BSC. The periodic location updateinterval can be BTS-specific, but normally the same value is used in the whole network.


14/33

14 DN985071

Issue 8-0-0


Id:0900d805808d42f1


3) AUTHENTICATION

Use the authentication. Before authentication can be set ON, do the following:

• Deliver the description of the algorithm or the MoU algorithm license to Nokia

Siemens Networks.

• Create the subscribers in the AUC.

• The subscribers are created with the correct versions of algorithms when compared

to the subscriber's SIM card.

4) AUTHENT RETRY

Use authentication retry when authentication parameters are corrupted between the MS

and the VLR, or the VLR does not receive response from the MS at all. In a UMTS

network, authentication can be repeated only in the last case.

5) TMSI AUTHENT RETRY

Do not use the TMSI authentication retry. In theory it is possible that the TMSI stored in

the VLR and the TMSI in the MS do not match. Whenever the authentication is not suc-cessful and the MS has identified with TMSI, the VLR requests the MS's IMSI. If the IMSI

is different from the IMSI identified from the TMSI, a new authentication is started by the

MSS/VLR.

6) AUTH RETRY WITH NEW TRIPLET

No recommendations. A5/3 ciphering support is needed in the BSC/MSS and also in the

MS in order to be able to use this functionality. For more information on this parameter,

see Feature 897: Authentication and Ciphering, Feature Description.

7) SECURITY KEY LIFETIME 2G, SECURITY KEY LIFETIME 3G

Set the security key lifetime in minutes respectively to the traffic profile and authentica-

tion frequency counters in PLMN parameters. The lower the security key lifetime is, themore frequent and stricter the authentication is, which can cause additional network load

between the authentication center (AUC) and the VLR.

The recommendation is to keep the security key lifetime as close to the periodic location

update time as possible.

For more information on these parameters, see Feature 897: Authentication and Cipher-

ing, Feature Description.

8) EMERGENCY CALL

Do not use the emergency call parameter values (authentication and IMEI checking).

These parameters only apply to calls done with a SIM card. Call Control handles emer-

gency calls done without a SIM card, which means that these parameter values do nothave an effect on those calls.

If the parameters are taken into use, international emergency calls are successful inde-

pendently on the result of the authentication and IMEI checking.

9) ALLOW CCBS WHEN UDUB

No recommendations. For more information on these CCBS parameters, see Feature

234: Completion of Calls to Busy Subscriber Phase 2, Feature Description.

10) ALLOW LOCATION UPDATE WHILE SCP UNAVAILABLE

Set the parameter value of the ALLOW LOCATION UPDATE WHILE SCP UNAVAIL-

ABLE to YES. This means that location updates are allowed even if the IN Service

Control Point cannot be reached, and that the subscribers are not blocked from thenetwork.


15/33

DN985071

Issue 8-0-0

15


Id:0900d805808d42f1

For more information on these parameters, see Feature 742: IN Mobility Management,

Feature Description.

11) NUMBER OF SIMULTANEOUS CALL TRANSFERS

No recommendations. For more information on these fraud related parameters, seeFeature 899: Subscriber Fraud Limitation, Feature Description.

12) TRAFFIC TERMINATION ON TERM REQUEST

Set the traffic termination on term request to MOC, MTC, SS and SMS TERMINATED.

Traffic termination does not apply to emergency calls.

13) DEFAULT ACTION FOR CALL TRANSFER INVOCATIONS

No recommendations. For more information on this parameter, see Feature 997: Sub-

scriber Fraud Detection and Limitation, Feature Description.

14) FORCE AUTHENTICATION WHEN SGSAP PAGE RESPONSE IS FROM DIFFER-

ENT LA

According to the release 9 specifications of the SGs interface, the VLR has to force the

authentication when the SGsAP paging response comes from another location area. Set

the ADIFFLA parameter to YES in order to comply the specifications.

For more information on this parameter, see Feature 1914: CS Fallback in EPS for MSS,

Feature Description.

15) LOITERING and VLR CLEANING START TIME

VLR cleaning means that the subscribers who have had no activity in the VLR for a given

period of time can automatically be deleted from the VLR database. The default value

of loitering (the time for how long a subscriber can stay inactive in the VLR) is 24 days,

but it is recommended to be decreased to 2 days.

The cleaning start time must be set for the quiet hours of the network operation, that is,

at night when there are no statistics or charging processing. The fact whether the start

time parameter has changed or not is checked in every minute. To set the cleaning

immediately, set the start time as the current time + 2 minutes. It is recommended to set

the start time to 04:12.

16) CALL WAITING

No recommendations. If the subscriber does not answer the waiting call in the set time,

the Call Forwarding no-reply-transfer is started.

17) MTMS LIST GATHERING START TIME

With this parameter you can set the accurate start time for the MTMS list gathering.

During this procedure the MTMS scans through the VLR database the same way as theVLR cleaning procedure does. At least a 60-minute interval is required between the VLR

cleaning start and the start of the data gathering process for MTMS. It is desirable to run

data gathering process first, before the VLR cleaning procedure. It is recommended to

set the start time to 03:12.

18) INTER VLR LU DETECTION

Set the parameter value of NEW VISITOR AND PREVIOUS LAI IS ZERO to N (No).

Setting the value of this parameter to Y (Yes) can lead to numerous false SM triggers

as the previous LAI can be zero not only when a new subscription is activated in the

network, but also after an unsuccessful location update, for example.


16/33

16 DN985071

Issue 8-0-0


Id:0900d805808d42f1


For more information on the INTER PLMN LU DETECTION, ROAMING STATUS, MS

CLASSMARK parameters and this parameter as well, see Feature 1433: Terminal Man-

agement Support, Feature Description.

19) TRIPLETSSet the minimum triplet value to two. The VLR requests for more triplets when the limit

is reached. The subscriber data can contain seven triplets, and the Nokia Siemens

Networks network can deliver five triplets per one request.

20) QUINTETS

Set the minimum quintet value to 0. The VLR requests for more quintets when the limit

is reached. The subscriber data can contain four quintets.

21) CDR ON LOCATION UPDATE

No recommendations. For more information on this parameter, see Feature 1448: High

Capacity MSS&GCS, Feature Description.

22) VLR TRAFFIC CONTROL PRIORITIES

No recommendations. For more information on this parameter, see Feature 1697:

Traffic Control in VLR, Feature Description.

23) SUPPORTED SERVICES

With this parameter you can define the supported services in the VLR. Not supported

services are ignored. The HLR can send a substituting service for the services that are

not supported in the VLR. This operation requires MAP Ph2. The substituting services

are defined in the HLR.

24) VLR LEVEL USSD BARRING LIST


USSD Barring Based on PLMN-Specific Service Code, Feature Description.

25) PAGE AND SEARCH

Set the parameter value for NBR OF STARTED SEARCH PROCEDURES to 100. If you

have overload problems in the radio network after the VLR reset, limit the search proce-

dures. If the counter value is 0, the MTCs for unknown subscribers do not go through.

26) NITZ PARAMETERS

Set the parameter value for ALLOW TRANSFER OF NITZ-RELATED TIME INFORMA-

TION to Y (=allowed). With these parameters you can transfer the network name, uni-

versal time, date, time zone and daylight saving time to the mobile stations. This

enhances roaming by permitting the accurate indication of network names that are

either newer than the mobile or have changed their names since the mobile was sold orits software was updated. Also a mobile supporting NITZ can set its clock automatically

to the local time and take daylight saving times into account. To avoid the overload of

the network it is recommended to receive NITZ information in every tenth case.

27) DEFAULT REJECT CAUSE CODES

The recommended value is CELL (no suitable cells in this LA) if you want to force the

subscriber from one access to another (for example, the UMTS subscriber should be

forced from GSM to UMTS radio network). The effect of using different reject cause

codes on the mobile subscriber is specified in 3GPP TS 24.008 . The PLMN level default

reject cause codes (other than value NO) overrule these settings. If both the PLMN and

VLR parameters are set to the value NO, the default value is LA, which means 'LOCA-

TION AREA NOT ALLOWED'.


17/33

DN985071

Issue 8-0-0

17


Id:0900d805808d42f1

28) IMSI ANALYSIS FAILURE REJECT CAUSE CODE

No recommendations.

29) MAX AGE OF LOCATION IN PREPAGE

No recommendations. For more information on this parameter, see Feature 1618: Pre-

paging, Feature Description.

30) MME SEARCH FOR MME SUBSCRIBERS

The execution of the search procedure over the SGs interface is configurable with the

MMESRC VLR parameter. Setting the parameter to USED may cause additional load on

the connected Mobility Management Entities (MMEs) and the SGs interface. For more

information on this parameter, see Feature 1914: CS Fallback in EPS for MSS, Feature

Description.

31) PSI PAGING OVER SGS INTERFACE , PSI PAGING ON LOCATION REQUEST

No recommendations. For more information on these parameters, see Feature 1914:

CS Fallback in EPS for MSS, Feature Description.

32) SUPER-CHARGER PARAMETERS


Super-Charger, Feature Description.

33) VLR BACKUP PARAMETERS

No recommendations. For more information on this parameter, see Feature 1881: VLR

Backup, Feature Description.

34) RDELAYSI, RDELAYCLO

The RDELAYSI timer parameter defines MT re-routing delay after MAP SendIdentifica-

tion is received. That is, it controls the time length the VLR waits between receiving MAPSendIdentification and performing Mobile Terminating Roaming Retry to the new VLR.

The recommendation is to set the timer to 500 MSEC at least to avoid reaching the new

MSS too early, when the CS fallback has not finished yet.

For more information on these parameters, see Feature 1914: CS Fallback in EPS for

MSS, Feature Description.

For more information, see section Managing VLR and PLMN parameters.

1.5 Recommendations for PLMN parameter values

To display the current PLMN-specific parameter values, use the MXP command.

The following execution printout of the MXP command includes the recommendedparameter values highlighted. Other values are either examples (not recommended) or

show the value range for the parameter in question.

PLMN PARAMETERS

VISITOR PLMN MIDDLEEARTH IN FOREIGN COUNTRY

INDEX: 8

35) CIPHERING: USED

36) TRIPLET RE-USE: USED

EMLPP DEFAULT PRIORITY LEVEL: NOT USED

SUPPORT OF EMLPP: YES 37)


18/33

18 DN985071

Issue 8-0-0


Id:0900d805808d42f1


COUNTRY CODE LENGTH: 3 NO RESPONSE EFFECT: ALLOW

38) MSRN GROUP: 02 BLACK LIST EFFECT: BLOCK

MSRN LIFE TIME: 75 SEC. GREY LIST EFFECT: BLOCK

39) PNS TIME LIMIT: 20 SEC. UNKNOWN IMEI EFFECT: TRACE

40) TRAFFIC TERMINATION ON CANCEL LOCATION: MOC, MTC, SS AND SMS TERMINATED

41) SUPPORTED CAMEL PHASE: PHASE 4

----------------------------------------------------------------------------------

42) CAMEL DATA NEGOTIATION TABLE:

O-CSI: DEFAULT SS-CSI: DEFAULT SMS-CSI: DEFAULT VT-CSI: DEFAULT

D-CSI: DEFAULT M-CSI: DEFAULT MTSMS-CSI: NS TIF-CSI: NS

----------------------------------------------------------------------------------

43) PSI PAGING: ALLOWED

44) FRAUD OBSERVATION AND LIMITATION: USED

SUPPORT OF LOCALISED SERVICE AREA: NOT USED

45) REGIONAL ROAMING: ALLOWED

ZONE CODES: F209 F20A F20B 0010 0011 0012 1C00 1C01ZONE CODES FROM HLR: USED

46) EXACT MS CATEGORY USAGE: ALLOWED

47) TRIGGER SM TO NTMS: NOT ALLOWED

48) REJECT CAUSE FOR UDL REJECTION: ROAM

49) SUPPORT OF BOR: NO

50) SUPPORT OF CNAP: NO

51) USAGE OF PLMN SPECIFIC SS 253: NOT SUPPORTED

52) CS/PS COORDINATION REQUIRED: NO

53) LA BASED IN-MM TRIGGERING IN USE: N

ZC FOR DP1: ALL

ZC FOR DP2: ALLZC FOR DP3 IMSI ATTACH: ALL

ZC FOR DP3 PERIODIC LU: ALL

ZC FOR DP3 INTRA-VLR LU: ALL

54) PRE-PAGING SUPPORTED: NO

55) IGNORE CLIR FROM HLR: N

LONG FORWARDED-TO NUMBER SUPPORTED: NO

56) ACCESS RESTRICTION BY BS30: NO

57) ALLOW ALWAYS HANDOVER TO 3G: NO

58) ALLOW ALWAYS HANDOVER TO 2G: NO

59) NBR OF FETCHED VECTORS IF NONE AVAIL.: 2

60) ANY TIME INTERROGATION DELAY TIME: 100 (1000 MSEC)

61) REDIRECT SUBSCRIBERS TO TEST MSS: NO

--------------------------------------------------------------------------------

63) ADVICE OF CHARGE PARAMETERS

E1: 1,5 E2: 11,7 E3: 7,50

E4: 11,0

E7: 111,2

--------------------------------------------------------------------------------

34) A5 ALGORITHM PARAMETERS

NONCIPHERED CONNECTION: NOT ALLOWED

A5/1: ALLOWED A5/2: NOT ALLOWED A5/3: ALLOWED

A5/4: NOT ALLOWED A5/5: NOT ALLOWED A5/6: NOT ALLOWEDA5/7: NOT ALLOWED


19/33

DN985071

Issue 8-0-0

19


Id:0900d805808d42f1

--------------------------------------------------------------------------------

64) EIR ADDRESS: 36209849367

65) IMEI STATUS CHECK FROM EIR IN CASE OF...

LOC UP: USED PER UP: NOT USED IMSI ATTACH: USED

MO CALL: NOT USED MO SMS: NOT USED SS OPER: NOT USED

MT CALL: NOT USED MT SMS: NOT USED MT USSD: NOT USED

MT LOC REQ: NOT USED

--------------------------------------------------------------------------------

USAGE FREQUENCY COUNTERS (0 = NOT USED)

66) TMSI ALLOCATION

IMSI ATTACH: 1 PER UP: 0 MO CALL: 0

MO SMS: 0 MT CALL: 0 MT SMS: 0

MT LOC REQ: 0 MT USSD: 0 SS OPER: 0

CS FALLBACK: 0

67) AUTHENTICATION

LOC UP NEW VIS: 1 LOC UP: 0 PER UP: 0

IMSI ATTACH: 1 MO CALL: 10 MO SMS: 1

MT CALL: 10 MT SMS: 0 MT LOC REQ: 0

MT USSD: 0 SS OPER: 0 IMSI ACCESS: 0

CS FALLBACK: 0

68) IMEI CHECKING

LOC UP NEW VIS: 1 LOC UP: 5 PER UP: 1

IMSI ATTACH: 1 MO CALL: 0 MO SMS: 0MT CALL: 0 MT SMS: 0 MT LOC REQ: 0

MT USSD: 0 SS OPER: 0 CS FALLBACK: 0

--------------------------------------------------------------------------------

69) EQUAL ACCESS

DEFAULT PREFERRED INTEREXCHANGE CARRIER (PIC): 288

DEFAULT PIC LOCK: CARRIER ACCESS CODE (CAC) DIALLING IS DENIED

PIC RELATION: SUBSCRIBER INFORMATION FROM HLR IS PREFERRED

PIC LOCK RELATION: PLMN DEFAULT IS USED ALWAYS

--------------------------------------------------------------------------------

70) INTELLIGENT NETWORK MOBILITY MANAGEMENT

SCP ADDRESS: 3332244668800

SERVICE KEY: 258

AUTO IN MM ALLOWED: N

--------------------------------------------------------------------------------

71) INTELLIGENT NETWORK MOBILE ORIGINATED SMS

SCP ADDRESS: O-CSI DATA IS USED

SERVICE KEY: 1370

--------------------------------------------------------------------------------

72) NITZ PARAMETERS

FULL NETWORK NAME: MIDDLEEARTHSHORT NETWORK NAME: MIDEARTH


20/33

20 DN985071

Issue 8-0-0


Id:0900d805808d42f1


ALLOW ADDING COUNTRY INITIALS TO FULL NETWORK NAME: YES

ALLOW ADDING COUNTRY INITIALS TO SHORT NETWORK NAME: NO

--------------------------------------------------------------------------------

73) INTER-PLMN HANDOVER AGREEMENTS

MOBILE COUNTRY CODE MOBILE NETWORK CODE

220 1

220 2

255 3

216 1

--------------------------------------------------------------------------------

74) EQUIVALENT PLMNS

MOBILE COUNTRY CODE MOBILE NETWORK CODE

100 2

100 3

210 2

216 2150 4

75) UMTS CIPHERING: USED

--------------------------------------------------------------------------------

76) UMTS ENCRYPTION PARAMETERS

NONCIPHERED CONNECTION: NOT ALLOWED

SUPPORTED ALGORITHMS: UEA1

--------------------------------------------------------------------------------

77) UMTS SECURITY PARAMETERS

SUPPORTED ALGORITHMS: UIA1

--------------------------------------------------------------------------------

78) NETWORK ACCESS RIGHTS

TO GSM REJECT CODE TO UMTS REJECT CODE

GSM SUBSCRIBERS YES NO PLMN

UMTS SUBSCRIBERS (USIM) NO LA YES

--------------------------------------------------------------------------------

79) PLMN SPECIFIC USSD BARRING LIST

LIST EFFECT: BLACK LIST

22,11,211

--------------------------------------------------------------------------------

80) TRACE ACTIVATION PARAMETER

TRACE ACTIVATION FROM THIS PLMN: ALLOWED

--------------------------------------------------------------------------------

81) LOCATION REQUEST

MOBILE ORIGINATED: SUPPORTED

MOBILE TERMINATED: SUPPORTED

DEFERRED MOBILE TERMINATED: SUPPORTED--------------------------------------------------------------------------------


21/33

DN985071

Issue 8-0-0

21


Id:0900d805808d42f1


PLMN UPDATE COUNTER 000

--------------------------------------------------------------------------------

83) REPORTING INSTANCES ALLOWED

ID NAME

--------------------------------------------------------------------------------

84) PLMN SPECIFIC SUPPLEMENTARY SERVICE HANDLING

RELAY LIST:

HANDLE LIST: F1, F2, F3, F4, F5, F6, F7, F8, F9, FA, FB, FC, FD, FE

DECAF CODE:

COMMAND EXECUTED

Follow the below recommendations when setting PLMN parameter values.

35) CIPHERING

This parameter must be set to 'USED'. You can do it only when the authentication is in

use.

There are several authentication algorithms for GSM ciphering available in the

MSS/VLR. A5/3 is a strong encryption algorithm created as part of the 3rd Generation

Partnership Project (3GPP), therefore, it is recommended to use.

The recommended order of preference is:

• A5/3

• A5/1

When using the A5/1 algorithm, it is recommended to use transaction authentication as

frequent as possible, taking the A/Iu and MAP interface capacities into consideration.

If more than one algorithms are allowed, the radio network configuration decides on

which algorithm shall be used towards the user equipment (UE).

The A5/2 ciphering algorithm is not supported by the standards any more because,

firstly, it is not strong enough, and secondly, A5/1 has been deemed mandatory by the

3GPP association. If still the A5/2 algorithm is allowed only, the NON-CIPHERED con-

nection is recommended to be allowed with as frequent authentication as possible.

36) TRIPLET RE-USE

Set the parameter value for triplet reuse to Y. This way, when authentication or ciphering

is in use, the network operations are not prevented if new triplets cannot be obtained

from the AUC.

37) EIR LIST EFFECTS

If the effect of unknown IMEI is BLOCK, use the CEIR or manually keep your EIR white

list always updated.

Trace observation reports cause substantial load in the MSS. The maximum number of

traced subscribers has been calculated assuming that each of them makes only a few

calls per day. You are recommended to limit the number of traced subscribers if you

expect the traced subscribers to make a lot of calls roughly at the same time.


22/33

22 DN985071

Issue 8-0-0


Id:0900d805808d42f1


It is recommended to use ALLOW for the grey equipment if heavy load is experienced.

38) MSRN GROUP, MSRN LIFETIME

Set the parameter value for home subscribers to 2 seconds and for visitors to 30

seconds. If the lifetime of the roaming number is too short, the call is cleared with a clearcode 405 erroneous request from co-process. There is no recommendation for the

MSRN group.

39) PNS TIME LIMIT

No recommendations. The default value is 20 seconds. When a PNS subscriber has

Call Forwarding No Reply service, the no_reply_condition_time of the CFNRy overrules

the pns_time_limit.

40) TRAFFIC TERMINATION ON CANCEL LOCATION

Traffic termination in the PLMN-specific parameters applies only in roaming (cancel

location).

41) SUPPORTED CAMEL PHASE


Licence Handling in VLR, Feature Description.

42) CAMEL DATA NEGOTIATION TABLE


CAMEL Phase 2, Feature Description.

43) PSI PAGING



44) FRAUD OBSERVATION AND LIMITATION No recommendations. For more information on this parameter, see Feature 997: Sub-

scriber Fraud Detection and Limitation, Feature Description.

45) REGIONAL ROAMING, ZONE CODES


Regional Roaming (Zone Codes), Feature Description.

46) EXACT MS CATEGORY USAGE

No recommendations. For more information on this parameter, see Feature 1632: Exact

Mobile Subscriber Category, Feature Description.

47) TRIGGER SM TO NTMS


Terminal Management Support, Feature Description.

48) REJECT CAUSE FOR UDL REJECTION


PLMN Specific Reject Cause, Feature Description.

49) SUPPORT OF BOR


Support of Optimal Routing for Basic Call Cases, Feature Description.

50) SUPPORT OF CNAP

No recommendations. For more information on this parameter, see Feature 1603:Calling Name Presentation Alternatives, Feature Description.


23/33

DN985071

Issue 8-0-0

23


Id:0900d805808d42f1

51) USAGE OF PLMN SPECIFIC SS 253



52) CS/PS COORDINATION REQUIRED

No recommendations. For more information on this parameter, see Feature 881: Gs

Interface Support, Feature Description.

53) LA BASED IN-MM TRIGGERING IN USE

No recommendations. For more information on this parameter, see Feature 742: IN

Mobility Management, Feature Description.

54) PRE-PAGING SUPPORTED



55) IGNORE CLIR FROM HLR

No recommendations. For more information on this parameter, see Feature 1962: Not

Supported Supplementary Services in VLR, Feature Description.

56) ACCESS RESTRICTION BY BS30


UMTS Subscription, Feature Description.

57) 58)ALLOW ALWAYS HANDOVER TO 3G, ALLOW ALWAYS HANDOVER TO 2G

No recommendations. For more information on this parameter, see Feature 1663: Radio

Access Technology Restriction, Feature Description.

59) NBR OF FETCHED VECTORS IF NONE AVAIL


UMTS Security in MSS, Feature Description.

60) ANY TIME INTERROGATION DELAY TIME

The recommended value is one second for delaying the MAP AnyTimeInterrogation

request sending.

The timer controls how much time the old MSS waits before sending the AnyTimeInter-

rogation Request after receiving the MAP CancelLocation Response (or MAP SendI-

dentification Response if Super-Charger is in use). If the HLR does not support the delay

of ATI and the new MSS does not support the MAP ProvideSubscriberInfo during the

location update procedure, the old MSS can delay the relayed PSI Request.

For more information on this parameter, see Feature 1914: CS Fallback in EPS for MSS,Feature Description.

61) REDIRECT SUBSCRIBERS TO TEST MSS

For more information on this parameter, see Feature 1449: Multipoint Iu in MSS

Concept, Feature Description and Feature 1564: Multipoint A Interface, Feature

Description.

63) ADVICE OF CHARGE PARAMETERS

No recommendations. For more information on this parameter, see Feature 418: Advice

of Charge, Feature Description.

64) EIR ADDRESS


24/33

24 DN985071

Issue 8-0-0


Id:0900d805808d42f1


Define the EIR address here if you use Multiple EIRs based on the subscribers' home

PLMN (optional). If you use the Multiple EIR functionality and do not define the EIR

address here, the VLR will not perform IMEI status checking for these subscribers.

65) IMEI STATUS CHECK FROM EIR IN CASE OF... Allow the IMEI status check from the EIR in location updates and on IMSI attach. The

status check is always done against the user equipment’s IMEI in the case of new

visitors (those subscribers who enter to the VLR at the first time), even if the parameters

do not require IMEI checking in the EIR. Also, the IMEI checking in the EIR is always

done if the IMEI sent by the MS is different from the IMEI stored in the database. The

stricter usage of IMEI checking might increase the network load between the VLR and

the EIR.

66) TMSI ALLOCATION

Set TMSI allocation to ON with IMSI attach. According to GSM specifications, TMSI is

location-area-specific which can be guaranteed by the recommended settings since

location area changes induce TMSI allocation.

67) AUTHENTICATION

According to specifications, authentication has to be done when the subscriber enters

the network. Authentication in other cases is necessary only for the changing of the

security key(s). The usage frequency of authentication increases the network load

between the VLR and the HLR, that is, the fetching of the triplets/quintets from the AUC.

The execution printout of the MXP command above includes typical settings.

68) IMEI CHECKING

Allow IMEI checking when the subscriber enters the network. Note that IMEI status is

checked automatically from the EIR when location update with new visitor is USED.

69) EQUAL ACCESS

No recommendations. For more information on this parameter, see Feature 818: World

Zone 1 Equal Access and Numbering Plan, Feature Description or Feature 1296:

Carrier Selection, Feature Descriptions.

70) INTELLIGENT NETWORK MOBILITY MANAGEMENT

No recommendations. Using this for home subscribers increases the network load. For

more information on this parameter, see Feature 742: IN Mobility Management, Feature

Description.

71) INTELLIGENT NETWORK MOBILE ORIGINATED SMS

No recommendations. For more information on this parameter, see Feature 910: IN:Short Message Service, Feature Description.

72) NITZ PARAMETERS


Network Identity and Time Zone Support, Feature Description.

73) INTER-PLMN HANDOVER AGREEMENTS


Multiple PLMN and Inter-PLMN Handover Support, Feature Description.

74) EQUIVALENT PLMNS

No recommendations. For more information on this parameter, see Feature 1260: Inter-

system Handover and UMTS Changes, Feature Description.


25/33

DN985071

Issue 8-0-0

25


Id:0900d805808d42f1

75) UMTS CIPHERING

For security reasons and for the subscriber's confidentiality it is recommended to use

UMTS ciphering. Authentication and authentication on location update with a new visitor

has to be set to ON, and at least one UMTS encryption algorithm or non-ciphered con-nection should be allowed in order to be able to give this parameter the value YES.

76) UMTS ENCRYPTION PARAMETERS

Although the subscriber's confidentiality is lowered in non-ciphered connections, due to

the fact that non-ciphered connections are rare, and they can be a result of a system

malfunction or failure, it is recommended to allow non-ciphered connections. The sup-

ported algorithm is UEA1, but there are further algorithms to be standardized and used

as supported algorithms. It is recommended to set this algorithm to ON.

77) UMTS SECURITY PARAMETERS

The supported algorithm is UIA1, but there are further algorithms to be standardized and

used as supported algorithms. It is recommended to set this algorithm to ON.

78) NETWORK ACCESS RIGHT

With these parameters you can define access rights for GSM and UMTS subscribers to

GSM and UMTS networks. You can also define reject cause codes for those GSM and

UMTS subscribers who attempt to attach to a not allowed GSM or UMTS network.

In case of the access right parameters the recommended value is YES, meaning that

access rights for GSM or UMTS subscribers are granted to attach to both a GSM and a

UMTS network.

In case of the reject causes the recommended value is NO (not used), meaning that the

default value is used. If the PLMN parameter is set to the value NO, the VLR parameter

becomes valid. If the VLR parameter is also set to the value NO, the default value is LA,

meaning LOCATION AREA NOT ALLOWED.

The execution printout of the MXP command above includes typical settings for a visitor

PLMN.

79) PLMN SPECIFIC USSD BARRING LIST



80) TRACE ACTIVATION PARAMETER

No recommendations. For more information on this parameter, see Subscriber and

Equipment Trace, Feature Description.

81) LOCATION REQUEST No recommendations. For more information on this parameter, see Feature 1070:

Support for Location Services (LCS), Feature Description.



Super-Charger, Feature Description.

83) REPORTING INSTANCES ALLOWED

No recommendations. For more information about this parameter, see Feature 1726:

Subscriber Data Feed from VLR, Feature Description.

84) PLMN SPECIFIC SUPPLEMENTARY SERVICE HANDLING


26/33

26 DN985071

Issue 8-0-0


Id:0900d805808d42f1



PLMN-Specific SS-Code Support in MSS/VLR, Feature Description.

For more information, see section Managing VLR and PLMN parameters.


27/33

DN985071

Issue 8-0-0

27

Parameter Management in EIR, HLR, and VLR Managing HLR and PLMN parameters

Id:0900d805808d42f3

2 Managing HLR and PLMN parametersYou can display and change the fixed type HLR parameters and PLMN-specific param-

eters in the HLR.

2.1 Adding a PLMN

You can add a PLMN on your list with the MJA command. The new PLMN gets the initial

parameter values of the default VPLMN (index 0) if the type is VPLMN. The new PLMN

gets the initial parameter values of the default HPLMN (index 1) if the type is HPLMN.

You can delete a PLMN record by using the MJD command.

Before you start

To be able to create an HPLMN type PLMN, you must have a default PLMN named

HPLMN. If this HPLMN does not exist, you can create it with the MJA command. The

default VPLMN exists automatically.

Steps

List PLMN names, addresses, and indices.

ZMJL;

2 Add a PLMN.

Use the MJA command to add a PLMN.

For further information, see section HLR parameters.

2.2 Modifying PLMN parametersYou can modify the PLMN parameter values with the MJN command. First identify the

PLMN with the name, address or index, and then list the desired parameters and their

values. With the parameters of this command you can define if a subscriber with a

certain service is not allowed to roam, if the subscriber is removed from the VLR when

location update fails, if the PLMN is handled as a home PLMN, and the supported

CAMEL phase. SMS re-routing parameters can also be set for a given PLMN.

Steps

Check the existing PLMN names, addresses, and indices.

ZMJL;

2 Display the parameter values.

Use the MJP command.

3 Modify PLMN parameters.

Use the MJN command.

For further information, see section HLR parameters.

2.3 Creating not allowed service

With the MJS command you can define the basic or supplementary services that are not

transferred from the HLR to the VLR or the SGSN when the subscriber is roaming intoa certain PLMN. The modifications on subscriber data affected by this command are


28/33

28 DN985071

Issue 8-0-0


Id:0900d805808d42f3

Managing HLR and PLMN parameters

updated when the subscriber makes the next location update after the modification

operation.

First define the name, address, or index of the PLMN where the restriction is used. Then

define the services that are not to be transferred. You can define both basic and supple-mentary services at the same time, but only one service of each at a time.

Steps

Create a not allowed service.

Use the MJS command to define the basic service either with a single basic service

code or a small group code.

g Do not use group codes unless a list of all basic service codes belonging to thatgroup is included.

For detailed information on subscriber management and services, see Subscriber

management in HLR, AUC, and VLR .

2.4 Deleting not allowed service

With the MJT command you can delete the not allowed service from a list that deter-

mines the services that are not transferred when the subscriber roams into a certain

PLMN. This means that you can define the services that are allowed to be transferred.

The modifications on subscriber data affected by this command are updated when the

subscriber makes the next location update after the modification operation. You can

define both basic and supplementary services at the same time, but only one service of

each at a time.

First define the address, name or index of the PLMN where the restriction is no longer

valid. Then define the services that are allowed to be transferred from now on.

Steps

Delete a not allowed service.

Use the MJT command to delete a not allowed service.

To see the whole topic summary, go to section Parameter management in EIR,

HLR, and VLR .

2.5 Modifying HLR parameters

You can modify the current HLR parameter values with the MJM command.

The parameters have no recommended parameter values.

When the parameter value update succeeds, the command displays the current param-

eter values in the same way as the MJO command does. If the parameter update fails,

the system displays an error message.

When you make changes in the subscriber data, the changes need to be transferred

from the HLR to the VLR. The and parameters define how many update attempts are

made and the length of the delay between the attempts of updating the subscriber data.

Sometimes you need to delete or deactivate the subscriber from the HLR. The HLR

needs to remove the subscriber from the VLR. This removal may be unsuccessful. In


29/33

DN985071

Issue 8-0-0

29

Parameter Management in EIR, HLR, and VLR Managing HLR and PLMN parameters

Id:0900d805808d42f3

this case the and parameters define how many additional deletion attempts are

made and the length of the delay between the deletion attempts.

In addition to the previous parameters there are HLR-specific parameters affecting callforwarding functions, IN services, and SMS functions.

Steps

Display the current HLR parameters.

ZMJO;

2 Modify HLR parameters.

Modify the HLR parameters using the MJM command.

For more information, see section HLR parameters.

2.6 Starting GSM restorationYou can start GSM restoration with the MJG command. It means that the reset message

with the given HLR is sent to the given VLR. After that, external location update is

executed to the subscribers of the given HLR in the given VLR. When you use the start

GSM restoration command, the VLR in question marks all the defined subscribers in its

database and when these subscribers use the network, their external location update is

initiated. Reset message can also be sent to a given SGSN.

GSM restoration means re-establishing subscriber data so that it is identical in two dif-

ferent network elements. The restoration is usually made in a situation when the HLR,

VLR or SGSN has failed and subscriber data has been lost, or for example, when old

data is copied to the database from a disk.

g GSM restoration may generate a lot of location updates.

You can use either the default values of the parameters or identify the HLR address, the

VLR address, or the SGSN address of the HLR, VLR, and SGSN that are subjected to

GSM restoration.

The default value of the HLR address parameter is the HLR where this command is

given. The default value of the VLR or SGSN address is all the VLR or SGSN addresses

where the subscribers of the defined HLR are roaming.

Steps

Start GSM restoration.

Use the MJG command to start GSM restoration.


30/33

30 DN985071

Issue 8-0-0


Id:0900d80580821af5

Modifying subscriber categories

3 Modifying subscriber categoriesWith this parameter you can change the value of the subscriber category when a sub-

scriber is roaming outside the HPLMN. The changed category is sent to the VLR but the

category in the HLR is not changed.

First the HLR checks the subscriber's VLR address and compares it to the HPLMN

network. If the VLR address is outside the HPLMN network, the parameter activity is

checked from UTP_H4MX. If the parameter is active, the subscriber's category is

compared to the UTP_H4MX category, and if the categories match, the subscriber's

category is changed to 'ordinary'.

The possible operations for this parameter ('SS SS' in the UTP_4HMX record) are the

following:

2B 01 Update location and Send parameters

68 02 Change of subscriber's category

g Usually both of these operations are ON at the same time. Two records are needed forUTP_H4MX.

The parameter identifier (PP PP in the UTP_H4MX record) is 01 00.

The data in the parameter is in the format DD XX XX XX, where:

DD defines the category which is changed to 'ordinary'. The possible values

are:

0B Priority subscriber

0F Payphone

0D Testphone04 Personal number service

F0 Ordinary no charge

F4 Priority no charge

XX means that the data is not used by this parameter

For detailed information on subscriber management, see Subscriber management in

HLR, AUC, and VLR .

Steps

Display records on the terminal.

Use the DFD command.

2 Modify records.

Use the DFS command; the system generates questions. For information on how to

answer, see the example below.


31/33

DN985071

Issue 8-0-0

31

Parameter Management in EIR, HLR, and VLR Managing VLR and PLMN parameters

Id:0900d805808d42f5

4 Managing VLR and PLMN parametersYou can modify VLR, PLMN, or call transfer observation parameters, display the param-

eter values, list the PLMN names you have on your switch, add new PLMNs to the list,

set and interrogate fraud reporting parameters.

4.1 Modifying VLR parameters

Steps

Display the current VLR parameter values.

ZMXO;

2 Change the VLR-specific parameters.

Modify the VLR parameter values with the MXM command.

The parameters have no default values.

For more information, see section Recommendations for VLR parameter values.

When the parameter value update succeeds, the command displays the current

parameter values in the same way as the MXO command does. If the parameter

update fails, the system displays an error message.

For further information, see section VLR parameters.

4.2 Adding a PLMN

Steps

List PLMN names and indices.

ZMXL;

The command lists both the PLMN names and their indices.

2 Add a new PLMN.

To add a new PLMN use the MXA command. The new PLMN has the default param-

eter values as the default PLMN (index 0, name DEFAULTS).

To modify the parameter values of the created PLMN, use the MXN command.

For further information, see section VLR parameters.

4.3 Modifying PLMN parameters

Steps

Display the current parameter values of a PLMN.

Use the MXP command; the PLMN is identified with a name or an index.

2 Modify PLMN parameters.

Modify the PLMN parameter values with the MXN command. First identify the PLMN

with the name or index, and then list the desired parameters and their values.

g The command line length of the command is limited. Because this commandincludes a lot of parameters, you cannot modify all the parameter values at once.Note also that these parameters have no default values.


32/33

32 DN985071

Issue 8-0-0


Id:0900d805808d42f5

Managing VLR and PLMN parameters

For more information, see section Recommendations for PLMN parameter values.

The counter values mean that, for example, when the location update counter is 5,

the operation (IMEI checking, TMSI allocation, or authentication) is done with every

5th location update registered in the VLR unit. If the counter value is 1, it means that

the operation in question is done every time it is registered in the VLR. If the counter

value is 0, it means that the counter is not used.

When the parameter value update succeeds, the command displays the current

parameter values in the same way as the MXP command does. If the parameter

update fails, the system displays an error message.

For more information, see section VLR parameters.

4.4 Modifying the call transfer observation parameters

Steps

Modify call transfer observation parameters.

Start and stop the call transfer observation, OR interrogate the sampling parameters

with the MXF command.

For more information, see Managing VLR and PLMN parameters.

4.5 Setting and interrogating the fraud handling parameters

Steps

Set and interrogate fraud handling parameters.

Set the fraud reporting parameters by giving the number and the value of the param-

eters to be modified OR interrogate all fraud handling parameters by giving no

parameters at all with the MXR command.

For more information, see Managing VLR and PLMN parameters.

For more information, see Subscriber fraud management in Subscriber Fraud Man-

agement in NSS, and Security Management in AUC, EIR, and VLR .


33/33

Parameter Management in EIR, HLR, and VLR Managing VLRU-UTPFIL parameters

5 Managing VLRU-UTPFIL parametersYou can use the UTPFIL parameters when more complex functionalities are necessary.

Some operator-dependent data is needed for defining the functionality. You can see it

from the following example.

Steps

Search for the index of active CM.

Search the index with the USI command, where x= index of active CM.

2 Search for the VLRU-UTPFIL in active CM if a record starting with SS SS PP PP

exists.

If such record does not exist, find first free record in the VLRU-UTPFIL that is a

record full of zeros.

ZDFD:CM,x:5AC001E;

result y = number of the record containing the parameter or number of the first empty

record

3 Change the record.

ZDFS:CM,x:5AC001E,y;

where x = active CM, and result y = record to be patched

Respond with Y to the following questions:

DO YOU WANT THESE SUBSTITUTIONS TO BE UPDATED ON DISK? (Y = YES, N = NO): Y

DO YOU WANT THESE SUBSTITUTIONS TO BE DISTRIBUTED? (Y = YES, N = NO): Y

New value for the record is SS SS PP PP DD DD DD DD

Where:

SS SS family SSSS (bytes are reversed, for example, 11 05 -> 0511)

PP PP parameter index, No.PPPP (bytes are reversed, for example, 01 00

-> 0001)

DD DD DD DD value of parameter

Respond with Y to the following question:

DO YOU WANT THIS SUBSTITUTION TO BE MADE? (Y = YES, N = NO): Y

4

Wait at least 1 minute until the process reads the new information from the UTPFIL.

Parameter Management in EIR, HLR, And VLR

Documents

Transcript of Parameter Management in EIR, HLR, And VLR