Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.018  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.2.1   5.2.2   5.2.3   5.2.4   5.3   6…   7…   7.2…   7.3…   8…   A…

 

5.2.3  Mobile Terminating Roaming Forwarding Call after successful Retrieval of Routeing Information |R10|p. 23

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).
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 TS 23.116), 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.
Copy of original 3GPP image for 3GPP TS 23.018, Fig. 4c: Information flow for a mobile terminating roaming forwarding call after successful Retrieval of Routeing Information
Up
The sequence follows the normal MT terminating call with the following differences:
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 9.
Receipt of the MSRN from the new MSC/VLR enables the old MSC to relay the call towards the new MSC.
Step 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.
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 TS 23.272). 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 TS 23.007).
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.
Copy of original 3GPP image for 3GPP TS 23.018, Fig. 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
Up
The sequence follows the normal flow for MTRF call after successful Retrieval of Routeing Information (as specified in Figure 4c) with the following differences:
Step 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.
Step 2.
Steps 1 to 5 as specified for Figure 4c.
Step 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.
Step 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.
Step 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).
Up

Up   Top   ToC