One of the most challenging things for 5G deployment would be the fact that the cell coverage is small (too small ?) comparing to other legacy technology (e.g, 3G, 4G).  But this is not because of engineering limitation (so Engineers.. don't blame yourself -:), it is due to physics. It is a common sense that a cell using higher frequency would have smaller radius (smaller coverage) comparing to the cells using lower frequency. In most cases, 5G(NR) cell would use higher frequency than the legacy cell (3G or 5G). Especially 5G FR2 uses much, much higher frequency than legacy cell or 5G FR1. I haven't seen any documents explicitely stating the exact cell radius of 5G cells, but I noticed that most of field test result showing the jaw-dropping speed especially in mmWave (FR2) is done within the radius of 300 m (NOTE : I heard of some cases where mmWave communication maintained reaching a few km but it was the case between mmWave cell and High Power CPE).

Think of how many of gNB we have to deploy to provide good and wide coverage with such a small radius. Even if carriers decided to invest enough money to scatter the cells in every few hundred meters, there would still be technical challenges. It is how they can branching out fibers to connect to such a huge amount of cells. It would be a natural for engineers to come up with such an idea of connecting some cells wirelsslessly instead of using fiber. This is the basic idea of IAB.

In IAB, usually a Macro Cell works as IAB donor and one or more of small cells (called IAB Node) is connected wirelesslesy to the IAB donor. You can think of IAB Node as a relay cell wirelessly connected to a donor. If a UE is connected to an IAB node, the communcation gets relayed to a macrocell via wireless IAB backhaul and then reaches corenetwork via optical fiber that is connected to the macro cell.

• Executive Summary
• High Level IAB deployment Scenario
• What exactly is inside an IAB node ?
• What frequency is used for IAB wireless backhaul link ?
• What kind of protocol is used for Backhaul Link ?
• What does BAP do, and why does the backhaul need its own protocol layer ?
• How does an IAB node join the network ?
• Why can an IAB node not transmit and receive at the same time ?
• How do the nodes stay time aligned over the air ?
• What does each extra hop cost ?
• How is IAB different from a repeater or an LTE relay ?
• What changed in Release 17 and Release 18 ?
• Reference
• YouTube

Executive Summary

High Level IAB deployment Scenario

The architecture reads more easily after seeing where the boxes actually sit. Figure 1 is a deployment as an engineer would sketch it. < 38.300 Figure 4.7.1-1 > below it is the same arrangement drawn formally.

Figure 1 shows one donor and three IAB nodes. Optical fiber reaches the donor and stops there. Every other site is fed by a wireless backhaul link (marked as red link), carried on NR spectrum. The links are ordinary access links to UEs (marked as blue), and every site has them. The donor has them too, so it keeps serving its own UEs while it feeds the nodes. Two of the nodes sit one hop from the donor, and the third is reached through one of them.

Figure 1. Fiber reaches exactly one site. Everything else is fed by the same NR spectrum that carries the UE traffic, which is where both the saving and the cost of IAB come from.

Three details in Figure 1 are worth naming. The first is the tree shape. Node A and node B are children of the donor, and node C is a child of node B. Node C is therefore two hops away from the fiber.

The second detail is that node B carries two loads at once. It serves its own UEs, and it also relays everything belonging to node C. The third is that the red links and the blue links use the same spectrum when the deployment is in-band. That sharing is what the section on hop cost below puts numbers to.

More formal representation of IAB within overal 5G network is shown in 38.300 as follows.

< 38.300-Figure 4.7.1-1 Figure 4.7.1-1: IAB architecture; a) IAB-node using SA mode with NGC; b) IAB-node using EN-DC >

The two panels of < 38.300 Figure 4.7.1-1 > differ in one thing, which is where the control plane is anchored. Panel a) is the standalone case. The IAB-donor is a full gNB. It reaches the 5G core over NG, its neighbours over Xn, and its children over NR Uu. Panel b) is the EN-DC case. The core is the EPC, the anchor is an MeNB reached over LTE Uu, and the IAB-donor acts as the SgNB. Each IAB-MT then holds two legs, one on LTE and one on NR.

