You are on page 1of 22

7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.

doc

Mobility Management Flow in

CS domain

Course Objectives:

· ZXWN MSC Server (V3.0) Technical Manual

· ZXWN MGW (V3.0) Media Gateway Technical Manual

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 1/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Contents

1 Mobility Management Services..................................................................................................................1

1.1 Introduction.............................................................................................................................................1

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 2/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

1 Mobility Management Services

 Key points

· Composition of mobility management services, and service process.

1.1 Introduction

1.1.1 Location of MM Sub-layer in the Protocol Stack and Its Function

Fig. 1.1-1 Location of MM in the Protocol Stack 

As shown in Fig. 1.1 -1, the mobility management sub-layer (MM) is the function
 provided by the terminal and network to support user mobility. It belongs to the radio
network application layer, and supports transparent transmission in the radio network 

system (RNS).
The MM sub-layer implements the mobility and roaming of UEs in the PLMN, such as
location update, TMSI re-allocation, authentication and security management. In
addition, the MM sub-layer provides connection management service for the upper 
connection management (CM) sub-layer, that is, when the CM sub-layer needs to
communicate with its peer entity, the signaling connection set up by the MM sub-layer 
is required.

The MM process can be implemented only when the RRC connection between the UE

and the network is established, and the RRC connection shall be initiated by the MM

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 3/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

sub-layer.

In the ZXWN MSCS, mobility management services involve the location update unit,
security management unit, user data management unit and error recovery processing
unit, as shown in Fig. 1.1 -2.

Service processing subsystem

M Location update unit


 o
 b 
l  
i  
 t  
 y
m
Security management unit
 a 
n
 a 
 g
 e 
m
 e 
n
 t  
 s 
 e 
r  User data management unit
 v
i  
 c 
 e 

Error recovery processing unit

Fig. 1.1-2 Composition of Mobility Management Services

The following describes the specific service process.

1.1.2 Location Update

Because of the mobility of mobile users, the locations of mobile users frequently
change. To easily obtain location information about mobile users in processing call
services, SMS and supplementary services and improve radio resource utilization
efficiency, the system registers the location information about mobile users in the
network and reports the activation status of mobile users, that is, to initiate the location
update service.

The location update service involves:

1. Common location update: Registers new location information to the network.


The common location update is divided into VLR location update and combined
location update.

2. Periodical location update: Informs the network of the availability of mobile

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 4/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

users periodically.

3. IMSI (GPRS) attach/detach: Indicates the attach/detach status of IMSI users.


Different location updates are identified by the location update class information in the
location update request. Their processes are basically the same.

1.1.2.1 Common Location Update

1. VLR location update

When the roaming location area of a mobile user changes, the MS initiates the
location update operation. If the original location area (LA) and the new LA

 belong to the same MSCS/VLR, the data can be modified easily in the VLR. If 
they do not belong to the same MSCS/VLR, the new MSCS/VLR requests the
data of the MS from the HLR. The HLR sends the information that the new
MSCS/VLR requests and notifies the original MSCS/VLR to delete the location
information and register the MS in the new MSCS/VLR. When the MS updates
the location to the new MSCS/VLR with the TMSI and PLAI which is not in the
new MSCS/VLR, the new MSCS/VLR can calculate the previous VLR (PVLR)
address according to the TMSI and PLAI, send a discrimination request to the
PVLR, and request the IMSI of the MS and unallocated authentication
 parameter set from the PVLR.

The specific process varies with the difference between the location information
reported by the MS and that registered in the VLR and HLR. When the new
location area registered by the MS is not in the original MSCS/VLR, or the
location area information about the MS is undetermined, it is required to initiate
the location update to the HLR. Otherwise, there is no need to initiate the
location update to the HLR. The following describes these two cases.

· Process with initiating location update to the HLR 

Fig. 1.1 -3 shows the process without initiating location update to the HLR.

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 5/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 6/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

 _MODE_CMD which is used to set the encryption and integrity protection


algorithm and key at the user side and network side. After receiving this
message, the MS returns the encryption mode completion message.

5:(TMSI_Reallocation_CMD)

If the user subscribes the relevant encryption service, the MSCS/VLR initiates
this operation to allocate new TMSI number for the user.

6: (Update_Location_Area_ack)

After the MSCS/VLR finishes processing the location update initiated by the
MS, it returns an acknowledgement message to the MS.

