4 Overview of IP Multimedia (IM) Core Network (CN) subsystem Service Continuity

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

4.1 General

In general, IMS Service Continuity provides the capability of continuing ongoing communication sessions with multiple media across different access networks. The main need for such continuity arises because user equipments (UEs) with multimedia capabilities can move across a multiplicity of different access networks.

NOTE 1: The capability of continuing ongoing communication sessions as a collaboration between different user equipments (UEs) is described in 3GPP TS 24.337 [64].

NOTE 2: In this subclause, the term "PS-CS" is used as a general term to refer to bi-directional access transfer. When required to specify the direction for the access transfer, then the terms "PS to CS" and "CS to PS" are used.

The following procedures are provided within this document:

– procedures for registration in IM CN subsystem are specified in clause 6;

– procedures for call origination are specified in clause 7;

– procedures for call termination are specified in clause 8;

– procedures for PS-CS access transfer are specified in clause 9;

– procedures for PS-PS access transfer are specified in clause 10;

– procedures for PS-PS access transfer in conjunction with PS-CS access transfer are specified in clause 11;

– procedures for PS-CS access transfer for Single Radio are specified in clause 12;

– procedures for media adding/deleting for access transfer are specified in clause 13; and

– procedures for service continuity and MMTEL interactions are specified in clause 20.

In general, the SC UE supports the capabilities of this specification that it needs, see subclause 5.2. Clause G.2 provides a summary of how the capabilities described in this specification are communicated from the SC UE to the network.

Network equipment conforming with this specification is detailed in subclause 5.3 through subclause 5.7, with additional optional procedures specified in clause 7 onwards, but may be summarised as follows:

1) conforming networks support at least one of the following core functionalities:

a) procedures for PS to CS dual radio access transfer, for a session with an active speech media component;

b) procedures for PS-PS access transfer, for a session with an active speech media component;

c) procedures for PS to CS SRVCC for a session with an active speech media component; or

d) procedures for CS to PS dual radio access transfer, for a session with an active speech media component;

2) for each of the core functionality in 1) above, access transfer for a session with an inactive speech media component may also be supported;

3) for each of the core functionality in 1) above, access transfer for a session with conference control with active speech media component or inactive speech media component may also be supported;

4) for each of the core functionality in 1) above, access transfer in the alerting phase with an active speech media component may also be supported. The alerting phase is applicable only for sessions where a SIP 180 (Ringing) response has been sent or received;

5) if 4) is supported, then PS to CS SRVCC access transfer for originating calls in pre-alerting phase with an active speech media component may also be supported. This applies for an early dialog where a SIP 180 (Ringing) response has not been received;

6) for each of the core functionality in 1) above, access transfer for a session with active speech media component and active video media component may also be supported. If access transfer for a session with active speech media component and active video media component is supported, then:

a) access transfer in the alerting phase with an active speech media component and active video media component may also be supported. The alerting phase is applicable only for sessions where a SIP 180 (Ringing) response has been sent or received; and

b) if 6a) is supported, then PS to CS SRVCC for originating calls in pre-alerting phase with an active speech media component and an active video media component may also be supported. This applies for an early dialog where a SIP 180 (Ringing) response has not been received;

7) if 1) c) is supported, then CS to PS SRVCC access transfer for an active session with an active speech media component may also be supported. Within this capability, then:

a) if 2) is supported, then access transfer for a session with an inactive speech media component may also be supported;

b) if 3) is supported, then access transfer for a session with conference control with active speech media component or inactive speech media component may also be supported; and

c) if 4) is supported, then access transfer in the alerting phase with an active speech media component may also be supported; and

8) if 1) a) and 1) d) is supported, then dual radio access transfer for originating calls in pre-alerting phase with an active speech media component may also be supported. This applies for an early dialog where a SIP 180 (Ringing) response has not been received.

In addition to the above, the network can choose to support SRVCC with ATCF and ATGW functionality. For a roaming user, the ATCF allows service continuity to be executed in the visited network as opposed to the home network.

Clause G.3 provides a summary of how the SCC AS and ATCF communicate their support for the access transfer features described in this document, to the SC UE.

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of

– one full-duplex session with active speech or speech/video media component; and

– up to one full-duplex session with active speech or speech/video media component and up to one session with inactive speech or speech/video media component when the MSC Server assisted mid-call feature is supported.

4.2 Underlying network capabilities

4.2.1 General

SC assumes the use of a number of underlying network capabilities:

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 3GPP TS 24.229 [2]; and

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4].

4.2.2 PS-CS session continuity, Single Radio

In order to allow for PS-CS session continuity, Single Radio, SRVCC procedures assume that filter criteria causes all sessions subject to PS to CS SRVCC to be anchored in an SCC AS as described in 3GPP TS 23.216 [5].

