Zxwn-cs Nitz Feature Guide

For Internal Use Only▲

Technical Document

Document Title: ZXWN-CS NITZ Feature Guide

Author: Wang Wenjun, Mao Rong

ZTE Corporation

ZTE Confidential Proprietary

NITZ Feature Guide For Internal Use Only▲

Table of Contents

1 Preface.................................................................................................................................................................5

2 Terminology and Abbreviations.........................................................................................................................5

2.1 Terminology...............................................................................................................................................5

2.2 Abbreviations.............................................................................................................................................5

3 Function Description..........................................................................................................................................5

3.1 Function.....................................................................................................................................................5

3.2 Reference Standards and Protocols............................................................................................................6

3.3 Description of Networking Mode and Application Scenario.....................................................................6

3.3.1 Application Scenario 6

3.3.2 Benefits 6

3.3.3 Use Restriction 7

3.4 Function Principle......................................................................................................................................7

3.4.1 Service Flow 7

3.4.2 Change of External Interface 8

3.4.3 Function Principle 9

4 Function Interaction.........................................................................................................................................11

4.1 Interaction with the Virtual MSC Server..................................................................................................11

4.2 Interaction with Original Implementation................................................................................................11

4.3 Compatible with Original Implementation in Engineering Upgrade........................................................11

5 Configuration Requirements...........................................................................................................................12

6 Configuration Description................................................................................................................................12

6.1 Configuration Preconditions....................................................................................................................12

6.2 Correlation Modification.........................................................................................................................12

ZTE Confidential Proprietary 2


6.3 New Configuration Item..........................................................................................................................15

6.4 Data Configurations under Various Networking Conditions....................................................................15

7 O&M Description.............................................................................................................................................23

7.1 Security Variables....................................................................................................................................23

7.2 Timer........................................................................................................................................................23

7.3 Performance Statistics..............................................................................................................................23

7.4 Alarm/Notice............................................................................................................................................24

7.5 Failure Observation..................................................................................................................................24

7.6 Service Observation/Dynamic Management............................................................................................24

7.7 Billing......................................................................................................................................................24

7.8 Maintenance Commands and Operations.................................................................................................25

7.9 Requirements on Other NEs....................................................................................................................25

7.10 Precautions.............................................................................................................................................25

7.11 FAQs......................................................................................................................................................25

8 Function Verification Cases................................................................................................................................25



Revision Record

Prepared by/

Changed byDate Version

Description

(Main Points)

Wang Wenjun 2009-2-5 V1.0

Note 1: Fill in this form for each change after this document is finalized.

Note 2: Fill None in the Reason and Description columns for files archived for the first time.



1 Preface

This document describes the overview, networking application scenarios, principle, function

interaction, and data configurations of NITZ function for pre-sales and after-sales personnel.

This document is the most important reference for pre-sales and after-sales personnel to

promote this function to operators.

2 Terminology and Abbreviations

2.1 Terminology

None

2.2 Abbreviations

3GPP: 3rd Generation Partnership Project

MSCS: Mobile Switching Centre Server

NITZ: Network Identity and Timezone

LTZ: Local Time Zone

3 Function Description

3.1 Function

The NITZ function is originated by the VLR to inform the user of the following information:

Network identity (NI)

Daylight saving time (DST)

Time and time zone



This function can deliver different NITZ indications based on different virtual MSC and

IMSI number segments. For example, if there is more than one (virtual) operator in the same

network and the (virtual) operators have different NIs, this function is needed. NI display

supports blank space. Blank space can be in the front, middle, or end of the NI. NI can even

be just a blank space. Also, MSC Server supports NI and TZ information to control sending

scenarios separately. Sending scenarios for NI and TZ are the same, including no sending,

sending when the terminal registers to the network for the first time, sending when the

terminal moves to another time zone, sending when the network changes the time zone,

sending when the network changes the NI, and sending when the terminal originates the

access in the network. The control policy is as follows:

Virtual

MSC

Index

IMSI

Range

NI

Sending

Scenario

