TW202420852A - Migration of nodes in an iab communication system - Google Patents

Abstract

Methods and apparatus for use in a migration process in which a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node is migrated from one IAB topology managed by a source IAB donor Central Unit, CU, to another IAB topology managed by a target IAB donor CU are disclosed. A method at the source IAB donor CU comprises determining the DU of the IAB node is to be migrated from the one IAB topology of the source IAB donor CU to the another IAB topology of the target IAB donor CU; sending, to the IAB node, a request for establishing a F1 connection between the IAB node and the target IAB donor CU. A method at the IAB node comprises receiving, from the source IAB donor CU, a request for establishing a F1 connection between a target IAB donor CU and the IAB node; sending, to the target IAB donor CU, a F1 setup request for requesting set up of the F1 connection.

Description

Node Migration in IAB Communication System

The present invention generally relates to methods used in a procedure for migrating nodes and traffic between mobile integrated access and backhaul (IAB) topologies in a wireless communication system involving IAB nodes. In particular, the present invention relates to methods used in a migration procedure in which a distributed unit (DU) of an IAB node (e.g., a mobile IAB node) migrates between IAB topologies.

Wireless communication systems are commonly deployed to address a wide range of applications, from mobile broadband, massive machine-type communications to ultra-reliable low latency communications (URLLC). Such systems allow multiple user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) through one or more base stations. The base stations are typically wired (e.g., via optical fiber) to the core network, forming an intermediate network called the backhaul (BH). Examples of such wireless multi-access communication systems include systems based on the 3rd Generation Partnership Project (3GPP-RTM) standards, such as the 4th Generation (4G) Long Term Evolution (LTE) or the more recent 5th Generation (5G) New Radio (NR) systems, or systems based on the IEEE 802.11 standards, such as WiFi. Due to the increase in the number of users and higher throughput requirements, the demand for network densification has increased. Faced with the high deployment cost and time of wired backhaul networks for network densification, 3GPP has proposed a wireless backhaul in 5G NR Release 16, also known as Integrated Access and Backhaul (IAB), in which part of the wireless (i.e., radio) spectrum is used for backhaul connections to base stations instead of using optical fibers. Wireless backhaul communications (between base stations) can use the same radio resources as access communications (between base stations and UEs). IAB has proven to be a competitive alternative to fiber-based backhaul in dense or hard-to-cover areas, as it allows for scalable and fast installations without the burden of cabling base stations. IAB will most likely operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rates. However, mmWave is known to suffer from strong attenuation of signal strength in some weather conditions (rain, fog) and can be blocked when there are obstacles in the path between the transmitter and receiver. To cope with these potential radio link failures, topological redundancy can be provided within the IAB framework, where multiple data paths are set up between the IAB base station directly connected to the core network (also known as the "IAB donor") and the IAB base station serving the UE (also known as the "access IAB node" of the UE). Each of the multiple paths between the IAB donor and the access IAB node may involve multiple intermediate IAB base stations (also known as IAB nodes), thereby forming alternative data paths within the multi-hop IAB topology. Furthermore, 3GPP has considered inter-donor redundancy, where an IAB node (called a border IAB node) has access to two different parent nodes connected to two different IAB donors, where each of the IAB donors manages a different IAB topology (also called an IAB network). The border IAB node, even though belonging to a single IAB topology, i.e., belonging to a single IAB donor for configuration and management purposes, is thus able to route packets from a first IAB topology managed by the first IAB donor to a second IAB topology managed by the second IAB donor. The advantage of such inter-donor redundancy is the ability of the first IAB donor to perform offloading by routing some of its packets through the second IAB topology, thus alleviating congestion problems or overcoming radio link failure problems that may occur in the first IAB topology. There are other situations where an IAB node becomes a boundary node. For example, in the case of a partial migration of an IAB node determined by an IAB donor, where the mobile terminal (MT) of the IAB node becomes connected to a single parent IAB node belonging to another IAB topology controlled by another IAB donor. This situation can also occur in the case of an IAB node that has experienced a radio link failure (RLF) and has recovered through a parent IAB node belonging to another IAB topology. In those situations, the migrated IAB node and its potential child IAB nodes still belong to the initial IAB topology, and this partial migration can be called MT migration. To ensure that traffic can be routed through other IAB topologies, MT migration should be followed by traffic migration, where traffic associated with a border node and its child IAB nodes is routed through other IAB topologies up to the border node (i.e., the migrated IAB node). Fixed IAB nodes should only require a single MT migration. In practice, a backhaul link (defined between two consecutive IAB nodes in a wireless backhaul) can experience radio failures due to fluctuations in radio conditions, and for non-moving IAB nodes, it should be a temporary condition with possible link recovery after some time. Therefore, there is no need for these fixed IAB nodes to perform multiple MT migrations within the same IAB topology or towards another IAB topology, and the transmission and handling of multiple protocol messages can be avoided. For the same reason, fixed nodes do not require migration of the distributed unit (DU) of the IAB node, thereby leaving the control of the IAB node to a new IAB donor. In addition, note that this DU migration (which can be called a full migration) also involves the handover of UEs served by the migrating mobile IAB node. Typically, urban environments are characterized by a high density of users along with the presence of a large number of vehicles (e.g., public/private passenger transportation, freight delivery, food trucks, etc.). Some of these vehicles (e.g., buses, trams, trains) may have predictable routes and a large number of co-located UEs (i.e., passenger devices). 3GPP is considering that these vehicles could provide opportunities to increase network coverage and connect to UEs inside the vehicle or even close to the vehicle by installing these vehicular base stations (or base station elements) acting as mobile repeaters on the vehicle. These mobile repeaters will rely on 5G wireless backhaul (usually IAB or Integrated Access and Backhaul) to connect to a fixed donor device. Therefore, building on the fixed IAB foundation of Release 16 and 17, 3GPP is now considering mobile IAB systems and architectures as part of the Release 18 framework to address scenarios focused on mobile IAB nodes installed in vehicles (such as buses, trains, taxis). In such scenarios, the mobile IAB nodes may be referred to as vehicle mounted repeaters (VMRs), providing 5G coverage/capability to onboard and/or surrounding UEs. The technical benefits of using a VMR include, among other things, the ability of the VMR to provide good radio link conditions to nearby UEs. In addition, vehicle mounted IAB nodes are expected to have better RF/antenna capabilities and less stringent power/battery constraints than repeater UEs compared to solutions using UEs as repeaters (i.e., sidelink repeating solutions). For mobile IAB nodes, it may be worthwhile to perform multiple MT migrations or DU migrations, because as mobile IAB nodes move around, the connection to the parent IAB node belonging to the first IAB topology may not occur for a long time or may never occur again in the case where the mobile IAB node moves far away from the parent IAB node. Furthermore, for flexible IAB network management, MT and DU migrations should be de-correlated, meaning that DU migration of an IAB node may occur independently before or after one or several MT migrations of this IAB node. Furthermore, DU migration of an IAB node may be performed towards an IAB donor different from the IAB donor associated with the MT of this IAB node. Therefore, some new mechanism is needed to provide this flexibility by supporting DU migration of an IAB node towards any other donor CU and decoupling the MT migration(s) of that IAB node.

According to a first aspect of the present invention, a method for use in a migration procedure is provided, in which a distributed unit (DU) of an integrated access backhaul (IAB) node is migrated from an IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, and the method comprises at the source IAB donor CU: determining that the DU of the IAB node is to be migrated from one IAB topology of the source IAB donor CU to the other IAB topology of the target IAB donor CU; and sending a request for establishing an F1 connection between the IAB node and the target IAB donor CU to the IAB node. According to a second aspect of the present invention, a method is provided for executing at an IAB node to be used in a migration procedure in which a DU of the IAB node is migrated from an IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, as described in the attached patent scope. According to a third aspect of the present invention, a method is provided for executing at a target IAB donor CU to be used in a migration procedure in which a DU of the IAB node is migrated from an IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, as described in the attached patent scope. Thus, by sending a request to the IAB node to establish an F1 connection between the IAB node and the target IAB donor CU, the source F1 donor CU (e.g., source IAB donor CU) facilitates DU migration of the IAB node with or without MT(s) migration. Furthermore, in response to receiving the request to establish an F1 connection, the IAB node may identify (e.g., via identification information sent by the source donor CU or by determining that a non-F1 donor CU is the target donor CU when no identification information is sent by the source donor CU) the target donor CU so that the UE served by the IAB node can be handed over to the target donor CU. The non-F1 (terminal) donor CU is also referred to as an RRC (terminal) donor CU. According to the fourth aspect of the present invention, a device for an IAB node of an IAB communication system is provided, as described in the attached patent scope. According to the fifth aspect of the present invention, a device for an IAB donor CU (e.g., a source IAB donor CU or a target IAB donor CU) of an IAB communication system is provided, as described in the attached patent scope. According to another aspect of the present invention, a method for use in a migration procedure is provided. In the migration procedure, a distributed unit (DU) of an integrated access backhaul (IAB) node is migrated from an IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU. The method includes: determining by the source IAB donor CU that the DU of the IAB node is to be migrated from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU; sending by the source IAB donor CU a message for migrating the DU of the IAB node from the IAB topology of the source IAB donor CU to the target IAB donor CU; A request to establish an F1 connection between an IAB node and the target IAB donor CU is sent to the IAB node; after receiving the request to establish the F1 connection, the IAB node sends an F1 setup request for requesting setup of the F1 connection to the target IAB donor CU; after receiving the F1 setup request for requesting setup of the F1 connection from the IAB node, the target IAB donor CU sends a response to the IAB node, the response including a request for one or more cells to be activated for a second logical DU entity for the IAB node. The present invention is further characterized in other independent and dependent request items. In the following, source and target will be referred to for different elements (such as nodes/topologies). However, it should be understood that the terms first and second can be used instead of source and target. Any features in one aspect of the present invention may be applied to other aspects of the present invention in any appropriate combination. Specifically, the method aspect may be applied to the device/apparatus/unit aspect, and vice versa. In addition, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be interpreted accordingly. For example, according to other aspects of the present invention, a computer program comprising instructions is provided, which, when executed by a processing unit, causes the processing unit to execute any of the above aspects or exemplary methods, and a computer-readable storage medium carrying the computer program.

