Parameter Management in EIR, HLR, and VLR

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 components.
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.
Parameter Management in EIR, HLR, and VLR
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 2013/4/20. All rights reserved
Important Notice on Product Safety

This 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:
Wichtiger Hinweis zur Produktsicherheit

Von diesem Produkt knnen Gefahren durch Laser, Elektrizitt, Hitzeentwicklung oder
andere Gefahrenquellen ausgehen.
Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch
geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheitsanforderungen erfolgen.
Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal,
Safety and Environmental Information dieses Dokuments oder dieses Dokumentationssatzes.
Id:0900d805808d3ca9
DN985071
Issue 8-0-0
Table of Contents
This document has 33 pages.
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
DN985071
Issue 8-0-0
1
1.1
1.2
1.3
1.4
1.5
Parameter management in EIR, HLR, and VLR . . . . . . . . . . . . . . . . . . . 7

EIR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
HLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
VLR parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Recommendations for VLR parameter values . . . . . . . . . . . . . . . . . . . . 10
Recommendations for PLMN parameter values . . . . . . . . . . . . . . . . . . 17
2
2.1
2.2
2.3
2.4
2.5
2.6
Managing HLR and PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . .

Adding a PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating not allowed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting not allowed service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying HLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting GSM restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying subscriber categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4
4.1
4.2
4.3
4.4
4.5
Managing VLR and PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . .

Modifying VLR parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying PLMN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying the call transfer observation parameters . . . . . . . . . . . . . . . .
Setting and interrogating the fraud handling parameters. . . . . . . . . . . .
Managing VLRU-UTPFIL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Id:0900d805808d3ca9
27
27
27
27
28
28
29
31
31
31
31
32
32
Id:0900d805808d3ca9
DN985071
Issue 8-0-0
Summary of changes
Summary of changes
Changes made between issues 8-0-0 and 7-0-1
Section Recommendations for VLR parameter values has been updated. The following
VLR parameters have been added to the document:
SECURITY KEY LIFETIME 2G, SECURITY KEY LIFETIME 3G, FORCE AUTHENTICATION WHEN SGSAP PAGE RESPONSE IS FROM DIFFERENT LA, AMR WB SUBSCRIPTION, 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, RDELAYCLO
Section Recommendations for PLMN parameter values have been updated. The following PLMN parameters have been added to the document:
NO RESPONSE EFFECT, CAMEL DATA NEGOTIATION TABLE, SUPPORT OF LOCALISED 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 ORIGINATED 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 PRIORITIES, 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, LOITERING 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 LIMITATION, REGIONAL ROAMING, ZONE CODES, EXACT MS CATEGORY USAGE,
TRIGGER SM TO NTMS, CS/PS COORDINATION REQUIRED, PRE-PAGING SUPPORTED, 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-
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 60 and 52
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
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.
The printout of the MXO command has been updated due to the changes in the execution
The printout of the MXP command has been updated due to the changes in the execution
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)
Id:0900d805808d42ef
DN985071
Issue 8-0-0
Parameter management in EIR, HLR, and VLR
1 Parameter management in EIR, HLR, and VLR

1.1
EIR parameters
The 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.
The dependency is checked only when an IMEI is entered on a list. This means that after
you 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, necessarily agree with the current list dependencies because they have been possibly inserted
under 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 database.
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:
DN985071
Issue 8-0-0
fixed type parameters (MJ command group)
Id:0900d805808d42f1
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 subscribers 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 <modification of
subscriber category> 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 00000000
SS 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.
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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 PLMNspecific 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 parameter 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:
DN985071
Issue 8-0-0
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
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 Handling, DF command group. These parameters are used when more complex functionalities 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

