19.1.1 Location updating

09.023GPPMobile Application Part (MAP) specificationTS

19.1.1.1 General

The location updating procedure is used to update the location information held in the network. For GPRS subscribers, this procedure describes also updating of the SGSN and, if Gs interface is installed, updating of the VLR in combination with an attach/routing area updating in the SGSN. This location information is used to route incoming calls, packet data, short messages and unstructured supplementary service data to the roaming subscriber. Additionally, this procedure is used to provide the VLR and/or the SGSN with the information that a subscriber already registered, but being detached, is reachable again (IMSI Attach and/or GPRS Attach, see GSM 03.12 and GSM 03.60). The use of the IMSI Detach / Attach feature is optional for the network operator.

To minimize the updates of the subscriber’s HLR, the HLR holds only information about the VLR and MSC the subscriber is attached to and, for GPRS subscribers, the SGSN the subscriber is attached to. The VLR and the SGSN contain more detailed location information, i.e. the location area the subscriber is actually roaming in (for the VLR) and the routing area (RA) where the GPRS subscriber is located (for SGSN). Therefore, the VLR needs to be updated at each location area change (see figure 19.1.1/1 for this procedure) and the SGSN needs to be updated at each routing area change.The HLR needs updating only in the following cases:

– when the subscriber registers in a new VLR or SGSN, i.e. the VLR or SGSN has no data for that subscriber;

– when the subscriber registers in a new location area of the same VLR and new routing information is to be provided to the HLR (change of MSC area);

– if the indicator "Confirmed by HLR" or the indicator "Location Information Confirmed in HLR" is set to "Not Confirmed" because of HLR, VLR or SGSN restoration, and the VLR or SGSN receives an indication that the subscriber is present.

If a mobile subscriber registers in a visitor location register (VLR) not holding any information about this subscriber and is identified by a temporary mobile subscriber identity (TMSI) allocated by a previous visitor location register (PVLR), if the PVLR identity can be derived from LAI the new VLR must obtain the IMSI from PVLR to identify the HLR to be updated (see figure 19.1.1/2). If the IMSI cannot be retrieved from PVLR, it is requested from the MS (see figure 19.1.1/3).

The stage 2 specification for GPRS is in GSM 03.60. The interworking between the MAP signalling procedures and the GPRS procedures in the SGSN is shown by the transfer of signals between these procedures (see subclause 19.1.1.8).

The message flow for successful GPRS Attach/ RA update procedure (with Gs interface not installed) is shown in figure 19.1.1/4.

The message flow for successful GPRS Attach/ RA update procedure combined with a successful VLR location updating (Gs interface installed) is shown in figure 19.1.1/5.

The following MAP services are invoked by the location update procedure:

MAP_UPDATE_LOCATION_AREA (see subclause 8.1);(**)

MAP_UPDATE_LOCATION (see subclause 8.1);(**)

MAP_UPDATE_GPRS_LOCATION (see subclause 8.1) (*);

MAP_CANCEL_LOCATION (see subclause 8.1);

MAP_INSERT_SUBSCRIBER_DATA (see subclause 8.8);

MAP_SEND_IDENTIFICATION (see subclause 8.1) (**);

MAP_PROVIDE_IMSI (see subclause 8.9) (**);

MAP_AUTHENTICATE (see subclause 8.5) (**);

MAP_SET_CIPHERING_MODE (see subclause 8.6) (**);

MAP_FORWARD_NEW_TMSI (see subclause 8.9) (**);

MAP_CHECK_IMEI (see subclause 8.7) (**);

MAP_ACTIVATE_TRACE_MODE (see subclause 9.2);

MAP_TRACE_SUBSCRIBER_ACTIVITY (see subclause 9.2) (**).

(*): only used in SGSN and HLR for GPRS

(**): not used in SGSN

+—-+ +—-+ A +—-+ B +—-+
ª MS ª——-ª BS ª—-+——ªMSC ª——-+———ªVLR ª
+—-+ +—-+ +—-+ +—-+
ª ª ªßß
ª A_LU_REQUEST ª ªßß
ª—————————->ª MAP_UPDATE_ ªßß
ª ª———————->ªßß
ª ª LOCATION_AREA ªßß
ª (note 1) ª ªßß
ª ª MAP_AUTHENTICATE ªßß
ª<—————————-ª<———————-ªßß
ª ª MAP_AUTHENTICATE ack ªßß
ª—————————->ª———————->ªßß
ª ª (note 2) ªßß
ª ª ªßß
ª ªMAP_SET_CIPHERING_MODE ªßß
ª<—————————-ª<———————-ªßß
ª ª ªßß
ª ª MAP_TRACE_SUBSCRIBER_ ªßß
ª ª ACTIVITY ªßß
ª ª<———————-ªßß
ª ª ªßß
ª ª MAP_CHECK_IMEI ªßß
ª<—————————-ª<———————-ªßß
ª ª MAP_CHECK_IMEI ack ªßß
ª—————————->ª———————->ªßß
ª ª ªßß
ª ª MAP_FORWARD_NEW_TMSI ªßß
ª<—————————-ª<———————-ªßß
ª ª ªßß
ª ª MAP_UPDATE_LOCATION_ ªßß
ª A_LU_CONFIRM ª<———————-ªßß
ª<—————————-ª AREA ack ªßß
ª ª ªßß
ª ªMAP_FORW._NEW_TMSI ack ªßß
ª—————————->ª———————->ªßß
ª ª ªßß
ª ª ªßß

NOTE 1: For details of the procedure on the radio path, see GSM 04.08. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.

NOTE 2: Optional services are printed in italics.

Figure 19.1.1/1: Interface and services for location updating when roaming within an visitor location registers area (without need to update HLR)

+—-+ +—-+ A +—-+ B +—-+ D +—-+
ª MS ª-ª BS ª–+–ªMSC ª—+—-ªVLR ª———+————ªHLR ª
+—-+ +—-+ +—-+ +—-+ +—-+
ª ªßß
ª G +—-+ D ªßß
+—–+—–ªPVLR+—-+—–+ßß
+—-+ ßßßß
ª A_LU_REQUEST ª ª ª ªßß
ª—————->ª MAP_UPDATE_ ª ª ªßß
ª ª————->ª ª ªßß
ª ª LOCATION_AREAªMAP_SEND_IDENTIFICATION ªßß
ª ª ª————->ª ªßß
ª ª ª ª ªßß
ª ª ªMAP_SEND_IDENTIFICATION ªßß
ª ª ª<————-ª ªßß
ª ª ª ack ªßß
ª ª ª ªßß
ª ª ª MAP_UPDATE_LOCATION ªßß
ª ª ª———————-> ªßß
ª ª ª ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ª LOCATION ªßß
ª ª ª ª<————ªßß
ª ª ª ª ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ªLOCATION ack ªßß
ª ª ª ª————>ªßß
ª ª ª ª ªßß
ª ª ªMAP_ACTIVATE_TRACE_MODE ªßß
ª MAP_TRACE_SUBSCRª<———————- ªßß
ª ª _ACTIVITY ª ªßß
ª ª<————-ª ªßß
ª ª ªMAP_ACTIVATE_TRACE_MODE ackªßß
ª ª ª———————-> ªßß
ª ª ª ªßß
ª ª ªMAP_INSERT_SUBSCRIBER_DATA ªßß
ª ª ª<———————- ªßß
ª ª ª ªßß
ª ª ªMAP_INSERT_SUBSCR._DATA ackªßß
ª ª ª———————-> ªßß
ª ª ª ªßß
ª ª ªMAP_UPDATE_LOCATION ack ªßß
ª ª ª<———————- ªßß
ª ª MAP_UPDATE_ ª ªßß
ª ª<————-ª ªßß
ª A_LU_CONFIRM ªLOCATION_AREA ack ªßß
ª<—————-ª ª ªßß
ª ª ª ªßß
ª ª ª ªßß
ª ª ª ªßß
ª ª ª ªßß
ª ª ª ªßß

