Content for  TS 38.401  Word version:  17.5.0

Figure 8.9.7-1 shows the procedure used for the activation and the deactivation of UE traces in the gNB-DU, the gNB-CU-UP or both.

The BH RLC channel is an RLC channel used for backhauling between IAB-node and IAB-donor-DU, or between different IAB-nodes. The BH RLC channel establishment may be triggered by a UE accessing the network and establishing a DRB.

The IAB-donor-CU uses the existing CU-DU split principles and the UE Context Setup procedure or UE Context Modification procedure to configure the parent IAB-DU side of the BH RLC channel. The IAB-donor-CU uses RRC signaling (which is encapsulated in the DL RRC MESSAGE TRANSFER message terminating at the parent node IAB-DU side of the BH RLC channel) to configure the child node IAB-MT side of the BH RLC channel. The IAB-donor-CU configures the IAB-DU with a mapping to the BH RLC channel to be used for a specific UL F1-U tunnel during the UE Context Setup procedure or the F1-AP UE Context Modification procedure for the UE.

An IAB-node may depart the network either in an orderly fashion, which implies that both the network and the IAB-node are aware in advance, or in a disorderly fashion (e.g. due to an RLF with failed recovery).

The IAB-node receives commands, configuration data and software downloads (e.g. for equipment software upgrades) from its OAM system. The IAB-node can also send alarms and traffic counter information to its OAM system. The transport connection between the IAB-node and its OAM, using IP, is provided by the IAB-MT's PDU session via 5G network, or the IAB-MT's PDN connection via LTE network when IAB-MT uses EN-DC. Alarms in the IAB generate bursts of high-priority traffic, to be transported in real time. Traffic counters generate bursts of traffic, but their transport need not be real-time. Configuration messages from OAM to the IAB will also generate small bursts of traffic, possibly with lower priority than alarms but still delay-sensitive: when a configuration is committed on the OAM, the time interval between the commitment and the effect on the equipment shall be small. Alarm messages and commands should be transported on a high-priority bearer, while counters may be transported on a lower priority bearer. OAM software download to the IAB may generate larger amounts of data, but both the required data rate and the priority of this kind of traffic are much lower than in the case of alarms, commands and counters. For different types of OAM traffic, it is necessary to use different DRBs between the IAB-MT and the serving DU, and different BH RLC channels for intermediate hops, with different QoS parameters. Aggregation of F1-U traffic for OAM with other F1-U traffic on the same BH RLC channels is not precluded. The QoS parameters are provided to the IAB-donor during the IAB-MT's PDU session establishment, or the IAB-MT's PDN connection establishment when IAB-MT uses EN-DC.

The IAB-MT optionally supports the RRC INACTIVE state. Upon the IAB-MT entering the RRC INACTIVE state, it is up to implementation to keep or release the F1 connection of the collocated IAB-DU.

An IAB-node may obtain IP address(es) either from the IAB-donor or from the OAM system. The IP address(es) is(are) used by the IAB-node for F1 and non-F1 traffic exchange via the backhaul. In case IPsec tunnel mode is used to protect this F1 and non-F1 traffic, the IP address(es) refer to the outer tunnel addresses. The allocation of the inner tunnel IP address(es) is outside of 3GPP scope. In case of IAB-donor-based IP address allocation, the IP address(es) is(are) allocated by the IAB-donor-CU or IAB-donor-DU. In both cases, the IAB-node requests the IP address(es) via RRC from the IAB-donor-CU. It includes a separate IP address request for each usage, where the usages defined are all traffic, F1-U, F1-C and non-F1. The IAB-donor-CU may initiate the IAB TNL Address Allocation procedure to obtain IP addresses from the IAB-donor-DU. The IAB-donor-CU sends the IP addresses allocated for each usage to the IAB-node via RRC. r each usage to the IAB-node via RRC. In case of IAB inter-CU topology management, the F1-terminating IAB-donor-CU may obtain the IP addresses for each usage in the non-F1-terminating IAB-donor-CU's topology from the non-F1-terminating IAB-donor-CU for the boundary IAB-node and the descendant IAB-nodes of the boundary IAB-node. The IAB-node may be allocated one or multiple IPv6 addresses or one 64-bit IPv6 prefix for each usage and/or one or multiple IPv4 addresses for each usage. Each allocated IP address/IPv6 prefix is unique within the IAB network and routable from the wireline network. In case of OAM-based IP address allocation, the IAB-node informs the IAB-donor-CU via an UL RRC message about the IP address(es) it received for each purpose. This occurs before the IAB node uses the IP address(es) for UL and/or DL traffic. The IAB-donor-CU configures the IAB-donor-DU with mappings between IP header fields and L2 parameters (BAP Routing ID, BH RLC channels) used for DL traffic. Each mapping configuration may hold an IPv4 address, IPv6 address or a 64-bit IPv6 prefix. In case of two mapping entries matching the same IP header where one holds an IPv6 prefix and the other holds a full IPv6 address, the one with full IPv6 address takes precedence at the IAB-donor-DU. In case of IAB-donor-allocated IP addresses, the IAB-node's IP address(es) can be updated using DL RRC signalling. For F1-C traffic transfer for NSA IAB, the LTE leg and NR leg should use separate IP address pairs {IAB-DU's IP address, IAB-donor-CU's IP address}. How the IAB-DU gets the remote IP end point(s) and its own IP address for LTE leg is not specified in this release.