Content for TS 23.237 Word version: 18.0.0

0… 4… 5… 5.4… 6… 6.2… 6.2.2… 6.3… 6.3.2… 6.3.2.1.3… 6.3.2.1.7… 6.3.2.1.9… 6.3.2.2… 6.3.2.3… 6.3.2.3.6… 6.3.3… 6.4… 6a… 6a.3… 6a.4… 6a.4.3… 6a.4.5… 6a.4.7… 6a.4a… 6a.5… 6a.6… 6a.7… 6a.8… 6a.9… 6a.10… 6a.11… 6c… 7… A… B… C…

6.0 Introduction 6.1 Registration 6.1.1 General 6.1.2 Registration using ATCF enhancements 6.1.3 Registration: CS to PS - Single Radio 6.1.3.1 IMS Registration by UE 6.1.3.2 UE IMS Registration change update
...

6 Procedures and flows for Access Transfer p. 33

6.0 Introduction p. 33

Some of the following figures contain a box labelled CS/IMS Intermediate Nodes. This is abstraction for CS/IMS functional elements that exist between the UE and the SCC AS which could include amongst others MSC Server enhanced for ICS, MSC Server enhanced for SRVCC or an MGCF and an MSC Server not enhanced for ICS.

6.1 Registration p. 33

6.1.1 General |R10| p. 33

Whenever the UE acquires IP connectivity via an IP-CAN, the UE registers in the IMS as defined in TS 23.228. The user profile contains a C-MSISDN which is bound to the IMS Private User Identity. The S-CSCF follows the procedures defined in TS 23.218 for performing 3rd party registration towards the SCC AS.

When using CS access for media, the UE may be registered in IMS as specified in TS 23.292.

When the SCC AS receives a 3rd party registration per procedures defined in TS 23.218, the SCC AS shall obtain the C-MSISDN from the HSS. If the C-MSISDN is associated with any ongoing session(s), the SCC AS shall bind all the unique identities associated with the SIP Registration e.g. GRUUs, contact address, etc with the session identifier of the ongoing session.

If the SCC AS receives a third-party register without a STN-SR pointing to the ATCF and this third-party register is related to a contact address for which SRVCC is provided, the SCC AS shall clear any existing STN-SR that has been set in the HSS and provide a home network configured STN-SR. The SCC AS shall ensure that the home network configured STN-SR can be restored in case of SCC AS failure (e.g. by storing it separately in the HSS as transparent data).

6.1.2 Registration using ATCF enhancements |R10| p. 33

To ensure that the MSC Server selects the correct ATCF during SRVCC procedure, a routable STN-SR pointing to the ATCF shall be provided to the MME before SRVCC procedure is triggered.

The ATCF shall allocate the STN-SR when the user performs initial registration in the IMS. The STN-SR shall be provided through IMS and via third-party registration to the SCC AS. Depending on operator policy, the SCC AS may interrogate the UDM/HSS to know if the user is subscribed for SRVCC (via STN-SR) and if the UE is SRVCC capable. If both conditions are met, or based on operator policy, the SCC AS shall further provide the STN-SR to the UDM/HSS if the received STN-SR is different from the existing one that has been set, which in turn shall update the MME/SGSN. In 5GS, the UDM updates the AMF with received STN-SR.

The following Figure shows an example of IMS registration flow where the ATCF provides the STN-SR to the home network. Existing IMS Registration procedures described in TS 23.228 are used to register the user in IMS.

Reproduction of 3GPP TS 23.237, Fig. 6.1.2-1: IMS Registration using ATCF enhancements

Figure 6.1.2-1: IMS Registration using ATCF enhancements

Step 1.

UE-1 sends an initial SIP REGISTER request to home network via ATCF (P-CSCF and I-CSCF not shown in flow).

Step 2.

ATCF decides, based on operator policy and if the home network supports (5G-)SRVCC enhanced with ATCF, to allocate a STN-SR. The ATCF includes itself in the signalling path for subsequent messages during the registration period. Additionally to the STN-SR, the ATCF allocates an ATCF management URI that can be used by SCC AS to address the ATCF directly.

