Migration of nodes in an iab communication system

Abstract

Discloses a method and apparatus for a migration process in which distributed units (DUs) of an integrated Access Backload (IAB) node are migrated from one IAB topology managed by a source IAB grant central unit (CU) to another IAB topology managed by a target IAB grant CU. One method at the source IAB grant CU includes, in the case that the DU of the IAB node is used to migrate from the one IAB topology managed by the source IAB grant CU to the other IAB topology managed by the target IAB grant CU, sending a message for establishing an F1 connection between the IAB node and the target IAB grant CU to the DU of the IAB node. Another method at the IAB node includes, at the DU of the IAB node, receiving a message from the source IAB grant CU for establishing an F1 connection between the target IAB grant CU and the IAB node; and sending an F1 configuration request for requesting the configuration of the F1 connection to the target IAB grant CU.

Description

Technical Field

[0001] The present invention generally relates to methods used in a process for migrating nodes and traffic between mobile integrated access and backhaul (IAB) topologies in a wireless communication system involving IAB nodes. Specifically, the present invention relates to methods used in a migration process in which a distributed unit (DU) of an IAB node (e.g., a mobile IAB node) is migrated between IAB topologies. Prior Art

[0002] Wireless communication systems are widely deployed to address a wide range of applications, from mobile broadband and 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 various types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) via one or more base stations. Base stations are typically wired (e.g., via 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 fourth generation (4G) Long Term Evolution (LTE) or the more recent fifth 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 is increasing. To address the high deployment costs and time associated with wired backhaul networks for network densification, 3GPP proposed wireless backhaul in 5G NR Release 16, also known as Integrated Access and Backhaul (IAB). This approach uses a portion of the wireless (i.e., radio) spectrum for backhaul connections between base stations, rather than using optical fiber. Wireless backhaul communications (between base stations) can utilize 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-reach areas as it allows for scalable and rapid installation without the burden of cabling base stations. IAB is most likely to operate in the millimeter wave (mmWave) frequency band to achieve the required Gbps (gigabits per second) data rates. However, mmWave is known to suffer from significant signal attenuation in some weather conditions (rain, fog) and can be blocked by obstacles in the path between the transmitter and receiver. To mitigate these potential radio link failures, topology redundancy can be provided within the IAB framework. Multiple data paths are established 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 UE's "access IAB node"). 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), forming alternative data paths within a multi-hop IAB topology. Furthermore, 3GPP has considered inter-donor redundancy, where an IAB node (referred to as a border IAB node) can access two different parent nodes connected to two different IAB donors, each of which manages a different IAB topology (also known as an IAB network). A border IAB node, even though belonging to a single IAB topology (i.e., a single IAB donor for configuration and management purposes), is able to route packets from a first IAB topology managed by a first IAB donor to a second IAB topology managed by a second IAB donor. The advantage of this inter-donor redundancy is the ability of the first IAB donor to offload some of its packets by routing them through the second IAB topology, thereby alleviating congestion or overcoming radio link failures that may occur in the first IAB topology. There are other scenarios where an IAB node becomes a border node. For example, in the case of a partial migration of an IAB node determined by an IAB donor, the IAB node's mobile terminal (MT) becomes connected to a single parent IAB node belonging to another IAB topology controlled by another IAB donor. This scenario 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 these cases, the migrated IAB node and its potential child IAB nodes remain part of the original IAB topology, and this partial migration can be referred to as an MT migration. To ensure that traffic can be routed through the other IAB topology, MT migration should be followed by traffic migration, where traffic associated with the border node and its child IAB nodes is routed through the other IAB topology 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 wireless backhaul) can experience radio failures due to fluctuating radio conditions. For non-mobile IAB nodes, this should be a temporary condition with possible link recovery after some time. Therefore, these fixed IAB nodes do not need 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 the migration of the IAB node's Distributed Unit (DU), thus handing over control of the IAB node to a new IAB donor. Furthermore, note that this DU migration (which can be referred to as a full migration) also involves the handover of the UE served by the migrating IAB node. Urban environments are often characterized by a high density of users and 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 the opportunity offered by these vehicles to increase network coverage and connect to UEs inside or even close to the vehicle by installing these vehicle-mounted base stations (or base station elements) acting as mobile repeaters. These mobile repeaters will rely on 5G wireless backhaul (typically IAB or integrated access and backhaul) to connect to a fixed donor device. Therefore, building on the fixed IAB foundation of Releases 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, and taxis). In these scenarios, the mobile IAB nodes can be referred to as vehicle-mounted repeaters (VMRs), providing 5G coverage and capabilities to onboard and / or surrounding UEs. The technical benefits of using a VMR include, among other things, its ability to provide good radio link conditions to nearby UEs. Furthermore, compared to solutions that use UEs as repeaters (i.e., sidelink relay solutions), vehicle-mounted IAB nodes are expected to have better RF / antenna capabilities and less stringent power / battery constraints than repeater UEs. For mobile IAB nodes, it may be worthwhile to perform multiple MT migrations or DU migrations because, as a mobile IAB node moves around, connectivity to a parent IAB node belonging to the first IAB topology may cease to exist for extended periods of time, or may cease to exist forever if the mobile IAB node moves away from the parent IAB node. Furthermore, for flexible IAB network management, MT and DU migrations should be decoupled, meaning that a DU migration of an IAB node can occur independently before or after one or more MT migrations of that IAB node. Furthermore, a DU migration of an IAB node can be performed to an IAB donor different from the IAB donor associated with the MT of that IAB node. Therefore, some new mechanism is needed to provide this flexibility by supporting decoupling of DU migration of an IAB node towards any other donor CU from the MT migration(s) of the IAB node. Summary of the Invention

[0003] According to a first 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 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 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 to the IAB node for establishing an F1 connection between the IAB node and the target IAB donor CU. According to a second aspect of the present invention, there is provided a method executed at an IAB node for use in a migration procedure in which a DU of the 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, as set forth in the accompanying claims. According to a third aspect of the present invention, a method is provided for use in a migration process executed at a target IAB donor CU for migrating a DU of an IAB node from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by the target IAB donor CU, as set forth in the accompanying claims. 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 can identify the target donor CU (e.g., via identification information sent by the source donor CU or, if no identification information is sent by the source donor CU, by determining that a non-F1 donor CU is the target donor CU) to enable handover of the UE served by the IAB node to the target donor CU. The non-F1 (terminating) donor CU is also referred to as an RRC (terminating) donor CU. According to a fourth aspect of the present invention, there is provided an apparatus for an IAB node of an IAB communication system, as set forth in the accompanying claims. According to a fifth aspect of the present invention, an apparatus for an IAB donor CU (eg, a source IAB donor CU or a target IAB donor CU) of an IAB communication system is provided, as set forth in the accompanying claims. 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 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 comprises: determining, by the source IAB donor CU, that the DU of the IAB node is to be migrated from one IAB topology managed by the source IAB donor CU to another IAB topology managed by the target IAB donor CU; and sending, by the source IAB donor CU, a message for migrating the DU of the IAB node from one IAB topology managed by the source IAB donor CU to another IAB topology managed by the target IAB donor CU. The invention relates to a method for transmitting a request for establishing an F1 connection between the IAB node and the target IAB donor CU to the IAB node; after receiving the request for establishing the F1 connection, transmitting an F1 setup request for requesting setup of the F1 connection to the target IAB donor CU by the IAB node; and after receiving the F1 setup request for requesting setup of the F1 connection from the IAB node, transmitting a response to the IAB node by the target IAB donor CU, the response including a request for one or more cells to be activated for a second logical DU entity of the IAB node. Further exemplary features of the invention are described in the other independent and dependent claims. In the following, the 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, a method aspect may be applied to an apparatus / device / unit aspect, and vice versa. Furthermore, features implemented in hardware can be implemented in software, and vice versa. Any reference herein to software and hardware features should be interpreted accordingly. For example, according to other aspects of the present invention, a computer program comprising instructions that, when executed by a processing unit, causes the processing unit to perform any of the above-described aspects or illustrative methods, and a computer-readable storage medium containing the computer program are provided. Simple diagram description

[0004] By way of example only, various aspects of the invention will now be described with reference to the accompanying drawings, in which: [FIG. 1] is a schematic diagram of a communication system according to one or more embodiments of the present invention; [Figures 2a and 2b] schematically illustrate the stacking of some protocol layers involved in IAB operation; [Figure 3] is a diagram illustrating the format of a BAP protocol data unit (PDU) or packet; [Figure 4] is a block diagram of an exemplary wireless communication device according to an embodiment of the present invention; FIG5 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 that enables DUs to migrate from a source IAB topology to a target IAB topology; FIG. 7 is a simplified diagram illustrating an exemplary message flow for performing DU migration of an IAB node including handover of a UE served by a migrating IAB node according to one or more embodiments of the present invention; FIG8a is a simplified diagram illustrating an exemplary message flow for executing a process for enabling a logic DU according to one or more embodiments of the present invention; [FIG. 8b] is a simplified diagram illustrating an exemplary message flow for setting a logical DU; [Figure 8c] is a simplified diagram illustrating an example message flow of the process of removing a logical DU; FIG8 d is a simplified diagram illustrating an exemplary message flow of a procedure used by a logical DU to notify a RAN node CU of a configuration change; FIG9a 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; FIG9 b is a simplified diagram illustrating an exemplary message flow used by a RAN node CU to coordinate with another RAN node CU to manage transport migration; FIG10 a is a flow chart of an exemplary method for managing DU migration of an IAB node at a source F1 terminal donor CU of the IAB node toward a target IAB topology according to an embodiment of the present invention; FIG10 b is a flow chart of an exemplary method for managing DU migration toward a target IAB topology at an IAB node according to an embodiment of the present invention; FIG. 10 c 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. 10 d ] is a flow chart of an exemplary method for managing DU migration of an IAB node at a target IAB donor CU toward a target IAB topology managed by the target IAB donor CU according to an embodiment of the present invention. Implementation Method

