6.3.2 Access Transfer Information flows

23.2373GPPIP Multimedia Subsystem (IMS) Service ContinuityRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.3.2.0 General

This clause details the procedures and flows for Access Transfers. In the flows that pertain to I1, the assumptions specified in clause 7.0 of TS 23.292 [5] apply.

For PS – CS Access Transfer, both Single Radio and Dual Radio procedures are specified in the following clauses. Dual Radio is not supported between two different 3GPP RATs (i.e. 3GPP specifications do not provide the possibility for a UE to transmit/receive on two 3GPP RATs simultaneously). Single Radio PS – CS Access Transfer require the use of SRVCC (specified in TS 23.216 [10]) in the access networks.

6.3.2.1 PS – CS Access Transfer

6.3.2.1.1 PS – CS Access Transfer: PS to CS – Dual Radio

Figure 6.3.2.1.1-1 PS – CS Access Transfer: PS to CS – Dual Radio, provides an information flow for Access Transfer of an IMS session in PS to CS direction. The flow requires that the user has an IMS originating or terminating session using PS media flow(s) at the time of initiation of Access Transfer to CS.

NOTE 1: This flow assumes the PS domain does not have any non real time media flow(s). If the PS domain has other non real time media flow(s), then the call flow in clause 6.3.2.3.1 applies.

Figure 6.3.2.1.1-1: PS – CS Access Transfer: PS to CS – Dual Radio

1. If the user is not attached to the CS domain at the time when the UE determines a need for Access Transfer to CS, the UE performs a CS Attach as specified in TS 23.292 [5], clause 7.2.1. It subsequently originates a session that uses CS media using the STN to establish an Access Leg via the CS access and requests Access Transfer of the IMS session to CS access using the procedures described in TS 23.292 [5], clause 7.3.2 Originating Sessions that use CS media.

2. Standard procedures as specified in TS 23.292 [5], clause 7.3.2 Originating Sessions that use CS media are used in CS and IMS intermediate nodes which results in routing of the INVITE with the STN or an IMRN to the I/S‑CSCF. The MSC Server enhanced for ICS includes the GRUU into the Access Transfer request if the user is registered in the IMS by the MSC Server enhanced for ICS as specified in TS 23.292 [5]. If the user is not registered in IMS then CS/IMS Interworking Nodes includes the C‑MSISDN as calling party number into the Access Transfer request.

3. Standard procedures are used at I/S-CSCF for routing of the INVITE to the SCC AS.

4. The SCC AS completes the establishment of the Access Leg via the CS access. The SCC AS is able to identify the correct anchored session using either the C‑MSISDN or the GRUU for session identification. The SCC AS determines if the state of the session to be transferred is active or inactive based on the session state information in the source Access Leg. The SCC AS performs the Access Transfer by updating the Remote Leg with the connection information of the newly established Access Leg using the Remote Leg Update procedure as specified in clause 6.3.1.5. The SCC AS completes the session setup towards UE according to procedures defined in TS 23.228 [4].

5. The Source Access Leg (which is the Access Leg previously established over PS access) is released as specified in clause 6.3.1.6

NOTE 2: Steps 4 and 5 consist of a sequence of messages, some of which may occur in parallel.

6.3.2.1.1a PS – CS Access Transfer: PS to CS – Dual Radio with Session State Information

Figure 6.3.2.1.1a-1 PS – CS Access Transfer: PS to CS – Dual Radio with Session State Information, provides an information flow for Access Transfer of an IMS session in PS to CS direction. The flow requires that the user has an active IMS originating or terminating session, together with at least one more IMS originating or terminating session (active and/or inactive), using PS media at the time of initiation of Access Transfer to CS and that the use of network capabilities to support MSC Server assisted mid-call feature during Access Transfer is supported by the UE and the network.

NOTE 0: When the UE is using a conference service, the procedures specified in clause 6.3.2.1.8 need to be performed in conjunction with this flow, for the conference service to be supported after the Access Transfer.

Figure 6.3.2.1.1a-1: PS – CS Access Transfer: PS to CS – Dual Radio with Session State Information

2. The procedures specified in TS 23.292 [5], clause 7.3.2, are used by the MSC Server, which results in routing of the INVITE with the STN to the I/S CSCF. The MSC Server includes the GRUU into the Access Transfer request, which can be used for session (and UE) correlation.

NOTE 1: The MSC Server enhanced for ICS obtains the GRUU during registration; the GRUU can be used for session (and UE) correlation.

NOTE 2: The MSC Server has indicated its capability to support MSC Server assisted mid-call feature during Access Transfer in the registration.

3. Standard procedures are used at I/S-CSCF for routing of the INVITE to the SCC AS.

4. The SCC AS completes the establishment of the Access Leg via the CS access. The SCC AS is able to identify the correct anchored session using the GRUU for session identification. The SCC AS performs the Access Transfer of the recently added active session or, if there is no active session, the inactive session which was active most recently, with bi-directional speech for the UE by updating the Remote Leg with the connection information of the newly established Access Leg using the Remote Leg Update procedure as specified in clause 6.3.1.5. The SCC AS completes the session setup towards the UE according to procedures defined in TS 23.228 [4].

5. The SCC AS provides Session State Information on the transferring-in leg. If there are more than two sessions with speech media before session transfer in the source Access Leg, the SCC AS performs the following:

If there are no active sessions, the SCC AS performs the following:

– besides the inactive session already handled in step 4, releases all other remaining inactive sessions;

– includes the information that the session is inactive in the transfer response sent to the MSC Server;

– skips following handling of step 5, 6 and 7, directly goes to step 8 in the information flow.

If there are at least one active session, the SCC AS performs the following:

– if there are two or more active speech sessions, selects the second-most recently active speech session, puts it on hold and releases all remaining active sessions;

– selects the held session that has been most recently made inactive. Any other in-active sessions are released.

the Session State Information of the selected inactive session is sent to the MSC Server.

6. The S-CSCF forwards the Session State Information to the MSC Server.

7. If the MSC Server receives the Session State Information on more than one active or inactive speech sessions, it initiates Access Transfer towards the SCC AS for the additional session.

8. The Source Access Leg (which is the Access Leg previously established over PS access) is released as specified in clause 6.3.1.6.

NOTE 3: Steps 4 and 8 consist of a sequence of messages, some of which may occur in parallel.

After completion of this procedure, the UE uses procedures as defined in TS 24.008 [24] to perform service control.

6.3.2.1.2 PS – CS Access Transfer: CS to PS – Dual Radio

Figure 6.3.2.1.2-1 PS – CS Access Transfer: CS to PS – Dual Radio, provides an information flow for Access Transfer of an IMS session in the CS to PS direction. The flow requires that the user has an IMS originating or terminating session that uses CS media at the time of initiation of Access Transfer to PS.

Figure 6.3.2.1.2-1: PS – CS Access Transfer: CS to PS – Dual Radio

1. When the UE determines a need for Access Transfer, the UE initiates registration with IMS (if not already registered in IMS) as specified in clause 6.1. It subsequently initiates an IMS originated session toward the SCC AS using a STI to establish an Access Leg via PS access and requests Access Transfer of the IMS session that is using CS media to PS access. The statically configured STI is used if no dynamically assigned STI has been provided to the UE during session establishment. Please refer to clause 6.2.1 – IMS Originating Sessions for details on IMS origination procedure.

2. Standard procedures are used at S‑CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS performs the Access Transfer by updating the Remote Leg with the session information, including session state and connection information, of the newly established Access Leg (see the Remote Leg Update procedure, clause 6.3.1.5). The SCC AS completes the establishment of the Access Leg according to procedures defined in TS 23.228 [4].

4. The source Access Leg which is the Access leg previously established over CS is subsequently released (see clause 6.3.1.6).

NOTE: Steps 3 and 4 consist of a sequence of messages, some of which may occur in parallel.

6.3.2.1.2a PS – CS Access Transfer: CS to PS – Dual Radio with Session State Information

Figure 6.3.2.1.2a-1 PS – CS Access Transfer: CS to PS – Dual Radio with Session State Information, provides an example flow for dual radio CS to PS Access Transfer with Held and Active sessions.

Figure 6.3.2.1.2a-1: CS to PS Access Transfer – Dual Radio with Session State Information

1. When the UE determines a need for Access Transfer, the UE initiates registration with IMS (if not already registered in IMS) as specified in TS 23.228 [4]. It subsequently initiates an IMS originated session towards the SCC AS using a static STI to establish an Access Leg via PS access and requests Access Transfer of the active session to PS access.

2. Standard procedures are used at the S CSCF for routing of the INVITE to the SCC AS.

NOTE 1: During session establishment, the UE has indicated its capability to support MSC Server assisted mid-call feature during Access Transfer.

3. The SCC AS performs the Access Transfer by updating the Remote Leg with connection information of the newly established Access Leg (see the Remote Leg Update procedure, described in clause 6.3.1.5). The SCC AS completes the establishment of the Access Leg according to procedures defined in TS 23.228 [4].

4. The SCC AS provides Session State Information when both an active session and an inactive session are transferred. The Session State Information includes the additional held session with speech or speech and video media including dynamic STI needed for the held session on the transferring-in leg.

5. The S-CSCF forwards the Session State Information to the UE.

6. If the UE receives the Session State Information of the held session, it initiates a Access Transfer request towards the SCC AS using the dynamic STI for the held session.

7. The Source Access Leg, which is the Access Leg previously established over CS access, is released as specified in clause 6.3.1.6.

NOTE 2: Steps 3 and 7 consist of a sequence of messages, some of which may occur in parallel.

6.3.2.1.2b CS – PS Access Transfer: CS to PS – Dual Radio, incoming voice call in alerting phase

This procedure done according to the procedure in clause 6.3.2.2.3, with the following amendment for steps 1-4: An MSC server has started a CS session towards the UE which is centralized in IMS according to in TS 23.292 [5]. The UE is awaiting answer from the User.

Before the user answers, the UE decides to move to PS. The procedure follows as from step 5 in clause 6.3.2.2.3. IP‑CAN 2 represents the new PS leg. The UE uses the statically configured STI for the transfer.

6.3.2.1.2c CS – PS Access Transfer: CS to PS – Dual Radio, outgoing voice call in pre-alerting state or in alerting phase