Step 3.

If allocated, the STN-SR and ATCF management URI are included in the request forwarded to the S-CSCF.

Step 4.

The S-CSCF sends the SIP REGISTER request to the SCC AS according to the third-party registration procedure.

Step 5.

Depending on the operator policy, the SCC AS sends Sh-Pull message to the UDM/HSS in order to know whether the UE is SRVCC capable, and to retrieve the STN-SR stored in the UDM/HSS.

Step 6.

The UDM/HSS replies to the SCC AS with a Sh-Pull Response message including the UE SRVCC capability if available, and the STN-SR if available.

Step 7.

The SCC-AS determines, based on operator policy or based on the outcome of Sh-pull procedure, that the user is subscribed for SRVCC via the presence of STN-SR and that the UE is SRVCC capable. If the STN-SR from the UDM/HSS is different from the STN-SR received from the ATCF, the SCC AS sends a Sh-Update to provide the STN-SR received from the ATCF to the UDM/HSS from the ATCF in order to replace the STN-SR pointing to the SCC AS or the previously stored STN-SR pointing to other ATCF.

Step 8.

The UDM/HSS responds by sending Sh-Update Response message to the SCC AS.

Step 9.

If for a user subscribed for SRVCC, the UDM/HSS received a STN-SR in step7 that is different from the stored STN-SR, it updates the stored STN SR and provides the updated STN-SR to the MME/SGSN. Otherwise this procedure is skipped. In the 5GS, the UDM provides the updated STN-SR to the AMF using Nudm_SDM_Notification service operation as specified in TS 23.502.

Step 10.

The MME/SGSN stores the updated STN-SR and responds to the UDM/HSS with Insert Subscriber Data Answer message.

Step 11.

The SCC AS returns 200 OK to the S-CSCF.

The SCC AS informs the UE SRVCC capability to ATCF during IMS registration by addressing the ATCF using the ATCF management URI. The SCC AS is able to retrieve the updated UE SRVCC capability status by sending Sh-Pull message to the UDM/HSS at any point. If SCC AS detects the UE SRVCC capability change, SCC AS then informs the ATCF about the updated SRVCC capability of the UE and the ATCF stores this information for deciding whether anchoring IMS voice originating sessions at the ATGW or not.

6.1.3 Registration: CS to PS - Single Radio |R11| p. 35

6.1.3.1 IMS Registration by UE p. 35

As a prerequisite for CS to PS SRVCC to be applied, the UE shall be IMS registered over PS. The IMS Registration procedures of clause 6.1.2 apply. The UE shall include a pre-defined port and codec for the voice media that can be used during the access transfer to send downlink media to. The UE shall also include its CS to PS SRVCC capability in the registration request.

Additionally, a dynamic STI-rSR shall be provided to the UE from the ATCF in conjunction to the IMS Registration.

6.1.3.2 UE IMS Registration change update p. 35

As a prerequisite for CS to PS SRVCC to be applied, the UE shall be attached to an MSC Server enhanced for ICS and IMS-registered via CS access by this MSC Server using I2 reference point, as specified in clause 7.2.1 of TS 23.292. In addition, as part of this registration procedure, the MSC Server enhanced for ICS shall indicate to the SCC AS that it needs to be updated with the UE's IMS registration status and/or changes to the ATCF management URI, as described below.

Figure 6.1.3.2-1 provides the procedures of how the MSC Server indicates to the SCC AS to retrieve the UE's IMS registration status and updates to ATCF management URI, and how it is updated with changes.

Reproduction of 3GPP TS 23.237, Fig. 6.1.3.2-1: Subscription to UE's IMS registration status

Figure 6.1.3.2-1: Subscription to UE's IMS registration status

Step 1.

As part of the IMS registration from the MSC Server, the MSC Server may indicate to the SCC AS the wish to be updated with the UE's IMS registration status and/or changes to the ATCF management URI.

Step 2-3.

If the UE's IMS registration status changes or the ATCF management URI changes for the UE's IMS registration, the SCC AS provides the information to the MSC Server. The UE CS to PS SRVCC capability is also provided in this message and is not updated further.