5 Functional entities

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

5.1 Introduction

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 3GPP TS 23.237 [9]).

5.2 User Equipment (UE)

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE:

– acting as an UA as defined in 3GPP TS 24.229 [2];

– according to subclause 6.2 for registration of the UE in the IM CN subsystem; and

– dependent on the desired functionality, one or more of the procedures according to subclause 6A.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, subclause 12.2, subclause 13.2 and subclause 20.1.

A UE supporting access transfer to the EPS IP-CAN shall originate the session or call in accordance with the requirements applicable to a UE in the SC role. Transfer of PDU sessions from 5GS to EPS is defined in 3GPP TS 23.502 [97].

5.3 Application Server (AS)

To be compliant with access transfer in this document, an AS shall implement the role of:

1) an AS performing 3rd party call control acting as an routeing B2BUA as defined in 3GPP TS 24.229 [2]; and

2) an SCC AS as follows: dependent on the desired functionality, one or more of the procedures according to subclause 6.3, subclause 6A.4, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3, subclause 13.3 and subclause 20.1.

If the SCC AS receives a SIP INVITE request:

– with either the Replaces header field (see IETF RFC 3891 [10]) or the Target Dialog header field (see IETF RFC 4538 [11]), indicating a dialog identifier of a session belonging to the subscribed user; and

– with the Request-URI not containing the additional transferred session SCC AS URI;

and the SCC AS does not support the procedures for performing PS to PS access transfer specified in subclause 10.3, then the SCC AS shall send a SIP 403 (Forbidden) response to the SIP INVITE request, with a Reason header field containing protocol "SIP" and reason-text set to "PS to PS access transfer not supported".

The SCC AS also handles SDP media description conflicts according to subclause 6A.5.

The SCC AS may also indicate the traffic leg according to subclause 6A.6.

If the SCC AS supports the procedures according to subclause 12.3, the SCC AS shall support procedures according to subclause 22.3.

5.4 MSC server

An MSC server can be compliant with PS to CS SRVCC session transfer procedures as described in this document.

In order to be compliant with PS to CS SRVCC session transfer procedures as described in this document:

– an MSC server using SIP interface to initiate the session transfer shall provide the UA role as defined for a MSC server enhanced for SRVCC using SIP interface in annex A of 3GPP TS 24.229 [2] and the role of an MSC server enhanced for PS to CS SRVCC using SIP interface as described in subclause 12.6.1.1; or

– an MSC server shall provide the role of an MSC server enhanced for ICS as specified in subclause 12.4.0.

If an MSC server is enhanced for ICS and is compliant with PS to CS SRVCC session transfer procedures as described in this document, the MSC server shall also provide the role of an MSC server enhanced for ICS as specified in subclause 22.2.

In order to be compliant with vSRVCC session transfer procedures as described in this document, the MSC server shall be:

– compliant with the PS to CS SRVCC session transfer procedure specified in subclause 12.6.1.1 and additionally provide the functionality to support vSRVCC, as described in subclause 12.6.1.2; or

– compliant with the PS to CS SRVCC session transfer procedure specified in subclauses 12.4.0 and additionally provide the functionality to support vSRVCC, as described in subclause 12.4.0B.

An MSC server can be compliant with the access transfer procedures for the MSC server assisted mid-call feature as described in this document.

In order to be compliant with the access transfer procedures for the MSC server assisted mid-call feature as described in this document, the MSC server shall:

– provide the role of an MSC server enhanced for ICS as described in subclause 6.4 and subclause 9.4 and additionally provide the functionality described in subclause 9.5;

– provide the role of an MSC server enhanced for ICS as described in subclause 12.4.0, and additionally provide the functionality described in subclause  12.4A; or

– provide the role of an MSC server enhanced for PS to CS SRVCC using a SIP interface as described in subclause 12.6.1.1, and additionally provide the functionality described in subclause 12.4A.

In order to enable the UE to remove/add participants from/to an IMS conference call after the access transfer, the MSC Server supporting the MSC server assisted mid-call feature shall provide the role of an MSC server enhanced for ICS.

An MSC server can be compliant with the procedures for the PS to CS SRVCC for calls in alerting phase as described in this document.

In order to be compliant with the procedures for the PS to CS SRVCC for calls in alerting phase as described in this document, the MSC server shall:

– provide the role of an MSC server enhanced for ICS as described in subclause 12.4.0 or subclause 12.4.0B, and additionally provide the functionality described in subclause 12.6.3; or

