Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 38.401  Word version:  17.1.1

Top   Top   Up   Prev   Next
1…   5…   6…   6.1.4   6.1.5…   6.2…   7…   8…   8.2…   8.2.2…   8.2.3…   8.2.4   8.2.5   8.3…   8.4…   8.4.4…   8.5…   8.9…   8.9.4…   8.9.6…   8.9.7…   8.10   8.11…   8.12…   8.13…   8.14…   8.15…   8.16…   8.17…   8.17.3…   8.17.4   8.18…   8.19…   8.19.2   8.19.3   8.19.4…   9…   A…

 

8.17.4  IAB Inter-CU Backhaul RLF recovery for single connected IAB-nodep. 99

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.
Copy of original 3GPP image for 3GPP TS 38.401, Fig. 8.17.4-1: IAB inter-CU backhaul RLF recovery procedure for an IAB-node in SA mode
Up
Step 1.
The IAB-MT of the IAB-node detects backhaul RLF.
Step 2.
The IAB-MT attempts RLF recovery by performing Random Access towards a new parent IAB-DU.
Step 3.
The IAB-MT undergoing RLF recovery sends an RRCReestablishmentRequest message to the new parent IAB-DU.
Step 4.
The new parent IAB-DU sends an INITIAL UL RRC MESSAGE to the new IAB-donor-CU, to convey the received RRCReestablishmentRequest message.
Step 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.
Step 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.
Step 7.
The new parent IAB-DU sends an RRCReestablishment message to the IAB-MT undergoing recovery.
Step 8.
The IAB-MT undergoing recovery sends an RRCReestablishmentComplete message to the new parent IAB-DU.
Step 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.
Step 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.
Step 11.
The new IAB-donor-CU triggers the path switch procedure for the IAB-MT undergoing recovery, if needed.
Step 12.
The new IAB-donor-CU sends UE CONTEXT RELEASE message to the initial IAB-donor-CU.
Step 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.
Step 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.
Step 15.
The new parent IAB-DU forwards the received RRCReconfiguration message to the IAB-MT undergoing recovery.
Step 16.
The IAB-MT undergoing recovery responds to the new parent IAB-DU with an RRCReconfigurationComplete message.
Step 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.
Step 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.
Up

Up   Top   ToC