Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4.2.3   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.2.15…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8…   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.15.11…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.32.6…   5.33…   5.34…   5.35…   5.38…   5.43…   6…   6.3…   6.3.8…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   H…   J   K…   M…   N…   O…   P…

 

5.35  Support for Integrated access and backhaul (IAB) |R16|p. 486

5.35.1  IAB architecture and functional entitiesp. 486

Integrated access and backhaul (IAB) enables wireless in-band and out-of-band relaying of NR Uu access traffic via NR Uu backhaul links. In this Release of the specification, NR satellite access is not applicable. The serving PLMN may provide the mobility restriction for NR satellite access as specified in clause 5.3.4.1
The Uu backhaul links can exist between the IAB-node and:
  • a gNB referred to as IAB-donor; or
  • another IAB-node.
The part of the IAB node that supports the Uu interface towards the IAB-donor or another parent IAB-node (and thus manages the backhaul connectivity with either PLMN or SNPN it is registered with) is referred to as an IAB-UE.
In this Release of the specification, the IAB-UE function does not apply to the NR RedCap UE.
At high level, IAB has the following characteristics:
  • IAB uses the CU/DU architecture defined in TS 38.401, and the IAB operation via F1 (between IAB-donor and IAB-node) is invisible to the 5GC;
  • IAB performs relaying at layer-2, and therefore does not require a local UPF;
  • IAB supports multi-hop backhauling;
  • IAB supports dynamic topology update, i.e. the IAB-node can change the parent node, e.g. another IAB-node, or the IAB-donor, during operation, for example in response to backhaul link failure or blockage.
Figure 5.35.1-1 shows the IAB reference architecture with two backhaul hops, when connected to 5GC.
Reproduction of 3GPP TS 23.501, Fig. 5.35.1-1: IAB architecture for 5GS
Up
The gNB-DU in the IAB-node is responsible for providing NR Uu access to UEs and child IAB-nodes. The corresponding gNB-CU function resides on the IAB-donor gNB, which controls IAB-node gNB-DU via the F1 interface. IAB-node appears as a normal gNB to UEs and other IAB-nodes and allows them to connect to the 5GC.
The IAB-UE function behaves as a UE, and reuses UE procedures to connect to:
  • the gNB-DU on a parent IAB-node or IAB-donor for access and backhauling;
  • the gNB-CU on the IAB-donor via RRC for control of the access and backhaul link;
  • 5GC, e.g. AMF, via NAS;
  • OAM system via a PDU session or PDN connection (based on implementation).
The IAB-UE can connect to 5GC over NR (SA mode) or connect to EPC (EN-DC mode). The UE served by the IAB-node can operate in the same or different modes than the IAB-node as defined in TS 38.401. The operation mode with both UE and IAB-node connected to EPC is covered in TS 23.401. Operation modes with UE and IAB-node connected to different core networks are described in clause 5.35.6.
Up

5.35.2  5G System enhancements to support IABp. 487

In IAB operation, the IAB-UE interacts with the 5GC using procedures defined for UE. The IAB-node gNB-DU only interacts with the IAB-donor-CU and follows the CU/DU design defined in TS 38.401.
For the IAB-UE operation, the existing UE authentication methods as defined in TS 33.501 applies. Both USIM based methods and EAP based methods are allowed, and NAI based SUPIs can be used.
The following aspects are enhanced to support the IAB operation in the Registration procedure as defined in clause 4.2.2.2 of TS 23.502:
  • The IAB-node provides an IAB-indication to the IAB-donor-CU when the RRC connection is established as defined in TS 38.331. When the IAB-indication is received, the IAB-donor-CU selects an AMF that supports IAB and includes the IAB-indication in the N2 INITIAL UE MESSAGE as defined in TS 38.413 so that the AMF can perform IAB authorization;
  • the UE Subscription data as defined in clause 5.2.3 of TS 23.502 is enhanced to include the authorization information for the IAB operation;
  • Authorization procedure during the UE Registration procedure is enhanced to perform verification of IAB subscription information;
  • If the IAB operation is not authorized and IAB-UE is not allowed to be registered, the AMF rejects the IAB-UE's registration or de-register the IAB-UE. The AMF initiates UE Context setup/modification procedure by providing IAB authorized indication with the value set to "not authorized" to the NG-RAN, if the IAB-UE is still allowed to be registered;
  • If the IAB operation is authorized, UE Context setup/modification procedure is enhanced to provide IAB authorized indication with the value set to "authorized" to NG-RAN.
After registered to the 5G system, the IAB-node remains in CM-CONNECTED state if the IAB operation is authorized. In the case of radio link failure, the IAB-UE uses existing UE procedure to restore the connection with the network. The IAB-UE uses Deregistration Procedure as defined in clause 4.2.2.3 of TS 23.502 to disconnect from the network. In the case of controlled IAB-node release as specified in clause 8.9.10 of TS 38.401 (including the case when authorization state of the IAB-node is changed from authorized to non-authorized), after UE Context Modification message to NG-RAN with authorization indication as not authorized and after a certain period (e.g. based on the expiration of a timer configured on the AMF), the AMF may trigger the IAB-UE Deregistration.
Up

5.35.3  Data handling and QoS support with IABp. 488

Control plane and user plane protocol stacks for IAB operation are defined in TS 38.300.
QoS management for IAB can remain transparent to the 5GC. If NG-RAN cannot meet a QoS requirement for a QoS Flow to IAB-related resource constraints, the NG-RAN can reject the request using procedures defined in TS 23.502.
The IAB-UE function can establish a PDU session or PDN connection, e.g. for OAM purpose (protocol stack not shown here). In that case, the IAB-UE obtains an IP address/prefix from the core network using normal UE procedures. The IAB-UE's IP address is different from that of the IAB-node's gNB DU IP address.
Up

