Content for  TS 24.229  Word version:  18.4.0

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. 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, 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 TS 26.114 shall also support RAN-assisted codec adaptation as specified in TS 38.300 and TS 38.321. 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 TS 38.300 and TS 38.321. The UE is allowed to include the SDP 'anbr' attribute during session establishment as specified in TS 26.114.

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:

1. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102;
2. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.103; and
3. the IMS_Registration_Policy node of TS 24.167.

If the UE is configured with both the IMS_Registration_Policy node of TS 24.167 and the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the IMS_Registration_Policy node of the EFIMSConfigData file shall take precedence. If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see TS 24.501), indicates voice is not supported, the UE shall:

1. 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
2. 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:
   1. 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
         1. 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
         2. 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
   2. 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.

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

Not applicable.

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:
   1. the 5GS IP-CAN via NR;
   2. the 5GS IP-CAN via E-UTRA; or
   3. the EPS IP-CAN;
3. if:
   1. the media type of item 2 is an "audio" media type;
   2. the UE supports codecs suitable for (conversational) speech; and
   3. 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:
   1. 3GPP PS data off status is "inactive";
   2. 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
   3. 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 TS 24.305); and
7. if the PDU session used for IMS is:
   1. available; or
   2. 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.

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

1. 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:
   1. the 5GS IP-CAN via NR;b) the 5GS IP-CAN via E-UTRA; or
   2. the EPS IP-CAN;
2. 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:
   1. 3GPP PS data off status is "inactive";
   2. 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
   3. 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
3. 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:

1. 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
2. the conditions for indicating the status of being available for voice over PS are no longer met.

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

1. is capable of using the MIME type "application/vnd.3gpp.sms" (see TS 24.341), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;
2. supports the role of an SM-over-IP sender (see TS 24.341);
3. determines the PDU session used for IMS exists;
4. 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
5. the UE does not determine that SMS over IP is restricted in TS 24.341 subclause 5.2.1.3; and
6. 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.

Void.

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:
   1. shall not alert the user; and
   2. 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:
   1. shall generate an SDP offer;
   2. if the local resources required at the terminating UE for the generated SDP offer are not available:
      1. shall not alert the user; and
      2. 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.

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;
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 TS 24.167, 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 TS 24.167 is not configured;
   • the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167, if the UE is in the VPLMN;
   • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, 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 EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured;
   • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN;
   • the /<X>/SNPN_Configuration/<X>/3GPP_PS_data_off/non_3GPP_ICSIs_exempt node specified in TS 24.167, 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 TS 24.167 is not configured; or
   • the non_3GPP_ICSIs_non-subscribed_exempt node specified in TS 24.167, if the UE is in a non-subscribed SNPN.
   If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
   If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 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;
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_exempt node specified in TS 24.167, 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 TS 24.167 is not configured;
   • the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167, if the UE is in a VPLMN;
   • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN;
   • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, 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 EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
   • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN.
   • the /<X>/SNPN_Configuration/<X>/3GPP_PS_data_off/non_3GPP_ICSIs_exempt node specified in TS 24.167, 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 TS 24.167 is not configured;
   • the non_3GPP_ICSIs_non-subscribed_exempt node specified in TS 24.167, if the UE is in a non-subscribed SNPN.
   If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
   If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.

Not applicable.

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.

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

1. if the barring result is "not-barred", continues with registration procedure as described in subclause 5.1.1; and
2. if the barring result is "barred", aborts the registration procedure. In this case, upon receiving an indication from the lower layers that the barring is alleviated, the registration procedure may be initiated, if still needed.

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

1. if the barring result is "not-barred", continues with subscribe procedure as described in subclause 5.1.1.3; and
2. if the barring result is "barred", aborts the subscribe procedure. In this case, upon receiving an indication from the lower layers that the barring is alleviated, the subscribe procedure may be initiated, if still needed.

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 RFC 3261;

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

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

1. 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 TS 24.501); and
2. a procedure for MO IMS registration related signalling has not ended;

then:

1. 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
2. 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.

Void.

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 TS 29.214 (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.

Void.

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.

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:

1. contain SDP with an "audio" media line and which are related to a IMS multimedia telephony service session specified in TS 24.173; or
2. 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.

For such identified requests:

1. where an unreliable transport mechanism is used as the transport protocol for SIP, the P-CSCF shall mark packets containing an INVITE request; and
2. 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.

This feature is not supported in this release.

This feature is not supported in this release.

Not applicable.

If the network supports ANBR as specified in TS 26.114 and RAN-assisted codec adaptation as specified in TS 38.300 and TS 38.321, 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.

Not applicable.

Not applicable.