Section: 8.17.3.1 IAB inter-CU topology adaptation procedure
Content: During the inter-CU topology adaptation for a single-connected IAB-node, the IAB-MT migrates from an old parent node to a new parent node, where the old and the new parent nodes are served by different IAB-donor-CUs. Without loss of generality, the old parent node is referred to as source parent node, and the new parent node is referred to as target parent node. Figure 8.17.3.1-1 shows an example of the topology adaptation procedure, where the IAB-MT is migrated from a source IAB-donor-CU to a target IAB-donor-CU. In this procedure, the migrating IAB-node becomes a boundary IAB-node since its IAB-DU retains F1AP with the source IAB-donor-CU while its IAB-MT obtains RRC connectivity with the target IAB-donor-CU. Figure 8.17.3.1-1: IAB inter-CU topology adaptation procedure 1. The source IAB-donor-CU sends an Xn HANDOVER REQUEST message to the target IAB-donor-CU . This message may include the migrating IAB-node’s TNL address information in the RRC container. 2. The target IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node IAB-DU, to create the UE context for the migrating IAB-MT and to set up the bearers, which the migrating IAB-MT uses for its signaling, and, optionally, data traffic. 3. The target parent node IAB-DU responds to the target IAB-donor-CU with a UE CONTEXT SETUP RESPONSE message. 4. The target IAB-donor-CU performs admission control and provides the new RRC configuration as part of the HANDOVER REQUEST ACKNOWLEDGE message. The RRC configuration includes a BAP address for the boundary node in the target IAB-donor-CU’s topology, a default BH RLC channel and a default BAP routing ID configuration for UL F1-C/non-F1 traffic mapping on the target path. The RRC configuration may include the new TNL address(es) anchored at the target IAB-donor-DU for the migrating node. 5. The source IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node IAB-DU, which includes the received RRCReconfiguration message from the target IAB-donor-CU. 6. The source parent node IAB-DU forwards the received RRCReconfiguration message to the migrating IAB-MT. 7. The source parent node IAB-DU responds to the source IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message. 8. The migrating IAB-MT performs a random access procedure at the target parent node IAB-DU. 9. The migrating IAB-MT responds to the target parent node IAB-DU with an RRCReconfigurationComplete message. 10. The target parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the target IAB-donor-CU, to convey the received RRCReconfigurationComplete message. 11. The target IAB-donor-CU triggers the path switch procedure for the migrating IAB-MT, if needed. 12. The target IAB-donor-CU sends UE CONTEXT RELEASE message to the source IAB-donor-CU. NOTE: The XnAP UE IDs of the migrating node are retained at target and source IAB-donor-CU as long as the target path is used for transport of traffic between the migrating node and the source IAB-donor-CU. 13. The source IAB-donor-CU may release BH RLC channels and BAP-sublayer routing entries on the source path between source parent IAB-node of the migrating IAB-node and the source IAB-donor-DU. 14. The target IAB-donor-CU configures BH RLC channels and BAP-sublayer routing entries on the target path between the migrating IAB-node and target IAB-donor-DU, as well as DL mappings on the target IAB-donor-DU for the migrating IAB-node’s target path. These configurations support the transport of F1-C traffic on the target path. 15. The F1-C connection between the migrating IAB-node and the source IAB-donor-CU are switched to the target path using the new TNL address information of the migrating IAB-node. The migrating IAB-node may report the new TNL address information it wants to use for F1-U traffic to the source IAB-donor-CU, via the gNB-DU CONFIGURATION UPDATE message. In case IPsec tunnel mode is used for TNL protection, the migrating IAB-node may use MOBIKE (IETF RFC 4555 [29]) to migrate the IPsec tunnel to the new IP outer addresses. After the completion of the MOBIKE procedure, the migrating IAB-DU initiates an F1AP gNB-DU Configuration Update procedure from which the IAB-donor-CU can conclude whether the existing inner IP address(es) (e.g., for SCTP association) and the DL F-TEID can be reused. If new TNL addresses for F1-C traffic are configured, new SCTP association(s) between the migrating IAB-node and the F1-terminating IAB-donor-CU may be established using the new TNL address information of the migrating IAB-node. The migrating IAB-node sends an F1AP gNB-DU CONFIGURATION UPDATE message to the F1-terminating IAB-donor-CU, which may include new (outer) IP addresses and corresponding new (inner) IP address for the F1-U traffic to be switched to the target path. 16. The source IAB-donor-CU sends an IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message to the target IAB-donor-CU, to provide the context of the traffic to be offloaded. The message may include the new DL TNL address information necessary for the target IAB-donor-CU to configure or modify DL mappings on the target IAB-donor-DU. 17. The target IAB-donor-CU may configure or modify BH RLC channels and BAP-sublayer routing entries on the target path between the migrating IAB-node and target IAB-donor-DU, as well as DL mappings on the target IAB-donor-DU for the migrating IAB-node’s target path. These configurations may support the transport of UP and non-UP traffic on the target path. 18. The target IAB-donor-CU responds to the source IAB-donor-CU with an IAB Transport Migration Management Response message, to provide the mapping information for the traffic to be offloaded. The message includes the L2 info that is used in the target IAB-donor-CU’s topology and necessary to configure the migrating IAB-node with the UL mappings of traffic indicated in step 16. The message includes the DSCP/IPv6 Flow Label values used to configure the DL mappings of traffic indicated in step 16. 19. The F1-U connections of the migrating IAB-node with the source IAB-donor-CU are switched to use the migrating IAB-node’s new TNL address(es). The source IAB-donor-CU provides to the IAB-DU of the migrating IAB-node the updated UL BH information for the traffic indicated in step 16, based on the UL BH information received from the target IAB-donor-CU in step 18. The source IAB-donor-CU may also update the UL BH information associated with non-UP traffic. This step may use UE associated signaling or non-UE associated signaling in E1 and/or F1 interface. Implementation must ensure the avoidance of potential race conditions, i.e., that no conflicting configurations are concurrently performed using UE-associated and non-UE-associated procedures. 20. The steps 16 to 19 may be repeated, if needed, where the source IAB-donor-CU can request the offload of further traffic, or the modification or release of offloaded traffic. The target IAB-donor-CU can fully or partially reject addition or modification requests by the source IAB-donor-CU. The target IAB-donor-CU may request the modification of the L2 transport for the offloaded traffic in the target IAB-donor-CU’s topology using the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message. The source IAB-donor-CU reconfigures the UL BH mappings accordingly, and acknowledges the modification via the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. The target IAB-donor-CU may further reconfigure the TNL addresses of the migrating IAB-node via RRC. The traffic offload through the inter-CU topology adaptation procedure for the migrating IAB-node can be fully revoked. The non-F1-terminating IAB-donor-CU can initiate the full revoking of traffic offload by executing the XnAP Handover Preparation procedure for the migrating IAB-MT. After the migrating IAB-MT is handed over in reverse direction, i.e., from the non-F1-terminating IAB-donor-CU to the F1-terminating IAB-donor-CU, the traffic of the migrating IAB-node’s IAB-DU is routed again along the former source path. The F1-terminating IAB-donor-CU can initiate the full revoking of traffic offload by requesting the release of all offloaded traffic from the non-F1-terminating IAB-donor-CU by sending the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST to the non-F1-terminating IAB-donor-CU. This message may trigger the XnAP Handover Preparation procedure for the migrating IAB-MT towards the F1-terminating IAB-donor-CU. The F1-terminating IAB-donor-CU may request full or partial release of the offloaded traffic from the non-F1-terminating IAB-donor-CU via the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message.