This procedure done according to the procedure in clause 6.3.2.2.4, with the following amendment for steps 1-4: The UE has started a CS session that is centralized in IMS according to in TS 23.292 [5]. The UE is awaiting answer from the remote end.

Before the remote end answers, the UE decides to move to PS. The procedure follows as from step 5 in clause 6.3.2.2.3. IP‑CAN 2 represents the new PS leg. The UE uses the statically configured STI for the transfer.

6.3.2.1.2d PS – CS Access Transfer: PS to CS – Dual Radio, outgoing voice or video call in pre-alerting state or in alerting phase

Figure 6.3.2.1.2d-1 PS-CS: PS to CS – Dual Radio, outgoing voice or video call in early dialogue phase (alerting or pre-alerting), provides an information flow for Dual Radio Access Transfer of media of an IMS session in early dialogue state for the PS to CS direction.

The flow requires that the user is active in a terminating IMS session and that the SIP session is in early dialogue state, there is no other ongoing session and the UE has not responded over the access leg.

Figure 6.3.2.1.2d-1: PS-CS: PS to CS – Dual Radio, outgoing voice or video call in alerting phase

1-4. Standard procedures are used to initiate a SIP session towards the UE. The originating UE is either in alerting or pre-alerting state.

5. UE determines a need for Access Transfer to CS. If the user is not attached to the CS access at this, the UE performs a CS Attach as specified in clause 7.2.1 of TS 23.292 [5].

6. UE starts the Dual Radio Access Transfer procedure by sending a CS setup message destined to STN according to TS 24.008 [24].

7. MSC Server routes the call towards the STN received in 5. If the MSC is not enhanced SC signalling will be used and the call setup message will be routed through an MGCF.

8. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

9. The SCC AS uses the STN to determine that Access Transfer using Dual Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session. The SCC AS proceeds with the Access Transfer of the recently added active session with bi-directional speech or bi-directional speech and synchronised video for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE: It is assumed the initial SDP negotiation has been completed prior to triggering the (v)SRVCC, thus the SCC AS can update the remote leg.

10. The SCC AS sends a Ringing or provisional response message towards the UE.

11. The S-CSCF forwards the Ringing or provisional response message to the MSC Server.

12. The MSC server responds to the UE according to TS 24.008 [24] (depending on whether Ringing or provisional response is received).

12a. The MSC moves to the correct call state, see TS 24.008 [24], e.g. Call Delivered in case of alerting, or Mobile Originating Call Proceeding in case of pre-alerting.

12b. The UE moves to the corresponding call state, which also ensures that the same ring back tone is played to the end user.

13. The remote end answers to the call.

14. The SCC AS sends an Answer message towards the MSC.

13. Standard procedures are used at S-CSCF for routeing Answer message to the MSC.

14. The MSC uses the standard procedure to send the CS connect message to UE as described in TS 24.008 [24].

14a. The MSC moves to Active state.

14b. The UE moves to Active state.

6.3.2.1.2e PS – CS Access Transfer: PS to CS – Dual Radio, incoming voice call in alerting phase

Figure 6.3.2.1.2e-1 PS-CS: PS to CS – Dual Radio, incoming voice or video call in alerting phase, provides an information flow for Dual Radio Access Transfer of media of an IMS session in alerting state for the PS to CS direction.

The flow requires that the user is active in a terminating IMS session and that the SIP session is in alerting state, there is no other ongoing session and the UE has not responded over the access leg.

Figure 6.3.2.1.2e-1: PS-CS: PS to CS – Dual Radio, incoming voice or video call in alerting phase

1-4. Standard procedures are used to initiate a SIP session towards the UE. The UE is alerting the user for the incoming voice or video-call session.

5. UE determines a need for Access Transfer to CS. If the user is not attached to the CS domain at this time, the UE performs a CS Attach as specified in TS 23.292 [5], clause 7.2.1.

6. In the ongoing SIP session, the UE sends a SIP message towards SCC AS which includes a request to initiate session transfer from PS to CS.

NOTE 1: The alerting towards the end user continues during the transfer.

7. Standard procedures are used at I/S-CSCF for routeing of the SIP message to the SCC AS.

8. The SCC AS starts the Session transfer procedure by sending a SIP INVITE towards the UE via the CS access. SCC AS uses STN as the calling party so that the UE can do a correlation to ongoing session.

NOTE 2: The SCC AS can direct the session to the CS access over Mg or I2, see TS 23.292 [5].

9. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the MSC Server. If MSC Server is not enhanced, CS signalling will be used via a MGCF.

10. MSC server sends a CS Setup to the UE. The UE determines that Access Transfer using Dual Radio VCC is requested when the calling party received is STN.

10a. At sending of the CS Setup the MSC puts itself in a state ready receive answer.

10b. At receipt of the CS Setup the UE puts itself in a state ready to receive answer by the user.

11. The UE acknowledge the CS Setup and the MSC Server responds with provisional response / ringing toward the remote side.

12. Based on the response from the UE, the SCC AS performs a remote end update according to clause 6.3.1.5.

13. The source access leg is released according to clause 6.3.1.6 as a consequence of the transfer to the new access leg.

14. User answers.

15. The UE uses the standard procedure to send the CS connect message to MSC Server as e.g. described in TS 24.008 [24].

15a. UE moves to active state.

15b. MSC Server moves to active state.

16. MSC sends an answer message in the SIP session started in Step 8.

17. Standard procedures are used at I/S-CSCF for routeing of the answer toward the SCC AS.

18. The call setup is completed.

6.3.2.1.3 Subsequent Access Transfers

Procedures for subsequent Access Transfers to CS and PS access are the same as procedures for initial Access Transfers specified in clause 6.3.2.1.1 for PS to CS access and clause 6.3.2.1.2 for CS to PS access.

6.3.2.1.4 PS – CS Access Transfer: PS to CS – Single Radio

Figure 6.3.2.1.4-1 PS-CS: PS to CS – Single Radio, provides an information flow for Access Transfer of media flow(s) of an IMS session in PS to CS direction for Access Transfers within 3GPP access networks as specified in TS 23.216 [10].

The flow requires that the user is active or inactive in an IMS originating or terminating session; procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer. It further requires that the MSC Server assisted mid-call feature as described in clause 6.3.2.1.4a is not used.

NOTE 1: See TS 23.216 [10] for initiation of handover of only one voice PS bearer at EPC.

NOTE 2: The UE capable of procedures as specified in TS 23.216 [10] does not need to support session and access transfer procedures as specified in clauses 6.3.2.1.1 and 6.3.2.3 to support PS to CS Access Transfer.

Figure 6.3.2.1.4-1: PS-CS: PS to CS – Single Radio

1. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of SRVCC procedures for Access Transfer to CS access. The MSC Server enhanced for SRVCC includes the C‑MSISDN as calling party number. If SRVCC with priority is supported, MSC Server enhanced for SRVCC also includes a priority indication if received.

2. Standard procedures are used at I/S-CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS uses the STN-SR to determine that Access Transfer using SRVCC is requested. The SCC AS may retrieve the C‑MSISDN from the HSS. The SCC AS is able to identify the correct anchored session. The SCC AS determines if the state of the session to be transferred is active or inactive based on the session state information in the source Access Leg. The SCC AS proceeds with the Access Transfer of the session with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 3: Please refer to clause 4.3.1.2.2 for the behaviour of the SCC AS when the SCC AS finds multiple active sessions with bi-directional speech anchored for the UE.

4a. If the Gm reference point is retained upon PS handover procedure then

4a-1. The UE sends a Re-INVITE via the PS access to update the remaining non-voice media flow(s) associated with the recently added active session. If the UE is using ICS capabilities, this Re-INVITE also adds Gm service control to the active session and the UE subsequently sends Re-INVITEs for any remaining inactive bi-directional speech sessions that are to be transferred.

4a-2. Standard procedures are used at S-CSCF for routing of the Re-INVITE(s) to the SCC AS.

4a-3. The SCC AS processes the Re-INVITE(s) and updates the Remote Leg if needed.

4b. If the Gm reference point is not retained upon PS handover procedure, e.g. because there was no other media flow(s) in the IMS session than the voice which was transferred to the target access, then the Source Access Leg is released as specified in clause 6.3.1.6.

NOTE 4: Some or all of the steps between steps 3 and 4b may consist of a sequence of messages, some of which may occur in parallel.

If the MSC Server above (located in the box labelled "CS/IMS Intermediate Nodes") is enhanced for ICS as defined in TS 23.292 [5], then it performs IMS registration after the transfer of the session is completed successfully i.e. after step 3. Registration is performed only if the ICS flag is received via the Sv reference point as specified in TS 23.216 [10] or as determined to by the procedure specified in clause 7.2.1.1 in TS 23.292 [5].

6.3.2.1.4a PS – CS Access Transfer: PS to CS – Single Radio with Session State Information

Figure 6.3.2.1.4a-1 PS-CS: PS to CS – Single Radio with Session State Information, provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers within 3GPP access networks as specified in TS 23.216 [10].

The flow requires that the user has an active IMS originating or terminating session, together with at least one more IMS originating or terminating session (active and/or inactive), and that the use of network capabilities to support MSC Server assisted mid-call feature during Access Transfer is possible; procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer.

The flow is not applicable in case ICS UE capabilities can be used.

NOTE 1: See TS 23.216 [10] for initiation of hand-over of only one voice PS bearer in EPC.

Figure 6.3.2.1.4a-1: PS-CS: PS to CS – Single Radio with Session State Information

1. Procedures specified in TS 23.216 [10], result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the Access Transfer request. The MSC Server indicates its capability to support MSC Server assisted mid-call feature during Access Transfer.

2. Standard procedures are used at I/S-CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C‑MSISDN from the HSS. The SCC AS identifies the correct anchored session and proceeds with the Access Transfer of the recently added active session or, if there is no active session, the inactive session which was active most recently, with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

4. The SCC AS provides Session State Information on the transferring-in leg. If there are more than two sessions with speech media before session transfer in the source Access Leg, the SCC AS performs the following:

If there are no active sessions, the SCC AS performs the following:

– includes the information that the session is inactive in the transfer response sent to the MSC Server;

– besides the inactive session already handled in step 3, releases all other remaining inactive sessions;