NOTE: The optional procedures in figure 19.1.1/1 apply here respectively.

Figure 19.1.1/2: Interface and services for location updating when changing the VLR area

+—-+ +—-+ A +—-+ B +—-+ D +—-+
ª MS ª—-ª BS ª—ª—ªMSC ª——+——ªVLR ª——+——ªHLR ª
+—-+ +—-+ +—-+ +—-+ +—-+
ª G +—-+ D ª ß
+—+–ªPVLR+–+—-+ ß
+—-+ ß
ª A_LU_REQUEST ª ª ªßß
ª———————>ª MAP_UPDATE_ ª ªßß
ª ª—————–>ª ªßß
ª ª LOCATION_AREA ª ªßß
ª ª ª ªßß
ª ª MAP_PROVIDE_IMSI ª ªßß
ª<———————ª<—————–ª ªßß
ª ª ª ªßß
ª ª MAP_PROVIDE_IMSI ª ªßß
ª———————>ª—————–>ª ªßß
ª ª ack ªMAP_UPDATE_LOCATIONªßß
ª ª ª——————>ªßß
ª ª ª ªßß
ª ª ª ª MAP_CANCEL_ªßß
ª ª ª ª LOCATION ªßß
ª ª ª ª<———–ªßß
ª ª ª ª ªßß
ª ª ª ª MAP CANCEL ªßß
ª ª ª ªLOCATION ackªßß
ª ª ª ª———–>ªßß
ª ª ª ªßß
ª ª ªMAP_ACTIVATE_TRACE_ªßß
ª ª MAP_TRACE_SUB – ª<——————ªßß
ª ª SCRIBER_ACTIVITYª MODE ªßß
ª ª<—————–ª ªßß
ª ª ªMAP_ACTIVATE_TRACE_ªßß
ª ª ª——————>ªßß
ª ª ª MODE ack ªßß
ª ª ª ªßß
ª ª ª MAP_INSERT_ ªßß
ª ª ª<——————ªßß
ª ª ª SUBSCRIBER_DATA ªßß
ª ª ª ªßß
ª ª ª MAP_INSERT_ ªßß
ª ª ª——————>ªßß
ª ª ªSUBSCRIBER_DATA ackªßß
ª ª ª ªßß
ª ª ªMAP_UPDATE_LOCATIONªßß
ª ª MAP_UPDATE_ ª<——————ªßß
ª A_LU_CONFIRM ª<—————–ª ack ªßß
ª<———————ªLOCATION_AREA ack ª ªßß
ª ª ª ªßß

NOTE: The optional procedures in figure 19.1.1/1 apply here respectively.

Figure 19.1.1/3: Interface and services for location updating involving both a VLR and an HLR, when IMSI can not be retrieved from the previous VLR

+—-+ +—-+ Gb +—–+ Gr +—-+
ª MS ª-ª BS ª————–+—ª SGSNª———-+———–ªHLR ª
+—-+ +—-+ +—–+ +—-+
ª ªßß
+—-+ D ª ªßß
ªVLR +—–+———-+ ªßß
Gs +—-+ ªßß
+—–+ Gr ªßß
ªPSGSN+—-+—-+ßß
+—–+ ßß
ª ª ª ª ªßß
ª Gb_ATTACH/RA_UPDATE_REQUEST ª ª ª ªßß
ª—————————–>ª ª ª ªßß
ª (note_1) ª ª ª ªßß
ª ª(Note_2)ª ª ªßß
ª ª ªßß
ª ª MAP_UPDATE_GPRS_LOCATION ªßß
ª ª—————————->ªßß
ª ª ª ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ª LOCATION ªßß
ª ª ª ª<————ªßß
ª ª ª ª ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ªLOCATION ack ªßß
ª ª ª ª————>ªßß
ª ª ª ª ªßß
ª ª MAP_ACTIVATE_TRACE_MODE ªßß
ª ª<—————————-ªßß
ª ª (note_3) ªßß
ª ª MAP_ACTIVATE_TRACE_MODE ackªßß
ª ª—————————->ªßß
ª ª ªßß
ª ª MAP_INSERT_SUBSCRIBER_DATA ªßß
ª ª<—————————-ªßß
ª ª ªßß
ª ª MAP_INSERT_SUBSCR._DATA ackªßß
ª ª—————————->ªßß
ª ª ªßß
ª ª MAP_UPDATE_GPRS LOCATION ackªßß
ª ª<—————————-ªßß
ª ª ª ªßß
ª ª(Note_4)ª ªßß
ª ª ª ªßß
ª Gb_ATTACH/RA_UPDATE_ ª ª ªßß
ª<—————————–ª ª ªßß
ª REQUEST ack ª ª ªßß
ª ª ª ªßß

PSGSN = Previous SGSN

NOTE 1: For details of the procedure on the radio path, see GSM 08.18. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.

NOTE 2: For security functions (authentication, ciphering, IMEI check) triggering refer to GSM 03.60. MAP processes invoked for those procedures are described in section 25.

NOTE 3: Optional services are printed in italics.

NOTE 4: Refer to GSM 03.60 for termination of the procedure and triggering of the signalling on the Gb interface.

Figure 19.1.1/14: Interface and services for GPRS location updating (Gs-interface not installed)

+—-+ +—-+ Gb +—–+ Gr +—-+
ª MS ª-ª BS ª————–+—-ª SGSNª———+———–ªHLR ª
+—-+ +—-+ +—–+ +—-+
ª +—-+ D ª ªßß
++-ªVLR +——-+——–+ ªßß
Gs +—-+ ªßß
+—–+ Gr ªßß
ªPSGSN+—-+—-+ßß
+—–+ ßß
ª Gb_ATTACH/RA_UPDATE_REQUEST ª ª ª ªßß
ª—————————–>ª ª ª ªßß
ª ª ª ª ªßß
ª ª ªßß
ª ª MAP_UPDATE_GPRS_LOCATION ªßß
ª ª—————————->ªßß
ª ª ª ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ª LOCATION ªßß
ª ª ª ª<————ªßß
ª ª ª ªMAP_CANCEL_ ªßß
ª ª ª ªLOCATION ack ªßß
ª ª ª ª————>ªßß
ª ª ª ª ªßß
ª ª MAP_ACTIVATE_TRACE_MODE ªßß
ª ª<—————————-ªßß
ª ª ªßß
ª ª MAP_ACTIVATE_TRACE_MODE ackªßß
ª ª—————————->ªßß
ª ª ªßß
ª ª MAP_INSERT_SUBSCRIBER_DATA ªßß
ª ª<—————————-ªßß
ª ª ªßß
ª ª MAP_INSERT_SUBSCR._DATA ackªßß
ª ª—————————->ªßß
ª ª ªßß
ª ª MAP_UPDATE_GPRS LOCATION ackªßß
ª ª<—————————-ªßß
ª ª ª ªßß
ª Gs_GPRS_LOCATION ª ªßß
ª ª——->ª ªßß
ª UPDATING ªMAP_UPDATE_LOCATION ªßß
ª ª ª——————->ªßß
ª ª ª ªßß
ª ª ª Note_1ªßß
ª ª ª MAP_INSERT ªßß
ª ª ª<——————-ªßß
ª ª ª SUBSCRIBER_DATA ªßß
ª ª ª ªßß
ª ª ª MAP_INSERT ªßß
ª ª ª——————->ªßß
ª ª ª SUBSCRIBER_DATA ackªßß
ª ª ª ªßß
ª ª ª MAP_UPDATE_LOCATIONªßß
ª ª ª<——————-ªßß
ª Gs_GPRS_LOCATION ª ack ªßß
ª ª<——-ª ªßß
ª UPDATING Ack ª ªßß
ª Gb_ATTACH/RA_UPDATE_ ª ª ªßß
ª<—————————–ª ª ªßß
ª REQUEST ack ª ª ªßß
ª ª ª ªßß
ª—————————–>ªGs_GPRS_TMSI_REALLOCATION ªßß
ª ª——->ª ªßß
ª ªCOMPLETEª ªßß

