U.3 Application usage of SIP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

U.3.1 Procedures at the UE

U.3.1.0 Registration and authentication

The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in annex R or annex W. The reregistration is performed using the new IP-CAN.

NOTE 1: This document does not specify how the UE detects that the used IP-CAN has changed. The information that is forcing the reregistration is also used to generate the content for the P-Access-Network-Info header field.

NOTE 2: The UE will send the reregistration irrespective of whether it has a SIP dialog or not.

If the UE supports the 3GPP PS data off, then the UE shall in all REGISTER requests include the "+g.3gpp.ps-data-off" header field parameter defined in subclause 7.9.8 set to a value indicating the 3GPP PS data off status.

When the UE sends a REGISTER request, if the 3GPP PS data off status is "active", then the UE shall only include media feature tags associated with services that are 3GPP PS data off exempt services in the g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3840 [62], for the IMS communication services it intends to use.

If the UE is registered, and the 3GPP PS data off status is changed, then the UE shall perform a reregistration of the previously registered public user identity.

A UE supporting ANBR as specified in 3GPP TS 26.114 [9B] shall also support RAN-assisted codec adaptation as specified in 3GPP TS 38.300 [270] and 3GPP TS 38.321 [271].

If the UE supports ANBR, upon receiving a 200 (OK) response to the REGISTER request and if the 200 (OK) response contains a Feature-Caps header field with the g.3gpp.anbr feature-capability indicator the UE shall assume that the Network supports RAN-assisted codec adaptation as specified in 3GPP TS 38.300 [270] and 3GPP TS 38.321 [271]. The UE is allowed to include the SDP ‘anbr’ attribute during session establishment as specified in 3GPP TS 26.114 [9B].

U.3.1.0A IMS_Registration_handling policy

The IMS_Registration_handling policy indicates whether the UE deregisters from IMS after a configured amount of time after receiving an indication that the IMS Voice over PS Session is not supported.

The UE may support the IMS_Registration_handling policy.

If the UE supports the IMS_Registration_handling policy, the UE may support being configured with the IMS_Registration_handling policy using one or more of the following methods:

a) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C];

b) the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the IMS_Registration_Policy node of 3GPP TS 24.167 [8G].

If the UE is configured with both the IMS_Registration_Policy node of 3GPP TS 24.167 [8G] and the IMS_Registration_Policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the IMS_Registration_Policy node of the EF_{IMSConfigData} file shall take precedence.

NOTE 1: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see 3GPP TS 24.501 [258]), indicates voice is not supported, the UE shall:

A) if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to stay registered, the UE needs not to deregister and maintains the registration as required for IMS services; or

NOTE 2: The UE will periodically refresh the registration when needed.

B) if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to deregister and the Deregistration_Timer leaf used to configure the NoVoPS-dereg timer defined in table 7.8.1 contains a timer value for the time to wait before deregistrerting from IMS, start a timer with the value indicated in the policy and:

a) if the timer expires before the UE receives an indication from the lower layers that IMS voice is supported:

1) if there is no ongoing IMS session, the UE either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6; or

2) if there is ongoing IMS session, and

i) if the UE does not receive indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, the UE either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6 as soon as the ongoing IMS based service is terminated; or

ii) if the UE receives indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, cancel the timer; or

NOTE 3: How the UE selects reregistration or deregistration is implementation dependent (e.g., SMS service)

b) if the UE receives an indication from the lower layers that IMS voice is supported before the timer expires, cancel the timer.

If the IMS_Registration_handling policy is not configured, the UE behaviour is implementation specific.

U.3.1.1 P-Access-Network-Info header field

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

NOTE: If the P-Access-Network-Info header field includes radio cell identity, the P-Access-Network-Info header field populated by the UE that supports Multi-RAT Dual Connectivity with the 5GCN as described in 3GPP TS 37.340 [264] will contain the information about the radio cell identity of the Master RAN node that is serving the UE.

U.3.1.1A Cellular-Network-Info header field

Not applicable.

U.3.1.2 Availability for calls

This subclause documents the minimal requirements for being available for voice communication services when using 5GS.

A UE shall perform an initial registration as specified in subclause 5.1.1.2 using a QoS flow for SIP signalling (see annex U.2.2.1), if all the following conditions are met:

1) if the UE is operating in the "voice centric" way;

2) if the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using:

a) the 5GS IP-CAN via NR;

b) the 5GS IP-CAN via E-UTRA; or

NOTE 1: The use of 5GS IP-CAN via E-UTRA can also be the result of an inter-RAT fallback during setup of the IMS voice call. This can occur, for example, when a UE not supporting the media type in 5GS IP-CAN via NR initiates an IMS voice call in 5GS IP-CAN via NR.

