19.2.2 Procedure in MSC‑A

29.0023GPPMobile Application Part (MAP) specificationRelease 17TS

This clause describes the inter-MSC handover procedure in MSC‑A; it covers basic inter-MSC handover to another MSC (MSC‑B) and subsequent inter-MSC handover to a third MSC (MSC‑B’) or back to the controlling MSC (MSC‑A).

The MAP process in MSC‑A to handle inter-MSC handover is shown in figure 19.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:

Receive_Open_Cnf see clause 25.1.2;

Check_Indication see clause 25.2.1.

Check_Confirmation see clause 25.2.2.

Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TS 23.009 [21].

19.2.2.1 Basic handover

The handling in MSC‑A for basic inter-MSC handover is shown in sheets 1 to 6 of figure 19.2/4.

Sheet 1: The MAP_PREPARE_HANDOVER request may contain:

– an indication that handover number allocation is not required;

– the target Cell ID, for compatibility for handover to GSM;

– the target RNC ID, for SRNS relocation or inter-system handover from GSM to UMTS;

– the IMSI;

– UMTS encryption information and UMTS integrity protection information, which are necessary for inter-system handover from GSM to UMTS;

– GSM radio resource information (channel type);

– the LCLS Global Call Reference;

– the LCLS-Negotiation;

– the LCLS-Configuration-Preference.

The conditions for the presence of these parameters and the processing in MSC‑B (3G_MSC‑B) are described in detail in 3GPP TS 29.010 [58], 3GPP TS 23.009 [21] and 3GPP TS 29.205 [146].

Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains one of:

– no handover number, if the MAP_PREPARE_HANDOVER request included an indication that handover number allocation is not required;

– a handover number;

– one or more relocation numbers.

Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains BSSAP or RANAP signalling information, which is passed to the Handover Control application in MSC‑A.

Sheet 2: If the MAP_PREPARE_HANDOVER confirmation contains an indication that MSC‑B does not support multiple bearers, the Handover Control application in MSC‑A may request handover of one bearer to the same cell in MSC‑B.

Sheet 5: If the original MAP_PREPARE_HANDOVER request included a parameter indicating that handover number allocation is not required, the Handover Control application in MSC‑A may request a handover number (or one or more relocation numbers); this triggers a further MAP_PREPARE_HANDOVER request towards MSC‑B.

19.2.2.2 Handling of access signalling

The Handover Control application in MSC‑A may forward access signalling to any of the MS, RNS‑B or BSS‑B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS‑B or BSS‑B may forward access signalling to the Handover Control application in MSC‑A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services.

19.2.2.3 Subsequent handover

The handling in MSC‑A for subsequent inter-MSC handover is shown in sheets 7 & 8 of figure 19.2/4. If the Handover Control Application determines that the call is to be handed over to a third MSC (MSC‑B’) it triggers another instance of the MAP process to handle the basic handover to MSC‑B’, and reports the result of the subsequent handover to the instance of the MAP process which handles the dialogue with MSC‑B.

Sheet 8: While the MAP process in MSC‑A is waiting for the completion of subsequent handover, it relays access signalling between the Handover Control application and the MS, RNS‑B or BSS‑B as described in clause 19.2.2.2.