One set of lines is worth following in both panels. The F1 lines run from every IAB-node directly to the IAB-donor. They pass the intermediate IAB-node without stopping there. That is the same property the next section describes, where F1 travels across the backhaul as payload.

• Fiber reaches one site only : The donor has the fiber. Every other site in Figure 1 is fed by NR radio, and that is the whole cost argument for IAB.
• The topology is a tree : Node A and node B hang off the donor, and node C hangs off node B. Hop count is a property of a position in that tree.
• Every IAB node serves UEs as well : The access links are ordinary NR access links, so an IAB node is a cell first and a relay second.
• A relaying node carries two loads : Node B serves its own UEs and relays the traffic of node C, on the same spectrum.
• The specification allows two deployment options : Standalone with the 5G core, and EN-DC with the EPC where an MeNB anchors the control plane.
• F1 bypasses intermediate nodes in both options : Each IAB-node terminates F1 with the IAB-donor, whatever sits between the two.

What exactly is inside an IAB node ?

I found IAB much easier to read once I stopped treating an IAB node as one box. It is two functions sharing a cabinet. Nearly every rule in the feature follows from that split, so it is worth getting clear before anything else.

The first function is the IAB-MT, where MT stands for Mobile Termination. It faces upward, toward the parent. To that parent it looks like a UE. It searches for a cell, runs random access, sets up an RRC connection and gets authenticated. The second function is the IAB-DU. It faces downward, toward child nodes and toward ordinary UEs. To them it looks like a normal gNB-DU. It transmits SSB, broadcasts system information and schedules traffic.

The IAB-donor is split in the same style, but along the CU and DU line. The donor-CU holds RRC, PDCP and SDAP for every UE in the tree. The donor-DU is the radio unit that the first hop of the tree connects to. One donor-CU can serve many donor-DUs and many IAB nodes below them.

One relationship is easy to miss on a first reading. Every IAB-DU, however many hops down the chain it sits, terminates an F1 interface directly with the donor-CU. F1 does not stop at the intermediate node. Instead it is carried across the backhaul as payload. Therefore the donor-CU sees a flat set of DUs, and the multi-hop structure below it is a transport detail.

Figure 2 shows a two-hop chain. The donor is on the left and a UE is on the right. Each IAB node is drawn with its MT half and its DU half separated, and the dashed lines are the F1 interfaces running back to the donor-CU.

Figure 2. The MT half and the DU half are what make the chain work. Every IAB-DU keeps its own F1 to the donor-CU, however many hops away it sits.

• An IAB node is an IAB-MT plus an IAB-DU : The MT half faces the parent, and the DU half faces children and UEs.
• The MT half is a UE to its parent : It performs cell search, random access, RRC connection setup and authentication, exactly as a UE does.
• The DU half is an ordinary gNB-DU : It transmits SSB, broadcasts system information and schedules the children below it.
• The donor splits into donor-CU and donor-DU : The donor-CU holds RRC, PDCP and SDAP for every UE in the tree.
• F1 runs end to end, not hop by hop : Every IAB-DU terminates F1 with the donor-CU. The backhaul carries F1 as payload rather than terminating it.

What frequency is used for IAB wireless backhaul link ?

Even in legacy technology, you may see some cases where the backaul links are connected wirelessly. But in most of those cases, they use different frequencies (in most cases non-cellular frequency) than cellular channel frequency and use their own protocol (non-3GPP) proprietorily designed for the connection. On the contray, in IAB the backhaul frequency is also NR band. It may be same as the access link frequency or different from the access link frequency, but it uses the NR band/frequency defined in 3GPP NR specification.

What kind of protocol is used for Backhaul Link ?

The radio protocol for the backhaul link is very similar to access link (i.e, probotol between UE and a cell). In IAB Backhaul, IAB Node act like a UE communicating with a IAB Donor. You see the block labeled 'MT' in the following illustration and this block act like a UE to the IAB Donor. It performs cell search and perform RACH and RRC signaling for radio resource allocation and authentication. The difference between the backhaul protocol and regular access link protocol would be that the highest layer in the protocol is BAP, not RLC. (See 38.874 ,38.300 and 38.401 for the details of this protocol). As you may notice, IAB works as DU in the overall RAN architecture. (NOTE : Refer to this page for CU/DU separation).

