4.1.2 Detailed procedure in the VLR

23.0123GPPLocation management proceduresRelease 17TS

4.1.2.1 Process Update_Location_Area_VLR

General comment: at any stage in the location updating process the MSC may receive an indication from the BSS that the MM transaction has been released. The MSC then sends an Abort signal to the VLR. Upon receipt of this message, the VLR shall follow one of two possible courses of action.

The two possible courses of action and the conditions determining which course shall be taken are as follows:

1. If a successfully authenticated radio connection is already established before the Abort message is received, the VLR shall ignore the message.

2. If a successfully authenticated radio connection has not been established before the Abort message is received, the VLR shall abort the Update Location Area process and return to the idle state.

Sheet 1: the location area updating process will be activated by receiving an 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 Update Location Area response to the MSC. Else, the behaviour will depend on the subscriber identity received, either an IMSI or a TMSI.

The Automatic Device Detection (ADD) function is an optional feature that allows the HLR to be updated with the current User Equipment (IMEISV) and thus enables the network to configure the subscriber’s equipment based on a predefined profile. The mechanism for the IMEISV retrieval by device management system (either from HLR or VLR) is outside the scope of this specification. As an optimisation, the VLR may optionally store whether or not the HLR supports the ADD feature and use this information to decide whether or not to send an update to the HLR.

The Paging Area function is an optional feature that allows the HLR to be updated with the current Paging Area (PgA) (see clause 2.6). If supported, whenever the paging area changes, the VLR shall send a MAP Update Location request with the Paging Area parameter set to the location areas belonging to the new paging area. The Paging Area is then sent by the HLR (if available) to the VLR in the MAP Provide Roaming Number and may be used for paging optimisation after a MSC/VLR restart (see 3GPP TS 23.018 [5a]).

Sheet 1: The usage of a Hop Counter is an optional optimization.

Sheet 2: at the decision "HLR updating required?" the "True" branch shall be taken if and only if one or more of the following conditions is true:

(1) Location Info Confirmed in HLR is false.

(2) Data Confirmed by HLR is false.

Sheet 2: : The execution of the test "HLR supports ADD?" and the action "set: skip subscriber data update" is an optional optimisation and depends on the presence of the relevant indication from the HLR that ADD functionality is supported. If this optimisation is not supported on the VLR or no indication is received, both are bypassed in which case processing continues at connector 4.

Sheet 2: The execution of the test "HLR supports PgA?" and the action "set: skip subscriber data update" depends on the presence of the relevant indication from the HLR that PgA functionality is supported.

Sheet 2: The "Subscriber data dormant" flag is an optional parameter that shall at least be supported by VLR implementing the Mobile Terminating Roaming Retry feature (see 3GPP TS 23.018 [5a]). A VLR not supporting this flag shall behave as if the flag is set to false.

Sheet 2: A VLR supporting the Mobile Terminating Roaming Retry feature sets the "Cancel Location received" flag to false after authenticating the radio connection. This is used to determine whether to trigger MT roaming retry upon receipt of an incoming call, see clause 7.3.2.1 of 3GPP TS 23.018 [5a].

Sheet 3: the procedure Obtain_IMSI_VLR is specified in 3GPP TS 23.018 [5a].

The type of Location Update is retrieved in 3GPP TS 23.078 [11] procedure ‘Set_Notification_Type’ and is returned into the ‘Notify’ variable; this information is necessary for the CAMEL Mobility Management event notification procedure 3GPP TS 23.078 [11] ‘Notify_gsmSCF’.

Figure 4.1.2.1 (sheet 1 of 3): Process Update_Location_Area_VLR

Figure 4.1.2.1 (sheet 2 of 3): Process Update_Location_Area_VLR

Figure 4.1.2.1 (sheet 3 of 3): Process Update_Location_Area_VLR

Figure 4.1.2.1 (sheet 4 of 4): Process Update_Location_Area_VLR

4.1.2.1a Procedure Retrieve_IMEISV_If_Required