c) the EPS IP-CAN;

NOTE 2: EPS can be used as IP-CAN as the result of an EPS fallback during setup of the IMS voice call. This can occur, for example, when a UE not supporting the media type in 5GS IP-CAN via NR initiates an IMS voice call in 5GS IP-CAN via NR, or when a UE not supporting the media type in 5GS IP-CAN via E-UTRA initiates an IMS voice call in 5GS IP-CAN via E-UTRA.

3) if:

a) the media type of item 2 is an "audio" media type;

b) the UE supports codecs suitable for (conversational) speech; and

c) the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1;

and one of the following is true:

a) 3GPP PS data off status is "inactive";

b) 3GPP PS data off status is "active", the UE is in the HPLMN or EHPLMN or a subscribed SNPN, and MMTEL voice is a 3GPP PS data off exempt service; or

c) 3GPP PS data off status is "active", the UE is in a VPLMN or a non-subscribed SNPN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off roaming exempt service in the VPLMN or MMTEL voice is a 3GPP data off non-subscribed exempt service in the non-subscribed SNPN;

4) if the UE determines that its contact has not been bound to a public user identity using the IP-CAN, such that the contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to the media of item 2 and item 3;

5) if the IMSVoPS indicator, provided by the lower layers indicates voice is supported;

6) if the procedures to perform the initial registration are enabled (see 3GPP TS 24.305 [8T]); and

7) if the PDU session used for IMS is:

a) available; or

b) not available, and the UE is allowed to send a PDU SESSION ESTABLISHMENT REQUEST message to establish a PDU session with 5GS QoS flow that is needed for performing the initial registration as described in U.2.2.1.

NOTE 3: Regardless of any of the above conditions, a UE might attempt to register with the IM CN subsystem at any time.

EXAMPLE: As an example of the note, a UE configured to preferably attempt to use the 5GS to access IM CN subsystem can perform an initial registration as specified in subclause 5.1.1.2, if the conditions in items 2, 3, 4, 5, 6 and 7 in this subclause, evaluate to true.

The UE indicates to the non-access stratum the status of being available for voice over PS when:

I) the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using:

a) the 5GS IP-CAN via NR;

b) the 5GS IP-CAN via E-UTRA; or

NOTE 4: The use of 5GS IP-CAN via E-UTRA can also be the result of an inter-RAT fallback during setup of the IMS voice call. This can occur, for example, when a UE not supporting the media type in 5GS IP-CAN via NR initiates an IMS voice call in 5GS IP-CAN via NR.

c) the EPS IP-CAN;

NOTE 5: EPS can be used as IP-CAN as the result of an EPS fallback during setup of the IMS voice call. This can occur, for example, when a UE not supporting the media type in 5GS IP-CAN via NR initiates an IMS voice call in 5GS IP-CAN via NR, or when a UE not supporting the media type in 5GS IP-CAN via E-UTRA initiates an IMS voice call in 5GS IP-CAN via E-UTRA.

II) if the media type of item I is an "audio" media type, the UE supports codecs suitable for (conversational) speech, the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1; and:

a) 3GPP PS data off status is "inactive";

b) 3GPP PS data off status is "active", the UE is in the HPLMN, the EHPLMN or a subscribed SNPN, and MMTEL voice is a 3GPP PS data off exempt service; or

c) 3GPP PS data off status is "active", the UE is in a VPLMN or a non-subscribed SNPN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off roaming exempt service in the VPLMN or MMTEL voice is a 3GPP PS data off non-subscribed exempt service in the non-subscribed SNPN; and

III) the UE determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media.

The UE indicates to the non-access stratum the status of being not available for voice over PS when:

I) in response to receiving the IMSVoPS indicator indicating voice is supported, the UE:

– initiated an initial registration as specified in subclause 5.1.1.2, received a final response to the REGISTER request sent, but the conditions for indicating the status of being available for voice over PS are not met; or

– did not initiate an initial registration as specified in subclause 5.1.1.2 and, these conditions for indicating the status of being available for voice over PS are not met; or

II) the conditions for indicating the status of being available for voice over PS are no longer met.

NOTE 6: The status of being not available for voice over PS is used for domain selection for UE originating sessions / calls specified in 3GPP TS 23.501 [257] subclause 5.16.3.5.

U.3.1.2A Availability for SMS

The UE determines that the UE is able to use SMS using IMS if the UE:

I) is capable of using the MIME type "application/vnd.3gpp.sms" (see 3GPP TS 24.341 [8L]), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;

II) supports the role of an SM-over-IP sender (see 3GPP TS 24.341 [8L]);

IIA) determines the PDU session used for IMS exists;

III) determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media; and

