Content for  TS 38.401  Word version:  18.3.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 continuity of OAM connectivity needs to be ensured as the mobile IAB-node moves across the mobile network.

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. The mapping between the IP addresses assigned to the IAB-node and the BAP address(es) of the corresponding IAB-donor-DU(s) anchoring these IP addresses should be known by the IAB-node and the IAB-donor-CU based on implementation. 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.

During the mobile IAB-node integration procedure or mobile IAB-MT migration via NG handover, the RRC-terminating IAB-donor-CU receives the authorization status of the mobile IAB-node from the 5GC. During the mobile IAB-MT migration via Xn handover procedure and the mobile IAB-node RLF recovery procedure, the target/new RRC-terminating IAB-donor-CU receives the authorization status of the mobile IAB-node from the source/initial RRC-terminating IAB-donor-CU as well as from the 5GC during Path Switch Request procedure. If the authorization status is "not authorized", the RRC-terminating IAB-donor-CU does not establish any backhaul resources. Additionally, the RRC-terminating IAB-donor-CU does not allocate any BAP address, TNL address(es) or default BAP configuration for this mobile IAB-node. If the authorization status for the mobile IAB-node changes, the 5GC sends an updated authorization status to the RRC-terminating IAB-donor-CU. In case the mobile IAB-MT and its co-located mobile IAB-DU connect to same IAB-donor-CU, and the updated authorization status received from the 5GC is "not authorized", the IAB-donor-CU performs the following actions in the following order: it attempts to hand over the UEs served by the mobile IAB-node to other cell(s), releases the F1 interface towards the mobile IAB-DU, and then releases all backhaul resources, the BAP address, TNL address and default BAP configuration for this mobile IAB-node. In case the mobile IAB-MT and its co-located mobile IAB-DU connect to different IAB-donor-CUs, the RRC-terminating IAB-donor-CU sends the updated authorization status to the F1-terminating IAB-donor-CU via the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message. The F1-terminating IAB-donor-CU confirms the reception of the updated authorization status via the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. If the updated authorization status for the mobile IAB-node is set to "not authorized", the F1-terminating IAB-donor attempts to hand over the UEs served by the mobile IAB-node to other cell(s), and then releases the F1 interface towards the mobile IAB-DU. After that, the F1-terminating IAB-donor requests from the RRC-terminating IAB-donor the release of all the offloaded traffic via the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message. The RRC-terminating IAB-donor releases the offloaded traffic and all backhaul resources, BAP address, TNL address and default BAP configuration for this mobile IAB-node. The RRC-terminating IAB-donor may send an indication that the mobile IAB-MT can be deregistered via a UE CONTEXT RELEASE REQUEST message, to the AMF. If the authorization status is changed back from "not authorized" to "authorized", the phase 2 and phase 3 of the mobile IAB-node integration procedure as defined in clause 8.12.3 are carried out.

The NCIs of the cells served by a mobile IAB-DU configured by the OAM can be reconfigured by the F1-terminating IAB-donor-CU serving the mobile IAB-DU, in case of an NCI collision with cells of other gNB-DUs served by the IAB-donor-CU. The reconfiguration of NCI pertains to the reconfiguration of the cellLocalId part of the NCI, where the new cellLocalId(s) are based on a list of NCIs that has been configured at the F1-terminating IAB-donor-CU. The value change of cellLocalId(s) shall be indicated to the OAM system of the mobile IAB-DU following the NCI reconfiguration. The mobile IAB-DU can notify OAM about the reconfigured cellLocalId(s) using notifications specified in TS 28.532.

The TAC/RANAC of mobile IAB-DU's cell is configured by the OAM, and it can be reconfigured by the OAM during the mobile IAB-node mobility. The TAC/RANAC of the mobile IAB-DU's cell may be same as or different than the TAC/RANAC of the co-located mobile IAB-MT's serving cell. The TAC/RANAC broadcasted by the mobile IAB-DU cell can be changed in order to reflect the mobile IAB-node's physical location.