TZ

Sending

Scenario

Long NI

of the

Network

Short NI

of the

Network

Whether to

Inform the

User of the

Network

Time

Whether to

Prefix the

Abbreviation of

Country Name to

the NI

…..

IMSI number segment analysis supports the co-existence of both long and short numbers,

and long numbers prevail. If the IMSI field is set to All FF, it indicates that all IMSI number

segments should be fully matched.

3.2 Reference Standards and Protocols

[1] 3GPP TS 22.042 V6.0.0

[1] 3GPP TS 23.038 V6.1.0

[3] 3GPP TS 24.008 V6.6.0

[2] 3GPP TS 29.018 V6.4.0

3.3 Description of Networking Mode and Application Scenario

3.3.1 Application Scenario

No special requirements.

3.3.2 Benefits

For operators: where there is more than one (virtual) operator in the same network and

the (virtual) operators have different NIs, this function can provide users with proper



NIs based on their IMSIs. When the operator is trans-regional, this function can provide

users with proper NIs based on different areas.

For end users: it brings convenience to users by providing them with proper NI and

time information.

3.3.3 Use Restriction

Only one time zone is supported within one physical MSC Server.

As actual applications prove, time zone should be configured in network establishment

and cannot be changed in running. If it is changed in running time, many issues (such

as billing) are involved. Therefore, for the time zone change of the network, this

function processes only the handovers between DST and winter time system.

3.4 Function Principle

3.4.1 Service Flow

3.4.1.1 User Location Update

Figure 1 Location Update Flow

1. The MS sends the LocationUpdate_Request message to the MSCS.



The MSCS completes the authentication and then originates the location update request

to the HLR.

2. The HLR inserts the user data to the MSCS and then sends the MSCS the message

indicating that the location update is complete.

3. After receiving UpdateLocation_Cnf, the MSCS processes the NITZ function if user

access is allowed. When NITZ is required to be sent to the MS, the MSCS sends MM

INFORMATION to the MS. Then the MSC sends the location update acceptance

message to the MS.

Note: If the MS does not support the MM INFORMAITON message, the message will be neglected, and the

MM STATUS will be returned to the MSCS with the cause value #97. After receiving MM STATUS, the

MSCS discards the message without processing.

3.4.1.2 Call/SMS/USSD/Supplementary Service/ LCS Access Flow

Figure 1 Call/SMS/USSD/Supplementary Service/ LCS Access Flow

1. The MS sends CmSrvReq requesting for MMS connection. The MSCS processes the

access process.

2. When the access flow is complete, the MSCS processes the NITZ function. If NITZ is

required to be sent to the MS, the MSCS sends MM INFORMATION to the MS. Then

the MSCS sends CmSrvAcc to the MS.

Note: if the MS does not support the MM INFORMAITON message, the message will be neglected, and the

MM STATUS will be returned to the MSCS with the cause value #97. After receiving MM STATUS, the

MSCS discards the message without processing.



3.4.2 Change of External Interface

None.

3.4.3 Function Principle

When the user changes the NI or time zone information, the data is synchronized to the OMP

of the MSC Server and is delivered by the OMP to the CMP where the VLR is located. In

the CMP, the VLR analyzes whether the condition for triggering the NITZ is satisfied when

the user accesses the network. If satisfied, the VLR will send MM INFORMATION to the

user. During the sending, the VLR needs to determine whether to use the Iu/A or Gs

interface according to the user’s access. Therefore, the VLR is in the core position of the

NITZ function.

Support multiple time zones or not

When the user LTZ changes, the NITZ function can send MM INFORMATION to the UE.

But due to the current function limitation, only one time zone is supported within one

physical MSC Server; therefore, the NTZ checks whether the LTZ changes only when the

inter-office location update occurs, and then sends the corresponding MM INFORMATION.

Similarly, for the dual homing of mutual standby and N+1, the multiple standby office

locations should be in the same time zone.

User Location Update/Call/SMS/USSD/Supplementary Service/ LCS Access Flow