FIG. 1 illustrates an exemplary wireless communication system 100, particularly a mobile wireless communication system, such as a fifth generation (5G) new radio (NR) system including a wireless integrated access and backhaul network supporting mobile IAB nodes. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it should be understood that the present invention is not intended to be limited to a 5G NR system and may be used in any wireless communication system having a mobile base station. Specifically, the following description mainly uses the specific term 5G, but it should be understood that this term also applies to components or processes that perform equivalent functions in other communication systems. The system 100 includes a plurality of UEs (user equipment) 132, 133, 131 and 134, a remote core network 110, a master base station 120 and two integrated access and backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes), and a mobile integrated access and backhaul (IAB) station 123 installed on a vehicle 105 (e.g., bus, train, taxi, car, etc.). The master base station 120, also referred to as an IAB donor 120, is connected to the core network 110 via a wired link 101, preferably an optical fiber or any other wired method. In embodiments and examples of embodiments of the present invention, the IAB donor 120 is a 5G NR gNB with additional functionality to support the IAB feature, as defined in the 3GPP TS 38.300 V17.2.0 specification document. In order to expand the network coverage of the IAB donor 120 and reach the remote UEs 132, 133 and 131, the operator has installed IAB stations 121 and 122, also referred to as IAB nodes 121 and 122. By acting as relay nodes between the IAB donor 120 and the UEs 132 and 133, the IAB nodes 121 and 122 allow to overcome the reachability issues caused by the presence of the building 108, which is a barrier to radio wave propagation and, therefore, a barrier to radio wave propagation for direct connection and further communication between the UE and the IAB donor 120. This is especially true when the communication between the IAB donor 120 and the UEs 132 and 133 operates at millimeter wave frequencies that are highly sensitive to shadowing phenomena. The IAB donor 120 also serves the UE 134 that is directly connected to it. The mobile IAB station 123 (also referred to as mobile IAB node 123 or mIAB node 123) is an IAB node installed on the vehicle 105 and provides network coverage and capacity expansion, allowing the IAB donor 120 to reach onboard remote UEs, such as remote UE 135, as well as UEs surrounding the IAB node 123 or UEs adjacent to the IAB node 123, such as remote UE 136. The IAB donor 120 and the IAB nodes 121, 122, and 123 thus form a backhaul network or IAB network, or IAB topology, which accommodates UEs 132, 133, 131, 134, 135, and 136. The terms IAB network and IAB topology are used interchangeably hereinafter. The Integrated Access and Backhaul (IAB) specification is distributed in multiple 3GPP standard documents, including: - TS 38.300 RAN architecture (V17.2.0), - TS 38.321 MAC protocol (V17.2.0), - TS 38.331 Radio Resource Control (RRC) protocol (V17.2.0), - TS 38.340 Backhaul Adaptation Protocol Layer (V17.2.0), - TS 38.401 RAN architecture (V17.2.0), - TS 38.423 Xn application protocol (V17.2.0) - TS 38.473 F1 application protocol (V17.2.0). Since IAB donor 120 and IAB nodes 121, 122, and 123 are connected to UEs 134, 131, 132, 133, 135, and 136, respectively, they are considered as access IAB nodes for their respective connected UEs. IAB donor 120 is a logical node that provides NR-based radio backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed units (DU or gNB-DU functionality). The IAB donor CU or donor CU (hereinafter also referred to as IAB donor CU or IAB donor CU) carries higher layer protocols such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols for controlling the operation of one or more DUs and each of one or more IAB donor DUs or donor DUs (hereinafter also referred to as IAB donor DUs or IAB donor DUs) includes lower layer protocols such as RLC, MAC and physical layer protocols. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be remote from one another or may be located in the same physical device. The gNB-DU function is defined in 3GPP TS 38.401. Its purpose is to terminate the NR access interface to the UE and the next relay IAB node, and to terminate the F1 protocol to the IAB donor gNB-CU functionality, as shown in Figures 2a and 2b discussed below. The IAB node, which can serve multiple radio sectors, is wirelessly backloaded to the IAB donor 120 via one or more relays on the intermediate IAB node. They form a directed acyclic graph (DAG) topology with the IAB donor as the root. Each IAB node consists of an IAB-DU (IAB distributed unit) and an IAB-MT (IAB mobile terminal). The gNB-DU function on the IAB node is also called IAB-DU, and it allows downstream (towards the UE) connection to the next relay IAB or to the UE. IAB-MT functionality includes, for example, physical layer, layer 2, RRC and non-access layer (NAS) functionality to connect to the gNB-DU of the upstream IAB node (including the IAB donor 120, which in this case is connected to the IAB donor gNB-CU and therefore to the core network 110, for example for initialization, registration and configuration). In this DAG topology, the neighbor nodes on the IAB-DU interface are called child nodes and the neighbor nodes on the IAB-MT interface are called parent nodes. The direction towards the child node is further referred to as downstream, while the direction towards the parent node is referred to as upstream. The IAB donor 120 (e.g., the IAB donor CU) performs centralized resource, topology and routing management for the entire IAB topology. This includes configuring the IAB nodes according to the network topology, for example, in order to perform appropriate routing of data packets. Figures 2a and 2b schematically illustrate the stacking of some protocol layers involved in IAB operation. The F1 interface supports the exchange of messaging information (e.g., control traffic) between endpoints, and the transmission of data to each endpoint (e.g., user traffic transmission). From a logical point of view, the F1 interface is a point-to-point interface between endpoints. In 5G NR, F1-C is the functional interface between the IAB donor CU and the IAB node DU (e.g., IAB node 2) in the control plane (CP) and between the IAB donor CU and the IAB donor DU. F1-U is the functional interface of the same unit in the user plane (UP). F1-C and F1-U are represented by reference numeral 212 in Figure 2a. In this example, F1-U and F1-C are transmitted via two backhaul relays (from IAB donor to IAB node 1 and then from IAB node 1 to IAB node 2). In the user plane, block 210 at IAB donor CU and IAB node DU refers to the GTP-U layer, while block 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. GTP-U tunnels are used to carry encapsulated PDUs and messaging messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for more details), here block 210 of IAB donor CU and IAB node DU. The well-known User Data Protocol (UDP) is a transport layer protocol that provides the best possible data block service and is adapted for use with the IP protocol. In the control plane, box 210 represents the F1AP (F1 Application Protocol) layer, and box 211 represents the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS 38.473 and TS 38.401) provides messaging services between the IAB donor CU and the IAB node DU, or UE-related services. These services are, for example, initialization, configuration, etc. The well-known SCTP layer provides reliable, in-order message transmission through congestion control. F1-U and F1-C rely on the IP transport layer between the IAB donor CU and the IAB node DU, as defined in 3GPP TS 38.401. Transport between the IAB donor DU and the IAB donor CU also uses the IP transport layer over various media (e.g., wire or optical fiber), such as when the IAB donor CU is remote to the IAB donor DU, or when the local IAB donor CU and the IAB donor DU are virtualized on the same physical machine. IAB-specific transport between the IAB donor CU and the IAB donor DU is defined in 3GPP TS 38.401. L1 and L2 in Figure 2a represent the transport layer and physical layer, respectively, appropriate to the media used. The IP layer may also be used for non-F1 traffic, such as operation, management and maintenance traffic. In wireless backhaul, the IP layer itself is carried over the Backhaul Adaptation Protocol (BAP) sublayer, which enables multi-hop routing. The BAP sublayer is specified in TS 38.340. The IP traffic of the IAB-DU traverses the BAP sublayer over wireless backhaul routing. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer at the IAB donor DU, thereby forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity of the intermediate IAB nodes (if any) (and the corresponding BAP entities in the IAB-DU and IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer at the destination IAB node (which may be an access IAB node if the upper layer packets in the BAP packet are intended for a UE). In the upstream direction, upper layer packets are encapsulated by the BAP sublayer at the originator IAB node (which may be an access IAB node if the upper layer packet comes from a UE) to form BAP packets or data units (PDUs) or data packets. BAP packets are routed by the BAP layer (and corresponding BAP entities in IAB-DU and IAB-MT, if any) of intermediate IAB nodes. The BAP packets are ultimately decapsulated by the BAP sublayer at the IAB Donor DU. At the BAP sublayer, packets are routed based on a BAP routing ID, which is carried in the BAP header of the BAP packet and is set by the BAP sublayer of the issuing IAB Donor DU or originator IAB node (e.g., a network node in an IAB network that generates the BAP packet). Figure 3 illustrates the format of a BAP data protocol data unit (PDU) or packet. It is specified in the standardized version of 3GPP TS 38.340 version 17.2.0, paragraph 6.2. The payload portion 307 is typically an IP packet. Header 30 contains fields 301 to 306. Field 301, named the D/C field, is a Boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302-304 are 1-bit reserved fields, preferably set to 0 (ignored by the receiver). Fields 305 and 306 together indicate the BAP routing ID of the BAP packet. The BAP address field 305, also known as the DESTINATION field, is located in the leftmost 10 bits, while the BAP path identity field 306, also known as the PATH field, is located in the rightmost 10 bits. Field 305 carries the BAP address (i.e., on the BAP sublayer) of the destination IAB node or IAB donor DU of the BAP packet. For routing purposes, each IAB node and IAB donor DU in the IAB network is configured (by the IAB donor CU of the IAB network) with an assigned unique BAP address. Field 306 carries a path ID that identifies the routing path that the BAP packet should follow to that destination in the IAB topology. For routing purposes, routing paths (including their path IDs) are configured in the IAB nodes of the IAB network (by the IAB donor CU of the IAB network). When a packet reaches the BAP layer from upper layers, the BAP header is added to the packet and when it reaches its destination node, the BAP header is stripped by the BAP layer. The BAP Routing ID of the selected packet is configured by the IAB donor CU. For example, when a BAP packet is generated by a node, i.e. by an IAB donor DU for downstream transmission or by an initiator (when the upper layer packet comes from a UE, the initiator can be an access IAB node) for upstream transmission, the node constructs a BAP header with the BAP Routing ID according to the configuration table defined in 3GPP TS 38.340. This table is called the Downlink Traffic to Routing ID Mapping Configuration Table in the IAB Donor DU or the Uplink Traffic to Routing ID Mapping Configuration Table in the initiator IAB node. In the intermediate IAB nodes, the BAP header field is already specified in the BAP packets to be forwarded. As mentioned above, these configuration tables that define the BAP paths (and therefore the routing policies and configuration of the IAB nodes given a given IAB network topology) are typically defined by the IAB Donor CU and transmitted to the IAB nodes to configure them. In order to transmit information on the 5G NR radio medium, three other sublayers (RLC, MAC and PHY) are implemented on each IAB node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for the segmentation or reconstruction of packets. It is also responsible for requesting retransmission of lost packets. The RLC layer is further described in TS 38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting an available transmission format for user data and for mapping logical channels to transmission channels. The MAC also handles part of the Hybrid Automatic Repeat Request scheme. The MAC layer is described in detail in TS 38.321. On the transmitter or transmitter side, the MAC encapsulates the data packets sent from the RLC. It adds a header with the information required for the MAC function. On the receiver side, the MAC decapsulates the data packets sent from the PHY, removes its header and passes the remaining data to the RLC. The PHY sublayer provides the electrical interface to the transmission medium (air) by converting the information stream into a physical modulated signal, modulating the carrier frequency on the transmitter side. On the receiver side, the PHY sublayer converts the physical modulated signal back into an information stream. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214. To deliver messages to the user or control plane, two other sublayers are used in the UE and IAB donor CU: the PDCP (Packet Data Convergence Protocol) sublayer and the SDAP (Service Data Adaptation Protocol) sublayer for user plane communication or the RRC (Radio Resource Control) sublayer for control plane communication. The PDCP sublayer handles IP header compression/decompression, encryption/decryption, and integrity of data packets when necessary. It enforces packet numbering on the transmitter side and reordering of packets on the receiver side. The PDCP sublayer is described in 3GPP TS 38.323. The SDAP sublayer 220 of the user plane handles quality of service. It is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with user applications (voice, video, etc., not shown in the figure). On the IAB donor CU side, the SDAP sublayer exchanges data (Internet traffic, cloud, etc.) with the core network 110. The RRC sublayer 220 of the control plane handles the configuration of the protocol entities of the user plane protocol stack. Described in TS 38.331. It is responsible for processing broadcast information required for UE to communicate with cells, etc.; transmitting call messages, managing connections, including setting up bearers; mobility functions; measurement configuration and reporting; device capabilities. The interface between nodes using PDCP, RLC, MAC and PHY layers (for CP and UP) is called NR-Uu. This mainly involves interfacing with the UE. The interface between nodes using BAP, RLC, MAC and PHY layers (for CP and UP) is called the backload RLC channel (BH RLC channel). This mainly involves the interface between IAB nodes. NR-Uu is the interface between the UE and the radio access network, that is, its access IAB node (for CP and UP). Figure 2b is from 3GPP TS 38.300 V17.2.0 and illustrates the protocol stack for RRC and NAS connections supporting IAB-MT. The Non-Access Stratum (NAS) protocol handles the messaging between the core network and the user equipment or IAB node. It manages the establishment of a communication session and maintains communication with the IAB node or user equipment as it moves. The 5G NAS is described in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the core network that receives all connection and session related information from the UE connected to the IAB node, and similar information from the IAB node. The AMF is responsible for handling connection and mobility management tasks only. The IAB-MT establishes a signaling radio bearer SRB (which carries the RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted between the IAB-MT and its parent node via the NR-Uu interface. Figure 4 shows a schematic diagram of an exemplary communication device (equipment) or station according to one or more exemplary embodiments of the present disclosure. The communication device 400 can be a device such as a microcomputer, a workstation or a lightweight portable device. The communication device 400 includes a communication bus 413, which is preferably connected to: - A central processing unit 411, such as a microprocessor, represented as a CPU. The central processing unit 411 can be a single processing unit or processor or may include two or more processing units or processors, which perform the processing required to operate the communication device 400. The number of processors and the allocation of processing functions of the central processing unit 411 are a matter of design choice for those skilled in the art; - memory for storing data and computer programs including instructions for operating the communication device 400. The computer program may include many different program elements (modules) or subroutines including instructions for various operations and various operations of implementing the method according to one or more embodiments of the present invention; and - at least one communication interface 402 for communicating with other devices or nodes in a communication system, such as the communication system of Figure 1. The at least one communication interface 402 may be connected to a radio communication network 403, such as a radio communication network for 5G NR (e.g., according to Release 17 and/or later), through which digital data packets or frames or control frames are transmitted. Frames are written from a FIFO send memory in a RAM 412 to the communication interface for transmission, or read from the communication interface for reception and written to a FIFO receive memory in the RAM 412, under the control of a software application running in the CPU 411. Each of the donor CU, donor DU, IAB node and UE may include such a communication device/apparatus 100. The memory may include: - a read-only memory 407, represented as ROM, for storing a computer program for implementing a method according to one or more embodiments of the present invention; - a random access memory 412, represented as RAM, for storing executable code of a method according to one or more embodiments of the present invention, and registers adapted to record variables and parameters required for implementing a method according to one or more embodiments of the present invention. Optionally, the communication device 400 may also include the following components: - a data storage component 404, such as a hard disk, for storing a computer program for implementing a method according to one or more embodiments of the present invention; - a disk drive 405 for a disk 406, which is suitable for reading data from the disk 1106 or writing data to the disk; - a screen 409 for displaying decoded data and/or acting as a graphical interface with the user through a keyboard 410 or any other input/output component. In an exemplary configuration, a communication bus 413 provides communication and interoperability between various components included in or connected to the communication device 400. The representation of a bus is not restrictive, and expressly states that the central processing unit is operable to communicate instructions to any component of the communication device 400, directly or through other components of the communication device 400. The disk 406 may alternatively be replaced by any information medium, such as a rewritable or non-rewritable optical disk (CD-ROM), a ZIP disk, a USB key or a memory card, and in general terms, by an information storage component that can be read by a microcomputer or a microprocessor, which may be integrated in the communication device or not, may be removable and is suitable for storing one or more programs, wherein the execution of the program enables the implementation of the method according to the present embodiment. The executable code may optionally be stored in the read-only memory 407, on the hard disk 404 or on a removable digital medium such as, for example, the aforementioned disk 406. According to an alternative variant, via the interface 402, the executable code of the program may be received via the communication network 403 in order to be stored in one of the storage means of the communication device 400 before execution, such as the hard disk 404. The central processing unit 411 may be adapted to control and direct the execution of the instructions of one or more programs according to the invention or parts of the software code, the instructions of which are stored in one of the aforementioned storage means. Once powered on, one or more programs stored in non-volatile memory such as hard disk 404 or read-only memory 407 are transferred to random access memory 412, which then saves the executable code of the one or more programs, as well as registers for storing variables and parameters required to implement the present invention. In an exemplary embodiment, the communication device (equipment) is a programmable device/equipment that uses software to implement the present invention. Instructions may be executed by one or more processors of a device, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits, to implement the present invention for network nodes (e.g., IAB nodes, IAB donors CUs, etc.). Accordingly, the term "central processing unit" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Alternatively, however, the present invention may be implemented in hardware (e.g., with application specific integrated circuits or ASICs or other logic elements). FIG. 5 illustrates an example of an IAB communication system (or IAB network system) 500 in which embodiments of the present invention and examples of embodiments may be implemented. In an example implementation, the radio links between IAB nodes and between IAB nodes and IAB donor DU (referred to as BH radio links) operate in the millimeter wave band (i.e., above 30 GHz), which is highly sensitive to radio channel interference. The IAB network will also be referred to as an IAB topology or topology, so in this application, the terms IAB network and IAB topology and topology will be used interchangeably. The IAB communication system 500 is composed of three IAB networks or IAB topologies 5001, 5002, and 5003, each of which includes a group of IAB nodes (e.g., the group may include a plurality of IAB nodes or at least one IAB node) and an IAB donor CU for controlling or managing the plurality of IAB nodes. The set of IAB nodes may include one or more IAB nodes, such as an initiator IAB node that generates a BAP packet and also include intermediate or relay IAB nodes. Each of the IAB nodes communicates with at least one other IAB node via a wireless backhaul (BH) link. Although FIG. 5 shows three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system including more than two IAB topologies, each of which includes a set of IAB nodes and an IAB donor CU as described above. As discussed above, each IAB node includes a mobile terminal (MT) portion or unit controlled and configured by the IAB donor using RRC messaging as defined in 3GPP TS 38.331 and a distributed unit (DU) portion controlled and configured by the IAB donor using F1-AP messaging as defined in 3GPP TS 38.473. For example, IAB node 510 includes an MT portion or unit 511 and a DU portion 512. IAB topology 5001 includes an IAB donor CU 501 (identified as donor 1-CU in FIG. 5 ), and its associated IAB donor DU 504 (identified as donor 1-DU 1 in FIG. 5 ), and a plurality of IAB nodes 510 and 520 similar to IAB nodes 121 and 122. The IAB topology 5002 includes an IAB donor CU 502 (identified as donor 2-CU in FIG. 5 ), its associated IAB donor DUs, IAB donor DU 505 (identified as donor 2-DU 1 in FIG. 5 ) and IAB donor DU 506 (identified as donor 2-DU 2 in FIG. 5 ), and a plurality of IAB nodes 530, 540, 550 similar to IAB nodes 121 and 122, and an IAB node 570 which may be similar to mobile IAB node 123. All IAB nodes may access nodes serving UEs, such as UE 580 served by mobile IAB node 570. The IAB topology 5002 is transparent to UE 580 connected to donor CU 502 via a DU portion or unit 572 of mobile IAB node 570. Although FIG5 shows only one UE 580, it should be understood that there will be multiple UEs connected to the network nodes of the IAB communication system 500. The IAB topology 5003 includes an IAB donor CU 503 (identified as donor 3-CU in FIG5 ), its associated IAB donor DU 507 (identified as donor 3-DU1 in FIG5 ), and an IAB node 560, such as IAB nodes 121 and 122. The wired backhaul IP network interconnects the IAB donor CUs 501, 502, and 503, and the IAB donor DUs 504, 505, 506, and 507 via a wired backhaul 508. For example, the wired backhaul 508 is composed of optical fiber cables. IAB donor CU 501, IAB donor DU 504, and IAB nodes 510 and 520 are part of the same IAB network or IAB topology 5001, which are configured and managed or controlled by IAB donor CU 501. IAB donor CU 502, IAB donor-DUs 505 and 506, and IAB nodes 530, 540, and 550 are part of the same IAB network or IAB topology 5002, which are configured and managed or controlled by IAB donor CU 502. IAB donor CU 503, IAB donor-DU 507, and IAB node 560 are part of the same IAB network or IAB topology 5003, which are configured and managed or controlled by IAB donor CU 803. Each IAB-DU and IAB donor DU supports wireless communication in a coverage area called a cell (not shown in FIG. 5 ). In other words, each IAB-DU and IAB donor DU is associated with a cell. A wireless communication device (such as a UE, or other IAB node) located in a cell can establish a communication link with a node (i.e., an IAB-DU or an IAB donor DU) serving the cell to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the Internet, etc.) through the node. It is assumed that the mobile IAB node 570 initially has a single parent IAB node 520, and the IAB node 570 belongs to an IAB topology 5001 controlled by an IAB donor CU 501. Thus, the IAB donor CU operates as an F1-terminal donor CU (which may also be referred to as an F1-terminal IAB donor CU or an F1 donor CU). When moving and given its proximity to the IAB topology 5002, specifically the IAB node 530, when the mobile IAB node 570 is in the position shown by the dashed line in FIG. 5 , the mobile IAB node 570 may establish a wireless BH link with the IAB node 530. This BH link is possible for a fixed IAB node, and is very possible for a mobile IAB node such as the IAB node 570 that moves, for example, in the direction of the IAB topology 5002 (shown by arrow 590 in FIG. 5 ). Then, the F1 donor CU 501 may have decided to perform a migration of the MT portion 571 of the IAB node 570 toward the IAB topology controlled by the donor CU 502, which becomes a non-F1 terminal donor CU (which may also be referred to as a non-F1 terminal IAB donor CU or a non-F1 donor CU or an RRC terminal donor CU or an RRC donor CU) of the IAB node 570 (i.e., the MT portion 571 of the IAB node 570 migrates toward the parent IAB node 530). For this purpose, the F1 donor CU 501 may start the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or section 8.17.3.2 (when the IAB node 570 has a predecessor IAB node). Therefore, the IAB node 501 still belongs to the IAB topology 5001 with its F1 connection to donor CU 501, but its RRC connection is now to donor CU2 502. After this procedure, the IAB donor CU 501 can request the migration of backload traffic (e.g., user traffic, control traffic) associated with the IAB node 570 towards the IAB topology 5002 (i.e., through the donor DU 505). In this case, the donor CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. In the IB communication system, all traffic communicated via the backload link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Thus, the offloaded or migrated traffic or backloaded traffic is F1 traffic and may include control and user traffic. While the mobile IAB node 870 is still moving in the direction indicated by arrow 590, the MT portion 571 of the IAB node 570 may then be moved by the non-F1 donor CU 502 toward the parent IAB node 550, using the backload link 5050 between the IAB node 550 and the IAB node 570. For this purpose, the non-F1 donor CU 502 may apply the intra-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.2.3.1 (or section 8.17.3.2), resulting in a continuous MT migration of the IAB node 570 (or another MT migration to another IAB node) utilizing a new single parent IAB node 550. Furthermore, the IAB node 501 makes its F1 connection to donor CU 501 and its RRC connection to donor CU2 502. After being informed to use donor DU 506 instead of donor DU 505 to route F1 traffic associated with IAB node 570, donor CU 501 may request to migrate traffic associated with IAB node 570 towards IAB topology 5002. In this case, donor CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. While moving further, now in the direction of the IAB topology 5003 controlled by the donor CU 503, the IAB node 570 may become in a position where the backload link 5060 with the IAB node 560 may have a better quality than the backload link 5050 with the IAB node 550. Therefore, the donor CU 502 may apply the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or 8.17.3.2. After this continuous MT migration, IAB node 501 still belongs to IAB topology 5001, it has F1 connection with donor CU 501, but it is now RRC connected with donor CU 503, and thus donor CU 503 becomes a non-F1 terminal donor CU (or non-F1 donor CU or RRC donor CU). However, donor CU 501 must be informed of the new non-F1 donor CU 503 for IAB node 570 and new donor DU 507 to redirect the offloaded traffic (F1 traffic, control and user traffic) through donor DU 507 instead of donor DU 506. In all MT migration scenarios described above, UE 580 is still connected to donor CU 501 through the DU part or unit 572 of mobile IAB node 570. If the IAB node 570 has some child IAB nodes, these child IAB nodes still belong to the IAB topology 5001 and they are still fully controlled by the donor CU 501 (via F1 and RRC connections). At any migration state of the MT part 571 of the IAB node 570, therefore regardless of whether the MT part 571 of the IAB node 570 is migrated to the IAB topology 5002 or the IAB topology 5003, and therefore regardless of whether the IAB node 570 has a non-F1 terminal donor CU, and if so, regardless of whether it is a non-F1 terminal donor CU 502 or 503, the F1 donor CU 501 can decide to perform the migration of the DU part of the IAB node 570. The reason for performing a DU migration may be to reduce the processing load at the F1 donor CU 501, or because the IAB node 570 is geographically far from the F1 donor CU 501 and close to an area where there is no more Xn connectivity between the F1 donor CU 501 and a target donor CU. After deciding to perform a DU migration of the IAB node 570, the F1 donor CU 501 must also decide towards which donor CU (which is referred to as the target F1 donor CU) the DU migration will be performed. If there is a current non-F1 terminal donor CU then it may be a DU migration towards the current non-F1 terminal donor CU (i.e., the default choice) and in this case the non-F1 terminal donor CU becomes the target F1 donor CU or a DU migration towards another target F1 donor CU. For example, if the IAB node 570 is mobile and its trajectory is predictable (e.g., for a bus or train), the F1 donor CU 501 may know the appropriate target F1 donor CU through which the IAB node 570 will soon connect to the control cell of the network. For example, although the non-F1 end donor CU of the IAB node 570 is the donor CU 502, the F1 donor CU may decide that the DU migration of the IAB node 570 should be directed toward the donor CU 503 because the IAB node 570 can quickly cross and does not reside in the IAB topology 5002 controlled by the donor CU 502. To perform the DU migration not toward the donor CU 502, and instead toward the donor CU 503, the intermediate DU migration protocol messages to the IAB node 570 will be avoided. When performing the DU migration, the handover of the UE served by the IAB node 570 must also be performed. Therefore, in order not to perform DU migration towards donor CU 502, an intermediate handover of UEs served by IAB node 570 to donor CU 502 will also be avoided before a new DU migration and UE handover towards donor CU 503. The process of performing DU migration and UE handover towards a selected target F1 donor CU is described in more detail with reference to the subsequent figures. FIG6 illustrates an example of an IAB node architecture 600 that enables migration of DUs of an IAB node from a source IAB topology to a target IAB topology (DU migration). IAB node 601 (which may be a mobile IAB node such as IAB node 570) is composed of an IAB-MT part or unit IAB-MT 610 (such as MT part 571 of IAB node 570 of FIG. 5), a part or unit IAB-DU1 611, and a part or unit IAB-DU2 612. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example they rely on different physical layers. At the DU migration of the IAB node 601, two logical DUs are active: one of the logical DUs terminates the F1 interface with the source F1 donor CU (e.g., donor CU 501 in FIG. 5 ), and the other logical DU terminates the F1 interface with the target F1 donor CU (e.g., donor CU 502 or 503 in FIG. 5 ). Otherwise (i.e., when DU migration is not performed), only one logical DU is sufficient for IAB operation. As an example and with reference to the IAB communication system of FIG. 5 , the F1-terminal donor CU of the IAB node 601 (i.e., IAB node 570) may be the donor CU 501 that thus operates as the source F1 donor CU. When the source F1 donor CU 501 determines that the IAB node 570 is moving toward/through the IAB topology 5002, the source F1 donor CU 501 may identify the IAB donor CU 502 as a suitable target F1 donor CU, the IAB topology 5002 including network nodes (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550) managed by the IAB donor CU 502, which network nodes serve the cells in the IAB topology 5002 to which the IAB node 570 is about to connect. Alternatively, for an IAB node that is connected to a parent IAB node or a parent IAB donor DU of an IAB topology 5001 managed by a donor CU 501 that is an F1 terminal donor CU and is fixed but is close to or adjacent to one or more IAB nodes in a neighboring IAB topology (such as the IAB topology 5002), the source F1 donor CU 501 may determine that the IAB node is a suitable target F1 donor CU when the source F1 donor CU 501 determines (e.g., based on signal measurements performed at the IAB node on radio signals received at the IAB node from all IAB nodes close to the IAB node, which may include the IAB nodes in the neighboring IAB topology 5002) that the IAB node is about to connect to an IAB node in the neighboring IAB topology 5002. 502 is a suitable target F1 donor CU. Before DU migration, for example, UE 602 (such as UE 580 in FIG. 5 ) is connected to source F1 donor CU 501 via logical DU IAB-DU1 611 and access link 621 in the cell served by logical DU IAB-DU1 611, and logical DU IAB-DU2 612 is disabled. At DU migration, logical DU IAB-DU2 612 is enabled and connected to target F1 donor CU 502, and UE 602 can also be connected to the target F1 donor CU 502 via logical DU IAB-DU2 612 and link 622 in the cell served by logical DU IAB-DU2 612. Activation of logical DU IAB-DU2 612 may be triggered by the source F1 donor CU and performed by the procedure described with reference to Figures 8a and 8b. Once handover from a cell controlled by logical DU IAB-DU1 611 to a UE 602 controlled by logical DU IAB-DU2 612 is completed, logical DU IAB-DU1 611 may be deactivated. Deactivation may be triggered by the procedure described with reference to Figure 8c by the source F1 donor CU 501 after detecting completion of handover for all UEs served by IAB-DU1 611. An example of a method according to one or more embodiments of the present invention will now be described, which enables DU migration of IAB nodes with or without (multiple) MT migration, and which includes notifying the IAB nodes about the identity of a target donor CU so that a UE served by the IAB node can be handed over to the target donor CU. Although the following method/apparatus will be described primarily with respect to mobile IAB nodes, it should be understood that the present invention is not intended to be limited to mobile IAB nodes. The method according to one or more embodiments of the present invention may be applied to fixed IAB nodes, for example, at the edge of an IAB topology and close to or adjacent to one or more IAB nodes in a neighboring IAB topology. FIG. 7 is a schematic simplified diagram 700 illustrating some exemplary message flows to perform DU migration of an IAB node with or without (multiple) MT migration according to one or more embodiments of the present invention, and includes notifying the IAB node about a target donor CU so that UEs served by the migrated IAB node can be handed over to the target donor CU. FIG. 7 shows a UE 708 such as UE 580, a source F1 donor CU 703 such as donor CU 501, a target F1 donor CU 707 such as donor CU 503, and a core network (5GC) 702 such as the core network 110 of FIG. 1. This Figure 7 also shows an IAB node 701, which may be a mobile IAB node such as the IAB node 570, consisting of an MT portion or unit IAB-MT 704, a DU portion or unit IAB-DU1 705 (e.g., a source or first logical DU entity), and a DU portion or unit IAB-DU2 706 (e.g., a target or second logical DU entity). Each of the first 705 and second 706 DU logical entities serves one or more cells. The cells of the IAB-DU1 705 are identified by different identifiers of the cells of the IAB-DU1 705 (e.g., a physical cell identifier (PCI), a new radio cell group identifier (NCGI)). IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for BAP, RLC and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example they rely on different physical layers. If the IAB-MT 704 has not migrated, the non-F1 donor CU of the IAB node 701 can be the source F1 donor CU 703 itself. If the IAB-MT 704 has previously migrated towards the target F1 donor CU 707, the non-F1 donor CU of the IAB node 701 can be the target F1 donor CU 707, or if the IAB-MT 704 has previously migrated towards another donor CU, this other donor CU (not shown in the figure). At the start of the flow, the IAB node 701 belongs to the source IAB topology controlled by the source F1 donor CU 703. The UE 708 is served by the IAB node 701 through the cell of IAB-DU1 705 (e.g., the DU of the IAB node 701 has an active IAB-DU1 705, which has an F1 connection with the source F1 IAB donor CU 703), and the logical IAB-DU2 706 is inactive. User data in the downstream direction is provided to the source F1 donor CU 703 by the 5GC 702 through the bearer 710, then the data is transmitted to the logical DU IAB-DU1 705 of the IAB node 701 through the backhaul bearer 711, and finally transmitted to the UE 708 through the data radio bearer 712. Backhaul transport 711 may be established in the source IAB topology controlled by the source F1 donor CU 703 or in the IAB topology controlled by the non-F1 donor CU of the IAB node 701 (if the IAB-MT 704 was previously migrated towards this non-F1 donor CU). User data in the upstream direction (not shown in the figure) is transmitted via a similar transport in the reverse direction. If the IAB-MT 704 has previously migrated toward this non-F1 donor CU (not shown in FIG. 7 ) or if it has not yet migrated from its F1-terminal donor CU to its F1-terminal donor CU (e.g., source F1 donor CU 703), the IAB-MT 704 may send measurement reports (not shown in FIG. 7 ) to its non-F1-terminal donor CU as a result of the IAB-MT 704 regularly performing measurements on signals received from the serving cell and one or more target cells (e.g., signal synchronization blocks (SSBs) transmitted in the serving cell and in the target cells). The target cell may be a cell that is adjacent to the serving or source cell (i.e., the current serving cell). Once the IAB-MT 704 finds at least one RSB that meets predefined criteria (e.g., received power exceeding a predefined threshold), a measurement report may be generated and transmitted to provide radio link quality information for different cells adjacent to the IAB node 701. The identity of each cell is included in the measurement report to allow a non-F1 donor CU if the IAB-MT 704 has migrated or an F1 end donor CU 703 if the IAB-MT 704 has not migrated to identify the target donor CU associated with the cell. In practice, the identity of the donor CU may be derived from a physical cell identity (PCI) broadcast in each cell managed by the donor CU in a synchronization signal and/or from a new radio cell group identifier (NCGI) also broadcast in each cell managed by the donor CU in a system information block (SIB) message. The PCI and/or NCGI may be reported by the IAB node 701 in a measurement report. Based on the received measurement reports, the non-F1 donor CU (if the IAB-MT 704 has migrated) or the F1 end donor CU 703 (if the IAB-MT 704 has not migrated) may detect that the IAB node 701 is receiving the radio signal in the target cell of the target parent IAB node with better quality than the quality in the source serving cell. The non-F1 donor CU (if the IAB-MT 704 has migrated) or the F1 end donor CU 703 (if the IAB-MT 704 has not migrated) may decide to apply a procedure to perform IAB-MT 704 migration towards a target parent IAB node belonging to the same IAB topology (intra-CU topology adaptation) or another IAB topology (inter-CU topology adaptation). In either case, the source F1 donor CU 703 will be notified about this MT migration by the non-F1 donor CU (if the IAB-MT 704 has already migrated), or the source F1 donor CU 703 will be notified because it made the decision to perform MT migration directly from the measurement reports received by the IAB node 701 (if the IAB-MT 704 has not yet migrated), and this information can be used by the source F1 donor CU 703 to trigger DU migration of the IAB node 701. In another example, the non-F1 donor CU can forward (relay) the information in the measurement reports received from the IAB node 701 to the source F1 donor CU 703. Therefore, the source F1 donor CU 703 can make a decision to migrate the DU of the IAB node 701 based on these measurement reports forwarded by the non-F1 donor CU. Therefore, the source F1 donor CU 703 determines that the DU of the IAB node is to be migrated from the IAB topology of the source F1 donor CU 703 to another IAB topology of the target IAB donor CU. The determination may be based on determining that the migration of the MT of the IAB node toward the new parent IAB node has been completed. Another example of a triggering event for determining that the DU of the IAB node is to be migrated may include that the decision of DU migration may be based on the detection of MT migration from a first IAB topology toward a second IAB topology, and based on a known (predefined) trajectory of the IAB node, which indicates to the source F1 donor CU that the MT will migrate to a second IAB topology at a later time. Three IAB topologies. In this case, to avoid the signaling for DU migration/UE handover toward the second IAB topology, the DU is migrated directly toward the third IAB topology. Another example of a triggering event for determining that a DU of an IAB node is to be migrated may include detecting a processing load level higher than a predetermined threshold in the source F1 donor CU. DU migration is then triggered, and the selection of the target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU. 703 determines or determines to perform DU migration of the IAB node 701 towards another IAB topology managed by another donor CU that becomes the target F1 donor CU 707, the first step 720 corresponds to sending a request to the IAB node 701 to establish a new F1 connection between the target F1 donor CU 707 and the mobile IAB node 701. This may require activating the second logical DU IAB-DU2 706 in the mobile IAB node 701 and therefore the first step 720 may include activating the second logical DU IAB-DU2 706 in the mobile IAB node 701. This operation is performed using, for example, the procedure described with reference to Figures 8a and 8b. Specifically, the message sent by the source F1 donor CU 703 to the IAB node 701 for activating the IAB-DU2 706 (e.g., 803 in FIG. 8 a) may include identification information for identifying the target donor CU (e.g., the TNL address (i.e., IP address) of the target F1 donor CU 707) so that a new F1 connection or F1 association (e.g., F1AP interface connection) may be set up with the target donor CU 707 (between the IAB-DU2 706 and the target donor CU 707). If the address of the target F1 donor CU is not included in the request for activation, then by default and in the case where the IAB-MT 704 has migrated to a non-F1 donor CU, the non-F1 donor CU is considered to be the target F1 donor CU. In this case, the IAB node 701 has been informed of the identity of the target donor CU (e.g., TNL address/IP address) when the IAB-MT 704 migrates to the non-F1 donor CU. In other words, the source F1 donor CU 703 may send identification information for identifying the target IAB donor CU unless the IAB-MT 704 has migrated to the non-F1 donor CU. Alternatively, the source F1 donor CU 703 may send identification information for identifying the non-F1 donor CU as the target IAB donor CU. After determining that the DU of the IAB node 701 is to be migrated and once the IAB-DU2 706 has been activated, the IAB-DU2 706 may send an F1 Setup Request message (e.g., 813 in FIG. 8 b ) to the target F1 donor CU 707 to request the establishment of an F1 connection between the IAB node 701 and the target F1 donor CU 707. This message may include identification information for identifying the source IAB donor CU, such as a TNL address (i.e., an IP address) or an identifier of the source F1 donor CU 703 of the IAB node 701 (i.e., the global NG-RAN node ID as specified in TS 38.423 V.17.2.0 section 9.2.2.3). If the IAB-MT 704 of the IAB node 701 has previously migrated towards this non-F1 donor CU (not shown in FIG. 7 ), this message may also include the TNL address (i.e., IP address) or the identifier of the non-F1 donor CU of the IAB node 701 (i.e., the global NG-RAN node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3). The destination address of the F1 Setup Request message is the target F1 donor CU 707, and when this IP packet is received by the donor DU in the F1 path for the IAB node 701, it may be routed to the target F1 donor CU 707 in the wired backhaul (508 in FIG. 5 ). For example, in the instance where IAB node 701 is IAB node 570 of Figure 5 connected to IAB node 550 via backhaul link 5050 and where the MT of IAB node 570 (MT 571, which corresponds to IAB-MT 704 in Figure 7) has been migrated to non-F1 donor CU 502 and IAB donor CU 501 is one of the source F1 donor CUs, the F1 path between F1 donor CU 501 and IAB node 570 uses donor DU 506. In the case where the IAB donor CU 503 has been identified (by the F1 donor CU 501) as a target F1 donor CU (e.g., target F1 donor CU 707), an F1 setup request message for the target F1 donor CU (e.g., donor CU 503) is sent through the IAB nodes 550, 540 and then to the donor DU 506, from where it may be routed in the wired backhaul (508 of FIG. 5) to the target F1 donor CU 503. In the F1 setup response (e.g., 814 of FIG. 8b), the target F1 donor CU 707 (e.g., donor CU 503 in the example described above with reference to FIG. 5) may request the IAB-DU2 706 to enable new cell(s) with the associated identifiers (PCI, NCGI). Typically the DU activates/deactivates cells under the control of the donor CU controlling the DU. See, for example, TS 38.473 section 8.2.3.2. Following the procedure described with reference to FIG. 8b, and using, for example, the procedure described with reference to FIG. 9a, the target F1 donor CU 707 may inform the source F1 donor CU 705 about activating new cell(s) from IAB-DU2 706 of the IAB node 701. The next step 730 consists of handing over the cells of the first logical DU IAB-DU1 705 to the cell(s) of the second logical DU IAB-DU2 706 for the UE to be served by the IAB node 701 (e.g., UE 708 in FIG. 7). This procedure may be the standardized procedure described in TS 38.300 Section 9.2.3.2 (Handover) or the standardized procedure described in TS 38.300 Section 9.2.3.4 (Conditional Handover). In one example, to trigger a handover of UE 708, source F1 donor CU 703 sends a handover request message including necessary information related to UE 708 for handover to target F1 donor CU 707 (e.g., identification information of UE, UE content information (e.g., identification information of security content (e.g., security parameters (e.g., security keys, UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about the carrier, etc.)). TS 38.423 Section 9.1.1.1 provides details about the content of a handover request message. After the target F1 donor CU 707 determines whether the donor CU can accept the handover of UE 708 in the acceptance control step, when the target F1 donor CU 707 When the request is accepted, the target F1 donor CU 707 sends a handover confirmation message to the source F1 donor CU 705, including configuration information of the UE 708 used for the handover. The configuration may include radio configuration information indicating the radio configuration of the second logical DU IAB-DU2 706 used by the UE 708 to connect to the IAB node 701 in the identified target cell of the second logical DU IAB-DU2 706 (for example, the radio configuration may include frequency, radio bearer configuration, etc.). The handover confirmation may include an identifier of each of one or more new cells (for example, target cells) that have been enabled at the second logical DU IAB-DU2 706. Then, the source F1 donor CU 705 sends this configuration information to UE 708 via IAB node 701 in an RRC reconfiguration message, including the identifier of the target cell of IAB-DU2 706 to which UE 708 is connected. The RRC reconfiguration message (specified in TS 38.331) is embedded in the F1 message DLRRC messaging (specified in TS 38.473) sent to IAB-DU1 705 and relayed by IAB-DU1 705 to UE 708. Upon receiving this configuration information, UE 708 performs a random access procedure in the target cell of the indicated IAB-DU2 706 to obtain uplink resources, and then transmits an RRC reconfiguration complete message to the target F1 donor CU 707. The RRC reconfiguration complete message (specified in TS 38.331) is sent to IAB-DU2 706, and then the RRC reconfiguration completion message is embedded in an F1 message UL RRC message transmission (specified in TS 38.473) sent to the target F1 donor CU 707. The source F1 donor CU 705 can be notified of the completion of the handover of the UE 708 by a handover success message (specified in TS 38.423) received from the target F1 donor CU 707. The target F1 donor CU 707 can execute a path switching procedure toward the core network 702 to request the delivery of user data related to the UE 708. For example, the target F1 donor CU 707 can execute 3GPP TS 38.413 The target F1 donor CU 707 must then set up a return path to and from the migrated IAB node 701 either in its own topology if there is a return path to reach the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., the target F1 donor CU 707 is a non-F1 terminal donor CU of the IAB node 701 because the IAB-MT 704 has been previously migrated to the target F1 donor CU 707), or in its own topology if there is no return path to reach the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., the IAB-MT 704 and IAB-DU2 706 is connected to a different donor CU), then the IAB topology of the non-F1 donor CU (not shown in FIG. 7 ) of the IAB node 701 is used. In the latter case, the target F1 donor CU 707 can trigger the procedure described with reference to FIG. 9 b to request traffic migration to the non-F1 donor CU of the IAB node 701. As an example of the latter case with reference to FIG. 5 , the IAB node 701 is the IAB node 570 of FIG. 5 connected to the IAB node 550 via the backhaul link 5050, and wherein the MT of the IAB node 570 (MT 571, which corresponds to the IAB-MT 704 in FIG. 7 ) has been migrated to the non-F1 donor CU 502, and the IAB donor CU 501 is a F1 donor CU. When the DU of the IAB node 570 (corresponding to DU 572 of IAB-DU2 706 in Figure 7) has been migrated to the target donor CU 503 and therefore has an F1 connection to the F1 donor CU 503 but the MT 571 remains connected to the non-F1 donor CU 502 (its RRC connection) through its RRC connection, the return path to and from the IAB node 570 is set up in the IAB topology 5002 controlled by the IAB donor CU 502 by executing a traffic migration procedure (for example, as described with reference to Figure 9b) (i.e., the return path through the IAB donor DU 506, IAB nodes 540 and 550 to the IAB node 570). After the handover to the UE 708 and the path switching have been performed, the user data in the downstream direction is transmitted from the core network 702 to the target F1 donor CU 707 via bearer 740, then it is transmitted to the logical DU IAB-DU2 706 of the IAB node 701 via backhaul bearer 741, and finally transmitted to the UE 708 via data radio bearer 742. The backhaul bearer 741 may be established in an IAB topology controlled by the target F1 donor CU 707 or in an IAB topology controlled by a non-F1 donor CU of the IAB node 707 (e.g., depending on whether the IAB-MT 704 and IAB-DU2 706 of the IAB node 701 are connected to different donor CUs). User data in the upstream direction (not shown in the figure) is transmitted in the opposite direction by similar transport. Once the handover of all UEs served by the IAB-DU1 705 of the IAB node 701 is completed, the source F1 donor CU 703 can deactivate the logical DU IAB-DU1 705 of the mobile IAB node 701 through the procedure described with reference to Figure 8c. This is represented as a whole by the procedure 735 in Figure 7. At the same time, the source F1 donor CU 705 can release the traffic (user traffic, control traffic) related to the UE served by the IAB node 701 through IAB-DU1 705. If the traffic is offloaded in the IAB topology controlled by another donor CU, the source F1 donor CU 705 can apply the procedure described with reference to Figure 9b to request the release of the traffic to the other donor CU. This is represented as a whole by the procedure 735 in Figure 7. FIG8a is a schematic simplified diagram 800 of a flow chart showing an exemplary message flow of a procedure for performing activation of a logical DU according to an embodiment of the present invention. This figure shows: - a RAN node DU 801, which may be a DU of an IAB node such as the IAB-DU 572 of the IAB node 570 of FIG5 (and the IAB-DU1 705 of the IAB node 701 of FIG7), - a RAN node CU 802, which may be an IAB donor CU such as the IAB donor CU 501 of FIG5 (and the source F1 donor CU 703 of FIG7). The message configuration request 803 is sent by the RAN node CU 802 to the RAN node DU 801 to request the activation of new cell(s) controlled by the RAN node DU 801 or to request the activation of a logical DU or to request the deactivation of cell(s) in the RAN node DU 801. In the case of a logical DU activation, the message 803 may include the TNL address (i.e., IP address) of the RAN node CU (e.g., target F1 donor CU 707 of FIG. 7 ) that will be connected to the logical DU once activated. For example, a configuration request 803 may be sent by the source IAB donor CU to an IAB node (e.g., a first logical DU entity 705 having an F1 connection with the source IAB donor CU) to request the establishment of an F1 connection between the target IAB donor CU and the IAB node. The RAN node DU 801 may acknowledge the request with a message configuration response 804 sent to the RAN node CU 802. According to an example, the flow in FIG8a corresponds to the procedure gNB-CU CONFIGURATION UPDATE procedure described in TS 38.473 V17.0.0, section 8.2.5, and the message 803 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0, section 9.2.1.10, and the message 804 corresponds to the message GNB-CU CONFIGURATION UPDATE CONFIRM described in TS 38.473 V17.2.0, section 9.2.1.11. The message GNB-CU CONFIGURATION UPDATE includes an information element (IE) CELL LIST TO BE ACTIVATED to indicate the new cell(s) to be activated at the RAN node DU 801. For example and with reference to Figure 7, the GNB-CU configuration update includes information for enabling (several) new cells indicated in the IE cell list to be enabled, which (such) new cells can be served by the first logical DU entity 705 at the IAB node 701. The cells to be enabled refer to the cells controlled by the RAN node DU 801 that receives the request. The associated PCI and NCGI values to be used by the RAN node DU 801 may also be provided. The message GNB-CU configuration update may also include an information element (IE) cell list to be disabled to indicate the (several) cells to be disabled. The cells to be disabled refer to the cells controlled by the RAN node DU 801 that receives the request. For example and with reference to FIG. 7 , the GNB-CU configuration update may include information for deactivating cells indicated in the IE list of cells to be deactivated, which are currently being served by the first logical DU entity 705 at the IAB node 701. According to an example, a new IE second DU enable may be added in the form of a Boolean (e.g., a one-bit IE) in the message 803 to request the activation of the second logical DU. One value of the one-bit IE (i.e., "0" or "1") means that no specific action associated with the second logical DU is requested and another value (i.e., "1" or "0") means requesting the activation of the second logical DU. This IE may be accomplished by a new IE for indicating that the F1 setup is for the purpose of DU migration towards the target RAN node CU (in other words, an IE for indicating that the request for establishing the F1 connection is for DU migration of the IAB node) and/or by a new IE indicating the number of cells to be enabled in the second logical DU. In the absence of such an IE indicating the number of cells, the number of cells to be enabled currently corresponds to the number of cells already enabled in the RAN node DU 801. Another IE may also provide a list of identifiers (e.g. PCI and/or NCGI) of cells that are controlled by the first logical DU 705 at the IAB node 701, for which a mapping with the identifiers of the cells to be activated is provided: for example, mapping may not be required for all active cells controlled by the first logical DU 705, and therefore only the identifiers of those cells that are mapped to the identifiers of the cells to be activated and controlled by the second logical DU 706 are included in the message 803. In addition, a new IE (e.g. Target TNL Address IE) may be added to identify the target RAN node CU by which the F1 connection should be set up. To complete the setup of the new logical DU at the IAB node, the procedure described with reference to Figure 8b may be used. FIG8b is a schematic simplified diagram 810 illustrating an exemplary message flow of a procedure for setting up a logical DU to establish an F1 connection with a target IAB donor CU according to an embodiment of the present invention. This diagram shows: - a RAN node DU 811, which may be a DU of an IAB node DU such as IAB DU 572 of IAB node 570 of FIG5 (and IAB-DU2 706 of IAB node 701 of FIG7), - a RAN node CU 812, which may be an IAB donor CU such as IAB donor CU 503 of FIG5 (and target F1 donor CU 707 of FIG7). A message setup request 813 is sent by the RAN node DU 811 to the RAN node CU 812 to request F1 setup for the logical DU. For example, a setup request 813 may be sent by the IAB node (e.g., by the second logical DU entity 706 that has been activated at the IAB node 701) to the target IAB donor CU 707 to request the establishment of an F1 connection between the target IAB donor CU and the IAB node (e.g., using the second logical DU entity 706 of the IAB node 701). As described with reference to FIG. 8a, the setup request message 813 may be sent after an activation request. This setup request message 813 may include an indication that the F1 setup is about DU migration of the RAN node embedded in the RAN node DU 811 (e.g., information for indicating that the request for establishing the F1 connection is about DU migration of the DU of the IAB node) and/or the number of cells to be enabled in conjunction with the activation of the logical DU. This setup request message 813 may optionally include the identifier of the (several) active cells controlled by the first logical DU 705 (e.g., PCI and/or NCGI) and/or the identifier of the (several) active cells controlled by the first logical DU 705 (e.g., PCI and/or NCGI), for which a mapping with the identifier of the (several) cells to be enabled is provided (as described above). This setup request message 813 may optionally include a request for a mapping between identifiers of (several) active cells controlled by the first logical DU (e.g., PCI and/or NCGI) and identifiers of (several) cells to be activated (e.g., at a second logical DU of the IAB node). This setup request message 813 may include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3)) of the RAN node CU terminating the F1 connection of the RAN node DU 811 (e.g., the source IAB donor CU 703). This message may include the TNL address (i.e., IP address) or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the RAN node CU that terminates the non-F1 (i.e., RRC) connection of the RAN node DU 811 in the event that the MT (e.g., mMT 571 of IAB node 570 or the corresponding IAB-MT of IAB node 701 of 704) has migrated to the RAN node CU (which is now a non-F1 donor CU). The RAN node CU 812 responds to the message SetupResponse 814 sent to the RAN node DU 811. It may include a list of cells activated with the logical DU, together with the associated PCI value and NGSI value to be used. It may also include a mapping between the identifiers (PCI and/or NCGI) of the cell(s) to be activated by the RAN node DU 811 and the identifiers of the active cell(s) controlled by the first logic DU 705. According to an example, the flow in FIG8b corresponds to the procedure F1 Setup described in TS 38.473 V17.2.0 section 8.2.3, and the message 813 corresponds to the message F1 Setup Request described in TS 38.473 V17.2.0 section 9.2.1.4, and the message 814 corresponds to the message F1 Setup Response described in TS 38.473 V17.2.0 section 9.2.1.5. The message F1 sets the response including an information element (IE) indicating a list of new cells to be activated. The cells to be activated are cells controlled by the RAN node DU 811 receiving the response. FIG8 c is a schematic simplified diagram 820 showing an example message flow of the procedure for removing a logic DU. This diagram shows: - a RAN node DU 821, which may be a DU of an IAB node DU such as the IAB-DU 572 of the IAB node 570 of FIG5 (and the IAB-DU1 705 of the IAB node 701 of FIG7 ), - a RAN node CU 822, which may be an IAB donor CU such as the IAB donor CU 501 of FIG5 (and the source F1 donor CU 703 of FIG7 ). The message Remove Request 823 is sent by the RAN node CU 822 to the RAN node DU 821 to request the removal of the logical DU (which is equivalent to deactivation). The RAN node DU 821 responds with the message Remove Response 814 sent to the RAN node CU 822. According to an example, the process in FIG. 8c corresponds to the procedure F1 removal described in TS 38.473 V17.2.0 section 8.2.8, and the message 823 corresponds to the message F1 Remove Request described in TS 38.473 V17.2.0 section 9.2.1.16, and the message 824 corresponds to the message F1 Remove Response described in TS 38.473 V17.2.0 section 9.2.1.7. FIG8d is a schematic simplified diagram 830 illustrating an example message flow of the process used by the logic DU to notify the IAB donor CU about a change of configuration according to an example. This diagram shows: - a RAN node DU 831, which may be a DU of an IAB node DU such as the IAB-DU 572 of the IAB node 570 of FIG5 (and the IAB-DU1 705 of the IAB node 701 of FIG7), - a RAN node CU 832, which may be an IAB donor CU such as the IAB donor CU 501 of FIG5 (and the source F1 donor CU 703 of FIG7). The message Configuration Update 833 is sent by the RAN node DU 831 to the RAN node CU 832 to indicate a configuration change of the RAN node (e.g., IAB node 570, 701) embedded in the RAN node DU 831. The configuration update message 833 may be sent by the RAN node DU 831 to indicate to the RAN node CU 832 that the F1 setup procedure is completed with the help of the target RAN node CU at the DU migration of the RAN node embedded in the RAN node DU 831, i.e., reporting a new F1 connection between the second logical DU activated in the RAN node embedded in the RAN node DU 831 (e.g., the IAB node 701) and the target F1 terminal donor CU (e.g., the target F1 terminal donor CU 707). This message 833 may include the identifier of the target RAN node CU (e.g., the target F1 donor CU 707). It may also include the identifier of the cell activated in the second logical DU of the RAN node embedded in the RAN node DU 831 (e.g., PCI and/or NCGI). Additionally or alternatively, the message 833 may include a mapping between identifiers of cells controlled by the RAN node DU 831 and identifiers of cells activated with this second logic DU. For example, referring to FIG. 7 , the message 833 is sent to the source IAB donor CU 703 by the first logic DU entity 705 activated at the IAB node 701 to indicate the completion of the F1 setup procedure toward the target IAB donor CU 707, and optionally together with identifiers of cells activated at the second logic DU 706 and optionally together with a mapping between identifiers of cells activated at the second logic DU 706 and identifiers of cells controlled by the first logic DU 705. This configuration update message 833 may include the TNL address (i.e., IP address) and/or identifier (i.e., the global NG-RAN node ID as specified in TS 38.423 V17.2.0, section 9.2.2.3) of the RAN node CU (e.g., the target F1 donor CU 707) terminating the new F1 connection of the RAN node embedded in the RAN node DU 831. The message 833 may indicate the success or failure of the F1 setup procedure. If the F1 setup procedure fails (e.g., the F1 connection cannot be established), the message 833 may also indicate the reason for the failure to establish the F1 connection. The RAN node CU 832 may respond or reply with a message Configuration Confirm 834 sent to the RAN node DU 831. According to an example, the flow in Figure 8d corresponds to the procedure gNB-DU Configuration Update described in TS 38.473 V17.2.0 chapter 8.2.4, which is modified to include the information elements described above. Message 833 corresponds to the message GNB-DU Configuration Update described in TS 38.473 V17.2.0 chapter 9.2.1.7, and message 834 corresponds to the message GNB-DU Configuration Update Confirm described in TS 38.473 V17.2.0 chapter 9.2.1.8. Message 833 can be sent after the F1 setup procedure, described with reference to Figure 8c and triggered by the RAN node CU 832 (using the procedure described with reference to Figure 8a) or by the RAN node embedded in the RAN node DU 831 with the selection of a target RAN node CU based on a pre-configured one. Pre-configuration may occur, for example, at the network integration of a RAN node embedded in RAN node DU 831. For example, the F1 setup procedure may be triggered by a RAN node CU 832 (e.g., source IAB donor CU 703/501) or by a RAN node (IAB node 701/570) embedded in RAN node DU 831 (e.g., IAB-DU1 572) determining that RAN node DU 831 is to be migrated to a target RAN node CU (e.g., target IAB donor CU 707/503). FIG. 9a is a schematic simplified diagram 900 illustrating an exemplary message flow of a procedure used by a RAN node CU for reporting activation of a cell to another RAN node CU according to an embodiment of the present invention. This figure shows two RAN nodes, RAN node CUa 901 and RAN node CUb 902, which may be two IAB donor CUs, such as two of the IAB donor CUs 501, 502 and 503 of Figure 5. With respect to the example shown in Figure 7, RAN node CUa 901 is the target F1 donor CU 707 and RAN node CUb 902 is the source F1 donor CU 703. The message Configuration Update 903 is sent by RAN node CUa 901 to RAN node CUb 902 to inform RAN node CUb 902 about activating new cell(s) in the logical DU of the RAN node DU such as IAB-DU2 706 of the IAB node 701. For example, the source F1 donor CU 703 receives a configuration update message 903 from the target F1 donor CU 707 and the configuration update message 903 includes identification information (e.g., PCI, NCIGI) identifying one or more new cells that have been enabled at the second logical DU entity (IAB-DU2 706) of the DU of the IAB node 701. In addition, the message 903 may include a mapping between the identifiers (PCI and/or NCGI) of the (several) cells enabled at the second logical DU (IAB-DU2 706) and the identifiers of the (several) active cells controlled by the first logical DU (IAB-DU1 705). The RAN node CUb 902 responds with a message Configuration Confirm 904 sent to the RAN node CUa 901. According to an example, Figure 9a corresponds to the procedure NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 8.42, and message 903 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 9.1.3.4, and message 904 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE CONFIRM described in TS 38.423 V17.2.0 section 9.1.3.5. Figure 9b is a schematic simplified diagram 910 illustrating an exemplary message flow of a procedure used by a RAN node CU to coordinate with another RAN node CU to manage traffic migration (e.g., migration or release of F1 traffic, such as user/control traffic) according to an embodiment of the present invention. This figure shows two RAN nodes, RAN node CUa911 and RAN node CUb912, which may be two IAB donor CUs, such as two of the IAB donor CUs 501, 502 and 503 of Figure 5. A message transport migration request 913 is sent by RAN node CUa911 to RAN node CUb912 to request traffic migration or release in the IAB topology controlled by RAN node CUb912. For example, referring to FIG. 7 , in a situation where the MT 704 of the IAB node 701 has been migrated to a non-F1 donor CU (not shown in FIG. 7 ), the source F1 donor CU 703 may send a transport migration request 913 to the non-F1 donor CU to request the release of traffic (e.g., F1 traffic) migrated to the topology of the non-F1 donor CU (i.e., when the F1 traffic is now to be routed from the target F1 donor CU 707 through the IAB topology managed by the non-F1 donor CU). Alternatively, in the case where the MT 704 of the IAB node 701 has been migrated to a non-F1 donor CU (not shown in FIG. 7 ), the target F1 donor CU 707 may send a transport migration request 913 to the non-F1 donor CU to request that traffic (e.g., F1 traffic) be migrated to the topology of the non-F1 donor CU (i.e., when the F1 traffic is now to be routed from the target F1 donor CU 707 through the IAB topology managed by the non-F1 donor CU). The RAN node CUb 912 responds with a message transport migration response 914 sent to the RAN node CUa 901 to accept or reject the request. Depending on the circumstances, FIG. 9 b may correspond to the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. Message 913 corresponds to the IAB Transport Migration Management Request message specified in TS 38.423 V17.2.0 Section 9.1.4.2, and message 914 corresponds to the IAB Transport Migration Management Response message specified in TS 38.423 V17.2.0 Section 9.1.4.3. Figure 9b may also correspond to the IAB Transport Migration Modification Procedure specified in TS 38.423 V17.2.0 Section 8.5.3. Message 913 corresponds to the IAB Transport Migration Modification Request message specified in TS 38.423 V17.2.0 Section 9.1.4.4, and message 914 corresponds to the IAB Transport Migration Modification Response message specified in TS 38.423 V17.2.0 Section 9.1.4.5. FIG. 10 a is a flow chart showing an exemplary method 1000 according to one or more embodiments of the present invention, which is performed at a source IAB donor CU for use in a migration procedure (or in a portion of a migration procedure) in which a distributed unit DU of an IAB node is migrated from one IAB topology managed by the source IAB donor CU to another IAB topology managed by a target IAB donor CU. The method 1000 is used to manage the migration of the DU of the IAB node toward the target IAB topology at a source F1-terminal donor CU of the IAB node. For example, with reference to the IAB communication system shown and described in reference FIG. 5 , the source IAB donor CU performing the method 1000 may be the IAB donor CU 501 (e.g., the F1-terminal donor CU of the IAB node 570 through which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501. The migration procedure may involve the migration of DUs 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003 managed by the IAB donor CU 503 (which is a target IAB donor CU). Referring to FIG. 7 , the IAB node may be an IAB node 701 and the migration procedure may involve the migration of DUs of the IAB node 701 from a source F1 donor CU 703 to a target F1 donor CU 707. The method 1000 shown and described in FIG. 10 a may be performed by software components and/or hardware components. The source IAB donor CU may be implemented in the communication device 400 as shown in and described with reference to FIG. 4 , wherein the method as shown in and described with reference to FIG. 10 a is executed by one or more processing units such as the central processing unit 411. At step 1001, a source F1 end donor CU (e.g., donor CU 501 of FIG. 5 (703 of FIG. 7)) determines that a DU of an IAB node (e.g., IAB node 570 of FIG. 5 (701 of FIG. 7)) is to be migrated from the source F1 donor CU 501, 703 to a target F1 donor CU, such as donor CU 503 of FIG. 5 (707 of FIG. 7). For example, the source F1 donor CU 503, 707 determines that a DU of an IAB node (e.g., IAB node 570) is to be migrated toward a target F1 donor CU, such as donor CU 503. For example, the source F1 donor CU 503, 707 determines that a DU of an IAB node (e.g., IAB node 570) is to be migrated toward a target F1 donor CU, such as donor CU 503. 501, 703 may determine that the DU of the IAB node 570, 701 is to be migrated in response to determining that the migration of the MT of the IAB node 570, 701 toward the new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining that a DU is to be migrated are described above. Details of how the source F1 donor CU 501, 703 determines the target F1 donor CU 503, 707 are also described above. At step 1002, the source F1 terminal donor CU 501, 703 will be used to establish the target IAB donor CU 8a. The source F1 donor CU 501, 703 sends a request for a new F1 connection (i.e., a new F1 connection) between the source F1 end donor CU 501, 703 and the IAB node 570, 701 (i.e., a new F1 connection) (e.g., a new F1 associated with the target IAB donor CU) to the IAB node. For example, the source F1 end donor CU 501, 703 sends a request for a new F1 connection to the IAB node 570, 701 to be migrated. The request may be the configuration request 803 described with reference to FIG. 8a. The source F1 donor CU 501, 703 may send information indicating that the F1 connection is for the purpose of DU migration towards a target IAB donor CU (e.g., information indicating that the request for establishing the F1 connection is a DU migration of a DU of the IAB node) and/or information indicating the number of cells to be activated at a second logical DU entity of the DU of the IAB node to the IAB node. The source F1 donor CU 501, 703 may optionally send identifiers (e.g., PCI and/or NCGI) of the active cell(s) controlled by the first logical DU 705, for which a mapping with identifiers of the cells to be activated (e.g., at the second logical DU to be activated) is provided. Optionally, at step 1003, the source F1 terminal donor CU 501, 703 sends identification information for identifying the target IAB donor CU 503, 707 to the IAB node 570, 701. The identification information may be the TNL address (i.e., IP address) of the target IAB donor CU 503, 707. For example, the source F1 terminal donor CU 501, 703 sends the address of the target F1 donor CU for the new F1 connection to the IAB node to be migrated. In the case where the IAB-MT 704 has been migrated to a non-F1 donor CU (which may be referred to as an RRC donor CU), the source F1 terminal donor CU may be used to send the target F1 donor CU address to the IAB node to be migrated. The identification information sent by 501 and 703 may include the address of the non-F1 donor CU (although the IAB node 701 may already have this information) to identify the non-F1 donor CU as the target F1 donor CU. The source F1 terminal donor CU 703 may receive identification information (e.g., an identifier) from the target F1 donor CU 707 or from the IAB node 570, 701, the identification information identifying one or more new cells that have been enabled at the second logical DU entity of the DU of the IAB node, optionally together with mapping information indicating a mapping between the identification information (e.g., an identifier) of the one or more new or target cells enabled at the second logical DU and the identification information (e.g., an identifier) of the source cell or active cell controlled by the first logical DU. As described above, the DU of the IAB node has a first logical DU entity with an F1 connection to the source F1 terminal donor CU 703, and a second logical DU entity is enabled to perform DU migration (e.g., establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). For example, the identification information and the optional mapping information may be received in the configuration update message 903 described above. In one example, the source F1 terminal donor CU 703 may send a handover request to the target F1 donor CU 707, the handover request being used to request that one or more user equipments (UEs, such as UE 708) to be served by the IAB node 701 be handed over from the source F1 terminal donor CU 703 to the target F1 donor CU 707 and being used to identify one or more target cells (e.g., candidate target cells) for each UE. The selection of the target cell for the UE may be based on a measurement report provided by the UE (e.g., an indication of the signal strength detected by the UE for one or more cells) or based on a mapping between an identifier of the target cell enabled at the second logical DU and an identifier of the source cell(s) controlled by the first logical DU. For example, the source F1 terminal donor CU 703 may select one or more of the new cells that have been activated at the second logical DU entity 706 as one or more candidate target cells for each of one or more UEs served by the IAB node based on the mapping information received from the target F1 donor CU 707 or the IAB node 701. The use of mapping avoids waiting for measurement reports from the UE to trigger the handover procedure. In response to receiving a handover confirmation from the target F1 donor CU 707 indicating that the handover of one or more UEs has been accepted and identifying a target cell for each UE, the source F1 terminal donor CU 703 sends configuration information for configuring each of the one or more UEs for the respective target cells to the IAB node 701. The handover confirmation from the target F1 donor CU 707 may also include configuration information for configuring each of the one or more UEs for the respective target cells. The handover procedure 730 described above may be performed for these steps. After completing the handover of the one or more UEs 708 to the target F1 donor CU 707, the source F1 terminal donor CU 703 may send a request for deactivating the first logical DU entity (e.g., IAB-DU1 705) of the DU of the IAB node 701 to the IAB node 701. The request may be a deactivation request sent in a configuration request message 803 or a removal request sent in a message 823. After completing the handover of one or more UEs 708 to the target F1 donor CU 707, and when the mobile terminal MT (e.g., IAB-MT 704) of the IAB node 701 has been migrated to the non-F1 donor CU, the source F1 terminal donor CU 703 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU for requesting the release of traffic associated with the IAB node that is routed via one or more paths in the IAB topology managed by the non-F1 donor CU. 10b is a flow chart showing an exemplary method 1010 for a migration procedure (or for a portion of a migration procedure) performed at an IAB node (e.g., a mobile IAB node or mIAB node) according to one or more embodiments of the present invention, in which a distributed unit DU of the IAB node is migrated from an IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. The method 1010 is used to manage DU migration towards a target F1 terminal donor CU at an IAB node. For example, referring to the IAB communication system shown and described with reference to FIG5 , the IAB node executing the method 1010 may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501 that is a source IAB donor CU (e.g., an F1 terminal donor CU of the mobile IAB node 570 through which the mobile IAB node 570 maintains an F1 connection). The migration procedure may involve the migration of the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003 managed by the IAB donor CU 503 that is a target IAB donor CU. 7, the IAB node may be a mobile IAB node 701 and the migration procedure may involve the migration of the DU of the IAB node 701 from the source F1 donor CU 703 to the target F1 donor CU 707. The method 1010 shown and described in FIG10b may be performed by software components and/or hardware components. The IAB node may be implemented in the communication device 400 shown and described in FIG4, wherein the method shown and described in FIG10b is performed by one or more processing units such as the central processing unit 411. At step 1011, an IAB node (e.g., IAB node 570 of FIG. 5 (701 of FIG. 7) receives a request for a new F1 connection (e.g., an F1 connection between the IAB node 570, 701 and a target F1 donor CU (e.g., donor CU 503 of FIG. 5 (707 of FIG. 7)) from a source F1 terminal donor CU (e.g., donor CU 501 of FIG. 5 (703 of FIG. 7)). The request may be a configuration request 803 described with reference to FIG. 8a. In response to receiving the request for the new F1 connection, the IAB node 570, 701 then sends an F1 setup request requesting setup of the F1 connection to the target F1 donor CU. 503, 707 (step 1018). For example, the setup request may be the setup request 813 described above. The F1 setup request message sent by the IAB node may include identification information for identifying the source F1 terminal donor CU or identification information for identifying a non-F1 donor CU (which may be referred to as an RRC donor CU) when the mobile terminal MT of the IAB node has migrated to the non-F1 donor CU. The IAB node 570, 701 may identify or determine the identity of the target F1 donor CU 503, 707 in response to receiving the request for establishing an F1 connection (step 1017), and then send the F1 setup request to the identified target F1 donor CU. The IAB node 570, 701 may identify or determine the identity of the target F1 donor CU 503, 707 based on the target F1 donor CU. The target F1 donor CU may be identified by the identification information of the IAB-MT 704 (e.g., the address (e.g., TNL address/IP address) of the target F1 donor CU 503, 707 received from the source F1 donor CU 501, 703) (e.g., in a message with the configuration request 803 or sent separately), as shown in optional step 1012. In the case where the IAB-MT 704 has been migrated to a non-F1 donor CU, the identification information received at the IAB node may include the address of the non-F1 donor CU in this case, and the IAB node will identify the non-F1 donor CU as the target F1 donor CU. Alternatively, if the address of the target F1 donor CU is not received from the source F1 donor CU 501, 703, and the IAB-MT 704 is not received, the IAB-MT 704 may be received by the IAB node. 704 has been migrated to a non-F1 donor CU, then the IAB node 570, 701 identifies or determines the identity of the target donor CU 503, 707 by treating/identifying the non-F1 donor CU as a target F1 donor CU (e.g., after receiving a request to establish an F1 connection). For example, in this case, the IAB node 701 has been informed of the address of the target donor CU (e.g., TNL address/IP address) when the IAB-MT 704 was migrated to the non-F1 donor CU and can therefore identify the address of the non-F1 donor CU as the address of the target donor CU. Optionally, at step 1012, the IAB node 570, 701 receives a packet for identifying the target F1 donor CU from the source F1 terminal donor CU 501, 703. 503, 707. The identification information may include the address (e.g., TNL address/IP address) of the target F1 terminal donor CU for the new F1 connection. As another method (e.g., replacing steps 1011, 1012), which is not shown in the figure, the IAB node 570, 701 may also trigger itself to send a request for a new F1 connection and identify the target F1 donor CU based on pre-configuration. Therefore, the IAB node 570, 701 itself can determine that a new F1 connection is to be set up and can identify the IAB donor CU with which the connection is to be set up based on the pre-configuration information pre-configured at the IAB node and then can send an F1 setup request for requesting the setup of the F1 connection to the identified target IAB donor CU. As a first example, the triggering condition may be detection of the IAB node 570, 701 by a cell or cells of a neighboring IAB node via an identifier (NCGI) associated with a donor CU that is in a pre-configured list of target donor CUs. In other words, the IAB node 570, 701 may determine that a new F1 connection is to be set up (e.g., because a DU (e.g., 572) of the IAB node 570/701 is to be migrated) in response to or after detecting one or more cells of the neighboring IAB node 570, 701 and may identify the IAB donor CU with which the connection is to be set up based on the pre-configuration information, the one or more cells being associated with an IAB donor CU included in a list of candidate target IAB donor CUs pre-configured at the IAB node. As a second example, when the first F1 connection with an IAB donor CU identified by pre-configuration must be set up after establishing an RRC connection between the IAB-MT and the IAB donor CU (which depends on the physical location of the IAB node), the triggering condition is at the network integration of the IAB node. In other words, the IAB node 570, 701 may determine that a new F1 connection is to be set up at the network integration of the IAB node 570/701 (e.g., when the IAB node 570/701 is connected to the network) and the IAB node 570/701 identifies the IAB donor CU with which the F1 connection is to be set up based on the list of candidate IAB donor CUs pre-configured at the IAB node and the IAB node location. FIG. 10c shows exemplary steps performed at an IAB node (e.g., a mobile IAB node or mIAB node) to identify a target IAB donor CU according to one or more embodiments of the present invention. In one example, step 1017 of FIG. 10b may be performed by implementing steps 1013 to 1015 of FIG. 10c, which are collectively referred to as step 1016. In an alternative method where the IAB node 570, 701 itself can determine that a new F1 connection is to be set up (without receiving a request for a new F1 connection), steps 1013 to 1015 may be performed at the IAB node to identify the IAB donor CU with which the connection is to be set up based on pre-configuration information pre-configured at the IAB node. At step 1013, the IAB node 701 determines whether it has received identification information for identifying the target IAB donor CU of the F1 connection from the source IAB donor CU (or by pre-configuration) by checking whether the address of the target F1 terminal donor CU for the new F1 connection has been received. If so, at step 1015, the IAB node 701 identifies the target F1 terminal donor CU from the received identification information and the IAB node sends an F1 setup request to the identified target F1 terminal donor CU. If not, then at step 1014, the IAB node 701 identifies a non-F1 terminal donor CU (which may be referred to as an RRC donor CU) as the target F1 terminal donor CU from the received identification information and the IAB node sends an F1 setup request to its non-F1 terminal donor CU (e.g., donor CU 502). The request for a new F1 connection received at the IAB node 701 (e.g., in the configuration request 803) may include a request for one or more cells to be enabled for the second logical DU entity (e.g., IAB-DU2 706), and optionally include the identifiers (PCI and/or NCGI) of the active cell(s) controlled by the first logical DU and/or the identifiers of the active cells (e.g., PCI and/or NCGI) for which a mapping with the identifiers of the cells to be enabled is to be provided. As described above, the DU of the IAB node has a first logical DU entity having an F1 connection with the source F1 terminal donor CU 703, and a second logical DU entity is enabled to perform DU migration (e.g., establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). In one example, the IAB node 701 enables the second logical DU entity (e.g., IAB-DU2 706) in response to receiving a request to establish an F1 connection (e.g., in the configuration request 803). In both of these cases, the F1 setup request (e.g., message 813) is sent by the second logical DU entity. The F1 setup request message sent to the target F1 terminal donor CU 707 may include information indicating the number of cells to be activated with the activation of the second logical DU at the IAB node and/or information indicating that the request for establishing the F1 connection is for DU migration of the DU of the IAB node. Optionally, the F1 setup request message includes a request for a mapping between identifiers (e.g., PCI and/or NCGI) of the active cell(s) controlled by the first logical DU and identifiers of the cell(s) to be activated. In one example, after sending the F1 setup request, the IAB node 701 receives a response (e.g., setup response 814) from the target F1 end donor CU 707 including a request for one or more cells to be enabled for the second logical DU entity. The response may include identification information, such as an identifier of each of the cells to be enabled. The IAB node 701 may receive a request (e.g., a remove request 823 or a disable request in the configuration request 803) from the source F1 donor CU 703 to disable a first logical DU entity (e.g., IAB-DU1 705) of a DU of the IAB node 701 and in response to the request, the IAB node 701 disables the first logical DU entity (e.g., IAB-DU1 705). FIG. 10 d is a flow chart showing an exemplary method 1020 according to one or more embodiments of the present invention, which is executed at a target IAB donor CU for use in a migration procedure (or for use in a portion of a migration procedure) in which a distributed unit DU of an IAB node is migrated from an IAB topology managed by a source IAB donor CU to another IAB topology managed by the target IAB donor CU. The method 1020 is used to manage the migration of DUs of an IAB node at a target F1 terminal donor CU toward a target IAB topology managed by the target F1 terminal donor CU. For example, with reference to the IAB communication system shown and described in reference FIG. 5 , the target IAB donor CU executing the method 1020 may be the IAB donor CU 503 controlling the IAB topology 5003. The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501. The migration procedure may involve the migration of a DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003. Referring to FIG7 , the IAB node may be an IAB node 701 and the migration procedure may involve the migration of a DU of the IAB node 701 from a source F1 donor CU 703 to a target F1 donor CU 707. The method 1020 shown in FIG10 d and described with respect to FIG10 d may be performed by software components and/or hardware components. The target IAB donor CU may be implemented in the communication device 400 as shown in FIG. 4 and described with reference to FIG. 4 , wherein the method as shown in FIG. 10 and described with reference to FIG. 10 d is executed by one or more processing units such as the central processing unit 411. At step 1021, the target IAB donor CU (such as the IAB donor CU 503 of FIG. 5 (707 of FIG. 7 )) receives an F1 setup request for requesting to establish an F1 connection between the target IAB donor CU and the IAB node from an IAB node (such as the IAB node 570 of FIG. 5 (701 of FIG. 7 )). For example, the setup request may be the setup request 813 described above. The F1 setup request message sent by the IAB node may include identification information for identifying the source F1 terminal donor CU or identification information for identifying a non-F1 donor CU (which may be referred to as an RRC donor CU) when the mobile terminal MT of the IAB node has migrated to the non-F1 donor CU. The F1 setup request message may include information indicating the number of cells to be activated with the activation of the second logical DU at the IAB node and/or information indicating that the request for establishing the F1 connection is about DU migration of a DU of the IAB node. Optionally, the F1 Setup request message may include identifiers of active cells controlled by the first logical DU (e.g., PCI and/or NCGI) and/or identifiers of active cells having a mapping to be provided therefor with identifiers of cells to be enabled (e.g., PCI and/or NCGI). The F1 Setup request message may additionally or alternatively include a request for a mapping between identifiers of active cell(s) controlled by the first logical DU (e.g., PCI and/or NCGI) and identifier(s) of cell(s) to be enabled (e.g., at a second logical DU of the IAB node). At step 1022, the target IAB donor CU 503, 707, in response to receiving the F1 setup request, sends a response (e.g., setup response 814) to the IAB node 570, 701, the response including a request for one or more cells to be activated for a second logical DU entity of the IAB node 570, 701. As described above, the DU of the IAB node has a first logical DU entity having an F1 connection with the source F1 terminal donor CU 703, and the second logical DU entity is activated to perform the DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). The response may include identification information identifying one or more cells to be enabled (e.g., an identifier of each of the cells to be enabled). Optionally, the response may also include a mapping between identifiers of the (several) currently used cells controlled by the first logical DU (e.g., PCI and/or NCGI) and the identifiers of the (several) cells to be enabled. The target IAB donor CU 503, 707 or IAB node 570, 701 may send identification information identifying each of the one or more new cells that have been enabled at the second logical DU entity of the DU of the IAB node 570, 701 to the source IAB donor CU 501, 703. The target IAB donor CU 503, 707 or IAB node 570, 701 may also send mapping information to the source IAB donor CU 501, 703. In one example, the target F1 donor CU 707 may receive from the source F1 terminal donor CU 703 a request for one or more user equipments (UEs, such as UE 708) to be served by the IAB node 701 to be handed over from the source F1 terminal donor CU 703 to the target F1 donor CU 707, and for identifying one or more target cells (e.g., candidate target cells) for each UE. The selection of the target cell for the UE may be based on a measurement report provided by the UE (e.g., an indication of the signal strength detected by the UE for one or several cells), or based on a mapping between an identifier of a target cell activated at the second logical DU and an identifier of a source cell controlled by the first logical DU. For example, the source F1 terminal donor CU 703 may select one or more of the new cells that have been activated at the second logical DU entity 706 as one or more candidate target cells for each of one or more UEs served by the IAB node 701 based on mapping information received from the target F1 donor CU 707 or the IAB node 701. The use of mapping avoids waiting for measurement reports from the UE to trigger the handover procedure. When the target F1 donor CU 707 determines that the handover of one or more UEs is acceptable, the target F1 donor CU 707 sends a handover confirmation to the source F1 terminal donor CU 703 indicating that the handover of the one or more UEs has been accepted and identifying the target cell for each UE. The handover confirmation may also include configuration information for configuring each of the one or more UEs for the respective target cell. The handover procedure 730 described above may be performed for these steps. After completing the handover of one or more UEs 708 to the target F1 donor CU 707, and when the mobile terminal MT (e.g., IAB-MT 704) of the IAB node 701 has been migrated to the non-F1 donor CU, the target F1 donor CU 707 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU for requesting traffic migration for traffic associated with the IAB node routed through one or more paths in the IAB topology managed by the non-F1 donor CU. Thus, by sending a request to the IAB node for establishing an F1 connection between the IAB node and the target IAB donor CU, the source F1 donor CU (e.g., source IAB donor CU) facilitates DU migration of the IAB node with or without MT migration. Furthermore, in response to receiving a request to establish an F1 connection, the IAB node may identify (e.g., via identification information sent by a source donor CU or by determining a non-F1 donor CU to be a target donor CU when no identification information is sent by the source donor CU) a target donor CU to enable handover of a UE served by the IAB node to the target donor CU. A determination that a DU of the IAB node is to be migrated may be triggered by an event. The event or events that trigger the determination that a DU of the IAB node is to be migrated may be left to the implementation scheme. For example, the decision to migrate a DU may be based on detection of an MT migration from a first IAB topology toward a second IAB topology, and based on a known (predefined) trajectory indicating to the source F1 donor CU that the MT will later migrate to an IAB node of a third IAB topology. In this case, to avoid the messaging for DU migration/UE handover towards the second IAB topology, the DU is migrated directly towards the third IAB topology. Another triggering event may be when the processing load level is detected to be higher than a predetermined threshold in the source F1 donor CU. DU migration is then triggered and the selection of the target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU. In other words and as an overview, the triggering events and decision procedures for the F1 terminal donor CU to perform mobile IAB-DU (mIAB-DU) migration of the mobile IAB node can be left to the implementation scheme. Furthermore, for flexible IAB network management, it should be allowed to migrate the mIAB-DU towards a target F1 terminal donor CU (which may be referred to as an RRC terminal donor CU) that is different from a non-F1 terminal donor CU (which may be referred to as an RRC terminal donor CU) of a co-located mobile IAB-MT (mIAB-MT). Therefore, an IAB-DU of a mobile IAB node may migrate towards a target F1 terminal donor CU that is different from a non-F1 terminal donor CU of a co-located IAB-MT. Then, when the F1 donor CU serving the mIAB-DU decides whether to perform the mIAB-DU migration, it may request the mobile IAB node to activate a second logical DU to be served by the target F1 donor CU identified in the request. For example, an F1 donor CU may trigger a gNB-CU configuration update procedure to request the mobile IAB node to set up a new F1 connection with an identified target F1 donor CU. Next, an activated logical DU triggers the F1 setup procedure with the target F1 donor CU. If the request from the F1 donor CU does not identify the target F1 donor CU, the activated logical DU triggers the F1 setup procedure with the non-F1 terminal donor CU of the mobile IAB node. Therefore, when requested by its serving F1 donor CU to set up a new F1 connection, a mobile IAB node may execute the F1 setup procedure with the target F1 donor CU indicated in the request. In the absence of such an indication, the mobile IAB node executes the F1 setup procedure with the non-F1 terminal donor CU. To trigger a handover for the UE served by the mobile IAB node during the mIAB-DU migration, the target F1 donor CU may notify the source F1 donor CU about the activation of the new cell(s) in the second logical DU of the mobile IAB node. To this end, the target F1 donor CU may perform a configuration update procedure with the NG-RAN node of the source F1 donor CU. Once notified, the source F1 donor CU may send a handover command to the UE served by the migrating mobile IAB node. Therefore, the NG-RAN Node Configuration Update procedure may be used by a target F1 terminal donor CU of a mobile IAB node to inform a source F1 terminal donor CU about the ID of the cell served by a second logical DU of the mobile IAB node. With regard to the procedure for triggering, executing and reporting F1 setup at DU migration, it may be observed that, to trigger a DU migration of a mobile IAB node determined by a source F1 donor CU, the following information may be delivered to the mobile IAB node: - an indication requesting a DU migration (mandatory), meaning that the F1 setup procedure should be initiated with the target logical DU. - an identifier of the target F1 donor CU (optional). This information element is relevant when migrating a DU towards a target F1 donor CU of a non-F1 donor CU that is different from the serving co-located mobile IAB-MT. In the absence of this indication, the mobile IAB node shall perform the F1 setup procedure towards the non-F1 terminal donor CU. Given the lower number of bits used for this signaling, it may not be necessary to establish a new F1AP procedure. Furthermore, this is about F1 interface management and therefore the gNB-CU configuration update procedure seems applicable for this signaling. It is then proposed that the gNB-CU configuration update procedure can be used by a source CU to trigger the F1 setup procedure for the purpose of DU migration towards a target CU. In the F1 Setup Request message, the mobile IAB node shall pass the following information to the target F1 donor CU: - The F1 Setup Request is an indication of DU migration. Thanks to this information element, the target F1 donor CU understands the content and can handle the request correctly. - PCI of the active cells at the source logical DU. This information element helps the target F1 donor CU to select the appropriate PCI for the cells to be enabled at the target logical DU. Next, it is proposed that in the scope of DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU should include an explicit indication that the F1 setup is related to the DU migration of the mobile IAB node, and it should include a list of PCIs at the source logical DU of this mobile IAB node. To report the result of the F1 setup procedure for the purpose of DU migration of the mobile IAB node, the mobile IAB node may pass the following information to the source F1 donor CU: - an indication of the success or failure of the F1 setup and, in case of failure, the reason for the failure. - the ID of the cell activated at the target logical DU by the target F1 donor CU. - a mapping between the ID of the cell activated at the target logical DU and the ID of the cell currently in use at the source logical DU as an optional information element. Due to this mapping, it should be possible to limit the scope of measurements to be performed at the UE, which may even avoid measurement reports from the UE to initiate the handovers. Since the gNB-CU Configuration Update procedure seems suitable for triggering F1 Setup, the gNB-DU Configuration Update procedure also seems to be a good candidate for the existing F1AP procedure to report the results of F1 Setup. It is then proposed that the gNB-DU Configuration Update procedure can be used by a mobile IAB node to report the results of the F1 Setup procedure towards a target CU to the source CU of the DU migration, and it is proposed that the mapping between the cell IDs activated at the target logical DU and the active cell IDs at the source logical DU be included as one of the optional information elements in the reporting of the F1 Setup results. With regard to providing identification information to the F1 donor CU, it can be observed that, at this CU, when a DU of a mobile IAB node migrates towards a target F1 donor CU that is different from a non-F1 donor CU of the co-located mobile IAB-MT, the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT should be provided to the target F1 donor CU. Due to these information elements, the target F1 donor CU will be able to perform transport migration management procedures towards the non-F1 donor CU. In addition, during network integration of the mIAB MT and the co-located mIAB-DU into different donor CUs, the UE XnAP ID of the mIAB-MT assigned by the CU of the MT and the gNB-ID of the CU of the MT should be known to the CU of the mIAB-DU. Considering the network integration scenario, there are two options: - Option 1: The mobile IAB node provides identification information based on information received from the non-F1 donor CU (i.e., the CU of the mIAB-MT), - Option 2: The non-F1 donor CU provides identification information once it knows the identifier of the F1 donor CU (i.e., the CU of the mIAB-DU) from the mobile IAB node. The disadvantage of Option 2 is that it requires the F1 donor CU to generate the UE XnAP ID for the mIAB-MT to provide it to the mobile IAB node which will pass it to the non-F1 donor CU together with the identifier of the F1 donor CU. This UE XnAP ID generated by the F1 donor CU will be used by the non-F1 donor CU in the XnAP message sent to the F1 donor CU using Option 2. Therefore, Option 1 appears to have less regulatory impact than Option 2. If Option 1 is adopted, and for consistency reasons, the mobile IAB node should also provide identification information associated with the non-F1 donor CU to the target F1 donor CU at DU migration. This can be done via the same F1AP signaling as for the network integration scenario. Going forward, the mobile IAB node should also provide identification information associated with the target non-F1 donor CU to its F1 donor CU at (continuous) MT migrations while still using the same F1AP signaling. To cover all scenarios considered above, the F1AP procedure gNB-DU configuration update is appropriate as it can be triggered at any time. Next, it is proposed that the gNB-DU configuration update procedure can be used by the mobile IAB node to notify the F1 donor CU about the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at this CU. This procedure can be applied during network integration, DU migration and MT migration of the mobile IAB node. It can be noted that the source donor CU of the mIAB-MT can send the information on the target donor CU of the mIAB-MT to the donor CU of the mIAB-DU after completing the IAB-MTHO. In fact, it is proposed to be compatible with this description because the source non-F1 donor CU (i.e., the source donor CU of the mIAB-MT) will pass the information to the F1 donor CU (i.e., the donor CU of the mIAB-DU), not directly, but through the mobile IAB node. In addition, it is proposed that the identifiers of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at this CU may be included in the F1 setup request sent to the target F1 donor CU at the DU migration. The absence of these information elements in the F1 setup request may indicate that the non-F1 donor CU is also the target F1 donor CU. Next, it is proposed that in the scope of DU migration of the mobile IAB node, the F1 setup request sent to the target F1 donor CU may also include the identifiers of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at this CU. Although the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. A person skilled in the art will appreciate that various changes and modifications may be made thereto without departing from the scope of the invention as defined by the appended claims. All features disclosed in this specification (including any appended claims, abstracts, and drawings) and/or all steps of any method or process disclosed may be combined in any combination, except combinations that would make at least some of these features and/or steps mutually exclusive. Each feature disclosed in this specification (including any appended claims, abstracts, and drawings) may be replaced by an alternative feature that provides the same, equivalent, or similar functionality, unless expressly stated to be prohibited. Therefore, unless expressly stated to be prohibited, each disclosed feature is merely an example of a general series of equivalent or similar features. In the scope of the patent application, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recorded in mutually different dependent clauses does not mean that the combination of these features cannot be used to advantage. In the above embodiments, the functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted in a computer-readable medium as one or more instructions or program codes, and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to tangible media such as data storage media, or communication media including any media that facilitates the transfer of a computer program from one place to another (e.g., according to a communication protocol). In this manner, computer-readable media may generally correspond to (1) non-transitory tangible computer-readable storage media; or (2) communication media such as signals or carrier waves. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, codes and/or data structures used to implement the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately defined as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave), then the coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave) is included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, or other transient media, and instead refer to non-transient, tangible storage media. The disk or disc used in this article includes a mini disc (CD), a laser disc, an optical disc, a digital versatile disc (DVD), a floppy disk, and a Blu-ray disc, wherein a disk generally refers to a disk that reproduces data through magnetic principles, while a disc reproduces data through laser optics. Combinations of the above may also be included in the scope of computer-readable media.

