5.2.3 Mobile Terminating Roaming Forwarding Call after successful Retrieval of Routeing Information

23.0183GPPBasic call handlingRelease 17Technical realizationTS

The information flow for mobile terminating roaming forwarding (MTRF) call after successful retrieval of routeing information is shown in figure 4c. It applies to a mobile terminating call while the called mobile is simultaneously moving from an old to a new MSC, if the old and the new terminating MSC/VLRs support the MT Roaming Forwarding procedure. The HLR should also support the Mobile Terminating Roaming Forwarding procedure in order to ensure that roaming forwarding can be offered in all scenarios (e.g. in case of IMSI in the LAU Request from UE).

NOTE 1: The full support of MTRF for roaming scenarios requires both home network (HLR) and visited network (VLRs) to support the MTRF procedures and protocol extensions. As deployment scenarios may exist where the home network (HLR) has not been updated to support MTRF the visited network can perform a limited roaming forwarding solution autonomously if the MTRF Supported flag is signalled in the MAP Send Identification message under the conditions defined in this clause.

The new terminating VLR shall include an MTRF Supported flag in the MAP Update Location message sent to the HLR. If the HLR authorises the MTRF call between the old and the new terminating MSCs, the HLR shall include the MTRF Supported And Authorized flag and the new MSC/VLR numbers in the MAP Cancel Location message sent to the old VLR. Otherwise if the HLR disallows the MTRF call between the old and the new terminating MSCs, the HLR shall include the MTRF Supported And Not Authorized flag in the MAP Cancel Location message sent to the old VLR. The new VLR may also signal the MTRF Supported flag and the new MSC/VLR numbers in the MAP Send Identification message to indicate to the old VLR that it supports MTRF.

An HLR supporting the "mobile terminating roaming forwarding" feature shall always send a MAP Cancel Location message message to the old VLR upon receipt of the MAP Update Location from the new VLR. This shall also apply if the HLR and the old VLR support Super-Charger (see 3GPP TS 23.116 [24]), regardless of whether the new VLR indicates or not during the location update procedure that the previous network entity must be notified.

If the old VLR receives a MAP Send Identification message containing the MTRF Supported flag it shall not trigger any MAP Provide Roaming Number request to the new terminating VLR until is has received the MAP Cancel Location message.

Upon receipt of a MAP Cancel Location message while ongoing paging, if either of the following is true:

– the MAP Cancel Location message includes the MTRF Supported And Authorized flag or;

– the MAP Cancel Location message does not include the MTRF Supported And Not Authorized flag and the old VLR has received the MTRF Supported flag earlier in the MAP Send Indentification message,

the old VLR shall send a MAP Provide Roaming Number request (including the MTRF Indicator and the parameters received from the HLR in the MAP Provide Roaming Number) to the new terminating VLR. The new terminating MSC/VLR shall then allocate an MSRN to allow the call to be routed from the old MSC to the new MSC and send it to the old VLR within the MAP Provide Roaming Number response.

Figure 4c: Information flow for a mobile terminating roaming forwarding call after successful Retrieval of Routeing Information

The sequence follows the normal MT terminating call with the following differences:

1. If the Location Update Request contains a valid TMSI/old LAI (e.g. not after the old VLR restart), a new MSC/VLR supporting the MTRF feature may include the MTRF Supported flag and the new MSC/VLR numbers in the MAP Send Identification to the old VMSC.

The new VLR shall not include the MTRF Supported flag in the MAP Send Identification message sent to the old VMSC if the Location Update message received from the MS indicates a CS fallback mobile originating call.

An old VLR supporting the MTRF feature may indicate in the MAP Send Identification response sent to the new VLR whether there is a pending mobile terminating call at the old VLR.

NOTE 2: it is implementation dependent if the new VLR decides to not include the MTRF Supported flag in the MAP Send Identification message sent to the old VMSC if the Location Update message received from the MS contains the "follow-on request pending" flag.

2. A new MSC/VLR supporting the MTRF feature includes the MTRF Supported flag in the MAP Update Location message sent to the HLR, unless the Location Update message received from the MS indicates a CS fallback mobile originating call.

NOTE 3: it is implementation dependent if the new VLR decides to not include the MTRF Supported flag in the MAP Update Location message sent to the HLR if the Location Update message received from the MS contains the "follow-on request pending" flag.

3. Upon receipt of a MAP Update Location including the MTRF Supported flag, an HLR supporting the MTRF feature decides whether to authorise MTRF call between the old and the new MSCs based on roaming agreements with the old and the new MSCs. If MTRF is authorised, the HLR includes the MTRF Supported And Authorized flag and the new MSC/VLR numbers in the MAP Cancel Location message sent to the old VLR. If MTRF is not authorised, the HLR includes the MTRF Supported And Not Authorized flag in the MAP Cancel Location message sent to the old VLR.

4. Upon receipt of a MAP Cancel Location message while on-going paging and if it includes the MTRF Supported And Authorized flag or if the MAP Cancel Location message does include neither the MTRF Supported And Authorized flag nor the MTRF Supported And Not Authorized flag but the old MSC/VLR had received earlier the MTRF Supported flag at step 1, the old MSC/VLR stops paging.

5. If it supports MTRF and decides to apply MTRF based on local operator policy and optionally roaming agreements with the HLR and new MSC for MTRF, it sends a MAP Provide Roaming Number request (including the MTRF Indicator and the parameters received from the HLR in the MAP Provide Roaming Number) to the new terminating VLR.