5.35.4  Mobility support with IABp. 488

For UEs, all existing NR intra-RAT mobility and dual-connectivity procedures are supported when the UE is served by an IAB-node except for the cases of NR satellite access. For a UE served by an IAB-node when the serving IAB-node changes its IAB-donor-CU due to mobility, the mobility support is specified in clause 5.35A.1 and clause 5.35A.3.
Up

5.35.5  Charging support with IABp. 488

IAB-donor has all the information regarding the UE and the IAB-node and corresponding mapping of the bearers. The PDU sessions for the UE and IAB-node are separate from IAB-node onwards to the core network. Therefore, the existing charging mechanism as defined in clause 5.12 can be used to support IAB.

5.35.6  IAB operation involving EPCp. 488

When the IAB-donor gNB has connection to both EPC and 5GC, based on PLMN configuration, there are two possible operation modes:
  • the IAB-node connects to a 5GC via the IAB-donor gNB, while the UEs served by the IAB-node connect to EPC with Dual Connectivity as defined in TS 37.340. In this operation mode, the IAB-donor gNB has connection to an eNB, and the 5GC is restricted for IAB-node access only; and
  • the IAB-node connects to an EPC via the IAB-donor gNB with Dual Connectivity as defined in TS 37.340, while the UEs served by the IAB-node connect to the 5GC. In this operation mode, the EPC is restricted for IAB-node access only.
To support the above operation modes, the IAB-UE shall be configured to select only a specific PLMN (as defined in TS 23.122) and whether it needs to connect to 5GC or EPC.
Up

5.35A  Support for Mobile Base Station Relay (MBSR) |R18|p. 489

5.35A.1  Generalp. 489

The MBSR uses the IAB architecture as defined in clause 5.35, and operates as an IAB node (with an IAB-UE and gNB-DU) with mobility when integrated with the serving PLMN. The architecture described in clause 5.35 applies unless specific handling is specified in clause 5.35A. Additionally, the following limitations apply to the MBSR:
  • the MBSR has a single hop to the IAB-donor node;
  • NR Uu is used for the radio link between a MBSR and served UEs, and between MBSR and IAB-donor node.
Regulatory requirements (e.g. emergency services, priority services) are supported when UEs access 5GS via a MBSR. LCS framework as defined in TS 23.273 is used for providing the location service to the served UEs, with additional enhancements described in clause 5.35A.5.
Roaming of the MBSR is supported, i.e. a MBSR can integrated with a VPLMN's IAB-donor node. The corresponding enhancements to support MBSR roaming are described in clause 5.35A.4.
CAG mechanism as defined in clause 5.30 can be used for the control of UE's access to the MBSR. Optional enhancements to the CAG mechanism for MBSR use are described in clause 5.35A.6.
For a MBSR node to operate as a MBSR, it provides a mobile IAB-indication to the IAB-donor-CU when the RRC connection is established as defined in TS 38.331. When the mobile IAB-indication is received, the IAB-donor-CU selects an AMF that supports mobile IAB-node and includes the mobile IAB-indication in the N2 INITIAL UE MESSAGE as defined in TS 38.413 so that the AMF can perform MBSR authorization as described in clause 5.35A.4. If the MBSR node is not authorized, e.g. due to the MBSR authorization indication from AMF, it also provides the mobile IAB-indication when establishing new RRC connection so that the AMF supporting mobile IAB-node will be selected by the IAB-donor-CU, to ensure that the operation related to MBSR authorization status change for a registered MBSR node can be performed as described in clause 5.35A.4. If the MBSR receives MBSR authorized indication from AMF, it provides the information about the authorization result to its IAB-DU component based on non-standardized interface as described in clause 5.35A.4.
As defined in TS 38.331, when a MBSR includes the mobile IAB-indication when establishing the RRC connection, it shall not include the IAB-indication as described in clause 5.35.2.
After the IAB-UE performs registration procedure in 5GS, further mobility procedure can be performed to change the IAB-donor-DU, the IAB-donor-CU as specified in TS 38.401. The mobility support of UEs served by the MBSR is specified in clause 5.35A.3.
Up

5.35A.2  Configuration of the MBSRp. 489

In order for an MBSR to operate as a mobile IAB node, it receives configuration from the OAM system of the serving PLMN as specified in TS 38.401. The MBSR IAB-UE establishes a secure and trusted connection to the OAM server only if it is authorized to operate as MBSR in the serving PLMN as defined in TS 38.401.
In addition, the MBSR(IAB-UE) is assumed to be configured with preferred PLMN lists and forbidden PLMNs by the HPLMN to perform PLMN selection as specified in TS 23.122.
When a PDU session is used for the MBSR to access the OAM server, the MBSR establishes a dedicated PDU session for the OAM traffic. The serving PLMN provides an Allowed NSSAI and establishes the PDU session for the OAM server access, considering the S-NSSAI and DNN requested by MBSR and/or the default values in subscription data. The MBSR can be (pre-)configured with UE policy or provisioned using existing UE Policy mechanism as defined in TS 23.503 including the OAM access PDU session parameters for the authorized PLMNs.
Up

5.35A.3  Mobility support of UEs served by MBSRp. 490

5.35A.3.1  UE mobility between a fixed cell and MBSR cellp. 490

