Section: 8.2.3.1 Intra-CU topology adaptation procedure in SA
Content: During the intra-CU topology adaptation in SA, both the source and the target parent node are served by the same IAB-donor-CU. The target parent node may use a different IAB-donor-DU than the source parent node. The source path may have common nodes with the target path. Figure 8.2.3.1-1 shows an example of the topology adaptation procedure, where the target parent node uses a different IAB-donor-DU than the one used by the source parent node. Figure 8.2.3.1-1: IAB intra-CU topology adaptation procedure 1. The migrating IAB-MT sends a MeasurementReport message to the source parent node IAB-DU. This report is based on a Measurement Configuration the migrating IAB-MT received from the IAB-donor-CU before. 2. The source parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received MeasurementReport. 3. The 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 set up one or more bearers. These bearers can be used by the migrating IAB-MT for its own signalling, and, optionally, data traffic. 4. The target parent node IAB-DU responds to the IAB-donor-CU with a UE CONTEXT SETUP RESPONSE message. 5. The IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node IAB-DU, which includes a generated RRCReconfiguration message. The RRCReconfiguration message includes a default BH RLC channel and a default BAP Routing ID configuration for UL F1-C/non-F1 traffic mapping on the target path. It may include additional BH RLC channels. This step may also include allocation of TNL address(es) that is (are) routable via the target IAB-donor-DU. The new TNL address(es) may be included in the RRCReconfiguration message as a replacement for the TNL address(es) that is (are) routable via the source IAB-donor-DU. In case IPsec tunnel mode is used to protect the F1 and non-F1 traffic, the allocated TNL address is outer IP address. The TNL address replacement is not necessary if the source and target paths use the same IAB-donor-DU. The Transmission Action Indicator in the UE CONTEXT MODIFICATION REQUEST message indicates to stop the data transmission to the migrating IAB-node. 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 IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message. 8. A Random Access procedure is performed 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 IAB-donor-CU to convey the received RRCReconfigurationComplete message. Also, uplink packets can be sent from the migrating IAB-MT, which are forwarded to the IAB-donor-CU through the target parent node IAB-DU. These UL packets belong to the IAB-MT’s own signalling and, optionally, data traffic. 11. The IAB-donor-CU configures BH RLC channels and BAP-sublayer routing entries on the target path between the target parent 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 be performed at an earlier stage, e.g. immediately after step 3, or before step 3. The IAB-donor-CU may establish additional BH RLC channels to the migrating IAB-MT via RRC message. 12. The F1-C connections are switched to use the migrating IAB-node’s new TNL address(es), IAB-donor-CU updates the UL BH information associated to each GTP-tunnel to migrating IAB-node. This step may also update UL FTEID and DL FTEID associated to each GTP-tunnel. All F1-U tunnels are switched to use the migrating IAB-node’s new TNL address(es). This step may use non-UE associated signaling in E1 and/or F1 interface to provide updated UP configuration for F1-U tunnels of multiple connected UEs or child IAB-MTs. The IAB-donor-CU may also update the UL BH information associated with non-UP traffic. Implementation must ensure the avoidance of potential race conditions, i.e. no conflicting configurations are concurrently performed using UE-associated and non-UE-associated procedures. In case IPsec tunnel mode is used for TNL protection, the 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 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 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 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. 13. The IAB-donor-CU sends a UE CONTEXT RELEASE COMMAND message to the source parent node IAB-DU. 14. The source parent node IAB-DU releases the migrating IAB-MT’s context and responds to the IAB-donor-CU with a UE CONTEXT RELEASE COMPLETE message. 15. The IAB-donor-CU releases BH RLC channels and BAP-sublayer routing entries on the source path between source parent IAB-node and source IAB-donor-DU. NOTE: In case that the source path and target path have common nodes, the BH RLC channels and BAP-sublayer routing entries of those nodes may not need to be released in Step 15. Steps 11, 12 and 15 should also be performed for the migrating IAB-node’s descendant nodes, as follows: The IAB-donor-CU may allocate new TNL address(es) that is (are) routable via the target IAB-donor-DU to the descendent nodes via RRCReconfiguration message. If needed, the IAB-donor-CU may also provide a new default UL mapping which includes a default BH RLC channel and a default BAP Routing ID for UL F1-C/non-F1 traffic on the target path, to the descendant nodes via RRCReconfiguration message. If needed, the IAB-donor-CU configures BH RLC channels, BAP-sublayer routing entries and BH RLC channel mappings on the target path for the descendant nodes in the same manner as described for the migrating IAB-node in step 11. The descendant nodes switch their F1-C connections and F1-U tunnels to new TNL addresses that are anchored at the new IAB-donor-DU, in the same manner as described for the migrating IAB-node in step 12. Based on implementation, these steps can be performed after or in parallel with the handover of the migrating IAB-node. To enable performing these steps in parallel, the IAB-donor-CU sends the RRCReconfiguration message with the new TNL address(es) and the new default BAP configuration to the descendent node while the migrating IAB-MT is still connected with source parent node, for example, before Step 5. In this case, the UE CONTEXT MODIFICATION REQUEST message carrying this RRCReconfiguration message includes a conditional delivery indication for the descendent node’s parent IAB-DU. Based on this indication, the parent IAB-DU retains the RRCReconfiguration message until the conditions for delivery are met, as specified in TS 38.473[ NG-RAN; F1 Application Protocol (F1AP) ]  [4]. The IAB-donor-CU may further configure the BAP-sublayer routing entries on the migrating IAB-node and the descendant nodes while the migrating IAB-MT is still connected with the source parent node. NOTE: In upstream direction, in-flight packets between the source parent node and the IAB-donor-CU can be delivered even after the target path is established. NOTE: In-flight downlink data in the source path may be discarded, up to implementation via the NR user plane protocol (TS 38.425[ NG-RAN; NR user plane protocol ]  [24]). NOTE: The IAB-donor-CU can determine the unsuccessfully transmitted downlink data over the backhaul link by implementation.