[0005] FIG1 illustrates an exemplary wireless communication system 100, specifically a mobile radio 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 embodiments and examples of the present invention will be described below with respect to a 5G NR system, it should be understood that the present invention is not intended to be limited to 5G NR systems and can be applied to any wireless communication system having mobile base stations. Specifically, the following description primarily uses the specific term 5G, but it should be understood that this term also applies to components or processes performing equivalent functions in other communication systems. System 100 includes a plurality of UEs (user equipment) 132, 133, 131, and 134, a remote core network 110, a master base station 120, two integrated access and backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes), and a mobile IAB station 123 installed in a vehicle 105 (e.g., a bus, train, taxi, car, etc.). Master base station 120, also referred to as IAB donor 120, is connected to core network 110 via a wired link 101, preferably optical fiber or any other wired method. In embodiments and examples of the present invention, IAB donor 120 is a 5G NR gNB with additional functionality to support IAB features, as defined in 3GPP TS 38.300 V17.2.0. To extend the network coverage of IAB donor 120 and reach remote UEs 132, 133, and 131, operators have installed IAB stations 121 and 122, also known as IAB nodes 121 and 122. By acting as relay nodes between IAB donor 120 and UEs 132 and 133, IAB nodes 121 and 122 allow accessibility issues caused by the presence of buildings 108, which are obstacles to radio wave propagation and, therefore, to direct connections and further communications between UEs and IAB donor 120, to be overcome. This is particularly true when communications between IAB donor 120 and UEs 132 and 133 operate at millimeter wave frequencies, which are highly sensitive to shadowing phenomena. The IAB Donor 120 also serves the UEs 134 that are directly connected to it. The mobile IAB station 123 (also referred to as a mobile IAB node 123 or an mIAB node 123) is an IAB node installed on the vehicle 105 and provides network coverage and capacity extension, 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. IAB donor 120 and 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) specifications are distributed across 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 Agreement (V17.2.0). Since the IAB donor 120 and the IAB nodes 121, 122, and 123 are connected to the UEs 134, 131, 132, 133, 135, and 136, respectively, they are considered as access IAB nodes for their respective connected UEs. The 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 (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. Each of the one or more IAB donor DUs or donor DUs (hereinafter also referred to as IAB donor DU or IAB donor DU) includes lower-layer protocols, such as RLC, MAC, and physical layer protocols. The IAB donor CU or donor CU and IAB donor DU or donor DU can be remote from each other or located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. It aims to terminate the NR access interface to the UE and the next hop IAB node, as well as to terminate the F1 protocol to the IAB donor gNB-CU functionality, as shown in Figures 2a and 2b discussed below. The IAB nodes that can serve multiple radio sectors are wirelessly backhauled to the IAB donor 120 via one or more relay points on intermediate IAB nodes. 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 functionality on an IAB node is also referred to as the IAB-DU and allows downstream (UE-towards) connectivity to the next relay point IAB or to the UE. The IAB-MT functionality includes, for example, physical layer, Layer 2, RRC, and non-access stratum (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, neighbor nodes on the IAB-DU interface are called child nodes, and neighbor nodes on the IAB-MT interface are called parent nodes. The direction toward the child nodes is further called downstream, while the direction toward the parent node is called upstream. The IAB donor 120 (eg, IAB donor CU) performs centralized resource, topology, and routing management for the entire IAB topology. This includes configuring IAB nodes according to the network topology, for example, to perform appropriate routing of data packets. Figures 2a and 2b schematically illustrate the stacking of some of the protocol layers involved in IAB operation. The F1 interface supports the exchange of signaling information (e.g., control traffic) between endpoints and the transmission of data (e.g., user traffic) to each endpoint. 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 over two backhaul relay points (from the IAB donor to IAB node 1, and then from IAB node 1 to IAB node 2). In the user plane, block 210 at the 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 signaling messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for more details), here shown as block 210 at the IAB donor CU and IAB node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol that provides the best possible block datagram service and is adapted for use with the IP protocol. In the control plane, block 210 represents the F1AP (F1 Application Protocol) layer, while block 211 represents the SCTP (Stream Control Transmission Protocol) layer. The F1AP (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 include initialization and configuration. The well-known SCTP layer provides reliable, in-sequence message delivery with 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 fiber), for example when the IAB donor CU is remote to the IAB donor DU, or when the local IAB donor CU and IAB donor DU are virtual instances on the same physical machine. IAB-specific transport between the IAB donor CU and IAB donor DU is defined in 3GPP TS 38.401. In FIG. 2 a , L1 and L2 represent the transport layer and physical layer, respectively, appropriate to the media being used. The IP layer can also be used for non-F1 traffic, such as operations, 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. IP traffic for the IAB-DU is routed through the BAP sublayer via wireless backhaul. In the downstream direction, upper-layer packets are encapsulated by the BAP sublayer at the IAB donor DU, forming BAP packets or packet data units (PDUs) or data packets. BAP packets are routed by the BAP layer or entity of intermediate IAB nodes (if any) (and the corresponding BAP entities in IAB-DU and IAB-MT). The BAP packets are ultimately 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 (or, if the upper layer packet originates from the UE, the access IAB node) to form BAP packets or data units (PDUs) or data packets. BAP packets are routed by the BAP layer (and the corresponding BAP entities in IAB-DU and IAB-MT) at intermediate IAB nodes (if any). BAP packets are ultimately decapsulated by the BAP sublayer at the IAB donor DU. At the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packet and set by the BAP sublayer of the issuing IAB donor DU or the originating IAB node (e.g., the network node in the 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 paragraph 6.2 of the standardized version of 3GPP TS 38.340, version 17.2.0. Payload portion 307 is typically an IP packet. Header 30 includes fields 301 through 306. Field 301, designated 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., at the BAP sublayer) of the BAP packet's destination IAB node or IAB donor DU. For routing purposes, each IAB node and IAB donor DU in the IAB network is configured with a unique BAP address (by the IAB donor CU of the IAB network). Field 306 carries a path ID, which identifies the routing path the BAP packet should follow to that destination in the IAB topology. For routing purposes, routing paths (including their path IDs) are configured within the IAB nodes of the IAB network (by the IAB donor CU of the IAB network). When a packet reaches the BAP layer from the upper layer, a BAP header is added to the packet, and when it reaches its destination node, the BAP header is stripped off by the BAP layer. The BAP routing ID selected for the packet is configured by the IAB donor CU. For example, when a BAP packet is generated by a node—for downstream transmission by an IAB Donor DU or upstream transmission by an initiator (for upper-layer packets originating from a UE, the initiator can be an access IAB node)—the node constructs a BAP header with a BAP Route ID according to the configuration table defined in 3GPP TS 38.340. This table is called the Downlink Traffic to Route ID Mapping Configuration Table in the IAB Donor DU or the Uplink Traffic to Route ID Mapping Configuration Table in the initiator IAB node. At intermediate IAB nodes, the BAP header fields are already specified in the BAP packet to be forwarded. As mentioned above, these configuration tables defining the BAP paths (and therefore the routing policies and configuration of the IAB nodes given the IAB network topology) are typically defined by the IAB donor CU and transferred to the IAB nodes to configure them. To transmit information over the 5G NR radio medium, three additional sublayers (RLC, MAC, and PHY) are implemented at each IAB node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconstruction. 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 mapping logical channels to transmission channels. MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the transmitter side, the MAC encapsulates data packets sent from the RLC. It adds a header with information required for MAC functions. On the receiver side, the MAC decapsulates data packets sent from the PHY, removes the 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 a data stream. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, and TS 38.214. To pass 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, when necessary, packet integrity. It enforces packet numbering on the transmitter side and packet reordering 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 (QoS). This is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with user applications (such as voice and video, not shown). On the IAB donor CU side, the SDAP sublayer exchanges data (such as internet traffic and cloud) with the core network 110. The RRC sublayer 220 of the control plane handles the configuration of protocol entities within the user plane protocol stack. This is described in TS 38.331. It is responsible for processing broadcast information required for UE-cell communication; transmitting call messages; managing connections, including bearer setup; mobility functions; measurement configuration and reporting; and device capabilities. The interface between nodes using the PDCP, RLC, MAC, and PHY layers (for both CP and UP) is called NR-Uu. This primarily involves interfacing with the UE. The interface between nodes using the BAP, RLC, MAC, and PHY layers (for CP and UP) is called the Backhaul RLC Channel (BH RLC Channel). This primarily involves the interface between IAB nodes. NR-Uu is the interface between the UE and the radio access network, i.e. its access IAB node (for CP and UP). Figure 2b, from 3GPP TS 38.300 V17.2.0, illustrates the protocol stack for RRC and NAS connections supporting IAB-MT. The Non-Access Stratum (NAS) protocol handles messaging between the core network and user equipment (UE) or IAB nodes. It manages the establishment of communication sessions and maintains communication with the IAB node or UE as it moves. 3GPP TS 24.501 describes the 5G NAS. 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 UEs connected to the IAB node, as well as similar information from the IAB node. The AMF is solely responsible for handling connection and mobility management tasks. The IAB-MT establishes a signaling radio bearer SRB (carrying RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted between the IAB-MT and its parent node over the NR-Uu interface. FIG4 is a schematic diagram illustrating an exemplary communication device (equipment) or station according to one or more exemplary embodiments of the present disclosure. The communication device 400 may be a device such as a microcomputer, a workstation, or a portable device. The communication device 400 includes a communication bus 413, which is preferably connected to: - Central processing unit 411, such as a microprocessor, denoted as CPU. Central processing unit 411 may be a single processing unit or processor or may include two or more processing units or processors that perform the processing required to operate communication device 400. The number of processors in central processing unit 411 and the distribution of processing functions are matters of design choice for those skilled in the art; - a memory for storing data and a computer program including instructions for operating the communication device 400. The computer program may include a number of different program elements (modules) or subroutines including instructions for various operations and for implementing various operations of 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 FIG. 1 . The at least one communication interface 402 can be connected to a radio communication network 403, such as a wireless communication network for 5G NR (e.g., according to Release 17 and / or later), for transmitting digital data packets or frames or control frames over the network. Frames are written from a transmit FIFO in RAM 412 to the communication interface for transmission, or read from the communication interface for reception and written to a receive FIFO in RAM 412, under the control of a software application running in CPU 411. Each of the donor CU, donor DU, IAB node, and UE may include such a communication device / apparatus 100 . Memory can include: - a read-only memory 407, represented as a ROM, for storing a computer program for implementing the method according to one or more embodiments of the present invention; - Random access memory 412, represented as RAM, for storing executable code of the method according to one or more embodiments of the present invention, and registers adapted to record variables and parameters required for implementing the 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 means 404, such as a hard disk, for storing a computer program for implementing the method according to one or more embodiments of the present invention; - a disk drive 405 for a disk 406, adapted to read data from or write data to the disk 1106; - Screen 409 for displaying decoded data and / or serving as a graphical interface with the user via keyboard 410 or any other input / output means. In one 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 limiting, and specifically, the central processing unit is operable to communicate instructions to any component of the communication device 400, either directly or through other components of the communication device 400. The disk 406 can optionally 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 component may be integrated into 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 read-only memory 407, on hard disk 404, or on a removable digital medium such as, for example, the aforementioned magnetic disk 406. According to an optional variant, the executable code of the program may be received via the communication network 403 via the interface 402 in order to be stored in one of the storage means of the communication device 400, such as the hard disk 404, before execution. The central processing unit 411 is adapted to control and direct the execution of instructions or portions of software code of one or more programs according to the present invention, the instructions of which are stored in one of the aforementioned storage devices. Upon power-up, the one or more programs stored in non-volatile memory, such as the hard drive 404 or read-only memory 407, are transferred to the random access memory 412, which then stores 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 one exemplary embodiment, the communication device (apparatus) is a programmable device / device that uses software to implement the present invention. Instructions can be executed by one or more processors of the device, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits, to implement the present invention for a network node (e.g., an IAB node, an IAB donor CU, 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., in an application-specific integrated circuit or ASIC or other logic element). FIG5 illustrates an example of an IAB communication system (or IAB network system) 500 in which embodiments and examples of embodiments of the present invention may be implemented. In one example implementation, radio links between IAB nodes and between IAB nodes and IAB donor DUs (referred to as BH radio links) operate in the millimeter wave frequency 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, and thus, in this application, the terms IAB network, IAB topology, and topology will be used interchangeably. IAB communication system 500 consists of three IAB networks or IAB topologies 5001, 5002, and 5003. Each IAB topology includes a set of IAB nodes (e.g., the set 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 BAP packets, as well as intermediate or relay IAB nodes. Each of these IAB nodes communicates with at least one other IAB node via a wireless backhaul (BH) link. While FIG5 illustrates three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and can 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. The IAB topology 5001 includes an IAB donor CU 501 (identified as donor 1-CU in FIG. 5 ), 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 the IAB nodes 121 and 122 . 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 ), as well as a plurality of IAB nodes 530, 540, and 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 can access nodes that serve UEs, such as UE 580 served by mobile IAB node 570. 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 FIG. 5 shows only one UE 580, it should be understood that there will be multiple UEs connected to the network nodes of IAB communication system 500. The IAB topology 5003 includes an IAB donor CU 503 (identified as donor 3-CU in FIG. 5 ), its associated IAB donor DU 507 (identified as donor 3-DU1 in FIG. 5 ), and an IAB node 560, such as the 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. The IAB donor CU 501, the IAB donor DU 504, and the IAB nodes 510 and 520 are part of the same IAB network or IAB topology 5001, which is configured and managed or controlled by the IAB donor CU 501. The IAB donor CU 502, the IAB donor-DUs 505 and 506, and the IAB nodes 530, 540, 550 are part of the same IAB network or IAB topology 5002, which is configured and managed or controlled by the IAB donor CU 502. The IAB donor CU 503, IAB donor-DU 507 and IAB node 560 are part of the same IAB network or IAB topology 5003, which is configured and managed or controlled by the IAB donor CU 803. Each IAB-DU and IAB donor DU supports wireless communication within 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) within a cell can establish a communication link with the node serving the cell (i.e., the IAB-DU or IAB donor DU) to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the internet, etc.) via the node. Assume that mobile IAB node 570 initially has a single parent IAB node 520 and belongs to IAB topology 5001 controlled by IAB donor CU 501. Therefore, the IAB donor CU operates as an F1-terminal donor CU (also referred to as an F1-terminal IAB donor CU or F1 donor CU). When mobile and given its proximity to IAB topology 5002, specifically IAB node 530, when mobile IAB node 570 is in the position shown by the dashed line in FIG5 , mobile IAB node 570 can establish a wireless BH link with IAB node 530. This BH link is possible for stationary IAB nodes and is particularly possible for mobile IAB nodes, such as IAB node 570, that are moving in the direction of IAB topology 5002 (shown by arrow 590 in FIG5 ). 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, with the donor CU 502 becoming a non-F1-terminal donor CU (which may also be referred to as a non-F1-terminal IAB donor CU, a non-F1 donor CU, 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). To this end, the F1 donor CU 501 may initiate 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, IAB node 501 remains part of IAB topology 5001 with its F1 connection to donor CU 501, but its RRC connection is now to donor CU2 502. Following this procedure, IAB donor CU 501 can request the migration of backhaul traffic (e.g., user traffic, control traffic) associated with IAB node 570 toward IAB topology 5002 (i.e., through donor DU 505). 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. In an IB communication system, all traffic communicated over the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Therefore, the offloaded or migrated traffic, or backhaul traffic, is F1 traffic and can 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 can then be moved toward the parent IAB node 550 via the non-F1 donor CU 502, using the backhaul link 5050 between the IAB node 550 and the IAB node 570. For this purpose, the non-F1 donor CU 502 can 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 continuous MT migration (or another MT migration to another IAB node) of the IAB node 570 using the new single parent IAB node 550. Furthermore, the IAB node 501 establishes its F1 connection with the donor CU 501 and its RRC connection with the 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 toward 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, IAB node 570 may become located in a position where the backhaul link 5060 with IAB node 560 may have better quality than the backhaul link 5050 with IAB node 550, now in the direction of the IAB topology 5003 controlled by donor CU 503. Therefore, donor CU 502 may apply the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0, sections 8.17.3.1 or 8.17.3.2. After this continuous MT migration, IAB node 501 still belongs to IAB topology 5001 and has an 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 terminating donor CU (or non-F1 donor CU or RRC donor CU). However, the donor CU 501 must be notified of the new non-F1 donor CU 503 for the IAB node 570 and the new donor DU 507 to redirect the offloaded traffic (F1 traffic, control and user traffic) through the donor DU 507 instead of the donor DU 506. In all the MT migration scenarios described above, the UE 580 is still connected to the donor CU 501 via the DU portion or unit 572 of the mobile IAB node 570. If the IAB node 570 has some child IAB nodes, these child IAB nodes are still part of the IAB topology 5001 and are still fully controlled by the donor CU 501 (via F1 and RRC connections). At any migration state of the MT portion 571 of the IAB node 570, regardless of whether the MT portion 571 of the IAB node 570 is migrating to the IAB topology 5002 or the IAB topology 5003, and regardless of whether the IAB node 570 has a non-F1-terminal donor CU, and if so, regardless of its non-F1-terminal donor CU 502 or 503, the F1 donor CU 501 may decide to perform a migration of the DU portion 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 the target donor CU. After deciding to perform a DU migration of the IAB node 570, the F1 donor CU 501 must also decide which donor CU (referred to as the target F1 donor CU) to perform the DU migration on. If there is a current non-F1-terminal donor CU, the DU migration can be directed toward the current non-F1-terminal donor CU (i.e., the default selection), in which case the non-F1-terminal donor CU becomes the target F1 donor CU, or toward another target F1 donor CU. For example, if IAB node 570 is mobile and its trajectory is predictable (e.g., for a bus or train), F1 donor CU 501 may know the appropriate target F1 donor CU of the control cell through which IAB node 570 will soon connect to the network. For example, although the non-F1-terminal donor CU of IAB node 570 is donor CU 502, the F1 donor CU may determine that the DU migration of IAB node 570 should be directed toward donor CU 503 because IAB node 570 can quickly traverse and does not reside in the IAB topology 5002 controlled by donor CU 502. By not performing a DU migration toward donor CU 502 and instead performing a DU migration toward donor CU 503, intermediate DU migration protocol messages to IAB node 570 are avoided. When performing a DU migration, a handover of the UE served by IAB node 570 must also be performed. Therefore, by not performing a DU migration toward donor CU 502, an intermediate handover of the UE served by IAB node 570 to donor CU 502 is also avoided before the new DU migration and UE handover toward donor CU 503. The procedures for performing DU migration and UE handover towards a selected target F1 donor CU are described in more detail with reference to the subsequent figures. FIG. 6 illustrates an example of an IAB node architecture 600 that enables migration of DUs of the 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 portion or unit IAB-MT 610 (e.g., MT portion 571 of IAB node 570 in FIG5 ), a portion or unit IAB-DU1 611, and a portion or unit IAB-DU2 612. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for the 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 point of IAB node 601, both logical DUs are active: one terminates the F1 interface with the source F1 donor CU (e.g., donor CU 501 in FIG5 ), while the other terminates the F1 interface with the target F1 donor CU (e.g., donor CU 502 or 503 in FIG5 ). Otherwise (i.e., when DU migration is not performed), only one logical DU is sufficient for IAB operation. As an example and referring to the IAB communication system of FIG5 , the F1 terminating donor CU of the IAB node 601 (i.e., the IAB node 570) can be the donor CU 501, which thus operates as a 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 can identify the IAB donor CU 502 as a suitable target F1 donor CU. The IAB topology 5002 includes network nodes (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550) managed by the IAB donor CU 502, which 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 stationary but is close to or adjacent to one or more IAB nodes in an adjacent IAB topology (such as the IAB topology 5002), the source F1 donor CU 501 may determine that the IAB donor CU 502 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 IAB nodes in the adjacent IAB topology 5002) that the IAB node is about to be connected to an IAB node in the adjacent IAB topology 5002. Before DU migration, for example, UE 602 (such as UE 580 in FIG. 5 ) is connected to the 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 the target F1 donor CU 502. 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. The activation of logical DU IAB-DU2 612 can be triggered by the source F1 donor CU and performed using the procedures described with reference to FIG. 8 a and FIG. 8 b. Once the handover from the cell controlled by the logical DU IAB-DU1 611 to the UE 602 controlled by the logical DU IAB-DU2 612 is completed, the logical DU IAB-DU1 611 may be deactivated. The deactivation may be triggered by the source F1 donor CU 501 following the procedure described with reference to FIG. 8 c after detecting the completion of the handover for all UEs served by IAB-DU1 611. An example 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 MT migration (multiple), and includes notifying the IAB nodes of the identity of a target donor CU to enable handover of UEs served by the IAB node to the target donor CU. While the following method / apparatus will be primarily described 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 can be applied to fixed IAB nodes, for example, those located at the edge of an IAB topology and close to or adjacent to one or more IAB nodes in a neighboring IAB topology. FIG7 is a schematic simplified diagram 700 illustrating some exemplary message flows for performing DU migration of an IAB node with or without MT(s) migration according to one or more embodiments of the present invention, and including notifying the IAB node about a target donor CU so that a UE served by the migrating IAB node can be handed over to the target donor CU. FIG7 illustrates 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 core network 110, shown in FIG1 . FIG7 also shows an IAB node 701, which may be a mobile IAB node, such as IAB node 570, consisting of a mobile equipment (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 IAB-DU1 705 are identified by different identifiers (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) of the cells of IAB-DU1 705. IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for the 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 to 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 to another donor CU, that other donor CU (not shown). At the start of the flow, IAB node 701 belongs to the source IAB topology controlled by source F1 donor CU 703. UE 708 is served by IAB node 701 via the cell of IAB-DU1 705 (e.g., the DU of IAB node 701 has an active IAB-DU1 705 with an F1 connection to source F1 IAB donor CU 703), while logical IAB-DU2 706 is inactive. User data in the downstream direction is provided to source F1 donor CU 703 via 5GC 702 via bearer 710. The data is then transmitted to logical DU IAB-DU1 705 of IAB node 701 via backhaul bearer 711, and finally to UE 708 via data radio bearer 712. Backhaul transport 711 can be established in the source IAB topology controlled by the source F1 donor CU 703 or in the IAB topology controlled by a non-F1 donor CU of the IAB node 701 (if the IAB-MT 704 was previously migrated toward this non-F1 donor CU). User data in the upstream direction (not shown) 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-terminating donor CU to its F1-terminating 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-terminating 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 (such as signal synchronization blocks (SSBs) transmitted in the serving cell and the target cells). The target cells may be cells 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., a received power exceeding a predefined threshold), it may generate and transmit measurement reports providing radio link quality information for different cells adjacent to the IAB node 701. The measurement report includes the identity of each cell to allow a non-F1 donor CU (if the IAB-MT 704 has migrated) or an F1-terminal donor CU 703 (if the IAB-MT 704 has not migrated) to identify the target donor CU associated with the cell. In practice, the donor CU's identity can be derived from the physical cell identity (PCI) broadcast in synchronization signals in each cell managed by the donor CU and / or from the new radio cell group identifier (NCGI) broadcast in system information block (SIB) messages in each cell managed by the donor CU. The PCI and / or NCGI can be reported by the IAB node 701 in the measurement report. Based on the received measurement reports, the non-F1 donor CU (if the IAB-MT 704 has migrated) or the F1 terminating donor CU 703 (if the IAB-MT 704 has not migrated) can 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 terminating donor CU 703 (if the IAB-MT 704 has not migrated) can decide to apply a procedure to perform the migration of the IAB-MT 704 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 informed of this MT migration by the non-F1 donor CU (if the IAB-MT 704 has migrated) or the source F1 donor CU. 703 will be informed because it made the decision to perform MT migration directly from the measurement reports received from IAB node 701 (if 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, a non-F1 donor CU can forward (relay) information in the measurement reports received from the IAB node 701 to the source F1 donor CU 703. Thus, the source F1 donor CU 703 can make the decision to perform DU migration of the IAB node 701 based on the measurement reports forwarded by the non-F1 donor CU directly from these measurement reports. Therefore, the source F1 donor CU 703 determines that the DUs of the IAB node are to be migrated from the IAB topology of the source F1 donor CU 703 to another IAB topology of the target IAB donor CU. This determination may be based on determining that the migration of the mobile equipment (MT) of the IAB node to the new parent IAB node has completed. Another example of a triggering event for determining that the DUs of the IAB node are to be migrated may include the decision to migrate the DUs based on the detection of MT migration from a first IAB topology to a second IAB topology, and based on a known (predefined) trajectory of the IAB node indicating to the source F1 donor CU that the MT will later migrate to a third IAB topology. In this case, to avoid signaling for DU migration / UE handover to the second IAB topology, the DUs are migrated directly to the third IAB topology. Another example of a triggering event for determining that the DUs of the IAB node are to be migrated may include the detection of a processing load level exceeding a predefined 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. When the source F1 donor CU 703 decides or determines to perform a DU migration of the IAB node 701 toward another IAB topology managed by another donor CU, which 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 active IAB node 701. This may require activating the second logical IAB-DU2 706 in the active IAB node 701, and thus the first step 720 may include activating the second logical DU IAB-DU2 706 in the active IAB node 701. This operation is performed using, for example, the procedures described with reference to FIG8 a and FIG8 b. 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 (such as 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) can be established 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 activation request, then by default, and in the case where the IAB-MT 704 has been migrated to a non-F1 donor CU, the non-F1 donor CU is considered the target F1 donor CU. In this case, when the IAB-MT 704 migrates to a non-F1 donor CU, the IAB node 701 has already been notified of the identity of the target donor CU (e.g., TNL address / IP address). In other words, the source F1 donor CU 703 can send identification information identifying the target IAB donor CU unless the IAB-MT 704 has already migrated to a non-F1 donor CU. Alternatively, the source F1 donor CU 703 can send identification information identifying the non-F1 donor CU serving as the target IAB donor CU. After determining that the DU of the IAB node 701 is to be migrated and once IAB-DU2 706 has been activated, 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 to 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 example of IAB node 701 being IAB node 570 of FIG. 5 connected to IAB node 550 via backhaul link 5050, and in which the MT of IAB node 570 (MT 571, which corresponds to IAB-MT 704 in FIG. 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 the 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 can be routed to the target F1 donor CU 503 over the wired backhaul (508 in FIG. 5 ). In an F1 setup response (e.g., 814 in FIG. 8 b ), the target F1 donor CU 707 (e.g., donor CU 503 in the example described above with reference to FIG. 5 ) can request the IAB-DU2 706 to enable new cell(s) with the associated identifiers (PCI, NCGI). Cells are typically enabled / disabled by the controlling DU's donor CU. See, for example, TS 38.473 section 8.2.3.2. Following the procedure described with reference to FIG. 8 b , and using, for example, the procedure described with reference to FIG. 9 a , the target F1 donor CU 707 may notify the source F1 donor CU 705 about enabling new cell(s) from the IAB-DU2 706 of the IAB node 701 . The next step 730 consists of handing over the UE served by the IAB node 701 (e.g., UE 708 in FIG7 ) from the cells of the first logical DU IAB-DU1 705 to the cell(s) of the second logical DU IAB-DU2 706. 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 the handover of the UE 708, the source F1 donor CU 703 sends a Handover Request message to the target F1 donor CU 707, including necessary information related to the UE 708 for handover (e.g., identification information for identifying the UE, UE context information (e.g., security context (e.g., security parameters (e.g., security keys, UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearer, etc.)). TS 38.423 Section 9.1.1.1 provides details on the content of a Handover Request message. After the target F1 donor CU 707 determines whether the donor CU can accept the handover of the UE 708 in an acceptance control step, when the target F1 donor CU 707 accepts the request, the target F1 donor CU 707 sends a Handover Confirm message to the source F1 donor CU 705, including configuration information of the UE 708 for handover. The configuration may include an indication of the configuration information to be used by the UE 708 to operate in the second logical DU. The handover confirmation may include an identifier of each of the one or more new cells (e.g., the target cell) that have been activated at the second logical DU IAB-DU2 706. The source F1 donor CU 705 then sends this configuration information to the UE 708 via the IAB node 701 in an RRC reconfiguration message, including the identifier of the target cell of the IAB-DU2 706 to which the UE 708 is connected. The RRC reconfiguration message (specified in TS 38.331) is embedded in the F1 message DLRRC message transmission (specified in TS 38.331) sent to the IAB-DU1 705 and relayed by the IAB-DU1 705 to the UE 708. Upon receiving this configuration information, the 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.An RRC Reconfiguration Complete message (specified in TS 38.331) is sent to IAB-DU2 706, and the RRC Reconfiguration Complete message is then embedded in an F1 message UL RRC messaging (specified in TS 38.473) sent to the target F1 donor CU 707. The source F1 donor CU 705 may be notified of the completion of the handover to the UE 708 via a Handover Success message (specified in TS 38.423) received from the target F1 donor CU 707. The target F1 donor CU 707 may perform a path switch procedure toward the core network 702 to request the delivery of user data associated with the UE 708. For example, the target F1 donor CU 707 may perform the path switch handover procedure described in 3GPP TS 38.413 V17.2.0 Section 8.4.4. Next, the target F1 donor CU 707 must set up a backload path to and from the migrated IAB node 701, either in its own topology if there is a backload 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 terminating donor CU of the IAB node 701 because the IAB-MT 704 was previously migrated to the target F1 donor CU 707), or through the IAB topology of the non-F1 donor CU of the IAB node 701 (not shown in FIG. 7 ) if there is no backload 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 are connected to different donor CUs). In the latter case, the target F1 donor CU 707 may trigger the procedure described with reference to FIG9 b to request that traffic be migrated to the non-F1 donor CU of the IAB node 701. As an example of the latter case with reference to FIG5 , the IAB node 701 is the IAB node 570 of FIG5 connected to the IAB node 550 via the backhaul link 5050, wherein the MT of the IAB node 570 (MT 571, which corresponds to the IAB-MT 704 in FIG7 ) has been migrated to the non-F1 donor CU 502, and the IAB donor CU 501 is an F1 donor CU. When the DU of the IAB node 570 (corresponding to the DU 572 of the IAB-DU2 706 in FIG. 7 ) has been migrated to the target donor CU 503 and thus 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) via its RRC connection, a backload path to and from the IAB node 570 is set up in the IAB topology 5002 controlled by the IAB donor CU 502 (i.e., a backload path through the IAB donor DU 506, IAB nodes 540 and 550 to the IAB node 570) by performing a traffic migration procedure (e.g., as described with reference to FIG. 9 b ). After handover of UE 708 and path switching has been performed, user data in the downstream direction is transmitted from core network 702 to target F1 donor CU 707 via bearer 740, then transmitted to logical DU IAB-DU2 706 of IAB node 701 via backhaul bearer 741, and finally transmitted to UE 708 via data radio bearer 742. Backhaul bearer 741 can be established in an IAB topology controlled by target F1 donor CU 707 or in an IAB topology controlled by a non-F1 donor CU of IAB node 707 (e.g., depending on whether IAB-MT 704 and IAB-DU2 706 of IAB node 701 are connected to different donor CUs). User data in the upstream direction (not shown) is transmitted in the opposite direction via similar bearers. Once the handover of all UEs served by IAB-DU1 705 of IAB node 701 is complete, source F1 donor CU 703 may deactivate logical DU IAB-DU1 705 of mobile IAB node 701 by the process described with reference to FIG8c. This is represented as a whole by process 735 in FIG7. At the same time, the source F1 donor CU 705 can release traffic (user traffic, control traffic) associated with the UE served by the IAB node 701 via IAB-DU1 705. If the traffic is offloaded in an IAB topology controlled by another donor CU, the source F1 donor CU 705 can apply the procedure described with reference to FIG. 9b to request that the traffic be released to the other donor CU. This is generally represented by procedure 735 in FIG. 7 . FIG. 8 a is a schematic simplified flow chart 800 illustrating an exemplary message flow for a process of executing activation of a logical DU according to an embodiment of the present invention. This image 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 in FIG5 (and the IAB-DU1 705 of the IAB node 701 in FIG7 ), - A RAN node CU 802, which may be an IAB donor CU such as the IAB donor CU 501 in FIG. 5 (and the source F1 donor CU 703 in FIG. 7). The message Configuration Request 803 is sent by RAN node CU 802 to RAN node DU 801 to request the activation of new cell(s) controlled by RAN node DU 801, the activation of a logical DU, or the deactivation of cell(s) within RAN node DU 801. In the case of a logical DU activation, message 803 may include the TNL address (i.e., IP address) of the RAN node CU (e.g., target F1 donor CU 707 in FIG. 7 ) that will connect to the logical DU once activated. For example, the source IAB donor CU may send Configuration Request 803 to an IAB node (e.g., the 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 one example, the process in Figure 8a corresponds to the procedure gNB-CU Configuration Update Procedure described in TS 38.473 V17.0.0 section 8.2.5, and message 803 corresponds to the message GNB-CU Configuration Update described in TS 38.473 V17.2.0 section 9.2.1.10, and 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 Enable to indicate the new cell(s) to be enabled at RAN node DU 801. For example, and referring to FIG7 , the GNB-CU Configuration Update message includes information for enabling the new cell(s) indicated in the IE Cell List to Enable. These new cell(s) can be serviced by the first logical DU entity 705 at IAB node 701. The cells to be enabled are cells controlled by the RAN node DU 801 that received the request. The message also provides associated PCI and NCGI values ​​to be used by the RAN node DU 801. The GNB-CU Configuration Update message may also include an information element (IE) Cell List to Deactivate to indicate the cell(s) to be deactivated. The cells to be deactivated are cells controlled by the RAN node DU 801 that received the request. For example, and referring to FIG7 , the GNB-CU Configuration Update message may include information for deactivating the cells indicated in the Cell List to Deactivate IE, which are currently being served by the first logical DU entity 705 at the IAB node 701. According to one example, a new IE, "Second DU Enable," can be added to message 803 in the form of a Boolean (e.g., a single-bit IE) to request the activation of the second logical DU. One value of this single-bit IE (i.e., "0" or "1") indicates that no specific action related to the second logical DU is requested, and another value (i.e., "1" or "0") indicates a request to activate the second logical DU. This IE can be implemented by a new IE indicating that the F1 setup is for DU migration toward the target RAN node CU (in other words, an IE indicating that the request to establish an F1 connection is for DU migration to the IAB node) and / or by a new IE indicating the number of cells to be activated in the second logical DU. If this IE indicating the number of cells is not present, the number of cells to be activated currently corresponds to the number of cells already activated in RAN node DU 801. Another IE may also provide a list of identifiers of cells (e.g., PCI and / or NCGI) that are controlled by the first logical DU 705 at the IAB node 701, for which a mapping to the identifiers of the cells to be enabled is to be 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 enabled and controlled by the second logical DU 706 are included in the message 803. Furthermore, a new IE (eg, Target TNL Address IE) may be added to identify the target RAN node CU through which the F1 connection should be set up. To complete the setup of a new logical DU at the IAB node, the procedure described with reference to FIG. 8 b may be used. FIG8 b is a simplified schematic diagram 810 illustrating an exemplary message flow 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 image shows: - a RAN node DU 811, which may be a DU of an IAB node DU such as the IAB DU 572 of the IAB node 570 of FIG. 5 (and the IAB-DU2 706 of the IAB node 701 of FIG. 7 ), - A RAN node CU 812, which may be an IAB donor CU such as the IAB donor CU 503 of FIG. 5 (and the target F1 donor CU 707 of FIG. 7). A setup request message 813 is sent by RAN node DU 811 to RAN node CU 812 to request F1 setup for a logical DU. For example, the setup request 813 may be sent by an IAB node (e.g., by the second logical DU entity 706 already enabled at 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 IAB node 701). As described with reference to FIG. 8a , the setup request message 813 may be sent after an enable request. The setup request message 813 may include an indication that the F1 setup is for a DU migration of the RAN node embedded in RAN node DU 811 (e.g., information indicating that the request to establish an F1 connection is for a 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 identifiers of the active cell(s) controlled by the first logical DU 705 (e.g., PCI and / or NCGI) and / or the identifiers of the active cell(s) controlled by the first logical DU 705 (e.g., PCI and / or NCGI), for which a mapping with the identifiers of the cell(s) to be enabled is provided (as described above). This setup request message 813 may optionally include a request for a mapping between the identifiers of the active cell(s) controlled by the first logical DU (e.g., PCI and / or NCGI) and the identifiers of the cell(s) to be enabled (e.g., at the 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 that terminates the F1 connection of the RAN node DU 811 (e.g., source IAB donor CU 703). This message 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 that terminates the non-F1 (i.e., RRC) connection of the RAN node CU 811 if the MT (e.g., mMT 571 of IAB node 570 or the corresponding IAB-MT of IAB node 704 of IAB node 701) has migrated to the RAN node CU (which is now a non-F1 donor CU). RAN node CU 812 responds to the message Setup Response 814 sent to RAN node DU 811. This message may include a list of cells enabled by the logical DU, along with the associated PCI and NGSI values ​​to be used. It may also include a mapping between the identifiers (PCI and / or NCGI) of the cell(s) to be enabled by RAN node DU 811 and the identifiers of the active cell(s) controlled by the first logical DU 705. According to one example, the process in FIG8b corresponds to the F1 Setup procedure described in Section 8.2.3 of TS 38.473 V17.2.0, message 813 corresponds to the F1 Setup Request message described in Section 9.2.1.4 of TS 38.473 V17.2.0, and message 814 corresponds to the F1 Setup Response message described in Section 9.2.1.5 of TS 38.473 V17.2.0. The F1 Setup Response message includes an information element (IE) (Cell List to Enable) indicating a list of new cells to be enabled. The cells to be enabled 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 a procedure for removing a logical DU. This image 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 in FIG5 (and the IAB-DU1 705 of the IAB node 701 in FIG7), - A RAN node CU 822, which may be an IAB donor CU such as the IAB donor CU 501 of FIG. 5 (and the source F1 donor CU 703 of FIG. 7). 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 a Remove Response 814 message sent to the RAN node CU 822 . According to one example, the process in FIG. 8 c 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 removal request described in TS 38.473 V17.2.0 section 9.2.1.16, and the message 824 corresponds to the message F1 removal response described in TS 38.473 V17.2.0 section 9.2.1.7. FIG8 d is a schematic simplified diagram 830 illustrating an example message flow of the procedure used by a logical DU to notify an IAB donor CU of a change in configuration, according to an example. This image 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 in FIG. 5 (and the IAB-DU1 705 of the IAB node 701 in FIG. 7 ), - A RAN node CU 832, which may be an IAB donor CU such as the IAB donor CU 501 of FIG. 5 (and the source F1 donor CU 703 of FIG. 7). The Configuration Update message 833 is sent by RAN node DU 831 to RAN node CU 832 to indicate a configuration change of the RAN node (e.g., IAB node 570, 701) embedded in RAN node DU 831. The Configuration Update message 833 may be sent by RAN node DU 831 to indicate to RAN node CU 832 that the F1 setup procedure has been completed with the target RAN node CU at the DU migration of the RAN node embedded in RAN node DU 831. Specifically, the message reports a new F1 connection between the second logical DU enabled in the RAN node embedded in RAN node DU 831 (e.g., IAB node 701) and the target F1 terminal donor CU (e.g., target F1 terminal donor CU 707). This message 833 may include the identifier of the target RAN node CU (e.g., target F1 donor CU 707). It may also include the identifier of the cell (e.g., PCI and / or NCGI) enabled in the second logical DU of the RAN node embedded in RAN node DU 831. Additionally or alternatively, message 833 may include a mapping between the identifiers of cells controlled by RAN node DU 831 and the identifiers of cells activated with the second logical DU. For example, referring to FIG7 , message 833 is sent by the first logical DU entity 705 activated at IAB node 701 to source IAB donor CU 703 to indicate the completion of the F1 setup procedure toward target IAB donor CU 707, optionally along with the identifiers of cells activated at the second logical DU 706 and optionally along with a mapping between the identifiers of cells activated at the second logical DU 706 and the identifiers of cells controlled by the first logical 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. Message 833 can indicate the success or failure of the F1 setup procedure. If the F1 setup procedure fails (for example, the F1 connection cannot be established), the message 833 can 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 Acknowledge 834 sent to the RAN node DU 831 . According to one example, the flow in Figure 8d corresponds to the gNB-DU Configuration Update procedure described in Section 8.2.4 of TS 38.473 V17.2.0, modified to include the information elements described above. Message 833 corresponds to the GNB-DU Configuration Update message described in Section 9.2.1.7 of TS 38.473 V17.2.0, and message 834 corresponds to the GNB-DU Configuration Update Confirm message described in Section 9.2.1.8 of TS 38.473 V17.2.0. Message 833 may be sent after the F1 setup procedure, described with reference to FIG. 8c and triggered by RAN node CU 832 (using the procedure described with reference to FIG. 8a ) or by a RAN node embedded in RAN node DU 831 having selected a target RAN node CU based on a preconfiguration. Preconfiguration may occur, for example, at the network integration of the RAN node embedded in RAN node DU 831. For example, the F1 setup procedure may be triggered by 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. 9 a 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 both of the IAB donor CUs 501, 502, and 503 of FIG5 . With respect to the example shown in FIG7 , RAN node CUa 901 is the target F1 donor CU 707 and RAN node CUb 902 is the source F1 donor CU 703. A message, "Configuration Update" 903, is sent by RAN node CUa 901 to RAN node CUb 902 to inform RAN node CUb 902 of the activation of new cell(s) in a logical DU of a RAN node DU, such as IAB-DU2 706 of IAB node 701. For example, source F1 donor CU 703 receives Configuration Update message 903 from target F1 donor CU 707, and Configuration Update message 903 includes identification information (e.g., PCI, NCGI) identifying one or more new cells activated at a second logical DU entity (IAB-DU2 706) of the DU of IAB node 701. Furthermore, message 903 may include a mapping between identifiers (PCI and / or NCGI) of the cell(s) activated at the second logical DU (IAB-DU2 706) and identifiers of the currently active cell(s) controlled by the first logical DU (IAB-DU1 705). The RAN node CUb 902 responds with a message Configuration Acknowledge 904 sent to the RAN node CUa 901 . According to one example, FIG. 9 a corresponds to the procedure NG-RAN NODE CONFIGURATION UPDATE described in section 8.42 of TS 38.423 V17.2.0, and message 903 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in section 9.1.3.4 of TS 38.423 V17.2.0, and message 904 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE CONFIRM described in section 9.1.3.5 of TS 38.423 V17.2.0. Figure 9b is a simplified schematic 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 transport 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 CUa 911 and RAN node CUb 912 , which may be two IAB donor CUs, such as two of the IAB donor CUs 501 , 502 , and 503 of FIG. 5 . The message transport migration request 913 is sent by the RAN node CUa 911 to the RAN node CUb 912 to request the migration or release of traffic within the IAB topology controlled by the RAN node CUb 912. For example, referring to FIG7 , in the case where the MT 704 of the IAB node 701 has been migrated to a non-F1 donor CU (not shown in FIG7 ), 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) that has been 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, Figure 9b 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. FIG10a is a flow chart illustrating an exemplary method 1000, executed at a source IAB donor CU, for use in a migration process (or as part of a migration process) in which a distributed unit (DU) of an IAB node migrates from one IAB topology managed by the source IAB donor CU to another IAB topology managed by a target IAB donor CU, according to one or more embodiments of the present invention. Method 1000 is used to manage the migration of the DU of an IAB node toward a target IAB topology at a source F1-terminal donor CU of the IAB node. For example, referring to the IAB communication system shown and described with reference to FIG5 , the source IAB donor CU executing method 1000 may be IAB donor CU 501 (e.g., the F1-terminal donor CU of an 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 the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve migrating DUs 572 of IAB node 570 from IAB topology 5001 to an IAB topology 5003 managed by IAB donor CU 503 (which is a target IAB donor CU). Referring to FIG. 7 , the IAB node may be IAB node 701, and the migration process may involve migrating DUs of IAB node 701 from source F1 donor CU 703 to target F1 donor CU 707. Method 1000, as shown and described in FIG. 10a , may be performed by software and / or hardware components. The source IAB donor CU may be implemented in communication device 400, as shown and described in FIG. 4 , wherein the method, as shown and described in FIG. 10a , is performed by one or more processing units, such as central processing unit 411. At step 1001, a source F1 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 the DU of the IAB node (e.g., IAB node 570) is to be migrated toward the target F1 donor CU, such as donor CU 503. For example, the source F1 donor CU In response to determining that the migration of the MT of the IAB node 570 / 701 to a new parent IAB node (which may be a new IAB node or a new IAB donor DU) has completed, 501 / 703 may determine that the DU of the IAB node 570 / 701 is to be migrated. 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, a source F1 terminating donor CU 501 / 703 sends a request to the IAB node to establish an F1 connection (i.e., a new F1 connection) between a target IAB donor CU 503 / 707 and an IAB node 570 / 701 (e.g., a new F1 associated with the target IAB donor CU). For example, the source F1 terminating donor CU 501 / 703 sends the 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 to the IAB node indicating that the F1 connection is for DU migration toward the target IAB donor CU (e.g., information indicating that the request to establish the F1 connection is for DU migration of a DU of the IAB node) and / or information indicating the number of cells to be enabled at a second logical DU entity of the DU of the IAB node. The source F1 donor CU 501, 703 may optionally send the identifiers of the active cell(s) controlled by the first logical DU 705 (e.g., PCI and / or NCGI), for which a mapping with the identifiers of the cells to be enabled (e.g., in the second logical DU to be enabled) will be provided. Optionally, at step 1003, the source F1 terminating donor CU 501 / 703 sends identification information 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 terminating 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 event that the IAB-MT 704 has been migrated to a non-F1 donor CU (which may be referred to as an RRC donor CU), the identification information sent by the source F1 terminating donor CU 501 / 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 terminating donor CU 703 may receive identification information (e.g., an identifier) ​​from the target F1 donor CU 707 or from the IAB node 570 or 701. The identification information identifies one or more new cells activated at a second logical DU entity of a DU of the IAB node, optionally along with mapping information indicating a mapping between the identification information (e.g., an identifier) ​​of the one or more new or target cells activated at the second logical DU and the identification information (e.g., an identifier) ​​of source cells or active cells 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 terminating donor CU 703, and a 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). For example, the identification information and 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, requesting that one or more user equipments (UEs, such as UE 708) 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 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 more cells) or based on a mapping between an identifier of a target cell enabled at the second logical DU and an identifier of a source cell(s) controlled by the first logical DU. For example, source F1 terminal donor CU 703 may select one or more of the new cells 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 mapping information received from target F1 donor CU 707 or IAB node 701. The use of mapping avoids waiting for measurement reports from the UEs to trigger the handover procedure. In response to receiving a handover confirmation from target F1 donor CU 707 indicating that the handover for the one or more UEs has been accepted and identifying a target cell for each UE, source F1 terminal donor CU 703 sends configuration information to IAB node 701 for configuring each of the one or more UEs for the respective target cells. The handover confirmation from 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 one or more UEs 708 to the target F1 donor CU 707, the source F1 donor CU 703 may send a request to the IAB node 701 to deactivate the first logical DU entity (e.g., IAB-DU1 705) of the DU of 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 traffic release for 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. FIG10B is a flow chart illustrating an exemplary method 1010 executed at an IAB node (e.g., a mobile IAB node or mIAB node) for a migration process (or portion thereof) 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, according to one or more embodiments of the present invention. Method 1010 is used to manage the migration of DUs to 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 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 a mobile IAB node 570 through which the mobile IAB node 570 maintains an F1 connection). The migration process may involve migrating DUs 572 of IAB node 570 from IAB topology 5001 to an IAB topology 5003 managed by IAB donor CU 503 (which is a target IAB donor CU). Referring to FIG. 7 , the IAB node may be mobile IAB node 701, and the migration process may involve migrating DUs of IAB node 701 from source F1 donor CU 703 to target F1 donor CU 707. The method 1010 shown and described in FIG. 10b may be executed by software and / or hardware components. The IAB node may be implemented in the communication device 400 shown and described in FIG. 4 , wherein the method shown and described in FIG. 10b is executed by one or more processing units, such as the central processing unit 411. At step 1011, an IAB node (e.g., IAB node 570 (701 in FIG. 7 ) of FIG. 5 ) receives a request for a new F1 connection (e.g., an F1 connection between IAB node 570, 701 and a target F1 donor CU (e.g., donor CU 503 (707 in FIG. 7 ) of FIG. 5 )) from a source F1 terminating donor CU (e.g., donor CU 501 (703 in FIG. 7 ) of FIG. 5 ). The request may be the configuration request 803 described with reference to FIG. 8 a . In response to receiving the request for a new F1 connection, the IAB node 570, 701 then sends an F1 setup request to the target F1 donor CU 503, 707 requesting the setup of the F1 connection (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, if the mobile terminal MT of the IAB node has migrated to the non-F1 donor CU, identification information for identifying a non-F1 donor CU (which may be referred to as an RRC 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 to establish the F1 connection (step 1017), and then send an F1 setup request to the identified target F1 donor CU. The IAB node 570, 701 may identify the target F1 donor CU 503, 707 based on identification information for the target F1 donor CU 503, 707, such as 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 migrated to a non-F1 donor CU, the IAB node may identify the non-F1 donor CU as the target F1 donor CU. In the case where the IAB-MT 704 has been migrated to a non-F1 donor CU, the IAB node 570, 701 identifies or determines the identity of the target donor CU 503, 707 (e.g., after receiving a request to establish an F1 connection) by treating / identifying the non-F1 donor CU as a target F1 donor CU. For example, in this case, the IAB node 701 was 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 identification information for identifying the target F1 donor CU 503, 707 from the source F1 terminating donor CU 501, 703. The identification information may include the address (e.g., TNL address / IP address) of the target F1 terminating donor CU for the new F1 connection. As another method (e.g., in place of steps 1011 and 1012), which is not shown in the figure, the IAB node 570 or 701 may also trigger itself to send a request for a new F1 connection and identify a target F1 donor CU based on a preconfiguration. Thus, the IAB node 570 or 701 may determine that a new F1 connection is to be set up, identify the IAB donor CU with which the connection is to be set up based on preconfiguration information preconfigured at the IAB node, and then send an F1 setup request requesting the setup of the F1 connection to the identified target IAB donor CU. As a first example, the triggering condition may be the detection by the IAB node 570 or 701 of one or more cells of the neighboring IAB node of an identifier (NCGI) associated with a donor CU belonging to a preconfigured list of target donor CUs. In other words, the IAB node 570, 701 may determine that a new F1 connection needs to be established (e.g., because a DU (e.g., 572) of the IAB node 570 / 701 is migrating) in response to or after detecting one or more cells of the neighboring IAB node 570, 701, and may identify an IAB donor CU with which the connection is to be established based on pre-configuration information. The one or more cells are 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 the IAB donor CU identified by pre-configuration needs to be established after an RRC connection between the IAB-MT and the IAB donor CU is established (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 nodes 570, 701 may determine that a new F1 connection is to be set up at 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 a list of candidate IAB donor CUs preconfigured at the IAB node and the IAB node location. FIG10c illustrates exemplary steps performed at an IAB node (e.g., a mobile IAB node or an 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 FIG10b can be performed by executing steps 1013 through 1015 of FIG10c , which are collectively referred to as step 1016. In an alternative approach where the IAB node 570 or 701 can determine that a new F1 connection is to be established (without receiving a request for a new F1 connection), steps 1013 through 1015 can be performed at the IAB node to identify the IAB donor CU with which the connection is to be established 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 identifying the target IAB donor CU for the new F1 connection from the source IAB donor CU (or via preconfiguration) by checking whether it has received the address of the target F1-terminating donor CU for the new F1 connection. If so, at step 1015, the IAB node 701 identifies the target F1-terminating donor CU from the received identification information and sends an F1 setup request to the identified target F1-terminating donor CU. If not, at step 1014, the IAB node 701 identifies a non-F1-terminating donor CU (which may be referred to as an RRC donor CU) as the target F1-terminating donor CU from the received identification information and sends an F1 setup request to its non-F1-terminating 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 may 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 for which a mapping with the identifiers of the cells to be enabled is provided (e.g., PCI and / or NCGI). As described above, the DU of the IAB node has a first logical DU entity with an F1 connection to the source F1 terminating donor CU 703, and enables a second logical DU entity to perform a DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). In one example, IAB node 701 activates a second logical DU entity (e.g., IAB-DU2 706) in response to receiving a request to establish an F1 connection (e.g., in configuration request 803). In both cases, the F1 setup request (e.g., message 813) is sent by the second logical DU entity. The F1 setup request message sent to target F1 terminating 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 to establish the F1 connection is for a DU migration of the DU of the IAB node. Optionally, the F1 setup request message includes a request for a mapping between identifiers of the active cell(s) controlled by the first logical DU (e.g., PCI and / or NCGI) 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 (such as setup response 814) from the target F1 terminating donor CU 707 including a request for one or more cells to be activated for the second logical DU entity. The response may include identification information, such as an identifier for each of the cells to be activated. The IAB node 701 may receive a request (e.g., a remove request 823 or a deactivation request in a configuration request 803) from the source F1 donor CU 703 for deactivating a first logical DU entity (e.g., IAB-DU1 705) of a DU of the IAB node 701 and, in response to the request, deactivate the first logical DU entity (e.g., IAB-DU1 705). FIG10d is a flow chart illustrating an exemplary method 1020, executed at a target IAB donor CU, for use in a migration procedure (or as part of a migration procedure) in which a distributed unit (DU) of an IAB node migrates from an IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU, according to one or more embodiments of the present invention. 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, referring to the IAB communication system shown and described in FIG5 , the target IAB donor CU executing method 1020 may be the IAB donor CU 503 controlling the IAB topology 5003. The IAB node may be the mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve migrating DU 572 of IAB node 570 from IAB topology 5001 to IAB topology 5003. Referring to FIG. 7 , the IAB node may be IAB node 701, and the migration process may involve migrating DUs of IAB node 701 from source F1 donor CU 703 to target F1 donor CU 707. Method 1020, as shown in and described with respect to FIG. 10 d , may be performed by software and / or hardware components. The target IAB donor CU may be implemented in communication device 400, as shown in and described with respect to FIG. 4 , wherein the method, as shown in and described with respect to FIG. 10 , is performed by one or more processing units, such as central processing unit 411. At step 1021, a target IAB donor CU (such as IAB donor CU 503 (707 in FIG. 7 ) in FIG. 5 ) receives an F1 setup request from an IAB node (such as IAB node 570 (701 in FIG. 7 ) in FIG. 5 ) requesting the establishment of an F1 connection between the target IAB donor CU and the IAB node. For example, the setup request may be 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 a 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 regarding 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 for which a mapping with identifiers of cells to be enabled (e.g., PCI and / or NCGI) is to be provided. 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, in response to receiving the F1 setup request, the target IAB donor CU 503 / 707 sends a response (such as setup response 814) to the IAB node 570 / 701. The response includes a request for one or more cells to be activated for the 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 with an F1 connection to the source F1 terminating donor CU 703, and the second logical DU entity is activated to perform a 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 the one or more cells to be activated (e.g., an identifier of each of the cells to be activated). Optionally, the response may also include a mapping between identifiers of the active cell(s) controlled by the first logical DU (e.g., PCI and / or NCGI) and the identifiers of the cell(s) to be activated. 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 activated 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 a handover request from the source F1 terminal donor CU 703 requesting that one or more user equipments (UEs, such as UE 708) 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 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 more cells), or based on a mapping between an identifier of a target cell enabled 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 activated in the second logical DU entity 706 as one or more candidate target cells for each of the one or more UEs served by the IAB node 701 based on mapping information received from the target F1 donor CU 707 or IAB node 701. The use of mapping avoids waiting for measurement reports from the UEs to trigger the handover procedure. When the target F1 donor CU 707 determines that the handover of the 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 that is routed via one or more paths in the IAB topology managed by the non-F1 donor CU. Thus, by sending a request to the IAB node to establish an F1 connection between the IAB node and a target IAB donor CU, a 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 the F1 connection, the IAB node may identify the target donor CU (e.g., via identification information sent by the source donor CU or, if no identification information is sent by the source donor CU, by determining that a non-F1 donor CU is the target donor CU) to enable handover of a UE served by the IAB node to the target donor CU. The determination that a DU of an IAB node is to be migrated can be triggered by an event. The event or events that trigger the determination that a DU of an IAB node is to be migrated can be left to the implementation. For example, the decision to migrate a DU can be based on the detection of a mobile unit (MT) migration from a first IAB topology to 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 in a third IAB topology. In this case, to avoid signaling for DU migration / UE handover to the second IAB topology, the DU is migrated directly to the third IAB topology. Another triggering event can be when the processing load level is detected to be above a predetermined threshold in the source F1 donor CU. DU migration is then triggered, and the target F1 donor CU is selected 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-making 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. Furthermore, for flexible IAB network management, it should be possible to migrate the mIAB-DU to a target F1 terminal donor CU that is not an F1 terminal donor CU (which can be referred to as an RRC terminal donor CU) but is different from the co-located mobile IAB-MT (mIAB-MT). Therefore, the IAB-DU of the mobile IAB node can migrate toward a target F1 terminal donor CU that is different from the non-F1 terminal donor CU of the serving co-located IAB-MT. Then, when the F1 donor CU serving the mAB-DU decides whether to perform mAB-DU migration, it may request the mobile IAB node to enable the second logical DU to be served by the target F1 donor CU identified in the request. For example, an F1 donor CU can 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, the activation 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 activation logical DU triggers the F1 setup procedure with a non-F1 terminal donor CU of the mobile IAB node. Therefore, when a request is made by its serving F1 donor CU to set up a new F1 connection, a mobile IAB node can perform 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 performs 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 this mIAB-DU migration, the target F1 donor CU may notify the source F1 donor CU of the activation of 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 can be used by the target F1 terminal donor CU of the mobile IAB node to inform the source F1 terminal donor CU about the ID of the cell served by the second logical DU of the mobile IAB node. Regarding the procedures for triggering, executing, and reporting F1 settings at DU migration, it can be observed that to trigger DU migration to a mobile IAB node determined by the source F1 donor CU, the following information can be passed to the mobile IAB node: - Instruction (regulation) to request DU migration, meaning that the F1 setup procedure should be started with the target logical DU. - Target F1 Donor CU identifier (optional). This information element is relevant when migrating a DU towards a target F1 Donor CU that is not the same as the non-F1 Donor CU of the co-located mobile IAB-MT. In the absence of this indication, the mobile IAB node should perform the F1 setup procedure towards the non-F1 donor CU. Given the low bit count used for this signaling, it may not be necessary to create a new F1AP procedure. Furthermore, since this is about F1 interface management, the gNB-CU configuration update procedure seems to be applicable to 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: - This F1 setup request is an instruction regarding 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 cell at the source logical DU. This information element helps the target F1 donor CU select the appropriate PCI for the cell to be activated at the target logical DU. Next, it is proposed that in the context of DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU should contain an explicit indication that the F1 setup is related to the DU migration of the mobile IAB node, and it should contain a list of PCIs at the source logical DU of this mobile IAB node. To report the results 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: -F1 indicates the success or failure of the setting, and in the event of a failure, the reason for the failure can be indicated. - ID of the cell enabled at the target logical DU by the target F1 donor CU. A mapping between the cell ID activated at the target logical DU and the cell ID currently in use at the source logical DU is included as an optional information element. This mapping should limit the scope of measurements to be performed at the UE, potentially even avoiding measurement reports from the UE to initiate the handover. Because the gNB-CU Configuration Update procedure appears suitable for triggering F1 setup, the gNB-DU Configuration Update procedure also appears to be a good candidate for the existing F1AP procedure to report the results of F1 setup. Next, it is proposed that a GNB-DU configuration update procedure can be used by an active IAB node to report the results of an F1 setup procedure toward a target CU to a source CU of a DU migration, and it is proposed that a mapping between the enabled cell IDs 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 report of the F1 setup results. Regarding the provision of identification information to the F1 donor CU, it should be noted that when a DU on a mobile IAB node is migrated to a target F1 donor CU that is different from a non-F1 donor CU of a 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. With 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 an mIAB MT and a co-located mIAB-DU into different donor CUs, the UE XnAP ID of the mIAB-MT assigned by the MT's CU and the gNB-ID of the MT's CU should be known to the mIAB-DU's CU. Considering the network integration situation, there are two options: - Option 1: The mobile IAB node provides identification information based on information received from a non-F1 donor CU (i.e., the mIAB-MT CU). - Option 2: Once the non-F1 donor CU knows the identifier of the F1 donor CU (ie, the CU of the mIAB-DU) from the mobile IAB node, the non-F1 donor CU provides the identification information. A disadvantage of Option 2 is that it requires the F1 donor CU to generate a UE XnAP ID for the mIAB-MT and provide it to the mobile IAB node, which will pass it along with the F1 donor CU's identifier to the non-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 used, and for consistency, the mobile IAB node should also provide identification information associated with the non-F1 donor CU to the target F1 donor CU at the DU migration site. This can be accomplished via the same F1AP signaling as for the network integration scenario. Continuing on, the mobile IAB node should also provide identification information related to the target non-F1 donor CU to its F1 donor CU while still using the same F1AP signaling during (continuous) MT migration. To cover all the scenarios considered above, the F1AP procedure gNB-DU configuration update is appropriate since it can be triggered at any time. Next, it is proposed that a mobile IAB node can use the gNB-DU configuration update procedure to notify the F1 donor CU of the non-F1 donor CU identifier and the mobile IAB-MT's XnAP UE ID at the CU. This procedure can be applied during network integration, DU migration, and MT migration of mobile IAB nodes. It may be noted that the source donor CU of the mIAB-MT may 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, the proposal is compatible with this description because the source non-F1 donor CU (ie, source donor CU of mIAB-MT) will pass information to the F1 donor CU (ie, donor CU of mIAB-DU) not directly but through the mobile IAB node. Furthermore, the identifiers of the non-F1 donor CU and XnAP UE ID that do not exclude IAB-MT at this CU may be included in the F1 Setup Request sent to the target F1 donor CU at 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 context of DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU may also include the identifier of the non-F1 donor CU and XnAP UE ID of the mobile IAB-MT at this CU. While the present invention has been described with reference to exemplary embodiments, it should be understood that the invention is not limited to the disclosed embodiments. Those 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 accompanying claims, abstract, and figures) and / or all steps of any disclosed method or process may be combined in any combination, except where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract, and figures) may be replaced by an alternative feature providing the same, equivalent, or similar functionality, unless expressly stated otherwise. Therefore, unless expressly stated otherwise, each disclosed feature is merely one example of a general series of equivalent or similar features. In the patent claims, 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 recited in mutually different appendices does not indicate that a combination of these features cannot be used to advantage. In the aforementioned embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or program codes in a computer-readable medium 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 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) a non-transitory, tangible computer-readable storage medium; or (2) a communication medium such as a signal or carrier wave. Data storage media can be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described herein. A computer program product may include computer-readable media. By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic 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 that can be accessed by a computer. Furthermore, 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 a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave are 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-transitory, tangible storage media. The term "disc" or "disk" as used herein includes minidiscs (CDs), laserdiscs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically. Combinations of these are also included within the scope of computer-readable media.