For UEs in RRC_IDLE and RRC_INACTIVE state when a MBSR goes out-of-service, procedure for cell (re-)selection as specified in TS 38.304 for RRC_IDLE and RRC_INACTIVE is used between MBSR cell and other cells.
If the MBSR goes out-of-service (due to e.g. MBSR moves to an area where the MBSR is not allowed to provide the relay service), the NG-RAN triggers the handover procedures to the neighbouring cells for UEs in RRC_CONNECTED state served by the MBSR. Any change of authorization state of the MBSR is also handled according to clause 5.35A.4.
The IAB-donor-CU triggers handover procedure when it is possible for the UEs accessing emergency service and being served by the MBSR, if MBSR is about to become unavailable to provide the services.
Up

5.35A.3.2  UE mobility between MBSR cellsp. 490

Similar to the behaviours described in clause 5.35A.3.1, UEs and NG-RAN use existing procedures as specified in clause 8.23 of TS 38.401, TS 23.502, or TS 38.304 to handle the mobility between MBSR cells.
Up

5.35A.3.3  UE mobility when moving together with a MBSR cellp. 490

For a UE served by a MBSR cell, it may observe change of TAC and/or cell IDs, even if it is still connected to the same MBSR. This can trigger mobility registrations, as defined in TS 23.502, if the new TAC is not in the TAI list in the RA.

5.35A.3.4  MBSR mobilityp. 490

The mobility of MBSR between different IAB-donor gNBs is described in clause 8.23 of TS 38.401.
If a MBSR operates without PDU sessions,
  • For N2 Handover, the NG-RAN triggers the N2 handover procedure for a dummy PDU session and includes the related dummy PDU session information in the Handover Required message, as specified in TS 38.413 towards the AMF of the MBSR (IAB-UE). The AMF checks the UE context it stores for the MBSR (IAB-UE) and since it includes no PDU sessions, the AMF shall not forward the PDU Session information it receives in the Handover Required message to any SMF. The AMF shall then perform the handover procedures as specified in clause 4.9.1.3 of TS 23.502 without involving any SMF and it includes in the Handover Request message towards the target NG-RAN the PDU session information received in the Handover Required message with an indication to cause the target NG-RAN to ignore the received PDU session information (No PDU Session Indication IE defined in TS 38.413). If the AMF is reallocated during the handover, the target AMF checks whether the UE context for the MBSR (IAB-UE) it receives from the source AMF includes any PDU sessions related information and if none is detected, it continues the handover without involving any SMF and it includes in the Handover Request message towards the target NG-RAN with an indication to cause the target NG-RAN to ignore the received PDU session information (No PDU Session Indication IE defined in TS 38.413).
  • For Xn Handover: the NG-RAN triggers the Xn handover procedure for a dummy PDU session and includes the related dummy PDU session information in the Path Switch Request message, as specified in TS 38.413. The AMF checks the UE context it stores for the MBSR (IAB-UE) and since it includes no PDU sessions, the AMF shall then perform the handover procedures as specified in clause 4.9.1.2 of TS 23.502 without involving any SMF and it includes in the Path Switch Acknowledge towards the target NG-RAN dummy PDU session information. The NG-RAN ignores the received PDU session information from the AMF as it has no PDU sessions in the RAN UE context.
Up

5.35A.4  MBSR authorizationp. 491

For a MBSR, the subscription information stored in the HPLMN indicates whether it is authorized to operate as MBSR, and the corresponding location and time information as specified in TS 23.502.
When the MBSR (IAB-UE) performs initial registration with the serving PLMN, it indicates the request to operate as a MBSR as described in clause 5.35A.1. The AMF authorizes the MBSR based on the subscription information, and provides MBSR authorized indication to the MBSR node over NAS and NG-RAN over NGAP as described in the registration procedure in TS 23.502. The MBSR establishes the connection to OAM system using the configuration information for MBSR operation upon the reception of MBSR authorization indication (authorized). The MBSR provides the information about the authorization result (authorized) to its IAB-DU component. When the AMF formulates the registration area for an authorized MBSR, the TAs included in the registration area are authorized for MBSR operation homogenously, taking any MBSR Operation allowed information in subscription data and operator local policy into account.
When MBSR roaming is supported, a roaming agreement between VPLMN and HPLMN regarding MBSR operation is in place. The AMF can make use of the subscription data for authorization of the MBSR in the V-PLMN.
MBSR (IAB-DU) can use IAB-node integration procedure or inter-IAB-donor gNB mobility procedure to integrate into the serving PLMN to provide service.
If the MBSR operation is not authorized (e.g. due to location or time limitation), the AMF of the MBSR can indicate to the MBSR IAB-UE that it is not allowed to act as an MBSR, i.e. the MBSR authorization indication (not authorized), as part of registration procedure. The AMF may provide the indication in a Registration Accept (if the PLMN allows the MBSR IAB-UE to be registered in the PLMN). In this case, the AMF includes the MBSR authorization indication (not authorized) to donor-gNB. The MBSR provides the information about the authorization result (not authorized) to its IAB-DU component. The AMF may reject the Registration (if the PLMN does not allow the MBSR IAB-UE to be registered in the PLMN).
When the MBSR authorization state changes for a registered MBSR node (either authorized, or not authorized), the AMF updates the MBSR and the NG-RAN accordingly. Based on the operator configuration, the AMF may use either Deregistration (with re-registration required indication) or the UE Configuration Update procedure to inform the MBSR regarding the updated authorization status:
  • When Deregistration (with re-registration required indication) procedure is used, AMF provides the new authorization indication to MBSR (IAB-UE) as described above, when the MBSR performs initial Registration procedure after the deregistration.
  • When UE Configuration Update procedure is used, the AMF provides the new authorization indication and additional information to the MBSR in the UE Configuration Update Command. The MBSR provides the information about the new authorization status to its IAB-DU component.