7: (TMSI_Reallocation_COM)

If the new TMSI of the user is set successfully, the result is returned to the
MSCS/VLR.

8: (IU_REL_CMD/IU_REL_COMPLETE)

After receiving the new TMSI setting completion message, the MSCS/VLR 
sends a clear command to the user. The MS returns an acknowledgement
message. The processing ends.

· Process with initiating location update to the HLR 

Fig. 1.1 -4 shows the process with initiating location update to the HLR.

MS MSCS/VLR  HLR  PVLR 

Update_Location_Area_REQ
Step 1
Update_Location
Step2
Cancel_Location
Step3
Cancel_Location_ack 
Step 4
Activate_Trace_Mode

Activate_Trace_Mode_ack  Step 5

Insert_Subscriber_Data
Step6
Insert_Subscriber_Data_ack 
Step 7
Forward_Check_SS_Indication
Step8
Update_Location_ack 
Step 9
Update_Location_Area_ack 
Step10

Fig. 1.1-4 Process with Initiating Location Update to the HLR 

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 7/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

Process description:

1: (Update_Location_Area_REQ)
The MS initiates a location update request to the MSCS/VLR. The MSCS/VLR 
receives the location update request sent by the MS, checks the validity of user 
data, and judges the location update type to determine the subsequent
operations.

2: (Update_Location)

 Note: The MSCS/VLR determines whether to initiate a location update request


to the HLR according to some conditions. In general, this operation is performed
in the following cases:

· The user powers on the mobile phone for the first time.

· The user roams outside the MSCS/VLR system.

· The user data is incorrect or inconsistent with that in the HLR due to the VLR 
restartup or specific reasons.

3: (Cancel_Location )

The MSCS/VLR receives the location deletion request from the HLR, deletes
the record from user data according to the IMSI in the parameters, and releases
the TMSI of the user.

4: (Cancel_Location_ack)

 No matter whether the user registers in the VLR, the MSCS/VLR returns the
location deletion acknowledgement to the HLR, and closes the session.

5: (Activate_Trace_Mode/Activate_Trace_Mode_ack)

The MSCS/VLR receives the Activate_Trace_Mode request from the HLR, and
returns the Activate_Trace_Mode acknowledgement to the HLR directly. The
MSCS sets user tracing flag in the related data area and traces the user.

6: (Insert_Subscriber_Data )

The MSCS/VLR sends a location update request to the HLR which initiates the
user data insertion operation, and sends the user data stored in the HLR to the
VLR.

7: (Insert_ Subscriber _Data_ack)


6

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 8/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

The MSCS/VLR verifies that all the user data sent by the HLR is correct, and
returns the acknowledgement primitive to the HLR.

8: (Forward_Check_SS_Indication)

The MSCS/VLR receives the Forward_Check_SS_Indication request from the


HLR, without acknowledgement.

9: (Update_Location_ack)

After the HLR location update processing is completed, the acknowledgement


 primitive is returned to the MSCS/VLR.

10: (Update_Location_Area_ack)
The MSCS/VLR finishes processing the location update initiated by the MSCS,
and then returns the acknowledgement message to the MS.

2. Combined location update

If the Gs interface is connected, the SGSN notifies the VLR to initiate the
location update after the GPRS location update ends. This is combined location
update, as shown in Fig. 1.1 -5.

SGSN HLR   VLR 

MAP_UPDATE_GPRS_LOCATION_REQ
Step1
MAP_INSERT_SUB._DATA_REQ
Step2
MAP_INSERT_SUB._DATA_ACK 
Step3
MAP_UPDATE_GPRS_LOCATION_ACK 
Step4
Gs_GPRS_LOCATION_UPDATING_REQ
Step5
MAP_UPDATE_LOCATION_REQ
Step6
MAP_INSERT_SUB._DATA_REQ
Step7
MAP_INSERT_SUB._DATA_ACK 
Step8
MAP_UPDATE_LOCATION_ACK 
Step9
Gs_GPRS_LOCATION_UPDATING_ACK 
Step10

Fig. 1.1-5 Combined Location Update Service Process

This location update service process is the same as the common location update service
 process.

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 9/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

1.1.2.2 Periodical Location Update

When an MS is switched off, the MSCS cannot obtain this state due to poor radio
quality or other reasons, but considers that the MS is in “attach” state. When an MS is
switched on but it roams beyond the coverage, namely in the dead zone, the MSCS
cannot know the actual state of the MS, and it considers that the MS is still in “attach”
state. In these two cases, if the user is called, the system constantly sends paging
messages. This wastes radio resources.