< 38.874 Figure 6.3.1-1: Reference diagram for architecture 1a (SA-mode with NGC) >

One label in < 38.874 Figure 6.3.1-1 > is worth explaining, because the name changed afterwards. The backhaul links are marked RLC/Adapt, and the stack on the right shows F1-U keeping GTP-U while UDP, IP and L1/L2 are replaced by RLC/Adapt over PHY/MAC. Adapt is the study-phase name for the adaptation layer. In the normative specification that layer became BAP, and TS 38.340 defines it. Read Adapt and BAP as the same idea, one release apart.

The final Release 16 design is not identical to the study, so the stack should not be read as normative. F1 runs over IP, and BAP routes the IP packets across the hops. The section below covers what BAP does and how it is configured.

Following diagrams from 3GPP spec would give you more detailed picture on the procedures behind the IAB backhaul link.

< 38.401 - Figure 8.12.1-1 > puts the whole integration on one time line. The vertical lines are the parties that take part. Two IAB nodes appear, because node 2 joins through node 1, and the parent is involved throughout. The IAB-donor is drawn as a dashed box holding the IAB-donor-DU and the IAB-donor-CU separately. Each phase is a horizontal band, and how far a band reaches to the right shows which parties that phase needs.

< 38.401 - Figure 8.12.1-1: The integration procedure for IAB-node in SA >

• Phase 1 is the only band that reaches the 5GC : The IAB-MT registers and is authenticated like a UE, so the core network takes part. Every later phase stops at the IAB-donor-CU, because the rest is internal to the RAN.
• Phase 2 is drawn as two steps, not one : Phase 2-1 establishes the BH RLC channels, and Phase 2-2 updates the routing. The channels have to exist before any route can point along them.
• Phase 3 comes last for a reason : The IAB-DU cannot bring up F1 until the backhaul path underneath it already carries traffic.
• The IAB-donor is drawn as two entities : The IAB-donor-CU decides the configuration, and the IAB-donor-DU is the radio end of the first hop. Both appear in every phase.

< 38.401 - Figure 8.9.8-1 > expands Phase 2-1 into individual messages. It uses the same two IAB nodes, and it configures the two hops one after the other. Steps 1 to 6 set up the hop between the IAB-donor-DU and IAB-node 1. Steps 7 to 12 repeat the identical exchange for the hop between IAB-node 1 and IAB-node 2. Reading one block is therefore enough to understand both.

< 38.401 - Figure 8.9.8-1: Signalling flow for IAB BH RLC channel establishment procedure >

• Each hop is configured from the parent side first : The IAB-donor-CU modifies the parent's UE context before the child is told anything.
• The child is reached through its parent : An RRCReconfiguration for the child travels inside a DL RRC MESSAGE TRANSFER addressed to the parent DU.
• F1AP runs between the donor-CU and every IAB-DU : In steps 7 to 12 the parent is IAB-node 1, and the donor-CU signals to it directly. That is F1 reaching past the intermediate node.
• The sequence is a loop, not a special case : A third hop would add steps 13 to 18 with the same six messages, one level further down.

What does BAP do, and why does the backhaul need its own protocol layer ?

The access link and the backhaul link use almost the same radio protocol. The difference is one sublayer, and that sublayer is BAP. It is small, and it is what turns a set of relays into a network.

BAP stands for Backhaul Adaptation Protocol, and TS 38.340 defines it. It sits directly above RLC, and it exists on the backhaul link only. A UE never sees it. Its job is to move a packet across several hops and hand it to the right RLC channel at each one.

Two functions matter most. The first is routing. Every BAP PDU carries a BAP Routing ID, which is a BAP address of 10 bits followed by a BAP path ID of 10 bits. The address says which node the packet is destined for. The path ID says which route should be taken to reach it. Each node holds a routing configuration written by the donor-CU, and it forwards on that configuration.

The second function is bearer mapping. A backhaul link does not carry one radio bearer per UE. Instead it carries BH RLC channels, and traffic from many UEs can be multiplexed onto one of them. BAP decides which egress BH RLC channel an arriving packet leaves on. In this way the quality of service treatment survives every hop.