– skips following handling of step 4, 5 and 6 in the information flow.

If there are at least one active session, the SCC AS performs the following:

– if there are two or more active sessions, selects the second-most recently active session, puts it on hold and releases all remaining active sessions;

NOTE 3: If the first-most recently active session is speech session and the second-most recently active session is a speech and video session, the SCC AS removes the video parts of second-most recently active session and places it on hold. If the second-most recently active session needs to be released according to the operator’s policy, the SCC AS releases this session after transfer. All the other remaining active sessions, if any, will be released and not be transferred.

– selects the held session that has been most recently made inactive. Any other inactive sessions are released;

– the Session State Information of the selected inactive session is sent to the MSC Server.

5. The S-CSCF forwards the Session State Information to the MSC Server.

6. If the MSC Server receives the Session State Information of more than one active or inactive speech sessions, it initiates Access Transfer towards SCC AS for the additional session.

NOTE 4: The SCC AS uses the C-MSISDN or GRUU to correlate the Access Transfer request, and additionally the Session State Information to select the correct session.

7a. If the Gm reference point is retained after PS handover procedure completion for non-voice media flows, then:

7a-1. The UE sends a Re-INVITE via the PS access to update the remaining non-voice media flow associated with the recently added active session.

7a-2. Standard procedures are used at S-CSCF for routing of the INVITE to the SCC AS.

7a-3. The SCC AS processes the Re-INVITE and updates the Remote Leg if needed.

7b. If the Gm reference point is not retained after PS handover procedure completion, e.g. because there was no other media in the IMS session than the voice that was transferred to the target access, then the Source Access Leg is released as specified in clause 6.3.1.6.

NOTE 5: Some or all of the steps between steps 3 and 4b consist of a sequence of messages, some of which may occur in parallel.

If the MSC Server above is enhanced for ICS as defined in TS 23.292 [5], then it performs IMS registration after the transfer of all sessions is completed successfully i.e. after step 6. Registration is performed only if the ICS flag is received via the Sv reference point as specified in TS 23.216 [10] or as determined to by the procedure specified in clause 7.2.1.1 in TS 23.292 [5].

After completion of this procedure, the UE uses procedures as defined in TS 24.008 [24] to perform service control.

6.3.2.1.4b PS to CS Access Transfer: PS to CS – Single Radio; using I1 reference point

Figure 6.3.2.1.4b PS-CS: PS to CS – Single Radio; using I1 reference point, provides an information flow for Access Transfer of media flow(s) of an IMS session in the PS to CS direction for Access Transfers within 3GPP access networks as specified in TS 23.216 [10], and with the use of I1 reference point for service control post transfer to CS.

The flow requires that the UE has indicated ICS capabilities and that the user is active in an IMS originating or terminating session; procedures specified in TS 23.216 [10] are used for the switching of access networks at the transport layer. The I1 reference point of ICS is used for control of IMS sessions established using CS media and a dynamically assigned STI is associated with each session.

NOTE 1: See TS 23.216 [10] for initiation of handover of only one voice PS bearer at EPC.

Figure 6.3.2.1.4b-1: PS-CS: PS to CS – Single Radio; using I1 reference point

1. Access Transfer of the active session with bi-directional speech is performed as defined in clause 6.3.2.1.4, steps 1-3.

2. The UE sends an I1: ICS Call Initiation via the CS access as specified in TS 23.292 [5] including an STI for continuation of establishment of the Access Leg using Single Radio VCC for the active session.

3. The SCC AS uses the STI to correlate the Access Transfer request received via the PS access with the Access Transfer request for the active session received via the CS access.

4. If there are any held sessions present at the time of Access Transfer, the UE proceeds with the Access Transfer of the first held session by sending an I1: ICS Call Initiation via the CS access (as described in TS 23.292 [5]) including an STI that identifies the held session.

NOTE 3: If the first-most recently active session is speech session and the selected held session is a speech and video session, the SCC AS removes the video parts of selected held session. If the held speech and video session needs to be released according to the operator’s policy, the SCC AS releases this session after transfer. All the other remaining sessions, if any, will be released and not be transferred.

5. The SCC AS uses the STI to identify the held session and updates the session information on the Access Leg.

NOTE 4: CS media is not established for the held session. The media established upon the transfer of the currently active session is reused for the held session when it is resumed.

Steps 4 and 5 are repeated for the remaining held sessions.

6. The Source Access Leg is released as specified in clause 6.3.1.6.

6.3.2.1.4c PS – CS Access Transfer: PS to CS – Single Radio, incoming voice or video call in pre-alerting or alerting phase

Figure 6.3.2.1.4c-1 PS-CS: PS to CS – Single Radio, incoming call in pre-alerting or alerting phase, provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216 [10].

The flow requires that the user is active in a terminating IMS session in pre-alerting or alerting state which the UE has not responded over the access leg and there is no other session (or there is one or more held sessions but mid-call service is not supported); procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer.

Figure 6.3.2.1.4c-1: PS-CS: PS to CS – Single Radio, incoming voice or video call in pre-alerting or alerting phase

1-4. Standard procedures are used to initiate a SIP session towards the UE. The UE is either in pre-alerting state or alerting the user for the incoming voice or video-call session. Precondition procedure can be executed in this phase but is not shown in the flow.

5. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. The MSC Server enhanced for (v)SRVCC includes the C-MSISDN as calling party number. The MSC Server indicates its capability to support mid-call services during session transfer. For PS-CS transfer for vSRVCC the video Codecs are also included in the session transfer request.

NOTE 1: This step is only triggered after QCI=1 bearer was established in step 1-4 for pre-alerting state.

6. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

7. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS uses the C-MSISDN to identify the correct anchored session. The SCC AS proceeds with the Access Transfer of the recently added active session with bi-directional speech or bi-directional speech and synchronised video media for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 2: It is assumed the initial SDP negotiation has been completed prior to triggering the (v)SRVCC, thus the SCC AS can update the remote leg.

8. The SCC AS provides Session State Information on the incoming speech call in pre-alerting state or alerting state.

9. The S-CSCF forwards the Session State Information to the MSC Server.

10. The MSC moves to the corresponding CS call state, e.g. Call Received in TS 24.008 [24].

NOTE 3: In call received state the MSC does not generate an in-band ring tone to the calling party.

11. The user answers to the call. For video call the UE may initiate at this stage the H.245 Codec negotiation.

11a. UE moves to Active state.

12. The UE uses the standard procedure to send the CS connect message to MSC as e.g. described in TS 24.008 [24].

NOTE 4: Solution for possible race conditions (e.g. MSC server receives the CS connect before the SCC AS responds) will be defined in Stage 3.

12b. The MSC moves to Active state.

13. The MSC notifies the SCC AS the user has answered the call.

14. Standard procedures are used at S-CSCF for routeing of the notification to the SCC AS.

15. The SCC AS creates the corresponding SIP request to the remote end, updates the remote leg.

6.3.2.1.4d PS – CS Access Transfer: PS to CS – Single Radio, outgoing voice or video call in pre-alerting state or in alerting phase

Figure 6.3.2.1.4d-1 PS-CS: PS to CS – Single Radio, outgoing call in early dialogue phase (i.e. pre-alerting or alerting), provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216 [10].

The flow requires that the user is active in an outgoing IMS session in early dialogue phase and there is no other session (or there is one or more held sessions but mid-call service is not supported); procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer.

Figure 6.3.2.1.4d-1: PS-CS: PS to CS – Single Radio, outgoing voice or video call in pre-alerting or in alerting phase

1-4. Standard procedures are used to initiate a SIP session from the UE towards the remote end. The remote end is either alerting the user for the incoming voice or video-call session or the call is in pre-alerting state and announcements may be played to the UE. Access bearer for voice or video is setup for the UE during this step.

5. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for (v)SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer. For PS-CS transfer for vSRVCC the video Codecs are also included in the session transfer request.

6. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

7. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session. The SCC AS proceeds with the Access Transfer of the recently added active session with bi-directional speech or bi-directional speech and synchronised video for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the (v)SRVCC, thus the SCC AS can update the remote leg.

NOTE 2: The SCC AS uses the C-MSISDN or GRUU to correlate the Access Transfer request.

8. The SCC AS provides Session State Information on the outgoing speech call in early dialogue phase (e.g., pre-alerting or alerting state).

9. The S-CSCF forwards the Session State Information to the MSC Server.

10. The MSC moves to the corresponding CS call state, e.g. Call Delivered or Mobile Originating Call Proceeding state as specified in TS 24.008 [24].

10b. In parallel to step 10, the UE has received the HO command as described in TS 23.216 [10]. The UE determines the local call state in the SIP session, and creates the corresponding CS call state, e.g. Call Delivered in TS 24.008 [24] for the alerting state, or Mobile Originating Call Proceeding for the pre-alerting state. The UE ensures that the same ring back tone or announcement if any is played to the end user. If the voice+video media is played to the UE in PS domain, and the CS domain does not support video media, only the voice media shall be played to the UE after the call is transferred to CS domain from PS domain, regardless of whether the media is locally generated by the UE or is network-generated to the UE.

11. The remote end answers to the call.

12. The SCC AS notifies the MSC the remote end has answered the call.

13. Standard procedures are used at S-CSCF for routeing of the notification to the MSC.

14. The MSC uses the standard procedure to send the CS connect message to UE as e.g. described in TS 24.008 [24]. For video call the UE may initiate at this stage the H.245 Codec negotiation.

15. The MSC moves to Active state.

16. The UE moves to Active state.

6.3.2.1.4e PS – CS Access Transfer: PS to CS – Single Radio, voice and video

Figure 6.3.2.1.4e-1 describes the information flows for transferring voice and video from PS to CS access single radio.

The flow requires that the user is active in an IMS originating or terminating session with voice and synchronised video media; procedures and capabilities specified in TS 23.216 [10], clause 6.2.2.3 are used for the switching of access networks at the transport layer.

NOTE 1: The UE capable of procedures as specified in TS 23.216 [10] does not need to support session and access transfer procedures as specified in clauses 6.3.2.1.5 and 6.3.2.3 to support PS to CS Access Transfer.

In this flow, the SCC AS waits for the H.245 negotiation completion before updating Remote Leg.