IV) the UE does not determine that SMS over IP is restricted in 3GPP TS 24.341 [8L] subclause 5.2.1.3; and

V) the 3GPP PS data off status is:

– "inactive";

– "active", the UE is in the HPLMN, the EHPLMN or a subscribed SNPN, and SMS over IMS is a 3GPP PS data off exempt service; or

– "active", the UE is in a VPLMN or a non-subscribed SNPN, the UE is configured with an indication that SMS over IMS is a 3GPP PS data off roaming exempt service in the VPLMN or SMS over IMS is a 3GPP PS data off non-subscribed exempt service in the non-subscribed SNPN.

When above criteria are not met, the UE determines that SMS using IMS is unavailable.

NOTE: The status that SMS using IMS is unavailable is used for domain selection for UE originating SMS specified in 3GPP TS 23.501 [257] subclause 5.16.3.8.

U.3.1.3 Authorization header field

Void.

U.3.1.4 SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE

Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated resource reservation for the UE, the UE:

1) if the INVITE request contains an SDP offer and the local resources required at the terminating UE for the received SDP offer are not available:

a) shall not alert the user; and

b) shall send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. If the INVITE request includes a Supported header field indicating support of reliable provisional responses, the UE shall send the 183 (Session Progress) response reliably. In the 183 (Session Progres) response, the UE shall include an SDP answer; and

2) if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field indicating support of reliable provisional responses:

a) shall generate an SDP offer;

b) if the local resources required at the terminating UE for the generated SDP offer are not available:

A) shall not alert the user; and

B) shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. In the 183 (Session Progres) response, the UE shall include the generated SDP offer.

Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the UE can send 180 (Ringing) response to the INVITE request and can alert the user.

U.3.1.5 3GPP PS data off

If the 3GPP PS data off status is "active" the UE shall only send initial requests that:

1) are associated with a 3GPP IMS service which enforces 3GPP PS data off;

NOTE 1: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

2) are associated with an emergency service; or

3) are associated with 3GPP PS data off exempt services configured in the UE using one or more of the following methods:

– the non_3GPP_ICSIs_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G] is not configured;

– the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the VPLMN;

– the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] is not configured;

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN;

– the /<X>/SNPN_Configuration/<X>/3GPP_PS_data_off/non_3GPP_ICSIs_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in the subscribed SNPN, or if the UE is in a non-subscribed SNPN and the non_3GPP_ICSIs_non-subscribed_exempt node specified in 3GPP TS 24.167 [8G] is not configured; or

– the non_3GPP_ICSIs_non-subscribed_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in a non-subscribed SNPN.

If the UE is configured with both the non_3GPP_ICSIs_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] shall take precedence.

If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of 3GPP TS 24.167 [8G] and the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], then the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C] shall take precedence.

If the 3GPP PS data off status changes from "inactive" to "active" the UE shall release all dialogs that

1) are not associated with a 3GPP IMS service which enforces 3GPP PS data off;

NOTE 2: These services are specified in 3GPP TS 22.011 [1C], and enforcement of 3GPP PS data off is described in the respective service specifications.

2) are not associated with an emergency service; and

3) are not associated with 3GPP data off exempt services configured in the UE using one or more of the following methods:

– the non_3GPP_ICSIs_roaming_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in a VPLMN;

– the non_3GPP_ICSIs_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN;

– the non_3GPP_ICSIs_roaming_exempt node in the EF_{3GPPPSDATAOFFservicelist} file described in 3GPP TS 31.102 [15C], if the UE is in the VPLMN.

– the non_3GPP_ICSIs_non-subscribed_exempt node specified in 3GPP TS 24.167 [8G], if the UE is in a non-subscribed SNPN.

U.3.1.6 RLOS

Not applicable.

U.3.1.7 SIP handling at the originating UE when redirecting the UE from NG-RAN to E-UTRAN fails

When a failure occurs in the process of redirecting the UE from NG-RAN to E-UTRAN and the UE is aware of the failure, the UE shall send out a CANCEL request to cancel the INVITE request that includes a Reason header field with a protocol value set to "RELEASE_CAUSE" and a "cause" header field parameter with the value of "7" as specified in subclause 7.2A.18.11.2.

U.3.1.8 Unified Access Control

The following information is provided to the non-access stratum:

– MO–IMS-registration-related-signalling-started; and

– MO-IMS-registration-related-signalling-ended;

Prior to sending a REGISTER request which is not for emergency registration, the UE sends the MO-IMS-registration-related-signalling-started to the non-access stratum and

a) if the barring result is "not-barred", continues with registration procedure as described in subclause 5.1.1; and

b) if the barring result is "barred", aborts the registration procedure;

