8.17.4 IAB Inter-CU Backhaul RLF recovery for single connected IAB-node

38.4013GPPArchitecture descriptionNG-RANRelease 17TS

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.

Figure 8.17.4-1: IAB inter-CU backhaul RLF recovery procedure for an IAB-node in SA mode

1. The IAB-MT of the IAB-node detects backhaul RLF.

2. The IAB-MT attempts RLF recovery by performing Random Access towards a new parent IAB-DU.

3. The IAB-MT undergoing RLF recovery sends an RRCReestablishmentRequest message to the new parent IAB-DU.

4. The new parent IAB-DU sends an INITIAL UL RRC MESSAGE to the new IAB-donor-CU, to convey the received RRCReestablishmentRequest message.

5. The new IAB-donor-CU retrieves the UE Context for the IAB-MT undergoing recovery, through the XnAP Retrieve UE Context procedure. The initial IAB-donor-CU may include the TNL address information of the IAB-node undergoing recovery in the RRC container of the RETRIEVE UE CONTEXT RESPONSE message.

6. The new IAB-donor-CU sends a DL RRC MESSAGE TRANSFER message to the new parent IAB-DU, to convey the generated RRCReestablishment message.

7. The new parent IAB-DU sends an RRCReestablishment message to the IAB-MT undergoing recovery.

8. The IAB-MT undergoing recovery sends an RRCReestablishmentComplete message to the new parent IAB-DU.

9. The new parent IAB-DU sends an UL RRC MESSAGE TRANSFER message to the new IAB-donor-CU, to convey the received RRCReestablishmentComplete message.

10. The new IAB-donor-CU triggers the UE Context Setup procedure toward the new parent IAB-DU, to create the UE context for the IAB-MT undergoing recovery and to set up one or more bearers. These bearers can be used by the IAB-MT undergoing recovery for its own signalling, and, optionally, data traffic.

11. The new IAB-donor-CU triggers the path switch procedure for the IAB-MT undergoing recovery, if needed.

12. The new IAB-donor-CU sends UE CONTEXT RELEASE message to the initial IAB-donor-CU.

NOTE: The XnAP UE IDs of the boundary IAB-MT are retained at initial IAB-donor-CU and new IAB-donor-CU as long as the recovery path is used for transport of traffic between the IAB-node undergoing recovery and the initial IAB-donor-CU.

13. The initial IAB-donor-CU may release the BH RLC channels and BAP-sublayer routing entries on the initial path between the initial parent IAB-node and the initial IAB-donor-DU.

14. The new IAB-donor-CU sends a DL RRC MESSAGE TRANSFER message to the new parent IAB-DU, which includes an RRCReconfiguration message for the IAB-MT undergoing recovery. The RRC configuration may include new TNL addresses anchored at the new IAB-donor-DU. The RRC configuration may further include a BAP address for the recovery IAB-node in the new IAB-donor-CU’s topology, default BH RLC channel and a default BAP routing ID configuration for UL F1-C/non-F1 traffic mapping on the recovery path.

15. The new parent IAB-DU forwards the received RRCReconfiguration message to the IAB-MT undergoing recovery.

16. The IAB-MT undergoing recovery responds to the new parent IAB-DU with an RRCReconfigurationComplete message.

17. The new parent IAB-DU sends an UL RRC MESSAGE TRANSFER message to the new IAB-donor-CU, to convey the received RRCReconfigurationComplete message.

18. The remaining part of the procedure follows the steps 14-20 of the inter-CU topology adaptation procedure defined in clause 8.17.3.1.

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.