To display the current parameter values, use the MXO command.
The execution printout of the MXO command is:
1)
2)
3)
4)
5)
6)
7)
7)
8)
9)
10
VLR PARAMETERS
TMSI:
USED
IMPLICIT IMSI DETACH:
USED
AUTHENTICATION:
USED
AUTHENT RETRY:
USED
TMSI AUTHENT RETRY:
NOT USED
AUTH RETRY WITH NEW TRIPLET: NOT USED
SECURITY KEY LIFETIME 2G:
360 MIN
SECURITY KEY LIFETIME 3G:
360 MIN
EMERGENCY CALL:
AUTHENT NOT USED
ALLOW CCBS WHEN UDUB:
YES
ALLOW CCBS WHEN CFB ACTIVE: NO
Id:0900d805808d42f1
IMEI CHECKING NOT USED
DN985071
Issue 8-0-0
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:
EMLPP
AMR WB SUBSCRIPTION:
NO
DN985071
Issue 8-0-0
Id:0900d805808d42f1
11
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:
USED
30)
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
12
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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 update
interval can be BTS-specific, but normally the same value is used in the whole network.
DN985071
Issue 8-0-0
Id:0900d805808d42f1
13
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 successful 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 authentication frequency counters in PLMN parameters. The lower the security key lifetime is, the
more 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 Ciphering, 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 emergency calls done without a SIM card, which means that these parameter values do not
have an effect on those calls.
If the parameters are taken into use, international emergency calls are successful independently 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 UNAVAILABLE 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 the
network.
14
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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, see
Feature 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: Subscriber Fraud Detection and Limitation, Feature Description.
14) FORCE AUTHENTICATION WHEN SGSAP PAGE RESPONSE IS FROM DIFFERENT 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,
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 the
VLR 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.
DN985071
Issue 8-0-0
Id:0900d805808d42f1
15
For more information on the INTER PLMN LU DETECTION, ROAMING STATUS, MS

CLASSMARK parameters and this parameter as well, see Feature 1433: Terminal Management Support, Feature Description.
19) TRIPLETS
Set 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 procedures. 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 INFORMATION to Y (=allowed). With these parameters you can transfer the network name, universal 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 or
its 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 'LOCATION AREA NOT ALLOWED'.
16
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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: Prepaging, 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 SendIdentification is received. That is, it controls the time length the VLR waits between receiving MAP
SendIdentification 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

To display the current PLMN-specific parameter values, use the MXP command.
The following execution printout of the MXP command includes the recommended
parameter 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)
DN985071
Issue 8-0-0
Id:0900d805808d42f1
17
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 1C01
ZONE 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:
ALL
ZC 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/4: NOT ALLOWED
A5/5: NOT ALLOWED
A5/7: NOT ALLOWED
18
Id:0900d805808d42f1
A5/3: ALLOWED
A5/6: NOT ALLOWED
DN985071
Issue 8-0-0
-------------------------------------------------------------------------------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:
MO SMS:
MT LOC REQ:
CS FALLBACK:
67) AUTHENTICATION
LOC UP NEW VIS:
IMSI ATTACH:
MT CALL:
MT USSD:
CS FALLBACK:
1
0
0
0
PER UP:
MT CALL:
MT USSD:
0
0
0
1
1
10
0
0
LOC UP:
MO CALL:
MT SMS:
SS OPER:
0
10
0
0
MO CALL:
MT SMS:
SS OPER:
0
0
0
PER UP:
MO SMS:
MT LOC REQ:
IMSI ACCESS:
0
1
0
0
68) IMEI CHECKING