30: Header 100: Communication system 101: Wired link 105: Vehicle 108: Building 110: Remote core network 120: Master base station/IAB donor 121: IAB node 122: IAB node 123: Mobile IAB station/Mobile IAB node 131: User equipment 132: User equipment 133: User equipment 134: User equipment 135: User equipment 136: User equipment 210: Box 211: Box 212: Functional interface 220: Sublayer 301: Field 302: Field 304: Field 305: Field 306: Field 307: Payload part 400: Communication device 402: Communication interface 403: Radio communication network 404: Data storage component/hard disk 405: Disk drive 406: Disk 407: Read-only memory 409: Screen 410: Keyboard 411: Central processing unit 412: Random access memory 413: Communication bus 500: IAB communication system 501: IAB-donor CU/F1 donor CU 502: IAB-donor CU/donor CU 503: IAB-donor CU/donor CU 504: IAB donor DU 505: IAB donor DU 506: IAB donor DU 507: IAB donor DU 508: Wired backload 510: IAB node 511: MT part or unit 512: DU part 520: IAB node 530: IAB-node 540: IAB node 550: IAB node 560: IAB node 570: IAB node 571: MT part 572: DU part or unit 580: User equipment 590: Arrow 600: IAB node architecture 601: IAB node 602: User equipment 611: Logical DUIAB-DU1 612: Logical DUIAB-DU2 621: Access link 622: Link 700: Simplified schematic diagram 701: IAB node 702: Core network 703: Source F1 donor CU/F1 terminal donor CU 704: IAB-MT 705: IAB-DU1 706: IAB-DU2 707: Target F1 donor CU 708: User equipment 710: Carrying 711: Backhauling 712: Data radio carrying 720: First step 730: Handover procedure 735: Procedure 740: Carrying 741: Backhauling 742: Data radio carrying 800: Simplified schematic diagram 801: RAN node DU 802: RAN node CU 803: Message 804: Message 810: Simplified schematic diagram 811: RAN node DU 812: RAN node CU 813: message 814: message 820: schematic simplified diagram 821: RAN node DU 822: RAN node CU 823: message 824: message 830: schematic simplified diagram 831: RAN node DU 832: RAN node CU 833: message 834: message 870: mobile IAB node 900: schematic simplified diagram 901: RAN node CUa 902: RAN node CUb 903: message 904: message 910: schematic simplified diagram 911: RAN node CUa 912: RAN node CUb 913: message 914: message 1000: method 1001: step 1002: step 1003: step 1010: method 1011: step 1012: step 1013: step 1014: step 1015: step 1016: step 1017: step 1018: step 1020: method 1021: step 1022: step 1106: disk 5001: IAB topology 5002: IAB topology 5003: IAB topology 5050: backlink