[0006] 30: Header 100: Communication System 101: Wired link 105: Vehicle 108: Buildings 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: Column 302: Column 304: Field 305: Column 306: Column 307: Payload 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 section 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 section or unit 580: User Equipment 590: Arrow 600:IAB node architecture 601:IAB Node 602: User Equipment 611:Logic DUIAB-DU1 612:Logic DUIAB-DU2 621: Access link 622: Link 700: Schematic simplified 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: Transport 711: Return delivery 712: Data Radio Transmission 720: First Step 730: Handover Procedure 735:Procedure 740:Transport 741: Return delivery 742: Data Radio Transmission 800: Schematic simplified diagram 801: RAN node DU 802: RAN node CU 803: Message 804: Message 810: Schematic simplified 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: Action 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: Steps 1002: Step 1003: Step 1010:Method 1011: Steps 1012: Steps 1013: Steps 1014: Steps 1015: Steps 1016: Steps 1017: Steps 1018: Steps 1020: Method 1021: Steps 1022: Steps 1106:Disk 5001:IAB topology 5002:IAB topology 5003:IAB topology 5050: Backhaul link

Claims

1. A method for a migration procedure in which distributed units (DUs) of integrated access backload (IAB) nodes are migrated from a source F1 terminal IAB grant central unit (CU) to a target F1 terminal IAB grant CU, the method comprising, at the source F1 terminal IAB grant CU: In the case where the DU of the IAB node is used to migrate from the source F1 terminal IAB grant CU to the target F1 terminal IAB grant CU, a message for establishing an F1 connection between the IAB node and the target F1 terminal IAB grant CU is sent to the DU of the IAB node; identification information is received identifying one or more cells that have been enabled at the second logical DU entity of the DU of the IAB node.

