19.3.2 HLR fault recovery procedures

29.0023GPPMobile Application Part (MAP) specificationRelease 17TS

19.3.2.1 General

For the HLR, periodic back-up of data to non-volatile memory is mandatory.

Data that have been changed after the last back-up and before the restart of the HLR cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the HLR fault at the first authenticated radio contact with the MS concerned.

As an implementation option, a notification can be forwarded to the MS to alert the subscriber to check the parameters for supplementary services that allow subscriber controlled input (MAP_FORWARD_CHECK_SS_INDICATION service). If the VLR receives this notification from the HLR it shall forward the notification to the MS. If the Gs-interface is implemented the VLR shall not forward this notification.

A restoration procedure may also be triggered for IMSI records that shares subscription data with other IMSI records when the shared subscription data is modified, added or deleted. This option presumes the support of Reset-IDs.

The message flow for HLR restoration for a non-GPRS subscriber is shown in figure 19.3.2/1.

The message flow for HLR restoration for a GPRS subscriber is shown in figure 19.3.2/2.

1) MAP_RESET_req/ind

2) MAP_PROCESS_ACCESS_REQUEST_req/ind

3) MAP_UPDATE_LOCATION_req/ind

4) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2)

5) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2)

6) MAP_INSERT_SUBSCRIBER_DATA_req/ind

7) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf

8) MAP_UPDATE_LOCATION_rsp/cnf

9) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1)

10) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1)

NOTE 1: Services printed in italics are optional.

NOTE 2: If subscriber tracing is active in the HLR.

Steps 2 to 10 may be skipped if the procedure is used to update shared subscription data.

Figure 19.3.2/1: Message flow for HLR restoration (non-GPRS)

1) MAP_RESET_req/ind

2) MAP_UPDATE_GPRS_LOCATION_req/ind

3) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2)

4) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2)

5) MAP_INSERT_SUBSCRIBER_DATA_req/ind

6) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf

7) MAP_UPDATE_GPRS_LOCATION_rsp/cnf

NOTE 1: Services printed in italics are optional.

NOTE 2: If subscriber tracing is active in the HLR.

Steps 2 to 7 may be skipped if the procedure is used to update shared subscription data.

Figure 19.3.2/2: Message flow for HLR restoration (GPRS)

19.3.2.2 Procedure in the HLR

The MAP process in the HLR to notify the relevant serving nodes that the HLR has restarted is shown in figure 19.3.2/3.

The SGSN address list includes one instance of the address of each SGSN in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart.

The VLR address list includes one instance of the address of each VLR in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart.

The MAP process in the HLR to notify a VLR that the HLR has restarted is shown in figure 19.3.2/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:

Receive_Open_Cnf see clause 25.1.2.

The MAP process in the HLR to notify an SGSN that the HLR has restarted is shown in figure 19.3.2/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:

Receive_Open_Cnf see clause 25.1.2.

19.3.2.3 Procedure in the VLR

The MAP process in the VLR to handle a notification that an HLR has restarted is shown in figure 19.3.2/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:

Receive_Open_Ind see clause 25.1.1.

When Reset-IDs are not supported or not present in the MAP_RESET indication, the VLR uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart.
When Reset-IDs are supported and present in the MAP_RESET indication, the VLR uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records.

The task "Update Data" includes any required action to let the update come into effect.
If the update of shared subscription data requires only local updates in the VLR (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring).
If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE.

NOTE: The rational for the recommendation to defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user’s activity.

To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the VLR may take a maximum operator configuration-depending time.

19.3.2.4 Procedure in the SGSN

The MAP process in the SGSN to handle a notification that an HLR has restarted is shown in figure 19.3.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:

Receive_Open_Ind see clause 25.1.1.

When Reset-IDs are not supported or not present in the MAP_RESET indication, the SGSN uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart.
When Reset-IDs are supported and present in the MAP_RESET indication, the SGSN uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records.
The task "Update Data" includes any required action to let the update come into effect.

If the update of shared subscription data requires only local updates in the SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring).
If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE.

NOTE: The rational for the recommendation to defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user’s activity.

To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the SGSN may take a maximum operator configuration-depending time.

Figure 19.3.2/3: Process Restart_HLR

Figure 19.3.2/4: Process Send_Reset_To_VLR_HLR

Figure 19.3.2/5: Process Send_Reset_To_SGSN_HLR

Figure 19.3.2/6: Process Receive_Reset_VLR

Figure 19.3.2/7: Process Receive_Reset_SGSN