By way of example only, different aspects of the present invention will now be described with reference to the following accompanying drawings, in which: [FIG. 1] is a schematic diagram of a communication system in which the present invention may be implemented according to one or more embodiments; [FIG. 2a and FIG. 2b] schematically illustrate the stacking of some protocol layers involved in IAB operation; [FIG. 3] is a schematic diagram illustrating the format of a BAP protocol data unit (PDU) or packet; [FIG. 4] is a block diagram of an exemplary wireless communication device according to an embodiment of the present invention; [FIG. 5] is a schematic diagram of an exemplary IAB communication system (or IAB network system) in which embodiments and examples of embodiments of the present invention may be implemented; [FIG. 6] is a schematic simplified diagram illustrating an example of an IAB node architecture enabling its DU to migrate from a source IAB topology to a target IAB topology; [FIG. 7] is a simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention to perform DU migration of an IAB node including handover of a UE served by a migrating IAB node; [FIG. 8a] is a simplified diagram illustrating an exemplary message flow of a procedure for performing activation of a logical DU according to one or more embodiments of the present invention; [FIG. 8b] is a simplified diagram illustrating an exemplary message flow of a procedure for setting a logical DU; [FIG. 8c] is a simplified diagram illustrating an example message flow of a procedure for removing a logical DU; [Figure 8d] is a simplified diagram showing an exemplary message flow of a procedure used by a logic DU to notify a RAN node CU of a change in configuration; [Figure 9a] is a simplified diagram illustrating an exemplary message flow of a procedure used by a RAN node CU to report activation of a cell to another RAN node CU; [Figure 9b] is a simplified diagram illustrating an exemplary message flow of a procedure used by a RAN node CU to coordinate management of transport migration with another RAN node CU; [Figure 10a] is a flow chart of an exemplary method according to an embodiment of the present invention for managing DU migration of an IAB node at a source F1 terminal donor CU of the IAB node toward a target IAB topology; [FIG. 10b] is a flowchart of an exemplary method according to an embodiment of the present invention, which is used to manage DU migration towards a target IAB topology at an IAB node; [FIG. 10c] is a flowchart showing exemplary steps performed at an IAB node to identify a target IAB donor CU according to one or more embodiments of the present invention; [FIG. 10d] is a flowchart of an exemplary method according to an embodiment of the present invention, which is used to manage DU migration of an IAB node at a target IAB donor CU towards a target IAB topology managed by the target IAB donor CU.

