4 High level principles and architectural requirements

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

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

4.1 Basic Assumptions

4.1.0 General

It is assumed that the UE may be capable of transmitting and receiving simultaneously in multiple Access Networks or it may be capable of transmitting and receiving in only one Access Network at a time.

4.1.1 PS-CS Access Transfer

The following assumptions apply for PS-CS Access Transfer:

– Functions of IMS Centralized Services and IMS Service Continuity are collocated in a single SCC AS. Not all functions are always required.

– When (v)SRVCC enhanced with ATCF is used or when 5G-SRVCC is used, additional functions of IMS Service Continuity are provided by the ATCF/ATGW in the serving (visited if roaming) network.

– IMS Centralized Services specifies functions and procedures for use of CS bearer for the media of the IMS sessions.

– If both UE and network supports the ICS UE capabilities described in TS 23.292 [5], these capabilities are used for communication of required information if needed for enablement of PS-CS Access Transfer of IMS multimedia sessions. During Access Transfer, the UE may decide to retain the use of the Gm reference point for service control of the real time media flow(s) in the old PS access (if available) or may decide to transfer the Gm service control for the real time media flow(s) to a new PS access. Support and use of the I1 interface in both the UE and SCC AS are subject to the requirements specified in clauses 5.3.2 and 5.3.1, respectively, of TS 23.292 [5].

– When using the CS bearer for the media of the IMS session(s), multiple sessions can exist, but only one active session can be transferred over the CS bearer; one or more inactive sessions can be transferred.

– When using the CS bearer for the voice + video media of the IMS session(s) as a result of performing vSRVCC, only one session with voice+video media can be transferred to the CS access. All remaining bi-directional voice and voice + video sessions but the transferred one are released, if the UE and network do not support ICS capabilities.

– PS-CS Access Transfer with UE-based conferencing is not specified in this release.

– The SCC AS shall provide the Session State Information to the MSC Server if:

– the Access Transfer request is sent by or via the MSC Server;

– the MSC Server has indicated its capability to support mid-call services in the registration or indicates its capability in the Access Transfer request sent to the SCC AS;

– and ICS UE capabilities cannot be used upon transfer.

– If supported, the SCC AS and ATCF have additional functions in handling of PS-CS Access Transfer procedure with priority indication for Single Radio.

– If supported, the MSC Server may invoke the optional procedure(s) as shown in Annex B for additional SRVCC enhancements.

4.1.2 PS-PS Access Transfer

If a UE has an ongoing multimedia session over an access system and moves to a different access system but its IMS contact address and its serving P‑CSCF remains the same, then there is no need to activate any IMS Service Continuity mechanisms to transfer its multimedia session. The UE may update the session (e.g. remove media type(s) not supported by the target access system) based on the normal IMS procedures specified in TS 23.228 [4].

When the Evolved Packet System mobility with IP address preservation is used, the assumption above also applies.

NOTE: If an ICS UE has an ongoing session using CS bearer and Gm reference point over an IP‑CAN and performs an Access Transfer to a different IP‑CAN, the Service Control Signalling Path can be transferred from the old IP‑CAN to the new IP‑CAN while retaining the media flow(s) in the CS access network, so that service continuity of the session is maintained.

4.1.3 Inter-UE Transfer

The following assumptions apply for Inter-UE Transfer:

– The UEs involved in IUT Media Control Related Procedures can belong to different IMS subscriptions under the same operator.

– The Collaborative Session Control can be transferred between UEs registering Public User identities that share the same service profile (and thus belong to the same IMS subscription).

– There is only one Controller UE within a Collaborative Session.

– A Controllee UE is not aware of its role within a Collaborative session and it is not aware of the Controller UE. In that respect any UE can undertake the role of Controllee UE.

– The Collaborative Session is transparent to the remote end, to which it appears that the session is with the Controller UE.

– 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.

– The UEs involved in Inter-UE Transfer without establishing a Collaborative Session use Public User identities that share the same service profile.

