8.17.3 IAB Inter-CU Topology Adaptation

38.4013GPPArchitecture descriptionNG-RANRelease 17TS

8.17.3.1 IAB inter-CU topology adaptation procedure

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.

8.17.3.2 IAB inter-CU topology adaptation procedure with descendant IAB-node

Figure 8.17.3.2-1 shows an example of the topology adaptation procedure where the migrating IAB-MT is migrated from a source IAB-donor-CU to a target IAB-donor-CU, and where the migrating IAB-node has a descendant IAB-node which retains both its RRC connection and F1 connection with the source IAB-donor-CU.

Figure 8.17.3.2-1: IAB inter-CU topology adaptation procedure with descendant IAB-node

0. The topology adaptation procedure of clause 8.17.3.1 is performed for the migrating IAB-node.

1. 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 descendant IAB-node’s traffic to be offloaded. The message may include a request for new TNL address(es) for the descendant IAB-node(s), anchored at a target IAB-donor-DU. The source IAB-donor-CU includes an identifier of the migrating IAB-node in the request message. This could be performed in parallel with step 0 after the source IAB-donor-CU receives HANDOVER REQUEST ACKNOWLEDGE message, e.g., the context of the traffic to be offloaded for the migrating/descendant nodes and IP address request information could be contained in the same IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message.

2. The target IAB-donor-CU determines the target IAB-donor-DU, based on the identifier of the migrating IAB-node. The target IAB-donor-CU may configure or modify BH RLC channels and BAP-sublayer routing entries on the target path between the boundary 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.

3. The target IAB-donor-CU may obtain new TNL address(es) from the target IAB-donor-DU, based on the request for TNL address(es) received in step 1.

4. The target IAB-donor-CU responds with an IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message to the source IAB-donor-CU, to provide the mapping information for the traffic to be offloaded. The message includes the L2 info from the target IAB-donor-CU topology that is necessary to configure the migrating IAB-node with the BAP-sublayer routing, header-rewriting and BH RLC CH mapping entries of traffic indicated in step 1. The message includes the DSCP/IPv6 Flow Label values to be used for the DL traffic to be offloaded as indicated in step 1. The message may include the new TNL address(es) obtained in step 3, if any.

NOTE: The target IAB-donor-CU should select the same IAB-donor-DU in its IAB topology for all to-be-offloaded traffic, whose UL BH mappings received from the source IAB-donor-CU in step 1 share the same BAP address.

5. The source IAB-donor-CU configures the migrating IAB-node’s IAB-DU with the BAP-sublayer routing, header-rewriting and BH RLC CH mapping entries of the migrating IAB-node.

6. The source IAB-donor-CU sends a DL RRC MESSAGE TRANSFER message to the descendant IAB-node’s parent IAB-DU, which includes an RRCReconfiguration message for the descendant IAB-MT. The RRC configuration may include the new TNL addresses received in step 4. If needed, the source IAB-donor-CU may also provide a new default UL mapping which includes a default BH RLC channel and a default BAP Routing ID on the target path, to the descendant nodes via RRCReconfiguration message.

7. The descendant IAB-node’s parent IAB-DU forwards the received RRCReconfiguration message to the descendant IAB-MT.

8. The descendant IAB-MT responds to the migrating IAB-node’s IAB-DU with an RRCReconfigurationComplete message.

9. The migrating IAB-node’s IAB-DU sends an UL RRC MESSAGE TRANSFER message to the source IAB-donor-CU, to convey the received RRCReconfigurationComplete message.

10. If needed, the source IAB-donor-CU configures UL BH mappings on the descendant node and BAP-sublayer routing entries between the descendant node and the migrating IAB-node. This step may be performed at an earlier stage, e.g., immediately after step 4.

11. The F1-C connections and F1-U tunnels are switched to use the descendant IAB-node’s new TNL address(es), if any, as described in Steps 15 and 19 of the inter-CU topology adaptation procedure in clause 8.17.3.1.

12. The source IAB-donor-CU sends an IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message to the target IAB-donor-CU, to modify the context of the descendant IAB-node’s offloaded traffic. The message may include the DL TNL address information received in step 11 that is necessary for the target IAB-donor-CU to configure or modify DL mappings on the target IAB-donor-DU.

13. The target IAB-donor-CU responds with an IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message to the source IAB-donor-CU.

14. The of steps above may be repeated, if needed, for the source IAB-donor-CU to request addition, modification or release of the offloaded traffic pertaining to the descendant IAB-node. 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 trigger the modification of the L2 transport of the offloaded traffic in the target IAB-donor-CU’s topology using the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message. Based on this message, the source IAB-donor-CU may reconfigure the UL BH mappings on the descendant nodes, the routing entries and BH RLC channel mappings on the migrating node and the descendant nodes, and the BAP header rewriting entries on the migrating node, and acknowledges the modification via the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. The target IAB-donor-CU may further provide updated TNL address information for the descendant IAB-node to the source IAB-donor-CU.

The full or partial release or revoking of traffic offload pertaining to the descendant IAB-nodes and their served UEs follows the same procedure as defined for the partial migration in clause 8.17.3.1.