Figure 6.3.2.1.4e-1: Information flow for voice and video transfer from PS to CS- single radio

1-2. See clause 6.3.2.1.4 steps 1 and 2. MSC Server includes the SDP of the voice and video SDP of the predefined Codecs. If vSRVCC with priority is supported, MSC Server enhanced for vSRVCC also includes a priority indication if received. The SCC AS performs the Access Transfer of the most recently added active session for bidirectional voice and synchronised video media. The transfer of the alerting session or during pre-alerting state is described 6.3.2.1.4c and 6.3.2.1.4d.

3. See clause 6.3.2.1.4 step 3. The SCC AS performs a remote leg update with the media type of the CS access leg for the voice and video session as specified in clause 6.3.1.5.

NOTE 2: If the remote end does not support the predefined Codecs, the MGW performs the appropriate transcoding.

4. The MSC Server completes the CS leg establishment with UE-1.

5. Predefined Codecs for voice and video with specific characteristics are initially used by the UE‑1 after it establishes the circuit bearer to the target MSC. The predefined Codecs for voice and video are the default Codecs specified in TS 26.111 [32]. If needed, UE-1 and MSC Server may start in band H.245 negotiation right after the UE‑1 establishes a circuit bearer to the MSC Server. 3G-324M codec negotiation for the video is executed (refer to TR 26.911 [29] for H.245 signalling optimizations) right after the UE‑1 establishes a circuit bearer to the Target MSC.

6a. If the Gm reference point is retained upon PS handover procedure then:

6a-1. The UE‑1 sends a Re-INVITE via the PS access to update the remaining non-voice and non-voice/non-video media flow(s) associated with the recently added active session. If the UE‑1 is using ICS capabilities, this Re-INVITE also adds Gm service control to the active session and the UE‑1 subsequently sends Re-INVITEs for any remaining inactive bi-directional speech sessions that are to be transferred.

6a-2. Standard procedures are used at S-CSCF for routing of the Re-INVITE(s) to the SCC AS.

6a-3. The SCC AS processes the Re-INVITE(s) and updates the Remote Leg if needed.

6b. If the Gm reference point is not retained upon PS handover procedure, or if there was no other non-voice and non-voice/non-video media flow(s) in the IMS session than the voice+video which was transferred to the target access, then the Source Access Leg is released as specified in clause 6.3.1.6.

NOTE 3: Some or all of the steps between steps 3 and 6b may consist of a sequence of messages, some of which may occur in parallel.

6.3.2.1.5 PS – CS Access Transfer for voice and video, Dual Radio

Figure 6.3.2.1.5-1 describes the information flows for transferring voice and video from PS to CS access.

In this flow, the SCC AS waits for the H245 negotiation completion before updating Remote Leg.

Figure 6.3.2.1.5-1: Information flow for voice and video transfer from PS to CS

1-3. UE-1 starts Access Transfer of multimedia session from PS to CS as specified in steps 1-3 of clause 6.3.2.1.1. The media types of voice and video, included in the INVITE message with STN in step 3, instruct the SCC AS to wait for H.245 negotiation complete to perform the Remote Leg update in step 8.

4. The SCC AS completes the CS leg establishment with UE-1.

5. UE-1 and CS/IMS intermediate node starts in band H.245 negotiation.

6-7. After the H.245 negotiation is done, CS/IMS intermediate node sends H.245 negotiation completion indication towards SCC AS.

8. On receipt of the H.245 negotiation complete indication, the SCC AS updates the Remote Leg as specified in step 4 of clause 6.3.2.1.1

9. The SCC AS may release the Source Access Leg as specified in step 5 of clause 6.3.2.1.1.

NOTE 1: If the non voice and video media flow is retained, the Source Access Leg may be updated by session re-negotiation.

NOTE 2: When using the MSC server enhanced for ICS, the H.245 negotiation with UE-1 shall be executed by the MSC server enhanced for ICS, and the H.245 negotiation complete indication shall be sent by the MSC server enhanced for ICS towards SCC AS.

6.3.2.1.6 PS – CS Access Transfer: PS to CS – Dual Radio, mid-call service with an active speech and video session

Figure 6.3.2.1.6-1 PS to CS with one active speech and video session, using SCUDIF, provides an information flow for Access Transfer of multiple IMS sessions in PS to CS direction. The flow requires that the user is active in an IMS originating or terminating speech and video session using PS media at the time of initiation of Access Transfer to CS and that the use of network capabilities to support mid-call services during session transfer is possible. It also requires that SCUDIF feature is supported by the UE and the CS network.

NOTE: When the UE is using a conference service, the procedures specified in clause 6.3.2.1.8 need to be performed in conjunction with this flow, for the conference service to be supported after the Access Transfer.

Figure 6.3.2.1.6-1: PS to CS with one active speech and video session, using SCUDIF

1. Standard procedure as specified in clause 6.3.2.1.5 PS – CS Access Transfer for voice and video is used for transferring the active speech and video session. The UE indicates SCUDIF support and provides two bearer capabilities (voice and multimedia) with multimedia preferred when initiating the transfer. Also, the SCC AS provides session state information on the inactive voice session including needed STI on the transferring-in leg to the MSC Server.

2. The MSC Server initiates session transfer towards SCC AS for the additional inactive voice session on behalf the UE.

3. The Source Access Leg associated with the inactive voice session is released as specified in clause 6.3.1.6.

Subsequently, the UE can switch between the speech and video session and the voice session with different bearer capabilities activated using SCUDIF feature as specified in TS 23.292 [5].

If SCUDIF is not supported, the transfer can be performed as Figure 6.3.2.1.6-1 with the differences that in step 1 the UE initiates Access Transfer not using SCUDIF, and after the transfer video channel is closed via H.245 negotiation if the voice session is to be activated.

6.3.2.1.7 PS – CS Access Transfer: PS to CS – Dual Radio, mid-call service with one inactive speech and video session

Figure 6.3.2.1.7-1 PS to CS with one inactive speech and video session, using SCUDIF, provides an information flow for Access Transfer of multiple IMS sessions in PS to CS direction. The flow requires that the user is inactive in an IMS originating or terminating speech and video session using PS media at the time of initiation of Access Transfer to CS and that the use of network capabilities to support mid-call services during session transfer is possible. It also requires that SCUDIF feature is supported by the UE and the CS network.

Figure 6.3.2.1.7-1: PS to CS with one inactive speech and video session, using SCUDIF

1. Standard procedure as specified in clause 6.3.2.1.1 PS – CS Access Transfer: PS to CS is used for transferring the active voice session. The UE indicates SCUDIF support and provides two bearer capabilities (voice and multimedia) with voice preferred when initiating the transfer. Also, the SCC AS provides session state information on the inactive speech and video session including needed STI on the transferring-in leg to the MSC Server.

2. The MSC Server initiates session transfer towards SCC AS for the additional inactive speech and video session on behalf the UE.

3. The Source Access Leg associated with the inactive speech and video session is released as specified in clause 6.3.1.6.

Subsequently, the UE can switch between the speech and video session and the voice session with different bearer capabilities activated using SCUDIF feature as specified in TS 23.292 [5].

If SCUDIF is not supported, the transfer can be performed as Figure 6.3.2.1.7-1 with the differences that in step 1 the UE initiates Access Transfer not using SCUDIF, and after the transfer redial mechanism can be used to switch between the speech and video call and the voice call as specified in TS 23.292 [5].

6.3.2.1.7a PS – CS Access Transfer: PS to CS – Single Radio, mid-call service with an incoming waiting call in alerting phase

Figure 6.3.2.1.7a-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216 [10].

The flow requires that the user is active in an IMS originating or terminating session and an incoming waiting call is indicated to the user which is in call waiting state; procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer.

Figure 6.3.2.1.7a-1: PS-CS: PS to CS – Single Radio, mid-call service with an incoming waiting call in alerting phase

1-4. Standard procedures are used to initiate a SIP session towards the UE, which has already an ongoing session. The UE is notifying the user for the incoming waiting session.

5. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.

6. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

7. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session. The SCC AS proceeds with the Access Transfer of the recently added active session with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the SRVCC, thus the SCC AS can update the remote leg.

NOTE 2: The SCC AS uses the C-MSISDN or GRUU to correlate the Access Transfer request.

8. The SCC AS provides session state information on the incoming waiting call in alerting state.

9. The S-CSCF forwards the session state information to the MSC Server.

10. The MSC Server receives the Session State Information which indicates one active and one session in alerting state. The MSC Server initiates Access Transfer towards SCC AS for the alerting session.

11. The MSC moves to the corresponding CS call state for the alerting session, e.g. Call Received in TS 24.008 [24].

NOTE 3: In call received state the MSC does not generate an in-band ring tone to the calling party.

11b. In parallel to step 11, the UE has received the HO command as described in TS 23.216 [10]. The UE determines the local call states in the SIP sessions, and creates the corresponding CS call states. The UE continues to indicate the user about for the incoming waiting call.

12. The user answers the waiting call and the UE locally swaps the active call with the waiting call.

12b. UE has one active and one held call.

13. The UE uses the standard procedure to send the CS set call hold for the previously active call to MSC. The UE uses the standard procedure to send the CS connect message for the alerting call to MSC as e.g. described in TS 24.008 [24].

NOTE 4: Solution for possible race conditions (e.g. MSC server receives the CS set call hold before the SCC AS responds) will be defined in Stage 3.

13b. The MSC has one active and one held call for the UE.

14. The MSC notifies the SCC AS the user has swapped the two sessions, i.e. the user has answered the previously alerting call, and put the previously active call on hold.

15. Standard procedures are used at S-CSCF for routeing of the notification to the SCC AS.

16. The SCC AS creates the corresponding SIP request to the remote end and updates the remote leg.

6.3.2.1.7b PS – CS Access Transfer: PS to CS – Single Radio, mid-call service with an outgoing call in pre-alerting state or in alerting phase

Figure 6.3.2.1.7b-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216 [10].

The flow requires that the user has a held IMS originating or terminating session and an outgoing IMS session in early dialogue phase (i.e. pre-alerting or alerting); procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer. The Held session is being transferred (step 5-7) first by the network prior to the alerting session (step 10).