NOTE: The optional procedures in figure 19.1.1/14 apply here respectively. For details of the procedure on the Gs-interface, see GSM 09.18.

NOTE 1: Location Cancellation procedure toward the old VLR and optional tracing activation toward the new VLR are not represented on this figure.

Figure 19.1.1/15: Interface and services for GPRS location updating (Gs-interface installed)

19.1.1.2 Detailed procedure in the MSC

Figure 19.1.1/4 shows the MSC process for location register updating, containing macro calls for:

Receive_Open_Cnf subclause 25.1;

Authenticate_MSC subclause 25.5;

Check_IMEI_MSC subclause 25.6;

Obtain_IMSI_MSC subclause 25.8;

Trace_Subscriber_Activity_MSC subclause 25.9.

For structuring purposes, the second part of the process is placed into the macro Update Location Completion MSC, which is specific to this process (see figure 19.1.1/5).

When the MSC receives an A_LU_REQUEST (normal location updating, periodic location updating or IMSI attach) for a subscriber via the radio path, the MSC opens a dialogue to the VLR (MAP_OPEN request without any user specific parameters) and sends a MAP_UPDATE_LOCATION_AREA request, containing the parameters provided in the A_LU_REQUEST by the MS or BSS (for the parameter mapping see GSM 09.10).

If the dialogue is rejected or the VLR indicates a fallback to the version Vr procedure (see Receive_Open_Cnf macro in subclause 25.1), the MSC will send an A_LU_Rej towards the MS and terminate the procedure.

If the dialogue is accepted, the VLR will process this updating request, invoking optionally the MAP_PROVIDE_IMSI, MAP_TRACE_SUBSCRIBER_ACTIVITY, MAP_CHECK_IMEI or the MAP_AUTHENTICATE services first (see subclause 19.1.1.3 for initiation conditions, clause 25 for macros defining the handling of services in the MSC). For these macros there are two possible outcomes:

– a positive outcome, in which case the process continues waiting for the MAP_UPDATE_LOCATION_AREA confirmation; or

– an error is reported, in which case the process terminates (not applicable for Trace_Subscriber_Activity_MSC, which has only a positive outcome).

After receiving the MAP_UPDATE_LOCATION_AREA indication and handling these optional services, the VLR will decide whether a new TMSI need to be allocated to the subscriber or not.

Updating without TMSI reallocation

If the VLR does not reallocate the TMSI, the MSC will receive a MAP_UPDATE_LOCATION_AREA confirmation next (figure 19.1.1/4).

– if there are no parameters with this primitive, updating was successful and a confirmation will be sent to the MS;

– if there is an error cause contained in the received primitive, this cause will be mapped to the corresponding cause in the confirmation sent to the MS (see GSM 09.10 for the mapping of messages and causes).

Updating including TMSI reallocation

This case is covered by the macro Update Location Completion MSC given in figure 19.1.1/5. The MSC will upon receipt of a MAP_SET_CIPHERING_MODE request send a ciphering command towards BSS/MS. Thereafter, the MAP_FORWARD_NEW_TMSI indication and the MAP_UPDATE_LOCATION_AREA confirmation are received in arbitrary order, causing a confirmation on the radio path containing both new LAI and new TMSI. If the MAP_UPDATE_LOCATION_AREA confirmation contains any error, the updating request is rejected towards the MS:

– the MS will confirm receipt of the new TMSI, resulting in an empty MAP_FORWARD_NEW_TMSI response terminating the dialogue;

– if there is no confirmation received from the A-interface, the dialogue is terminated locally.

Before receiving a MAP_UPDATE_LOCATION_AREA confirmation, the MSC may receive a MAP_CHECK_IMEI indication. Handling of this indication, comprising IMEI request towards the MS and IMEI checking request towards the EIR, is given in the macro description in subclause 25.6. The result may either be to return to the state Wait for TMSI or to return to terminate.

Forwarding the Check SS Indication

When the VLR receives a MAP_FORWARD_CHECK_SS_INDICATION_Ind during the Update LOCATION Area process, this indication is relayed to the MS (see GSM 09.11 for detailed interworking) and the MSC remains in the current state.

Abort handling

If the VLR receives a MAP_U_ABORT, a MAP_P_ABORT or a premature MAP_CLOSE indication from the VLR during the location update process, the MSC terminates the process by sending an A_LU_CONFIRM containing the error cause Updating Failure to the MS. If the MSC had already confirmed the location update towards the MS, the process terminates without notification towards the A-interface.

If the MSC receives a MAP_NOTICE indication, it issues a MAP_CLOSE and terminates the A-interface dialogue, and the process terminates.

When the procedure is terminated abnormally on the radio path, the dialogue towards the VLR is aborted with the appropriate diagnostic information, and the procedure terminates.

Figure 19.1.1/4: Process Update_Location_Area_MSC

Figure 19.1.1/5: Macro Update_Location_Completion_MSC

19.1.1.3 Detailed procedure in the VLR

Figure 19.1.1/6 shows the process for location updating in the VLR. The following general macros are used:

Receive_Open_Ind subclause 25.1;

Receive_Open_Cnf subclause 25.1;

Authenticate_VLR subclause 25.5;

Check_IMEI_VLR subclause 25.6;

Insert_Subscriber_Data_VLR subclause 25.7;

Obtain_IMSI_VLR to request the IMSI for the subscriber subclause 25.8;

Activate_Tracing_VLR and Trace_Subscriber_Activity_VLR subclause 25.9,

Subscriber_Present_VLR subclause 25.10.

Additionally, the process specific macro

Location_Update_Completion_VLR, for optional initiation of Ciphering and TMSI reallocation as for acknowledgement of the MAP_UPDATE_LOCATION_AREA service, see figure 19.1.1/7,

and the optional process specific macro

VLR_Update_HLR to update the HLR and download subscriber data from there, see figure 19.1.1/8,

are invoked by this process.

Process Initiation