The AMF informs the NG-RAN of the new authorization status using UE Context Modification, Initial Context Setup procedure or the DOWNLINK NAS TRANSPORT message, with the following principles:
  • If the authorization state changes from authorized to not authorized and AMF uses the UE Configuration Updated procedure to update the MBSR, the AMF updates the NG-RAN with the new authorization indication (not authorized) by including this information in the DOWNLINK NAS TRANSPORT message. The NG-RAN completes handover of the UEs served by the MBSR before releasing the F1 connection to the MBSR IAB-DU.
  • If the authorization state changes from authorized to not authorized and the AMF uses the Deregistration procedure to update the MBSR, the AMF sends the UE Context Modification message to NG-RAN with the authorization indication as not authorized. Then, if the AMF receives a NGAP UE CONTEXT RELEASE REQUEST message from the NG-RAN with a cause code indicating the NG-RAN node has completed the operation for a non-authorized MBSR, including e.g. the handover of the UEs the MBSR was serving as defined in TS 38.413, or after a certain period (e.g. based on the expiration of a timer configured on the AMF) the AMF executes the deregistration procedure with MBSR and releases the NAS signalling connection.
If the Network-initiated Deregistration procedure is triggered for MBSR IAB-UE that is registered with authorization to act as MBSR, the AMF sends the UE Context Modification message to NG-RAN and updates the NG-RAN with the authorization indication as not authorized. Then, if the AMF receives a NGAP UE CONTEXT RELEASE REQUEST message from the NG-RAN with a cause code indicating that the NG-RAN node has completed the operation for a non-authorized MBSR, including e.g. the handover of the UEs the MBSR was serving as defined in TS 38.413, or after a certain period (e.g. based on the expiration of a timer configured on the AMF) the AMF executes the deregistration procedure with MBSR and releases the NAS signalling connection.
If a PDU session is used to provide OAM access for MBSR when it is not authorized but remains registered, the AMF may notify the SMF serving the PDU session for O&M access to trigger the release of the PDU Session.
Up

5.35A.5  Location Service Support of UEs served by MBSRp. 492

When a UE accesses 5GS via a MBSR, it can use the location service as defined in TS 23.273. However, in order to provide accurate estimation of the UE location, LMF needs to take the location of the MBSR into account. Enhancements to the LCS framework for MBSR support is described in clause 5.9 of TS 23.273.

5.35A.6  Providing cell ID/TAC of MBSR for servicesp. 492

The TAC and cell ID broadcasted by the MBSR cell(s) are configured and reconfigured e.g. upon mobility as specified in TS 38.401.
After the MBSR is authorized as defined in clause 5.35A.4, when a UE is served by a cell of this MBSR, the IAB-donor-CU may provide 'Additional ULI' in addition to User Location Information, in N2 messages. The 'Additional ULI' is the ULI of the IAB-UE. The AMF may consider the 'Additional ULI' when it determines UE location and manages the UE location related functions (e.g. Mobility Restrictions).
When the AMF provides user location information to other NFs (e.g. LMF as specified in clause 5.9 of TS 23.273) for a UE connected via MBSR, the AMF may also send the Additional ULI received via N2 messages.
Up

5.35A.7  Control of UE access to MBSRp. 492

CAG Identifier is used to control the access of UE via MBSR (i.e. mobile IAB-node) and existing CAG mechanism defined in clause 5.30.3 can be used for managing UE's access to MBSR, with the following additional considerations:
  • When the MBSR is allowed to operate as an IAB node for a PLMN, the MBSR is configured, either during the communication with the serving PLMN OAM or (pre-)configuration mechanism, with a CAG identifier which is unique within the scope of this PLMN. If the MBSR is (pre-)configured with the PLMN list in which the MBSR is allowed to operate as MBSR, the corresponding CAG Identifier per PLMN is also configured in the MBSR.
  • NG-RAN and 5GC support the UE access control based on the CAG identifier associated with the MBSR cell and the allowed CAG identifiers for the UE that supports CAG functionality.
  • For the UE that does not support CAG functionality, NG-RAN and 5GC are allowed to use not only CAG mechanism but also the other existing mechanism e.g. forbidden Tracking Area, to manage its access to MBSR.
  • Time duration restriction may be provided together with the CAG Identifier(s) for the MBSR(s) that the UE can access. The enhanced Allowed CAG list will be provided to UE and AMF for enforcement, to make sure that UE not accessing the MBSR cell outside of the time duration. For example, if the time when a certain CAG is allowed for a UE is up, the CAG for the UE is revoked from the network.
Up

5.36  RIM Information Transfer |R16|p. 493

The purpose of RIM Information Transfer is to enable the transfer of RIM information between two RAN nodes via 5GC. The RIM Information Transfer is specified in TS 38.413.
When the source AMF receives RIM information from source NG-RAN towards target NG-RAN, the source AMF forwards the RIM information to the target AMF, as described in TS 38.413 and TS 29.518. The AMF does not interpret the transferred RIM information.
Up

5.37  Support for high data rate low latency services, eXtended Reality (XR) and interactive media services |R17|p. 493

5.37.1  General |R18|p. 493

This clause provides an overview of 5GS functionalities for support of XR services (AR/VR applications) and interactive media services that require high data rate and low latency communication, e.g. cloud gaming and tactile/multi-modal communication services according to service requirements documented in TS 22.261. The standardized 5QI characteristics for such interactive services are provided in Table 5.7.4-1 and TSCAI is used to describe the related traffic characteristics as defined in clause 5.27.2. Further enhancements for these interactive media services are as follows:
  • The 5GS may support QoS policy control for multi-modal traffic, see clause 5.37.2.
  • The 5GS may support network information exposure which can be based on ECN markings for L4S, see clause 5.37.3 or 5GS exposure API, see clause 5.37.4.
  • The 5GS may support PDU Set based QoS handling including PDU Set identification and marking, see clause 5.37.5.
  • The 5GS may ensure that the UL and DL packets together meet the requested round trip delay and also update the delay for UL and DL considering QoS monitoring results, see clause 5.37.6.
  • The 5GS may perform per-flow Packet Delay Variation (PDV) monitoring and policy control according to AF provided requirements, see clause 5.37.7.
  • The 5GC may provide traffic assistance information to the NG-RAN to enable Connected mode DRX power saving, see clause 5.37.8.
