Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Radio Access Network

Boundary IAB-node

Boundary Integrated Access and Backhaul node

Radio Access Network →

Boundary IAB-node is an IAB-node whose RRC interface terminates at a different IAB-donor-CU than its F1 interface, enabling features like partial migration and inter-donor recovery in multi-donor networks.

Introduced
Rel-17
Where
Radio Access Network › NG-RAN (5G)
Specifications
4 specs
Boundary IAB-node Description Purpose What changed Neighbours Specifications

Description

A Boundary IAB-node is a specific type of Integrated Access and Backhaul (IAB) node in 3GPP 5G networks, defined as an IAB-node with one RRC interface terminating at a different IAB-donor-CU than the F1 interface. This definition applies to scenarios involving partial migration, inter-donor redundancy, and inter-donor radio link failure (RLF) recovery. The concept was introduced in Release 17 to support advanced IAB topologies where multiple IAB-donors cooperate to serve a single IAB-node, enhancing robustness and mobility.

In an IAB network, IAB-nodes provide both access and backhaul functionality, relaying traffic between user equipment and IAB-donors. The IAB-donor consists of a Central Unit (CU) and Distributed Units (DUs). The CU hosts the RRC and PDCP layers, while the DU handles RLC, MAC, and PHY layers. Normally, an IAB-node's RRC and F1 interfaces terminate at the same IAB-donor-CU. However, in a boundary IAB-node, the RRC interface terminates at one IAB-donor-CU (the RRC donor) while the F1 interface terminates at another (the F1 donor). This split allows the IAB-node to maintain RRC connectivity with one donor while using a different donor for user plane and control plane data via F1.

The boundary IAB-node architecture supports several key use cases. In partial migration, an IAB-node can migrate its F1 interface from one donor to another while keeping its RRC connection with the original donor, minimizing service interruption. In inter-donor redundancy, the IAB-node can have simultaneous F1 connections to multiple donors, providing path diversity and resilience. In inter-donor RLF recovery, if the RRC connection to the original donor fails, the IAB-node can recover by re-establishing RRC with the donor that hosts its F1 interface, or vice versa. These capabilities are essential for maintaining service continuity in dense deployments and during network upgrades.

The boundary IAB-node concept relies on enhanced signaling and coordination between IAB-donors. The 3GPP specifications 38.300, 38.401, 38.420, and 38.423 define the procedures for establishing and managing boundary IAB-nodes, including RRC and F1 interface management, mobility, and RLF recovery. The network must ensure that the RRC and F1 donors can communicate and coordinate, often via the Xn interface, to support seamless operation. This coordination includes exchanging context information, managing security keys, and handling handover procedures.

From a protocol perspective, the boundary IAB-node introduces new challenges for RRC and F1AP. The RRC layer, terminated at the RRC donor, handles connection management, mobility, and security. The F1 layer, terminated at the F1 donor, handles data transfer and lower-layer control. The split requires careful handling of UE contexts and bearer mappings. For example, when a UE connects to the boundary IAB-node, its RRC connection is anchored at the RRC donor, but its data flows through the F1 donor. This necessitates coordination between the two donors to ensure proper routing and QoS enforcement.

The introduction of boundary IAB-nodes in Release 17 reflects the evolution of IAB towards more flexible and resilient multi-donor architectures. It enables operators to deploy IAB networks with overlapping coverage from multiple donors, improving reliability and enabling seamless migration of IAB-nodes between donors. The definition has remained unchanged in Releases 18 and 19, indicating its stability and continued relevance.

Purpose & Motivation

The Boundary IAB-node concept was created to address the limitations of single-donor IAB deployments, where an IAB-node's RRC and F1 interfaces are tied to the same IAB-donor-CU. In such deployments, any failure or migration of the donor affects both interfaces, leading to service interruption. The boundary IAB-node decouples these interfaces, allowing them to terminate at different donors, thereby enabling partial migration, inter-donor redundancy, and inter-donor RLF recovery.

Partial migration allows an IAB-node to move its F1 interface to a new donor while keeping its RRC connection with the original donor, minimizing disruption during network upgrades or load balancing. Inter-donor redundancy provides multiple F1 paths to different donors, enhancing reliability against backhaul failures. Inter-donor RLF recovery enables the IAB-node to recover from RLF by leveraging the alternative donor, improving service continuity.

Historically, the boundary IAB-node was introduced in Release 17 as part of the ongoing evolution of IAB in 5G-Advanced. It builds on earlier IAB work in Release 16, which focused on single-donor topologies. The new concept addresses the need for more robust and flexible backhaul in dense urban and rural deployments, where multiple donors may be available. By allowing RRC and F1 to terminate at different donors, the boundary IAB-node provides a foundation for advanced multi-connectivity and mobility features.

What changed in its specifications

The latest release-to-release comparison of specifications that define Boundary IAB-node. Each summary describes the whole specification, not only this term.

TS 38.300Rel-18 → Rel-19

Rel-19 adds multi-hop L2 UE-to-Network relay for NR sidelink as the largest item. It also adds low-power wake-up signal and receiver (LP-WUS/WUR) text, on-demand SSB and SIB1 for network energy savings, and sub-band full duplex for TDD carriers.

Full comparison in TS 38.300 →
TS 38.401Rel-18 → Rel-19

Rel-19 adds Wireless Access Backhaul (WAB) architecture and node procedures to TS 38.401. It also adds multi-hop Layer-2 sidelink UE-to-Network relay with First, Intermediate and Last U2N Relay UE roles. Ambient IoT support is added, including A-IoT session contexts and AMF connectivity.

Full comparison in TS 38.401 →

Release Timeline

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-17 Initial

Initial definition: a boundary IAB-node is an IAB-node with one RRC interface terminating at a different IAB-donor-CU than the F1 interface. This applies to partial migration, inter-donor redundancy, and inter-donor RLF recovery.

Definition carried over unchanged from Rel-17.

Definition carried over unchanged from Rel-17, with minor formatting adjustment.

Defining Specifications

3GPP specifications that define or reference Boundary IAB-node, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 38.300 vj40 NR and NG-RAN Overall Description Rel-19 read
TS 38.401 vj30 NG-RAN Architecture Description Rel-19 read
TS 38.420 vj10 Introduction to Xn interface specifications Rel-19 read
TS 38.423 vj40 NG-RAN Xn Application Protocol Rel-19 read