The location area updating process will be activated by receiving a MAP_UPDATE_LOCATION_AREA indication from the MSC. If there are parameter errors in the indication, the process is terminated with the appropriate error sent in the MAP_UPDATE_LOCATION_AREA response to the MSC. Else, The behaviour will depend on the subscriber identity received, either an IMSI or an TMSI.

Updating using IMSI

If the subscriber identity is an IMSI, the VLR checks whether the subscriber is unknown (i.e. no IMSI record). If so, the indicator "Location Information Confirmed in HLR" is set to "Not Confirmed" to initiate HLR updating later on. If the IMSI is known, the VLR checks whether the previous location area identification (LAI) provided in the primitive received from the MSC belongs to this VLR. If it does not, the indicator "Location Information Confirmed in HLR" is set to "Not Confirmed" to initiate HLR updating later on. The process may continue in both cases with the authentication check (see below).

Updating using TMSI

If the subscriber identity is a TMSI, the VLR checks whether the previous location area identification (LAI) provided in the primitive received from MSC belongs to an area of this VLR:

– if so, the TMSI will be checked. In case of location area change within a VLR, the TMSI should be known and the process may continue with the authentication check. Additionally, the indicator "Location Information Confirmed in HLR" is set to "Not confirmed" and the trace activity status is checked in case the target Location Area Id belongs to a new MSC.

– if the TMSI is not known or the subscriber data stored are incomplete, e.g. because the new LA belongs to a different VLR or due to VLR restoration, the indicator "Confirmed by VLR" is set to "Not Confirmed" to initiate HLR updating later on.

If the subscriber has not already been registered in the VLR, i.e. the previous LAI belongs to a different VLR, the indicators "Confirmed by HLR" and "Location Information Confirmed in HLR" are set to "Not Confirmed" and the VLR checks whether the identity of the Previous VLR (PVLR) is derivable from the previous LAI:

– if so, the IMSI and authentication parameters are requested from that VLR using the MAP_SEND_IDENTIFICATION service (see sheet 3 of figure 19.1.1/6), containing the subscriber’s TMSI.

– if the dialogue is rejected by the PVLR, the process continues requesting the IMSI from the MS. In case the PVLR reverts to the MAP version Vr dialogue, the VLR will perform the respective procedure of version Vr, too, with outcomes as for the current MAP version dialogue. Else, the process waits the for the respective MAP_SEND_IDENTIFICATION response from the PVLR:

– if the IMSI is received in that primitive, the process continues with the authentication check;

– if the IMSI is not received from the previous VLR for any reason, the dialogue to the PVLR is terminated and the IMSI will be requested from the MS;

– if a MAP_NOTICE indication is received from the PVLR, the dialogue will be terminated by sending a MAP_CLOSE indication, and the process continues requesting the IMSI from the MS;

– if a MAP_P_ABORT or MAP_U_ABORT indication is received from the MSC while waiting for the MAP_SEND_IDENTIFICATION response, the process is terminated;

– if a MAP_NOTICE indication is received from the MSC while waiting for the MAP_SEND_IDENTIFICATION response, the dialogue with the PVLR will be aborted by sending a MAP_U_ABORT indication (Remote Operations Failure), the dialogue with the MSC will be terminated by sending a MAP_CLOSE and the process terminates;

– if the identity of the previous VLR cannot be derived, the process continues by requesting the IMSI from the MS.

Requesting IMSI from the MS

For requesting the IMSI from the MS, the macro Obtain_IMSI_VLR described in subclause 25.8 is invoked (see figure 19.1.1/6 sheet 3). The outcome will be:

– OK, i.e. receipt of IMSI, in which case the process continues with the authentication check described below; or

– receipt of an Absent Subscriber error, indicating that the MS did not respond. In this case the System Failure error is reported in the MAP_UPDATE_LOCATION_AREA response towards the MSC and the updating process is terminated;

– aborted, i.e. the MSC dialogue has been released while waiting for the IMSI. In this case the updating process is terminated, too.

Authentication check

After a subscriber identity has been received, either in the service indication or by an explicit request procedure, the VLR checks whether authentication of this identity is required (see figure 19.1.1/6 sheet 2). If so, the authentication macro described in subclause 25.5 is invoked. The outcome of this macro can be:

– OK, i.e. the subscriber has been authenticated successfully, in which case the process is continued by setting the indicator "Confirmed by Radio Contact" to "Confirmed" and updating the location information held in the register. Thereafter,

– if one or both of the indicators "Confirmed by HLR" and "Location Information Confirmed in HLR" is set to "Not Confirmed", HLR updating is invoked first;

– otherwise the process continues with the Location Update Completion VLR macro described below, and the register is updated after successful completion of this macro.

– Illegal subscriber, i.e. there was a mismatch between expected and received SRES. The VLR checks whether authentication had been performed using the TMSI, in which case a new authentication attempt with IMSI may be started (VLR operator option).

– if so, the process continues by requesting the IMSI from the MS;

– else, the Illegal Subscriber error is reported in the MAP_UPDATE_LOCATION_AREA response.

– Unknown Subscriber, i.e. the IMSI given is unknown in the HLR. In this case, the subscriber data are deleted in the VLR and the same error is returned in the MAP_UPDATE_LOCATION_AREA response.

– Procedure error, i.e. the authentication process was unsuccessful for some other reason, e.g. because of a failure while requesting authentication information from the HLR. In this case the System Failure error is reported in the MAP_UPDATE_LOCATION_AREA response.

– Null, indicating impossible dialogue continuation (e.g. termination of the radio path), and leading to procedure termination without any further action.

Updating the HLR

If the HLR is to be updated, the VLR_Update_HLR macro described below is performed, with one of the following results (see sheet 4 of figure 19.1.1/6):

– OK, if HLR updating has been completed successfully. The response will contain the HLR number as parameter. Next, the Location_Update_Completion VLR macro is invoked (checking amongst others the roaming restrictions and regional subscription data), and upon successful outcome of this macro the register is updated and the process terminates.

– Roaming Not Allowed, qualified by PLMN Roaming Not Allowed if the location information indicates a PLMN for which the subscriber has no subscription or if the subscribers HLR cannot be reached (e.g. SS7 links to the subscribers HPLMN do not yet exist). In this case, the error Roaming Not Allowed qualified by PLMN Roaming Not Allowed is sent in the MAP_UPDATE_LOCATION_AREA response. The Subscriber Data are deleted in the VLR.

– if Roaming Not Allowed was qualified by the parameter Operator Determined Barring, the same value is sent in the MAP_UPDATE_LOCATION_AREA response to the MSC. The subscriber data are deleted in the VLR.

– Unknown Subscriber, if the subscriber is not known in the HLR. In this case, the subscriber data are deleted in the VLR, and the same error is sent in the MAP_UPDATE_LOCATION_AREA response.

– Procedure error, if there occurs some other error during HLR updating (e.g. abort of the connection to HLR):

– if the VLR can proceed in stand alone mode (VLR operator option), the Location Update Completion VLR macro is invoked to complete the VLR updating, and the indicator "Confirmed by HLR" remains unchanged;

– otherwise, the System Failure error is sent in the MAP_UPDATE_LOCATION_AREA response.

– Aborted, indicating that during HLR updating the MSC dialogue has been terminated. In this case, the updating process terminates without any further action.

The macro Location Update Completion VLR