Up

5.37.2  Policy control enhancements to support multi-modal services |R18|p. 493

A multi-modal service is a communication service that consists of several data flows that relate to each other and that are subject to application coordination. The data flows can transfer different types of data (for example audio, video, positioning, haptic data) and may come from different sources(e.g. a single UE, a single device or multiple devices connected to the single UE, or multiple UEs).
For the single UE case, it is expected that those data flows are closely related and require strong application coordination for the proper execution of the multi-modal application and therefore, all those data flows are transmitted in a single PDU session.
The Nnef_AFsessionWithQoS service allows the AF to provide, at the same time, for each data flow that belongs to the multi-modal service, a Multi-modal Service ID, the service requirements and the QoS monitoring requirements:
  • The Multi-modal Service ID is an explicit indication that data flows are related to a multi-modal service. The PCF may use this information to derive the correct PCC rules and to apply appropriate QoS policies for the data flows that are part of a specific multi-modal application.
  • The AF may provide QoS monitoring requirements for data flows associated to a multi-modal service to the PCF . The PCF generates the authorized QoS Monitoring policy for each data flow.
In addition to the features that are provided for the case that the data flows are associated with a single UE, the following features are provided for the case where the data flows are associated with more than one UE:
  • The same DNN/S-NSSAI combination for the multi-modal service should be selected by each of the involved UEs. The URSP Rule evaluation framework is used to ensure that the same DNN/S-NSSAI is selected.
  • The AF should use the same Multi-modal Service ID in the interactions with the PCF(s) for all the involved UEs that relate to a multi-modal service. The PCF may take this information into account (e.g. to apply a specific QoS policy) when processing each AF request independently. The data flows contribute to the service experience, but are still valid stand-alone, as they are transmitted over separate PDU Sessions to/from the involved UEs.
  • If multiple PCFs are involved, the PCFs take policy decisions according to the input provided by the AF. There is no support for policy coordination among the multiple PCFs in this Release of the specification. Policy decisions are taken by each PCF separately on a per PDU Session basis.
Up

5.37.3  Support of ECN marking for L4S to expose the congestion information |R18|p. 494

5.37.3.1  Generalp. 494

L4S (Low Latency, Low Loss and Scalable Throughput) is described in RFC 9330, RFC 9331 and RFC 9332. It exposes congestion information by marking ECN bits in the IP header of the user IP packets between the UE and the application server to trigger application layer rate adaptation.
In 5G System, ECN marking for L4S may be supported. ECN marking for L4S is enabled on a per QoS Flow basis in the uplink and/or downlink direction and may be used for GBR and non-GBR QoS Flows. ECN marking for the L4S in the IP header is supported in either the NG-RAN (see clause 5.37.3.2 and TS 38.300), or in the PSA UPF (see clause 5.37.3.3).
In the case of ECN marking for L4S by PSA UPF, the NG-RAN is instructed to perform congestion information monitoring and report to the PSA UPF the congestion information (i.e. a percentage of packets that UPF uses for ECN marking for L4S) of the QoS Flow on UL and/or DL directions via GTP-U header extension to PSA UPF and accordingly, the PSA UPF may mark the UL and/or DL direction packets of the QoS Flow.
When serving PSA UPF or NG-RAN is changed e.g. due to inter-NG-RAN handover or PSA UPF relocation, target NG-RAN and target PSA UPF, if supported, should continue to perform ECN marking for L4S for the QoS Flow. However, if not available (i.e. ECN marking for L4S is not supported in both, target NG-RAN and target PSA UPF), AF should be notified that ECN marking for L4S can no longer be performed if ECN marking for L4S had been enabled for the QoS Flow based on AF request. When ECN marking for L4S is supported again either in target NG-RAN or in target PSA UPF, AF should be notified that ECN marking for L4S can be performed again if ECN marking for L4S had been enabled for the QoS Flow based on AF request.
Up

5.37.3.2  Support of ECN marking for L4S in NG-RANp. 495

ECN marking for L4S may be supported in NG-RAN as specified in TS 38.300.
To enable ECN marking for L4S in NG-RAN, dedicated QoS Flow(s) are used for carrying L4S enabled IP traffic. The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to NG-RAN for a corresponding QoS Flow(s) in UL and/or DL directions. In the absence of such PCC rule, the use of ECN marking for L4S in NG-RAN on a QoS Flow is controlled by a coordinated configuration in NG-RAN and 5GC.
The criteria based on which NG-RAN decides to mark ECN bits for L4S is NG-RAN implementation specific.
In the case of inter NG-RAN UE mobility, if the ECN marking for L4S has been enabled on source NG-RAN, but the target NG-RAN does not support ECN marking for L4S, then the SMF may, if supported, enable ECN marking for L4S in PSA UPF as defined in clause 5.37.3.3.
Up

5.37.3.3  Support of ECN marking for L4S in PSA UPFp. 495