Figure 6.3.2.1.7b-1: PS-CS: PS to CS – Single Radio, mid-call service with an outgoing call in pre-alerting or in alerting phase

1-4. Standard procedures are used to initiate a SIP session from the UE, which has already an IMS session (held). The remote end is either alerting the user for the incoming voice session or the call is in pre-alerting state and announcements may be played the UE. Access bearer for voice or video is setup during this step for the UE.

5. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.

6. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

7. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session (i.e. the held session). The SCC AS proceeds with the Access Transfer of the held session for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the SRVCC, thus the SCC AS can update the remote leg.

NOTE 2: The SCC AS uses the C-MSISDN or GRUU to correlate the Access Transfer request.

8. The SCC AS provides Session State Information that the outgoing speech call in early dialog state (e.g. pre-alerting state or alerting state) and other session information as specified in clause 6.3.2.1.4a.

9. The S-CSCF forwards the Session State Information to the MSC Server.

10. The MSC Server receives the Session State Information which indicates one held session and one session in early dialog state. The MSC Server initiates Access Transfer towards SCC AS for the alerting or pre-alerting session.

11. The MSC moves to the corresponding CS call state, e.g. Call Delivered or Mobile Originating Call Proceeding state specified in TS 24.008 [24].

11b. In parallel to step 11, the UE has received the HO command as described in TS 23.216 [10]. The UE determines the local call state in the SIP session, and creates the corresponding CS call state, e.g. Call Delivered in TS 24.008 [24] for the alerting state, or Mobile Originating Call Proceeding for the pre-alerting state. The UE ensures that the same ring back tone or announcement if any is played to the end user.

12. The remote end answers to the call.

13. The SCC AS notifies the MSC the remote end has answered the call.

14. Standard procedures are used at S-CSCF for routeing of the notification to the MSC.

15. The MSC uses the standard procedure to send the CS connect message to UE as e.g. described in TS 24.008 [24].

16. The MSC has one active and one held call for the UE.

17. The UE has one active and one held call.

6.3.2.1.7c PS – CS Access Transfer: PS to CS – Single Radio, mid-call service with an incoming call in alerting phase and a held session

Figure 6.3.2.1.7c-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216 [10].

The flow requires that the user has a held IMS originating or terminating session and an incoming call in alerting state; procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer. The Held session is being transferred (step 5-7) first by the network prior to the alerting session (step 10).

Figure 6.3.2.1.7c-1: PS-CS: PS to CS – Single Radio, mid-call service with an incoming call in alerting phase

1-4. Standard procedures are used to initiate a SIP session towards the UE, which has already an IMS session (held). The UE is notifying the user for the incoming session.

5. Procedures specified in TS 23.216 [10] result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.

6. Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.

7. The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session (i.e. the held session). The SCC AS proceeds with the Access Transfer of the held session for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the SRVCC, thus the SCC AS can update the remote leg.

NOTE 2: The SCC AS uses the C-MSISDN or GRUU to correlate the Access Transfer request.

8. The SCC AS provides session state information that the incoming speech call in alerting state and other session information as specified in clause 6.3.2.1.4a.

9. The S-CSCF forwards the session state information to the MSC Server.

10. The MSC Server receives the Session State Information which indicates one held and one session in alerting state. The MSC Server initiates Access Transfer towards SCC AS for the alerting session.

11. The MSC moves to the corresponding CS call state for the alerting session, e.g. Call Received in TS 24.008 [24].

NOTE 3: In call received state the MSC does not generate an in-band ring tone to the calling party.

12. The user answers the incoming call and the UE locally swaps the active call with the incoming call.

12b. UE has one active and one held call.

13. The UE uses the standard procedure to send the CS connect message for the alerting call to MSC as e.g. described in TS 24.008 [24].

NOTE 4: Solution for possible race conditions (e.g. MSC server receives the CS set call hold before the SCC AS responds) will be defined in Stage 3.

13b. The MSC has one active and one held call for the UE.

14. The MSC notifies the SCC AS the user has answered the call.

15. Standard procedures are used at S-CSCF for routeing of the notification to the SCC AS.

16. The SCC AS creates the corresponding SIP request to the remote end and updates the remote leg.

6.3.2.1.8 PS – CS Access Transfer: Conferencing – for UEs not using ICS capabilities

When the UE is using a conference service and Access Transfer between PS and CS access networks happens, the conference information should be provided by the SCC AS.

The following procedures require that the use of network capabilities to support MSC Server assisted mid-call feature during Access Transfer is supported by the UE and the network according to clause 6.3.2.1.1a, clause 6.3.2.1.4a or clause 6.3.2.1.6 for PS to CS Access Transfer, and according to clause 6.3.2.1.2a for CS to PS Access Transfer. They further require that the MSC Server is enhanced for ICS as specified in TS 23.292 [5].

When the UE in an on-going conference performs Access Transfer from PS to CS, the SCC AS shall provide the conference information (i.e. conference URI, identifier of all participants, etc.) to the MSC Server on the Target Access Leg. When the MSC Server receives the conference information, it shall create a conference state in CS access network (i.e. call in MPTY). When multiple multi-media sessions including a conference exist, if the active session being transferred or the selected additional session to be transferred is a conference call, the conference information shall also be included in the session state information to be sent by the SCC AS to the MSC Server. The MSC Server enhanced for ICS using the conference information then performs conference control on behalf of the UE as specified in clause 7.6.2.8 of TS 23.292 [5]. The MSC Server not enhanced for ICS performs conference control as specified in clause 7.6.3.6 of TS 23.292 [5] after the Access Transfer from PS to CS.

MSC Server enhanced for ICS or the MSC Server not enhanced for ICS may subscribe the conference related events in IMS after the access transfer from PS to CS and when the MSC server receives the conference related events, it should inform the UE of the events.

When the UE in an on-going conference performs Access Transfer from CS to PS, the SCC AS shall provide the conference information (i.e. conference URI, etc.) to the UE on the Target Access Leg. When multiple sessions including a conference exist, if the active session being transferred or the additional held session is a conference call, the conference information shall also be included in the Session State Information to be sent by the SCC AS to the UE. The UE then uses the conference information to control the conference in PS domain as specified in TS 24.147 [25].

6.3.2.1.9 PS – CS Access Transfer: PS to CS – Single Radio using ATCF enhancements

6.3.2.1.9.1 ATCF with media anchored in ATGW

This clause describes the main differences with the (v)SRVCC procedures specified in clauses 6.3.2.1.4 and 6.3.2.1.4a for the case when the media is anchored in the ATGW and the ATCF enhancements are used. A pre-requisite for this scenario is that the ATCF has been included during the IMS registration according to clause 6.1.2. Some of the procedures that are not impacted have been left out for clarity of the flow.

Figure 6.3.2.1.9.1-1: PS to CS Access Transfer when using ATCF enhancements and media anchored.

1. Interaction between UE, RAN, MME/SGSN and MSC Server as specified in TS 23.216 [10]. The following step is triggered after the MSC Server has received the PS to CS request from the MME / SGSN and has allocated resources in the RAN.

NOTE 1: In case of PS HO taking place in parallel, and according to TS 23.216 [10] clauses 6.2.2.2 and 6.3.2.2, both the MSC Server and the target SGSN send independently the Reloc / HO Req to the target RAN. The target RAN synchronizes the PS and CS resource allocation based on information (received in transparent containers provided by the source RAN) before responding to both MSC Server and SGSN, which in turn respond to the source MME/SGSN. The source MME/SGSN will instruct the UE to move to the target RAN when having received responses from both SGSN and MSC Server.

2. The MSC Server initiates Access Transfer message, and if supported, the MSC Server indicates its capability to support MSC Server assisted mid-call feature. The MSC Server provides all the supported Codecs for voice or voice and video in the Access Transfer message.

NOTE 2: It is expected that the CS MGW will support the Codecs used for the PS session, and thereby the likelihood is minimized that ATCF has to instruct the ATGW to insert Codecs (i.e. for transcoding).

3. The ATCF receives the Access Transfer message and correlates the transferred session using the C-MSISDN. The ATCF identifies the correct anchored session and proceeds with the Access Transfer of the most recently active speech session. The ATCF updates the ATGW by replacing the existing PS access leg media path information with the new CS access leg media path information, by sending a Configure ATGW message to ATGW. ATCF may provide priority handling if the Access Transfer message contains priority indication.

NOTE 3: The ATCF could instruct the ATGW to keep using the local port of the PS access leg media path for the new CS access leg media path.

4. The ATGW sends Configure ATGW Acknowledgment message back to ATCF.

5. The ATCF sends an Access Transfer response to the MSC Server. The media path is switched to CS when receiving SDP information.

NOTE 4: If the ATCF instructs the ATGW to use the local port of the PS access leg media path for the new CS access leg media path, the Access Transfer response can be sent right after step 3.

NOTE 5: Since step 2 to 5 are in parallel to step 1, the voice interruption starts when either the media is switched to the CS MGW controlled by the MSC Server enhanced for (v)SRVCC or when the UE starts to relocate to the target (whatever comes first). The media interruption ends when the UE has tuned to the target and media has switched to CS MGW (whatever comes last). It is assumed that the media is switched to CS MGW during the time the UE tunes to target.

6. After receiving the Access Transfer message, the ATCF re-establishes the communication with the SCC AS and updates the SCC AS that the transfer has taken place by sending an Access Transfer Update message to the SCC AS using the stored ATU-STI. If the MSC server indicated it supported mid-call feature, it also indicates this in the message to the SCC AS. The Access Transfer Update creates a new dialogue between the ATCF and SCC AS. The SCC AS correlates the new dialog with the remote dialog (e.g., using the C-MSISDN). As there is no update in the session description, no remote end update will be performed.

NOTE 6: The new dialog between ATCF and SCC AS is needed to replace the old dialog that has been setup over the PS access leg (and registration). This is to ensure that if the PS registration for the user expires, the new home leg will not be released / affected.

7. The SCC AS sends confirmation response to the ATCF. If the SCC AS and MSC Server supports mid call feature, the SCC AS provides the SSI according to clause 6.3.2.1.4a.

8. If the ATCF receives the SSI, it forwards the SSI to the MSC server.

9. If the MSC Server receives the Session State Information of more than one active or inactive speech sessions, it initiates Access Transfer towards SCC AS for the additional session.