To solve the above problem, the MSCS takes the compulsory register measure. The MS
shall register at a regular interval. This is periodical location update.

If the user does not perform any operation for a long time (The system administrator 
can set the time flexibly. In general, it is 24 hours), the system administrator requires
that the invalid user record in the VLR shall be deleted through the OMC. The VLR 
deletes the user data and notifies that to the HLR.

The periodical location update process is the same as the common location update
 process.

1.1.2.3 IMSI Attach/Detach

When an MS is switched off (or the SIM card is taken off), the MS cannot set up any
connection. If the MSCS still implements normal paging, the resources are wasted. To
introduce the IMSI attach/detach procedure is to avoid resource waste.

The user will initiate the location update operation when switching on the MS. The
current location area will be registered in the MSCS/VLR where the user is located. If 
the current MSCS/VLR has no user record, it requests user data from the HLR 
according to the IMSI of the user. The HLR records the current location of the user 
(records the current MSCS/VLR number), and transmits the user data to the
MSCS/VLR. The MSCS/VLR sets the user state to “attach”.

If the MSCS/VLR has user data, it does not need to request data from the HLR. The
system initiates the location update operation in the MSCS/VLR, and then sets the user 
state to “attach”.

When the MS is being switched off, the MS sends a message to the MSCS/VLR. The
network considers that the MS is switched off after receiving the message, and sets the
user state to “detach”.

The IMSI attach process is the same as the location update process. The location

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 10/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

update type parameters in different location update request are different. The location
update type parameters include these values: Normal location update, periodical
location update and IMSI attach. For the location update procedure, the location update
type parameter value is “Normal location update” or “Periodical location update”. For 
the IMSI attach procedure, the location update type parameter value is “IMSI attach”.

1.1.3 Security Management

1.1.3.1 Overview

From the perspective of technologies, the radio transmission is unsafer than the fixed
line transmission. The ZXWN MSCS ensures the security of the system in the
following ways:

1. Preventing the access of unauthorized users. This is implemented through the


authentication.

2. Protecting the privacy of users. This is implemented through the encryption and
integrity protection.

3. Preventing the fraud of user IMSI. This is implemented through the TMSI
allocation.

4. Preventing the MSs of users from embezzlement. This is implemented through


the IMEI check.

1.1.3.2 Authentication Process

The authentication is to protect legal users and void intrusion of illegal users.

The authentication of the UMTS is implemented through the authentication and key
agreement (AKA) procedure. During the AKA procedure, the bidirectional
authentication is adopted. Not only the network can authenticate users, but also users
can authenticate the network. This prevents unauthorized illegal users from access to
the network, and prevents unauthorized illegal network from providing services for 
users. Compared with the GSM authentication, the UMTS authentication has these
advantages:

1. Bidirectional authentication. The network authentication function is added.

2. Introducing and using the SQN.

3. Using the authentication management parameter AMF.

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 11/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

4. Authentication vectors cannot be reused.

These features enhance the security of the UMTS.


The following describes the authentication:

1. Generation and composition of authentication parameters

The user authentication is implemented through the quintuple parameter set


 provided by the system. The quintuple parameter set of the user is generated in
the AUC. When a user is registering, an IMSI is allocated. The IMSI is written
into the USIM card through a USIM reader, and the unique user key Ki
corresponding to this IMSI is generated in the USIM reader. The key is stored in
the USIM card and AUC respectively. The parameters stored in the USIM and
AUC include these authentication algorithms: f1, f2, f3, f4, f5, f1star and f5star.
The sequence numbers SQNms and SQNhe are stored in the USIM and AUC
respectively. These sequence numbers change with the implementation of the
authentication procedure. There is a pseudo number generator in the AUC,
which generates an unpredictable pseudo number (RAND) for the user. In
addition, the AUC stores the authentication management domain parameter 
AMF.

The functions of the algorithms are as follows:

· The RAND, Ki, AMF and SQNhe generate the authentication code MAC-A
through the f1 algorithm.

· The RAND and Ki generate the response number XRES through the f2
algorithm of the AUC.

· The RAND and Ki generate the encryption key CK through the f3 algorithm of 
the AUC.

· The RAND and Ki generate the integrity key IK through the f4 algorithm of the
AUC.

