Content for  TS 38.300  Word version:  17.4.0

The IAB-DU's IP traffic is routed over the wireless backhaul via the BAP sublayer. The BAP sublayer is specified in TS 38.340. In downstream direction, upper layer packets are encapsulated by the BAP sublayer at the IAB-donor-DU and de-encapsulated at the destination IAB-node. In upstream direction, upper layer packets are encapsulated at the IAB-node and de-encapsulated at the IAB-donor-DU. IAB-specific transport between IAB-donor-CU and IAB-donor-DU is specified in TS 38.401. On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header. The BAP header is added to the packet when it arrives from upper layers, and the BAP header is stripped off when the packet has reached its destination node. The selection of the packet's BAP routing ID is configured by the IAB-donor-CU. The BAP routing ID consists of BAP address and BAP path ID, where the BAP address indicates the destination node of the packet on the BAP sublayer, and the BAP path ID indicates the routing path the packet should follow to this destination. For the purpose of routing, each IAB-node and IAB-donor-DU is further configured with a designated BAP address. On each hop of the packet's path, the IAB-node inspects the packet's BAP address in the BAP routing ID carried in the BAP header to determine if the packet has reached its destination, i.e., matches the IAB-node's BAP address. In case the packet has not reached the destination, the IAB-node determines the next hop backhaul link, referred to as egress link, based on the BAP routing ID carried in the BAP header and a routing configuration it received from the IAB-donor-CU. For each packet, the IAB-node further determines the egress BH RLC channel on the designated egress link. For packets arriving from upper layers, the designated egress BH RLC channel is configured by the IAB-donor-CU, and it is based on upper layer traffic specifiers. Since each BH RLC channel is configured with QoS information or priority level, BH-RLC-channel selection facilitates traffic-specific prioritization and QoS enforcement on the BH. For F1-U traffic, it is possible to map each GTP-U tunnel to a dedicated BH RLC channel or to aggregate multiple GTP-U tunnels into one common BH RLC channel. For traffic other than F1-U traffic, it is possible to map UE-associated F1AP messages, non-UE-associated F1AP messages and non-F1 traffic onto the same or separate BH RLC channels. When packets are routed from one BH link to another, the egress BH RLC channel on the egress BH link is determined based on the mapping configuration between ingress BH RLC channels and egress BH RLC channels provided by the IAB-donor-CU.

Flow and congestion control can be supported in both upstream and downstream directions in order to avoid congestion-related packet drops on IAB-nodes and IAB-donor-DU:

• In upstream direction, UL scheduling on MAC layer can support flow control on each hop;
• In downstream direction, the NR user plane protocol (TS 38.425) supports flow and congestion control between the IAB-node and the IAB-donor-CU for UE bearers that terminate at this IAB-node. Further, flow control is supported on BAP sublayer, where the IAB-node can send feedback information on the available buffer size for an ingress BH RLC channel or BAP routing ID to its parent node. The feedback can be sent proactively, e.g., when the buffer load exceeds a certain threshold, or based on polling by the parent node.

The IAB-node can reduce UL scheduling latency through signalling of a Pre-emptive BSR to its parent node. The IAB-node can send the Pre-emptive BSR based on UL grants it has provided to child nodes and/or UEs, or based on BSRs it has received from child nodes or UEs (Figure 4.7.3.3-1). The Pre-emptive BSR conveys the data expected rather than the data buffered.

The IAB-node integration procedure is captured in TS 38.401.

The IAB-node can migrate to a different parent node underneath the same IAB-donor-CU. The IAB-node continues providing access and backhaul service when migrating to a different parent node. The IAB-MT can also migrate to a different parent node underneath another IAB-donor-CU. In this case, the collocated IAB-DU and the IAB-DU(s) of its descendant node(s) retain F1 connectivity with the initial IAB-donor-CU. The IAB-MT of each descendant node and all the served UEs retain the RRC connectivity with the initial IAB-donor-CU. This migration is referred to as inter-donor partial migration. The IAB-node, whose IAB-MT migrates to the new IAB-donor-CU, is referred to as a boundary IAB-node. After inter-donor partial migration, the F1 traffic of the IAB-DU and its descendant nodes is routed via the BAP layer of the IAB topology to which the IAB-MT has migrated. Inter-donor partial migration is only supported for SA-mode. The intra-donor IAB-node migration procedure and inter-donor partial migration procedures are captured in TS 38.401.

The IAB-node may have redundant routes to the IAB-donor-CU(s). For IAB-nodes operating in SA-mode, NR DC can be used to enable route redundancy in the BH by allowing the IAB-MT to have concurrent BH links with two parent nodes. The parent nodes may be connected to the same or to different IAB-donor-CUs, which control the establishment and release of redundant routes via these two parent nodes. Either parent node's gNB-DU functionality together with the respective IAB-donor-CU assumes the role of the IAB-MT's master node or secondary node. The NR DC framework (e.g., MCG/SCG-related procedures) is used to configure the dual radio links with the parent nodes (TS 37.340). The procedure for establishment of topological redundancy for IAB-nodes operating in SA-mode is captured in TS 38.401. An IAB-node operating in NR-DC may also use one of its links for BH connectivity with an IAB-donor and the other link for access-only connectivity with a separate gNB that does not assume IAB-donor role. The IAB-donor can assume the MN or the SN role. The IAB-node may exchange F1-C traffic with the IAB-donor via the backhaul link and/or via the access link with the gNB. In the latter case, the F1-C messages are carried over NR RRC between the IAB-node and the gNB, and via XnAP between the gNB and the IAB-donor. IAB-nodes operating in EN-DC can exchange F1-C traffic with the IAB-donor via the MeNB. The F1-C message is carried over LTE RRC using SRB2 between IAB-node and MeNB and via X2AP between the MeNB and the IAB-donor. The procedures for establishment of redundant transport of F1-C for IAB-nodes using NR-DC and EN-DC are captured in TS 37.340 and TS 38.401.

When the IAB-node using SA-mode declares RLF on the backhaul link, it can perform RLF recovery at another parent node underneath the same or underneath a different IAB-donor-CU. In the latter case, the collocated IAB-DU and the IAB-DU(s) of its descendant node(s) may retain the F1 connectivity with the initial IAB-donor-CU, while the IAB-MT(s) of the descendant node(s) and all the served UEs retain the RRC connectivity with the initial IAB-donor-CU, in the same manner as for inter-donor partial migration. The BH RLF recovery procedure for the IAB-node is captured in TS 38.401. BH RLF declaration for IAB-node and the aspects of RLF recovery by the IAB-MT are handled in clause 9.2.7 of the present document.

An IAB-DU is subject to the same downlink timing alignment of a gNB. The IAB-DU may use the received downlink signal from a parent as a reference to control its downlink timing using TA in conjunction with an additional Tdelta parameter received by the collocated IAB-MT from the parent via MAC-CE.

Inter node discovery is supported via SSB-based and/or CSI-RS-based measurements. An IAB-node can be configured to transmit and receive off synchronization raster SSB signals to discover neighbouring IAB-nodes. The configuration is not expected to create a conflict between IAB-DU SSB transmission and IAB-MT SSB measurement windows.