The decision box "received IMEISV = stored IMEISV" takes the "No" exit if no IMEISV is stored.

Figure 4.1.2.1A: Procedure Retrieve_IMEISV_If_Required

4.1.2.2 Procedure Authenticate_VLR

Sheet 2: The procedure Obtain_IMSI_VLR is specified in 3GPP TS 23.018 [5a].

Figure 4.1.2.2 (sheet 1 of 2): Procedure Authenticate_VLR

Figure 4.1.2.2 (sheet 2 of 2): Procedure Authenticate_VLR

4.1.2.3 Procedure Location_Update_Completion_VLR

Sheet 1: Decision "National Roaming Restrictions Exist?" distinguishes whether or not the subscriber is allowed service in the target LA, based on the current location of the MS and the VLR’s knowledge of other networks. The "Yes" branch results in the sending of "Update Location Area Negative Response" toward the MSC (and the MS), with cause "National Roaming Not Allowed." However, subscriber data shall not be deleted from the VLR. This is to avoid unnecessary HLR updating should the subscriber be allowed subsequently to roam in other LAs of the same MSC.

Sheet 1: Decision "Access-Restriction-Data permits current RAT?" performs a check on the subscriber’s AccessRestrictionData information received from the HLR and either allows the operation to continue or rejects the Location Update. The decision is taken according to the following:

-If AccessRestrictionData value includes "GERAN not allowed" and the LA/RA, where the MS accesses the network, is served by GERAN, then the subscriber’s access is not permitted.

-If AccessRestrictionData value includes "UTRAN not allowed" and the LA/RA, where the MS accesses the network is served by UTRAN, then the subscriber’s access is not permitted.

Sheet 1: When the Location Update is not allowed because the subscriber access is restricted due to Administrative Restriction of Subscribers’ Access feature, the flow results in the sending of "Update Location Area Negative Response" toward the MSC (and the MS). The recommended cause code is "RAT not allowed", but cause codes "PLMN not allowed" or "National Roaming Not allowed" may also be used based on operator configuration and the required MS behaviour.

Note: For the mapping of MAP Process cause code values to values on the MM protocol interface see 3GPP TS 29.010 [14].

For the MS behaviour determined on the received cause code see 3GPP TS 24.008[13].

Sheet 1: Decision "Roaming restriction due to Unsupported Feature received in subscriber data?" distinguishes whether or not the subscriber data received from the HLR indicates "roaming restriction due to unsupported feature." The "Yes" branch results in the sending of "Update Location Area Negative Response" toward the MSC (and the MS), with cause "National Roaming Not Allowed." However, subscriber data shall not be deleted from the VLR. This is to avoid unnecessary HLR updating should the subscriber be allowed subsequently to roam in other LAs of the same MSC.

Sheet 1: Decision "Regional subscription restriction" distinguishes whether or not the subscriber is allowed service in the target LA, which the VLR deduces based on regional subscription information received from the HLR. The "Yes" branch results in the sending of "Update Location Area Negative Response" toward the MSC (and the MS), with cause "location area not allowed." However, subscriber data shall not be deleted from the VLR. This is to avoid unnecessary HLR updating should the subscriber be allowed subsequently to roam in other LAs of the same MSC.

Sheet 1: Causes "National Roaming Not Allowed" and "RAT not allowed" lead to sending of cause #13 (roaming not allowed in the Location Area) and #15 (no suitable cells in Location Area) respectively to the MS (see 3GPP TS 29.010 [14]). On receipt of cause #13 or #15 the TMSI and LAI currently stored in the MS are not deleted (see 3GPP TS 24.008 [13]). As an option (referred-to as "TMSI option"), for these two reject causes, the VLR may forward a new TMSI (with the new LAI) together with the sending of "Update Location Area Negative Response" toward the MSC. The Location Updating Reject is sent to the MS after forwarding of the new TMSI (and new LAI) (see clause 4.1.1.1).

This optional TMSI allocation (with new LAI) ensures that:

– a pre-Rel-8 MS will initiate a location updating if it roams back to the previous Location Area (allowed), i.e. to the location area whose identity is already stored in the MS, after having received the reject cause #13 or #15; otherwise the location updating may not be initiated and mobile terminated calls may not be delivered until the next mobile originated activity or periodic location update (see 3GPP TR 29.994 [18]).

– the next location update enables the new VLR to address the correct previous VLR (which controls the not allowed Location Area) and to obtain the right IMSI and security context; otherwise a wrong VLR is addressed (corresponding to the TMSI/LAI of the VLR that controlled the previous allowed LA) and a wrong IMSI / security context would be obtained if the TMSI was reallocated.

Sheet 2: If the MS performs a location update procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and if the VLR needs to retrieve the CSG Subscription Data of the MS from the CSS, the VLR shall initiate the Update VCSG Location Procedure with the CSS and store the CSG Subscription data if any received from the CSS. The stored CSG Subscription data is used by VLR to perform access control for the MS.

If the Update VCSG Location Procedure fails, the VLR continues the location update procedure.

Sheet 3: The procedure Check_IMEI_VLR is specified in 3GPP TS 23.018 [5a].

Figure 4.1.2.3 (sheet 1 of 3): Procedure Location_Update_Completion_VLR

Figure 4.1.2.3 (sheet 2 of 3): Procedure Location_Update_Completion_VLR

Figure 4.1.2.3 (sheet 3 of 3): Procedure Location_Update_Completion_VLR

4.1.2.4 Procedure Update_HLR_VLR

Sheet 1: The procedure Check_User_Error_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TS 23.116 [7].

Sheet 1: A VLR supporting the MT Roaming Forwarding feature (see 3GPP TS 23.018 [5a]) includes the "MTRF supported" flag in the MAP Update Location message sent to the HLR. After sending this message, the VLR may receive at any time an MT Provide Roaming Number request including the MTRF Indicator from the old VLR in the WAIT_FOR_DATA state (not represented in the SDL).

Figure 4.1.2.4 (sheet 1 of 1): Procedure Update_HLR_VLR

4.1.2.5 Procedure Insert_Subs_Data_VLR

The procedure Check_Parameters is specified in 3GPP TS 23.018 [5a].

Figure 4.1.2.5 (sheet 1 of 1): Procedure Insert_Subs_Data_VLR

4.1.2.6 Procedure Activate_Tracing_VLR

The procedure Check_Parameters is specified in 3GPP TS 23.018 [5a].

Figure 4.1.2.6 (sheet 1 of 1): Procedure Activate_Tracing_VLR

4.1.2.7 Process Send_Identification_PVLR

Sheet 1: The procedure Check_Parameters is specified in 3GPP TS 23.018 [5a].

Sheet 1: Decision "IuFlex applied?" distinguishes whether or not the PVLR applies "Intra Domain Connection of RAN Nodes to Multiple CN Nodes" as described in 3GPP TS 23.236 [12]. If this feature is applied, the VLR shall extract the NRI from the TMSI and attempt to derive the VLR address of the VLR where the subscriber was previously registered, denoted in the following as the "real PVLR".

Sheet 1: Decision "Result = success?" distinguishes whether the NRI could be successfully converted into the "real PVLR" address. In case of successful conversion, the PVLR shall relay the received Send_Identification message to the "real PVLR" as specified in 3GPP TS 23.236 [12]. The new VLR and the "real PVLR" shall not perceive that relaying is being performed, i.e. they shall not notice the presence of the relaying node. The actual mechanism used to perform the relay is an implementation choice. A possible mechanism is described in clause 4.1.2.9.

Sheet 1: If supported by the VLR, the "Subscriber data dormant" flag shall be set to true to reflect that the MS has moved outside the VLR area. A VLR not supporting this flag shall behave as if the flag is set to false.