2. The method as described in claim 1, further comprising sending identification information for identifying the target F1 terminal IAB implementer CU to the IAB node.

3. The method as described in claim 2, wherein, The identification information used to identify the target F1 terminal IAB grant CU for the F1 connection includes the address associated with the target F1 terminal IAB grant CU.

4. As in request item 1, where the IAB node is an action IAB node.

5. The method of any one of claims 1 to 4, wherein sending includes sending the message to a first logical DU entity of the IAB node, wherein the first logical DU entity has an F1 connection with the source F1 terminal IAB implement CU.

6. The method of claim 1, further comprising receiving mapping information indicating a mapping between one or more cells that have been enabled at the second logical DU entity of the DU in the IAB node and one or more cells that have been enabled at the first logical DU entity of the DU in the IAB node.

7. The method as described in claim 1, further comprising: The delivery request is sent to the target F1 terminal IAB grant CU. The delivery request is used to request that one or more user equipments (UEs) served by the IAB node be delivered from the source F1 terminal IAB grant CU to the target F1 terminal IAB grant CU and to identify one or more candidate target cells for each UE.

8. The method as described in claim 6 or claim 7, further comprising: Based on the mapping information, one or more of the cells that have been enabled at the second logical DU entity are selected as one or more candidate target cells for each UE served by the IAB node, wherein the delivery request includes information for identifying the selected one or more candidate target cells.

