20 Service continuity and MMTEL interactions
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
20.1 Roles for access transfer and supplementary services interaction
20.1.1 Introduction
This subclause describes the SCC AS and SC UE procedures for interaction of access transfer when execution of supplementary service as described in 3GPP TS 22.173 [24].
20.1.2 Originating Identification Presentation (OIP)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIP besides the procedures described in 3GPP TS 24.607 [25].
20.1.3 Originating Identification Restriction (OIR)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIR besides the procedures described in 3GPP TS 24.607 [25].
20.1.4 Terminating Identification Presentation (TIP)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the procedures described in 3GPP TS 24.608 [26].
20.1.5 Terminating Identification Restriction (TIR)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIR besides the procedures described in 3GPP TS 24.608 [26].
20.1.6 Communication Diversion (CDIV)
Upon receiving an incoming session split across multiple access legs, if the SC UE desires to invoke the CDIV, it may choose any of the PS access legs to invoke the call deflection supplementary service following the procedures described in 3GPP TS 24.604 [27] or the CS access leg to invoke the call deflection supplementary service following the procedures described in 3GPP TS 24.072 [42].
NOTE: Communication Forwarding unconditional, Communication forwarding on no reply, Communication Forwarding on Busy, Communication Forwarding Not Logged-in and Communication Diversion Notification supplementary services are invoked by the CDIV AS as described in 3GPP TS 24.604 [27] independent on access type.
When the SCC AS which is dividing an IMS session into multiple access legs, receives a CDIV request from the SC UE on any access leg, the SCC AS shall terminate any other access legs and invoke the CDIV for that access leg according to the procedures described in 3GPP TS 24.604 [27].
20.1.7 Communication Hold (HOLD)
When the SC UE which is dividing an IMS session through multiple access legs, desires to invoke HOLD on one or more media components, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for PS access legs, 3GPP TS 24.083 [43] for a CS access leg not controlled by the I1 interface or 3GPP TS 24.294 [44] for a CS access leg controlled by the I1 interface which contains the affected media components.
When the SCC AS which dividing an IMS session into multiple access legs, receives a HOLD request from the SC UE or remote end on any access leg, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for that access leg.
20.1.8 Communication Barring (CB)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CB besides the procedures described in 3GPP TS 24.611 [29].
20.1.9 Message Waiting Indication (MWI)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and MWI besides the procedures described in 3GPP TS 24.606 [30].
20.1.10 Conference (CONF)
When the SC UE has multiple access legs and if it wants to send any CONF related requests such as SIP SUBSCRIBE request or SIP REFER request, the SC UE may send the request on the PS access leg as describes in 3GPP TS 24.605 [31] or use the procedures described in 3GPP TS 24.294 [44] for a CS access leg controlled by the I1 interface. For a CS access leg without I1 interface control the procedures in 3GPP TS 24.084 [47] shall be used to create and add participants to a conference.
When the SC UE has multiple access legs and if it receives a request on one of the access legs for CONF service to replace an existing session, the SC UE shall:
– if each access les is PS access leg, follow procedures specified in 3GPP TS 24.605 [31] to establish a new session to the conference focus;
– if the CS access leg is not controlled by the I1 interface follow the procedures in 3GPP TS 24.008 [8] for releasing and establishing a new call towards the conference focus; and
– if the CS access leg is controlled by the I1 interface follow the procedures in 3GPP TS 24.294 [44] for establish a new session towards the conference focus.
When the SC UE has multiple access legs and if it receives a request on one the access legs for CONF service to replace an existing session outside the dialog, the SC UE shall follow procedures specified in 3GPP TS 24.605 [31] to establish a new session to the conference focus.
When the SC UE has multiple access legs and if the remote UE sends a request for the CONF service to replace an existing session within the same dialog, the SCC AS shall deliver the request for CONF service on the Gm controlled any of access legs or over the I1 interface if I1 interface control is used or to the CS leg if only a CS leg exists, to the SC UE.
Upon receipt of a CC BuildMPTY request from the SC UE and if the MSC server:
1) is enhanced for ICS and supports CS to PS SRVCC; and
2) the latest SRVCC information received for the registration path of the SC UE contains the ATCF management URI and the C-MSISDN;
then when sending the SIP INVITE request due to receipt of a CC BuildMPTY request from the SC UE as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4], then the MSC server shall additionally populate the SIP INVITE request with:
1) topmost Route header field with the ATCF management URI and lr URI parameter;
2) the Accept header field containing application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the value "2";
3) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
4) application/vnd.3gpp.srvcc-ext+xml MIME body with the <srvcc-ext> root element containing the <Setup-info> element containing the CS to PS SRVCC information bound to the registration path (see subclause 6A.3.1) and indicating the "initiator" role of the MSC server in the session set up; and
5) the g.3gpp.ti media feature tag with value as described in subclause C.12 indicating value of an invited participant in the Contact header field.
If the MSC server:
– is enhanced for ICS and supports CS to PS SRVCC; and
– the latest SRVCC information received for the registration path of the SC UE contains the ATCF management URI and the C-MSISDN;
then upon receipt of a DISCONNECT message from a SC UE with an established conference, with a transaction identifier corresponding to a specific remote party, if:
– not all conference participants are removed when the timer expires as specified in 3GPP TS 29.292 [18]; and
– the g.3gpp.ti media feature tag last provided in the Contact header field towards SCC AS had the value of the transaction identifier corresponding to a specific remote party;
the MSC server shall send UPDATE request within dialog of the established conference. The MSC server shall populate the SIP UPDATE request with the g.3gpp.ti media feature tag with value as described in subclause C.12 indicating value of an another participant of the established conference in the Contact header field.
If the ATCF supports CS to PS SRVCC then upon receipt of a UPDATE request received in dialog established as described in subclause 8.4.2.3 or a described in subclause 12.7.2, if:
– the Contact received from SCC AS indicated isfocus media feature tag; and
– if the UPDATE request contains a Contact header field with the g.3gpp.ti media feature tag;
the ATCF shall store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP UPDATE request.
If the SCC AS supports CS to PS SRVCC then upon receipt of a UPDATE request received in dialog established as described in subclause 7.3.2 and if:
– the Contact sent towards ATCF indicated isfocus media feature tag; and
– the UPDATE request contains a Contact header field with the g.3gpp.ti media feature tag;
the SCC AS shall store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP UPDATE request.
20.1.11 Explicit Communication Transfer (ECT)
When the SC UE has multiple access legs and if it acts as the transferor UE, the SC UE may send the request for ECT service on any of the PS legs as specified in 3GPP TS 24.629 [32], or on the CS access leg not controlled by the I1 interface follow the procedures in 3GPP TS 24.091 [46] and on a CS access leg controlled by the I1 interface follow the procedures in 3GPP TS 24.294 [44].
When the SC UE has multiple access legs and if it acts as the transferee UE, the SCC AS may deliver the request for ECT service on any of the access legs.
NOTE: Delivering of the request towards the CS access leg may be controlled by operator policy.
When the SC UE has multiple access legs and if it receives an ECT request on one of the access legs, the SC UE shall follow the procedures specified in 3GPP TS 24.629 [32] to establish a new session to the Transfer Target.
20.1.12 Advice of Charge (AOC)
When the AOC service as specified in 3GPP TS 24.647 [33] is active and if the SC UE has multiple access legs, the SCC AS may deliver charging information during the communication to the SC UE over any of the access legs which accept application/vnd.etsi.aoc+xml MIME type.
20.1.13 Closed User Groups (CUG)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CUG besides the procedures described in 3GPP TS 24.654 [34].
20.1.14 Three-Party (3PTY)
The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with session transfer is the same as that specified in subclause 20.1.10 for CONF service.
20.1.15 Flexible Alerting (FA)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and FA besides the procedures described in 3GPP TS 24.239 [35].
20.1.16 Communication Waiting (CW)
Upon receiving an incoming session split across multiple access legs if the SC UE desires to invoke the CW, it may choose any of the access legs to invoke the CW service following to the procedures defined in 3GPP TS 24.615 [36].
When the SCC AS which is dividing an IMS session into multiple access legs, receives a CW request from the SC UE on any access leg, the SCC AS shall invoke the CW service following the procedures defined in 3GPP TS 24.615 [36].
20.1.17 Completion of Communications to Busy Subscriber (CCBS)/Completion of Communications by No Reply (CCNR)
There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CCBS/CCNR besides the procedures described in 3GPP TS 24.642 [37].
20.1.18 Customized Alerting Tones (CAT)
There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 3GPP TS 24.182 [38].
When the terminating network is providing CAT, the PS to CS SRVCC for calls in alerting phase is only supported if a SIP 180 (Ringing) response is sent. This is not required as part of the CAT service.
20.1.19 Malicious Communication IDentification (MCID)
When invoking the MCID service in temporary subscription mode and there are multiple active access legs for the session, the SC UE may send the SIP re-INVITE request for invoking MCID service as defined in 3GPP TS 24.616 [39] on any of the access legs.
20.1.20 Reverse Charging
The interaction of the Reverse Charging service according to 3GPP TS 24.647 [33] with access transfer is not specified in this version of the specification.
20.1.21 Personal Network Management (PNM)
The interaction of the PNM service according to 3GPP TS 24.259 [40] with access transfer is not specified in this version of the specification.
20.1.22 Customized Ringing Signal (CRS)
The interaction of the CRS service according to 3GPP TS 24.183 [41] with access transfer is not specified in this version of the specification.