NOTE: HLRs compliant with this release of the specification and supporting mobile terminating roaming retry and Super-Charger will always send a Cancel Location message to the old VLR even in a supercharged network (see 3GPP TS 23.018 [5a]). HLRs compliant with an earlier release of the specification may not always send a Cancel Location message in a supercharged network. To support mobile terminating roaming retry with such HLR implementations, the old VLR can start a timer upon receipt of the MAP Send Identification message while on-going paging to trigger the sending of an internal Cancel Location to the old MSC and thus the sending of a MAP Resume Call Handling message by the old MSC to the GMSC after the sending of the MAP Update Location by the new VLR to the HLR.

Figure 4.1.2.7 (sheet 1 of 1): Process Send_Identification_PVLR

4.1.2.8 Process Trace_Subscriber_Activity_VLR

Figure 4.1.2.8 (sheet 1 of 1): Process Trace_Subscriber_Activity_VLR

4.1.2.9 Procedure Perform Relaying

The relay may be performed by opening a new MAP dialogue to the "real PVLR" and keeping it linked to the existing MAP dialogue between the new VLR and the PVLR. Every message received for one of these dialogues shall be relayed to the other one, until the two dialogues are closed. This mechanism is described in figure 4.1.2.9.

In order to improve the signalling efficiency of the relaying function, alternative mechanisms may be implemented as long as no difference shall be perceived by the new VLR and the "real PVLR".

The usage of a Hop Counter is an optional optimization.

Figure 4.1.2.9 (sheet 1 of 1): Procedure Perform Relaying

4.1.2.10 Procedure Update_VCSG_Location_VLR

The VLR uses this procedure to register the MS with the CSG Subscriber Server and may retrieve the CSG subscription data from CSS.

When using this procedure, the VLR sends an Update VCSG Location request towards the CSS, and waits for the answer from the CSS.

– If the VLR receives a negative Update VCSG Location response from the CSS, the VLR sets the result with failure cause and ends this procedure.

– If the VLR receives an Insert VCSG Subscriber Data request, it shall update the CSG Subscription Data and returns a response message to CSS. The CSG Subscription Data received from the CSS is stored and managed in the VLR independently from the CSG Subscription Data received from the HLR. If the same CSG ID exists in both CSG Subscription Data from the CSS and CSG Subscription Data from the HLR, the CSG Subscription Data from the HLR shall take precedence over the CSG Subscription Data from the CSS.

– If the VLR receives a successful Update VCSG Location ACK message, it ends the procedure.

– If the successful Update VCSG Location ACK message indicates that there is no CSG Subscription data, the VLR shall not send any subsequent Update VCSG Location Request message to the CSS.

Figure 4.1.2.10 (sheet 1 of 1): Procedure Update_VCSG_Location_VLR

4.1.2.11 Procedure Insert_VCSG_Subs_Data_VLR

Whenever the CSG subscription data is changed for a MS in the CSS, and the changes affect the CSG subscription data stored in the VLR, the CSS shall inform the VLR about the changes by the means of an Insert VCSG Subscriber Data request (IMSI, CSG subscription data) which initiates the procedure Insert_VCSG_Subs_Data_VLR.

The VLR checks the received parameters. If the MS is unknown, the VLR shall send a negative Insert VCSG Subscriber Data response message to the CSS that deregisters the VLR for this MS. If the MS is known, the VLR shall update the stored CSG subscription data and acknowledge the Insert VCSG Subscriber Data request by returning an Insert VCSG Subscriber Data Ack.

The CSG Subscription Data received from the CSS is stored and managed in the VLR independently from the CSG Subscription Data received from the HLR. The Insert VCSG Subscriber Data procedure shall only affect the CSG Subscription Data received from the CSS.

If the same CSG ID exists in both CSG Subscription Data from the CSS and CSG Subscription Data from the HLR, the CSG Subscription Data from the HLR shall take precedence over the CSG Subscription Data from the CSS.

Figure 4.1.2.11 (sheet 1 of 1): Procedure Insert_VCSG_Subs_Data_VLR