That last point is what lets the design scale. An intermediate IAB node does not terminate PDCP, and it does not hold UE context. It reads the BAP header, looks up the route and forwards the packet. The PDCP peer of the UE stays at the donor-CU for the whole path.

Figure 3 shows a single backhaul hop. The layers on the left belong to the IAB-MT of one node, and the layers on the right belong to the IAB-DU of its parent. The box above the stacks is the traffic being carried, which the backhaul treats as payload.

Figure 3. BAP is the only layer the backhaul adds. Everything above it, F1 included, travels as payload that BAP routes and maps.

Nothing in BAP is self-organising. A node does not discover its neighbours, and it does not learn routes by exchanging tables with anyone. Every entry it uses is written by the donor-CU. Two protocols carry that configuration, and they divide the work by which half of the node they address.

F1AP configures the IAB-DU half. The BAP MAPPING CONFIGURATION procedure carries the routing table. Its BH Routing Information Added List holds one entry per route, and each entry pairs a BAP Routing ID with the next-hop BAP address. The same procedure carries the traffic mapping that decides which egress BH RLC channel a packet leaves on. The UE CONTEXT SETUP and UE CONTEXT MODIFICATION procedures create the backhaul RLC channels themselves, each identified by a BH RLC Channel ID.

RRC configures the IAB-MT half. The BAP-Config information element inside RRCReconfiguration gives the node its own bap-Address, which is 10 bits. It also gives the defaults the node applies when nothing more specific matches, namely defaultBAP-RoutingID and defaultUL-BH-RLC-Channel. Alongside it, BH-RLC-ChannelConfig sets up each backhaul RLC channel on the MT side, with its bh-RLC-ChannelID and its RLC and logical channel parameters.

The order those messages arrive in is drawn in < 38.401 - Figure 8.9.8-1 >, in the section above. The pattern repeats once per hop. The donor-CU first modifies the UE context of the parent, which creates the channel on the parent's DU side. It then sends an RRCReconfiguration to the child, carried inside a DL RRC MESSAGE TRANSFER through that same parent. Steps 1 to 6 configure the hop below the IAB-donor-DU. Steps 7 to 12 repeat the identical exchange one hop further down.

The header BAP adds is small. The data PDU header is three octets. It holds a D/C flag saying whether the PDU carries data or control, some reserved bits, and then the DESTINATION and PATH fields of 10 bits each. Those two fields together are the BAP Routing ID.

Control PDUs carry no user data at all. Flow control feedback is the important one. It reports buffer status per BH RLC channel or per routing ID, so that a parent can slow down before a child runs out of room. A backhaul radio link failure indication travels the same way.

• BAP sits above RLC, on the backhaul only : TS 38.340 defines it. The access link does not have it, and a UE never sees it.
• BAP Routing ID is address plus path : A BAP address of 10 bits names the destination node, and a BAP path ID of 10 bits names the route to it.
• Bearer mapping preserves quality of service : BAP chooses the egress BH RLC channel, so the treatment a packet gets survives every hop.
• Intermediate nodes hold no UE context : They do not terminate PDCP. They read the BAP header, look up the route and forward.
• The donor-CU writes the routing configuration : Nodes do not discover routes themselves, so topology changes are a configuration action by the donor.
• F1AP addresses the DU half and RRC addresses the MT half : BAP MAPPING CONFIGURATION and UE CONTEXT MODIFICATION reach the IAB-DU. BAP-Config and BH-RLC-ChannelConfig reach the IAB-MT inside an RRCReconfiguration.
• The BAP data PDU header is three octets : A D/C flag, reserved bits, and the 20-bit BAP Routing ID built from DESTINATION and PATH.
• Channel setup repeats once per hop : The donor-CU modifies the parent's UE context, then reconfigures the child through that same parent.
• Control PDUs carry flow control back up the tree : Buffer status is reported per BH RLC channel or per routing ID. Backhaul radio link failure is indicated the same way.

How does an IAB node join the network ?

A new IAB node does not become useful in one step. It joins in three phases, and each phase leaves it more capable than the last. TS 38.401 sets them out in that order, and the order explains most integration problems.