NOTE 7: The Access Leg for the control has moved over to the CS access.

10. Procedures according to clause 6.3.2.1.4, steps 4a and 4b are used to handle the cases where the Gm reference point is either retained upon PS handover procedure, not retained upon PS handover, or if there was no other media flow(s) in the IMS session.

6.3.2.1.9.2 ATCF without media anchored in ATGW

This clause describes the main differences with the (v)SRVCC procedures specified in clauses 6.3.2.1.4 and 6.3.2.1.4a for the case when the ATCF is included in the session path, but media has not been anchored in ATGW. Some of the procedures that are not impacted have been left out for clarity of the flow.

Figure 6.3.2.1.9.2-1: PS to CS access transfer

NOTE 1: In case of PS HO taking place in parallel, and according to TS 23.216 [10] clause 6.2.2.2 and clause 6.3.2.2, both the MSC Server and the target SGSN send independently the Reloc / HO Req to the target RAN. The target RAN synchronizes the PS and CS resource allocation based on information (received in transparent containers provided by the source RAN) before responding to both MSC Server and SGSN, which in turn respond to the source MME/SGSN. The source MME/SGSN will instruct the UE to move to the target RAN when having received responses from both SGSN and MSC Server.

2. The MSC Server initiates Access Transfer message and if supported, the MSC Server indicates its capability to support MSC Server assisted mid-call feature. The MSC Server provides all the supported Codecs for voice or voice and video in the Access Transfer message.

3. The ATCF receives the Access Transfer message and correlates the transferred session using the C-MSISDN. As the media flow has not been anchored in the ATGW, the ATCF forwards the Access Transfer message along with priority indication if received to the SCC AS using the stored ATU-STI. If the MSC server indicated it supported mid-call feature, it also indicates this in the message to the SCC AS.

4. The SCC AS correlates the incoming Access Transfer message. As the Session Description has changed, a remote end update is initiated according to clause 6.3.1.5.

5. The SCC AS sends an Access Transfer response to the MSC Server, and in the case MSC Server assisted mid-call feature is supported and used, the SCC AS provides Session State Information (SSI) according to clause 6.3.2.1.4a.

6. The ATCF forwards the response to the MSC server.

7. If the MSC Server receives the Session State Information of more than one active or inactive speech sessions, it initiates Access Transfer towards SCC AS for the additional session according to clause 6.3.2.1.4a.

8. Procedures according to clause 6.3.2.1.4, steps 4a and 4b are used to handle the cases where the Gm reference point is either retained upon PS handover procedure, not retained upon PS handover, or if there was no other media flow(s) in the IMS session.

6.3.2.1.9.3 ATCF not included during registration

If the decision by the ATCF during registration was not to be included at all, the SRVCC procedures will fall back to procedures according to clauses 6.3.2.1.4 and 6.3.2.1.4a.

6.3.2.1.10 PS – CS Access Transfer: CS to PS – Single Radio

6.3.2.1.10.1 CS to PS – Single Radio procedures with CS media anchored in ATGW

Figure 6.3.2.1.10.1-1 PS-CS: CS to PS – Single Radio, provides an information flow for Access Transfer of a CS speech media flow in CS to PS direction for Access Transfers within 3GPP access networks as specified in TS 23.216 [10].

The flow requires that the user is active or inactive in a CS originating or terminating speech session; procedures and capabilities specified in TS 23.216 [10] are used for the switching of access networks at the transport layer. It further requires that the UE has an active IMS registration prior the transfer take place.

Figure 6.3.2.1.10-1: CS to PS – Single Radio procedures with CS media anchored in ATGW

1. Procedures specified in TS 23.216 [10] result in that the MSC Server receives a CS to PS HO request.

2. The MSC Server initiates a Session Transfer Notification towards the ATCF, which indicates to the ATCF that it should prepare for the transfer of media to PS. The ATCF responds with information required for the transfer, including allocated media IP/ports for UL direction and UE’s port for DL direction and voice codec information allocated in the ATGW.

NOTE 1: The ATCF retrieves the ports/codec information from the UE during the IMS registration.

3. The MSC Server performs the CS to PS HO preparation procedures by interacting with target MME/SGSN to initiate the handover according to TS 23.216 [10].

4. When the target MME/SGSN have reserved appropriate resources in the target network, the MSC Server sends a Session Transfer Preparation request to the ATCF to instruct the ATCF that media should be switched to the target access and also triggers the UE to hand over to the target according to TS 23.216 [10].

5. The ATCF switches the media path in the ATGW from the source access to target access.

NOTE 2: The voice media will be sent on the target access on the pre-negotiated ports between UE and ATGW.

6. The UE initiates a Session Transfer Complete request to the ATCF to move the session control to the PS access. If mid-call and alerting is supported, the UE will include this in the request.

7. The ATCF sends a Session Transfer Complete response to the UE and releases the Source Access Leg toward the MSC Server.

NOTE 3: PCC interactions will be performed by the P-CSCF according to standard procedures of TS 23.228 [4] during step 6 and step 7. This will create the dedicated voice bearer for the session.

8. After receiving the Session Transfer Complete message, the ATCF re-establishes the communication with the SCC AS and updates the SCC AS that the transfer has taken place by sending an Access Transfer Update message to the SCC AS using the stored ATU-STI and C-MSISDN. If the UE indicated it supported mid-call feature and/or alerting, it also indicates this in the message to the SCC AS. The Access Transfer Update creates a new dialogue between the ATCF and SCC AS. The SCC AS correlates the new dialog with the remote dialog (e.g., using the C-MSISDN). As there is no update in the session description, no remote end update will be performed.

9. The SCC AS sends confirmation response to the ATCF. If the SCC AS and UE supports mid-call feature and/or alerting, the SCC AS provides the Session State Information (SSI) according to clause 6.3.2.1.2a. The Session State Information includes the additional held session with speech media including dynamic STI needed for the held session on the transferring-in leg.

10-11. If the ATCF receives the SSI, it forwards the SSI to the UE.

12. If the UE receives the Session State Information of the held session, it initiates a Access Transfer request towards the SCC AS using the dynamic STI for the held session.

6.3.2.1.10.2 CS to PS – Single Radio procedures without CS media anchored in ATGW

Figure 6.3.2.1.10.1-2 PS-CS: CS to PS – Single Radio, provides an information flow for Access Transfer of a CS speech media flow in CS to PS direction for Access Transfers within 3GPP access networks as specified in TS 23.216 [10].

Figure 6.3.2.1.10-2: CS to PS – Single Radio procedures without CS media anchored in ATGW

1. Procedures specified in TS 23.216 [10] result in that the MSC Server receives an CS to PS HO request.

NOTE 1: The ATCF retrieves the ports/codec information from the UE during the IMS registration.

3. The MSC Server performs the CS to PS HO preparation procedures by interacting with target MME/SGSN to initiate the handover according to TS 23.216 [10].

4. When the target MME/SGSN have reserved appropriate resources in the target network, the MSC Server sends a Session Transfer Preparation request to the ATCF.

5. When receiving the Session Transfer Preparation request from the MSC Server, the ATCF reserves ATGW resources for the media path connected to MGW and then sends a Session Transfer Preparation response to the MSC Server. Upon receipt of the Session Transfer Preparation response, the MSC Server instructs the MGW to switch the media path from the source access (CS RAN) to the target access (ATGW), and also triggers the UE to hand over to the target according to TS 23.216 [10].

NOTE 2: The voice media will be sent on the target access on the designated ports between UE and ATGW.

6. The UE initiates a Session Transfer Complete request to the ATCF to move the session control to the PS access. If mid-call and alerting is supported, the UE will include this in the request.

7. The ATCF sends an Session Transfer Complete response to the UE.

NOTE 3: PCC interactions will be performed by the P-CSCF according to standard procedures of TS 23.228 [4] during step 6 and step 7. This will create the dedicated voice bearer for the session.

8. After receiving the Session Transfer Complete message, the ATCF re-establishes the communication with the SCC AS and updates the SCC AS that the transfer has taken place by sending an Access Transfer Update message to the SCC AS using the stored ATU-STI and C-MSISDN. If the UE indicated it supported mid-call feature and/or alerting, it also indicates this in the message to the SCC AS. The Access Transfer Update creates a new dialogue between the ATCF and SCC AS. The SCC AS correlates the new dialog with the remote dialog (e.g., using the C-MSISDN). As there is update in the session description, Remote Leg Update and Source Access Leg procedures (to release unused resources at the CS MGW) will be performed as specified in 6.3.1.5 and 6.3.1.6 respectively.

10-11. If the ATCF receives the SSI, it forwards the SSI to the UE.

12. If the UE receives the Session State Information of the held session, it initiates an Access Transfer request towards the SCC AS using the dynamic STI for the held session.

6.3.2.2 PS – PS Access Transfer

NOTE: If a PS-PS session transfer occurs and there is a change in IP address, TCP-based media flow(s) using transferring-out access will break. Recovery procedures from broken TCP connections are application specific.

6.3.2.2.1 PS-PS Access Transfer with full media transfer

UE‑1 is attached to one IP-CAN and it registers to the S-CSCF. UE-1 establishes an active multimedia session with UE-2 via this IP‑CAN. After changing to a new IP‑CAN, obtaining new signalling and media addresses, and completing the Access Transfer procedures, UE‑1 continues the multimedia session with UE‑2 via the new IP‑CAN.

Figure 6.3.2.2.1-1: Information flow for PS-PS Access Transfer

1. UE‑1 connects to a new IP‑CAN and receives new IP address(es). UE‑1 decides to perform PS to PS Access Transfer based on SC policy information.

2. UE‑1 registers to the S‑CSCF via the new IP‑CAN. This registration may go through the same P‑CSCF or a different P‑CSCF.

3 ~ 5. UE‑1 sends an INVITE message on the new IP-CAN towards the SCC AS. The INVITE message includes the STI identifying the session to be transferred. The INVITE message also indicates to the SCC AS that it performs Access Transfer with full media transfer.

6. The SCC AS identifies the session based on STI and updates the session over the remote access leg (see clause 6.3.1.5).

7. The SCC AS completes session setup with UE-1 on the new access leg and releases old session based on the standard IMS procedures.

