Content for  TS 23.272  Word version:  17.0.0

The procedure in this clause may be applied for mobile terminated calls where the MSC/VLR, to which the UE sends the LAU, is different from the MSC/VLR that sent the paging message to the UE. The procedure is based on the "Mobile Terminating Roaming Forwarding" procedure defined in TS 23.018; the specific behaviour for CSFB is described in this clause. This procedure avoids impacting all GMSC nodes and can coexist with Mobile Terminating Roaming Retry procedure described in clause 7.5. In order to ensure roaming forwarding can be offered in all scenarios (e.g. in case of IMSI in the LAU Request from UE), HLRs should be updated to support MTRF. In order to permit Mobile Terminating Roaming Forwarding from the old VLR if the HLR is not updated to support MTRF but the visited network does support MTRF, the new VLR may include MTRF supported flag in Send Identification when it receives a Location Updating Request containing the "CSMT" flag.

The main differences compared to the "Mobile Terminating Roaming Forwarding" procedure defined in TS 23.018 are described below:

• The paging message in E-UTRAN triggers the CS fallback which is followed by a location update in the new RAT.
• The UE includes the "CSMT" flag in the location update request message so that the signalling link is maintained for longer in case the IAM is delayed by the old MSC/VLR.
• If the Location Update Request contains the "CSMT" flag set and a valid TMSI/old LAI, the new MSC/VLR may indicate to the old MSC/VLR that it supports MTRF in the Send Identification message. The new VLR then performs authentication to the Location update and updates the HSS. If the Location Update Request contains the IMSI, only HLR-based MTRF procedure can be used.
• After Cancel Location is received from HSS, if the HLR authorised the MTRF call between the old and the new terminating MSCs or if the HLR did not disallow the MTRF call between the old and the new terminating MSCs but the new MSC/VLR indicated its MTRF support earlier in Send Identification message, the old MSC/VLR stops paging timer and checks roaming and charging pre-configured agreements with regards to call routeing to the new MSC/VLR. If these checks are successful, the old MSC/VLR sends a Provide Roaming Number request (MTRF Indicator, parameters received from the HLR) to the new MSC/VLR.
• In a MT CSFB call, last used LTE PLMN identity may be added in the Provide Roaming Number Request message from old MSC/VLR to new MSC/VLR, based on configuration.

If an MSC/VLR supports both the procedures as specified in clause 7.5 and 7.5a, and the GMSC has indicated support roaming retry as specified in clause 7.5, the old MSC/VLR which sends the initial paging request can decide based on operator policy whether to follow the procedure specified in clause 7.5 or clause 7.5a.

Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS Fallback mechanisms are needed. During the release of an RR connection the MSC should indicate to GERAN/UTRAN that the RR connection (for call or CISS or LCS) was established as a result of CS fallback. GERAN and UTRAN may use the indication to determine which of the existing mechanisms that should be used to move the UE to E-UTRAN. When configured to support the return to the last used PLMN after CSFB, after a successful setup of an RR connection or during the release of the UTRAN RR connection, the MSC shall further indicate to GERAN/UTRAN the last used LTE PLMN ID. GERAN and UTRAN shall take the last used LTE PLMN ID into account when selecting the target cell in PS handover to E-UTRAN or when selecting the dedicated target frequency list for idle mode mobility to E-UTRAN in RR Connection Release procedure. When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed as specified in clause 6.5.

Regular pre-Release 8 MSC procedures are performed without any ISR or SGs specifics.