tn_sp019_e1_0 mobility management flow in cs domain-25.doc
TRANSCRIPT
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
1/22
Mobility Management Flow in
CS domain
Course Objectives:
ZXWN MSC Server (V3.0) Technical Manual
ZXWN MGW (V3.0) Media Gateway Technical Manual
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
2/22
Contents
1 Mobility Management Services..................................................................................................................1
1.1 Introduction.............................................................................................................................................1
i
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
3/22
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
4/22
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.
Mobilitymanagementservice
Location update unit
Error recovery processing unit
User data management unit
Security management unit
Service processing subsystem
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
5/22
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. Ifthey 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.
3
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
6/22
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
7/22
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.
Insert_Subscriber_Data
Update_Location_Area_ack
Insert_Subscriber_Data_ack
Update_Location_ack
Update_Location
Update_Location_Area_REQStep 1
Step2
Step6
Step 7
Cancel_Location
Cancel_Location_ack
Activate_Trace_Mode
Activate_Trace_Mode_ack
Forward_Check_SS_Indication
Step3
Step 4
Step 5
Step8
Step 9
Step10
PVLRHLRMSCS/VLRMS
Fig. 1.1-4 Process with Initiating Location Update to the HLR
5
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
8/22
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
9/22
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
MAP_UPDATE_GPRS_LOCATION_REQ
MAP_INSERT_SUB._DATA_REQ
Step1
Step2
VLR
MAP_INSERT_SUB._DATA_ACK
MAP_UPDATE_GPRS_LOCATION_ACK
Gs_GPRS_LOCATION_UPDATING_REQ
MAP_UPDATE_LOCATION_REQ
MAP_INSERT_SUB._DATA_REQ
MAP_INSERT_SUB._DATA_ACK
MAP_UPDATE_LOCATION_ACKStep9
Step8
Step7
Step6
Step5
Step4
Step3
Gs_GPRS_LOCATION_UPDATING_ACKStep10
Fig. 1.1-5 Combined Location Update Service Process
This location update service process is the same as the common location update service
process.
7
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
10/22
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 administratorcan 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
8
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
11/22
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.
9
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
12/22
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
13/22
Chapter 1 Mobility Management Services
K K
SQN
RAND
AMF
CK IKMAC-A XRES
f3 f4f1 f2
AK
f5
SQN AK
xor
K
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.
K K
SQN
RAND
AMF
CK IK XMAC-A RES
f3 f4f1 f2
AK
f5
SQN AK
xor
K
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
14/22
TN_SP019_E1_0 Mobility Management Flow in CS domain
Step1:Calculate accordingto Ki and AUTN tocheckXMAC_A=XMAC_A? Check whetherthe SQN is withinthe correct range?
Step2:
Calculate XRES,
CK and IK.
Transmit XRES to
the VLR/SGSN
Step1:
Transmit
RAND and
AUTN to the
MS
Step2:
Compare XRES:
XRES=RES?
Step1:Generateauthenticationvector accordingto the parameterssuch as Ki, SQNand AMF
Step2:Transmit thegeneratedauthenticationparameter set to
the VLR/SGSN
MS VLR/SGSN HLR/AUC
SendAuthInfoReq
SendAuthInfoRsp
AuthReq
AuthRsp
(RAND, AUTN,
RES, CK, IK).
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 eachpacket 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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
15/22
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 isimplemented. 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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
16/22
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.
PLAINTEXT
BLOCK
f8
COUNT-C DIRECTION
BEARER LENGTH
CK
KEYSTREAM
BLOCK
CIPHERTEXT
BLOCK
f8
COUNT-C DIRECTION
BEARER LENGTH
CK
KEYSTREAM
BLOCK
PLAINTEXT
BLOCK
Sender
UE or RNC
Receiver
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
17/22
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.
f 9
COUNT-I DIRECTION
MESSAGE FRESH
IK
MAC -I
f 9
COUNT-I DIRECTION
MESSAGE FRESH
IK
XMAC -I
Sender
UE or RNC
Receiver
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
18/22
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
19/22
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
(a)
(b)
HLR
MAP_INSERT_SUBSCRIBER_DATA
MAP_INSERT_SUBSCRIBER_DATA_ack
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
(a)
(b)
HLR
MAP_DELETE_SUBSCRIBER_DATA
MAP_DELETE_SUBSCRIBER_DATA_ack
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
20/22
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
(a)
(b)
HLR
MAP_RESTORE_DATA
MAP_INSERT_SUBSCRIBER_DATA
MAP_INSERT_SUBSCRIBER_DATA_ack
MAP_RESTORE_DATA_ack
MAP_ACTIVATE_TRACE_MODE
MAP_ACTIVATE_TRACE_MODE_ack
(f)
(e)
(d)
(c)
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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
21/22
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 theuser 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
-
7/27/2019 TN_SP019_E1_0 Mobility Management Flow in CS domain-25.doc
22/22