1. The user originates access for location update/call/SMS/USSD/supplementary

service/LCS service.

2. The VLR obtains the virtual MSCID based on the user’s LAI. The VLR then matches

the NITZ configuration based on the virtual MSCID and IMSI. The IMSI supports the

co-existence of both long and short numbers, and the long number should prevail.

Matching process: if the IMSI number segment matching is failed in the virtual MSC

configuration (long and short numbers are mismatching), the virtual MSC index is set

to 0 and global matching is configured based on the NITZ of the IMSI; if the matching

is still failed, the user IMSI field is be set to all FF according to the virtual MSC index

in the input parameters, and the default NITZ configuration of the virtual MSC is

obtained through matching; if the matching is still failed, the virtual MSC=0, IMSI

field is All-FF in the default global configuration; if the NITZ still cannot be obtained,

the MSC Server does not send NITZ.



3. The VLR obtains the NITZ assignment policy, in which the sending scenarios of NI

and TZ can be set respectively. When it is required to send the TZ, to prevent the wrong

MSC Server time from interfering with the terminal time, set whether to inform the

user of the network time in the NITZ function. If yes, the MSC Server fills in the Net

Time And Zone field; otherwise, the MSC Server fills in the Net Time Zone field.

4. If the VLR determines that it is required to send NITZ to the UE/MS based on the

scenario in the assignment policy, the VLR continues to determine whether it is

combined location update. If yes, the VLR sends MM INFORMATION to the UE/MS

via the Gs interface through the SGSN. Otherwise, the VLR sends MM

INFORMATION to the UE/MS via the Iu/A interface.

5. If the UE/MS does not support MM INFORMAITON, the message will be neglected,

and the MM STATUS will be returned to the core network with the cause value #97.

6. After receiving MM STATUS, the MSC Server discards the message without

processing.

The network changes its time zone

As actual applications prove, time zone should be configured in network

establishment and cannot be changed in running. If it is changed in running

time, many issues (such as billing) are involved. Therefore, this function

processes only the handovers between DST and winter time system.

1. The maintenance personnel configure whether to use the DST, DST effective time, and

time offset in the global data configuration of MSC Server. The offset time can be set to

+1 hour (Note 1). The maintenance personnel then synchronize the data.

2. If the condition for user access process is satisfied and the TZ sending scenario is set to

“sending when the network time zone changes”, the MM information message is sent to

the user when DST switch is performed between the last access time and this access

time.

Note 1: Although +0.5 is applied in some areas, the 3GPP protocol does not support +0. Therefore, this

offset cannot be sent to the UE.

The network changes its NI.

1. The maintenance personnel change the NI configured in the NITZ configuration,

including long NI or long identity coding method of the local network, or short NI or



short identity coding method of the local network. The maintenance personnel then

synchronize the data.

2. The VLR marks that all users of the virtual MSCID may be informed of NITZ in the

network access. Moreover, the MSC Server records the change time of the

corresponding virtual MSCID NI.

3. If the user who meets the access condition accesses the network for the first time and

the NI sending scenario is set to “sending when the network changes the NI”, the VLR

sends MM INFORMATION to the UE/MS.

4. If the VLR that meets the condition exists in the user access network and the NI

sending scenario is set to “sending when the network changes the NI”, the MM

information message is sent to the user only when the user access time is before the NI

change time. After the MM information message is sent to the user, the MSC Server

reaches the purpose of sending only one MM information message to the user by

changing the user access time.

4 Function Interaction

4.1 Interaction with the Virtual MSC Server

The virtual MSC Server is one of the multiple virtual MSC Servers within the physical MSC

Server. Each virtual MSC Server has its unique service feature and routing method. In the

NITZ function, each virtual MSC Server is configured with a different NITZ property, and

different NIs are allowed. However, the time zone and DST configurations of all virtual

MSC Servers should be the same.

4.2 Interaction with Original Implementation

This function expands and fully integrates with the original implementation. This function

does not conflict with the original Implementation.

4.3 Compatible with Original Implementation in Engineering Upgrade