9. The method as described in claim 7, further comprising: In response to receiving a delivery confirmation from the target F1 terminal IAB grant CU indicating that the delivery of one or more UEs has been accepted and identifying the target cell for each UE, the configuration information for configuring one or more UEs for their respective target cells is sent to the IAB node.

10. The method as described in claim 7, further comprising: After delivering one or more UEs to the target F1 terminal IAB implement CU, a request to disable the first logical DU entity of the DU of the IAB node having an F1 connection with the source F1 terminal IAB implement CU is sent to the IAB node.

11. The method as described in claim 7, further comprising: After the handover of one or more UEs to the target F1 terminal IAB facility CU is completed and the mobile terminal (MT) of the IAB node has been migrated to the RRC terminal facility CU, a traffic migration request 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 RRC terminal facility CU will be sent to the RRC terminal facility CU.

12. The method of claim 1 further comprises determining that the DU of the IAB node is to be migrated in response to determining that the migration of the MT of the IAB node toward the new parent IAB node has been completed.

13. A method for a migration procedure in which distributed units (DUs) of an integrated access backload (IAB) node are migrated from a source F1 terminal IAB grant central unit (CU) to a target F1 terminal IAB grant CU, the method comprising, at the IAB node: At the DU of the IAB node, a message is received from the source F1 terminal IAB grant CU for establishing an F1 connection between the target F1 terminal IAB grant CU and the IAB node; an F1 setting request for requesting the settings of the F1 connection is sent to the target F1 terminal IAB grant CU; and identification information of one or more cells that have been enabled at the second logical DU entity of the DU of the IAB node is sent to the source F1 terminal IAB grant CU.

