IMS sessions from and to a UE are anchored at the SCC AS in the home IMS and may also be anchored at the ATCF in the serving (visited if roaming) network to provide Service Continuity for the user during transition between two Access Networks. Sessions are anchored at the SCC AS in the home IMS, based on iFC. A 3pcc (3rd party call control) function is employed at the SCC AS to facilitate inter-Access Network mobility through the use of Access Transfers between the two Access Networks. IMS media sessions may be anchored by the ATCF during session establishment depending on operator policy. Access Transfers may be enabled in one or both directions as per network configuration requirements. The SCC AS has the capability to perform Access Transfers for a UE's sessions multiple times. Initiation of Access Transfer procedures for ongoing multimedia session may be based on the operator policy received from the SCC AS.

IMS sessions established in CS or PS Access Networks are anchored at the SCC AS. Additionally, IMS media sessions subject to CS to PS or PS to CS SRVCC can be anchored by the ATCF. IMS sessions using CS bearer are established at session setup or upon Access Transfer using procedures specified in TS 23.292. PS-CS Access Transfer shall be provided according to the requirements specified in clause 22.3 of TS 22.101, Service Continuity. When using a UE that does not have, or that is unable to use, ICS UE capabilities as specified in TS 23.292, Access Transfer of one active bi-directional speech or speech and video session and zero or one inactive bi-directional speech session shall be provided when transferring speech and/or video media flow between CS and PS access. For PS to CS (not CS to PS) Access Transfer, if the UE has more than one anchored active bi-directional session, the session that was most recently made active shall be transferred. When using a UE that is able to use ICS capabilities as specified in TS 23.292, Access Transfer of one active bi-directional speech or speech and video session and zero or more inactive bi-directional speech sessions shall be provided using the Gm reference point, or optionally the I1 reference point, of ICS to transport required information, as specified in TS 23.292, when transferring speech and/or video media flow between CS and PS access. For PS to CS Dual Radio Access Transfer, if the UE has more than one anchored active bi-directional speech session, then the UE shall first request transfer of one of the active bi-directional sessions, put the remaining active sessions on hold and then request the transfer of one of the remaining inactive bi-directional sessions. Access Transfer shall also be provided for one or more inactive bi-directional speech sessions if the UE has no active bi-directional speech sessions. When Single Radio PS-to-CS Access Transfer is performed for an active bi-directional speech and video session, if the UE and network do not support ICS capabilities, all the remaining bi-directional speech and speech + video sessions, if any, are released by the UE and SCC AS. The SCC AS maintains, for all active and inactive sessions, Session State Information as defined in clause 4.3.3. For PS to CS Access Transfer, if the Access Transfer request has been sent by MSC Server or by the UE through the MSC Server and if the MSC Server has indicated its capability and ICS UE capability cannot be used upon transfer, then the SCC AS shall provide Session State Information to the MSC Server enhanced for ICS or (v)SRVCC as specified in TS 23.292 and TS 23.216, respectively. The SCC AS shall not provide Session State Information if either the UE or operator policy on the SCC AS indicates that network capabilities shall not be used to support mid-call services during Access Transfer. When receiving information about an additional session, the MSC Server enhanced for ICS or (v)SRVCC shall initiate Access Transfer towards the SCC AS for the additional session. When receiving information for a session, the MSC Server shall create a service context for this session using this information and perform service control on behalf of the UE as specified in TS 23.292. For CS to PS Access Transfer initiated by a UE not able to use ICS capability, the SCC AS shall provide Session State Information to the UE on the transferring-in leg.

The MSC Server assisted mid-call feature provides the preservation of mid-call services (inactive sessions or sessions using the Conference service) upon PS - CS Access Transfer without requiring the UE to use ICS capabilities. When the MSC Server assisted mid-call feature is enabled, the MSC Server, the SCC AS and the UE shall support one or more of the procedures specified in clause 6.3.2.1.1a, clause 6.3.2.1.2a, clause 6.3.2.1.4a, clause 6.3.2.1.6, clause 6.3.2.1.7, clause 6.3.2.1.7a, clause 6.3.2.1.7b and clause 6.3.2.1.8. The MSC Server assisted mid-call feature shall only be triggered if UE, MSC Server, and SCC AS all support the MSC Server assisted mid-call feature.