The NITZ optimization function adds the IMSI parameter in the NITZ configuration. In the

upgrade, the IMSI field in the original record sheet is set to all FF, and default NITZ



configurations of virtual MSCs are reserved. The following describes the methods for

upgrading the configuration sheets.

NITZ

Command Name

\\Service Configuration\NITZ Configuration\NITZ

Command Description

Add the IMSI parameter;

Change the original NITZ Message Sending Scenario to NI Sending Scenario;

Add TZ Sending Scenario. Its value is the same as in NI Sending Scenario;

Change Whether to Inform the User of Network Time in NITZ Function to Whether to Inform the

User of Network Time in TZ Delivery.

Parameter Description

IMSI is all-FFF by default, indicating that all IMSI number segments are fully matched.

Upgrade Description

After the upgrade, the IMSI field is set to the default value.

The NI Sending Scenario value is the same as that of the original NITZ Message Sending Scenario.

The TZ Sending Scenario value is the same as that of the original NITZ Message Sending Scenario.

5 Configuration Requirements

This function supports 255 IMSI number segments.

6 Configuration Description

6.1 Configuration Preconditions

Before configuring the function: complete the following configurations:

1. Location update data configuration

2. Data configuration of services, such as call, SMS, USSD, independent call, and LCS.



6.2 Correlation Modification

Configuration item 1: NITZ. In the NITZ configuration under the service configuration,

NITZ Message Sending Scenario is changed to NI Sending Scenario; TZ Sending

Scenario is added; Whether to Inform the User of Network Time in NITZ Function is

changed to Whether to Inform the User of Network Time in TZ Delivery; IMSI Prefix is

added, and NITZ sending scenario can be matched based on the IMSI prefix. Other

configuration items are not changed.

Changed

Parameter NameOriginal Meaning Current Meaning Impact

NI Sending

Scenario

It indicates that the

NITZ configures the

sending scenario at

the same.

It indicates that the NITZ configures NI

sending scenario separately. There are five

scenarios: when the network changes its

time zone, when the terminal moves to

another time zone, when the network

changes its N, when the terminal registers

to the network for the first time, and the

terminal originates the access process in the

network.

TZ Sending

Scenario

It indicates that the

NITZ configures the

sending scenario at

the same.

It indicates that the NITZ configures TZ

sending scenario separately. There are five

scenarios: when the network changes its

time zone, when the terminal moves to

another time zone; when the network

changes its NI, when the terminal registers

to the network for the first time, and the

terminal originates the access process in the

network.

Whether to Inform

the User of

Network Time in

TZ Delivery

It indicates whether to

inform the user of

network time in NITZ

function.

It indicates whether to inform the user of

network time in TZ delivery.

IMSI Prefix NoneNI or TZ sending scenario is matched based

on the IMSI prefix.

Other configuration items:



Parameter Name MeaningValue

Range

Filling

Description

(Recommended

Value)

ImpactRelated

Protocol

Virtual MSC Index

It is used to configure the

specified virtual MSC

index.

0-65535 0NITZ

configuration

Whether to Prefix

the Abbreviation of

Country Name to

the NI

It configures whether to

prefix the NI with the

abbreviation of country

name.

Yes or No NoNITZ

configuration

Long NI of the

NetworkIt configures the long NI.

0 - 208

characters None

NITZ

configuration

Long ID Coding

Method

It configures the coding

method of long ID.

“BIT7” or

“UCS2”None

NITZ

configuration

Short ID of the

NetworkIt configures the short NI.

0 - 208

characters None

NITZ

configuration

Short ID Coding

Method

It configures the coding

method of short ID.

“BIT7” or

“UCS2”None

NITZ

configuration

Configuration item 2: time zone information of global configuration. It is under the global

configuration of the equipment configuration. It is used to configure the time zone of this

office.

Parameter Name Meaning Value Range

Filling

Description

(Recommended

Value)

ImpactRelated

Protocol

Time Zone

It indicates the

related time zone

of this office.

-12-+131 None