14. The method as described in claim 13, further comprising: After receiving the message for establishing an F1 connection, the target F1 terminal IAB executor CU is identified, wherein sending includes sending the F1 setup request to the identified target F1 terminal IAB executor CU.

15. The method as described in claim 14, further comprising: Receive identification information from the source F1 terminal IAB executor CU for identifying the target F1 terminal IAB executor CU for the F1 connection.

16. The method as described in claim 13, wherein, The DU of the IAB node includes a first logical DU entity having an F1 connection to the source F1 terminal IAB grant CU, and the method further includes receiving information from the source F1 terminal IAB grant CU indicating the number of cells to be enabled at the second logical DU entity of the DU in the IAB node.

17. The method as described in claim 13, wherein, The DU of the IAB node includes a first logical DU entity having an F1 connection with the source F1 terminal IAB grant CU. The method further includes: after receiving the message for establishing an F1 connection, enabling the second logical DU entity to establish the F1 connection with the target F1 terminal IAB grant CU, wherein sending includes sending the F1 setting request to the target F1 terminal IAB grant CU through the second logical DU entity.

18. The method as described in claim 13, further comprising: After sending the F1 setup request, a response is received from the target F1 terminal IAB grant CU, the response containing a request for one or more cells to be enabled for the second logical DU entity; the one or more cells are enabled based on the received response.