4.2 Architectural Requirements

4.2.1 General Requirements

– It shall be possible to perform multimedia session transfer between access systems regardless of whether network layer mobility is deployed or not.

NOTE 1: The mechanism to avoid potential conflict between PS-PS Access Transfer and underlying network layer mobility (e.g. Evolved Packet System mobility, etc.) is not specified within this Release of the specification.

– The service disruption when session transfer occurs shall be minimized.

– There shall be no impact on the radio and transport layers and on the PS core network.

– UEs that do not support the functionality described in this specification shall not be impacted.

– In the context of this specification, an MME that supports 5G-SRVCC from NG-RAN to UTRAN is a MME_SRVCC, as defined in TS 23.216 [10].

– All media flow(s) within a multimedia session or a subset of media flow(s) within a multimedia session could be subject to session transfer procedures.

– It shall be possible to register a Public User Identity with multiple contact addresses (at the same or via separate UEs) via IMS registration procedures as defined in TS 23.228 [4], clause 5.2.1. The number of allowed simultaneous registrations is defined by home operator policy.

– It shall be possible to perform correlation of charging data from different access networks when service continuity between these networks is performed.

– The UE shall be IMS registered before invoking any Session Transfer procedures.

– The filter criteria shall contain a condition that a 3rd-party registration is performed via the ISC interface for the SCC AS.

– It shall be possible to provide SR-VCC support for IMS emergency call from PS to CS Access Transfer when using UTRAN and E-UTRAN radio access network (see TS 23.167 [23]).

NOTE 2: This includes an IMS emergency call which has been originated on NG-RAN (see TS 23.501 [37]), and subsequently transferred to a system where PS to CS Access Transfer for the call is possible.

– It shall be possible to provide DR-VCC support for IMS emergency call from PS to CS Access Transfer when using WLAN access to EPC (see TS 23.167 [23]).

NOTE 3: In this Release, DR-VCC support for IMS emergency call from PS to CS Access Transfer is only supported if the UE has valid subscription.

NOTE 4: The CS to PS Access transfer for IMS emergency call SRVCC or DRVCC is not supported in this Release of the specification.

4.2.2 Access Transfer Requirements

– It shall be possible to provide Access Transfer in the home network or in the visited network (if roaming) when the user is moving between 3GPP access systems.

– It shall be possible to provide Access Transfer when the user is moving between 3GPP and non-3GPP access systems.

– It shall be possible to provide Access Transfer when the user is moving between non-3GPP access systems.

– It shall be possible to provide Access Transfer between an Access Network that supports real-time media on the CS domain and non-real-time media on the PS domain, and an IP‑CAN that supports transport of all media types.

– If it is not possible or not desired (e.g. due to user preferences and/or operator policies) to transfer all the media flow(s), then a subset of the media flow(s) shall be transferred (if possible) and the remaining flow(s) will be released or kept in the transferred out access.

– It shall be possible for the UE to add or remove one or more media flow(s) to/from an ongoing multimedia session that it controls during Access Transfer.

– It shall be possible to provide Access Transfer when the P‑CSCF changes.

– It shall be possible for the UE to use IMS mechanisms to transfer its ongoing multimedia sessions to a target Access Network without requiring any new functionality on the remote party.

– It shall be possible for the UE to initiate an Access Transfer procedure based on operator policy provided by the network which may include restrictions of Access Transfer.

– It shall be possible for the SCC AS to update the operator policy in the UE.

4.2.3 IUT Requirements

– It shall be possible for the Controller UE to apply IUT when a remote end adds media to an existing session.

– IUT shall be able to coexist with Access Transfer as specified in this specification and TS 23.292 [5].

– If the Collaborative Session Control is lost for an active Collaborative Session, the SCC AS shall release all the Access Legs participating in that Collaborative Session.

– It shall be possible for the Controller UE to determine all other UEs that are currently available and authorised for IUT procedures.

