Content for  TS 38.300  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.3……   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.3   16.4…   17…   A…   B…


4.7  Integrated Access and Backhaul |R16|

4.7.1  Architecture

Integrated access and backhaul (IAB) enables wireless relaying in NG-RAN. The relaying node, referred to as IAB-node, supports access and backhauling via NR. The terminating node of NR backhauling on network side is referred to as the IAB-donor, which represents a gNB with additional functionality to support IAB. Backhauling can occur via a single or via multiple hops. The IAB architecture is shown in Figure 4.7.1-1.
The IAB-node supports gNB-DU functionality, as defined in TS 38.401, to terminate the NR access interface to UEs and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in TS 38.401, on the IAB-donor. The gNB-DU functionality on the IAB-node is also referred to as IAB-DU.
In addition to the gNB-DU functionality, the IAB-node also supports a subset of the UE functionality referred to as IAB-MT, which includes, e.g., physical layer, layer-2, RRC and NAS functionality to connect to the gNB-DU of another IAB-node or the IAB-donor, to connect to the gNB-CU on the IAB-donor, and to the core network.
The IAB-node can access the network using either SA mode or EN-DC. In EN-DC, the IAB-node connects via E-UTRA to a MeNB, and the IAB-donor terminates X2-C as SgNB (TS 37.340).
Reproduction of 3GPP TS 38.300, Figure 4.7.1-1: IAB architecture; a) IAB-node using SA mode with NGC; b) IAB-node using EN-DC
All IAB-nodes that are connected to an IAB-donor via one or multiple hops form a directed acyclic graph (DAG) topology with the IAB-donor as its root (Fig. 4.7.1-2). In this DAG topology, the neighbour node of the IAB-DU or the IAB-donor-DU is referred to as child node and the neighbour node of the IAB-MT is referred to as parent node. The direction toward the child node is referred to as downstream while the direction toward the parent node is referred to as upstream. The IAB-donor performs centralized resource, topology and route management for the IAB topology.
Reproduction of 3GPP TS 38.300, Figure 4.7.1-2: Parent- and child-node relationship for IAB-node

4.7.2  Protocol StacksWord‑p. 23
Fig. 4.7.2-1 shows the protocol stack for F1-U and Fig. 4.7.2-2 shows the protocol stack for F1-C between IAB-DU and IAB-donor-CU. In these figures, F1-U and F1-C are carried over two backhaul hops.
F1-U and F1-C use an IP transport layer between IAB-DU and IAB-donor-CU as defined in TS 38.470. F1-U and F1-C need to be security-protected as described in TS 33.501 (the security layer is not shown in the Figures 4.7.2-1/2).
On the wireless backhaul, the IP layer is carried over the Backhaul Adaptation Protocol (BAP) sublayer, which enables routing over multiple hops. The IP layer can also be used for non-F1 traffic, such as OAM traffic as defined in TS 38.401.
On each backhaul link, the BAP PDUs are carried by BH RLC channels. Multiple BH RLC channels can be configured on each BH link to allow traffic prioritization and QoS enforcement. The BH-RLC-channel mapping for BAP PDUs is performed by the BAP entities on each IAB-node and the IAB-donor-DU.
Protocol stacks for an IAB-donor with split gNB architecture are specified in TS 38.401.
Reproduction of 3GPP TS 38.300, Figure 4.7.2-1: Protocol stack for the support of F1-U protocol
Reproduction of 3GPP TS 38.300, Figure 4.7.2-2: Protocol stack for the support of F1-C protocol
The IAB-MT further establishes SRBs (carrying RRC and NAS) with the IAB-donor-CU. For IAB-nodes operating in ENDC, the IAB-MT also establishes one or more DRBs with the IAB-donor-CU, which can be used, e.g., to carry OAM traffic. For SA mode, the establishment of DRBs is optional. These SRBs and DRBs are transported between the IAB-MT and its parent node over Uu access channel(s). The protocol stacks for the SRB is shown in Fig. 4.7.2-3.
Reproduction of 3GPP TS 38.300, Figure 4.7.2-3: Protocol stack for the support of IAB-MT's RRC and NAS connections

4.7.3  User-plane AspectsWord‑p. 25  Backhaul transport

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 it is stripped off when it 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 packet 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 packet 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 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.
Up  Flow and Congestion Control

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.
Up  Uplink Scheduling LatencyWord‑p. 26
The IAB-node can reduce UL scheduling latency through signaling 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 The Pre-emptive BSR conveys the data expected rather than the data buffered.
Reproduction of 3GPP TS 38.300, Figure Scheduling of BSR in IAB a) regular BSR based on buffered data, b) Pre-emptive BSR based on UL grant, c) Pre-emptive BSR based on reception of regular BSR

4.7.4  Signalling procedures  IAB-node Integration

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

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-node migration procedure is captured in TS 38.401.  Topological Redundancy

The IAB-node may have redundant routes to the IAB-donor-CU.
For IAB-nodes operating in SA-mode, NR DC is 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 have to be connected to the same IAB-donor-CU, which controls the establishment and release of redundant routes via these two parent nodes. The parent nodes' gNB-DU functionality together with the IAB-donor-CU obtains 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.
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 MeNB and IAB-donor.
The procedure for establishment of redundant transport of F1-C for IAB-nodes using EN-DC is captured in TS 38.401.
Up  Backhaul RLF RecoveryWord‑p. 27
When the IAB-node using SA-mode declares RLF on the backhaul link, it can migrate to another parent node. The BH RLF recovery procedure to a parent node underneath the same IAB-donor-CU is captured in TS 38.401. BH RLF declaration for IAB is handled in clause 9.2.7.  OTA timing synchronization

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 signalled via MAC-CE.  Inter node discovery

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 neighboring IAB-nodes. The configuration is not expected to create a conflict between IAB-DU SSB transmission and IAB-MT SSB measurement windows.

4.8  Non-Public Networks |R16|

A Non-Public Network (NPN) is a network for non-public use (see TS 22.261), which can be deployed as (see TS 23.501):
  • a Stand-alone Non-Public Network (SNPN) when not relying on network functions provided by a PLMN; or
  • a Public Network Integrated (PNI) NPN when relying on the support of a PLMN.

Up   Top   ToC