9.3.1 Procedures for Mobility management for CS subscriber

23.0783GPPCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4Release 17Stage 2TS

The different procedures for Mobility Management are shown in Figures 9.2-1 to 9.2-5.

Figure 9.2-1: Location Update within a single VLR Service Area. (The VLR Service area may be in the HPLMN or in the VPLMN.);

Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area. (Both VLR Service Areas are in the HPLMN or in the same VPLMN.);

Figure 9.2-3: Location Update from one PLMN to another PLMN;

– update from HPLMN to VPLMN;

– update from VPLMN to HPLMN;

– update from one VPLMN to another VPLMN.

Figure 9.2-4: IMSI Detach (in HPLMN or in VPLMN);

– explicit detach (the MS has been switched off by the subscriber);

– implicit detach (the network has not received a periodic paging update from the MS and assumes that the MS is switched off or unreachable).

Figure 9.2-5: IMSI Attach (in HPLMN or in VPLMN);

– attach (the MS has been switched on by the subscriber – subscription data is still available in the VLR, no location update is needed).

Figure 9.2-1: Location Update within a single VLR Service Area

Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area

Figure 9.2-3: Location Update from one PLMN to another PLMN

Figure 9.2-4: IMSI Detach (implicit/explicit)

Figure 9.2-5: IMSI Attach

When a Mobility Management Event has taken place and the processing has been completed, then the VLR may find it necessary to send a notification to the gsmSCF. The processing of the Mobility Management event in the VLR is not suspended by the sending of the notification nor is it in any way affected by the notification.

The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have M‑CSI without O‑CSI or VT‑CSI.

The sending of a Mobility Management event notification is subscription based.

Refer to subclause 9.2.1 for a description of M‑CSI and the different Mobility Management events that may lead to a notification to the gsmSCF.

9.3.1.1 Procedure descriptions

9.3.1.1.1 Procedure Set_Notification_Type

This procedure is called from process Update_Location_VLR in 3GPP TS 23.012 [10]. It checks the information element ‘Location Update Type’, which the VLR receives from the MSC via MAP_UPDATE_LOCATION_AREA service. This element identifies the type of Location Update requested by the mobile station.

The possible values of this parameter are specified in 3GPP TS 24.008 [30].

The type of Location Update that was requested by the mobile station determines which Mobility Management notification information flow shall be sent to the gsmSCF.

The values ‘Periodic Updating’ and ‘Reserved’ shall not lead to a Mobility Management notification to the gsmSCF.

Figure 9.-1a: Procedure Set_Notification_Type (sheet 1)

9.3.1.1.2 Procedure Notify_gsmSCF

This procedure is called from the process ‘Update_Location_Area_VLR’ and process ‘Detach_IMSI_VLR’ in 3GPP TS 23.012 [10]. It is also called from the process ‘Update_Location_VLR’ in 3GPP TS 29.002 [34].

The calling process passes on the variable ‘Notify’ to the procedure ‘Notify_gsmSCF’. This variable indicates which Mobility Management notification may be necessary to be sent to the gsmSCF. If this variable has a value NULL, then no notification shall be sent to the gsmSCF.

If a notification may be necessary to be sent to the gsmSCF, then the procedure checks the presence of M‑CSI.

– If M‑CSI is present and the Mobility Management event indicated in the variable ‘Notify’ is marked in M‑CSI, then a notification shall be sent to the gsmSCF.

– If M‑CSI is not present or the Mobility Management event indicated in the variable ‘Notify’ is not marked in M‑CSI, then no notification shall be sent to the gsmSCF.

Figure 9.3-1: Procedure Notify_gsmSCF (sheet 1)