Time zone of

global

configuration

Configuration item 3: Set the DST information. It is under the global configuration of the

equipment configuration. It is used to configure DST start time, end time, and step size.

1




Filling

Description

(Recommended

Value)

ImpactRelated

Protocol

DST Start and End

Time

It configures DST

start and end time.

State date, start

time, end date, and

end time

The date format is

MM-DD and the

time format is

HH:MM.

DST

information

setting

DST Step SizeIt configures DST

step size.0 or 1

0: disable DST

1: enable DST.

The offset time is

+1 hour.

DST

information

setting

Configuration item 4: multiple time zones configuration. It is in the NTIZ function

configuration of the service configuration. It is used to configure the time zone of an

adjacent office.


Filling

Description

(Recommended

Value)

ImpactRelated

Protocol

MSC Number of

Adjacent Office

It indicates the

MSC number of an

adjacent office.

None None

Multiple

time zones

configuration

Time Zone

It indicates the time

zone information of

the corresponding

adjacent office.

GMT-00:00 -

GMT+00:15None

Multiple

time zones

configuration

6.3 New Configuration Item

None

6.4 Data Configurations under Various Networking Conditions

The network management version in the captured figures here is CSV3.07.40.P3.B3.

1. The NI and TZ sending scenario is that the terminal registers to the network for the first

time.



1) Check that there is no record of the user in the R-MS sheet.

2) Under the MSCS\Service Configuration\NITZ Function Configuration, set the

NITZ sending scenario to the scenario in which the terminal registers with the

network for the first time.

ADD

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="REGIST",SCENE

TZ="REGIST",SENDTM=YES,ADDCNY=YES,LNAME="operator",LNAMEC

ODE=BIT7,SNAME="operator",SNAMECODE=BIT7;

3) Select the content to be sent in the NITZ configuration.

4) The user originates the location update or access process. Check whether the

signaling tracking MM INFO message is consistent with the configuration.



2. The NI and TZ sending scenario is that the terminal moves to another time zone.

1) Under the MSCS\service configuration\NITZ function configuration, set the NITZ

sending scenario to the scenario in which the terminal moves to another time zone.

ADD

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="ENTERNEWLTZ

",SCENETZ="ENTERNEWLTZ",SENDTM=NO,ADDCNY=YES,LNAME="ope

rator",LNAMECODE=BIT7,SNAME="operator",SNAMECODE=BIT7;



2) Under the MSCS\Equipment Configuration\Global Configuration, configure the

time zone of this office.

SET TZ:TZ=GMT+08:00;

3) This service needs the user to update VLR location. In the MSCS\Access

Configuration\Location Area Configuration, configure the location area

information of the original location zone, which should associate with the MSC

Code of the adjacent office.

ADD

LAI:LAC="0146",ID=146,NAME="146BSC",MCC="460",MNC="02",MSC="86

13903023",VLR="8613903023",LOCNUM="01",ECCIDX=0,BSC="0",RNC="0"

,TPDAS=0,BELONG=NO_MSC,WDMID=0;

4) Under the MSCS\Service Configuration\NITZ Function Configuration, configure

the time zone of the adjacent office.



ADD TIMEDIFF:MSC="8613903023",TIMEZONE=GMT+01:00;

5) The user originates the VLR location update. Check whether the signaling tracking

MM INFO message is consistent with the configuration.

3. The NI and TZ sending scenario is the one in which the network changes its time zone.


sending scenario to the scenario in which the network changes its time zone.



ADD

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="DSTCHG",SCEN

ETZ="DSTCHG",SENDTM=YES,ADDCNY=YES,LNAME="operator",LNAM

ECODE=BIT7,SNAME="operator",SNAMECODE=BIT7;

2) Under the MSCS\Dev Configuration\Global Data Configuration, configure DST

start time, end time, and step size. Note: The DST start time and end time cannot

be on the same day.

SET DAYLIGHTSAVE:DAYLIGHTSAVE="07-03"-"11:38"-"07-

04"-"18:00",OFFSET=1;