19. The method as described in claim 18, wherein, The response contains identification information for identifying each of the one or more cells to be enabled.

20. The method of claim 18, further comprising sending information indicating the mapping between the one or more cells that have been enabled at the second logical DU entity and the one or more cells that have been enabled at the first logical DU entity of the DU of the IAB node to the source IAB grant CU.

21. The method as described in claim 13, further comprising: After receiving a request from the source F1 terminal IAB implement CU to disable the first logical DU entity of the DU of the IAB node having an F1 connection with the source F1 terminal IAB implement CU, the first logical DU entity is disabled.

22. The method as described in claim 13, wherein, Sending the F1 setup request includes sending an F1 setup request message for requesting settings for the F1 connection. The F1 setup request message includes identification information for identifying the source F1 terminal IAB provider CU when the mobile terminal (MT) of the IAB node has been migrated to the RRC terminal provider CU, or identification information for identifying the RRC terminal provider CU.

23. The method as described in claim 13, wherein, Sending the F1 setup request includes sending an F1 setup request message for requesting the settings of the F1 connection, wherein the F1 setup request message contains information indicating that the request for establishing the F1 connection is related to the migration of the DU of the IAB node.

24. The method as described in claim 13, wherein, This IAB node is an active IAB node.

25. The method of any one of claims 13 to 24, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection with the source F1 terminal IAB provider CU and the second logical DU entity, wherein receiving includes receiving the message for establishing an F1 connection at the first logical DU entity of the IAB node, and wherein sending includes sending the F1 setup request to the target F1 terminal IAB provider CU via the second logical DU entity.