LOC UP NEW VIS:
1
LOC UP:
5
PER UP:
1
IMSI ATTACH:
1
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
-------------------------------------------------------------------------------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:
MIDDLEEARTH
SHORT NETWORK NAME:
MIDEARTH
DN985071
Issue 8-0-0
Id:0900d805808d42f1
19
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
2
150
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
--------------------------------------------------------------------------------
20
Id:0900d805808d42f1
DN985071
Issue 8-0-0

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 connection 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.
DN985071
Issue 8-0-0
Id:0900d805808d42f1
21
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 clear
code 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: Subscriber 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
Calling Name Presentation Alternatives, Feature Description.
22
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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 AnyTimeInterrogation Request after receiving the MAP CancelLocation Response (or MAP SendIdentification 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,
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
DN985071
Issue 8-0-0
Id:0900d805808d42f1
23
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 equipments 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: Intersystem Handover and UMTS Changes, Feature Description.
24
Id:0900d805808d42f1
DN985071
Issue 8-0-0
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 connection 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 supported 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
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
DN985071
Issue 8-0-0
Id:0900d805808d42f1
25

PLMN-Specific SS-Code Support in MSS/VLR, Feature Description.
For more information, see section Managing VLR and PLMN parameters.
26
Id:0900d805808d42f1
DN985071
Issue 8-0-0
Managing HLR and PLMN parameters
2 Managing HLR and PLMN parameters

You can display and change the fixed type HLR parameters and PLMN-specific parameters 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
1
List PLMN names, addresses, and indices.

ZMJL;
Add a PLMN.
Use the MJA command to add a PLMN.
For further information, see section HLR parameters.
2.2
Modifying PLMN parameters

You 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
1
Check the existing PLMN names, addresses, and indices.

ZMJL;
Display the parameter values.

Use the MJP command.
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 into
a certain PLMN. The modifications on subscriber data affected by this command are
DN985071
Issue 8-0-0
Id:0900d805808d42f3
27
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 supplementary services at the same time, but only one service of each at a time.
Steps
1
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.
Do not use group codes unless a list of all basic service codes belonging to that
group 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 determines 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
1
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 parameter 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 <number of insert attempts> and <interval
between insert attempts> 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
28
Id:0900d805808d42f3
DN985071
Issue 8-0-0
this case the <number of deletion attempts> and <interval between

deletion attempts> 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 call
forwarding functions, IN services, and SMS functions.
Steps
1
Display the current HLR parameters.

ZMJO;
Modify HLR parameters.

Modify the HLR parameters using the MJM command.
For more information, see section HLR parameters.
2.6
Starting GSM restoration

You 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 different 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.
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
1
Start GSM restoration.

Use the MJG command to start GSM restoration.
DN985071
Issue 8-0-0
Id:0900d805808d42f3
29
Modifying subscriber categories
3 Modifying subscriber categories

With this parameter you can change the value of the subscriber category when a subscriber 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
Usually both of these operations are ON at the same time. Two records are needed for
UTP_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:
XX
0B
Priority subscriber
0F
Payphone
0D
Testphone
04
Personal number service
F0
Ordinary no charge
F4
Priority no charge
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
1
Display records on the terminal.

Use the DFD command.
Modify records.
Use the DFS command; the system generates questions. For information on how to
answer, see the example below.
30
Id:0900d80580821af5
DN985071
Issue 8-0-0
4 Managing VLR and PLMN parameters

You can modify VLR, PLMN, or call transfer observation parameters, display the parameter 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
1
Display the current VLR parameter values.

ZMXO;
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
1
List PLMN names and indices.

ZMXL;
The command lists both the PLMN names and their indices.
Add a new PLMN.

To add a new PLMN use the MXA command. The new PLMN has the default parameter 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
1
Display the current parameter values of a PLMN.

Use the MXP command; the PLMN is identified with a name or an index.
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
DN985071
Issue 8-0-0
The command line length of the command is limited. Because this command
includes a lot of parameters, you cannot modify all the parameter values at once.
Note also that these parameters have no default values.
Id:0900d805808d42f5
31
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
1
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
1
Set and interrogate fraud handling parameters.

Set the fraud reporting parameters by giving the number and the value of the parameters 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 Management in NSS, and Security Management in AUC, EIR, and VLR.
32
Id:0900d805808d42f5
DN985071
Issue 8-0-0
Managing VLRU-UTPFIL parameters
5 Managing VLRU-UTPFIL parameters

You 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
1
Search for the index of active CM.

Search the index with the USI command, where x= index of active CM.
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
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
DN985071
Issue 8-0-0
Wait at least 1 minute until the process reads the new information from the UTPFIL.
Id:0900d80580821af9
33

Parameter Management in EIR, HLR, and VLR

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Parameter Management in EIR, HLR, and VLR

Transféré par

Droits d'auteur :

Formats disponibles

Open Mobile Softswitch, Rel.