· The RAND and Ki generate the anonymity key AK through the f5 algorithm of 
the AUC.

If the SQN is to be protected, use the AK to encrypt the SQN ( XOR ), and link 
the SQN, AMF and MAC-A to form an authentication token AUTN. In this way,
the RAND, XRES, CK, IK and AUTN form an authentication quintuple. The

specific generation process in the AUC is shown in the figure below.


10

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 12/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

RAND
K  K K 
AMF

f 5 xor  SQN f 1 f 2 f 3 f 4

MAC-A XRES CK  IK 


AK  SQN ⊕ AK 

AUTN = SQN [ ⊕ AK] || AMF || MAC-A


Q = (RAND, XRES, CK, IK, AUTN )

Fig. 1.1-6 Generation Process of Authentication Parameters in the AUC

The generation process of the XMAC-A, RES, CK and IK in the USIM is shown
in the figure below.

RAND
SQN ⊕ AK 
K  K  K 
AMF

f 5 xor  f 1 f 2 f 3 f 4


SQN

AK  XMAC-A RES CK IK  

Fig. 1.1-7 Generation Process of Authentication Parameters in the USIM

2. Normal authentication procedure

The procedure is shown in the figure below.

11

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 13/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

MS VLR/SGSN HLR/AUC

Step1:
Step1: Step1: Generate
Calculate according Transmit authentication
to Ki and AUTN to AuthReq RAND and SendAuthInfoReq vector according
check  to the parameters
XMAC_A=XMAC_  AUTN to the
such as Ki, SQN
A? Check whether  MS and AMF
the SQN is within
the correct range? (RAND, AUTN,
RES, CK, IK).

Step2: AuthRsp Step2: SendAuthInfoRsp Step2:


Calculate XRES, Compare XRES: Transmit the
CK and IK. generated
XRES=RES?
authentication
Transmit XRES to  parameter set to
the VLR/SGSN the VLR/SGSN

Fig. 1.1-8 Normal Authentication Procedure

· When the HLR receives a request of the VLR/SGSN for obtaining


authentication vector, it judges whether to send the authentication vector in
segments. Discrimination method: When the MAP version number is V3, and
the authentication parameter set that the VLR/SGSN applies for exceeds the

 permitted number of authentication parameter sets for each time or in each


 packet transmission, the segmented transmission is needed. In this case, if the
VLR/SGSN supports segmentation, there are multiple authentication requests
and responses. In other cases, no segmentation is implemented.

· The HLR returns the quintuple or triplet according to the authentication


operation version number and subscription option. When the UMTS user asks
the HLR to provide authentication parameters through the R99+VLR/SGSN, the
HLR returns the quintuple. In other cases, the HLR returns the triplet. The HLR 

invokes the AUC interface function to obtain the authentication parameter set.
The UMTS user applies for the quintuple, and the GSM user applies for the
triplet. The number of applied sets is up to 5.

· The AUC searches the parameters such as Ki, SQN and AMF in the database
table according to the IMSI of the user, generates several sets of RANDs, and
computes the corresponding XRES, CK, IK and AUTN.

· The HLR obtains authentication parameters from the AUC successfully,


converts the quintuple into triplet if the UMTS user is accessed from the R98
VLR/SGSN, and sends the authentication parameter set to the VLR/SGSN.
12

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 14/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

Otherwise, the conversion is not implemented, and the obtained authentication


 parameter set is sent to the VLR/SGSN directly.

· The VLR/SGSN initiates the authentication operation, and transmits a RAND


and AUTN to the MS.

· The MS obtains the authentication code XMAC-A through the same f1


algorithm according to the Ki, RAND and AUTN, and then checks whether the
XMAC-A is equal to the MAC-A. If they are not equal, it indicates that the
network is an illegal network, that is, the MS fails to authenticate the network.
Otherwise, the MS checks whether the SQN is within a correct range. If the

SQN is not within a correct range, the re-synchronization procedure is


implemented. If the SQN is within a correct range, it indicates that the network 
is an authorized network, that is, the MS succeeds in authenticating the network.

· The MS obtains the RES through the same f2 algorithm according to the Ki and
RAND, obtains the CK through the same f3 algorithm, obtains the IK through
the same f4 algorithm, and sends the calculated RES to the VLR/SGSN.

