Content for  TS 38.401  Word version:  18.0.0

The inter-CU backhaul RLF recovery procedure for IAB-nodes in SA mode enables recovery of an IAB-node to another parent node underneath a different IAB-donor-CU, when the IAB-MT of the IAB-node detects backhaul RLF. Figure 8.17.4-1 shows an example of the backhaul RLF recovery procedure for an IAB-node in SA mode. In this example, the IAB-node changes from its initial parent node to a new parent node, where the new parent node is served by a different IAB-donor-CU than that serving its initial parent node. In this procedure, the recovering IAB-node becomes a boundary IAB-node since the IAB-DU retains F1AP with the initial IAB-donor-CU while its IAB-MT obtains RRC connectivity with the new IAB-donor-CU.

Traffic offload for descendant nodes follows the same procedure as that of clause 8.17.3.2. The new IAB-donor-CU may request the modification of the L2 transport of the offloaded traffic in the new IAB-donor-CU's topology. The new IAB-donor-CU may further reconfigure the TNL addresses of the boundary IAB-node via RRC. The traffic offload due to inter-CU RLF recovery procedure for the boundary IAB-node and its descendant IAB-nodes can be fully revoked. In this case, the boundary IAB-MT is handed over in reverse direction, i.e., from the new IAB-donor-CU to the initial IAB-donor-CU, and the traffic of the boundary IAB-DU and the descendant IAB-DUs is routed again along the initial path used prior to BH RLF recovery. The new IAB-donor-CU can initiate the full revoking of traffic offload by executing the XnAP Handover Preparation procedure for the boundary IAB-MT towards the initial IAB-donor-CU. The initial IAB-donor-CU can initiate the full revoking of traffic offload in the same manner as described in clause 8.17.3.1 for the revoking initiated by the F1-terminating IAB-donor-CU. The initial IAB-donor-CU may request full or partial release of the offloaded traffic from the new IAB-donor-CU via the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message.