26. An apparatus for an IAB node in an integrated access and load (IAB) communication system, the apparatus comprising: One or more processing units are configured to: in the case where the DU of the IAB node is used to migrate from the source F1 terminal IAB grant central unit (CU) to the target F1 terminal IAB grant CU, at the DU of the IAB node, receive a message from the source F1 terminal IAB grant CU for establishing an F1 connection between the target F1 terminal IAB grant CU and the IAB node; send an F1 setting request for requesting the setting of the F1 connection to the target F1 terminal IAB grant CU; and send identification information of one or more cells that have been enabled at the second logical DU entity of the DU of the IAB node to the source F1 terminal IAB grant CU.

27. The device as claimed in claim 26, wherein the one or more processing units are further configured to: identify the target F1 terminal IAB executor CU after receiving the message for establishing an F1 connection, wherein sending includes sending the F1 setup request to the identified target F1 terminal IAB executor CU.

28. The device as claimed in claim 26, wherein the one or more processing units are further configured to receive identification information from the source F1 terminal IAB executor CU for identifying the target F1 terminal IAB executor CU for the F1 connection, wherein the one or more processing units are configured to identify the target F1 terminal IAB executor CU from the received identification information.

29. The device as claimed in claim 26, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection with the source F1 terminal IAB implement CU, and wherein the one or more processing units are further configured to: upon receiving the message for establishing an F1 connection, enable the second logical entity for establishing the F1 connection with the target F1 terminal IAB implement CU, wherein the one or more processing units are configured to send an F1 setup request to the target F1 terminal IAB implement CU via the second logical DU entity.

30. The device as claimed in claim 26, wherein the one or more processing units are further configured to: receive a response from the target F1 terminal IAB grant CU after sending the F1 setup request, the response containing a request for one or more cells to be enabled for use with the second logical DU entity; and enable the one or more cells based on the received response.

31. The device as claimed in claim 30, wherein the response includes identification information that identifies each of the one or more cells to be enabled.

32. The apparatus of claim 26, wherein the one or more processing units are further configured to send information indicating a mapping between the one or more cells that have been enabled at the second logical DU entity and the one or more cells that have been enabled at the first logical DU entity of the DU in the IAB node to the source IAB grant CU.

33. The device as claimed in claim 26, wherein the one or more processing units are further configured to: deactivate the first logical DU entity after receiving a request from the source F1 terminal IAB implement CU for deactivating the first logical DU entity of the DU having an F1 connection with the source F1 terminal IAB implement CU.

34. The device as claimed in claim 26, wherein the one or more processing units are configured to send an F1 setup request message for requesting settings of the F1 connection, wherein the F1 setup request message includes identification information for identifying the source F1 terminal IAB provider CU or identification information for identifying the RRC provider CU when the mobile terminal (MT) of the IAB node has been migrated to the RRC terminal provider CU.

35. The device as claimed in claim 26, wherein the one or more processing units are configured to send an F1 setup request message for requesting the setup of the F1 connection, wherein the F1 setup request message includes information indicating that the request for establishing the F1 connection relates to the migration of the DU of the IAB node.

36. The device of any one of claims 26 to 35, wherein the DU of the IAB node includes a first logical DU entity having an F1 connection with the source F1 terminal IAB executor CU and the second logical DU entity, wherein receiving includes receiving the message for establishing an F1 connection at the first logical DU entity of the IAB node, and wherein sending includes sending the F1 setup request to the target F1 terminal IAB executor CU via the second logical DU entity.

37. An apparatus for an IAB grant central unit (CU) of an integrated access and load (IAB) communication system, the apparatus comprising: One or more processing units, in the case where the IAB grant CU operates as a source F1 terminal IAB grant CU, are configured to: send a message for establishing an F1 connection between the IAB node and the target F1 terminal IAB grant CU to the DU of the IAB node in the case where the distributed unit (DU) of the integrated access and reload (IAB) node is used to migrate from the source IAB F1 terminal grant CU to the target F1 terminal IAB grant CU; and receive identification information of one or more cells that have been enabled at the second logical DU entity of the DU of the IAB node.

38. The device as claimed in claim 37, wherein the one or more processing units are further configured to send identification information for identifying the target F1 terminal IAB implementer CU to the IAB node.

39. The apparatus of claim 37, wherein the one or more processing units are further configured to receive from the IAB node information indicating a mapping between one or more new cells that have been enabled at the second logical DU entity of the DU in the IAB node and one or more cells that have been enabled at the first logical DU entity of the DU in the IAB node.

40. The device as claimed in claim 37, wherein the one or more processing units are further configured to: send a delivery request to the target F1 terminal IAB grant CU, the delivery request being used to request the delivery of one or more user equipments (UEs) served by the IAB node from the source F1 terminal IAB grant CU to the target F1 terminal IAB grant CU and to identify one or more candidate target cells for each UE.

41. The device as claimed in claim 40, wherein the one or more processing units are further configured to: after completing the delivery of the one or more UEs to the target F1 terminal IAB implement CU, send a request to the IAB node for disabling the first logical DU entity of the DU having an F1 connection with the source F1 terminal IAB implement CU.

42. The device as claimed in claim 40, wherein the one or more processing units are further configured to: after completing the delivery of the one or more UEs to the target F1 terminal IAB facility CU, and when the mobile terminal (MT) of the IAB node has been migrated to the RRC terminal facility CU, send a traffic migration request to the RRC terminal facility CU for traffic requesting traffic release for traffic associated with the IAB node and routed via one or more paths in the IAB topology managed by the RRC terminal facility CU.

43. The device as claimed in any one of claims 37 to 42, wherein the one or more processing units are configured as a first logical DU entity for sending the message to the IAB node, wherein the first logical DU entity has an F1 connection to the source F1 terminal IAB implement CU.

44. A computer program including instructions that, when executed by one or more processing units of an integrated access load (IAB) node, cause the IAB node to: In a case where the DU of the IAB node is used to migrate from a source F1 terminal IAB grant central unit (CU) to a target F1 terminal IAB grant CU, receive at the DU of the IAB node a message from the source F1 terminal IAB grant CU for establishing an F1 connection between the target F1 terminal IAB grant CU and the IAB node; send an F1 setting request for requesting the settings of the F1 connection to the target F1 terminal IAB grant CU; and send identification information identifying one or more cells that have been enabled at a second logical DU entity of the DU of the IAB node to the source F1 terminal IAB grant CU.

45. A computer-readable medium carrying a computer program as claimed in claim 44.

Images