This macro completes the VLR updating process. First, the VLR checks whether there is a roaming restriction for the subscriber (see figure 19.1.1/7):

– if the target LA is not allowed for the subscriber due to national roaming restrictions, the error Roaming Not Allowed with cause National Roaming Not Allowed is returned in the MAP_UPDATE_LOCATION_AREA response towards the MSC.

The subscriber data are not deleted from VLR, to avoid unnecessary HLR updating when roaming into other LAs of the same MSC. An indication that the subscriber is not allowed to roam is set in the VLR (LA Not Allowed Flag set to not allowed). As a consequence the subscriber is not reachable (checked for MTC, SMS and MT USSD) and cannot perform outgoing actions (checked in Access Management).

– if the target LA is not allowed for the subscriber because of regional subscription data (Zone Code List) or Roaming Restriction Due To Unsupported Feature stored in the VLR, the error Roaming Not Allowed with cause Location Area Not Allowed is returned towards the MSC in the MAP_UPDATE_LOCATION_AREA response.

Also in this case the subscriber data are not deleted from VLR, to avoid unnecessary HLR updating when roaming into other LAs of the same MSC. The LA Not Allowed Flag is set to not allowed in the VLR.

– if, after check of possible roaming restrictions, the subscriber is allowed to roam in the target LA, the LA Not Allowed Flag is set to allowed (if necessary), the IMSI Detached Flag is set to attached and the process SUBSCRIBER_PRESENT_VLR is started; this may inform the HLR that the subscriber is present again to retry an SMS delivery (see subclause 19.1.1.7). Thereafter, the VLR checks whether TMSI reallocation is required.

– if so, the VLR sends a MAP_SET_CIPHERING_MODE request containing:

– Ciphering Mode (version 1 GSM); and

– Kc, the cipher key to be used.

– if IMEI checking is required by the operator, the VLR will invoke the CHECK_IMEI_VLR macro (see subclause 25.6) to initiate both requesting IMEI from the MS and checking of this IMEI towards the EIR. As result either the service is granted, with process continuation as given below, or the service is rejected, in which case the VLR marks the subscriber as detached and returns an Illegal Equipment error in the MAP_UPDATE_LOCATION_AREA response before the process terminates.

– the VLR then sends a MAP_FORWARD_NEW_TMSI request containing the new TMSI, and the MAP_UPDATE_LOCATION_AREA response containing no parameters. The process will thereafter wait for the MAP_FORWARD_NEW_TMSI confirm. If this indicates a negative outcome, or if a MAP_P_ABORT or a MAP_U_ABORT primitive is received, the old TMSI is frozen. Subsequent accesses of the MS shall be accepted with both old or new TMSI.

– if TMSI reallocation is not required, the VLR invokes the CHECK_IMEI_VLR macro (see subclause 25.6) to initiate both requesting IMEI from the MS and checking of this IMEI towards the EIR, if IMEI Checking is required by the operator. As a result, either the service is granted, in which case the MAP_UPDATE_LOCATION_AREA response is sent without any parameters, or the service is rejected, in which case an Illegal Equipment error is returned in the MAP_UPDATE_LOCATION_AREA response, before the process terminates.

In all cases where the VLR sends a MAP_UPDATE_LOCATION_AREA response to the MSC, the dialogue towards the MSC is terminated by a MAP_CLOSE request with parameter Release Method indicating Normal Release.

The macro VLR Update HLR

This macro is invoked by the VLR process for location updating or by some other process handling the first subscriber access to the network after a register failure in order to perform HLR updating. If the VLR does not know the subscribers HLR (e.g. no IMSI translation exists as there are not yet any SS7 links to the subscribers HPLMN), the error Roaming Not Allowed with cause PLMN Roaming Not Allowed is returned.

If the subscribers HLR can be reached, the VLR opens a dialogue towards the HLR (see figure 19.1.1/8) by sending a MAP_OPEN request without any user specific parameters, together with a MAP_UPDATE_LOCATION request containing the parameters

– IMSI, identifying the subscriber;

– Location Info, containing the MSC number;

– VLR Number, the E.164 address of the VLR, to be used by the HLR when addressing the VLR henceforth (e.g. when requesting an MSRN);

– the LMSI as an VLR operator option; this is a subscriber identification local to the VLR, used for fast data base access.

In case the HLR rejects dialogue opening (see subclause 25.1), the VLR will terminate the procedure indicating procedure error. If the HLR indicates version Vr protocol to be used, the VLR will revert to the version Vr procedure concerning the dialogue with the HLR, with outcomes as for the current MAP version procedure.

If the HLR accepts the dialogue, the HLR will respond with:

– a MAP_INSERT_SUBSCRIBER_DATA indication, handled by the macro Insert_Subs_Data_VLR defined in subclause 25.7;

NOTE: The HLR may repeat this service several times depending on the amount of data to be transferred to the VLR and to replace subscription data in case they are not supported by the VLR.

– a MAP_ACTIVATE_TRACE_MODE indication, handled by the macro Activate_Tracing_VLR defined in subclause 25.9;

– a MAP_FORWARD_CHECK_SS_INDICATION_ind. This indication will be relayed to the MSC without any change of the current state.

– the MAP_UPDATE_LOCATION confirmation:

– if this confirmation contains the HLR Number, this indicates that the HLR has passed all information and that updating has been successfully completed. The VLR is updated using the parameters provided in the service and needed by the VLR. If certain parameters are not needed in the VLR, e.g. because some service is not supported, the corresponding data may be discarded. The VLR sets the "Confirmed by HLR" and "Location information confirmed in HLR" indicators to "Confirmed" to indicate successful subscriber data updating;

– if the confirmation contains an User error cause (Unknown Subscriber, Roaming Not Allowed or some other), the process calling the macro continues accordingly. In the last case, the subscriber data are marked as incomplete by setting the indicators "Confirmed by HLR" and "Location information confirmed in HLR" to "Not Confirmed". The same holds if there is a Provider error or a Data error in the confirmation;

– a MAP_P_ABORT, MAP_U_ABORT, or MAP_CLOSE indication. In these cases, the subscriber data are marked to be incomplete and the process continues as in the case of an error reported by the HLR;

– a MAP_NOTICE indication. Then, the dialogue towards the HLR is terminated, the subscriber data are marked to be incomplete and the process continues as in the case of an error reported by the HLR;

– if during HLR updating the VLR receives a MAP_P_ABORT, MAP_U_ABORT or a MAP_CLOSE indication concerning the MSC dialogue, the process is terminated by sending a MAP_U_ABORT request towards the HLR, and subscriber data are marked to be incomplete;

– if during HLR updating the VLR receives a MAP_NOTICE indication concerning the MSC dialogue, the dialogue with the MSC is terminated by sending a MAP_CLOSE, the dialogue with the HLR is terminated by sending a MAP_U_ABORT, subscriber data are marked to be incomplete and the process is terminated.

Abort Handling

If the VLR receives a MAP_NOTICE indication from the MSC while waiting for a MAP service primitive, the VLR will terminate the MSC dialogue by sending a MAP_CLOSE and any pending HLR dialogue by sending a MAP_U_ABORT (Remote Operations Failure), and the process is terminated.

Updating request via the Gs interface (optional for GPRS)