A UE may implement both ICS UE capability and the MSC Server assisted mid-call feature for situations when the ICS UE capabilities cannot be used or be maintained after the transfer. For such a scenario, if ICS UE indicates both capabilities then the SCC AS needs to determine which capabilities are used to transfer the additional active or inactive sessions. The following logic is applied in the SCC AS to achieve this:

• If the Access Transfer request is made using ICS UE capabilities, the SCC AS detects that ICS UE capabilities are used and executes the transfer according to procedures defined in clause 6.3.2 of the present document.
• If the Access Transfer request is made via the MSC Server, the SCC AS needs to determine whether ICS capabilities are used:
  • If the ICS UE is able to use ICS capabilities, then clause 6.3.2 of the present document applies.
  • If the ICS UE is not able to use ICS capabilities, then MSC Server assisted mid-call feature is used.
  The SCC AS can determine whether ICS capabilities are used based on the local configuration, or alternatively delay for an adequate time sending the session state information to the MSC Server in order to trigger the MSC Server assisted mid-call feature such that the potential re-establishment of Service Control Signalling Path by the ICS UE can be excluded.
• If no Access Transfer request is received, and the SCC AS detects that the ICS UE capabilities can not be used for the ICS UE due to loss of the Service Control Signalling Path over Gm reference point and unavailability of I1 reference point, the MSC Server assisted mid-call feature is used, with the following differences from the PS-CS Access Transfer:
  • the CS Bearer Control Signalling Path(s) is/are used for control of the session(s), with the existing CS bearer Control Signalling Path reused for control of the most recently active session.
  • upon detecting that the Service Control Signalling Path is unavailable then clause 6.3.5 of the present document applies.

IMS sessions from and to a UE are anchored at the SCC AS in the home IMS to provide service continuity for the user when one or more media flows of an ongoing IMS multimedia session are transferred, added or deleted among different UEs. A Collaborative Session, which is split on the local end across two or more UEs and anchored in the SCC AS, is established due to the Inter-UE Transfer procedures; such procedures may be executed by the UE either at the time of IMS session setup or subsequent to IMS session setup. The UE which initiates the Inter-UE Transfer procedures to establish the Collaborative Session becomes the Controller UE of the Collaborative Session and the other UE(s) involved in the Collaborative Session become the Controllee UE(s). Subsequent Inter-UE Transfer procedures, initiated by the Controller UE, can also be performed within the Collaborative Session. The SCC AS provides the coordination of the Collaborative Session procedures which may involve both the Controller UE and the Controllee UE(s). Any IUT capable UE can request IUT Media Control Related Procedures. Such requests are subject to authorization by the SCC AS and/or the Controller UE. Authorization is based on user and/or operator provided application specific settings in the SCC AS and/or the Controller UE. These application specific settings may be associated with the service profile of the Controller UE in service specific data in the HSS. Although any IUT capable UE can request IUT Media Control Related Procedures, there can be only one Controller UE at a time in a Collaborative Session. The UE that establishes the Collaborative Session and whose service profile is active for the session with the remote end is the initial Controller UE. The Controller UE role (Collaborative Session Control) may be transferred to a different UE during the life of the Collaborative Session. Collaborative Session Control may be transferred only to another Controller capable UE that has registered a Public User Identity that shares the same service profile (and thus belongs to the same IMS subscription) as the Controller UE. The Hosting SCC AS does not change during the life of the Collaborative Session. Inter-UE Transfer procedures can also be executed without establishing a Collaborative Session. In this case, the whole IMS multi-media session is transferred from one UE to the other UE, and the roles of the Controller and Controllee UEs are not applicable. Inter-UE Transfer procedures may be initiated by the UE based on the information it gets from Target UE discovery. The UEs that participate in IUT Media Control Related Procedures may belong to different IMS subscriptions under the same operator. When this is the case, the IUT service request must be authorized by the Controller UE (or by its associated SCC AS on behalf of the Controller UE) of a Collaborative Session, and may also be authorized by the SCC AS associated with a Controllee UE or associated with another UE not participating in the Collaborative Session that has issued an IUT service request. In order to perform "network-based" (SCC AS-based) authorization of such requests, the SCC AS can use participant (user)-related information in the request; that is, the SCC AS may authorize a given IUT service request if it is associated with a particular user, but not authorize the same request if it is associated with a different user.