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.
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.
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.
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
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
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
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.
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.