To enable ECN marking for L4S by a PSA UPF, a QoS Flow level ECN marking for L4S indicator may be sent by SMF to PSA UPF over N4. SMF also indicates to NG-RAN to report the congestion information (i.e. a percentage of packets that UPF uses for ECN marking for L4S) of the QoS Flow on UL and/or DL directions via GTP-U header extension to PSA UPF and accordingly, the PSA UPF may mark the UL and/or DL direction packets of the QoS Flow. If there is no UL packet when report for DL and/or UL needs to be provided, NG-RAN may generate an UL Dummy GTP-U Packet for such a reporting.
The SMF may be instructed, based on either dynamic or predefined PCC rule, to provide an indication for ECN marking for L4S to PSA UPF for a corresponding QoS Flow(s) in UL and/or DL directions.
Upon successful activation of congestion information reporting for UL and/or DL directions, PSA UPF uses information sent by NG-RAN in GTP-U header extension (see TS 38.415 and TS 38.300) to perform ECN bits marking for L4S for the corresponding direction.
The criteria based on which NG-RAN decides to provide the congestion information is up to NG-RAN implementation.
In the case of PSA UPF relocation, if the ECN marking for L4S has been enabled on source PSA UPF, SMF should select a target PSA UPF supporting ECN marking for L4S. If the target PSA UPF does not support ECN marking for L4S, then SMF may, if supported, switch to ECN marking for L4S in target NG-RAN by following clause 5.37.3.2. In such case, the target NG-RAN stops sending congestion information to the target PSA UPF.
In the case of inter NG-RAN UE mobility, if the congestion information reporting has been enabled on source NG-RAN while the target NG-RAN does not support congestion information reporting, then the SMF shall inform PSA UPF to stop ECN marking for L4S. If ECN marking for L4S is supported by the target NG-RAN, the SMF may instruct the target NG-RAN to perform ECN marking for L4S in NG-RAN by following clause 5.37.3.2. For a given QoS Flow, if the target NG-RAN supports congestion information reporting, the target NG-RAN shall report congestion information to UPF once it is available.
Up

5.37.4  Network Exposure of 5GS information |R18|p. 495

5GS and XR/media services cooperate to provide a better user experience using External Network Exposure.
Based on the AF request, the 5GS can expose the following information based on the QoS Monitoring as defined in clause 5.33.3 and/or clause 5.45:
  • The UL and/or DL congestion information monitoring (see clause 5.45.3).
    Based on the PCC rule from PCF, the SMF requests the NG-RAN to report congestion information (i.e. a percentage of congestion level for exposure) via GTP-U header to PSA UPF. This NG-RAN reported congestion information is sent to the PSA UPF in a common information element to support congestion information exposure and to support ECN marking for L4S in PSA UPF as described in clause 5.37.3.3. In the case of congestion information exposure, the PSA UPF interprets the RAN reported information as the percentage of congestion level for exposure and exposes the corresponding UL and/or DL congestion information via Nupf_EventExposure service or via SMF/PCF/NEF as described in clause 5.8.2.18. It can be applied to a Non-GBR or GBR QoS Flow. In the case of ECN marking for L4S in PSA UPF, the PSA UPF interprets the RAN reported information as percentage of packets that UPF uses for ECN marking for L4S as described in clause 5.37.3.3.
  • The UL and/or DL Data rate information (see clause 5.45.4).
    Based on the PCC rule from PCF, the SMF requests the PSA UPF to measure and report the information. They may be exposed to the AF directly by PSA UPF via Nupf_EventExposure service or via SMF/PCF/NEF as described in clause 5.8.2.18.
  • The round trip delay for two service data flows considering the UL direction of a service data flow and the DL direction of another service data flow in the same PDU Session.
    It is determined based on the QoS Monitoring for packet delay of individual QoS Flows as described in clause 5.33.3. The PCF derives the separate QoS monitoring policies for each direction packet delay (see clause 5.33.3) based on AF request and local policy. The PCF provides the two QoS Monitoring policies in the PCC rules for the service data flows. The PSA UPF reports the delay information per QoS Flow to the SMF. The SMF reports to PCF. The PCF derives round trip delay information based on the two direction's packet delay result for the service data flows and exposes the information to the AF directly or via NEF.
  • The round trip delay for one service data flow.
    If the service data flow is mapped to two QoS Flows (i.e. the UL traffic and DL traffic of the service data flow are separated into two QoS flows respectively) in the same PDU Session, similarly to the round trip delay for two service data flows over two QoS flows, the PCF triggers QoS Monitoring for each direction packet delay of individual QoS flows respectively and derives round trip delay based on the two direction QoS flows' packet delay monitored result.
The AF may provide the Alternative QoS parameter set requirements and Averaging Window to the NEF/PCF for the GBR QoS Flow as specified in clause 4.15.6.6 of TS 23.502.
Up

5.37.5  PDU Set based Handling |R18|p. 496

5.37.5.1  Generalp. 496

