Content for  TS 23.501  Word version:  18.5.0

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.