If Gs-interface is installed, the VLR may receive the Gs_GPRS_LOCATION_UPDATING_Request message from the SGSN for triggering an IMSI Attach or Location Updating procedure (see GSM 03.60 and 09.18).

Figure 19.1.1/16 shows the process for handling this Gs interface message.

The process specific macro

« GPRS_Location_Update_Completion_VLR » for optional initiation of TMSI reallocation as for acknowledgement of the Gs_GPRS_LOCATION_UPDATING_Request message (see figure 19.1.1/17),

and the optional process specific macro

« VLR_Update_GPRS_HLR » to update the HLR and download subscriber data from there (see figure 19.1.1/18), are invoked by this process.

On receipt of the Gs_GPRS_LOCATION_UPDATING_Request message, the VLR checks whether the subscriber is unknown (i.e. no IMSI record). If so, the indicator "Location Information Confirmed in HLR" is set to "Not Confirmed" to initiate HLR updating later on. The indicator "Confirmed by Radio Contact" is set to "Confirmed" and the location information held in the register is updated. If no VLR/SGSN association exits it is created (storage of SGSN address received) otherwise it is updated.

If the HLR is to be updated, the VLR_Update_GPRS_HLR macro described below is performed, with one of the following results (see sheet 2 of figure 19.1.1/18):

– OK, if HLR updating has been completed successfully. The response will contain the HLR number as parameter. Next, the GPRS_Location_Update_Completion VLR macro is invoked (checking amongst others the roaming restrictions and regional subscription data), and upon successful outcome of this macro the register is updated and the process terminates.

– Roaming Not Allowed, qualified by PLMN Roaming Not Allowed if the location information indicates a PLMN for which the subscriber has no subscription or if the subscribers HLR cannot be reached (e.g. SS7 links to the subscribers HPLMN do not yet exist). In this case, the appropriate error (see GSM 09.18) is sent to the SGSN in the Gs_GPRS_LOCATION_UPDATING Reject. The Subscriber Data are deleted in the VLR.

– if Roaming Not Allowed was qualified by the parameter Operator Determined Barring, the appropriate error (see GSM 09.18) is sent in the Gs_GPRS_LOCATION_UPDATING Reject to the SGSN. The subscriber data are deleted in the VLR.

– Unknown Subscriber, if the subscriber is not known in the HLR. In this case, the subscriber data are deleted in the VLR, and the appropriate error (see GSM 09.18) is sent in the Gs_GPRS_LOCATION_UPDATING Reject.

– Procedure error, if there occurs some other error during HLR updating (e.g. abort of the connection to HLR). In this case the appropriate error (see GSM 09.18) is sent in the Gs_GPRS_LOCATION_UPDATING Reject.

The macro GPRS Location Update Completion VLR

This macro completes the VLR updating process. First, the VLR checks whether there is a roaming restriction for the subscriber (see figure 19.1.1/17):

– if the target LA is not allowed for the subscriber due to national roaming restrictions, the appropriate error (see GSM 09.18) is sent in the Gs_GPRS_LOCATION_UPDATING Reject towards the SGSN.

The subscriber data are not deleted from VLR, to avoid unnecessary HLR updating when roaming into other LAs of the same MSC/VLR. An indication that the subscriber is not allowed to roam is set in the VLR (LA Not Allowed Flag set to not allowed). As a consequence the subscriber is not reachable (checked for MTC, SMS and MT USSD) and cannot perform outgoing actions (checked in Access Management).

– if the target LA is not allowed for the subscriber because of regional subscription data (Zone Code List) or Roaming Restriction Due To Unsupported Feature stored in the VLR, the appropriate error (see GSM 09.18) is returned to the SGSN in the Gs_GPRS_LOCATION_UPDATING Reject.

Also in this case the subscriber data are not deleted from VLR, to avoid unnecessary HLR updating when roaming into other LAs of the same MSC. The LA Not Allowed Flag is set to not allowed in the VLR.

– if, after check of possible roaming restrictions, the subscriber is allowed to roam in the target LA, the LA Not Allowed Flag is set to allowed (if necessary), the IMSI Detached Flag is set to attached and the process SUBSCRIBER_PRESENT_VLR is started; this may inform the HLR that the subscriber is present again to retry an SMS delivery (see subclause 19.1.1.7). Thereafter, the VLR checks whether TMSI reallocation is required.

– if so, the VLR sends the TMSI within the Gs_GPRS_LOCATION_UPDATING Accept message and Gs_GPRS_TMSI_REALLOCATION_Complete is expected.

– if TMSI reallocation is not required, the VLR sends the Gs_GPRS_LOCATION_UPDATING Accept message to the SGSN.

The macro VLR Update GPRS HLR

This macro is invoked by the VLR process for location updating (see GSM 03.60). If the VLR does not know the subscribers HLR (e.g. no IMSI translation exists as there are not yet any SS7 links to the subscribers HPLMN), the error Roaming Not Allowed with cause PLMN Roaming Not Allowed is returned.

If the subscribers HLR can be reached, the VLR opens a dialogue towards the HLR (see figure 19.1.1/18) by sending a MAP_OPEN request without any user specific parameters, together with a MAP_UPDATE_LOCATION request containing the parameters

– IMSI, identifying the subscriber;

– Location Info, containing the MSC number;

– VLR Number, the E.164 address of the VLR, to be used by the HLR when addressing the VLR henceforth (e.g. when requesting an MSRN);

– the LMSI as an VLR operator option; this is a subscriber identification local to the VLR, used for fast data base access.

In case the HLR rejects dialogue opening (see subclause 25.1), the VLR will terminate the procedure indicating procedure error. If the HLR indicates version Vr protocol to be used, the VLR will revert to the version Vr procedure concerning the dialogue with the HLR, with outcomes as for the current MAP version procedure.

If the HLR accepts the dialogue, the HLR will respond with:

– a MAP_INSERT_SUBSCRIBER_DATA indication, handled by the macro Insert_Subs_Data_VLR defined in subclause 25.7;

NOTE: The HLR may repeat this service several times depending on the amount of data to be transferred to the VLR and to replace subscription data in case they are not supported by the VLR.

– a MAP_ACTIVATE_TRACE_MODE indication, handled by the macro Activate_Tracing_VLR defined in subclause 25.9;

– a MAP_FORWARD_CHECK_SS_INDICATION_ind. This indication will not be relayed to the SGSN.

– the MAP_UPDATE_LOCATION confirmation:

– if this confirmation contains the HLR Number, this indicates that the HLR has passed all information and that updating has been successfully completed. The VLR is updated using the parameters provided in the service and needed by the VLR. If certain parameters are not needed in the VLR, e.g. because some service is not supported, the corresponding data may be discarded. The VLR sets the "Confirmed by HLR" and "Location information confirmed in HLR" indicators to "Confirmed" to indicate successful subscriber data updating;

– if the confirmation contains an User error cause (Unknown Subscriber, Roaming Not Allowed or some other), the process calling the macro continues accordingly. In the last case, the subscriber data are marked as incomplete by setting the indicators "Confirmed by HLR" and "Location information confirmed in HLR" to "Not Confirmed". The same holds if there is a Provider error or a Data error in the confirmation;

– a MAP_P_ABORT, MAP_U_ABORT, or MAP_CLOSE indication. In these cases, the subscriber data are marked to be incomplete and the process continues as in the case of an error reported by the HLR;