A PDU Set is comprised of one or more PDUs carrying an application layer payload such as a video frame or video slice. The PDU Set based QoS handling by the NG-RAN is determined by PDU Set QoS Parameters in the QoS profile of the QoS Flow (specified in clause 5.7.7) and PDU Set Information provided by the PSA UPF via N3/N9 interface as described in clause 5.37.5.2. The PDU Set based Handling can be applied for GBR and non-GBR QoS Flows. The AF should provide PDU Set related assistance information for dynamic PCC control. One or more of the following PDU Set related assistance information may be provided to the NEF/PCF using the AF session with required QoS procedures in clauses 4.15.6.6 and 4.15.6.6a of TS 23.502.
  • PDU Set QoS Parameters as described in clause 5.7.7.
  • Protocol Description: Indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information, e.g. the following:
    • RTP [185] or SRTP [186];
    • RTP or SRTP with RTP Header Extensions, including:
      • RTP Header Extensions for PDU Set Marking as defined in TS 26.522;
      • Other RTP Header Extensions as defined RFC 8285;
    • RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g. H.264 [187] or H.265 [188]);
    • RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in TS 26.522, and together with RTP Payload Format (e.g. H.264 [187] or H.265 [188]);
    • RTP or SRTP with other RTP Header Extensions following RFC 8285, and together with RTP Payload Format (e.g. H.264 [187] or H.265 [188]).
    When RTP Header Extensions for PDU Set Marking (as defined in TS 26.522 or other RTP header extensions as defined in RFC 8285 is included, the differentiation between different RTP Header Extension Types should be supported.
    When RTP Payload Format is included, the differentiation between different RTP Payload Formats should be supported.
The Protocol Description can be UL only, DL only or UL and DL. The Protocol Description for UL and DL traffic may be different.
AF provided PDU Set QoS Parameters and UL and/or DL Protocol Description may be used in determining the PCC Rule by the PCF as defined in clause 6.1.3.27.4 of TS 23.503 and the DL Protocol Description may be used for identifying the PDU Set Information and PDU Set Information marking by the PSA UPF.
When the SMF receives the PCC rule, the SMF performs binding of the PCC rule to one QoS Flow as described in clause 6.1.3.2.4 of TS 23.503. At least one of the following shall be included in the PCC rule to enable PDU Set based handling: 1) a PSIHI and/or 2) both PSDB and PSER. Based on the PCC rule, the SMF adds the PDU Set QoS Parameters to the QoS Profile of the QoS Flow as described in clause 6.2.2.4 of TS 23.503. Alternatively, the SMF may be configured to support PDU Set based Handling without receiving PCC rules from a PCF.
For the downlink direction, the PSA UPF identifies PDUs that belong to PDU Sets and marks them accordingly as described in clause 5.37.5.2. If the PSA UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification, then the PSA UPF still maps it to a PDU Set and determines the PDU Set Information as described in clause 5.37.5.2.
For the uplink direction, the UE may identify PDU Sets, and how this is done is left up to UE implementation. The SMF may send the UL Protocol Description associated with the QoS rule to UE.
In this Release, the PDU Set based handling is supported in 5GS for UE registered in 3GPP access for single access PDU Session with IP PDU Session Type.
Up

5.37.5.2  PDU Set Information and Identificationp. 497

To support PDU Set based QoS handling, the PSA UPF identifies PDUs that belong to PDU Sets and determines the below PDU Set Information which it sends to the NG-RAN in the GTP-U header. The PDU Set information is used by the NG-RAN for PDU Set based QoS handling as described above.
The PDU Set Information comprises:
  • PDU Set Sequence Number.
  • Indication of End PDU of the PDU Set.
  • PDU Sequence Number within a PDU Set.
  • PDU Set Size in bytes.
  • PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.
The NG-RAN may use the Priority Level (see clause 5.7.3.3) across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion.
If the NG-RAN has provided a PDU Set based handling support Indication indicating that PDU Set handling is supported and a Protocol Description together with 1) a PSIHI and/or 2) PSDB and PSER is included in the PCC rule, the SMF instructs PSA UPF to perform PDU Set marking and may provide the PSA UPF the DL Protocol Description used by the service data flow. The DL Protocol Description may be received in the PCC rule, based on information provided by the AF or by PCF local policies as described in clause 5.37.5.1.
PSA UPF can identify the PDU Set Information using the DL Protocol Description and the received transport protocol headers and payload or using implementation specific means. The details of the RTP/SRTP headers, header extensions and/or payloads used to identify PDU Set Information are defined in TS 26.522.
For each DL PDU received on N6 for which PDU Set based QoS handling is indicated from the SMF, the PSA UPF applies the rules for PDU Set identification and provides the available PDU Set Information to the RAN in the GTP-U header.
Up

5.37.5.3  Non-homogenous support of PDU set based handling in NG-RANp. 498

The SMF, by sending PDU Set QoS parameters to the NG-RAN as described in clause 5.7.7.1, requests the NG-RAN to activate PDU Set QoS handling for a given QoS Flow and the NG-RAN provides the SMF with a PDU Set Based Handling Support Indication if the PDU Set based handling is supported. Based on this indication, SMF may activate the PDU Set identification and marking in the PSA UPF.
During mobility procedures that result in the change of NG-RAN, the target NG-RAN provides to the SMF a PDU Set Based Handling Support Indication if it supports PDU Set based handling, as specified in TS 38.413. Based on the target NG-RAN indication, the SMF may, upon completion of the mobility procedure, initiate the PDU Session modification procedure to provide PDU Set QoS parameters to NG-RAN and may configure the PSA UPF to activate the PDU Set identification and marking. If the PDU Set Based Handling Support Indication is not received from the target NG-RAN and PDU Set identification and marking is active in the PSA UPF, the SMF may deactivate it.
In the case where the PSA UPF identifies and marks PDUs with PDU Set information in GTP-U header, it shall start doing so from a complete PDU Set.
Up

5.37.6  UL/DL policy control based on round-trip latency requirement |R18|p. 498