– It shall be possible for the Controller UE to determine the media and service capabilities of each available UE.

– The network shall reject IUT between UEs that are not authorised.

– The Hosting SCC AS shall maintain the end-to-end session service state of a UE engaged in IUT.

– It shall be possible to execute IUT Media Control Related Procedures in any order, and any number of times, for a given session.

– The Controller UE shall maintain the Collaborative Session Control for the session until the Collaborative Session is released or until the Collaborative Session Control is transferred to another Controller capable UE.

– It shall be possible for a Controller UE to initiate transfer of Collaborative Session Control to another Controller capable UE that has registered a Public User identity that shares the service profile with the Public User identity used in the Collaborative Session.

– It shall be possible for a Controller capable UE to request and, when authorized, to pull Collaborative Session Control from a source UE.

– The media flow(s) on the target UE shall be established using IMS session setup procedures as specified in TS 23.228 [4].

– The Controller UE may transfer one or more media flow(s) to one or more target UEs (including itself).

– The selection of the media flows to be transferred may be based on the target UE(s) capabilities.

– The Controller UE shall have information about a Collaborative Session, which describes all media components currently existing in this session and the UEs associated with these media components.

– The Collaborative Session procedures for a Controllee UE without IUT capabilities shall not have any impact to the UE. Therefore any IMS UE shall be able to act a Controllee UE within a Collaborative Session.

– UEs using CS access interworked with IMS by an interworking node shall be provided with limited Controllee UE functionality based on the constraints of the interworking node.

– After the local end changes due to an IUT procedure without establishing a Collaborative Session, the SCC AS shall update the remote end that the session is continuing with a new local end.

– It shall be possible to apply IUT Media Control Related Procedures between UEs belonging to different IMS subscriptions.

– When UEs from different subscriptions are involved in a Collaborative Session, the SCC ASs shall assure that UEs do not create subsequent Collaborative Sessions for media belonging to Access Legs of the original Collaborative Session, and thus only a single Collaborative Session with a single hosting SCC AS shall be allowed.

– When an SCC AS creates an access leg towards a UE that is not part of the same subscription that is currently associated with the Collaborative Session, it shall include sufficient information indicating that there already exists a hosting SCC AS.

– It shall be possible for a UE to indicate that it is capable to become a Controller UE.

– It shall be possible for the Controller UE to apply IUT Media Control Related Procedures when setting up either an originating or terminating session.

– It shall be possible, based on the terminating user’s preferences, to route incoming IMS session requests to a UE that is capable of becoming a Controller UE.

– It shall be possible for a UE to request to replicate one or more media flow(s) from the remote end.

– It shall be possible for the network to replicate media in order to support the media replication scenarios described in this document.

– It shall be possible for a UE to determine the information of ongoing multimedia session(s) in other UEs before or during IUT Media Control Related Procedures.

– It shall be possible for the network to mask information on some or all of the sessions or media flows composing the session from session discovery based on user service configuration or operator policy.

– The selection of the media flows to be transferred may be based on the ongoing multimedia session(s) on the source UE(s) discovered by the target UE(s) in pull mode.

– It shall be possible for a UE to request and, when authorized, to pull one or more media flow(s) from a source UE.

– It shall be possible for the Controller UE to authorize requests for IUT Media Control Related Procedures.

– It shall be possible for the network to authorize requests for IUT Media Control Related Procedures on behalf of the Controller UE.

– The network shall resolve conflicting IUT Media Control Related Procedures within a Collaborative Session.

– When the Collaborative Session Control on the Controller UE is lost, the SCC AS may transfer the Collaborative Session Control to another Controller capable UE (with a Public User Identity belonging to the same service profile) involved in the Collaborative Session based on the user preferences associated with the Controller UE.

– It shall be possible for the SCC AS to initiate Inter-UE Transfer on behalf of the UE/user as a result of a UE requesting IUT, or due to other stimulus such as, but not restricted to, IMS signalling received by the SCC AS from other IMS entities, user preferences, or other service layer triggers.