Phase 1 is IAB-MT setup. The MT half attaches exactly as a UE would. It performs cell search, random access and RRC connection setup with its parent. It then registers with the core network and is authenticated. Two things mark it as different from a UE. It sends an IAB-node indication in RRCSetupComplete, and the AMF returns an authorisation confirming that this device may act as an IAB node.

Phase 2 is backhaul setup. The donor-CU establishes BH RLC channels on the new link. It also updates the BAP routing configuration, both on the new node and on every ancestor between that node and the donor. Without the ancestor update there would be no route toward the newcomer, and traffic could reach it in neither direction.

Phase 3 is IAB-DU setup. The DU half starts and sets up F1 with the donor-CU, across the backhaul path that Phase 2 has just built. Only once F1 is up may the node transmit its own SSB, broadcast system information and accept UEs of its own.

The order explains a symptom that is easy to misread. A node can be attached, authenticated and fully visible to the core network, and still serve nobody at all. That is a node which finished Phase 1 and stopped. Therefore the first question in any IAB integration problem is which of the three phases completed.

• Phase 1 attaches the IAB-MT : Cell search, random access, RRC setup and authentication, exactly as a UE performs them.
• The node declares itself : An IAB-node indication in RRCSetupComplete, and an authorisation from the AMF in return.
• Phase 2 builds the transport : BH RLC channels on the new link, plus a routing update on every ancestor up to the donor.
• Phase 3 brings up the IAB-DU : F1 to the donor-CU comes first. Only then can the node transmit SSB and accept UEs.
• Attached is not the same as serving : A node stuck after Phase 1 looks healthy from the core network and carries no traffic.

Why can an IAB node not transmit and receive at the same time ?

This is the constraint I would look at first when somebody reports disappointing IAB throughput. It is rarely a coverage problem. Most of the time it is air time.

An IAB node normally cannot receive on its parent link while it is transmitting on its child link. The reason is ordinary radio engineering. The transmitter and the receiver share a band, and often share a panel. The node's own transmission would therefore be far stronger than the signal it is trying to receive. This is the in-band half-duplex constraint.

Three ways to separate the two links exist. The first is time division, where the IAB-MT and the IAB-DU use different symbols. The second is frequency division, where they use different parts of the band. The third is space division, where separated panels and enough isolation let both run at once. Time division is the simple case, and it is what a Release 16 node relies on.

The separation has to be signalled, and this is where the resource types come in. Each IAB-DU resource is configured as downlink, uplink or flexible. It is then marked in one of three further ways. Hard means the IAB-DU may always use it. Soft means the parent decides, and the parent indicates availability using DCI format 2_5. Not Available means the IAB-DU must not use it at all.

The Soft category has a consequence worth stating on its own. It puts the parent in control of how much air time a child receives. An IAB tree is therefore not a set of independent cells. It is one scheduling hierarchy, and capacity planning has to treat it as one.

Figure 4 shows ten slots at one IAB node. The top lane is the parent link and the middle lane is the child link, and the two never overlap. The bottom lane gives the resource type that the donor configured for each IAB-DU slot.

Figure 4. The Soft resources are the interesting column. They put the parent, not the child, in charge of how much air time the child gets.

• The constraint is half-duplex, not coverage : One node cannot receive from its parent while transmitting to its children on the same band.
• Time, frequency or space can separate the links : Time division is the Release 16 baseline. Frequency and space division need extra bandwidth or extra isolation.
• Every IAB-DU resource carries a type : Hard means always usable, Soft means the parent decides, and Not Available means never usable.
• DCI format 2_5 carries the availability indication : That is how a parent releases Soft resources to a child, slot by slot.
• An IAB tree is one scheduling hierarchy : Because parents control Soft resources, child capacity is a parent decision, and not a property of the child cell.

How do the nodes stay time aligned over the air ?

A multi-hop IAB network has to behave like one synchronous TDD network. If two nodes disagree about when a slot begins, their transmissions interfere in ways an ordinary deployment never produces. There is no fibre carrying a common clock, so the alignment has to come over the air.

Release 16 adopted one alignment rule, known as Case 1. Every IAB-DU aligns its downlink transmit timing with the donor and with every other IAB-DU. Seen from a UE, the tree then looks like a set of normal cells that happen to be synchronised.