– a MAP_NOTICE indication. Then, the dialogue towards the HLR is terminated, the subscriber data are marked to be incomplete and the process continues as in the case of an error reported by the HLR.

Figure 19.1.1/6 (sheet 1 of 4): Process Update_Location_Area_VLR

Figure 19.1.1/6 (sheet 2 of 4): Process Update_Location_Area_VLR

Figure 19.1.1/6 (sheet 3 of 4): Process Update_Location_Area_VLR

Figure 19.1.1/6 (sheet 4 of 4): Process Update_Location_Area_VLR

Figure 19.1.1/7: Macro Location_Update_Completion_VLR

Figure 19.1.1/8 (sheet 1 of 2): Macro VLR_Update_HLR

Figure 19.1.1/8 (sheet 2 of 2): Macro VLR_Update_HLR

Figure 19.1.1/16 (sheet 1 of 2): Process GPRS_Update_Location_Area_VLR

Figure 19.1.1/16 (sheet 2 of 2): Process GPRS_Update_Location_Area_VLR

Figure 19.1.1/17: Macro GPRS_Location_Update_Completion_VLR

Figure 19.1.1/18 (sheet 1 of 2): Macro VLR_Update_GPRS_HLR

Figure 19.1.1/18 (sheet 2 of 2): Macro VLR_Update_GPRS_HLR

19.1.1.4 Detailed procedure in the HLR

When addressed by the VLR, the following macros are used by the process Update_Location_HLR:

– Receive_Open_Ind, defined in subclause 25.1;

– Check_indication, defined in subclause 25.2;

– Insert_Subs_Data_Framed_HLR, described in subclause 19.4.1;

– Control_Tracing_HLR, described in subclause 25.9;

and the processes Cancel_Location_HLR (see subclause 19.1.2) and Subscriber_Present_HLR (see subclause 19.1.1.7) are invoked.

The location updating process in the HLR is activated by receipt of a MAP_UPDATE_LOCATION indication (see figure 19.1.1/9):

– if there is a parameter problem in the indication, the error Unexpected Data Value is returned in the MAP_UPDATE_LOCATION response (see Check_indication macro defined in subclause 25.2); if the subscriber is not known in the HLR, the error Unknown Subscriber is returned in the response. In either case the process terminates;

– if Network Access Mode is set to “GPRS only” the error Unknown Subscriber is returned in the response. The process terminates;

– tracing shall be set to deactive in the VLR

– if the VLR address received in the MAP_UPDATE_LOCATION indication differs from the one actually stored against the subscriber, the Cancel_Location_HLR process is started to cancel the subscriber data in the stored VLR (see subclause 19.1.2).

The next action will be to check whether the subscriber is allowed to roam into the PLMN indicated by the VLR Number given in the MAP_UPDATE_LOCATION indication:

– if the subscriber is not allowed to roam into the PLMN, the error Roaming not Allowed with cause PLMN Roaming Not Allowed is returned in the MAP_UPDATE_LOCATION response, and the routing information stored (VLR number, MSC Number, LMSI) is deleted (deregistration);

– otherwise the HLR database will be updated with information received in the indication. The HLR sets the "MS purged for non-GPRS" flag to False and checks whether tracing is required for that subscriber. This is handled by the macro Control_Tracing_HLR described in subclause 25.9.

Thereafter, the macro Insert_Subs_Data_Framed_HLR described in subclause 19.4.1 is invoked. The outcome of this macro may be:

– aborted, in which case the process terminates;

– error, in which case the error System Failure is returned in the MAP_UPDATE_LOCATION response and the process terminates;

– OK, indicating successful outcome of downloading the subscriber data to the VLR.

The SUBSCRIBER_PRESENT_HLR process is then started to alert the Short Message Service Centre, if required (see subclause 19.1.7). Additionally, the MAP_FORWARD_CHECK_SS_INDICATION request is sent to inform the subscriber about an uncertain state of his SS-Data if this is needed due to previous HLR restoration (use of this service may be omitted as an HLR operator option).

The HLR number is then returned in the MAP_UPDATE_LOCATION response.

In all cases where the HLR sends a MAP_UPDATE_LOCATION response to the VLR, the dialogue towards the VLR is terminated by a MAP_CLOSE request with parameter Release Method indicating Normal Release.

Finally the process Update_Location_HLR sends a "Location updating complete" message to the process CCBS_Coordinator_HLR (specified in GSM 03.93 [107]) and the process terminates.

When addressed by the SGSN, the following macros are used by the process Update_GPRS_Location_HLR:

– Receive_Open_indication, defined in subclause 25.1;

– Check_indication, defined in subclause 25.2;

– Insert_Subs_Data_In_SGSN_Framed_HLR, described in subclause 19.4.x;

– Control_Tracing_HLR_with_SGSN, described in subclause 25.9;

and the processes Cancel_Location_HLR (see subclause 19.1.2) and Subscriber_Present_HLR (see subclause 19.1.1.7) are invoked.

The location updating process in the HLR is activated by receipt of a MAP_UPDATE_GPRS_LOCATION indication (see figure 19.1.1/19):

– if there is a parameter problem in the indication, the error Unexpected Data Value is returned in the MAP_UPDATE_LOCATION response (see Check_indication macro defined in subclause 25.2); if the subscriber is not known in the HLR, the error Unknown Subscriber (with diagnostic value set to “Imsi Unknown”) is returned in the response. In either case the process terminates;

– if Network Access Mode is set to “non-GPRS only” the error Unknown Subscriber (with diagnostic value set to “Gprs Subscription Unknown”) is returned in the response. The process terminates;

– tracing shall be set to deactive in the SGSN.

– if the SGSN number received in the MAP_UPDATE_GPRS_LOCATION indication differs from the one actually stored against the subscriber, the Cancel_Location_HLR process is started to cancel the subscriber data in the stored SGSN (see subclause 19.1.2).

The next action will be to check whether the subscriber is allowed to roam into the PLMN indicated by the SGSN Number given in the MAP_UPDATE_GPRS_LOCATION indication:

– if the subscriber is not allowed to roam into the PLMN, the error Roaming not Allowed with cause PLMN Roaming Not Allowed or ‘Operator determined Barring’, depending on the case, is returned in the MAP_UPDATE_GPRS_LOCATION response, and the routing information stored (SGSN number) is deleted (deregistration);

– otherwise the HLR database will be updated with information received in the indication. The HLR sets the "MS purged for GPRS" flag to False and checks whether tracing is required for that subscriber. This is handled by the macro Control_Tracing_HLR-with_SGSN described in subclause 25.9.

Thereafter, the macro Insert_Subs_Data_In_SGSN_Framed_HLR described in subclause 19.4.x is invoked. The outcome of this macro may be:

– aborted, in which case the process terminates;

– error, in which case the error System Failure is returned in the MAP_UPDATE_GPRS_LOCATION response and the process terminates;

– OK, indicating successful outcome of downloading the subscriber data to the SGSN.

The SUBSCRIBER_PRESENT_HLR process is then started to alert the Short Message Service Centre, if required (see subclause 19.1.7).

Finally the HLR number is returned in the MAP_UPDATE_GPRS_LOCATION response.

In all cases where the HLR sends a MAP_UPDATE_GPRS_LOCATION response to the SGSN, the dialogue towards the SGSN is terminated by a MAP_CLOSE request with parameter Release Method indicating Normal Release.