– Replication / transfer of some or all media components to target IMS UE(s), belonging to the same or to different user(s) that are subscribed to the same operator, shall not be performed when the remote end (e.g. the source of the media) of the session restricts such operation.

4.3 Service Continuity

4.3.1 Session Transfer concepts

4.3.1.1 General

When an UE is active in an IMS session, the Session Transfer procedures provide service continuity between Access Networks and between UEs having IMS subscriptions under the same operator.

The initial and all subsequent Session Transfer procedures are initiated by the UE and are executed and controlled by the same SCC AS.

The SCC AS generates charging information for all Session Transfers for an IMS session for the purpose of billing and charging.

The UE sends information required by the SCC AS in order to execute Session Transfer procedures.

4.3.1.2 Access Transfer concepts

4.3.1.2.1 General Access Transfer concepts

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.

4.3.1.2.2 Access Transfer (PS – CS) concepts

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 [5].

PS-CS Access Transfer shall be provided according to the requirements specified in clause 22.3, Service Continuity, of TS 22.101 [9].

When using a UE that does not have, or that is unable to use, ICS UE capabilities as specified in TS 23.292 [5], 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.

NOTE: PS to CS transfer – Single Radio of a bi-directional session before the first SDP answer is not supported.

When using a UE that is able to use ICS capabilities as specified in TS 23.292 [5], 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 [5], 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 [5] and TS 23.216 [10], 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 [5].

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.

4.3.1.2.2A MSC Server assisted mid-call feature

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 clauses 6.3.2.1.1a, 6.3.2.1.2a, 6.3.2.1.4a, 6.3.2.1.6, 6.3.2.1.7, 6.3.2.1.7a, 6.3.2.1.7b and 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.

4.3.1.2.3 Co-existence of ICS UE and 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.

4.3.1.3 Inter‑UE Transfer concepts

4.3.1.3.1 General

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.

4.3.1.3.2 Controller UE and Controllee UE operations

4.3.1.3.2.1 Overview

The operations of Controller UE and Controllee UE are described respectively in clauses 5.3.2.2.2 and 5.3.2.2.3.

4.3.2 Void

4.3.3 Information used for IMS Service Continuity

The following information may be provided between SCC AS and the UE.

Depending on the IMS Service Continuity scenario, the Access Transfer request may contain the following:

– session transfer indicator;

– details about the access and the media flow(s) being transferred / kept / released;

– optionally, an IMS Communication Service Identifier defined in TS 23.228 [4];

– which session is required to be replaced or updated;

– whether to merge the session(s).

The above addressed information are carried in various SIP/SDP and CS call control messages (specified in the applicable information flows), which provides the necessary details to enable IMS Service Continuity. The SCC AS and the UE analyze the included information and determine if and how a Session Transfer operation needs to be performed.

The ATCF may include into the Registration request the following:

– allocated STN-SR pointing to the ATCF.

The above information is carried in SIP messages (specified in the information flows) providing the necessary details.

When an ATCF is used, t the SCC AS provides the following information to the ATCF:

– ATU-STI; and

– C-MSISDN.

The above information is carried in SIP messages (specified in the information flows) providing the necessary details.

The Access Transfer Update request from the ATCF to the SCC AS may contain the following:

– indication that Access Transfer has taken place for a particular session.

The above information is carried in SIP messages (specified in the information flows) providing the necessary details.

For support of CS to PS SRVCC, a dynamic STI-rSR is provided to the UE from the ATCF.

The Session State Information sent by the SCC AS may contain the following about one active and zero or one inactive bi-directional speech session(s) for enablement of PS-CS service continuity of IMS multimedia-sessions:

– calling party;

– called party;

– needed STI;

– further session information (e.g. active, inactive, conference call initiator, conference URI, identifier of all participants) as required.

The above information is carried in SIP messages (specified in the information flows) providing the necessary details to enable MSC Server assisted mid-call feature.