Reaching that alignment needs a value the node cannot work out alone. An IAB-MT knows when downlink arrives from its parent, and it knows its own timing advance. Those two are not sufficient, because the propagation delay and the parent's own offset remain unknown to it. The parent therefore signals a correction called T_delta in a MAC CE. The node then derives its IAB-DU downlink transmit timing from its measured receive timing, its timing advance and T_delta.

The error compounds down the chain. Each node aligns to its parent, and that parent has already aligned to its own parent. Timing error therefore accumulates with hop count, which is one more reason deployments stay shallow.

Release 17 added two further cases for the enhanced duplexing work. Case 6 aligns the uplink transmit timing of the IAB-MT with the downlink transmit timing of the IAB-DU. Case 7 aligns the downlink receive timing of the IAB-MT with the uplink receive timing of the IAB-DU. Each case makes one form of simultaneous operation possible that Case 1 on its own does not support.

• Case 1 is the Release 16 rule : Every IAB-DU aligns its downlink transmit timing with the donor, so the tree looks synchronous to a UE.
• T_delta is the missing piece : The parent signals it in a MAC CE, because the child cannot measure the propagation delay and the parent offset by itself.
• Timing error accumulates with hops : Each node aligns to a parent that is itself aligned to a parent, so depth costs accuracy.
• Release 17 added Case 6 and Case 7 : They align an IAB-MT timing to an IAB-DU timing, which is what simultaneous operation needs.

What does each extra hop cost ?

I have seen the per-hop penalty quoted without its assumption attached more often than any other IAB number. You should check that assumption before reusing the figure. It changes completely depending on whether the backhaul shares a carrier with the access link.

Take the in-band case first, because that is the one people usually mean. Access and backhaul use the same carrier, and the node is half-duplex. Every packet therefore crosses the air once for each link on the path. A UE two hops from the donor needs three transmissions, not one.

The air time is shared, so the throughput falls in proportion. With H intermediate IAB nodes there are H+1 links on the path. The end-to-end rate is then roughly one divided by H+1, measured against a UE connected directly to the donor. One hop halves the rate. Two hops leave about a third of it.

Two things change that arithmetic. The first is an out-of-band deployment, where the backhaul uses a different carrier from the access link. The sharing disappears, and the limit becomes the capacity of the backhaul carrier instead. The second is the duplexing enhancement of Release 17, where an IAB-MT and an IAB-DU may operate at the same time under defined conditions.

Latency behaves differently from throughput, and the two are worth separating. Each hop adds a scheduling delay and a processing delay, and those delays add rather than divide. The specification sets no maximum hop count. Deployments still concentrate on one or two hops, because the throughput loss and the added latency both grow quickly.

Figure 5 plots the in-band case against hop count. The leftmost bar is a UE connected straight to the donor, which is the baseline every other bar is measured against.

Figure 5. The curve is one over the number of links on the path, and it only holds for the in-band case. Quote the number with that assumption attached.

• The rule of thumb is one over the number of links : With H intermediate nodes the path has H+1 links, and the end-to-end rate scales as 1/(H+1).
• The baseline is a direct connection to the donor : A hop penalty stated without that baseline cannot be checked or reused.
• It only holds in-band : With the backhaul on a separate carrier the sharing disappears, and the backhaul capacity becomes the limit.
• Latency adds, it does not divide : Every hop contributes its own scheduling and processing delay on top of the previous one.
• No hop limit is specified, but depth is expensive : Deployments concentrate on one or two hops because both curves worsen quickly.

How is IAB different from a repeater or an LTE relay ?

IAB is not the first attempt at relaying, and it is not the only option available today. Setting it beside the alternatives makes both its cost and its benefit easier to judge.

The dividing line is what the device does with the signal. A repeater amplifies and forwards it. It never decodes anything, so it amplifies the noise along with the wanted signal, and it cannot make a routing decision. A relay decodes the signal and transmits it again. That removes the accumulated noise and makes routing possible, but it costs processing time and a scheduling round at every hop.

