Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   None
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

W (Normative)  IP-Connectivity Access Network specific concepts when using the 5GCN via WLAN to access IM CN subsystem |R15|Word‑p. 967

W.1  Scope

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IM CN subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is the 5GCN via Wireless Local Access Network (WLAN).

W.2  IP-CAN aspects when connected to the IM CN subsystem

W.2.1  Introduction

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the 5GCN and the WLAN to provide packet-mode communication between the UE and the IM CN subsystem.
Requirements for the UE on the use of these packet-mode services are specified in this clause.

W.2.2  Procedures at the UE

W.2.2.1  Establishment of IP-CAN bearer and P-CSCF discovery

The UE handles an IP-CAN bearer for SIP signalling as follows:
  1. the UE shall obtain a local IP address;
  2. the UE shall establish an IKEv2 security association and an IPsec ESP security association as described in TS 24.502; and
  3. the IKEv2 security association and the IPsec ESP security association (tunnel) shall remain active throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration; and
In addition the procedures specified in Annex U.2.2.1 apply
Up

W.2.2.1A  Modification of an IP-CAN used for SIP signalling

The procedures specified in Annex U.2.2.1A apply.

W.2.2.1B  Re-establishment of the IP-CAN used for SIP signalling

The procedures specified in Annex U.2.2.1B apply.

W.2.2.1C  P-CSCF restoration procedureWord‑p. 968
The procedures specified in Annex U.2.2.1C apply.

W.2.2.2  Session management procedures

The procedures specified in Annex U.2.2.2 apply.

W.2.2.3  Mobility management procedures

The procedures specified in Annex U.2.2.3 apply.

W.2.2.4  Cell selection and lack of coverage

Not applicable.

W.2.2.5  5GS QoS flow for media

W.2.2.5.1  General requirements
If the resource allocation is initiated by the UE, the UE starts reserving resources whenever it has sufficient information about the media streams, and used codecs available as specified in TS 24.501 and TS 24.502.
Up
W.2.2.5.1A  Activation or modification of QoS flows for media by the UE
If the UE is configured not to initiate resource allocation for media according to TS 24.167, then the UE shall refrain from requesting additional 5GS QoS flow(s) for media until the UE considers that the network did not initiate resource allocation for the media.
W.2.2.5.1B  Activation or modification of QoS flows for media by the network
If the UE receives an activation request from the network for a 5GS QoS flow for media which is associated with the 5GS QoS flow used for signalling, the UE shall correlate the media 5GS QoS flow with a currently ongoing SIP session establishment or SIP session modification.
If the UE receives a modification request from the network for a 5GS QoS flow that is used for one or more media streams in an ongoing SIP session, the UE shall:
  1. modify the related PDU session context in accordance with the request received from the network.
Up
W.2.2.5.1C  Deactivation of a QoS flow for media
When a data stream for media related to a session is released, if the 5GS QoS flow transporting the data stream is no longer needed and allocation of the 5GS QoS flow was requested by the UE, then the UE releases the 5GS QoS flow.
W.2.2.5.2  Special requirements applying to forked responses
The procedures specified in Annex U.2.2.5.2 apply.
W.2.2.5.3  Unsuccessful situationsWord‑p. 969
Not applicable.

W.2.2.6  Emergency service

W.2.2.6.1  General
Emergency session is supported over the WLAN access if the UE has failed or has not been able to use 3GPP access to set up an emergency session as described in TS 23.167 annex L. IMS emergency session is also supported for UEs with unavailable IMSI (i.e. a UE without USIM) or unauthenticated IMSI.
Some jurisdictions allow emergency calls to be made when the UE does not contain an ISIM or USIM, or where the credentials are not accepted.
The UE determines that the 5GCN supports emergency services via WLAN when the Emergency service support for non-3GPP (EMCN3) access indicator in the REGISTRATION ACCEPT message indicates emergency services are supported over non-3GPP access as defined in subclause 9.11.3.5 of TS 24.501.
When the UE is registered over a WLAN access and detects an emergency call attempt, if the UE supports the emerg-non3gpp timer defined in table 7.8.1 and has determined that 5GCN supports emergency services via WLAN the UE shall start the emerg-non3gpp timer when starting a domain selection searching for a 3GPP access usable to establish an emergency call. The UE shall stop the timer when a 3GPP access supporting emergency call is found. When the emerg-non3gpp timer expires the UE shall consider that it has failed to use 3GPP access to setup the emergency call and shall attempt to setup the emergency call over the available WLAN access.
The UE may support being configured for the emerg-non3gpp timer using one or more of the following methods:
  1. the Timer_Emerg_non3gpp leaf of the EFIMSConfigData file described in TS 31.102;
  2. the Timer_Emerg_non3gpp leaf of the EFIMSConfigData file described in TS 31.103; and
  3. the Timer_Emerg_non3gpp leaf of TS 24.167.