500:IAB communication system

501: Donor 1CU

502: Donor 2CU

503: Donor 3CU

504: Donor 1DU1

505: Donor 2DU1

506: Donor 2DU2

507: Donor 3DU1

508: Wired backload

510:IAB node

511:MT part or unit

512:DU part

520:IAB node

530:IAB-Node

540:IAB node

550:IAB node

560:IAB node

570:IAB node

571:MT part

572:DU part or unit

580: User equipment

590:arrow

5001:IAB Topology

5002:IAB Topology

5003:IAB Topology

5050:Return link

5060:Return link

Claims (55)

A method for use in a migration procedure, in which a distributed unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method comprising at the source IAB donor CU: Determining that the DU of the IAB node is to be migrated from the one IAB topology of the source IAB donor CU to the other IAB topology of the target IAB donor CU; Sending a request for establishing an F1 connection between the IAB node and the target IAB donor CU to the IAB node. The method of claim 1, further comprising sending identification information for identifying the target IAB donor CU to the IAB node. The method of claim 2, wherein the identification information used to identify the target IAB donor CU for the F1 connection includes an address associated with the target IAB donor CU. The method of any one of claims 1 to 3, further comprising sending information to the IAB node indicating the number of cells to be enabled at the second logical DU entity of the DU of the IAB node. The method of any of the preceding claims, further comprising sending identification information identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node to the IAB node. The method of any of the preceding claims, further comprising sending information to the IAB node indicating that the request for establishing the F1 connection is related to the migration of the DU of the IAB node. The method of any of the preceding claims, further comprising receiving, from the target IAB donor CU or from the IAB node, identification information identifying each of one or more new cells that have been enabled at a second logical DU entity of the DU of the IAB node. A method as in any of the aforementioned request items, further comprising receiving mapping information indicating a mapping between identification information of one or more new cells that have been activated at a second logical DU entity of the DU of the IAB node and identification information of one or more current cells controlled by a first logical DU entity of the DU of the IAB node. A method as in any of the aforementioned request items, further comprising: Sending a handover request to the target IAB donor CU, the handover request being used to request that one or more user equipments (UEs) to be served by the IAB node be handed over from the source IAB donor CU to the target IAB donor CU and being used to identify one or more candidate target cells for each UE. The method of claim 8 and claim 9 further comprises: selecting one or more of the new cells as one or more candidate target cells for each of one or more UEs served by the IAB node based on the mapping information, wherein the handover request includes information for identifying the selected one or more candidate target cells. The method of claim 9 or claim 10, further comprising: In response to receiving a handover confirmation from the target IAB donor CU indicating that the handover of the one or more UEs has been accepted and identifying the target cell for each UE, sending configuration information for configuring each of the one or more UEs for the respective target cell to the IAB node. The method of any one of claims 9 to 11 further comprises: After completing the handover of the one or more UEs to the target IAB donor CU, sending a request for deactivating the first logical DU entity of the DU of the IAB node having an F1 connection with the source IAB donor CU to the IAB node. The method of any one of claim items 9 to 12 further comprises: After completing the handover of the one or more UEs to the target IAB donor CU and when the mobile terminal (MT) of the IAB node has been migrated to the non-F1 donor CU, a traffic migration request for requesting traffic release for traffic associated with the IAB node routed via one or more paths in the IAB topology managed by the non-F1 donor CU is sent to the non-F1 donor CU. The method of any of the preceding claims, wherein determining that the DU of the IAB node is to be migrated comprises determining that the DU of the IAB node is to be migrated in response to determining that migration of the MT of the IAB node toward a new parent IAB node is complete. A method for use in a migration procedure in which a distributed unit (DU) of an integrated access backhaul (IAB) node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method comprising at the IAB node: receiving a request from the source IAB donor CU to establish an F1 connection between the target IAB donor CU and the IAB node; sending an F1 setup request for requesting setup of the F1 connection to the target IAB donor CU. The method of claim 15, further comprising: Identifying the target IAB donor CU in response to receiving the request for establishing an F1 connection, wherein sending comprises sending the F1 setup request to the identified target IAB donor CU. The method of claim 15 or claim 16 further comprises: Receiving identification information from the source IAB donor CU for identifying the target IAB donor CU for the F1 connection. The method of claim 16 or claim 17, wherein identifying the target IAB donor CU comprises identifying the target IAB donor CU from the received identification information. The method of claim 16, wherein identifying comprises: Determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; In response to determining that identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU, identifying the target IAB donor CU from the received identification information. The method of claim 16, wherein identifying comprises: determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has not been received from the source IAB donor CU and the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, identifying comprises identifying the non-F1 donor CU as the target IAB donor CU, wherein sending comprises sending the F1 setup request to the non-F1 donor CU identified as the target IAB donor CU. The method of claim 17, further comprising: After receiving the request for establishing an F1 connection, determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; Wherein, in response to determining that the identification information for identifying the target IAB donor CU for the F1 connection has been received, sending includes sending the F1 setup request to the target IAB donor CU identified by the received identification information. The method of claim 15 or claim 16 further comprises: After receiving the request for establishing an F1 connection, determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; wherein, in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has not been received from the source IAB donor CU and the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, identifying the non-F1 donor CU as the target IAB donor CU, wherein sending comprises sending the F1 setup request to the non-F1 donor CU identified as the target IAB donor CU. A method as in any one of claims 17 to 19 or claim 21, wherein the identification information used to identify the target IAB donor CU for the F1 connection includes an address associated with the target IAB donor CU. A method as in any one of claims 15 to 23, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection to the source IAB donor CU, the method further comprising receiving information from the source IAB donor CU indicating the number of cells to be activated at a second logical DU entity of the DU of the IAB node. The method of any one of claims 15 to 24, further comprising receiving, from the source IAB donor CU, identification information for identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node. The method of any one of claims 15 to 25, further comprising receiving information from the source IAB donor CU indicating that the request for establishing an F1 connection is related to a migration of the DU of the IAB node. A method as in any one of claims 15 to 26, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection with the source IAB donor CU, wherein the request for establishing the F1 connection includes a request for one or more cells to be enabled for a second logical DU entity, wherein sending includes sending the F1 setup request to the target IAB donor CU by the second logical DU entity. A method as in any one of claims 15 to 26, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection with the source IAB donor CU, the method further comprising: In response to receiving the request for establishing the F1 connection, enabling a second logical DU entity for establishing the F1 connection with the target IAB donor CU, wherein sending includes sending the F1 setup request to the target IAB donor CU via the second logical DU entity. The method of any one of claim 15 to claim 26 or claim 28, further comprising: After sending the F1 setup request, receiving a response from the target IAB donor CU, the response comprising a request for one or more cells to be enabled for the second logical DU entity; Enabling the one or more cells based on the received response. The method of claim 29, wherein the response includes identification information for identifying each of the one or more cells to be enabled. The method of claim 29 or claim 30, further comprising sending identification information for identifying each of the one or more new cells that have been enabled at the second logical DU entity to the source IAB donor CU. A method as in any one of claims 29 to 31, further comprising sending mapping information indicating a mapping between identification information of one or more new cells that have been enabled at the second logical DU entity and identification information of one or more active cells controlled by the first logical DU entity of the DU of the IAB node to the source IAB donor CU. The method of any one of claim 24 to claim 32, further comprising: Receiving a request from the source IAB donor CU to deactivate the first logical DU entity of the DU of the IAB node having an F1 connection to the source IAB donor CU. The method of claim 33 further comprises: In response to receiving the request to deactivate the first logical DU entity, deactivate the first logical DU entity. A method as in any one of claim 15 to claim 34, wherein sending the F1 setup request includes sending an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes identification information for identifying the source IAB donor CU or identification information for identifying the non-F1 donor CU when the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU. The method of any one of claims 15 to 35, wherein sending the F1 setup request comprises sending an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes information indicating a number of cells to be enabled with activation of a second logical DU at the IAB node. A method as in any one of claim 15 to claim 36, wherein sending the F1 setup request comprises sending an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message comprises identification information for identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node. A method as in any one of claim 15 to claim 37, wherein sending the F1 setup request comprises sending an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes information indicating that the request for establishing the F1 connection is related to migration of the DU of the IAB node. A method as in any one of claim 15 to 38, wherein sending the F1 setup request includes sending an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes a request for a mapping between identification information of one or more new cells to be activated at a second logical DU entity of the DU of the IAB node and identification information of one or more existing cells controlled by a first logical DU entity of the DU of the IAB node. A method for use in a migration procedure in which a distributed unit (DU) of an integrated access backhaul (IAB) node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method comprising at the target IAB donor CU: Receiving an F1 setup request from the IAB node for requesting to set up an F1 connection between the target IAB donor CU and the IAB node; Sending a response to the IAB node, the response including a request for one or more cells to be activated for a second logical DU entity for the IAB node. A method as in claim 40, wherein receiving the F1 setup request includes receiving an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes identification information for identifying the source IAB donor CU or identification information for identifying the non-F1 donor CU when the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU. The method of claim 40 or claim 41, wherein receiving the F1 setup request comprises receiving an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes information indicating a number of cells to be enabled with activation of a second logical DU at the IAB node. A method as in any of claim 40 to 42, wherein receiving the F1 setup request comprises receiving an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message comprises identification information for identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node. A method as in any one of claim 40 to 43, wherein receiving the F1 setup request comprises receiving an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes information indicating that the request for establishing the F1 connection is related to migration of the DU of the IAB node. A method as in any of claim items 40 to 44, wherein receiving the F1 setup request includes receiving an F1 setup request message for requesting setup of the F1 connection, wherein the F1 setup request message includes a request for a mapping between identification information of one or more new cells to be activated at a second logical DU entity of the DU of the IAB node and identification information of one or more existing cells controlled by a first logical DU entity of the DU of the IAB node. The method of any one of claims 40 to 45, further comprising sending identification information for identifying each of the one or more new cells that have been enabled at the second logical DU entity of the DU of the IAB node to the source IAB donor CU. A method as in any of claims 40 to 46, wherein the response includes identification information for identifying each of the one or more cells to be enabled. A method as in any one of claims 40 to 47, further comprising sending mapping information indicating a mapping between identification information of one or more new cells to be activated for the second logical DU entity and identification information of one or more existing cells controlled by the first logical DU entity of the DU of the IAB node to the source IAB donor CU. The method of any one of claim 40 to claim 48, further comprising: receiving a handover request from the source IAB donor CU, the handover request being used to request that one or more user equipment (UE) served by the IAB node be handed over from the source IAB donor CU to the target IAB donor CU and being used to identify one or more candidate target cells for each UE; sending a handover confirmation to the source IAB donor CU indicating that the handover of the one or more UEs has been accepted by the target IAB donor CU and identifying the target cell for each UE. The method of claim 49 further comprises: After completing the handover of the one or more UEs to the target IAB donor CU and when the mobile terminal (MT) of the IAB node has been migrated to the non-F1 donor CU, a traffic migration request for requesting traffic release for traffic associated with the IAB node routed via one or more paths in the IAB topology managed by the non-F1 donor CU is sent to the non-F1 donor CU. The method of any of the preceding claims, wherein the IAB node is a mobile IAB node. A device for an integrated access and backhaul (IAB) node of an IAB communication system, the device comprising: One or more processing units configured to perform the method of any one of claims 15 to 39 or claim 51. A device for an integrated access and backhaul (IAB) communication system of an IAB donor central unit (CU), the device comprising: One or more processing units configured to perform a method as in any one of claims 1 to 14 and claims 40 to 51. A computer program comprising instructions which, when executed by a computer, cause the computer to implement a method as claimed in any one of claims 1 to 51. A computer-readable medium carrying a computer program as claimed in claim 54.

Images