Figure 19.1.1/9 (sheet 1 of 2): Process Update_Location_HLR

Figure 19.1.1/9 (sheet 2 of 2): Process Update_Location_HLR

Figure 19.1.1/19 (sheet 1 of 2): Process Update_GPRS_Location_HLR

Figure 19.1.1/19 (sheet 2 of 2): Process Update_GPRS_Location_HLR

19.1.1.5 Send Identification

19.1.1.5.1 General

This service is invoked by a VLR when it receives a MAP_UPDATE_LOCATION_AREA indication containing a LAI indicating that the subscriber was registered in a different VLR (henceforth called the Previous VLR, PVLR). If the identity of the PVLR is derivable for the VLR (usually if both are within the same network), the IMSI and authentication sets are requested from the PVLR (see subclause 19.1.1.3), using the service described in subclause 8.1.4.

+—-+ B +—-+ G +—-+
ªMSC ª———–ª————ªVLR ª——-+———ªPVLRª
+—-+ +—-+ +—-+
ª ª ªßß
ª MAP_UPDATE_LOCATION_ ª ªßß
ª—————————->ª ªßß
ª AREA ª MAP_SEND_ ªßß
ª ª———————->ªßß
ª ª IDENTIFICATION ªßß
ª ª ªßß
ª ª MAP_SEND_ ªßß
ª ª<———————-ªßß
ª ª IDENTIFICATION ack ªßß
ª ª ªßß

NOTE: The service shown in dotted lines indicates the trigger provided by other MAP signalling.

Figure 19.1.1/10: Interface and services for Send Identification

19.1.1.5.2 Detailed procedure in the VLR

The VLR procedure is part of the location area updating process described in subclause 19.1.1.3, see also figure 19.1.1/6 sheet 3.

19.1.1.5.3 Detailed procedure in the PVLR

On receipt of a dialogue request for the Send Identification procedure, (see Receive_Open_Ind macro in subclause 25.1), the PVLR will:

– terminate the procedure in case of parameter problems;

– revert to the MAP version Vr procedure in case the VLR indicated version Vr protocol; or

– continue as below, if the dialogue is accepted.

If the PVLR process receives a MAP_NOTICE indication, it terminates the dialogue by sending a MAP_CLOSE request.

If the PVLR process receives a MAP_SEND_IDENTIFICATION indication from the VLR (see figure 19.1.1/11), it checks whether the subscriber identity provided is known:

– if so, the IMSI and – if available – authentication parameters for the subscriber are returned in the MAP_SEND_IDENTIFICATION response;

– if not, the error Unidentified Subscriber is returned in the MAP_SEND_IDENTIFICATION response.

In all cases where the PVLR sends a MAP_SEND_IDENTIFICATION response to the VLR, the dialogue towards the VLR is terminated by a MAP_CLOSE request with parameter Release Method indicating Normal Release.

Figure 19.1.1/11: Process Send_Identification_PVLR

19.1.1.6 The Process Update Location VLR

This process is started by some other MAP user process in case the HLR need to be updated due to previous network failure. It is invoked when the subscriber accesses the network, e.g. for mobile originated call set-up, response to paging or supplementary services handling. Here, location updating consists only of invoking the macro VLR_Update_HLR described above (see subclause 19.1.1.3), which performs HLR updating and downloading of subscriber data.

If updating is successful (OK) the HLR Number is received in the MAP_UPDATE_LOCATION confirm primitive and the process terminates.

If one of the errors Roaming not Allowed or Unknown Subscriber is received instead, all subscriber data are deleted from the VLR before the process terminates.

In case some other error occurs during HLR updating, the process simply terminates. Note, in all error cases the initiating restoration flags in VLR remain false, therefore a new HLR updating attempt will be started later on.

NOTE: This process will be performed independent from the calling process, no coordination is required.

Figure 19.1.1/12: Process UL_VLR

19.1.1.7 The Process Subscriber Present HLR

The process Subscriber Present HLR is started by the location updating process in HLR to perform actions required for short message alerting. The process checks the Message Waiting Data flag, and if this is set, the macro Alert_Service_Centre_HLR defined in subclause 25.10 is invoked. This macro will alert all service centres from which there are short messages waiting for this subscriber.

Figure 19.1.1/13: Process Subscriber_Present_HLR

19.1.1.8 Detailed procedure in the SGSN

Figure 19.1.1/20 shows the MAP process for updating of the SGSN. The following general macros are used:

Receive_Open_Cnf subclause 25.1;

Insert_Subscriber_Data_SGSN subclause 25.7;

Activate_Tracing_SGSN subclause 25.9;

Subscriber_Present_SGSN subclause 25.10.

Process Initiation

The location area updating process will be activated by receiving a MAP_UPDATE_LOCATION_AREA indication from the MSC. If there are parameter errors in the indication, the process is terminated with the appropriate error sent in the MAP_UPDATE_LOCATION_AREA response to the MSC. Else, The behaviour will depend on the subscriber identity received, either an IMSI or an TMSI.

The location updating process

The MAP process receives an « Update HLR request » from the relevant process in the SGSN (see GSM 03.60) to perform HLR updating. If the SGSN does not know the subscribers HLR (e.g. no IMSI translation exists as there are not yet any SS7 links to the subscribers HPLMN), the « Update HLR negative response » with error Roaming Not Allowed (cause PLMN Roaming Not Allowed) is returned to the requesting process.

If the subscribers HLR can be reached, the SGSN opens a dialogue towards the HLR by sending a MAP_OPEN request without any user specific parameters, together with a MAP_UPDATE_GPRS_LOCATION request containing the parameters

– IMSI, identifying the subscriber;

– SGSN Address and SGSN number;

In case the HLR rejects dialogue opening (see subclause 25.1) or indicates version Vr protocol to be used, the SGSN will terminate the process indicating « Update HLR negative response » to the requesting process.

If the HLR accepts the dialogue, the HLR will respond with:

– a MAP_INSERT_SUBSCRIBER_DATA indication, handled by the macro Insert_Subs_Data_SGSN defined in subclause 25.7;

NOTE: The HLR may repeat this service several times depending on the amount of data to be transferred to the SGSN and to replace subscription data in case they are not supported by the SGSN.

– a MAP_ACTIVATE_TRACE_MODE indication, handled by the macro Activate_Tracing_SGSN defined in subclause 25.9;

– the MAP_UPDATE_GPRS_LOCATION confirmation:

– if this confirmation contains the HLR Number, this indicates that the HLR has passed all information and that updating has been successfully completed. The « Update HLR response » message is returned to the requesting process for completion of the SGSN updating (see GSM 03.60).

– if the confirmation contains an User error cause (Unknown Subscriber, Roaming Not Allowed or some other), the corresponding error is returned to the requesting process in the « Update HLR negative response ».

– a MAP_P_ABORT, MAP_U_ABORT, or MAP_CLOSE indication. In these cases, the corresponding error is returned to the requesting process in the « Update HLR negative response ».

– a MAP_NOTICE indication. Then, the dialogue towards the HLR is terminated, and the « HLR Update negative response » with the appropriate error is returned to the requesting process.

Figure 19.1.1/20 (sheet 1 of 2): Process SGSN_Update_HLR

Figure 19.1.1/20 (sheet 2 of 2): Process SGSN_Update_HLR