Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  19.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…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   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|p. 1000

W.1  Scopep. 1000

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 subsystemp. 1000

W.2.1  Introductionp. 1000

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 UEp. 1000

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

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
The UE may support the policy on when a UE is allowed to transfer a PDU session providing access to IMS between 5GC via non-3GPP access and 5GS as specified in subclause U.2.1.1. If the UE is in a session and the policy indicates "a UE having an ongoing IMS session, is not allowed to transfer the PDU session providing access to IMS between 5GCN via non-3GPP access and 5GCN via NG-RAN" or if the UE is roaming when in a session and the policy indicates "a UE roaming in a VPLMN and having an ongoing IMS session, is not allowed to transfer the PDU session providing access to IMS between 5GCN via non-3GPP access and 5GCN via NG-RAN" the UE shall not handover the PDU session providing access to IMS from 5GC via non-3GPP access to 5GS.
If the UE is in a seesion in the EPS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDU session providing access to IMS, if any, between 5GCN via non-3GPP access and 5GCN via NG-RAN" or the UE is roaming in an EPS IP-CAN and the policy indicates "a UE roaming in a VPLMN and having an ongoing IMS session, is allowed to transfer the PDU session providing access to IMS between 5GCN via non-3GPP access and 5GCN via NG-RAN" the UE shall, if not prevented by other rules or policies, handover the PDU session providing access to IMS from 5GC via non-3GPP access to 5GS.
If the UE is in a 5GS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDU session providing access to IMS, if any, between 5GCN via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" or the UE is roaming in a 5GS IP-CAN and the policy indicates "a UE roaming in a VPLMN is not allowed to transfer a PDU session providing access to IMS, if any, between 5GCN via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" the UE shall not handover the PDU session providing access to IMS from 5GC via non-3GPP access to 5GS.
Up

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

The procedures specified in Annex U.2.2.1A apply.

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

The procedures specified in Annex U.2.2.1B apply.

W.2.2.1C  P-CSCF restoration procedurep. 1001

The procedures specified in Annex U.2.2.1C apply.

W.2.2.2  Session management proceduresp. 1001

The procedures specified in Annex U.2.2.2 apply.

W.2.2.3  Mobility management proceduresp. 1001

The procedures specified in Annex U.2.2.3 apply.

W.2.2.4  Cell selection and lack of coveragep. 1001

Not applicable.

W.2.2.5  5GS QoS flow for mediap. 1001

W.2.2.5.1  General requirementsp. 1001
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 UEp. 1001
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 networkp. 1002
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 mediap. 1002
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 responsesp. 1002
The procedures specified in Annex U.2.2.5.2 apply.
W.2.2.5.3  Unsuccessful situationsp. 1002
Not applicable.

W.2.2.6  Emergency servicep. 1002

W.2.2.6.1  Generalp. 1002
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 valuep. 1004
Annex U.2.2.6.1A applies.
W.2.2.6.1B  Type of emergency service derived from extended local emergency number listp. 1004
Annex U.2.2.6.1B applies.
W.2.2.6.2  eCall type of emergency servicep. 1004
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 callp. 1004
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 SDPp. 1004

W.3  Application usage of SIPp. 1005

W.3.1  Procedures at the UEp. 1005

W.3.1.0  Registration and authenticationp. 1005

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

W.3.1.0a  IMS_Registration_handling policyp. 1005

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 fieldp. 1006

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 fieldp. 1006

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 callsp. 1006

Not applicable.

W.3.1.2A  Availability for SMSp. 1006

Void.

W.3.1.3  Authorization header fieldp. 1006

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 UEp. 1006

Not applicable.

W.3.1.5  3GPP PS data offp. 1006

Not applicable.

W.3.1.6  Transport mechanismsp. 1007

Void.

W.3.1.7  RLOS |R16|p. 1007

Not applicable.

W.3.2  Procedures at the P-CSCFp. 1007

W.3.2.0  Registration and authenticationp. 1007

Void.

W.3.2.1  Determining network to which the originating user is attachedp. 1007

The procedures specified in Annex U.3.2.1 apply.

W.3.2.2  Location information handlingp. 1007

Void.

W.3.2.3  Prohibited usage of PDU session for emergency bearer servicesp. 1007

The procedures specified in Annex U.3.2.3 apply.

W.3.2.4  Support for paging policy differentiationp. 1007

Void.

W.3.2.5Void

W.3.2.6  Resource sharingp. 1007

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

W.3.2.7  Priority sharingp. 1007

The feature is not supported in this release of the specificaiton

W.3.2.8  RLOS |R16|p. 1007

Not applicable.

W.3.3  Procedures at the S-CSCFp. 1007

W.3.3.1  Notification of AS about registration statusp. 1007

Not applicable.

W.3.3.2  RLOS |R16|p. 1007

Not applicable.

W.4  3GPP specific encoding for SIP header field extensionsp. 1008

W.5  Use of circuit-switched domainp. 1008

Void.

X  Support of SBA in IMS |R17|p. 1009

X.1  Scope |R16|p. 1009

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 and Mr'/Cr 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 and Mr'/Cr reference points, the usage of the equivalent SBA services is a valid option.
Up

X.2  Reference points to support SBA in IMS |R16|p. 1009

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.
  • DC2: Reference point between an SBI capable IMS AS and MF.
Up

X.3  Services to support SBA in IMS |R16|p. 1009

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 document 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.
If an I-CSCF or an S-CSCF uses the Nnrf_NFDiscovery service, it will apply Nnrf_NFDiscovery service operations instead of Cx procedures mentioned throughout the present document and will interact with an SBI capable NRF.
If an IMS AS uses MF services, it will apply Nmf service operations (defined in TS 29.176).
  • Nmf_MediaResourceManagement (MRM): This service is provided by an MF. It enables an IMS AS to create, update and delete media resources related to IMS Data Channel.
Up

$  Change historyp. 1011


Up   Top