When the UE needs to send SUBSCRIBE request for the reg event package, then the UE sends the MO-IMS-registration-related-signalling-started to the non-access stratum before sending SUBSCRIBE request and

a) if the barring result is "not-barred", continues with subscribe procedure as described in subclause 5.1.1.3; and

b) if the barring result is "barred", aborts the subscribe procedure;

When a procedure for MO IMS registration related signalling ends, i.e.

– a final response to the REGISTER request which is not for emergency registration is received;

– a final response to the SUBSCRIBE request for the reg event package is received;

– timer F expires at the UE; or

– a fatal transport error for sending the REGISTER request or the SUBSCRIBE request is reported by the transport layer, as desribed in IETF RFC 3261 [26];

the UE sends the MO-IMS-registration-related-signalling-ended to the non-access stratum.

U.3.1.9 Abnormal cases

Upon sending MO-IMS-registration-related-signalling-started indication to the non-access stratum as described in subclause U.3.1.8, if:

a) the UE receives, from the lower layers, a notification that the service request

1) was not accepted due to congestion; or

2) resulted in starting timer T3525 (see 3GPP TS 24.501 [258]); and

b) a procedure for MO IMS registration related signalling has not ended;

then:

a) the UE shall abort the procedure for MO-IMS-registration-related-signalling and send MO-IMS-registration-related-signalling-ended indication to the non-access stratum; and

b) if an alternative radio access network is available, the UE may attempt the procedure for MO-IMS-registration-related signalling on the alternative radio access network.

U.3.2 Procedures at the P-CSCF

U.3.2.0 Registration and authentication

Void.

U.3.2.1 Determining network to which the originating user is attached

If the P-CSCF is configured to handle emergency requests, in order to determine from which network the request was originated the P-CSCF shall check the MCC and MNC fields received:

– during the registration procedure from the Rx interface as defined in 3GPP TS 29.214 [13D] (e.g. used for deployments without IMS-level roaming interfaces where the P-CSCF is located in the home network); or

– from the P-Access-Network-Info header field.

NOTE: The above check can be against more than one MNC code stored in the P-CSCF.

U.3.2.2 Location information handling

Void.

U.3.2.3 Prohibited usage of PDU session for emergency services

If the P-CSCF detects that a UE uses a PDU session for emergency services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

NOTE: By assigning specific IP address ranges for a PDU session for emergency bearer services and configuring those ranges in P-CSCF, the P-CSCF can detect based on the registered Contact address if UE uses an emergency PDU session for initial registration.

U.3.2.4 Support for paging policy differentiation

The P-CSCF may support paging policy differentiation by marking packet(s) to be sent towards the UE related to that IMS capability. A specific DSCP (IPv4) value and/or a specific Traffic Class (IPv6) value are assigned by local configuration in the P-CSCF.

If local policy requires to provide such marking, the P-CSCF shall identify terminating requests which:

a) contain SDP with an "audio" media line and which are related to a IMS multimedia telephony service session specified in 3GPP TS 24.173 [8H]; or

b) do not contain an SDP offer but some indication, e.g. a feature capability indicator, indicates that an "audio" media line that would meet network policy for such differentiation, could form part of the subsequent SDP offer.

NOTE 1: Precise details of such indications, if any, are subject to operator policy. Alternatively the operator policy can be to not preferentially page requests without an SDP offer.

For such identified requests:

a) where an unreliable transport mechanism is used as the transport protocol for SIP, the P-CSCF shall mark packets containing an INVITE request; and

b) if a reliable transport mechanism is used as the transport protocol for SIP:

1) if a new reliable transport connection needs to be established, the P-CSCF shall turn on the marking of packets within the reliable transport connection in advance of sending an INVITE request; and

2) if there is an existing reliable transport connection, the P-CSCF may turn on the marking of packets within the reliable transport connection in advance of sending an INVITE request.

In both these cases for a reliable transport connection, the P-CSCF shall turn off the marking of packets within the reliable transport connection at an appropriate time.

U.3.2.5 Void

U.3.2.6 Resource sharing

This feature is not supported in this release.

U.3.2.7 Priority sharing

This feature is not supported in this release.

U.3.2.8 RLOS

Not applicable.

U.3.2.9 Support of ANBR and RAN-assisted codec adaptation

If the network supports ANBR as specified in 3GPP TS 26.114 [9B] and RAN-assisted codec adaptation as specified in 3GPP TS 38.300 [270] and 3GPP TS 38.321 [271], then the P-CSCF might be configured to indicate ANBR support.

If the P-CSCF is configured to indicate ANBR support, when the P-CSCF receives the 200 (OK) response to the REGISTER request the P-CSCF shall include the "g.3gpp.anbr" feature-capability indicator in the Feature-Caps header field of the 200 (OK) response to the REGISTER request.