Configuration of QoS assignment for PS to CS SRVCC as defined in 3GPP TS 23.203 [65] and 3GPP TS 23.107 [66] need to be aligned with the initial filter criteria and SCC AS determination that a session is subject to SR-VCC as defined in 3GPP TS 23.216 [5].

In order to allow for PS-CS session continuity, Single Radio, vSRVCC procedures assume that filter criteria causes all sessions subject to vSRVCC to be anchored in an SCC AS as described in 3GPP TS 23.216 [5].

Configuration of QoS assignment for vSRVCC as defined in 3GPP TS 23.203 [65] needs to be aligned with the initial filter criteria and SCC AS determination that a session is subject to vSRVCC as defined in 3GPP TS 23.216 [5].

When SRVCC enhanced with ATCF is used, the SRVCC and vSRVCC procedures assume that all sessions subject to SRVCC and vSRVCC are anchored in the same ATCF. When 5G SRVCC is used, the SRVCC procedures assume that all sessions subject to SRVCC are anchored in the same ATCF.

4.2.3 PS to CS and CS to PS session continuity, dual radio access transfer

In order to allow for dual radio access transfer procedures in clauses 9 and 10, the dual radio procedures assume that filter criteria causes all sessions subject to dual radio access transfer to be anchored in an SCC AS as described in 3GPP TS 23.237 [9].

4.3 URI and address assignments

In order to support SC to a subscriber, the following URI and address assignments are assumed:

a) in this version of the document, the SC UE for access transfer will be configured with a static STI, in accordance with subclause 5.11 in 3GPP TS 24.216 [5]; a static STN in accordance with subclause 5.12 in 3GPP TS 24.216 [5]. The static STI is used by the SC UE to perform CS to PS access transfer when no dynamically assigned STI is provided to the UE over the CS domain (e.g. when the SC UE does not support ICS capabilities as defined in 3GPP TS 24.292 [4]). The static STN is used by the SC UE to perform PS to CS access transfer when no service control signalling path as specified in 3GPP TS 24.292 [4] is available; a PS to PS STI URI in accordance with subclause 5.30 in 3GPP TS 24.216 [5].

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. Either:

– this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in international form) comprise part of the implicit registration set associated with that SC UE in the IM CN subsystem; or

– the SCC AS can be configured to provide a functional relationship between separate numbers providing each of these identities in the CS domain and the IM CN subsystem, respectively.

c) the SCC AS is configured to be reachable using:

– the STN-SR allocated to the SCC AS;

– the additional transferred session SCC AS URI allocated to the SCC AS;

– the additional transferred session SCC AS URI for PS to CS SRVCC allocated to the SCC AS;

– the additional transferred session SCC AS URI for CS to PS SRVCC allocated to the SCC AS;

– the additional transferred session SCC AS URI for PS to CS dual radio allocated to the SCC AS;

– the additional transferred session SCC AS URI for CS to PS dual radio allocated to the SCC AS;

– the ATU-STI for PS to CS SRVCC allocated to the SCC AS;

– the ATU-STI for CS to PS SRVCC allocated to the SCC AS;

– the PS to PS STI for PS to PS access transfer; and

– the dynamic STN allocated to the SCC AS.

d) the ATCF is configured to be reachable using:

– the STN-SR allocated to the ATCF;

– the ATCF URI for originating requests allocated to the ATCF;

– the ATCF URI for terminating requests allocated to the registration path;

– ATCF management URI allocated to the ATCF. The ATCF management URI is included in the g.3gpp.atcf-mgmt-uri feature-capability indicator that the ATCF includes in a Feature-Caps header field in the SIP REGISTER request; and

– ATCF URI for anchoring additionally transferred call in ATCF.

e) the MSC server enhanced for ICS and supporting CS to PS SRVCC is configured to be reachable (in addition to configuration in 3GPP TS 24.292 [4]) using:

– the MSC URI for redirected terminating sessions allocated to the registration path; and

– the MSC server management URI allocated to the MSC server.

4.4 Support of session continuity in enterprise scenarios

Session continuity can be applied where hosted enterprise services are supported as documented in ETSI TS 182 024 [76] the UE registers with the S-CSCF in the normal manner, and the procedures of this document can be used with an SCC AS in the home network.

Where the UE is supported by an application server in the enterprise, any enterprise UE requiring service continuity to be supported by the public network requires an SCC AS in the home network, and therefore registration with an S-CSCF in the home network.

4.5 Guidelines for use of media feature tags or feature capability indicators

NOTE 1: When the values appropriate for use with a media feature tag are of string type, then when included in Contact, Accept-Contact or Reject-Contact header fields, the value of the media feature tag is preceded by "<" and followed by ">" according to IETF RFC 3840 [53] and IETF RFC 3841 [78].

NOTE 2: When the values appropriate for use with feature capability indicators specified in annex C are string, then when the values are included in Feature-Caps header field, the value of the header field is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809 [60].