Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  17.2.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.3.2…   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.2…   16.3…   16.4…   16.9…   16.10…   16.12…   16.13…   16.14…   17…   18…   19…   A…   B…   C…

 

4.7  Integrated Access and Backhaul |R16|p. 26

4.7.1  Architecturep. 26

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 the 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, Fig. 4.7.1-1: IAB architecture; a) IAB-node using SA mode with NGC; b) IAB-node using EN-DC
Up
All IAB-nodes that are connected to an IAB-donor via one or multiple backhaul hops and controlled by this IAB-donor via F1AP and/or RRC form an IAB topology with the IAB-donor as its root (Figure 4.7.1-2). In this IAB topology, the neighbour node of the IAB-DU or the IAB-donor-DU is referred to as the child node and the neighbour node of the IAB-MT is referred to as the 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 its IAB topology.
Reproduction of 3GPP TS 38.300, Fig. 4.7.1-2: Parent- and child-node relationship for IAB-node
Up

4.7.2  Protocol Stacksp. 27

Figure 4.7.2-1 shows the protocol stack for F1-U and Figure 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, Fig. 4.7.2-1: Protocol stack for the support of F1-U protocol
Up
Reproduction of 3GPP TS 38.300, Fig. 4.7.2-2: Protocol stack for the support of F1-C protocol
Up
The IAB-MT further establishes SRBs (carrying RRC and NAS) with the IAB-donor-CU. For IAB-nodes operating in EN-DC, the IAB-MT establishes one or more DRBs with the eNB and 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 Figure 4.7.2-3.
Reproduction of 3GPP TS 38.300, Fig. 4.7.2-3: Protocol stack for the support of IAB-MT's RRC and NAS connections
Up

4.7.3  User-plane Aspectsp. 29

4.7.3.1  Backhaul transportp. 29

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.
Up

4.7.3.2  Flow and Congestion Controlp. 29

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

4.7.3.3  Uplink Scheduling Latencyp. 30

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.
Reproduction of 3GPP TS 38.300, Fig. 4.7.3.3-1: 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
Up

4.7.4  Signalling proceduresp. 30

4.7.4.1  IAB-node Integrationp. 30

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

4.7.4.2  IAB-node Migrationp. 30

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.
Up

4.7.4.3  Topological Redundancyp. 30

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.
Up

4.7.4.4  Backhaul RLF Recoveryp. 31

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.
Up

4.7.4.5  OTA timing synchronizationp. 31

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.

4.7.4.6  Inter node discoveryp. 31

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.

4.8  Non-Public Networks |R16|p. 31

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