When the IM CN subsystem is selected as the domain for the emergency call attempt, the UE determines whether it is currently attached to its home operator's network (e.g. HPLMN) or not (e.g. VPLMN) after it has determined that the 5GCN supports emergency services via WLAN.
To perform emergency registration, the UE shall request to establish an emergency PDU session as described in TS 24.501. The procedures for PDU session establishment and P-CSCF discovery, as described in subclause W.2.2.1 of this specification apply accordingly.
If the ME is equipped with a UICC, in order to find out whether the UE is attached to the home PLMN or to the visited PLMN, the UE shall compare the MCC and MNC values derived from its IMSI with the MCC and MNC of the PLMN the UE is attached to. If the MCC and MNC of the PLMN the UE is attached to do not match with the MCC and MNC derived from the IMSI, then for the purposes of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN. If the ME is not equipped with a UICC, the procedure to find d out whether the UE is attached to the home PLMN or to the visited PLMN for the purpose of emergency calls in the IM CN subsystem, is implementation specific.
If the UE detected an emergency number, the UE subsequently uses a different PLMN than the PLMN from which the UE received the last Extended Local Emergency Number List, the dialled number is not stored in the ME, in the USIM and in the Local Emergency Number List, and:
  • the REGISTRATION ACCEPT message received from the different PLMN contains the Extended Local Emergency Number List and the emergency number is present in the updated Extended Local Emergency Number List then the UE uses the updated Extended Local Emergency Number List when it performs the procedures in subclause W.2.2.6.1B; and
  • the REGISTRATION ACCEPT message received from the different PLMN contains no Extended Local Emergency Number List or the emergency number is no longer present in the updated Extended Local Emergency Number List then the UE shall attempt UE procedures for SIP that relate to emergency using emergency service URN "urn:service:sos".
If the dialled number is equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301), then the UE shall recognize such a number as for an emergency call and:
  • if the dialled number is equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform either procedures in the subclause W.2.2.6.1B or the procedures in subclause W.2.2.6.1A; and
  • if the dialled number in not equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform procedures in the subclause W.2.2.6.1B.
If the dialled number is not equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301) and:
  • if the dialled number is equal to an emergency number stored in the ME, in the USIM or in the Local Emergency Number List (as defined in TS 24.008), then the UE shall recognize such a number as for an emergency call and performs the procedures in subclause W.2.2.6.1A.
Once IPsec tunnel setup is completed, the UE shall follow the procedures described in subclause W.2.2.1 of this specification for establishment of IP-CAN bearer and P-CSCF discovery accordingly.
Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, if:
  • the 380 (Alternate Service) response contains a Contact header field;
  • the value of the Contact header field is a service URN; and
  • the service URN has a top-level service type of "sos";
then the UE determines that "emergency service information is included" as described TS 23.167.
Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.3.1, if the 380 (Alternate Service) response does not contain a Contact header field with service URN that has a top-level service type of "sos", then the UE determines that "no emergency service information is included" as described TS 23.167.
Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, the UE shall proceed as follows:
  1. if a 3GPP access network is available and the UE has not already attempted to use a 3GPP access network to set up an emergency session as described in TS 23.167 annex L, when the UE selects a domain in accordance with the conventions and rules specified in TS 22.101 and TS 23.167, the UE shall attempt to select a domain of the 3GPP access network, and:
    • if the CS domain is selected, the UE behaviour is defined in subclause 7.1.2 of TS 23.167 and in annex B; and
    • if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt;
    In addition, when the UE determines that "it has not been able to use 3GPP access to set up an emergency session" in accordance with subclause L.1 of TS 23.167, the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt; and
  2. if a 3GPP access network is not available, then the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt.