For XR and other interactive media services that require very low Round-Trip (RT) latency, Uplink-Downlink policy control may be supported to meet the RT latency requirement. RT latency requirement is the upper bound for the sum of UL delay and DL delay of a single data flow or two different data flows between UE and N6 termination point at the UPF. PCF may support Uplink-Downlink policy control based on RT latency requirement based on an RT latency indication from AF (as defined in clause 6.1.3.27.2 of TS 23.503) during the AF session with the required QoS procedure as defined in clause 4.15.6.6 of TS 23.502.
The AF can provide an RT latency indication with a single direction delay requirement between the UE and the PSA UPF expressed as the QoS Reference parameter or individual QoS parameters (as defined in clause 6.1.3.22 of TS 23.503). The RT latency indication indicates the need to meet the RT latency requirement for data flow, i.e. doubling of the single direction delay requirement between the UE and the PSA UPF expressed by the QoS Reference parameter or individual QoS parameter.
PCF determines the data flow's UL PDB and DL PDB based on the RT latency requirement. The UL PDB and DL PDB can be unequal, but their sum shall not exceed the RT latency requirement. The PCF shall generate two PCC rules, one for UL QoS flow for UL traffic of the data flow and one for DL QoS flow for DL traffic of the data flow, respectively. PCF shall assign the 5QIs for each of these two PCC rules according to the derived UL PDB and DL PDB.
To support UL and DL delay tracking, the QoS monitoring for UL packet delay and the DL packet delay (as defined in clause 6.1.3.21 of TS 23.503) shall be triggered respectively to request tracking the UL packet delay of the QoS flow used in UL and DL packet delay of the QoS flow used in DL independently. Based on the QoS monitoring results, the PCF may readjust the UL PDB and/or DL PDB under the consideration of the RT latency requirement to better fit the new situation.
The Uplink-Downlink policy control based on round-trip latency requirement for two unidirectional service data flows is described in clause 6.1.3.27.2 of TS 23.503.
Up

5.37.7  5GS Packet Delay Variation monitoring and reporting |R18|p. 499

5.37.7.1  Generalp. 499

The 5GS Packet Delay Variation is the variation of packet delay measured between UE and PSA UPF. The AF may send the requirement for Packet Delay Variation monitoring to 5GS together with the requirement for packet delay measurement, as described in clause 6.1.3.26 of TS 23.503.
Upon AF request for Packet Delay Variation monitoring together with packet delay monitoring, the PCF triggers the QoS monitoring procedure, and obtains the UL, DL or RT QoS Monitoring result from the SMF. After receiving the QoS Monitoring result, the PCF derives the 5GS Packet Delay Variation based on the QoS Monitoring result and then reports to the AF/NEF both packet delay measurements and Packet Delay Variation.
The details of the QoS Monitoring and QoS Monitoring for packet delay are described in clauses 5.45 and 5.33.3.
QoS Monitoring is used to obtain measurement of QoS parameters of individual QoS Flows. PCF determines the measurements required based on input from AF and enables the measurements by generating an authorized QoS Monitoring Policy for the PCC Rule as specified in clause 6.1.3.21 of TS 23.503.
Up

5.37.8  UE power saving management |R18|p. 499

5.37.8.1  Generalp. 499

The following traffic assistance information may be provided by the CN to NG-RAN in order to configure UE power saving management scheme for connected mode DRX:
  • UL and/or DL Periodicity;
  • N6 Jitter Information associated with the DL Periodicity;
  • Indication of End of Data Burst.
The UL and/or DL Periodicity and N6 Jitter Information associated with the DL Periodicity are provided by the CN to NG RAN via TSCAI.

5.37.8.2  Periodicity and N6 Jitter Information associated with Periodicityp. 500

In the procedures for setting up or updating an AF session with QoS, the 5G System may be provided with UL/DL Periodicity information for NG-RAN to configure UE power management for connected mode DRX. The UL/DL Periodicity information is provided by the AF to the PCF via NEF or directly to the PCF when the AF is trusted.
If UL/DL Periodicity information is available at the PCF, the PCF sends the Periodicity information received from the AF/NEF to the SMF. In accordance with the operator's local policies, the PCF may include an indication for SMF to request the UPF to perform N6 Traffic Parameter(s) measurement (i.e. N6 Jitter Information associated with the DL Periodicity and if not provided by the AF, UL/DL periodicity) within the PCC Rules.
Upon reception of a PCC rule with Periodicity information, the SMF determines the TSCAI and forwards it to the NG-RAN. If the PCC rule indicates to perform N6 Traffic Parameter measurements, the SMF shall request the UPF to monitor and periodically or event-triggered report the N6 Traffic Parameters (i.e. the N6 Jitter Information associated with the DL Periodicity and, if not provided by the AF, UL/DL periodicity) using the N4 Session Modification procedure, see clause 5.8.5.11. If the measurement of N6 Jitter Information associated with the DL Periodicity is required and the DL Periodicity is available at the SMF, the SMF also sends the DL Periodicity to the UPF. The UPF reports the measured N6 Traffic Parameters to SMF via N4 interface.
At reception of measured N6 Traffic Parameter(s) from the UPF in the N4 Session Level Report, the SMF includes the N6 Jitter Information associated with the DL Periodicity together with the DL periodicity and the UL periodicity if not provided by the AF in the TSCAI and forwards it to the NG-RAN in an NGAP message, see clause 5.27.2.
The N6 Jitter Information associated with the DL Periodicity indicates the range of the positive or negative deviation of the arrival time of first arrived packet of a Data Burst compared to the ideal Data Burst start time which is be determined based on the DL periodicity.
Up

5.37.8.3  End of Data Burst Indicationp. 500

An indication of End of Data Burst may be provided to the NG-RAN by the UPF, e.g. to configure UE power management schemes like connected mode DRX.
Based on the End of Data Burst Marking Indication in a PCC rule and/or on local operator policies, SMF should request the UPF to detect the last PDU of the data burst and mark the End of Data burst in the GTP-U header of the last PDU in downlink. The SMF may provide the PSA UPF the End of Data Burst Marking Indication and Protocol Description used by the service data flow. The Protocol Description may be received in the PCC rule, based on information provided by the AF or by PCF local policies as described in clause 5.37.5.1.
According to the request and information from the SMF, the UPF identifies the last PDU of a Data burst in the DL traffic based on the End indication according to the Protocol Description or UPF implementation and provides an End of Data Burst indication to the NG-RAN over GTP-U of the last PDU of a Data burst.
Up

Up   Top   ToC