· In the VLR/SGSN, compare the RES calculated by the MS with that calculated
 by the AUC. If they are the same, it indicates that the user is a legal user. The
network finishes authenticating the user.

3. Re-synchronization procedure

When the MS fails to authenticate the SQN, it indicates that the SQN is not
within a correct range. A re-synchronization procedure shall be initiated to re-
synchronize the sequence number of the MS and that in the HLR/AUC.

1.1.3.3 Encryption and Integrity Protection

1. Encryption service

The user data and some signaling information elements are considered sensitive,
and shall be encrypted and protected. To ensure the confidentiality of the
identity, the TMSI of a temporary user must be transmitted in the protected
format during the allocation and other signaling process. This service is
implemented by using the encryption algorithm on the private channel between
the ME and the RNS.

· Encryption method

The figure below describes how to use the encryption algorithm f8 to obtain the
13

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 15/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

cipher text. The cipher text is obtained in the case of the key stream exclusive or 
the plain text. The plain text is obtained in the case of the cipher text exclusive
or the key.

The following module is included: The algorithm output key stream


KEYSTREAM used to encrypt the PLAINTEXT to generate output
CIPHERTEXT.

COUNT -C DIRECT ION COUNT -C DIRECT ION

BEARER LENGTH BEARER LENGTH

CK  f8 CK  f8

KEYSTREAM KEYSTREAM
BLOCK  BLOCK 

PLAINTEXT CIPHERTEXT PLAINTEXT


BLOCK  BLOCK  BLOCK 

Sender  Receiver 
UE or RNC RNC or UE

Fig. 1.1-9 Encryption Process

· Encryption algorithm input parameters

COUNT-C: 32 bits. Each logical RLC AM channel and each RLC UM channel
have a COUNT-C value, and the logical channel using the transparent RLC
mode (and mapping to DCH) has a COUNT-C value. The COUNT-C value

consists of two parts: “short” sequence number and “long” sequence number.
CK: 128 bits. The CK is saved in the USIM, and backed up in the ME. Once the
request of the ME is received, the CK is sent to the ME from the USIM.

BEARER: 5 bits. Each user has only one parameter BEARER that is
multiplexed on a separate 10 ms physical layer frame. It is used to avoid using
the same input parameter for different key streams.

DIRECTION: 1 bit. It is used to prevent the integrity algorithm from using the
same input parameter in calculating message authentication code for the uplink 

14

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 16/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

and downlink. The DIRECTION of the message from the UE to the RNS is set
to 0, and that of the message from the RNS to the UE is set to 1.

LENGTH: 16 bits. The length indicator indicates the length of the required key
stream.

2. Integrity protection

Most control signaling information elements transmitted between the MS and


the network are considered sensitive, so the integrity protection must be
implemented. The message authentication function is used to protect these
signaling information elements transmitted between the ME and RNS.

· Data integrity protection method

Fig. 1.1 -10 shows the process of using the integrity protection algorithm f9 to
validate the data integrity of the signaling message.

COUNT-I DIRECTION COUNT-I DIRECTION

MESSAGE FRESH MESSAGE FRESH

IK  f9 IK  f9

MAC -I XMAC -I

Sender  Receiver 
UE or RNC UE or RNC

Fig. 1.1-10 Integrity Protection Process

The algorithm input parameters include integrity key (IK), integrity sequence
number (COUNT-I), network generated random value (FRESH), direction
(DIRECTION) and signaling data MESSAGE. Based on these input parameters,
the user uses the integrity algorithm f9 to compute the data integrity message
authentication code MAC-I. The MAC-I is transmitted with the message at the
radio access link. The receiver computes the XMAX-I of the message, and
compares it with the MAC-I sent by the transmitter to check the integrity of the
received data.

· Integrity algorithm input parameters


15

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 17/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

COUNT-I: 32bits. Each logical signaling channel has a COUNT-I. The COUNT-
I consists of two parts: “short” sequence number and “long” sequence number.

IK: 128 bits. The IK is stored in the USIM, and backed up in the ME. After the
request of the ME is received, the IK is sent to the ME from the USIM.

FRESH: The FRESH at the network side is 32 bits. Each user has only one
FRESH parameter that is used to protect the network for being attacked by the
user signaling replay.

DIRECTION: 1 bit. It is used to prevent the integrity algorithm from using the
same input parameter in calculating message authentication code for the uplink 
and downlink. The DIRECTION of the message from the UE to the RNS is set
to 0, and that of the message from the RNS to the UE is set to 1.