When the emergency registration expires, the UE should disconnect the emergency PDU session.
Up
W.2.2.6.1A  Type of emergency service derived from emergency service category valueWord‑p. 971
Annex U.2.2.6.1A applies.
W.2.2.6.1B  Type of emergency service derived from extended local emergency number list
Annex U.2.2.6.1B applies.
W.2.2.6.2  eCall type of emergency service
The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".
W.2.2.6.3  Current location discovery during an emergency call
The UE may support the current location discovery during an emergency call specified in subclause 5.1.6.8.2, subclause 5.1.6.8.3, subclause 5.1.6.8.4, and subclause 5.1.6.12.

W.2A  Usage of SDP

W.3  Application usage of SIP

W.3.1  Procedures at the UE

W.3.1.0  Registration and authentication

The procedures specified in Annex U.3.1.0 apply with the following clarification:
  • 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 U or annex L.

W.3.1.0a  IMS_Registration_handling policyWord‑p. 972
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.
Up

W.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.

W.3.1.1A  Cellular-Network-Info header fieldWord‑p. 973
The UE:
  1. using the 5GCN via Wireless Local Access Network (WLAN) as IP-CAN to access the IM CN subsystem; and
  2. supporting one or more cellular radio access technology (e.g. NR);
shall always include the Cellular-Network-Info header field specified in subclause 7.2.15, if the information is available, in every request or response in which the P-Access-Network-Info header field is present.

W.3.1.2  Availability for calls

Not applicable.

W.3.1.2A  Availability for SMS

Void.

W.3.1.3  Authorization header field

Void.

W.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

Not applicable.

W.3.1.5  3GPP PS data off

Not applicable.

W.3.1.6  Transport mechanisms

Void.

W.3.1.7  RLOS |R16|

Not applicable.

W.3.2  Procedures at the P-CSCF

W.3.2.0  Registration and authentication

Void.

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

The procedures specified in Annex U.3.2.1 apply.

W.3.2.2  Location information handling

Void.

W.3.2.3  Prohibited usage of PDU session for emergency bearer servicesWord‑p. 974
The procedures specified in Annex U.3.2.3 apply.

W.3.2.4  Support for paging policy differentiation

Void.

W.3.2.5Void

W.3.2.6  Resource sharing

The feature is not supported in this release of the specification.

W.3.2.7  Priority sharing

The feature is not supported in this release of the specificaiton

W.3.2.8  RLOS |R16|

Not applicable.

W.3.3  Procedures at the S-CSCF

W.4  3GPP specific encoding for SIP header field extensions

W.5  Use of circuit-switched domain

Void.

X  Support of SBA in IMS |R16|Word‑p. 975

X.1  Scope

This annex describes support for SBA for IMS nodes.
IMS nodes can use the SBA interfaces described in the present Annex as an alternative to the Diameter Rx and Cx and Sh reference points based on configuration. To support co-existence of IMS nodes supporting SBA services and IMS nodes not supporting SBA services SBI, enabled IMS nodes can support both SBI and non-SBI interfaces.
While the main body of the present document only describes usage of Diameter Rx and Cx and Sh reference points, the usage of the equivalent SBA services is a valid option.
Up

X.2  Reference points to support SBA in IMS

The following IMS related reference points are realized by service-based interfaces:
  • N5: Reference point between the PCF and an AF.
  • N70: Reference point between an SBI capable I/S-CSCF and an SBI capable HSS.
  • N71: Reference point between an SBI capable IMS AS and an SBI capable HSS.
Up

X.3  Services to support SBA in IMS

If a P-CSCF uses the Npcf_PolicyAuthorization service, it will apply Npcf_PolicyAuthorization service operations (defined in TS 29.514) instead of Rx procedures (defined in TS 29.214) and will interact with the PCF instead of the PCRF.
  • Npcf_PolicyAuthorization: This service is provided by the PCF. This service is to authorise an AF request and to create policies as requested by the authorized AF for the PDU Session to which the AF session is bound. This service also allows the NF service consumer to subscribe/unsubscribe the notification of events.
If an I-CSCF or an S-CSCF uses the Nhss_ims services, it will apply Nhss_ims service operations instead of Cx procedures mentioned throughout the present specification and will interact with an SBI capable HSS.
  • Nhss_imsUEContextManagement: This service is provided by an SBI capable HSS. It enables service operations related to the management of a UE context.
  • Nhss_imsSubscriberDataManagement: This service is provided by an SBI capable HSS. It enables service operations related to subscriber data management.
  • Nhss_imsUEAuthentication: This service is provided by an SBI capable HSS. It enables a service operation related to the authentication between the end user and the home IMS network.
Up

$  Change historyWord‑p. 977

Up   Top