3) The user originates the location update or access process. Ensure that the time

when the user originates the location update is after the DST start or end time. If

the DST period is set to 1, when the DST is switched, confirm that the foreground

time changes by 1 hour and check whether the signaling tracking MM INFO

message is consistent with the configuration.



4. The NI and TZ sending scenario is the one in which the network changes its NI.


sending scenario to the scenario in which the network changes its NI.

ADD

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="NMCHG",SCENE

TZ="NMCHG",SENDTM=YES,ADDCNY=YES,LNAME="operator",LNAMEC

ODE=BIT7,SNAME="operator",SNAMECODE=BIT7;



2) Change the NI or coding method, or set the NI length to null. The user then

originates the location update or access process. Check whether the signaling

tracking MM INFO message is consistent with the configuration.

SET

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="NMCHG",SCEN

ETZ="NMCHG",LNAME="cmcc",LNAMECODE=BIT7,SNAME="cmcc",SNA

MECODE=BIT7;

This configuration sets NI to cmcc.



5. The NI and TZ sending scenario is the one in which the terminal accesses the network.

1) Under the MSCS\service configuration\NITZ function configuration, configure the

NITZ sending scenario to the scenario that the terminal accesses the network.

ADD

NITZ:VMSCIDX=0,IMSI="FFFFFFFFFFFFFFF",SCENENI="UEACCESS",SC

ENETZ="UEACCESS",SENDTM=YES,ADDCNY=YES,LNAME="operator",L

NAMECODE=BIT7,SNAME="operator",SNAMECODE=BIT7;

2) The user originates the location update or access process. Check whether the

signaling tracking MM INFO message is consistent with the configuration.



7 O&M Description

7.1 Security Variables

None

7.2 Timer

None

7.3 Performance Statistics

Serial No. 42002

Measurement type Related information of NITZ measurement

Measurement item NITZ Measurement



Abbreviation of the

measurement item

(database field name)

CN_P_MSCSNITZDATA

DescriptionMeasure respectively the total times and failed times of sending the Mm info

through the BBS and RNC in the public domain.

Trigger point None

Object of statistics None

Collection method None

Accumulation method None

Unit None

Remarks None

Serial No. 42003

Measurement type Related information of the virtual MSC NITZ measurement

Measurement item Virtual NITZ Measurement

Abbreviation of the

Measurement Item

(database field name)

CN_P_MSCSVNITZDATA

DescriptionMeasure respectively the total times and failed times of sending the Mm info

through the BBS and RNC in the virtual MSCs.

Trigger point None

Object of Statistics None

Collection method None

Accumulation method None

Unit None

Remarks None

7.4 Alarm/Notice

None

7.5 Failure Observation

None

7.6 Service Observation/Dynamic Management

None



7.7 Billing

None

7.8 Maintenance Commands and Operations

None

7.9 Requirements on Other NEs

It requires mobile phones to support this function.

7.10 Precautions

1. The time in the Signaling Tracking Time Zone and Time field is in GMT; the signaling

tracking message is printed after the change of the time zone.

2. In the location update or access process, if the MM info message is sent with the

obtained IMEI or CheckIMEI closed or encrypted, the service model will release the

corresponding process data area; if the mobile phone receives the message

unsuccessfully and responds with the network, the network does not process this

problem and this situation is not counted as failed sending.

3. NI and TZ scenarios can be set respectively.

7.11 FAQs

None

8 Function Verification Cases

Preconditions

1. The system runs normally and all office directions can be reached normally.

2. The NI and time zone data are set.

3. Call loss and signaling tracking are enabled.

Test procedure

1. The NI and TZ function is set to enable When the terminal accesses the

network, and set the sending scenarios based on the actual condition.

2. The terminal originates the location update (including authentication,

encryption, and TMSI reallocation process).



Expected results

1. The location update is successful without any call loss.

2. The signaling tracking can decode correctly the MM Information message, in

which the parameter is the same as the configuration.


Documents

Zxwn-cs Nitz Feature Guide