– provide the role of an MSC server enhanced for SRVCC using a SIP interface as described in subclause 12.6.1 and additionally provide the functionality described in subclause 12.6.3.

The MSC server also handles SDP media description conflicts according to subclause 6A.5.

If the MSC server supports the PS to CS SRVCC for calls in alerting phase, the MSC server may also support the PS to CS SRVCC for originating calls in pre-alerting phase. The procedures for the PS to CS SRVCC for originating calls in pre-alerting phase are described in the subclauses describing the PS to CS SRVCC for calls in alerting phase.

In order to be compliant with PS to CS dual radio access transfer procedures as described in this document an MSC server enhanced for DRVCC using SIP interface to initiate the access transfer shall provide the UA role as defined for an MSC server enhanced for DRVCC using SIP interface in annex A of 3GPP TS 24.229 [2] and the role of an MSC server enhanced for PS to CS dual radio access transfer using SIP interface as described in subclause 9.8.

If a MSC server supports the PS to CS dual radio access transfer for calls in alerting phase, the MSC server shall support UA role procedure defined in IETF RFC 3262 [86] and IETF RFC 3311 [87].

The MSC server may also indicate the traffic leg according to subclause 6A.6.

In all SIP INVITE requests sent by the MSC server, the MSC server shall insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [85] and a type 1 "orig-ioi" header field parameter. The MSC server shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The MSC server shall not include the type 1 "term-ioi" header field parameter.

When initiating a failure response to any received request, depending on operator policy, the MSC server may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "msc-server" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17 of 3GPP TS 24.229 [2].

5.5 EATF

To be compliant with access transfer in this document, the EATF shall act as B2BUA and:

– extract charging information as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.2;

– identify the served user as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.3A.2;

– map the message header fields from a SIP message received in one dialog to related SIP message sent in the correlated dialog managed by EATF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1;

– pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1;

– handle P-Charging-Vector header as specified for an routeing AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and

– implement the role of an EATF according to subclause 7.4 and subclause 12.5.

The EATF also handles SDP media description conflicts according to subclause 6A.5.

5.6 Access Transfer Control Function (ATCF)

To be compliant with access transfer in this document, the ATCF shall:

1) provide the proxy role as defined in 3GPP TS 24.229 [2], with the exceptions and additional capabilities as described for the ATCF in subclause 6.5, subclause 6A.3, subclause 7.5, subclause 8.4, and subclause 12.7.2.4;

2) provide the B2BUA functionality with the exceptions and additional capabilities as described for the ATCF in subclause 12.7.2. When providing the B2BUA functionality, the ATCF shall provide the UA role as defined in 3GPP TS 24.229 [2] and additionally shall:

a. internally map the message header fields from a SIP message received in one dialog to related SIP message sent in the correlated dialog managed by ATCF;

b. transparently pass supported and unsupported signalling elements (e.g. SIP headers, SIP messages bodies); and

c. transparently forward received Contact header field, P-Asserted-Identity header field and, if available, the Privacy header field.

The following procedures apply to all procedures at the ATCF:

1) if it has been decided to anchor the media in ATGW according to operator policy, and a SIP message including an SDP offer or answer is received:

NOTE: At this point, ATCF interacts with ATGW to provide information needed in the procedures below, and to request the ATGW to start forwarding the media(s) from the remote UE to the local UE. The details of interaction between ATCF and ATGW are out of scope of this document.

a. upon the received message with an SDP offer or answer included is sent by the served UE within the dialog, replace the SDP in the received SIP message with updated SDP provided by ATGW, which contains the ATGW IP addresses and ports; and

b. upon the received message with an SDP offer or answer included is sent by the remote UE within the dialog, replace the SDP in the received SIP message with updated SDP provided by ATGW, which contains the ATGW IP addresses and ports; and

2) the ATCF also handles SDP media description conflicts according to subclause 6A.5.

The ATCF may also indicate the traffic leg according to subclause 6A.6.

The ATCF shall log all SIP requests and responses that contain a "logme" header field parameter, as defined in IETF RFC 8497 [94], in the SIP Session-ID header field if required by local policy.

When initiating a failure response to any received request, depending on operator policy, the ATCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "atcf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17 of 3GPP TS 24.229 [2].

5.7 Access Transfer Gateway (ATGW)

The functionality of the ATGW is specified in 3GPP TS 23.237 [9].