6.3.2.2.2 PS-PS Access Transfer with partial media transfer

UE‑1 is on an active multimedia session with UE‑2 via one IP‑CAN. After changing to a new IP‑CAN and obtaining new signalling and media addresses, UE‑1 transfers part of the multimedia session with UE‑2 to the new IP‑CAN and keeps the remaining part on the original IP‑CAN. UE‑1 is attached to both the new and old IP‑CANs after the Access Transfer procedures. The call flow is the same as shown in clause 6.3.2.2.1. The only difference is that in Step 3, the INVITE needs to indicate that the request is for a partial transfer and instead of releasing the old session in step 7, the UE updates session information over the old access leg. In this case, the INVITE message sent in step 3 shall indicate the media flow(s) which need to be transferred to the new IP‑CAN.

6.3.2.2.3 PS-PS Access Transfer with full media transfer for an incoming call in early dialog phase

UE‑1 is attached to IP‑CAN 1 and registered to IMS over that IP‑CAN. UE-1 and is in the process of establishing an incoming multimedia session with UE‑2 via this IP CAN. While an early dialog has been established over IP‑CAN 1, UE‑1 detects that an Access Transfer to IP‑CAN 2 is required.

Figure 6.3.2.2.3-1: PS-PS Access Transfer with full media transfer incoming call in early dialog phase

1-4. Standard procedures are used to initiate a SIP session over IP CAN 1 from the remote end towards UE‑1. An early dialog has been established and UE‑1 might be alerting the user.

5-6. If it has not done it yet, UE‑1 connects to a new IP‑CAN, IP‑CAN 2, and receives new IP address(es). It then registers to the S‑CSCF via IP‑CAN 2. This registration may go through the same P‑CSCF or a different P‑CSCF. UE 1 decides to perform PS to PS Access Transfer based on SC policy information.

7-8. UE 1 sends an INVITE message on IP‑CAN2 towards the SCC AS. The INVITE message includes the STI identifying the session to be transferred. The INVITE message also indicates to the SCC AS that it performs Access Transfer with full media transfer.

9. The SCC AS identifies the early dialog, and updates the session over the remote access leg (see clause 6.3.1.5).

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the PS-PS access transfer, thus the SCC AS can update the remote leg.

10-11. The SCC AS answers to UE‑1 over IP‑CAN 2 with the appropriate message to have the new session moved to the same state as the session on the transferred out access.

12. The UE determines that the session has been transferred to IP‑CAN 2, and continues to alert the user for incoming call if appropriate.

13-15. UE‑1 sends the final response. The remote end is notified, and the session starts over IP‑CAN 2.

6.3.2.2.4 PS-PS Access Transfer with full media transfer for an outgoing call in early dialog phase

UE‑1 is attached to IP‑CAN 1 and registered to IMS over that IP‑CAN. UE‑1 and is in the process of establishing an outgoing multimedia session with UE‑2 via this IP‑CAN. While an early dialog has been established over IP‑CAN 1, UE‑1 detects that an Access Transfer to IP‑CAN 2 is required.

Figure 6.3.2.2.4-1: PS-PS Access Transfer with full media transfer outgoing call in early dialog phase

1-4. Standard procedures are used to initiate a SIP session over IP‑CAN 1 from the UE towards the remote end. An early dialog has been established and the remote end might be alerting the user.

5-6. If the UE has not done it yet, UE‑1 connects to a new IP‑CAN, IP‑CAN 2, and receives new IP address(es). It then registers to the S‑CSCF via IP‑CAN 2. This registration may go through the same P‑CSCF or a different P‑CSCF. UE‑1 decides to perform PS to PS Access Transfer based on SC policy information.

7-8. UE‑1 sends an INVITE message on IP‑CAN2 towards the SCC AS. The INVITE message includes the STI identifying the session. The INVITE message also indicates to the SCC AS that it performs Access Transfer with full media transfer.

9. The SCC AS identifies the early dialog, and updates the session over the remote access leg (see clause 6.3.1.5).

NOTE 1: It is assumed the initial SDP negotiation has been completed prior to triggering the PS-PS access transfer, thus the SCC AS can update the remote leg.

10-11. The SCC AS answers to UE‑1 over IP‑CAN 2 with the appropriate message to have the new session moved to the same state as the session on the transferred out access.

12. The UE determines that the session has been transferred to IP‑CAN 2. The UE ensures that the same ringback tone is played to the end user if appropriate.

13-14. The remote end sends the final response. UE‑1 is notified, and the session starts over IP‑CAN 2.

6.3.2.3 PS – PS in conjunction with PS – CS Access Transfer

6.3.2.3.1 PS – PS in conjunction with PS – CS Access Transfer: PS to CS for UEs not using ICS capabilities

It is required that the UE has a single ongoing IMS session containing speech or speech and video and other media with the remote end. After the Access Transfer, the two sessions are treated as independent sessions on the transferring-in Access Legs for mid-call service (e.g. hold of PS or CS media).

Figure 6.3.2.3.1-1: PS-PS in conjunction with PS-CS Access Transfer: PS to CS

1. When the UE determines a need for Access Transfer, the UE attaches to CS (if not already attached). It subsequently initiates the PS–CS Access Transfer by sending a CS call setup including the STN to establish the Access Leg via the CS access. A static STN preconfigured to the UE is used.

2. An INVITE is routed to the I/S-CSCF.

3. An INVITE is routed to the SCC AS.

4. The SCC AS performs the Remote Leg update by using procedures defined in clause 6.3.1.5. The SCC AS updates the speech or speech and video media being transferred in the session towards the Remote Leg.

5. The SCC AS completes the session setup towards UE according to procedures defined in TS 23.228 [4].

6. The UE initiates registration with IMS via the new PS access (if not already registered) as specified in clause 6.1. It subsequently initiates the PS–PS Access Transfer by sending an INVITE including the SDP for the non-real-time media flow(s) and STI to establish the Access Leg via the PS access. A dynamic STI allocated at the time of IMS session creation is used.

7. An INVITE is routed to the SCC AS.

8. The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg update by using procedures defined in clause 6.3.1.5. The SCC AS updates the non-real-time media flow(s) in the session towards the Remote Leg.

9. The SCC AS completes the session setup towards UE according to procedures defined in TS 23.228 [4].

10. Source Access Leg Release is performed according to the procedures defined in clause 6.3.1.6.

NOTE: Steps 1-5 can be performed in reversed order with steps 6‑8.

6.3.2.3.2 PS – PS in conjunction with PS – CS Access Transfer: CS to PS for UEs not using ICS capabilities

It is required that the UE has an ongoing CS call and a related IMS session with the remote end.

Figure 6.3.2.3.2-1: PS-PS in conjunction with PS-CS Access transfer: CS to PS

1. When the UE determines a need for Access Transfer, the UE initiates registration with IMS via the new PS access (if not already registered) as specified in clause 6.1. It subsequently initiates the Access Transfer by sending an INVITE to establish the Access Leg via the PS access. The INVITE includes the SDP for speech or speech and video and non-real-time media flow(s) and STI-1 and STI-2 respectively for the IMS session using CS and the IMS session using PS to be transferred. For STI-1 a static STI preconfigured to the UE is used. For STI-2 a dynamic STI allocated at the time of IMS session creation is used. STI-1 and STI-2 are never the same.

2. Standard procedures are used at S-CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS identifies the session to be transferred using the STI-1 and STI-2. The SCC AS performs the Remote Leg Update by using procedures defined in clause 6.3.1.5. The SCC AS updates the combined session towards the Remote Leg.

4. The SCC AS completes the session setup towards UE-1 according to procedures defined in TS 23.228 [4].

5. Source Access Leg Release is performed according to the procedures defined in clause 6.3.1.6.

6.3.2.3.3 PS – PS in conjunction with PS – CS Access Transfer: PS to CS for UEs with ICS capabilities – Using Gm reference point

Figure 6.3.2.3.3-1 PS-PS in conjunction with PS–CS Access Transfer: PS to CS for UEs with ICS capabilities, provides an information flow for Access Transfer of real time media flow(s) of an IMS session in PS to CS direction and zero or more non real time media flow(s) in PS to PS direction. The UE may choose to retain some of the non real time media flow(s) in the original PS access.

The flow requires that the user is in an active or inactive IMS originating or terminating session; the Gm reference point of ICS is used for control of IMS sessions that use CS media.

Figure 6.3.2.3.3-1: PS-PS in conjunction with PS-CS Access transfer: PS to CS for UEs with ICS capabilities

1. When the UE determines a need for Access Transfer, the UE initiates registration with IMS via the new PS access (if not already registered) as specified in clause 6.1. It subsequently initiates the "Originations with CS media using the Gm reference point" procedure as specified in TS 23.292 [5], clause 7.3.2.2.4 by sending an INVITE including the STI to establish the Access Leg via the PS access. The INVITE also includes an indication to use a CS bearer for the real time media and a description of non real time media flow(s) that are to be transferred to the new PS access if any non real time media is present at the time of initiation of Access Transfer.

2. Standard procedures are used at S-CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS identifies the session to be transferred using the STI and the media flow(s), and continues the "Originations with CS media using the Gm reference point" procedure for completion of the setup of CS media for the Access Leg by allocating a SCC AS PSI DN and sending it in a reliable provisional response to the S-CSCF (see TS 23.292 [5] for SCC AS PSI DN).

4. The S-CSCF forwards the provisional response (containing the SCC AS PSI DN) to the UE.

5. The UE continues the "Originations with CS media using the Gm reference point" procedure by sending a Setup message including the SCC AS PSI DN to establish the CS media for the Access Leg.

6. The "Originations with CS media using Gm reference point procedure" is used at the CS and IMS intermediate nodes, resulting in routing of an INVITE to the I/S-CSCF.

7. The I/S-CSCF extends the INVITE with the SCC AS PSI and SDP of the MGW as part of the "Originations with CS media using the Gm reference point" procedure.

8. The SCC AS uses the SCC AS PSI to correlate the incoming session via the CS access with the Access Transfer request previously received via the PS access.

The SCC AS completes the establishment of the Access Leg by combining the description of the media established via the CS access with the description of the media flow(s) established via the PS access for the signalling associated with the Access Leg.