If the the MAP Cancel Location message does not include the MTRF Supported And Authorized flag and it did not receive the MTRF Supported flag at step 1 or if the MAP Cancel Location message includes the MTRF Supported And Not Authorized flag, the old MSC/VLR may initiate the MT Roaming Retry procedure as per clause 5.2.1.

If the old MSC supports both the MT Roaming Retry and the MT Roaming Forwarding procedures, and if the conditions for using these procedures are met, the MSC can decide based on operator policy which procedure to follow.

6. Upon receipt of the MAP Provide Roaming Number Request, the new MSC/VLR may check roaming agreements with the HLR and the old MSC for MTRF.

The new MSC/VLR may reject the MAP Provide Roaming Number Request with a cause indicating that the subscriber is busy if it has received from the MS a CM Service Request indicating a CS mobile originated call.

If the new VLR rejects the MTRF request, the new VLR returns a negative response to the old VLR.

As an option, the new MSC/VLR may check whether it also performs the GMSC function for the call by comparing the GMSC address received in the MAP Provide Roaming Number with its own MSC address. If so, the GMSC / new MSC/VLR may proceed as shown in figure 4ca to deliver the MT call directly to the UE without further involving the old MSC/VLR.

7. If the new VLR accepts the MAP Provide Roaming Number request, upon successful completion of the MAP Update Location procedure with the HLR, the new MSC/VLR allocates an MSRN to allow the call to be routed from the old MSC to the new MSC. As an implementation option, the new MSC/VLR may allocate an MSRN before completion of the MAP Update Location procedure with the HLR.

8. The new MSC/VLR sends MSRN to the old VLR within the MAP Provide Roaming Number response.

Upon receipt of the MSRN from the new MSC/VLR, the old MSC/VLR terminates any on-going Camel transaction.

9. Receipt of the MSRN from the new MSC/VLR enables the old MSC to relay the call towards the new MSC.

10. If the IAM message is received before the Location Update procedure is completed with the MS, the new MSC may delay the setup of the call until the completion of the Location Update procedure or start at once the normal terminating call procedure. In the former case, if the Location Update is received with the "follow-on" indication and if the MSC supports the "follow-on" indication, the incoming IAM may either be handled as a waiting call or forwarded as Busy (CFB), depending on the state of the "follow-on" call and the subscriber’s subscription data.
The Location Update Accept message may be sent to the MS at any time after receipt of the MAP Update Location Ack from the HLR, i.e. the location update procedure with the MS is not affected by the MT Roaming Forwarding procedure.

If no MAP Provide Roaming Number request has been received at the time the Location Update procedure completes, the new MSC may shortly defer the release of the signalling connection with the MS if the old VLR indicated in the MAP Send Identification response that there is a pending mobile terminating call at the old VLR.

NOTE 4: For a CS Fallback mobile terminating call, the new MSC also defers the release of the signalling connection with the MS if the MS includes the "CSMT" flag in the Location Update message (see clause 7.5a of 3GPP TS 23.272 [42]).

The MAP Update Location message and Send Identification message may include the new LMSI allocated by the new terminating MSC/VLR if the MTRF Supported flag is present in those messages. If available, the HLR shall include the new LMSI in the MAP Cancel Location message it sends to the old VLR if the MTRF Supported And Authorized flag is present in this message. If available, the old VLR shall include the new LMSI in the MAP Provide Roaming Number message it sends to the new VLR.

A VLR may also set the MTRF Supported flag in the MAP Update Location message it sends to the HLR upon establishment of an SGs association (see 3GPP TS 23.272 [42]). This enables in particular mobile terminating roaming forwarding calls during the mobile terminated CS service delivery via an alternative MME in MME pool procedure when the new SGs association is established towards a new VLR (see clause 26 of 3GPP TS 23.007 [43]).

The information flow for mobile terminating roaming forwarding (MTRF) call if the GSMC and the new MSC/VLR are the same node and if they support the option (in step 6) to deliver the MT call directly to the UE without further involving the old MSC/VLR is shown in figure 4ca.

Figure 4ca : Information flow for a mobile terminating roaming forwarding call after successful Retrieval of Routeing Information with MTRF Optimal Routing when the GMSC and the new MSC/VLR are the same node

The sequence follows the normal flow for MTRF call after successful Retrieval of Routeing Information (as specified in figure 4c) with the following differences:

1. The GMSC shall include the GMSC address and the Call reference number used by the GMSC for this call in the MAP Send Routing Information . The HLR shall include these parameters in the MAP Provide Roaming Number if received in the MAP Send Routing Information.

2. Steps 1 to 5 as specified for figure 4c.

3. The new MSC/VLR shall determine that it also performs the GMSC function for the call identified by the Call Reference Number if the GMSC address received in the MAP Provide Roaming Number matches its own MSC address.

4. In that case, the GMSC shall send a Release message to the old MSC/VLR. Upon receipt of this message, the old MSC/VLR shall return a Release Complete message to the GMSC.

5. The new MSC/VLR shall close the MAP Dialogue (initiated in step 3) locally (i.e. MAP-Close service with the release method set to "pre-arranged end"). Alternatively, the new MSC/VLR may send a MAP Abort message to the old MSC/VLR after receiving the Release Complete message. The old MSC/VLR shall release all resources associated to the call (if not already done at step 4).

NOTE 5: The MAP Abort message is sent after receipt of the Release Complete message to avoid the old MSC/VLR initiating a Release procedure towards the GMSC or invoking Call Forwarding upon receipt of the MAP Abort message.6. The new MSC/VLR shall then proceed with the establishment of the MT call without further involving the old MSC/VLR.

NOTE 6: The internal messages between the GMSC and the new MSC/VLR are implementation specific and not further described in 3GPP specifications.