MESSAGE: Signaling message.

1.1.3.4 TMSI Allocation/Release

The TMSI instead of the IMSI is transmitted over the radio channel. This enhances the
secrecy of the user identity. The value of the TMSI is determined in the VLR, so the
TMSI is only valid in the VLR area. The TMSI includes the time information and the

information used for distinguishing the user identity. Once a new TMSI is allocates
successfully, it is transmitted to the MS in encrypted mode.

1.1.3.5 IMEI Check

The VLR can conduct the IMEI check in setting the location update and access request.
In the CheckIMEI response initiated in the VLR, check whether the IMEI is the same
as the expected value. The VLR also can send the ObtainIMEI request.

1.1.4 User Data Management

After the subscription information in the HLR changes, the synchronization message is
initiated to keep the user data in the VLR consistent with that in the HLR. The
synchronization methods are as follows:

1. Inserting user data.

2. Deleting user data.

These two types of messages support the message retransmission mechanism.

1. Inserting user data

16

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 18/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

In adding or modifying subscription information about a user, the HLR inserts


the user data. Fig. 1.1 -11 shows the service process.

VLR HLR

MAP_INSERT_SUBSCRIBER_DATA
(a)

MAP_INSERT_SUBSCRIBER_DATA_ack
(b)

Fig. 1.1-11 Process of Inserting User Data

Process description:

1) The HLR initiates a request for inserting user data to the VLR (According to the
amount of user data, the data is transmitted through one or multiple packets).

2) After the user data is inserted into the VLR, the VLR returns a response.

2. Deleting user data

In deleting the subscription information about a user, the HLR deletes the user 
data. Fig. 1.1 -12 shows the service process.

VLR HLR

MAP_DELETE_SUBSCRIBER_DATA
(a)

MAP_DELETE_SUBSCRIBER_DATA_ack
(b)

Fig. 1.1-12 Process of Deleting User Data

Process description:

1) The HLR initiates a request for deleting user data from the VLR.

2) After the VLR deletes the related subscription information, the VLR returns a
response.

17

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 19/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

TN_SP019_E1_0 Mobility Management Flow in CS domain

1.1.5 Error Recovery Processing

1. VLR restart

The VLR may stop working due to faults or sudden power off. After restart-up,
the data in the VLR must be restored. The restoration methods are as follows:

1) When triggering the VLR restoration operation during the operation procedures
such calling and SMS, the HLR transmits the user data to the VLR. The
following figure shows the process.

VLR HLR

MAP_RESTORE_DATA
(a)

MAP_ACTIVATE_TRACE_MODE
(b)

MAP_ACTIVATE_TRACE_MODE_ack
(c)

MAP_INSERT_SUBSCRIBER_DATA
(d)

MAP_INSERT_SUBSCRIBER_DATA_ack
(e)

MAP_RESTORE_DATA_ack
(f)

Fig. 1.1-13 VLR Restart Service Process

Process description:

a. During the operation procedures such as calling and SMS, the VLR initiates
the data restoration request to the HLR.

 b. If the user is to be activated and traced, the HLR sends a request for activating
the user tracing to the VLR.

c. The VLR responds and sets the user to activated state, and sends an
acknowledgement of activating the user tracing to the HLR.

d. The HLR sends a request to the VLR, and inserts the user data (According to
the amount of user data, the data may be inserted through one or multiple

 packets).
18

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 20/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

Chapter 1 Mobility Management Services

e. The VLR where the user is located currently responds and sends an
acknowledgement of user data insertion to the HLR.

f) The HLR acknowledges the VLR data restoration request.

2) The restoration operation of the user due to location update is the same as that of 
the above “IMSI attach”.

 Note: In the GSM Phase I, the VLR uses the Send Parameters service to request
user data from the HLR.

2. HLR restart

After restart-up, the HLR sends the RESET message to the VLR to which the
user in the HLR roams. After receiving the message, the VLR attaches an
uncertainty flag to the data of the user of the HLR. The VLR implements the
location update in the subsequent incoming call or outgoing call to obtain user 
data. The figure below shows the process.

VLR HLR

MAP_RESET

Fig. 1.1-14 HLR Restart Process

19

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 21/22
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc

http://slidepdf.com/reader/full/tnsp019e10-mobility-management-flow-in-cs-domain-25doc 22/22

You might also like