The SCC AS performs the Access Transfer by updating the Remote Leg with the media description and other information of the newly established Access Leg using the Remote Leg Update procedure as specified in clause 6.3.1.5.

9a. If the UE transfers all the non real time media flow(s) to the new PS access, the Source Access Leg (which is the Access Leg previously established over PS access) is released as specified in clause 6.3.1.6.

9b. If the UE chooses to retain some media flow(s) in the original PS access, then:

9b1. the UE sends an INVITE to the SCC AS (as part of the existing dialog) to update the session information over the Source Access Leg; and

9b2. the SCC AS performs the Remote Leg update (if necessary) by using procedures defined in clause 6.3.1.5. The Source Access Leg is not released in this case.

NOTE: Steps 8 and 9 consist of a sequence of messages, some of which may occur in parallel.

6.3.2.3.4 PS – PS in conjunction with PS – CS Access Transfer: CS to PS for UEs with ICS capabilities – Using Gm reference point

The information flow for Access Transfer of real time media of an IMS session in CS to PS direction, and zero or more non real time media flow(s) in PS to PS direction is the same as the information flow for PS–CS Access Transfer: CS to PS access, as specified in clause 6.3.2.1.2.

The flow requires that the user is in an active or inactive IMS originating or terminating session; the Gm reference point of ICS is used for control of IMS sessions that use CS media; and a dynamic STI is associated with each session.

6.3.2.3.5 PS – PS in conjunction with PS – CS Access Transfer: Active/Held sessions – Using Gm reference point

Figure 6.3.2.3.5-1 PS–PS in conjunction with PS–CS Access Transfer: Active/Held sessions, provides an information flow for Access Transfer of real time media flow(s) of one active and one or more held sessions between PS and CS, any of which may have zero or more non real time media flow(s) which is transferred within the PS access.

The flow requires that the user is in an active IMS originating and/or terminating sessions; the Gm reference point of ICS is used for control of IMS sessions that use CS media; and a dynamic STI is associated with each session.

Figure 6.3.2.3.5-1: PS-PS in conjunction with PS-CS Access transfer: Active/Held sessions

1a, 1b. When the UE determines a need for Access Transfer, the UE initiates the Access Transfer of the active session as specified in clause 6.3.2.3.3 PS–PS in conjunction with PS–CS Access Transfer: PS to CS for UEs with ICS capabilities, or clause 6.3.2.3.4 PS–PS in conjunction with PS-CS Access Transfer: CS to PS for UEs with ICS capabilities, based on the direction of the Access Transfer of the real time media. The STI of the active session is used by SCC AS to identify the active session.

1c. The UE and the SCC AS complete the Access Transfer of the active session.

2a, 2b. The UE initiates the Access Transfer of the first held session using the same procedures as identified in steps 1a and 1b with a difference that for transfer to CS access, the CS media is not established for the held session; the media established upon the transfer of the currently active session is reused for the held session when it is resumed. The STI of the held session is used by SCC AS to identify the held session.

2c. The UE and the SCC AS complete the Access Transfer of the held session.

Steps 2a, 2b and 2c are repeated for the remaining held sessions.

NOTE 1: Steps 1c and 2c consist of a sequence of messages, which may occur in parallel.

NOTE 2: Another supported scenario is when there are no active sessions, i.e. the session in 1a and 1b may also be a held session.

6.3.2.3.6 PS – PS in conjunction with PS – CS Access Transfer: Explicit Communication Transfer – Using Gm reference point

Prior to consultative transfer, the transferor UE may have one session with the transferee UE and one session with the transfer target UE. If the transferor UE performs Access Transfer in this case, the information flow for PS–PS in conjunction with PS–CS Access Transfer: Explicit Communication Transfer is the same as the information flow in clause 6.3.2.3.5 PS–PS in conjunction with PS–CS Access Transfer: Active/held sessions.

For all other cases in ECT service, there is only one session at the UE. Depending on the direction of the Access transfer, the following information flows apply:

– the information flow in clause 6.3.2.3.3 for PS-PS in conjunction with PS-CS Access Transfer: PS to CS; or,

– the information flow in clause 6.3.2.3.4 for PS-PS in conjunction with PS-CS Access Transfer: CS to PS.

The flow requires that the user is active in IMS originating and/or terminating sessions with the Explicit Communication Transfer service; the Gm reference point of ICS is used for control of IMS sessions that use CS media; and a dynamic STI is associated with each session.

6.3.2.3.7 PS – PS in conjunction with PS – CS Access Transfer: Conferencing – Using Gm reference point

The information flows for PS–PS in conjunction with PS–CS Access Transfer: Conferencing in PS to CS and CS to PS directions, are the same as the information flows in clause 6.3.2.3.3 PS–PS in conjunction with PS–CS Access Transfer: PS to CS for UEs with ICS capabilities, and clause 6.3.2.3.4 PS–PS in conjunction with PS–CS Access Transfer: CS to PS for UEs with ICS capabilities respectively.

The flow requires that the user is in an active or inactive IMS originating and/or terminating sessions with the Conferencing service; the Gm reference point of ICS is used for control of IMS sessions that use CS media.

6.3.2.3.8 PS – PS in conjunction with PS – CS Access Transfer: PS to CS – using I1 reference point

Figure 6.3.2.3.8-1 PS‑CS in conjunction with PS‑CS Access Transfer: PS to CS access – using I1 reference point, provides an information flow for Access Transfer of real time media flow(s) of an IMS session in PS to CS direction.

The flow requires that the user is in an active or inactive IMS originating or terminating session; the I1 reference point of ICS is used for control of IMS sessions that use CS media; and a unique STI is associated with each session.

Figure 6.3.2.3.8-1: PS–CS in conjunction with PS–CS Access Transfer: PS to CS access – using I1 reference point

2. The SCC AS identifies the session to be transferred using the STI, and continues the "Originations to a SIP URI" procedure for completion of the setup of CS media for the Access Leg by allocating a SCC AS PSI DN and sending it in an I1, ICS Call Initiation Result; see TS 23.292 [5] for SCC AS PSI DN.

3. The UE continues the "Originations to a SIP URI" procedure by sending a Setup message including the SCC AS PSI DN to establish the CS media for the Access Leg.

4. The "Originations to a SIP URI" procedure is used at the CS and IMS intermediate nodes, resulting in routeing of an INVITE with the SCC AS PSI to the I/S-CSCF.

5. The I/S-CSCF forwards the INVITE with the SCC AS PSI and SDP of the MGW as part of the "Originations with CS media using the Gm reference point" procedure.

6. The SCC AS uses the SCC AS PSI to correlate the CS bearer control signalling request received via the CS access with the Access Transfer request previously received via the PS access.

7. The Source Access Leg (which is the Access Leg previously established over PS access) is released as specified in clause 6.3.6.

NOTE: Steps 6 and 7 consist of a sequence of messages, some of which may occur in parallel.

6.3.2.3.9 PS – PS in conjunction with PS – CS Access Transfer: CS to PS – using I1 reference point

The information flow for Access Transfer of real time media of an IMS session in CS to PS direction when the I1 reference point is used for service control of sessions that use CS media, is the same as the information flow PS–CS Access Transfer: CS to PS access, as specified in clause 6.3.2.1.2.

6.3.2.3.10 PS – PS in conjunction with PS – CS Access Transfer: PS to CS for Active/Held sessions – using I1 reference point

Figure 6.3.2.3.10-1 PS – PS in conjunction with PS – CS Access Transfer: PS to CS for Active/Held sessions – using I1 reference point, provides an information flow for Access Transfer of real time media of one active and one or more held sessions from PS to CS when the I1 reference point is used for service control of sessions that use CS media.

The flow requires that the user is active in IMS originating and/or terminating sessions; the I1 reference point of ICS is used for control of IMS sessions that use CS media; and a unique STI is associated with each session.

Figure 6.3.2.3.10-1: PS – PS in conjunction with PS – CS Access Transfer: PS to CS for Active/Held sessions – using I1 reference point

1a. When the UE determines a need for Access Transfer, the UE initiates the Access Transfer of the active session as specified in clause 6.3.2.3.8 PS – PS in conjunction with PS – CS Access Transfer: PS to CS – using I1 reference point The STI of the active session is used by SCC AS to identify the active session.

1b. The UE and the SCC AS complete the Access Transfer of the active session.

2a. The UE initiates the Access Transfer of the first held session using the same procedures as identified in steps 1a and 1b with a difference that the CS media is not established for the held session; the media path established upon transfer of the currently active session is reused for the held session when it is resumed. The STI of the held session is used by SCC AS to identify the held session.

2b. The UE and the SCC AS complete the Access Transfer of the held session.

Steps 2a and 2b are repeated for the remaining held sessions.

NOTE 1: Steps 1b and 2b consist of a sequence of messages, which may occur in parallel.

NOTE 2: Another supported scenario is when there are no active sessions, i.e. the session in 1a and 1b may also be a held session.

6.3.2.3.11 PS – PS in conjunction with PS – CS Access Transfer: CS to PS for Active/Held sessions – using I1 reference point

Figure 6.3.2.3.11-1 PS – PS in conjunction with PS – CS Access Transfer: CS to PS for Active/Held sessions – using I1 reference point, provides an information flow for Access Transfer of real time media of one active and one or more held sessions from CS to PS when the I1 reference point is used for service control of sessions that use CS media.

Figure 6.3.2.3.11-1: PS – PS in conjunction with PS – CS Access Transfer: CS to PS for Active/Held sessions – using I1 reference point

1a, 1b. When the UE determines a need for Access Transfer, the UE initiates the Access Transfer of the active session as specified in clause 6.3.2.3.9 PS – PS in conjunction with PS – CS Access Transfer: CS to PS – using I1 reference point. The STI of the active session is used by SCC AS to identify the active session.

1c. The UE and the SCC AS complete the Access Transfer of the active session.

2a, 2b. The UE initiates the Access Transfer of the first held session using the same procedures as identified in steps 1a, 1b and 1c. The STI of the held session is used by SCC AS to identify the held session.

2c. The UE and the SCC AS complete the Access Transfer of the held session.

Steps 2a, 2b and 2c are repeated for the remaining held sessions.

NOTE: Steps 1c and 2c consist of a sequence of messages, which may occur in parallel.