6.5.1 Location Update
The location update procedure is
completed through logical coordination between entities such as HLR and
MSC/VLR. The HLR stores the current location information of each mobile
subscriber and all the subscriber data; the VLR stores the subscriber data of
the subscribers roaming to the location area under its control; and the MSC
processes the location registration procedure of each mobile subscriber, has
dialog with the mobile subscribers and exchanges information with HLR and VLR.
The
location update procedure includes location registration, periodic location
registration and subscriber data deletion.
1. Location
registration
It is to
execute the Update Location operation of MAP. Different types of location
registration can be distinguished through the Update Location Type parameter in
the Update Location Request message.
The
following condition can trigger the normal location registration procedure of a
mobile subscriber:
When the
UE is switched on or the mobile subscriber roams to cause the change of his
location. The Update Location Type indicates IMSI Attach in the case of UE switch-on
while Normal Updating in the case of subscriber roaming.
The UE
compares the LAI in the broadcast message it has received with the LAI stored
in itself. If these two LAIs are the same, the UE will initiate the IMSI Attach
procedure; otherwise it will initiate the Normal Updating operation.
2. Periodic
location registration
It is to
execute the Update Location operation of MAP and the Update Location Type
parameter in the Update Location Request message indicates Periodic Updating.
Through
periodic location registration (location update), the PLMN can keep track of
the current state of each mobile subscriber, especially those subscribers that
have no operation for a long period of time. The location update period and the
protection time can be set and adjusted by the PLMN operator according to the
specific traffic and subscriber habits.
3. Subscriber
data deletion
It is to
execute the Cancel Location operation of MAP.
Through
subscriber data deletion, subscriber records can be deleted from the VLR and
the cases include the subscriber data deletion caused by subscriber roaming,
that caused by no subscriber operation for a long period of time and the
deletion of the invalid subscriber data by system administrators.
The
purpose of subscriber data deletion is to enable the HLR to delete the old
subscriber information in the VLR at the time of location update or enable the
independent location deletion triggered by subscriber data modification and
allow operating staff to delete the subscriber location information.
The
following figure depicts a typical location update flow that basically
comprises the above three procedures.
1)
The MSC/VLR receives the
location update request initiated by the subscriber with TMSI. If the TMSI is
not known:
A. If the carried old
location information indicates the location area of an adjacent VLR, the
MSC/VLR will initiate the procedure for getting the identification from PVLR.
For details, refer to the SEND IDENTIFICATION procedure indicated in the above
figure.
B. If the old location area
is one of a non-adjacent VLR or the request for identification from PVLR fails,
the MSC/VLR will initiate a procedure (not indicated in the above figure) to
request the UE to provide the IMSI. For details, refer to the subsequent
sections.
2) If it is the first time for the subscriber to register its location
in the current VLR, a location update request will be initiated to the HLR.
Otherwise, the LOCATION UPDATING ACCEPT procedure will follow directly.
3) If the HLR finds that the MSC/VLR number involved in subscriber
roaming has changed upon receipt of the location update request from MSC/VLR,
it will initiate the CANCEL LOCATION procedure to PVLR so as to delete the
subscriber information in PVLR.
4)
If the roaming request is
rejected, the HLR will directly initiate a location update response with the
reject information to the MSC/VLR; otherwise it will insert subscriber data to
the MSC/VLR before deciding to accept or reject the location update request
according to the result of subscriber data insertion.
6.5.2 Detachment
The
detachment procedure is the procedure of IMSI Detach initiated by the UE upon
switch-off, after which the MSC/VLR will set the subscriber state to IMSI
detached. It should be noted that this procedure will not be notified to the
HLR. This is different from the Purge procedure, because the HLR contains no
Detach/Attach state indicator bit for the subscriber but the Purge procedure
involves this indicator bit. For details, refer to the subsequent Purge
operation descriptions.
If the
subscriber is called, the HLR will request for a roaming number from VLR
through the Provide Roaming Number procedure. Since the subscriber is detached,
the Provide Roaming Number procedure will fail with the cause value of Absent
Subscriber returned and the calling MSC will play the subscriber switch-off
announcement to the calling UE according to this cause value.
For some models of UEs, the Detach procedure may also be initiated if the UE is switched off during the conversation.
6.5.3 Identification
The identification procedure takes place at
the Iu interface so that the network can provide IMEI or IMSI information to
the UE. The Identity procedure is executed for subscriber identification.
There
are two types of Identity procedures:
l When the VLR does not contain any
IMEI of the UE, one Identity procedure will be forced for execution and the
network will initiate a request for the IMEI to the UE through the Identity
Request message while the UE will provide the IMEI to the network through the
Identity Response message.
The typical cases are the first location
update of the UE, the invalidity of subscriber IMEI stored in the VLR (note
that this will not affect the subscribers since presently IMEI authentication
is not yet applied).
l When the TMSI is unidentifiable
during location update, one Identity procedure will also be forced for
execution and the network will initiate a request for the IMSI to the UE
through the Identity Request message while the UE will provide the IMSI to the
network through the Identity Response message.
The typical cases include subscriber
roaming and the areas without using the TMSI.
6.5.4 Purge
The
Purge procedure refers to the VLR-initiated purge MS procedure, that is, the
Purge UE procedure in MAP. It is used for the VLR to report its subscriber
deletion operation to the HLR. Different from the IMSI Detach procedure
described in the previous section, the Purge UE procedure should be notified to
the HLR, so that the HLR will set the UE Purge Flag of this UE upon receipt of
the Purge UE message to indicate that the subscriber data have been purged from
the VLR.
If the
subscriber is called, the HLR will query the UE Purge Flag when the calling UE
queries the HLR in the Send Routing Information procedure. Since the UE Purge
Flag has been set, the HLR will return the cause value of Absent Subscriber to
the MSC and the calling MSC will play the subscriber switch-off announcement to
the calling UE according to this cause value. This procedure does not involve
the Provide Roaming Number operation from the HLR to the VLR.
6.5.5 Authentication Procedure
The authentication procedure is initiated
by the network to check if the UE is allowed to access the network, provide the
random number array in the authentication quintuple for the UE to calculate the
Ciphering Key (CK), allow the UE to calculate the Integrity Key (IK) for
consistency check between the UE and the network, as well as providing the UE’s
authentication of the network.
Compared with the GSM authentication
procedure, the 3G
authentication procedure has the additional consistency check function and the
function of the UE to authenticate the network. All these functions contribute
to the enhanced 3G security
features.
Before
the network initiates the authentication procedure and if the VLR does not
contain any authentication quintuple, the procedure of requesting an
authentication set from the HLR will be initiated to wait for the return of the
authentication quintuple. The authentication quintuple contains such
information as RAND, XRES, AUTN, CK and IK.
After
detecting the presence of the authentication quintuple, the network will send
an authentication request message, which contains the RAND
and AUTN information of a certain quintuple. Upon receipt of this message, the
UE will have its USIM card check the AUTN, that is, the UE will authenticate
the network. If the network is accepted, the USIM card will use the RAND to calculate the CK, the IK and the RES. If the USIM
card determines that the authentication succeeds, the RES will be returned in
the authentication response message.
Upon
receipt of the authentication response message, the network will compare the
RES in this message with the XRES in the authentication quintuple stored in the
VLR database to verify if the authentication is successful or not. If the
authentication is successful, the subsequent procedures will normally continue;
otherwise the exception handling procedure will be initiated to release the
connection between the network and the UE as well as the occupied network and
radio resources.
After
the successful authentication, the UE will store the CK and the IK in its USIM
card.
In some
cases, the UE will report authentication failure upon receipt of the
authentication request message. There are two typical causes of authentication
failure:
When
authenticating the network, the UE will check the AUTN parameter in the
authentication request message sent from the network. If the MAC information is
incorrect, the UE will report the authentication failure information with the
cause value being “MAC Failure”.
At this
time, the network will decide if to initiate the Identity procedure according
to the subscriber identity reported by the UE. If the current identity is TMSI
or P-TMSI, it will initiate the Identity procedure and request the UE to report
the IMSI information before re-initiating the authentication procedure.
Another
cause of authentication failure is that the UE detects the SQN error in the
AUTN message with the cause value being “Synch failure”.
At this time, the VLR at the
network side will delete all the authentication quintuples and initiate the
procedure of synchronization to the HLR to request the HLR to re-insert the
authentication quintuple before the re-authentication procedure is started.
6.5.6 Secure
Mode Control
The
secure mode control procedure is used by the network to send ciphering
information to the RAN. In this process, the core network will negotiate with
the RAN on the ciphering algorithm for the UE so that the UE can use this
ciphering algorithm in the subsequent service transfer procedure and shall try
the best to use this ciphering algorithm after the UE handover, that is, the
relevant parameters for ciphering will be sent to the handover destination RNC.
6.5.7 TMSI
Reallocation
A TMSI
(Temporary Mobile Subscriber Identity) is a series of digits (4 bytes)
temporarily assigned to a subscriber. It is managed by the MSC/VLR, assigned to
a subscriber when the subscriber is registered for the first time in a location
area and deleted when the subscriber leaves this location area. It is used to
uniquely identify the MS in a location area and is transmitted on the radio
channels in place of IMSI to prevent any third party from intercepting the
signals over the radio channels and/or tracking the mobile subscriber.
Therefore, the basic purpose of TMSI is to enhance the security of the MS.
The
correspondence between TMSIs and IMSIs is stored in the VLR that manages the
current visited location area of the MS, and the new TMSI is also stored in the
SIM card of the MS. We can see that the TMSI is stored in both the VLR and the
SIM card.
The TMSI
reallocation procedure may take place during subscriber location update, call
setup and supplementary service procedures. It can be implemented by selecting
the execution of the TMSI reallocation procedure in the MAP functional
procedures of MSC.
The TMSI
reallocation procedure during location update is integrated with the location
update accept.
Note: Among the mobility
management procedures, the procedures of authentication, security mode control
and TMSI reallocation are optional and network operators may decide whether to activate
or provision them.
For example, this is
implemented by the MAP functional procedure configuration parameters in the
MSC9800.
6.5.8 Combined
Location Update
When both the location area and the routing
area of a UE have changed, the combined location update procedure will be
initiated and the location update procedure will be initiated simultaneously in
the PS domain and the CS domain. The CS domain at the network side is connected
via the Gs interface with the PS domain (when the CS domain and the CS domain
of the core network are separated in the networking, the following descriptions
will use the MSC to represent the CS domain while the SGSN to represent the PS
domain). The Gs interface adopts the BSSAP+ protocol in the SS7 signaling
system and enables the CS domain and the PS domain to mutually update the MS
location information stored in the databases, so as to reduce the air interface
signaling and help the MSC page the Class B MS ongoing with the GPRS service.
The following figure shows a typical combined
location update procedure.
Комментариев нет:
Отправить комментарий