IAB sits at the decode-and-forward end, and it goes further than the Release 10 LTE relay did. The LTE relay handled a single hop. IAB routes across several hops using BAP, and its DU half is an ordinary gNB-DU with an F1 interface to the donor-CU. That is why an IAB node integrates into the RAN rather than sitting beside it.

The Release 18 Network-Controlled Repeater is worth knowing about as the cheap alternative. It amplifies and forwards like a plain repeater, but the gNB controls its beams and its on and off state. It therefore avoids the per-hop latency that IAB pays, and it gives up routing, scheduling and any protection against accumulated noise.

• Amplify-and-forward against decode-and-forward is the real split : Repeaters amplify the noise with the signal. Relays and IAB nodes decode first, and pay processing time for it.
• IAB extends the LTE relay idea to several hops : The Release 10 relay handled one hop. BAP is what makes multi-hop routing possible in IAB.
• An IAB node is part of the RAN : Its DU half is a gNB-DU with F1 to the donor-CU, and not a separate appliance.
• The Network-Controlled Repeater is the low-cost option : No decoding and no routing, but the gNB steers it, and it adds almost no latency.

What changed in Release 17 and Release 18 ?

Release 16 defined IAB and left several problems to later work. Two follow-up releases are worth knowing about, because claims about what IAB can do usually assume one of them.

Release 17 is the enhanced IAB work. Topology adaptation improved, so a node can move to a new parent with less interruption to the UEs below it. Migration between two donor-DUs became possible, and so did partial migration between two donor-CUs. BAP gained local rerouting, which lets a node that loses its backhaul link divert traffic without waiting for the donor to reconfigure it. Duplexing enhancements allow an IAB-MT and an IAB-DU to operate at the same time under defined conditions.

Release 18 added mobile IAB. The node itself moves, usually mounted on a vehicle such as a bus or a train. The cell travels with the vehicle, which raises questions a fixed node never has to answer. Cell identity handling and the mobility of the UEs travelling alongside it are the substantial parts of that work.

The practical use of this list is version checking. Inter-donor migration and simultaneous IAB-MT and IAB-DU operation do not exist in a Release 16 node. A statement about IAB capability is therefore incomplete until the release it assumes is named.

• Release 16 is the baseline : Architecture, BAP, the three-phase integration, half-duplex resource types and Case 1 timing.
• Release 17 improved topology and duplexing : Inter-donor-DU and partial inter-donor-CU migration, BAP local rerouting, and simultaneous MT and DU operation.
• Release 18 let the node move : Mobile IAB puts the node on a vehicle, so the cell and its UEs travel together.
• Always name the release : Several capabilities people attribute to IAB in general belong to Release 17 or later.

Reference :

[1] The 5G Evolution:3GPP Releases 16-17 (5G Americas)

[2] RP-202343 - Revised WID: Integrated Access and Backhaul for NR (3GPP Work Item Description)

[3] TR 38.874 - NR; Study on Integrated Access and Backhaul

[4] TS 38.174 - Integrated Access and Backhaul (IAB) radio transmission and reception

[5] TS 38.340 - Backhaul Adaptation Protocol (BAP) specification

[6] 38.306 - NR;User Equipment (UE) radio access capabilities Section 4.2.15 IAB Parameters

[7] 38.300 NR and NG-RAN Overall description; Stage-2 - NR;User Equipment (UE) radio access capabilities - Section 4.7 Integrated Access and Backhaul

[8] 38.401 - NG-RAN; Architecture description Section 6.1.3, 6.1.4

[9] 38.213 - NR; Physical layer procedures for control, Section 14 (IAB-specific procedures, resource availability and timing)

[10] 38.331 - NR; Radio Resource Control (RRC) protocol specification (IAB-node indication and IAB-specific configuration)

YouTube

• mmWave Solutions for 5G Backhaul (Jul 2017) // Not IAB, but good to know of in comparison with IAB
• Integrated mmWave Access and Backhaul in 5G: Bandwidth Partitioning and Downlink Analysis (Nov 2017)
• 5G Mobile mmWave Technology Evolution (Mar 2020)
• Samsung A71 5G: affordable 5G. | Verizon Wireless IAB 5G Tech | 5G UWB | Airpods Pro Deal (Jul 2020)