Migration management in an IAB communication system

Abstract

Methods and apparatus for use in managing a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, from a source IAB topology managed by a source IAB dono

Description

29 05 25 Field of the Invention The present invention generally relates to methods for use in a process for migrating 5 nodes between Integrated Access and Backhaul, IAB, topologies of a wireless communication system involving mobile IAB nodes. Particularly, the present invention relates to a method for use in managing a migration process for migrating a Distributed Unit, DU, of an IAB node, for example a mobile IAB node, between IAB topologies. 10 Background Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data 15 content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations. The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH). Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation 20 (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi. The demand for network densification increases due to the rising number of users and higher throughput requirement. Facing the issues of high deployment costs and time of the wired backhaul networks with 25 network densification, 3GPP has proposed, from release 16 for 5GNR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio / network resources as access communications (between a base station and UEs). 30 IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations. IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. However, millimeter waves are known to be 29 05 25 subject to strong attenuations of signal strength in some weather conditions (rain, fog), and to blockage in case of obstacles located in the path between the emitter and the receiver. To manage these potential radio link failures, a topological redundancy can be provided within the IAB framework, where multiple data paths are set up between the IAB base station 5 directly connected to the core network (also referred to as the “IAB-donor”) and the IAB base station serving UEs (also referred to as the “access lAB-node” for the UEs). Several intermediate IAB base stations (also referred to as lAB-nodes) may be involved in each of the several paths between the IAB-donor and the access lAB-node, thus forming alternative data paths within a multi-hop IAB topology. 10 Besides, 3GPP has been considering inter-donor redundancy, where an lAB-node, referred to as a boundary IAB node, can access two different parent nodes connected to two different lAB-donors, with each of the lAB-donors managing a different IAB topology (also referred to as IAB network). The boundary lAB-node, even though belonging to a single IAB topology, i.e. belonging to a single IAB-donor for configuration and management, is thus able 15 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 such inter-donor redundancy lies in the ability for the first IAB-donor to perform offloading by routing some of its packets through the second IAB topology, thus mitigating congestion issues or overcoming radio link failure issues that may arise in the first IAB topology. 20 There are other situations where an lAB-node becomes a boundary node. For example, in the case of partial migration of an lAB-node, decided by the IAB-donor, where the Mobile Termination (MT) of the lAB-node becomes connected to a single parent lAB-node belonging to another IAB topology controlled by another IAB-donor. This situation may also happen in the case of an lAB-node that experienced radio link failure (RLF) and that has recovered 25 through a parent lAB-node belonging to another IAB topology. In those cases, the migrated lAB-node and its potential descendant IAB node(s) still belong to the initial IAB topology, and such partial migration may be called MT migration. In order to ensure that traffic can be routed through the other IAB topology, MT migration should be followed by traffic migration where the traffic related to the boundary node and its descendant lAB-nodes is routed through the 30 other IAB topology up to the boundary node (i.e. the migrated lAB-node). Stationary lAB-nodes should only require a single MT migration. Indeed, a backhaul link (defined between two successive lAB-nodes in the wireless backhaul) may experience radio failure due to fluctuations of radio conditions and, for lAB-nodes that do not move, it should be a temporary situation with possible link recovery after some time. Thus, it should not be 29 05 25 required for such stationary lAB-nodes to perform multiple MT migrations in the same IAB topology or toward another IAB topology, and the transmission and the handling of multiple protocol messages can be avoided. For the same reason, the migration of the Distributed Unit (DU) of the lAB-node, leaving the control of the lAB-node to a new lAB-Donor, should not 5 be required for stationary nodes. Moreover, it is noted that such DU migration, that may be called full migration, also involves the handover of UEs served by the migrating mobile IAB-node. Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public / private passengers transportation, 10 goods delivery, food trucks ...). Some of these vehicles (e.g. buses, trams, trains), may have predictable routes and a significant number of collocated UEs (i.e. passengers’ devices). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as 15 mobile relays. These mobile relays would rely on 5G wireless backhaul (typically IAB, or Integrated Access &Backhaul) for connecting to a fixed donor device. Thus, based upon the fixed IAB foundations of releases 16 and 17, 3GPP is now considering Mobile IAB systems and architecture, as a part of the release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles (such as buses, 20 trains, taxis). In such scenarios, mobile lAB-nodes can be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage / capacity to on-board and / or surrounding UEs. The technical benefits of using VMRs include, among others, is the ability of the VMR to offer good radio link conditions to the nearby UEs. Additionally, comparing with a solution using a UE as relay (i.e. a Sidelink Relay solution), an lAB-node mounted on a vehicle is 25 expected to have better RF / antenna capabilities, and to have less stringent power / battery constraints than a relay UE. For a mobile lAB-node it may be worth performing multiple MT migrations or DU migration, as the connection to a parent lAB-node belonging to a first IAB topology may not occur again for a long time as the mobile lAB-node moves around or never again in the case 30 where the mobile lAB-node moves away from the parent lAB-node. Besides, for flexible IAB network management, the DU migration for an lAB-node may be performed toward an IAB-donor different to the lAB-donor associated to the MT of this lAB-node. Actually, the criteria for DU migration and MT handover differ: MT handover is driven by the radio conditions while DU migration decision may be based, for instance, on the 29 05 25 available connectivity between lAB-donors and / or for load balancing purpose. Thus, the source lAB-donor may select a suitable target lAB-donor for the DU migration of an lAB-node based on its own criteria. However, the target lAB-donor may not be able to handle the migrating lAB-node and the served UEs, for example due to current load at the target lAB-donor and / or 5 current load in the network. Therefore, some new mechanisms are required to allow the revocation or rejection of the DU migration of an lAB-node. Summary In accordance with an aspect of the present invention, there is provided a method, 10 performed at a target Fl terminating IAB donor CU, for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, as recited in claim 1 of the accompanying claims. In accordance with another aspect of the present invention, there is provided a method, performed at a source Fl terminating IAB donor CU, for use in a migration process for 15 migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, as recited in claim 8 of the accompanying claims. In accordance with another aspect of the present invention, there is provided a method, performed at an Integrated Access Backhaul, IAB, node, for use in a migration process for migrating a Distributed Unit, DU, of the IAB node as recited in claim 13 of the accompanying 20 claims. In accordance with a first example, there is provided a method for use in managing a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, from a source IAB topology managed by a source IAB donor Central Unit, CU, to a target IAB topology managed by a target IAB donor CU, performed at the target IAB donor 25 CU. The method comprises: receiving, from the source IAB donor CU, a request for requesting DU migration of the DU of the IAB node from the source IAB donor CU to the target IAB donor CU; determining whether to accept or partially accept or reject the DU migration of the IAB node; after determining to accept or partially accept or reject the DU migration, sending, to the source IAB donor CU, a response indicating the target IAB donor CU has determined to 30 accept or partially accept or reject the request for DU migration to the target IAB donor CU. In accordance with a second example, there is provided a method for use in managing a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, from a source IAB topology managed by a source IAB donor Central Unit, CU, to a target IAB topology managed by a target IAB donor CU, performed at the source IAB donor 29 05 25 CU. The method comprises: determining the DU of the IAB node is to be migrated to the target IAB donor CU; sending, to the target IAB donor CU, a request for requesting DU migration of the DU of the IAB node from the source IAB donor CU to the target IAB donor CU; receiving, from target IAB donor CU, a response indicating the target IAB donor CU has accepted or 5 partially accepted or rejected the request for DU migration to the target IAB donor CU. In an example, a decision to accept (i.e. fully accept) corresponds to a decision to accept the whole traffic (i.e. all of the traffic associated with the traffic profile(s) of the IAB node to be migrated) and all the UEs served by the lAB-node. A decision to partially accept corresponds to a decision to accept some or part of the traffic (i.e. accept some or a subset of 10 the traffic profile(s) associated with the IAB node to be migrated) and / or a limited number or subset or some of the UEs served by the IAB node. Particularly, a decision to partially accept may correspond to a decision to accept the Fl setup connection with the IAB node but to accept some or part of the traffic (i.e. accept some or a subset of the traffic profile(s) associated with the IAB node to be migrated) and / or a limited number or subset or some of 15 the UEs served by the IAB node. In accordance with a sixth aspect of the present invention, there is provided an apparatus for an IAB donor CU as recited in claim 25 of the accompanying claims. In accordance with a seventh aspect of the present invention, there is provided an apparatus for an IAB node as recited in claim 26 of the accompanying claims. 20 The method / apparatus in accordance with one or more embodiments of the present invention enables the target IAB donor CU to accept or partially accept or reject or revoke the DU migration (and thus, the subsequent handover of UEs served by the IAB node) and send a response indicating whether the DU migration has been accepted or rejected or revoked. The target IAB donor CU can inform the source IAB donor CU of its decision to accept or partially 25 accept or reject or revoke DU migration by sending a message to the source IAB donor CU or to the IAB node (which can then inform the source IAB donor CU). With the target IAB donor CU sending a response to the source IAB donor CU to indicate the DU migration has been accepted or partially accepted or rejected, triggering activation of a second logical DU in the IAB node when DU migration is rejected can be avoided. With the target IAB donor CU 30 sending a response to the IAB node to indicate the DU migration has been accepted or partially accepted or rejected, the Fl setup procedure will have already been completed which saves setup time when DU migration is accepted. Thus, the method / apparatus in accordance with one or more embodiments of the present invention enables the target IAB donor CU to reject or revoke the DU migration (and thus, the subsequent handover of UEs served by the IAB node) 29 05 25 in the case the target IAB donor CU is not able to accommodate the IAB node DU and the traffic related to the served UEs (because of some lack of processing resources, or some lack of radio / network resources) and to inform the source IAB donor CU so that appropriate action can be taken. 5 Further example features of the invention are described in other independent and dependent claims. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa. 10 Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any 15 aspect or example described above and a computer readable storage medium carrying the computer program. Brief Description of the Drawings Different aspects of the invention will now be described, by way of example only, and 20 with reference to the following drawings in which: Figure lisa schematic diagram of a communication system in which the present invention may be implemented according to one or more embodiments; Figure 2a and 2b schematically illustrate stacks of some protocol layers involved in IAB operations; 25 Figure 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet; Figure 4 is a block schematic diagram of an example wireless communication device in accordance with embodiments of the present invention; Figure 5 is a schematic diagram of an example IAB communication system (or IAB 30 network system) in which embodiments and examples of embodiments of the present invention may be implemented; Figure 6 is a schematic and simplified diagram illustrating an example of lAB-node architecture enabling its DU migration from a source IAB topology to a target IAB topology; 29 05 25 Figure 7 is a simplified diagram illustrating example message flows to perform the DU migration of an lAB-node including the handover of UEs served by the migrating lAB-node; Figure 8 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to allow a target Fl terminating donor-CU to partially 5 accept or reject the DU migration of an lAB-node; Figure 9a is a simplified diagram illustrating an example message flow, according to one or more embodiments of the invention, of a procedure used by a RAN node CU to report configuration information to another RAN node CU; Figure 9b is a simplified diagram illustrating an example message flow, according to 10 one or more embodiments of the invention, of a procedure used by a RAN node CU to manage the DU migration of a RAN node in coordination with another RAN node CU, including the signaling to partially accept, to reject or to revoke the DU migration; Figure 10a is a simplified diagram illustrating an example message flow, according to one or more embodiments of the invention, of a procedure to perform the activation of a 15 logical DU in a RAN node, including the signaling to partially accept, to reject or to revoke by a RAN node CU the DU migration of the RAN node; Figure 10b is a simplified diagram illustrating an example message flow, according to one or more embodiments of the invention, of a procedure to setup a logical DU in a RAN node, including the signaling to partially accept, to reject or to revoke a DU migration of the 20 RAN node by a RAN node CU; Figure 10c is a simplified diagram illustrating an example message flow of a procedure to remove a logical DU in a RAN node; Figure 1 la is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an lAB-node, the 25 DU migration of the lAB-node; Figure 1 lb is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an lAB-node, the DU migration of the lAB-node; Figure 12a is a flowchart of another example method in accordance with embodiments 30 of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- node, the DU migration of the lAB-node; Figure 12b is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at an lAB-node its DU migration to a target Fl terminating donor-CU; 29 05 25 Figure 12c is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at a target Fl terminating donor-CU of an lAB-node, the DU migration of the lAB-node. 5 Detailed Description Figure 1 illustrates an example communication system 100, in particular 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 lAB-node(s). Although in the following description, embodiments and examples of embodiments of the present 10 invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having a mobile base station. In particular, the following description predominantly uses terminology specific to 5G, but it should be appreciated that such terminology also applies to elements or processes performing an equivalent function in 15 other communi cati on sy stem s. The system 100 comprises a plurality of UEs (User Equipment) 132, 133, 131 and 134, a remote core network 110, a main Base Station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (also referred to in the following as IAB-nodes), and a mobile Integrated Access and Backhaul (IAB) station 123 mounted on a vehicle 20 105 (for example, a bus, a train, a taxi, a car, etc.). The main Base Station 120, also referred to as the lAB-donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, lAB-donor 120 is a 5GNR gNB with additional functionality to support IAB features, as defined in 3GPP TS 25 38.300 vl7.2.0 specification document. In order to extend the network coverage of lAB-donor 120 and reach the remote UEs 132, 133 and 131, IAB stations 121 and 122, also referred to as lAB-nodes 121 and 122, have been installed by the operator. By acting as relaying nodes between the lAB-donor 120 and the UEs 132 and 133, lAB-nodes 121 and 122 allow overcoming the reachability issue 30 resulting from presence of building 108, which is an obstacle to the propagation of radio waves and hence to the direct attachment and further communications between the UEs and the lAB-donor 120. This is particularly true when the communications between the IAB-donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena. 29 05 25 The lAB-donor 120 also serves UE 134, which is directly connected to it. The mobile IAB station 123, also referred to as mobile lAB-node 123 or mlAB node 123, is an lAB-node that is mounted on vehicle 105 and provides network coverage and capacity extension, allowing the lAB-donor 120 to reach onboard remote UEs, like remote 5 UE 135, as well as surrounding UEs or UEs in the vicinity of the lAB-node 123, like remote UE 136. The lAB-donor 120 and the lAB-nodes 121, 122 and 123 are thus forming 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 will be used interchangeably in the 10 following. The specification of the Integrated Access and Backhaul (IAB) is spread over several 3GPP standard documents, including: - TS 38.300 RAN architecture (V17.2.0), - TS 38.321 MAC protocol (V17.2.0), 15 - 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 Fl Application Protocol (V17.2.0). 20 As lAB-donor 120 and lAB-nodes 121, 122 and 123 are respectively connected to UEs 134, 131, 132, 133, 135 and 136, they are considered as Access lAB-nodes fortheir respectively connected UEs. The lAB-donor 120 is a logical node that provides the NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed 25 unit(s) (DU or gNB-DU functionality). The lAB-donor-CU or donor-CU (also referred to in the following as lAB-donor CU or IAB donor CU) hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling operation of one or more DUs and each of the one or more lAB-donor-DUs or donor DUs (also referred to in the following as lAB-donor DU or IAB donor DU) includes 30 lower layer protocols, such as the RLC, MAC and physical layer protocols. The lAB-donor-CU or donor-CU and lAB-donor DU or donor DU may be located far from the other or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. It aims at terminating the NR access interface to the UEs and next-hop lAB-nodes, 29 05 25 and at terminating the Fl protocol to the lAB-donor gNB-CU functionality as shown in Figures 2a and 2b discussed below. The IAB nodes, which may serve multiple radio sectors, are wireless backhauled to the lAB-donor 120, via one or multiple hops over one or more intermediate IAB nodes. They 5 form a directed acyclic graph (DAG) topology with the lAB-donor at its root. The IAB nodes each consist of an IAB-DU (lAB-Distributed Unit) and an IAB-MT (lAB-Mobile Termination). The gNB-DU functionality on an lAB-node is also referred to as IAB-DU and allows the downstream (toward the UE) connection to the next-hop IAB or to a UE. The IAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access 10 Stratum (NAS) functionalities to connect to the gNB-DU of an upstream lAB-node (including the lAB-donor 120 in which case it connects to the lAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration). In this DAG topology, the neighbour node on the IAB-DU’s interface is referred to as child node and the neighbour node on the IAB-MT’s interface is referred to as parent node. 15 The direction toward the child node is further referred to as downstream while the direction toward the parent node is referred to as upstream. The lAB-donor 120 (e.g. the lAB-donor CU) performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the lAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data 20 packets. Figures 2a and 2b schematically illustrate stacks of some protocol layers involved in IAB operations. Fl interface supports the exchange of signalling information (e.g. control traffic) between the endpoints, as well as the data transmission (e.g. user traffic transmission) to the 25 respective endpoints. From a logical standpoint, Fl interface is a point-to-point interface between the endpoints. In 5G NR, Fl-C is the functional interface in the Control Plane (CP) between the IAB-donor -CU and an lAB-node -DU (e.g. of lAB-node 2), and between the lAB-donor-CU and an lAB-donor DU. Fl-U is the functional interface in the User Plane (UP) for the same units. 30 Fl-C and Fl-U are shown by reference 212 in Figure 2a. In this example, Fl-U and Fl-C are carried over two backhaul hops (from lAB-donor to lAB-node 1 and then from lAB-node 1 to IAB-node2). In the User Plane, boxes 210 at the lAB-donor-CU and the lAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer. GTP-U stands for GPRS Tunnelling 29 05 25 Protocol User Plane. GTP-U Tunnels are used to carry encapsulated PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints (refer to 3GPP TS 29.281 for more details), here boxes 210 at the lAB-donor-CU and the lAB-node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram 5 service and fit to use with an IP protocol. In the Control Plane, boxes 210 indicate the F1AP (Fl Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer. The Fl Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signalling services between the lAB-donor-CU and the lAB-node DU, or UE associated services. These 10 services are for example initialization, configuration, and so on. The well-known SCTP layer provides reliable, in sequence transport of messages with congestion control. Fl-U and Fl-C rely on an IP transport layer between the lAB-donor-CU and the IAB-node DU as defined in 3GPP TS 38.401. The transport between the lAB-donor DU and the lAB-donor-CU also uses an IP 15 transport Layer over various media, like for example wires or optical fiber when the IAB-donor-CU is remote from the lAB-donor DU, or locally in a virtual instantiation of the IAB-donor-CU and the lAB-donor DU on the same physical machine. lAB-specific transport between lAB-donor-CU and lAB-donor-DU is specified in 3GPP TS 38.401. LI and L2 on the Figure 2a stand respectively for the transport and physical layers 20 appropriate to the medium in use. The IP layer can also be used for non-Fl traffic, such as Operations, Administration and Maintenance traffic. On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is 25 specified in TS 38.340. The lAB-DU’s IP traffic is routed over the wireless backhaul via the BAP sublayer. In a downstream direction, upper layer packets are encapsulated by the BAP sublayer at the lAB-donor DU, thus forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity (and corresponding BAP entities in the 30 IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the destination lAB-node (which may be an access lAB-node should the upper layer packets in the BAP packets be intended for a UE). In an upstream direction, upper layer packets are encapsulated by the BAP sublayer at an initiator lAB-node (which may be an access lAB-node should the upper layer packets 29 05 25 come from a UE), thus forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally deencapsulated by the BAP sublayer at the lAB-donor DU. 5 On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packets, and which is set by the BAP sublayer of the emitting lAB-donor-DU or initiator lAB-node (e.g. a network node in the IAB network generating the BAP packets). Figure 3 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 10 17.2.0. The payload section 307 is usually an IP packet. The header 30 includes fields 301 to 306. Field 301, named D / C field, is a Boolean 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 (to be ignored by the receiver). 15 Fields 305 and 306 indicate together the BAP routing ID for the BAP packet. BAP address field 305, also referred to as DESTINATION field, is located in the leftmost 10 bits while BAP path identity field 306, also referred to as PATH field, is located in the rightmost 10 bits. Field 305 carries the BAP address (i.e. on the BAP sublayer) of the destination IAB-20 node or lAB-donor DU for the BAP packet. For the purpose of routing, each lAB-node and lAB-donor DU in an IAB network is configured (by lAB-donor-CU of the IAB network) with a designated and unique BAP address. Field 306 carries a path ID identifying the routing path the BAP packet should follow to this destination in the IAB topology. For the purpose of routing, the routing paths, including their path ID, are configured (by lAB-donor-CU of 25 the IAB network) in the lAB-nodes of the IAB network. The BAP header is added to the packet when it arrives from upper layers to the BAP layer, and it is stripped off by the BAP layer when it has reached its destination node. The selection of the packet’s BAP routing ID is configured by the lAB-donor-CU. For instance, when the BAP packet is generated by a node, i.e. either by the lAB-donor-30 DU for downstream transmission or by an initiator (which may be an access lAB-node should the upper layer packets come from a UE) for upstream transmission, the BAP header with the BAP Routing ID is built by this node according to a configuration table defined in 3GPP TS 38.340. This table is called Downlink Traffic to Routing ID Mapping Configuration table in the lAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the 29 05 25 initiator lAB-node. In intermediate lAB-nodes, the BAP header fields are already specified in the BAP packet to forward. As mentioned above, these configuration tables defining the BAP paths (hence the routing strategy and the configuration of the lAB-nodes given the IAB network topology) are 5 usually defined by the lAB-donor-CU and transmitted to the lAB-nodes to configure them. To transport messages over the 5GNR radio medium, three more sublayers (RLC, MAC and PHY) are implemented at each lAB-node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for the segmentation or reconstruction of packets. It is also responsible for requesting retransmissions of missing packets. The RLC 10 layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for the user data and for the mapping of logical channel to the transport channels. The MAC handles also a part of the Hybrid Automated Repetition request scheme. The MAC layer is detailed in TS 38.321. On the emitter or transmitter side, the MAC encapsulates the data packet issued from the RLC. It 15 adds a header carrying information necessary to the MAC function. On the receiver side, the MAC decapsulates the data packet issued from the PHY sublayer, deletes its header and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (the air) by converting the stream of information into physical modulation signals, modulating a carrier frequency at emitter side. At the receiver side, the 20 PHY sublayer converts the physical modulation signals back to a stream of information. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214. To pass messages towards the user or control plane, two other sublayers are used in the UE and lAB-donor-CU: the PDCP (Packet Data Convergence Protocol) sublayer and either the SDAP (Service Data Adaptation Protocol) sublayer for the User Plane communications or 25 the RRC (Radio Resource Control) sublayer for the Control Plane communications. The PDCP sublayer handles IP Header compression / decompression, ciphering / deciphering, and handles the integrity on the data packet if necessary. It mandatorily numbers the packets on the emitter side and reorders the packets on the receiver side. The PDCP sublayer is described in 3GPP TS38.323. 30 SDAP sublayer 220 for the User Plane handles the Quality of Service. It is described in TS38.324. On the UE side, the SDAP sublayer exchanges the payload data with the user’s application (voice, video, etc... - not shown in the Figure). On the lAB-donor-CU side, the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc...). 29 05 25 RRC sublayer 220 for the Control Plane handles the configuration of the protocol entities of the User Plane protocol stack. It is described in TS38.331. It is responsible for the handling of, inter alia, broadcasting information necessary to a UE to communicate with a cell; transmitting paging messages, managing connection, including setting up bearers; 5 mobility functions; measurement configuration and reporting; devices capabilities. The interface (for both CP and UP) between nodes using the layers PDCP, RLC, MAC and PHY is referenced NR-Uu. This mainly concerns the interface with the UE. The interface (for both CP and UP) between nodes using the layers BAP, RLC, MAC and PHY is named BackHaul RLC Channel (BH RLC channel). This mainly concerns the 10 interfaces between the lAB-nodes. NR-Uu is the interface between the UE and the radio access network, i.e. its access lAB-node (for both CP and UP). Figure 2b comes from 3GPP TS 38.300 vl7.2.0 and illustrates the protocol stack for the support of lAB-MT’s RRC and NAS connections. The Non-Access Stratum (NAS) protocol 15 handles the messages between the core network and a user equipment, or an lAB-node. It manages the establishment of communication sessions and maintains communications with the lAB-node or the user equipment as it moves. The 5G NAS is described in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the Core Network that receives all connection and session related information from the UEs 20 connected to the IAB node, as well as similar information for the lAB-node. AMF is only responsible for handling connection and mobility management tasks. The IAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the lAB-donor-CU. These SRBs are transported between the IAB-MT and its parent node(s) over NR-Uu interface(s). 25 Figure 4 shows a schematic representation of an example communication device (apparatus) or station, in accordance with one or more example embodiments of the present disclosure. The communication device 400 may be a device such as a micro-computer, a workstation or a light portable device. The communication device 400 may comprise a 30 communication bus 413 to which there are preferably connected: - a central processing unit 411, such as a microprocessor, denoted CPU. The central processing unit 411 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out the processing required for the operation of 29 05 25 the communication device 400. The number of processors and the allocation of processing functions to the central processing unit 411 is a matter of design choice for a skilled person; - memory for storing data and computer programs containing instructions for the operation of the communication device 400. The computer programs may contain a number 5 of different program elements (modules) or sub-routines containing instructions for a variety of operations and for implementing the methods in accordance with one or more embodiments of the invention; and - at least one communication interface 402 for communicating with other devices or nodes in a communication system, such as the communication system of Figure 1. The at 10 least one communication interface 402 may be connected to the radio communication network 403, such as a wireless communication network for 5G NR (e.g. according to release 17 and / or subsequent releases), over which digital data packets or frames or control frames are transmitted. The frames are written from a FIFO sending memory in RAM 412 to the communication interface for transmission or are read from the communication interface for 15 reception and writing into a FIFO receiving memory in RAM 412 under the control of a software application running in the CPU 411. Each of a donor CU, a donor DU, an IAB node and a UE may be implemented in such a communication device / apparatus 100. The memory may include: 20 - a read only memory 407, denoted ROM, for storing computer programs for implementing methods in accordance with one or more embodiments of the invention; - a random-access memory 412, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to 25 one or more embodiments of the invention. Optionally, the communication device 400 may also include the following components: - a data storage means 404 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; - a disk drive 405 for a disk 406, the disk drive being adapted to read data from the disk 30 1106 or to write data onto said disk; - a screen 409 for displaying decoded data and / or serving as a graphical interface with the user, by means of a keyboard 410 or any other input / output means. In an example arrangement, the communication bus 413 provides communication and interoperability between the various elements included in the communication device 400 or 29 05 25 connected to it. The representation of the bus is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by means of another element of the communication device 400. The disk 406 may optionally be replaced by any information medium such as for 5 example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the communication device, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented. 10 The executable code may optionally be stored either in read only memory 407, on the hard disk 404 or on a removable digital medium such as for example a disk 406 as described previously. According to an optional variant, the executable code of the programs can be received by means of 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 15 404, before being executed. The central processing unit 411 may be adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example 20 on the hard disk 404 or in the read only memory 407, are transferred into the random-access memory 412, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention. In an example implementation, the communication device (apparatus) is a programmable device / apparatus which uses software to implement the invention. Instructions 25 may be executed by one or more processors of the apparatus, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry to implement the invention for a network node (e.g. IAB node, IAB donor CU). Accordingly, the term “central processing unit” as used herein may refer to any 30 of the foregoing structure or any other structure suitable for implementation of the techniques described herein. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC or other logic element). 29 05 25 Figure 5 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, the radio links between the IAB nodes and between the IAB nodes and the IAB donor DUs (referred to as BH radio links) are 5 operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance. An IAB network will also be referred to as an IAB topology or topology and so in this application, the terms IAB network and IAB topology and topology will be used interchangeably. IAB communication system 500 is composed of three IAB networks or IAB topologies 10 5001, 5002, and 5003 with each IAB topology comprising a set of IAB nodes (e.g. the set may comprise a plurality of IAB nodes or at least one IAB node) and an lAB-donor-CU for controlling or managing the plurality of IAB nodes. The set of IAB nodes may include one or more lAB-nodes, such as initiator lAB-nodes which generate BAP packets and also intermediate or relay lAB-nodes. Each of the IAB nodes communicate with at least one other 15 IAB node over a wireless backhaul (BH) link. Although Figure 5 shows three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system comprising more than two IAB topologies with each topology comprising a set of IAB nodes and an IAB donor-CU as discussed above. As discussed above, each IAB node comprises a Mobile Termination (MT) part or unit, 20 controlled and configured by the IAB donor using RRC messaging as defined in 3GPP TS 38.331, and a Distributed Unit (DU) part, controlled and configured by the IAB donor using Fl-AP messaging as defined in 3GPP TS 38.473. For example, lAB-node 510 comprises a MT part or unit 511 and a DU part 512. IAB topology 5001 includes lAB-donor-CU 501 (identified as Donor 1-CU in Figure 5), 25 and its associated lAB-donor-DU 504 (identified as Donor 1-DU1 in Figure 5), and a plurality of lAB-nodes 510 and 520, similar to lAB-nodes 121 and 122. IAB topology 5002 includes lAB-donor-CU 502 (identified as Donor2-CU in Figure 5), its associated lAB-donor-DUs, lAB-donor-DU 505 (identified as Donor2-DUl in Figure 5) and lAB-donor-DU 506 (identified as Donor2-DU2 in Figure 5), and a plurality of IAB- 30 nodes 530, 540, 550, similar to lAB-nodes 121 and 122, and lAB-node 570, that may be similar to mobile lAB-node 123. All lAB-nodes can be access nodes serving UEs like the UE 580 served by the mobile lAB-node 570. The IAB topology 5002 is transparent for the UE 580 that connects to the donor-CU 502 through the DU part or unit 572 of the mobile IAB- 29 05 25 node 570. Although figure 5 shows only one UE 580, it will be appreciated that there will be a plurality of UEs connected to the network nodes of the IAB communication system 500. IAB topology 5003 includes lAB-donor-CU 503 (identified as Donor3-CU in Figure 5), and its associated lAB-donor-DU 507 (identified as Donor3-DUl in Figure 5), and an IAB-5 node 560, similar to lAB-nodes 121 and 122. A wired backhaul IP network interconnects the lAB-donor-CUs 501, 502, and 503, and the lAB-donor-DUs 504, 505, 506 and 507 through the wired backhaul 508. For instance, this wired backhaul 508 consists of optical fiber cables. lAB-Donor-CU 501, lAB-Donor-DU 504 and lAB-nodes 510 and 520 are part of the 10 same IAB network or IAB topology 5001, which is configured and managed or controlled by lAB-Donor-CU 501. lAB-Donor-CU 502, lAB-Donor-DUs 505 and 506, and lAB-nodes 530, 540, 550 are part of the same IAB network or IAB topology 5002, which is configured and managed or controlled by lAB-Donor-CU 502. 15 lAB-Donor-CU 503, lAB-Donor-DU 507, and lAB-node 560 are part of the same IAB network or IAB topology 5003, which is configured and managed or controlled by IAB-Donor-CU 803. Each IAB-DU and IAB Donor DU supports wireless communication in a coverage area(s) referred to as cell(s) (not shown in figure 5). In other words, each IAB-DU and IAB 20 Donor DU is associated with cell(s). Wireless communication devices (such as UEs, or other lAB-nodes) located within a cell may establish communication links with the node (i.e. IAB-DU or IAB Donor DU) serving the cell in order to communicate with other devices (e.g. other UEs, lAB-nodes, servers providing access to the Internet, etc.) via the node. It is assumed that the mobile lAB-node 570 had initially a single parent lAB-node 520, 25 and that lAB-node 570 belongs to the IAB topology 5001 controlled by the lAB-Donor-CU 501. The lAB-Donor-CU is thus operating as the Fl terminating donor-CU (which may also be referred to as a Fl-terminating lAB-donor-CU or Fl donor-CU). When moving, and in view of its proximity to IAB topology 5002, in particular to the lAB-node 530 when the mobile lAB-node 570 is in the position shown in dotted lines in figure 5, the mobile IAB- 30 node 570 may be able to establish a wireless BH link 5030 with the lAB-node 530. Such a BH link is possible for a stationary lAB-node, and it is very likely to happen for a mobile lAB-node like lAB-node 570, moving, for instance, in the direction of the IAB topology 5002 (shown by arrow 590 in figure 5). 29 05 25 Then, the Fl donor-CU 501 may have decided to perform the migration of the MT part 571 of the lAB-node 570 toward the IAB topology controlled by the donor-CU 502, which became the non-Fl terminating donor-CU (which may also be referred to as a non-Fl -terminating lAB-donor-CU or non-Fl donor-CU, or RRC terminating donor-CU) for the 5 lAB-node 570 (i.e. the MT part 571 of the lAB-node 570 is migrated toward the parent IAB-node 530). For this purpose, the Fl donor-CU 501 may have initiated 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 lAB-node 570 has descendant lAB-nodes). As a result, the lAB-node 570 still belongs to the IAB topology 5001, with its Fl connection to the donor-CU 501, but its RRC 10 connection is now to the donor-CU2 502. After that procedure, the lAB-donor-CU 501 may request the migration toward the IAB topology 5002 (i.e. through the donor-DU 505) of the backhaul traffic (e.g. user traffic, control traffic) related to the lAB-node 570. In this case, the donor-CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. In the IAB communication system, all traffic communicated 15 over backhaul links uses a Fl interface (Fl-C or Fl-U) between an IAB donor CU and an IAB-DU. Thus, the traffic or backhaul traffic that is offloaded or migrated is Fl traffic and can include control and user traffic. While the mobile lAB-node 570 is still moving in the direction shown by arrow 590, the MT part 571 of the lAB-node 570 may then have been migrated by the non-Fl donor-CU 20 502 toward the parent lAB-node 550, using the backhaul link 5050 between the lAB-node 550 and the lAB-node 570. For this purpose, the non-Fl donor-CU 502 may have applied the intra-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.2.3.1 (or section 8.17.3.2), resulting in a consecutive MT migration (or another MT migration to another lAB-node) of the lAB-node 570 with a new single parent lAB-node 550. Still, the 25 lAB-node 501 has its Fl connection with the donor-CU 501 and its RRC connection with the donor-CU2 502. After being informed to use the donor-DU 506 instead of donor-DU 505 to route the Fl traffic related to the lAB-node 570, the donor-CU 501 may request the migration of the traffic related to the lAB-node 570 toward the IAB topology 5002. In this case, the donor-CU 30 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. While further moving, this time in the direction of IAB topology 5003 controlled by the donor-CU 503, the lAB-node 570 may become in a position where a backhaul link 5060 with the lAB-node 560 may have a better quality than the backhaul link 5050 with the lAB-node 29 05 25 550. Thus, the donor-CU 502 may apply the inter-CU Topology Adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or 8.17.3.2. After this consecutive MT migration, the lAB-node 501 still belongs to the IAB topology 5001, with its Fl connection with the donor-CU 501, but its RRC connection is now with the donor-CU 503 and thus, the 5 donor-CU 503 becomes the non-Fl terminating donor-CU (or non-Fl donor-CU, or RRC terminating donor-CU). However, the donor-CU 501 has to be informed of the new non-Fl donor-CU 503 for the lAB-node 570 and of the new donor-DU 507 to redirect the offloaded traffic (Fl traffic, control and user traffic) through the donor-DU 507 instead of donor-DU 506. 10 In all the MT migration cases described above, the UE 580 still connects to the donor-CU 501 through the DU part or unit 572 of the mobile lAB-node 570. In case the lAB-node 570 has some child lAB-node(s), such child lAB-node still belongs to the IAB topology 5001, and it is still fully controlled (through Fl and RRC connections) by the donor-CU 501. At any state of migration of the MT part 571 of the lAB-node 570, thus regardless of 15 whether the MT part 571 of the lAB-node 570 has migrated to IAB topology 5002 or another IAB topology and so regardless of whether the lAB-node 570 has a non-Fl terminating donor-CU and if it does, whether it’s the non-Fl terminating donor-CU 502 or another donor-CU, the Fl donor-CU 501 may decide to perform the migration of the DU part of the IAB-node 570. The reason for performing DU migration may be to reduce the processing load at 20 the Fl donor-CU 501, or because the lAB-node 570 is geographically far from the Fl donor CU 501 and close to an area where there is no more Xn connectivity between the Fl donor CU 501 and a target donor-CU. After the decision to perform the DU migration of the IAB-node 570, the Fl donor-CU 501 has also to decide toward which donor-CU (which is referred to as the target Fl donor-CU) the DU migration shall be performed. It may be a DU 25 migration toward the current non-Fl terminating donor-CU (i.e. the default choice) if there is a current non-Fl terminating donor-CU and in this case the non-Fl terminating donor-CU becomes the target Fl donor-CU, or to another target Fl donor-CU. It is optimal for an IAB-node to have the same donor-CU controlling both the MT and the DU of the lAB-node, as it avoids to setup the transport migration from one lAB-topology to another lAB-topology for 30 the backhaul traffic from / to the lAB-node. However, the reason to perform the DU migration to a donor-CU different from the current non-Fl terminating donor-CU 502, may be to anticipate the next move of the lAB-node in the direction of another IAB topology. For instance, the lAB-node 570 may become in a position where a backhaul link 5060 with the lAB-node 560 may have a better quality than the backhaul link 5050 with the lAB-node 550. 29 05 25 As the lAB-node 560 belongs to the IAB topology 5003 controlled by the donor-CU 503, the donor-CU 503 may soon become the non-Fl terminating donor-CU for the lAB-node 570 (after a new consecutive MT migration), and it is natural to select the donor-CU 503 as the target Fl-terminating donor-CU for the lAB-node 570. Besides, if the lAB-node 570 is 5 mobile and its trajectory is predictable (e.g. for a bus or a train), the Fl donor-CU 501 may be aware of a suitable target Fl-donor-CU controlling cells through which the lAB-node 570 will soon connect to the network. For instance, while the non-Fl terminating donor-CU of the lAB-node 570 is the donor-CU 502, the Fl donor-CU may decide the DU migration of the lAB-node 570 should be directly toward the donor-CU 503, as the lAB-node 570 may rapidly 10 cross and not stay in the IAB topology 5002 controlled by the donor-CU 502. To not perform the DU migration toward the donor-CU 502, and instead perform DU migration toward the donor-CU 503, will avoid protocol messages for the intermediate DU migration of the IAB-node 570. When DU migration is performed, handover of the UEs served by the lAB-node 570 must also be performed. Thus, to not perform the DU migration toward the donor-CU 15 502 will also avoid the intermediate handover of UEs served by the lAB-node 570 to the donor-CU 502, before a new DU migration and UEs handover toward the donor-CU 503. The procedure to perform a DU migration and the UEs handover toward a selected target Fl donor-CU is described in more detail with reference to the subsequent figures. Figure 6 illustrates an example of lAB-node architecture 600 which enables migration 20 of the DU of the lAB-node (DU migration) from a source IAB topology to a target IAB topology. The IAB node 601, which may be a mobile lAB-node like the lAB-node 570, is composed of an IAB-MT part or unit IAB-MT 610 (like the MT part or MT 571 of the IAB-node 570 of figure 5), a part or unit IAB-DU1 611, and a part or unit IAB-DU2 612. IAB-25 DU1 and IAB-DU2 are two logical DU entities (also referred to as logical DUs) 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 separated physical layers. At the DU migration of the lAB-node 601, both logical DUs are active: one of the logical DU terminates the Fl interface with a source Fl donor-CU (like 30 donor-CU 501 in figure 5), while the other logical DU terminates the Fl interface with a target Fl donor-CU (like donor-CU 502 or 503 in figure 5). Otherwise (i.e. when DU migration is not to be performed), only one logical DU is sufficient for IAB operations. As an example and with reference to the IAB communication system of figure 5, the Fl terminating donor CU of the IAB node 601 (i.e. IAB node 570) may be donor-CU 501 which is thus 29 05 25 operating as the source Fl donor-CU. The source Fl-donor CU 501 may identify IAB donor-CU 503 as a target Fl donor-CU. Alternatively, for an IAB node which is connected to parent lAB-node or parent IAB donor-DU of the IAB topology 5001 managed by the donor-CU 501 as the Fl terminating donor CU and which is stationary but is in proximity to or in the 5 vicinity of one or more IAB nodes in a neighbouring IAB topology, such as IAB topology 5002, the source Fl-donor CU 501 may determine that IAB donor-CU 502 is a suitable target Fl donor-CU when source Fl-donor CU 501 determines (e.g. based on signal measurements performed at the lAB-node on radio signals received at the lAB-node from all lAB-nodes in proximity to the lAB-node and which may include lAB-nodes in the neighbouring IAB 10 topology 5002) that the lAB-node may soon connect to an lAB-node in the neighbouring IAB topology 5002. Before the DU migration, a UE 602 (like UE 580 of figure 5) is for instance connected to the source Fl donor-CU 501 through the logical DU IAB-DU1 611 with the access link 621 in the cell served by the logical DU IAB-DU1 611, and the logical DU IAB-DU2 612 is 15 deactivated. At the DU migration, the logical DU IAB-DU2 612 is activated and connects to the target Fl donor-CU 502, to which the UE 602 may also connect through the logical DU IAB-DU2 612 with the link 622 in the cell served by the logical DU IAB-DU2 612. The activation of the logical DU IAB-DU2 612 may be triggered by the source Fl donor-CU and executed with the procedures described with reference to the figures 10a and 10b. Once the 20 handover of UE 602 is completed from a cell controlled by the logical DU IAB-DU1 611 to a cell controlled by the logical DU IAB-DU2 612, the logical DU IAB-DU1 611 may be deactivated. The deactivation may be triggered by the source Fl donor-CU 501 with the procedure described with reference to figure 10c, after the detection of the completion of the handover for all UEs served by the IAB-DU1 611. 25 Figure 7 is a schematic and simplified diagram 700 illustrating some example message flows, to perform the DU migration of an lAB-node, with or without (multiple) MT migration(s), and which includes the setup of data path(s) for packets routing between the target Fl donor-CU and the lAB-node through an IAB topology controlled by the non-Fl donor-CU / RRC terminating donor-CU of the lAB-node. 30 This figure 7 shows a UE 708 like the UE 580, a source Fl donor-CU 703 like the donor-CU 501, a target Fl donor-CU 707 like the donor-CU 503, a non-Fl donor-CU 709 like the donor-CU 502, the core network (5GC) 702 like the core network 110 of figure 1. This figure 7 also shows an lAB-node 701 that may be a mobile lAB-node like the lAB-node 570 composed of a MT part or unit IAB-MT 704, a DU part or unit IAB-DU1 705 (e.g. 29 05 25 source or first logical DU entity or DU), and a DU part or unit IAB-DU2 706 (e.g. target or second logical DU entity or DU). Each of the first 705 and second 706 logical DU entities serve one or more cells which are identified by identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)). The cell(s) of the IAB-DU1 705 are identified by 5 different values for the identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)) compared to the values for the identifiers for the cell(s) of the IAB-DU2 706. 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 separated 10 physical layers. The non-Fl donor-CU 709 for the lAB-node 701 may be the source Fl donor-CU 703 itself (e.g. donor-CU 501) if the IAB-MT 704 was not migrated. The non-Fl donor-CU for the lAB-node 701 may be the target Fl donor-CU 707 (e.g. donor-CU 503) if the IAB-MT 704 was previously migrated toward the target Fl donor-CU 707, or another donor-CU (e.g. donor-CU 502) if the IAB-MT 704 was previously migrated toward this other 15 donor-CU (e.g. donor-CU 502). At the beginning of the flow, the lAB-node 701 belongs to the source IAB topology controlled by the source Fl donor-CU 703. The UE 708 is served by the lAB-node 701 through a cell of IAB-DU1 705 (e.g. the DU of the lAB-node 701 has an active IAB-DU1 705 having a Fl connection with the source Fl IAB donor CU 703), while the logical IAB-20 DU2 706 is inactive. The user data in the downstream direction are provided by the 5GC 702 to the source Fl donor-CU 703 through the bearer 710, then the data are transmitted to the logical DU IAB-DU1 705 of the lAB-node 701 through the backhaul bearer 711, and finally to the UE 708 through the data radio bearer 712. The backhaul bearer 711 may be established in the source IAB topology controlled by the source Fl donor-CU 703, or in the IAB 25 topology controlled by the non-Fl donor-CU 709 of the lAB-node 701 (if the IAB-MT 704 was previously migrated toward this non-Fl donor-CU). User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. The IAB-MT 704 may send measurement reports (not represented in the figure 7) to its 30 non-Fl terminating donor-CU 709 as the result of the measurements regularly performed by IAB-MT 704 on signals received from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The non-Fl terminating donor-CU will be the Fl terminating donor-CU for the IAB node (e.g. source Fl donor-CU 703) if the MT has not been migrated from its Fl terminating 29 05 25 donor-CU. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the IAB-MT 704 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), a measurement report may be generated and transmitted to provide radio link quality information for 5 different cells in the vicinity of the lAB-node 701. The identity of each cell is included in the measurement report to allow the non-Fl donor-CU if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, to identify the target donor CU associated with the cell. Indeed, the identification of a donor-CU can be deduced from the Physical Cell identity (PCI) broadcasted in each cell managed by this donor-CU in a 10 synchronization signal, and / or from the New Radio Cell Group Identifier (NCGI) also broadcasted in each cell managed by this donor-CU in a System Information Block (SIB) message. The PCI and / or the NCGI may be reported by the lAB-node 701 in the measurement report. Based on the received measurement reports, the non-Fl donor-CU 709 if the IAB-MT 15 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, may detect that the lAB-node 701 receives radio signals in a target cell of a target parent lAB-node with a better quality than in the source serving cell. The non-Fl donor-CU 709 if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, may decide to apply a procedure to perform the IAB-MT 704 20 migration toward a target parent IAB node that belongs either to the same IAB topology (intra-CU topology adaptation), or to another IAB topology (inter-CU topology adaptation). In any case, the source Fl donor-CU 703 will be informed about this MT migration by the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated or the source Fl donor-CU 703 will be informed since it made the decision to perform MT migration directly from the 25 measurement reports received from the lAB-node 701 if the IAB-MT 704 has not been migrated, and this information may be used by the source Fl donor-CU 703 to trigger a DU migration of the lAB-node 701. In another example, the non-Fl donor-CU 709 may relay the information in the measurement reports received from the lAB-node 701 to the source Fl donor-CU 703. Thus, the source Fl donor-CU 703 may base its decision for DU migration of 30 the lAB-node 701 directly from these measurement reports relayed by the non-Fl donor-CU 709. Thus, the source Fl donor-CU 703 determines the DU of the IAB node is to be migrated from the IAB topology (also referred to as the source IAB topology) of the source Fl donor-CU 703 to another IAB topology (also referred to as the target IAB topology) of a 29 05 25 target IAB donor CU. The determination may be based on determining that a migration of a MT of the IAB node toward a new parent IAB node has been completed. Another example of a triggering event for determining the DU of the IAB node is to be migrated may include the decision for DU migration may be based on the detection of a MT migration from a one IAB 5 topology (e.g. first IAB topology) towards another IAB topology (e.g. second IAB topology), and on a known (predefined) trajectory of the lAB-node that indicates to the source Fl donor-CU that the MT will be migrated later to a yet another IAB topology (e.g. third IAB topology). In this case, to avoid signaling messages for DU migration / UEs handover toward the another IAB topology (e.g. second IAB topology), the DU is directly migrated toward the 10 yet another IAB topology (e.g. third IAB topology). Another example of a triggering event for determining the DU of the IAB node is to be migrated may include the processing load level being detected above a predefined threshold in the source Fl donor-CU. Then DU migration is triggered and the choice of target Fl donor-CU is based on the processing load of other donor-CUs connected to the source Fl donor-CU. 15 Upon the decision of or determination by the source Fl donor-CU 703 to perform the DU migration of the lAB-node 701 toward another IAB topology managed by another donor-CU which becomes the target Fl donor-CU 707, the first step 720 corresponds to sending a request to the IAB node 701 to establish a new Fl connection between the target Fl donor-CU 707 and the mobile IAB node 701. This may require activation of the second logical 20 IAB-DU2 706 in the mobile IAB node 701 and thus the first step 720 may include the activation of the second logical DU IAB-DU2 706 in the mobile IAB node 701. This operation is performed using, for example, the procedures described with reference to the figures 10a and 10b. In particular, the message sent by the source Fl donor-CU 703 to the lAB-node 701 for the activation of the IAB-DU2 706 (e.g. 1003 in figure 10a) may include 25 identification information for identifying the target donor CU, such as the TNU address (i.e. IP address) of the target Fl donor-CU 707, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may be set up with the target donor CU 707 (between the IAB-DU2 706 and the target donor CU 707). If the address of the target Fl donor-CU is not included in the request for activation, then by default and in the case where the IAB-MT 704 30 has been migrated to a non-Fl donor-CU 709, the non-Fl Donor-CU 709 is considered as the target Fl donor-CU. In this case, the lAB-node 701 has already been informed of the identity (e.g. the TNL address / IP address) of the target Fl donor-CU when the IAB-MT 704 was migrated to the non-Fl Donor-CU 709. In other words, the source Fl donor-CU 703 may send identification information for identifying the target Fl donor-CU 707 if the IAB-MT 29 05 25 704 has been migrated to a non-Fl donor-CU 709 different from (i.e. not the same as) the target Fl donor-CU 707. Alternatively, the source Fl donor-CU 703 may send identification information for identifying the non-Fl donor-CU 709 as the target IAB donor CU. After determining the DU of the IAB node 701 is to be migrated and once the IAB- 5 DU2 706 has been activated, then, the IAB-DU2 706 may send a Fl setup request message (e.g. 1013 in figure 10b) to the target Fl donor-CU 707 for requesting set up of the Fl connection between the lAB-node 701 and the target Fl donor-CU 707. This message may include identification information for identifying the source IAB donor CU, such as the TNL address (i.e. the IP address) and / or the identifier (i.e. GlobalNG-RAN Node ID as specified in 10 TS 38.423 V17.2.0 section 9.2.2.3) of the source Fl donor-CU 703 of the lAB-node 701. The destination address of the Fl setup request message is the target Fl donor-CU 707, and when this IP packet is received by the donor-DU in the Fl path for the lAB-node 701, it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 707. For instance, in an example where the lAB-node 701 is the lAB-node 570 of figure 5 which is 15 connected to lAB-node 550 via backhaul link 5050 and where the MT (MT 571 which corresponds to IAB-MT 704 in figure 7) of the lAB-node 570 has been migrated to the non-Fl donor CU 502 and the IAB donor CU 501 is the source Fl donor CU, the Fl path between the FI donor CU 501 to the lAB-node 570 uses the donor-DU 506. In the case where the IAB donor CU 503 has been identified (by Fl donor CU 501) as the target Fl donor CU (e.g. 20 target Fl donor-CU 707), the Fl setup request message for the target Fl donor-CU (for instance donor-CU 503) is sent through the lAB-nodes 550, 540 and then to the donor-DU 506 from where it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 503. In the Fl setup response (e.g. 1014 in figure 10b), the target Fl donor-CU 707 (e.g. donor-CU 503 in the example described above with reference to figure 5) may 25 request the IAB-DU2 706 to activate new cell(s) with associated identifiers (PCI, NCGI). Usually the DU activates / deactivates cell(s) under the control of the donor-CU which is controlling the DU. See, for example, TS 38.473 section 8.2.3.2. After the procedure described with reference to figure 10b, and using, for example, the procedure described with reference figure 9a, the target Fl donor-CU 707 (e.g. in the 30 configuration update message 903) may inform the source Fl donor-CU 705 about the activation of new cell(s) from the IAB-DU2 706 of the lAB-node 701. The next step 730 consists in the handover of UEs (e.g. UE 708 in figure 7) served by the IAB node 701, from the cell(s) 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 29 05 25 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 an example, to trigger the handover of the UE 708, the source Fl donor-CU 703 sends a HANDOVER REQUEST message to the target Fl donor-CU 707 including the necessary information related to the UE 708 to hand 5 over (e.g. identification information identifying the UE, UE context information, such as the security context (e.g. security parameters such as security key, UE security capabilities), measurement configuration, radio configuration (e.g. UE radio capability), information about bearers, etc.). TS 38.423, section 9.1.1.1 provides details as to the content of a HANDOVER REQUEST message. After an admission control step in which the target Fl donor-CU 707 10 determines whether the donor-CU can accept the handover of the UE 708, when the target Fl donor-CU 707 accepts the request, the target Fl donor-CU 707 sends a handover acknowledgement message to the source Fl donor-CU 705, including configuration information for the UE 708 for the handover. The configuration may include radio configuration information indicating the radio configuration to be used by the UE 708 to 15 connect to the second logical DU IAB-DU2 706 of the IAB node 701 in an identified target cell of the second logical DU IAB-DU2 706 (e.g. the radio configuration may include frequency, radio bearer configuration, etc.). The handover acknowledgement may include an identifier for each of the one or more new cells (e.g. the target cell(s)) that have been activated at the second logical DU IAB-DU2 706. Then, the source Fl donor-CU 705 sends 20 this configuration information to the UE 708 via the IAB node 701 in a RRC Reconfiguration message, including the identifier of the target cell of IAB-DU2 706 to which the UE 708 is to connect. The RRC Reconfiguration message (specified in TS 38.331) is embedded in a Fl message DL RRC MESSAGE TRANSFER (specified in TS 38.473), sent to the IAB-DU1 705 and relayed by the IAB-DU1 705 to the UE 708. Upon reception of this 25 configuration information, the UE 708 performs a random-access procedure in the indicated target cell of IAB-DU2 706 to obtain uplink resources, and then to transmit a RRC Reconfiguration Complete message to the target Fl donor-CU 707. The RRC Reconfiguration Complete message (specified in TS 38.331) is sent to the IAB-DU2 706, and then embedded in a Fl message UL RRC MESSAGE TRANSFER (specified in TS 38.473), 30 sent to the target Fl donor-CU 707. The source Fl donor-CU 705 may be informed about the completion of the UE 708 handover through the HANDOVER SUCCESS message (specified in TS 38.423) received from the target Fl donor-CU 707. Once the handover of all UEs served by the IAB-DU1 705 of the lAB-node 701 is completed, the source Fl donor-CU 703 may deactivate the logical DU IAB-DU1 705 of the 29 05 25 mobile lAB-node 701 through the procedure described with reference to figure 10c. This is represented generally by the procedure 735 in figure 7. Also, the source Fl donor-CU 705 may release the traffic (user traffic, control traffic) related to the UEs that were served by the lAB-node 701 through the IAB-DU1 705 and the 5 source Fl donor-CU 705. If the traffic was offloaded in an IAB topology controlled by the non-Fl donor-CU 709 (e.g. when the MT of the lAB-node 701 is migrated to the non-Fl donor-CU 709), the source Fl donor-CU 705 may apply the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2 to request the traffic release to the non-Fl donor-CU 709. This is represented generally by the procedure 735 in 10 figure 7. Finally, the target Fl donor-CU 707 has to setup the data path(s) to / from the migrated lAB-node 701, either in its own topology if there is a backhaul path to reach the lAB-node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e. the target Fl donor-CU 707 is a non-Fl terminating donor-CU for the lAB-node 701 as the IAB-MT 704 has 15 previously been migrated to the target Fl donor-CU 707), or through the IAB topology of the non-Fl donor-CU 709 of the lAB-node 701 if there is no backhaul path to reach the IAB-node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e. IAB-MT 704 and IAB-DU2 706 are connected to different donor-CUs). In this latter case, the target Fl donor-CU 707 may trigger the transport migration and path switch procedure 731 including 20 the request of traffic migration to the non-Fl donor-CU 709 of the lAB-node 701 (for instance through the IAB transport migration management procedure specified in TS 38.423 VI7.2.0 section 8.5.2), and the path switch procedure toward the core network 702. As an example of this latter case with reference to figure 5, the lAB-node 701 is the lAB-node 570 of figure 5 connected to lAB-node 550 via backhaul link 5050 and where the MT (MT 571 25 which corresponds to IAB-MT 704 in figure 7) of the lAB-node 570 has been migrated to the non-Fl donor CU 502 and the IAB donor CU 501 is the Fl donor CU. When the DU (DU 572 which corresponds to IAB-DU2 706 in figure 7) of the lAB-node 570 has been migrated to the target donor CU 503, and so has a Fl connection to the Fl donor CU 503, but the MT 571 remains connected through its RRC connection to the non-Fl donor-CU 502, (its RRC 30 connection), the data path(s) or backhaul path(s) to / from the lAB-node 570 is set up in the IAB topology 5002 controlled by the IAB donor CU 502 (i.e. a backhaul path to the IAB node 570 through the IAB donor DU 506, IAB nodes 540 and 550) by performing the traffic migration management procedure. Also, the target donor-CU 503 may perform a path switch procedure toward the core network 702 to request the delivery of the user data related to the 29 05 25 UE 708 / 580. For example, target donor-CU 503 may perform the path switch handshake procedure described in 3GPP TS 38.413 vl7.2.0 section 8.4.4. After the handover of UE 708 and the setup of the new data paths has been performed (731), the user data in the downstream direction are transmitted by the core network 702 to 5 the target Fl donor-CU 707 through the bearer 740, then they are transmitted to the logical DU IAB-DU2 706 of the lAB-node 701 through the backhaul bearer 741, and finally to the UE 708 through the data radio bearer 742. The backhaul bearer 741 may be established in the IAB topology controlled by the target Fl donor-CU 707, or in the IAB topology controlled by the non-Fl donor-CU 709 of the lAB-node 707 (e.g. depending on whether the IAB-MT 704 10 and IAB-DU2 706 of IAB node 701 are connected to different donor-CUs). User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction. In case the target Fl donor-CU 707 is not able to accommodate the lAB-node DU (IAB-DU2 706) and the traffic related to the served UEs like UE 708 (because of some lack 15 of processing resources, or some lack of radio / network resources), the target Fl donor-CU 707 should be allowed to reject or to revoke the DU migration (and thus the subsequent handover of UEs). The target Fl donor-CU may also be allowed to partially accept the DU migration, for instance by accepting a limited amount of traffic or a limited number of served UEs. 20 Examples of methods, in accordance with one or more embodiments of the present invention, which enable a target donor-CU to partially accept, to reject or to revoke a request for DU migration of an lAB-node will now be described. Although the following methods / apparatus’ will be described primarily with respect to a mobile IAB node, it will be appreciated that it is not intended that the invention is limited to mobile IAB nodes. The 25 methods in accordance with one or more embodiments of the present invention may apply to stationary IAB nodes e.g. that are at the edge of one IAB topology and in the proximity of or in the vicinity of one or more IAB nodes in a neighbouring IAB topology. In general terms, methods (and apparatus configured to perform such methods) for use in managing DU migration of a DU of an IAB node, from a source IAB topology managed by 30 a source IAB donor CU to a target IAB topology managed by a target IAB donor CU in accordance with one or more embodiments of the invention comprise receiving, at the target IAB donor CU, a message indicating a DU migration of the DU of the IAB node from the source IAB donor CU to the target IAB donor CU is requested. The message sent to the target IAB donor CU may be sent by the source IAB donor CU (e.g. the migration request 811,913 29 05 25 as discussed below with reference to figures 8 and 9b) or the message may be sent by the IAB node (e.g. the Fl setup request 814, 1013 as discussed below with reference to figures 8 and 10b). The message is sent following a determination that the IAB node is to be migrated to the target IAB donor CU. For example, the source IAB donor CU may determine that there is 5 a need (e.g. a triggering event for the migration has occurred) to migrate the DU of the IAB node to another IAB donor CU and may then decide to which IAB donor CU the DU migration shall be performed. Examples of reasons and triggering events for determining the DU of the IAB node is to be migrated have been discussed above with respect to figure 7. The message sent to the target IAB donor CU may include context information relating to the 10 context of the DU migration to help the target IAB donor CU decide whether to accept or reject the request for DU migration of the IAB node or in some cases to partially accept the DU migration of the IAB node. In response to the received message (or after receiving the message), the target IAB donor CU determines whether to (fully) accept or partially accept or reject the DU migration 15 of the IAB node. The decision may be based for example on whether the target IAB donor CU is able to accommodate the IAB node (e.g. all of the traffic associated with the IAB node) and the traffic related to all of the UEs served by the IAB node (e.g. based on the available resources at the target IAB donor CU, such as processing resources, and / or radio / network resources). The target IAB donor CU sends a response indicating the target IAB donor has 20 determined to accept or partially accept or reject the DU migration of the IAB node. As an optimization, the target IAB donor-CU may partially accept the DU migration by accepting a subset or some of the traffic related to the UEs served by the IAB node (e.g. by accepting at least one of one or more traffic profiles associated with the IAB node), and / or by accepting a subset or some of the UEs served by the IAB node (e.g. by accepting at least one of the UEs 25 served by the IAB node). The decision to partially accept may be based on the comparison of the available resources, such as the processing resources and / or network resources at the target IAB donor (and at the controlled IAB topology (i.e. the topology controlled by the target IAB donor), with the resources, such as the processing / network resources, required by the traffic profile(s) to be migrated, and / or on the comparison of the number of additional 30 UEs that can be connected to the target IAB donor-CU with the number of UEs served by the lAB-node. If the available processing / radio resources are not sufficient to accommodate the whole traffic (e.g. including all of the traffic associated with the traffic profile(s) to be migrated) and / or all the served UEs, the target IAB donor-CU may select a subset or some of the traffic profile(s) and / or a limited number or a subset or some of the served UEs to 29 05 25 support. The criterion for selection may be related to QoS parameters indicating some priority among traffic profiles / UEs, and the target IAB donor-CU may select to accept the traffic profiles / UEs with the highest priority. For a served UE, a criterion may be the onboard status of the UE with respect to the lAB-node: i.e. whether the UE is physically inside a moving 5 vehicle equipped with the lAB-node or otherwise surrounding and moving with the IAB-node. Indeed, if the handover of an onboard UE toward the target IAB donor-CU for DU migration is rejected, then this UE will have to be handed over to another cell (controlled by another CU) and it will lose the benefit of the mobile cell served by the IAB node. An advantage to partially accept a DU migration is to give the source donor-CU a possibility to 10 maintain some UEs with highest priority connected to the mobile cell of the IAB node, especially when there is no alternative choice for a target IAB donor-CU other than the target IAB donor-CU. In response to or after determining to reject (or partially accept) the DU migration, the target IAB donor CU sends a response (e.g. a message) indicating the target IAB donor CU 15 has rejected (or partially accepted) the request for DU migration to the target IAB donor CU. The message sent by the target IAB donor CU may be sent to the source IAB donor CU (e.g. the migration response 812, 914 as discussed below with reference to figures 8 and 9b or a configuration update message 903 sent based on Fl setup as discussed below with reference to figure 9a) or the message may be sent to the IAB node (e.g. the Fl setup response 815, 20 1014 as discussed below with reference to figures 8 and 10b). In the case the DU migration is rejected or revoked by the target IAB donor CU, the migration process is not executed (e.g. the source IAB donor CU does not send an DU activation request 813) or if it has already been initiated, execution of the migration process is cancelled. In case of partial acceptance, the response may include the identification of the part of the traffic that is accepted (e.g. the 25 index(es) of the accepted traffic profile(s) that have been accepted), and / or the number of UEs that are accepted. In response to or after determining to (fully or partially) accept the DU migration, the target IAB donor CU sends a message indicating the target IAB donor CU has (fully or partially) accepted the DU migration and in response, the source IAB donor CU may initiate 30 the migration process which is then executed or continues to perform the migration process (e.g. the steps of the migration process described above with reference to figure 7 are performed). In case of partial acceptance, the source IAB donor CU may not execute the migration process, and in such a case, the source IAB donor CU may send a new request later or select another target IAB donor-CU. The message sent by the target IAB donor CU may be 29 05 25 sent to the source IAB donor CU (e.g. the migration response 812, 914 as discussed below with reference to figures 8 and 9b or a configuration update message 903 sent based on Fl setup as discussed below with reference to figure 9a) or the message may be sent to the IAB node (e.g. the Fl setup response 815, 1014 as discussed below with reference to figures 8 and 5 10b). After determining to (fully or partially) accept the DU migration, the target IAB donor CU may determine to revoke the DU migration of the IAB node to the target IAB donor CU and may send a revocation response indicating the target IAB donor CU has determined to revoke the DU migration of the IAB node to the target IAB donor CU. For example, in case 10 that after acceptance or partial acceptance of the request of the DU migration, and during the execution of the process for DU migration together with the served UEs or even after the DU migration process has been completed or terminated, the target IAB donor CU detects that it is no longer able to accommodate the migrated IAB node and the served UEs, then the target IAB donor CU can revoke the DU migration. The revocation response indicating the target 15 IAB donor CU has determined to revoke the DU migration may be sent to the source IAB donor CU. For example, the procedure described with reference to the figure 9b may be used to signal the revocation to the source IAB donor CU. The revocation response indicating the target IAB donor CU has determined to revoke the DU migration may be sent to the IAB node. For example, the target IAB donor-CU may also take the opportunity of the Fl setup 20 procedure described with reference to the figure 10b to revoke the DU migration previously accepted. At reception of the message indicating the revocation, the DU migration process is stopped. If some UEs were already handed over to the target IAB donor CU, these UEs are handed back to the source IAB donor-CU. If the second logical DU of the lAB-node was already activated, it is removed by the target IAB donor CU using the procedure described 25 with reference to figure 10c. The message sent by the target IAB donor CU to reject or to revoke a DU migration includes a cause information for indicating the cause of the rejection or revocation of the request for DU migration to the target donor CU. The message sent by the target IAB donor CU to partially accept a DU migration may include a cause information for indicating the 30 cause of the partial acceptance of the request for DU migration to the target donor CU (e.g. overload). It may also include an identification of the part of the traffic that is accepted (e.g. the index(es) of the accepted traffic profile(s)) and / or the number of UEs that are accepted. 29 05 25 After partial acceptance, rejection or revocation, the source IAB donor-CU may decide to postpone the DU migration and to make a new attempt later, or it may decide to select another target donor-CU. Thus, the method / apparatus in accordance with one or more embodiments of the 5 present invention enables the target IAB donor CU to reject or to revoke the DU migration (and thus, the subsequent handover of UEs served by the IAB node) in the case the target IAB donor CU is not able to accommodate a part of the traffic or the whole traffic related to the served UEs (because of some lack of processing resources, or some lack of radio / network resources). In case of partial acceptance, the source IAB donor CU performs the handover 10 toward the target IAB donor CU (for the DU migration) for the UEs for which the traffic has been accepted and / or for a number of UEs accepted by the target IAB donor CU. The other UEs are handed over toward a different CU (which may be any base station, not only an IAB donor CU). Figure 8 is a simplified diagram illustrating example message flows, according to one 15 or more embodiments of the invention, to allow a target Fl terminating donor-CU to accept, partially accept, or reject the DU migration of an lAB-node. For example, the message flows shown in figure 8 enable a target IAB donor CU (e.g. target Fl terminating donor CU) to determine whether to (fully or partially) accept or reject DU migration of an lAB-node to the target IAB donor CU and in response to or after determining to fully or partially accept or to 20 reject the DU migration, to inform the source IAB donor CU (e.g. source Fl terminating donor-CU) that the target IAB donor CU has fully or partially accepted or rejected the request for DU migration. This figure 8 shows a source Fl donor-CU 803 like the donor-CU 501, a target Fl donor-CU 807 like the donor-CU 503, and an lAB-node 801 that may be a mobile lAB-node 25 like the lAB-node 570 composed of a MT part or unit IAB-MT 804, a DU part or unit IAB-DU1 805 (e.g. source or first logical DU entity or DU), and a DU part or unit IAB-DU2 806 (e.g. target or second logical DU entity or DU). Each of the first 805 and second 806 logical DU entities serve one or more cells. IAB-DU1 805 and IAB-DU2 806 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, 30 they share the same physical layer (i.e. the same hardware resources), while in another example they rely on separated physical layers. At the beginning of the flow, the lAB-node 801 belongs to the source IAB topology controlled by the source Fl donor-CU 803. According to one embodiment of the invention, upon the decision of or determination by the source Fl donor-CU 803 to perform the DU 29 05 25 migration of the lAB-node 801 toward the IAB topology managed by the target Fl donor-CU 807, the first step corresponds to sending a request for requesting DU migration of the DU of the lAB-node 801 from the source Fl donor-CU 803 to the target Fl donor-CU 807. The request may be sent as a DU migration request message 811 by the source Fl donor-CU 803 5 to the target Fl donor-CU 807. The message 811 is used to inform the target Fl donor-CU 807 that it has been selected by the source Fl donor-CU 803 to be the new Fl terminating donor-CU for the lAB-node 801. The message 811 may be followed by a response, such as the DU migration response message 812, sent by the target Fl donor-CU 807 to the source Fl donor-CU 803 either to (fully or partially) accept the DU migration or to reject the DU 10 migration. The decision to (fully or partially) accept or to reject may be based on the current load of processing resources of the target Fl donor-CU 807, or on the current load of network resources (wired backhaul and / or wireless backhaul) in the IAB topology managed by the target Fl donor-CU 807. To assist the decision by the target Fl donor-CU 807, the request, such as the DU migration request message 811, may include context information relating to 15 or associated with the context of the DU migration to the target Fl donor-CU 807. The context information may include part or all of the following information that may be referred to as the context of the DU migration: identification information for identifying the IAB node. The identification information may include the identifier of lAB-node 801 as known by the source Fl 20 donor-CU 803, either with the information element F1 -Terminating 1AB-donor UE XnAP ID identifying the MT 804 of the lAB-node 801, or with the information element gNB-DUID identifying the first logical DU IAB-DU1 805 of the lAB-node 801. The identification information may, additionally or alternatively, include the identifier of the lAB-node 801 as known by the IAB donor CU serving the MT 804 25 of the IAB node 801, if the MT 804 has been migrated to a non-Fl donor-CU (or RRC terminating donor-CU) and if this non-Fl donor-CU is different from the target Fl donor-CU 807, with the information element non-F 1-Terminating IAB-donor UE XnAP ID identifying the MT 804 of the lAB-node 801, identification information for identifying the IAB donor CU serving the MT 804 of 30 the IAB node 801, if the MT 804 has been migrated to a non-Fl donor-CU and if this non-Fl donor-CU is different from the target Fl donor-CU 807, with for instance the TNL address (i.e. the IP address) and / or the identifier (i.e. Global NG-RANNode ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801, 29 05 25 an indication related to the priority to consider for the DU migration request. For example, priority information for indicating a level of priority for the request for DU migration. It may be a value within a predefined range (e.g. from 1 to 5), where a low value indicates that the DU migration is not critical for the source Fl donor- 5 CU 803, while a high value indicates of the DU migration is critical for the source Fl donor-CU 803, for instance because of some load issue associated to the processing or radio / network resources in the source Fl donor-CU’s IAB topology, an indication related to the profile of the user traffic associated to the lAB-node 801 (e.g. traffic profile information for indicating a profile of user traffic associated with 10 the IAB node), including QoS (Quality of Service) parameters, as defined in TS 38.423 V17.2.0 section 9.2.2.81. Each traffic profile may be identified by a traffic index, an indication related to the throughput of the user traffic associated to the lAB-node 801 (e.g. traffic throughput information for indicating the throughput of user traffic 15 associated with the IAB node), both in upstream (from the lAB-node) and downstream direction (to the lAB-node), - the number of UEs, like UE 580, served by the lAB-node 801 that would be handed over to the target Fl donor-CU 807 together with the DU migration of the IAB-node 801. In addition, the number of onboard UEs may be indicated (i.e. UEs 20 physically inside the vehicle equipped with the lAB-node or otherwise surrounding and moving with the lAB-node). F1 -Terminating lAB-donor UEXnAP ID and non-F1 -Terminating lAB-donor UEXnAP ID correspond to a NG-RAN node UE XnAP ID as specified in TS 38.423 section 9.2.3.16. In case of partial acceptance or rejection of the DU migration request, the target Fl 25 donor-CU 807 may include the cause of the partial acceptance or rejection in the DU migration response message 812. The cause may be, for instance, a lack of processing resources, or a lack of radio / network resources. Each possible cause may be associated to a predefined value, as for instance specified in TS 38.423 V17.2.0 section 9.2.3.2. In case of partial acceptance, the response may include the index of the traffic profiles that are accepted, 30 and / or the number of UEs that are accepted. The messages 811 and 812 may correspond to the procedure described with reference to figure 9b where message 811 corresponds to message 913 and message 812 corresponds to message 914 at the figure 9b. They are exchanged between the source Fl donor-CU 803 and the target Fl donor-CU 807 before the migration process or procedure describe with 29 05 25 reference to figure 7 is executed, which is only executed if the target Fl donor-CU 807 has (fully or partially) accepted the DU migration request. As another example of method to allow a target Fl terminating donor-CU to partial accept or to reject the DU migration of an lAB-node, the source Fl donor-CU 803 may 5 trigger the procedure described with the reference 720 at the figure 7. Upon the decision of or determination by the source Fl donor-CU 803 to perform the DU migration of the lAB-node 801 toward the IAB topology managed by the target Fl donor-CU 807, the first step corresponds to sending a request for establishing a Fl connection between the target Fl donor-CU 807 and the mobile lAB-node 801 for informing the target Fl donor-CU 807 the 10 Fl connection to be established relates to a request for DU migration of the lAB-node 801 to the target Fl donor-CU 807. The request may be sent as a DU activation request message 813 to the IAB node 801, to establish a new Fl connection between the target Fl donor-CU 807 and the mobile IAB node 801, through the second logical DU IAB-DU2 804. The activation of the second logical IAB-DU2 806 in the mobile IAB node 801 is performed with the 15 operation 810. The message 813 sent by the source Fl donor-CU 803 to the lAB-node 801 for the activation of the IAB-DU2 806 is sent to the first logical DU IAB-DU1 805 as the source Fl donor-CU 803 has a Fl connection with this first logical DU of the lAB-node 801. The DU activation request message 813 may be a configuration request message 1003 as shown in figure 10a. This message 813 includes a request for establishing a Fl connection 20 and for informing the target donor CU 807 of the identity of the IAB donor CU serving the MT 804 of the IAB node 801. The request may indicate (explicitly or implicitly) to the IAB node 801 that the IAB node is to inform the target Fl donor CU 807 the Fl connection to be established relates to a request for DU migration of the lAB-node 801 to the target Fl donor-CU 807 and may also inform the target Fl donor CU 807 of the context of the DU migration 25 as described above. For example, the DU activation request message 813 may include the context information as described above with respect to message 811 and the message 813 may indicate (explicitly or implicitly) that the IAB node 801 is to provide at least some of the context information in the received DU activation request message 813 to the target Fl donor CU 807. 30 After activation of the second logical DU IAB-DU2 806, the information contained in the message 813 may be transmitted from the first logical DU IAB-DU1 805 to the second logical DU IAB-DU2 806. In particular, the message 813 may include identification information for identifying the target Fl donor CU 807, such as the TNL address (i.e. IP address) of the target Fl donor- 29 05 25 CU 807, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may be set up with the target donor CU 807 (between the IAB-DU2 806 and the target donor CU 807). This message 813 may also include a request to inform the identified target Fl donor-CU 807 of the context of the DU migration as described above. For example, Once activated, the IAB-DU2 806 may send a Fl setup request message 814 to the target Fl donor-CU 807 for requesting the setup of the Fl connection between the lAB-node 801 and the target Fl donor-CU 807 and for indicating the Fl connection to be established relates to a request for DU migration of the IAB node 801 to the target Fl donor-CU 807. This message 814, also described with the reference 1013 at the figure 10b, may include the information that the Fl setup request is related to the DU migration of the lAB-node 801. Thus, the message 814 may include identification information for identifying the source Fl donor-CU 803, such as the TNL address (i.e. the IP address) and / or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the source Fl donor-CU 803 of the lAB-node 801. This message 814 may also include information related to the context of the DU migration as described above. For example, message 814 may include the context information described above with reference to message 811. Finally, the message 814 may include the identifier gNB-DUID of the second logical DU IAB-DU2 806 of the IAB-node 801. As specified in TS 38.473 section 9.3.1.19, the. gNB-DUID uniquely identifies the gNB-DU at least within a gNB-CU. Thus, a logical DU of an lAB-node is assigned a unique ID by configuration. The unique ID may be provided to the Fl IAB donor-CU terminating the Fl connection with the logical DU at Fl setup procedure (described in the figure 10b). In the Fl setup response 815 (and also described with the reference 1014 in figure 10b), the target Fl donor-CU 807 may accept or reject the Fl setup request. As the Fl setup request is related to the DU migration of an lAB-node, the Fl setup request may be accepted by the target Fl donor-CU 807 if the DU migration of the lAB-node is partially or fully accepted, and the Fl setup request may be rejected by the target Fl donor-CU 807 if the DU migration of the lAB-node is not accepted or rejected. The decision by the target Fl donor-CU 807 may be based on the information related to the context of the DU migration (if context information is included in the message 814). In case of (full or partial) acceptance, the target Fl donor-CU 807 may request the IAB-DU2 806 to activate new cell(s) with associated identifiers (PCI, NCGI). Usually the DU activates / deactivates cell(s) under the control of the donor-CU which is controlling the DU. See, for example, TS 38.473 section 8.2.3.2. In case of rejection or partial acceptance, the target Fl donor-CU 807 may indicate (e.g. via cause information included in the message 815) the cause of the rejection / partial acceptance as described above 29 05 25 with respect to the message 812. In case of partial acceptance, the response may identify the part of the traffic that is accepted (e.g. the index(es) of the accepted traffic profile(s)), and / or the number of UEs that are accepted. After reception of the Fl setup response message 815, the IAB-DU2 806 may inform 5 the IAB-DU1 805 about the result of the activation procedure (i.e. activation of IAB-DU2 806 and activation of new cell(s)). Then, the IAB-DU1 805 may relay this information to the source Fl donor-CU 803 through a response, such as the message DU activation response 816, which indicates whether the target Fl donor-CU 807 has accepted or rejected the request for establishing a Fl connection between the target Fl donor-CU 807 and the 10 lAB-node 801 and hence has (partially or fully) accepted or rejected the request for DU migration of the lAB-node 801. In case of successful activation (i.e. in case of the target Fl donor-CU 807 has (partially or fully) accepted the DU migration of the lAB-node 801), this message 816 may include the gNB-DUID of the second logical DU IAB-DU2 806 of the lAB-node 801. In case of partial acceptance, the message 816 may indicate the cause of this 15 partial acceptance. The message 816 is further described with the reference 1004 in figure 10a. In the case when the target Fl donor-CU 807 has rejected the request for DU migration of the lAB-node 801, the response 816 indicates the target IAB donor CU has rejected the request for establishing a Fl connection between the target Fl donor-CU 807 and the IAB-node 801 and hence has rejected the request for DU migration of the lAB-node 801. The 20 response 816 may include cause information for indicating the cause of the rejection of the request for DU migration to the target donor CU as described above with respect to the message 812. As a variant of the method above, when the target Fl donor-CU 807 has rejected or revoked the DU migration of the lAB-node 801 and thus rejected the Fl setup request 814, 25 the lAB-node 801 may not send the message 816 or may send the message 816 without the cause of unsuccessful DU activation. In this case, it will be the target Fl donor-CU 807 that will directly inform the source Fl donor-CU 803 with, for instance, the procedure described at the figure 9a. For example, in such a case, the target Fl donor-CU 807 may send a response (such as message 903 described with reference to figure 9a) to the source Fl donor-30 CU 803, which response indicates the target Fl donor-CU 807 has rejected / revoked the request for DU migration of the lAB-node 801 to the target Fl donor-CU 807. Such a response may also include cause information for indicating the cause of the rejection / revocation of the request for DU migration to the target donor CU as described above with respect to the message 812. 29 05 25 Figure 9a is a schematic and simplified diagram 900 illustrating an example message flow of a procedure in accordance with embodiments of the present invention, used by a RAN Node CU to report configuration information to another RAN Node CU according to an example. 5 This figure shows two RAN nodes, RAN node CUa 901 and RAN node CUb 902, that may be two lAB-Donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5. With respect to the example shown in figure 8, RAN node CUa 901 may be the target Fl donor-CU 807 and RAN node CUb 902 may be the source Fl donor-CU 803. RAN node may be lAB-node 801. 10 In particular, the message 903 may be sent by the RAN node CUa 901 to report the status of a Fl setup procedure related to the DU migration of a RAN node, for which the RAN node CUb 902 is the Fl terminating donor-CU that has previously triggered the Fl setup procedure following the decision to migrate the RAN node DU to the RAN node CUa 901. The RAN node DU may the DU of an lAB-node like the lAB-node 801. 15 In case of successful Fl setup operation, meaning that the RAN node CUa 901 has (fully or partially) accepted the DU migration of the RAN node, the message CONFIGURATION UPDATE 903 may be sent by the RAN node CUa 901 to the RAN node CUb 902 to inform the RAN node CUb 902 about the activation of new cell(s) in a logical DU of a RAN node DU like the IAB-DU2 806 of the lAB-node 801. 20 For example, the source Fl donor-CU 803 receives the CONFIGURATION UPDATE message 903 from the target Fl donor-CU 807 and the CONFIGURATION UPDATE message 903 includes identification information (e.g. PCI, NRGI) identifying one or more new cells that have been activated at a second logical DU entity (IAB-DU2 806) of the DU of the IAB node 801. 25 The messages 903 may also include at least one of - the identifier of the migrated RAN node as known by the RAN node CUa 901, either with the information element F1-Terminating I AB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node, or with the information element gNB-DUID identifying the logical DU of the migrated RAN 30 node having Fl connection with the RAN node CUa 901, the identifier of the MT of the migrated RAN node as known by the RAN node CU terminating the RRC connection with the migrated RAN node, through the information element non-F 1-Terminating lAB-donor UE XnAP ID, 29 05 25 - the identifier gNB-DUID of a logical DU of the migrated RAN node having a F1 connection with the RAN node CUb 902, - the cause information related to the cause of the partial acceptance in case of partial acceptance of the DU migration, 5 - the index of the traffic profiles that are accepted, and / or the number of UEs that are accepted in case of partial acceptance. In case of unsuccessful Fl setup operation, meaning that the RAN node CUa 901 has rejected or revoked the DU migration of the RAN node, the message CONFIGURATION UPDATE 903 may be sent by the RAN node CUa 901 to the RAN node CUb 902 to inform 10 the RAN node CUb 902 about the rejection / revocation of the DU migration of the RAN node. In that case, the message 903 may include an information element (e.g. cause information) indicating the cause of the rejection / revocation, as described with reference to the message 812 in the figure 8. The RAN node CUb 902 may answer with the message CONFIGURATION 15 ACKNOWLEDGE 904 sent to the RAN node CUa 901. According to one example, the Figure 9a corresponds to the procedure NG-RAN node configuration update described in TS 38.423 V17.2.0 section 8.4.2, and the message 903 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 9.1.3.4, amended with IEs listed above, while the message 904 20 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.5. Figure 9b is a simplified diagram 910 illustrating an example message flow, according to one or more embodiments of the invention, of a procedure used by a RAN node CU to manage the DU migration of a RAN node in coordination with another RAN node CU, 25 including the signaling to partially accept, to reject or to revoke the DU migration. This figure shows two RAN nodes, RAN node CUa 911 and RAN node CUb 912, that may be two lAB-Donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5. The message MIGRATION REQUEST 913 is sent by the RAN node CUa 911 to the RAN node CUb 912 to request the DU migration of a RAN node that may be an lAB-node 30 like the lAB-node 801. For example, with reference to figure 8, the source Fl donor-CU 803 may send a MIGRATION REQUEST 913 to the target Fl donor CU 807 to request the DU migration of the lAB-node 801. In other words, MIGRATION REQUEST 913 may correspond to message 811 described above with reference to figure 8. 29 05 25 The message 913 may also include context information relating to or associated with the context of the DU migration to the target Fl donor-CU 807. The context information may include a part or all of the following information that may be referred to the context of the DU migration: 5 - identification information for identifying the RAN node. The identification information may include the identifier of the RAN node as known by the RAN node CUa 911, either with the information element Fl-Terminating lAB-donor UE XnAP ID identifying the MT of the RAN node, or with the information element gNB-DUID identifying a first logical DU of the RAN node. The identification 10 information may, additionally or alternatively, include the identifier of the RAN node as known by the RAN node CU serving the MT of the RAN node, if the MT has been migrated to a non-Fl RAN node CU and if this non-Fl donor-CU is different from the RAN node CUb 912, with the information element non-Fl-Terminating lAB-donor UE XnAP ID identifying the MT of the RAN node, 15 - identification information for identifying the RAN node CU serving the MT of the RAN node, if the MT has been migrated to a non-Fl RAN node CU and if this non-Fl RAN node CU is different from the RAN node CUb 912, with for instance the TNL address (i.e. the IP address) and / or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl RAN node CU 20 of the RAN node, an indication related to the priority to consider for the DU migration request. For example, priority information for indicating a level of priority for the request for DU migration. It may be a value within a predefined range (e.g. from 1 to 5), where a low value indicates that the DU migration is not critical for the RAN node CUa 25 911, while a high value indicates of the DU migration is critical for the RAN node CUa 911, for instance because of some load issue associated to the processing or radio / network resources in the IAB topology controlled by the RAN node CUa 911, an indication related to the profile of the user traffic associated to the RAN node (e.g. traffic profile information for indicating a profile of user traffic associated with 30 the RAN node), including QoS (Quality of Service) parameters, as defined in TS 38.423 V17.2.0 section 9.2.2.81. Each traffic profile may be identified by a traffic index, an indication related to the throughput of the user traffic associated to the RAN node (e.g. traffic throughput information for indicating the throughput of user traffic 29 05 25 associated with the RAN node), both in upstream (from the RAN node) and downstream direction (to the RAN node), - the number of UEs that would be handed over to the RAN node CUb 912 together with the migration of the RAN node DU. In addition, the number of onboard UEs 5 may be indicated (i.e. UEs physically inside the vehicle equipped with the IAB- node or otherwise surrounding and moving with the lAB-node). F1 -Terminating lAB-donor UEXnAP ID and non-F1 -Terminating lAB-donor UEXnAP ID correspond to a NG-RAN node UE XnAP ID as specified in TS 38.423 section 9.2.3.16. The RAN node CUb 912 answers with the message MIGRATION RESPONSE 914 10 sent to the RAN node CUa 911 to (fully or partially) accept or to reject the request. The procedure described with the figure 9b may be used by the RAN node CUb 912 to revoke a DU migration previously accepted. For this purpose, the RAN node CUb 912 sends another message MIGRATION RESPONSE 914 to indicate the revocation to the RAN node CUa 911. 15 In case of partial acceptance, rejection or revocation, the message 914 may include an information element (e.g. cause information) indicating the cause of the partial acceptance, rejection or revocation, as described with reference to the message 812 in the figure 8. In case of partial acceptance, the response may include the index of the traffic profiles that are accepted, and / or the number of UEs that are accepted. 20 The figure 9b may correspond to the handover preparation procedure specified TS 38.423 V17.2.0 section 8.2.1, and amended with the information elements and the behaviour described above. The message 913 may correspond to the HANDOVER REQUEST message specified in TS 38.423 V17.2.0 section 9.1.1.1. In case of (full or partial) acceptation of the DU migration, the message 914 may correspond to the HANDOVER REQUEST 25 ACKNOWLEDGE message specified in TS 38.423 V17.2.0 section 9.1.1.2, while in case of rejection or revocation of the DU migration, the message 914 may correspond to the HANDOVER PREPARATION FAILURE message specified in TS 38.423 V17.2.0 section 9.1.1.3. Figure 10a is a simplified diagram 1000 illustrating an example message flow, 30 according to one or more embodiments of the invention, of a procedure to perform the activation of a logical DU in a RAN node, including the signaling to partially accept, reject or revoke by a RAN node CU the DU migration of the RAN node. This figure shows: 29 05 25 - a RAN node DU 1001 of a RAN node, that may be DU of an lAB-node like IAB-DU 572 of IAB node 570 of figure 5 (and IAB-DU1 805 of IAB node 801 of figure 8), - a RAN node CU 1002, that may be an lAB-Donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8). 5 The message CONFIGURATION REQUEST 1003 is sent by the RAN node CU 1002 to the RAN node DU 1001 either to request the activation of new cell(s) controlled by the RAN node DU 1001, or to request the activation of a logical DU, or to request the deactivation of cell(s) in the RAN node DU 1001. In case of a logical DU activation, the message 1003 may include the TNL address (i.e. IP address) of a target RAN node CU (e.g. 10 the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated. For example, CONFIGURATION REQUEST 1003 may be sent by the source IAB donor CU to the IAB node (e.g. the first logical DU entity 805 having a Fl connection with the source IAB donor CU) for requesting establishment of a Fl connection between a target IAB donor CU and the IAB node (e.g. CONFIGURATION REQUEST 1003 may correspond to request 15 813 described above with reference to figure 8, which is a request for establishing a Fl connection between a target IAB donor CU and the IAB node for informing the target IAB donor CU the Fl connection to be established relates to a request for DU migration of the IAB node to the target IAB donor CU). The message 1003 may also include an information element (IE) indicating that the request is related to the DU migration of the RAN node. This 20 IE may be limited to one bit: one value (i.e. “0” or “1”) of this one-bit IE means no specific action is requested and another value (i.e. “1” or “0”) means sending the context of the DU migration to the target RAN node CU (e.g. the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated. This IE may be extended to include context information which may include a part or all of the following information that may be referred 25 to as the context of the DU migration: identification information for identifying the RAN node. The identification information may include the identifier of the RAN node as known by the RAN node CUa 1002, either with the information element F1 -Terminating 1AB-donor UE XnAP ID identifying the MT of the RAN node, or with the information element 30 gNB-DUID identifying the RAN node DU 1001. The identification information may include, additionally or alternatively, the identifier of the RAN node as known by the RAN node CU serving the MT of the RAN node, if the MT has been migrated to a non-Fl (or RRC) RAN node CU and if this non-Fl donor-CU (or RRC terminating donor-CU) is different from the RAN node CUb 1002, with the 29 05 25 information element non-F1 -Terminating 1AB-donor UE XnAP ID identifying the MT of the RAN node, identification information for identifying the RAN node CU serving the MT of the RAN node, if the MT has been migrated to a non-F 1 RAN node CU and if this non- 5 Fl RAN node CU is different from the RAN node CUb 1002, with for instance the TNL address (i.e. the IP address) and / or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl RAN node CU of the RAN node, an indication related to the priority to consider for the DU migration request. For 10 example, priority information for indicating a level of priority for the request for DU migration. It may be a value within a predefined range (e.g. from 1 to 5), where a low value indicates that the DU migration is not critical for the RAN node CUa 1002, while a high value indicates of the DU migration is critical for the RAN node CUa 1002, for instance because of some load issue associated to the processing or 15 radio / network resources in the IAB topology controlled by the RAN node CUa 1002, an indication related to the profile of the user traffic associated to the RAN node (e.g. traffic profile information for indicating a profile of user traffic associated with the RAN node), including QoS (Quality of Service) parameters, as defined in TS 20 38.423 V17.2.0 section 9.2.2.81. Each traffic profile may be identified by a traffic index, an indication related to the throughput of the user traffic associated to the RAN node (e.g. traffic throughput information for indicating the throughput of user traffic associated with the RAN node), both in upstream (from the RAN node) and 25 downstream direction (to the RAN node), - the number of UEs that would be handed over to the RAN node CUb 1002 together with the RAN node. In addition, the number of onboard UEs may be indicated (i.e. UEs inside the vehicle equipped with the lAB-node or otherwise surrounding and moving with the lAB-node). 30 The RAN Node DU 1001 may acknowledge the request with the message CONFIGURATION RESPONSE 1004 sent to the RAN Node CU 1002. The message 1004 may be used to report to the RAN node CU 1002 the status of the Fl connection with the target F1 RAN node CU. 29 05 25 In case of successful Fl setup for the DU migration of the RAN node, it means that the target Fl RAN node CU has (fully or partially) accepted the DU migration. Then, the message 1004 may include an Information Element (IE) (e.g. second DU gNB-DU ID), to identify the activated logical DU in the RAN node. In case of partial acceptance of DU 5 migration, the message 1004 may include the cause of the partial acceptance. In case of unsuccessful Fl setup for the DU migration of the RAN node, it means that the target Fl RAN node CU has rejected or revoked the DU migration. In this latter case, the message 1004 may include the cause (e.g. cause information) of the rejection or revocation as described with reference to the message 812 in the figure 8. 10 According to one example, the flow in figure 10a corresponds to the procedure gNB-CU Configuration Update procedure described in TS 38.473 V17.0.0 section 8.2.5, and amended with the information elements and the behavior described above. The message 1003 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, while the message 1004 corresponds to the message GNB-CU 15 CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11. Figure 10b is a simplified diagram illustrating an example message flow, according to one or more embodiments of the invention, of a procedure to setup a logical DU in a RAN node, including the signaling to partially accept, reject or revoke a DU migration of the RAN 20 node by a RAN node CU. This figure shows: - a RAN node DU 1011 of a RAN node, that may be a DU of an lAB-node DU like IAB-DU 572 of IAB node 570 of figure 5 (and IAB-DU2 806 of IAB node 801 of figure 8), - a RAN node CU 1012, that may be an lAB-Donor-CU like lAB-donor-CU 503 of 25 figure 5 (and target Fl donor-CU 807 of figure 8). The message SETUP REQUEST 1013 is sent by the RAN node DU 1011 to the RAN node CU 1012 to request the Fl setup for the logical DU. For example, SETUP REQUEST 1013 may be sent by the IAB node (e.g. by the second logical DU entity 806 which has been activated at the IAB node 801) to the target IAB donor CU 807 for requesting set up of a Fl 30 connection between a target IAB donor CU and the IAB node (e.g. with the second logical DU entity 806 of the IAB node 801). SETUP REQUEST 1013 may correspond to request 814 described above with reference to figure 8, which is a Fl setup request for requesting the setup of the Fl connection and for indicating the Fl connection to be established relates to a request for DU migration of the IAB node 801 to the target IAB donor CU. The SETUP 29 05 25 REQUEST message 1013 may be sent after an activation request as described with reference to figure 10a. This SETUP REQUEST message 1013 may include the number of cells to be activated along with activation of the logical DU. This SETUP REQUEST message 1013 may include the indication that it is related to the DU migration of the RAN node and it may 5 include all or part of the context of the DU migration (e.g. context information) as described with reference to the message 1003 of the figure 10a. The message 1013 may also include the TNL address (i.e. the IP address) and / or the identifier (i.e. GlobalNG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the source RAN node CU that has requested the F1 setup, 10 The RAN node CU 1012 answers with the message SETUP RESPONSE 1014 sent to the RAN node DU 1011. SETUP RESPONSE 1014 may correspond to response 815 described above with reference to figure 8, which is a Fl setup response for indicating the target IAB donor CU has accepted or rejected the Fl setup request relating to the request for DU migration to the target IAB donor CU. The RAN node CU 1012 may accept or reject the 15 Fl setup request. If the Fl setup request is related to the DU migration of an lAB-node, the Fl setup request may be accepted by the RAN node CU 1012 if the DU migration of the lAB-node is (fully or partially) accepted, or the Fl setup request may be rejected by the RAN node CU 1012 if the DU migration of the lAB-node is rejected or the Fl setup request may be revoked by the RAN node CU 1012 if the DU migration of the lAB-node has been 20 previously accepted and then revoked. The decision by the RAN node CU 1012 may be based on the information related to the context of the DU migration (if context information is included in the message 1013). In case of (full or partial) acceptance, the RAN node CU 1012 may include a list of cell(s) to activate with the logical DU, along with the associated PCI and NCGI value(s) to be used. In case of partial acceptance, rejection or revocation, the RAN 25 node CU 1012 may indicate (e.g. via cause information included in the message 1014) the cause of the partial acceptance, rejection or revocation as described above with respect to the message 812. In case of partial acceptance, the response may include the identification of the part of the traffic that is accepted (e.g. the index(es) of the accepted traffic profile(s)), and / or the number of UEs that are accepted. 30 According to one example, the flow in figure 10b corresponds to the procedure Fl setup described in TS 38.473 V17.2.0 section 8.2.3, amended with the information elements and the behavior described above. The message 1013 may correspond to the message Fl SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4. The message 1014 may correspond to the message Fl SETUP RESPONSE described in TS 38.473 V17.2.0 section 29 05 25 9.2.1.5, if the RAN node CU 1012 has accepted the request (e.g. when the RAN node CU 1012 has (fully or partially) accepted the DU migration of the RAN node), while the message 1014 may correspond to the message Fl SETUP FAILURE described in TS 38.473 V17.2.0 section 9.2.1.6, if the RAN node CU 1012 has rejected the request (e.g. when the RAN node 5 CU 1012 has rejected the DU migration of the RAN node). Figure 10c is a simplified diagram 1020 illustrating an example message flow of a procedure to remove a logical DU. This figure shows: - a RAN node DU 1021 of a RAN node, that may be a DU of an lAB-node DU like 10 IAB-DU 572 of IAB node 570 of figure 5 (and IAB-DU1 805 of IAB node 801 of figure 8), - a RAN node CU 1022, that may be an lAB-Donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8). The message REMOVAL REQUEST 1023 is sent by the RAN node CU 1022 to the RAN node DU 1021 to request the removal (which is equivalent to deactivation) of the 15 logical DU. The RAN node DU 1021 answers with the message REMOVAL RESPONSE 1014 sent to the RAN node CU 1022. According to one example, the flow in Figure 10c corresponds to the procedure Fl removal described in TS 38.473 V17.2.0 section 8.2.8, and the message 1023 corresponds to 20 the message Fl REMOVAL REQUEST described in TS 38.473 V17.2.0 section 9.2.1.16, while the message 1024 corresponds to the message Fl REMOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7. Figure 1 la is a flowchart of an example method 1100 in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- 25 node, the DU migration of the lAB-node. For example, method 1100 in accordance with embodiments of the present invention is performed at the source IAB donor CU and is for use in managing, or as part of, a migration process / procedure for migrating a DU of an IAB node from the source IAB donor CU to a target IAB donor CU. For example, with reference to the IAB communication system 500 shown in and 30 described with respect to figure 5, the source IAB donor CU performing the method 1100 may be the IAB donor CU 501 (e.g a Fl terminating donor CU or Fl donor-CU of the IAB node 570 with which the IAB node 570 retains a Fl connection). The IAB node may be the mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the IAB donor CU 501. The migration process may involve the 29 05 25 migration of the DU 572 of the IAB node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by IAB donor CU 503 which is the target IAB donor CU. With reference to figures 7 and 8, the IAB node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 5 801 from the source Fl terminating donor-CU 703, 803 to the target Fl terminating donor- CU 707, 807. The method 1100 as shown in and described with respect to figure Ila may be performed by software elements and / or hardware elements. The source IAB donor CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure Ila being 10 performed by an apparatus for the source IAB donor CU including one or more processing units, such as the central processing unit 411. At step 1101, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), determines that the DU of the IAB node, like the lAB-node 570 of figure 5 (701, 801) is to be migrated from the source Fl donor-CU 501, 703, 803 to a target Fl terminating 15 donor-CU, like the donor-CU 503 of figure 5 (707, 807). For example, the source Fl terminating donor-CU 501, 703, 803 decides the DU migration of an lAB-node, like the IAB-node 570, toward a target Fl donor-CU, like the donor-CU 503, 707, 807. For example, the source Fl donor-CU 501, 703, 803 may determine that the DU 572 of the IAB node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the 20 IAB node 570, 701, 801 toward a new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl terminating donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above. 25 At step 1102, the source Fl terminating donor-CU 501, 703, 803 sends to the target Fl terminating donor-CU 503, 707, 807 a request for DU migration of the IAB node (e.g. a request for requesting DU migration of the DU of the IAB node 570, 701, 801 from the source Fl terminating donor-CU 501, 703, 803 to the target Fl terminating donor-CU 503, 707, 807). The message sent at step 1102 may be a migration request message such as the 30 message 811 in figure 8. At step 1103, the source Fl terminating donor-CU 501, 703, 803 receives from the target Fl donor-CU 503, 707, 807 a response indicating if the target Fl terminating donor-CU 503, 707 (fully or partially) accepts or rejects the DU migration of the IAB node. The message received at step 1103 may be a migration response message such as the message 812 29 05 25 in figure 8. As discussed above, the response received at step 1103 may include CU cause information for indicating the cause of the partial acceptance or rejection of the request for DU migration to the target donor CU. In case of partial acceptance, the response may include the identification of the part of the traffic that is accepted (e.g. the index(es) of the accepted 5 traffic profile(s)), and / or the number of UEs that are accepted. When the target Fl terminating donor-CU 503, 707, 807 determines to partially accept or to reject the DU migration of the IAB node 570, 701, 801, the response indicates the target Fl terminating donor-CU 503, 707, 807 has partially accepted or rejected the request for DU migration. After receiving (or in response to receiving) a rejection response, the migration 10 process is not executed or execution of the migration process is terminated (e.g. the source IAB donor CU does not send a DU activation request 813). After rejection or partial acceptance, the source IAB donor-CU may decide to postpone the DU migration and to make a new attempt later, or it may decide to select another target donor-CU. In the case the DU migration is (fully or partially) accepted by the target Fl donor-CU 15 503, 707, 807, the response received at the source Fl terminating donor-CU 501, 703, 803 indicates the target Fl donor-CU 503, 707, 807 has (fully or partially) accepted the DU migration and in response, the source Fl terminating donor-CU 501, 703, 803 may initiate the migration process which is then executed (e.g. the steps described above with reference to figure 7 are performed). 20 Figure 1 lb is a flowchart of an example method 1110 in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an IAB-node, the DU migration of the lAB-node. For example, method 1110 in accordance with embodiments of the present invention is performed at the target IAB donor CU and is for use in managing, or as part of, a migration process / procedure for migrating a DU of an IAB node 25 from a source IAB donor CU to the target IAB donor CU. For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the target IAB donor CU performing the method 1110 may be the IAB donor CU 503 which controls IAB topology 5003. The IAB node may be the mobile lAB-node 570 belonging to IAB topology 5001 controlled by the IAB donor CU 501. 30 The migration process may involve the migration of the DU 572 of the IAB node 570 from IAB topology 5001 to IAB topology 5003. With reference to figures 7 and 8, the IAB node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl terminating donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 1110 as shown in and described with respect to figure 1 lb 29 05 25 may be performed by software elements and / or hardware elements. The target IAB donor CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 1 lb being performed by an apparatus for the target IAB donor CU including one or more 5 processing units, such as the central processing unit 411. At step 1111, the target Fl terminating donor-CU, like the donor-CU 503 of figure 5 (707, 807), receives a request for requesting DU migration of the DU of the IAB node 570, 701, 801 from the source Fl terminating donor CU to the target Fl terminating donor CU. The request may be sent as a DU migration request from the source Fl terminating donor 10 CU, such as IAB donor CU 501 of figure 5 (703, 803) to request the DU migration of the IAB node 570, 701, 801 in the IAB topology controlled by the target Fl terminating donor-CU 503, 707, 807. The message received at step 1111 may be the message 811 in figure 8. At step 1112, the target Fl terminating donor-CU 503, 707, 807 determines if it (fully) accepts or partially accepts or rejects the DU migration of the lAB-node 570, 701, 801. The 15 decision may be based on the current load of processing resources of the target Fl terminating donor-CU 503, 707, 807, or on the current load of network resources (wired backhaul and / or wireless backhaul) in the IAB topology managed by the target Fl terminating donor-CU 503, 707, 807. To assist the decision by the target Fl terminating donor-CU 503, 707, 807 may use the information related to the context of the DU migration 20 included in the message received at step 1111 (e.g. context information as described above with respect to message 811). At step 1113, the target Fl terminating donor-CU 503, 707, 807 sends to the source Fl donor-CU 501, 703, 803 a response indicating if the target Fl terminating donor-CU 503, 707 (fully or partially) accepts or rejects the DU migration of the IAB node 570, 701, 801. The 25 message sent at step 1113 may be the message 812 in figure 8. After the target Fl terminating donor-CU 503, 707, 807 determines to partially accept or to reject the DU migration of the IAB node 570, 701, 801, the response indicates the target Fl terminating donor-CU 503, 707, 807 has partially accepted or rejected the request for DU migration. As discussed above, although not shown in figures Ila and 1 lb, after determining to 30 (fully or partially) accept the request for DU migration, the target Fl donor-CU 503, 707, 807 may determine to revoke DU migration of the IAB node to the target Fl donor-CU 503, 707, 807 (e.g. when the target Fl donor-CU 503, 707, 807 cannot support the DU migration (and any served UEs). In this case, the target Fl donor-CU 503, 707, 807 sends a revocation response (e.g. a message such as message 914), to the source Fl donor-CU 501, 703, 803 29 05 25 indicating the target Fl donor-CU 503, 707, 807 has determined to revoke the DU migration of the IAB node to the target Fl donor-CU 503, 707, 807. Figure 12a is a flowchart of another example method 1200 in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU 5 of an lAB-node, the DU migration of the lAB-node. For example, method 1200 in accordance with embodiments of the present invention is performed at the source IAB donor CU and is for use in managing, or as part, of a migration process / procedure for migrating a DU of an IAB node from the source IAB donor CU to a target IAB donor CU. For example, with reference to the IAB communication system shown 500 in and 10 described with respect to figure 5, the source IAB donor CU performing the method 1200 may be the IAB donor CU 501 (e.g a Fl terminating donor CU or Fl donor-CU of the IAB node 570 with which the IAB node 570 retains a Fl connection). The IAB node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the IAB donor CU 501. The migration process may involve the 15 migration of the DU 572 of the IAB node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by IAB donor CU 503 which is the target IAB donor CU. With reference to figures 7 and 8, the IAB node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl terminating donor-CU 703, 803 to the target Fl terminating donor- 20 CU 707, 807. The method 1200 as shown in and described with respect to figure 12a may be performed by software elements and / or hardware elements. The source IAB donor CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 12a being performed by an apparatus for the source IAB donor CU including one or more processing 25 units, such as the central processing unit 411. At step 1201, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), determines that the DU of the IAB node, like the lAB-node 570 of figure 5 (701, 801) is to be migrated from the source Fl terminating donor-CU 501, 703, 803 to a target Fl terminating donor-CU, like the donor-CU 503 of figure 5 (707, 807). For example, the source 30 Fl terminating donor-CU 501, 703, 803 decides the DU migration of an lAB-node, like the lAB-node 570, 701, 801, toward a target Fl terminating donor-CU, like the donor-CU 503, 707, 807. For example, the source Fl terminating donor-CU 501, 703, 803 may determine that the DU of the IAB node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the IAB node 570, 701, 801 toward a new parent IAB 29 05 25 node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above. 5 At step 1202, the source Fl terminating donor-CU 501, 703, 803 sends to the lAB-node 570, 701, 801 a request for establishing a Fl connection (i.e. a new Fl connection) between the target IAB donor CU 503, 707, 807 and the lAB-node 570, 701, 801 (e.g. a new Fl association with the target IAB donor CU) and for informing the target IAB donor CU that the Fl connection is related to a DU migration of the lAB-node 570, 701, 801. The request 10 from the source Fl terminating donor-CU 501, 703, 803 may indicate (explicitly via an IE or implicitly) to the lAB-node 570, 701, 801 that the IAB node is to inform the target IAB donor CU 503, 707, 807 that the Fl connection is related to the DU migration of the lAB-node 570, 701, 801. The request may also inform the target IAB donor CU 503, 707, 807 of the context of the DU migration as described above. For example, the request may include the context 15 information as described above with respect to message 811. The request may indicate (explicitly via an IE or implicitly) that the lAB-node 570, 701, 801 is to transmit the context of the DU migration (which may also be included in the request) to the target IAB donor CU 503, 707, 807. The message sent at step 1202 may be the message 813 in figure 8. Not represented in the figure 12a, the source Fl terminating donor-CU 501, 703, 803 20 may have executed the procedure described with the figure 9b before the step 1202, and it may have received the acceptance of the DU migration by the target IAB donor CU 503, 707, 807 (e.g. in a migration response 914). At step 1203, the source Fl terminating donor-CU 501, 703, 803 receives a response indicating whether the target IAB donor CU 503, 707, 807 has (fully) accepted or partially 25 accepted or rejected (or revoked if the target IAB donor CU 503, 707, 807 has previously accepted the DU migration of the lAB-node 570, 701, 801) the request for DU migration to the target IAB donor CU 503, 707, 807. The response may be a DU activation response from the lAB-node 570, 701, 801. The message received at step 1203 may be the message 816 shown in and described with respect to figure 8. 30 In the case when the target IAB donor CU 503, 707, 807 has rejected or revoked the request for DU migration of the lAB-node 570, 701, 801, the response 816 indicates the target IAB donor CU has rejected the request for establishing a Fl connection between the target IAB donor CU 503, 707, 807 and the lAB-node 570, 701, 801 and hence has rejected or revoked the request for DU migration of the lAB-node 570, 701, 801. The response 816 29 05 25 may include cause information for indicating the cause of the rejection of the request for DU migration to the target donor CU as described above with respect to the message 812. In case of partial acceptance of the DU migration (with acceptance of the Fl setup request), the response 816 may include the cause of partial acceptance. 5 In another example (not shown in figure 12a), when the target IAB donor CU 503, 707, 807 has rejected or revoked the DU migration of the lAB-node 570, 701, 801 and thus rejected setting up a Fl connection between the target IAB donor CU 503, 707, 807 and the lAB-node 570, 701, 801, the source Fl terminating donor-CU 501, 703, 803 may receive a response indicating the target IAB donor CU 503, 707, 807 has rejected or revoked the 10 request for DU migration to the target IAB donor CU 503, 707, 807 from the target Fl donor-CU 807 with, for instance, the procedure described at the figure 9a. Such a response may also include cause information for indicating the cause of the rejection or revocation of the request for DU migration to the target donor CU as described above. In case of partial acceptance of the DU migration (with acceptance of the Fl setup request), the target Fl donor-CU 807 may 15 inform the source Fl donor-CU 803 about the cause of partial acceptance. After receiving (or in response to receiving) a rejection / revocation response, the migration process is not executed or execution of the migration process is terminated (e.g. the source IAB donor CU does not send a DU activation request 813). After rejection / revocation, the source IAB donor-CU may decide to postpone the DU migration and to make a new 20 attempt later, or it may decide to select another target donor-CU. Figure 12b is a flowchart of an example method 1210 in accordance with embodiments of the present invention, for managing, at an lAB-node its DU migration to a target Fl terminating donor-CU. For example, method 1210 in accordance with embodiments of the present invention is performed at the IAB node and is for use in, or as part of, managing a 25 migration process / procedure for migrating a DU of an IAB node from a source IAB donor CU to a target IAB donor CU. For example, with reference to the IAB communication system shown 500 in and described with respect to figure 5, the IAB node performing the method 1210 may be the mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB 30 topology) controlled by the IAB donor CU 501 (e.g. a Fl terminating donor CU of the mobile IAB node 570 with which the mobile IAB node 570 retains a Fl connection) which is the source IAB donor CU. The migration process may involve the migration of the DU 572 of the IAB node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by IAB donor CU 503 which is the target IAB donor CU. With 29 05 25 reference to figures 7 and 8, the IAB node may be mobile lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl terminating donor-CU 703, 803 to the target Fl terminating donor-CU 707, 807. The method 1210 as shown in and described with respect to figure 12b may be performed by 5 software elements and / or hardware elements. The IAB node may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 12b being performed by an apparatus for the IAB node including one or more processing units, such as the central processing unit 411. 10 At step 1211, an lAB-node, like the lAB-node 570 of figure 5 (701, 801), receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), a request for establishing a Fl connection or a new Fl connection (for example, a Fl connection between the lAB-node 570, 701, 801 and a target Fl donor CU, like the donor-CU 503 of figure 5 (707, 807)) and for informing the target IAB donor CU that the Fl connection is 15 related to the DU migration of the lAB-node 570, 701, 801. The request from the source Fl terminating donor-CU 501, 703, 803 may indicate (explicitly or implicitly) to the lAB-node 570, 701, 801 that the IAB node is to inform the target IAB donor CU 503, 707, 807 that the Fl connection is related to the DU migration of the lAB-node 570, 701, 801. The request may also inform the target Fl donor CU 807 of the context of the DU migration as described 20 above. For example, the request may include the context information as described above with respect to message 811. The request may indicate (explicitly or implicitly) that the lAB-node 570, 701, 801 is to provide or transmit the context of the DU migration (which may also be included in the request) to the target IAB donor CU 503, 707, 807. The message received at step 1211 may be the message 813 in figure 8. 25 At step 1212, in response to (or after) receiving a request for a new Fl connection, the IAB node 570, 701, 801 then sends, to the target Fl terminating donor CU 503, 707, 807, a Fl setup request requesting the setup of the Fl connection and indicating the Fl connection to be established relates to a request for DU migration of the IAB node 570, 701, 801 to the target Fl terminating donor CU 503, 707, 807. For example, the Fl setup request message 30 sent by the IAB node 570, 701, 801 may include an indication that the Fl connection to establish is related to the DU migration of the IAB node 570, 701, 801. It may also include part of or all the context of the DU migration (such as all or part of the context information described above). The message sent at the step 1212 may be the message 814 in figure 8. 29 05 25 At step 1213, the IAB node 570, 701, 801 receives, from the target Fl terminating donor CU 503, 707, 807, a Fl setup response message. This message indicates whether the target Fl terminating donor CU 503, 707, 807 accepts or rejects the Fl setup request. The decision to accept or to reject the Fl setup request may be linked to the decision to (fully or 5 partially) accept or to reject (or to revoke if the target IAB donor CU 503, 707, 807 has previously accepted DU migration of the IAB node 570, 701, 801) the DU migration of the IAB node 570, 701, 801. The message received at the step 1213 may be the message 815 in figure 8. In case of rejection or revocation, the Fl setup response indicates the target Fl terminating donor CU 503, 707, 807 has rejected the Fl setup request relating to the request 10 for DU migration to the target Fl terminating donor CU 503, 707, 807. In this case, the Fl setup response may also indicate (e.g. via cause information included in the message 815) the cause of the rejection or revocation of the DU migration as described above with respect to the message 812. In case of partial acceptance of DU migration (with acceptance of the Fl setup request), the Fl setup response may indicate the cause of partial acceptance of the DU 15 migration. At step 1214, the lAB-node 570, 701, 801 sends to the source Fl terminating donor-CU 501, 703, 803 a DU activation response. This message indicates the status of the Fl connection establishment with the target Fl terminating donor CU 503, 707, 807. It may 20 relay the decision by the target Fl terminating donor CU 503, 707, 807 to (fully or partially) accept or to reject or to revoke the DU migration of the lAB-node 570, 701, 801. The message sent at step 1214 may be the message 816 shown in and described with respect to figure 8. In the case when the target IAB donor CU 503, 707, 807 has rejected or revoked the 25 request for DU migration of the lAB-node 570, 701, 801, the response 816 indicates the target IAB donor CU has rejected the request for establishing a Fl connection between the target IAB donor CU 503, 707, 807 and the lAB-node 570, 701, 801 and hence has rejected or revoked the request for DU migration of the lAB-node 570, 701, 801. The response 816 may include cause information for indicating the cause of the rejection or revocation of the 30 request for DU migration to the target donor CU as described above with respect to the message 812. In case of partial acceptance of DU migration (with acceptance of the Fl setup request), the response 816 may indicate the cause of partial acceptance of the DU migration. Figure 12c is a flowchart of another example method 1220 in accordance with embodiments of the present invention, for managing, at a target Fl terminating donor-CU of 29 05 25 an lAB-node, the DU migration of the lAB-node. For example, method 1220 in accordance with embodiments of the present invention is performed at the target IAB donor CU and is for use in managing, or as part of, a migration process / procedure for migrating a DU of an IAB node from a source IAB donor CU to the target IAB donor CU. 5 For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the target IAB donor CU performing the method 1220 may be the IAB donor CU 503 which controls IAB topology 5003. The IAB node may be the mobile lAB-node 570 belonging to IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve the migration of the DU 572 of the IAB node 570 from 10 IAB topology 5001 to IAB topology 5003. With reference to figures 7 and 8, the IAB node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl terminating donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 1220 as shown in and described with respect to figure 12c may be performed by software elements and / or hardware elements. The target IAB donor CU 15 may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 12c being performed by an apparatus for the target IAB donor CU including one or more processing units, such as the central processing unit 411. At step 1221, the target Fl terminating donor-CU, like the donor-CU 503 of figure 5 20 (707, 807), receives, from the IAB node 570, 701, 801, a Fl setup request requesting the setup of the Fl connection and indicating the Fl connection to be established relates to a request for DU migration of the IAB node 570, 701, 801 to the target Fl terminating donor CU 503, 707, 807. For example, the Fl setup request message sent by the IAB node 570, 701, 801 may include an indication that the Fl connection to establish is related to the DU 25 migration of the IAB node IAB node 570, 701, 801. It may also include part of or all the context of the DU migration (such as all or part of the context information described above). The message received at the step 1221 may be the message 814 in figure 8. At step 1222, the target Fl terminating donor-CU 503, 707, 807 determines if it (fully) accepts or partially accepts or rejects (or revokes if it has previously accepted the DU 30 migration of the lAB-node 570, 701, 801) the DU migration of the lAB-node 570, 701, 801, and thus the Fl setup request. The decision may be based on the current load of processing resources of the target Fl terminating donor-CU 503, 707, 807, or on the current load of network resources (wired backhaul and / or wireless backhaul) in the IAB topology managed by the target Fl terminating donor-CU 503, 707, 807. To assist the decision by the target Fl 29 05 25 terminating donor-CU 503, 707, 807 may use the information related to the context of the DU migration included in the message received at step 1221. After determining whether to (fully or partially) accept or reject / revoke DU migration, the target Fl terminating donor-CU 503, 707, 807 sends a response indicating whether the 5 target IAB donor CU 503, 707, 807 has (fully or partially) accepted or rejected / revoked the request for DU migration to the target IAB donor CU 503, 707, 807. For example, at step 1223, the target Fl terminating donor-CU 503, 707, 807 sends to the lAB-node 570, 701, 801 a response indicating if the target Fl terminating donor-CU 503, 707 (fully or partially) accepts or rejects or revokes the DU migration of the lAB-node 570, 701, 801, and thus 10 accepts or rejects the Fl setup request of the IAB node 570, 701, 801. The message sent at step 1223 may be the message 815 in figure 8. In an alternative example (not shown in figure 12c), the target Fl terminating donor-CU 503, 707, 807 sends a response to the source Fl terminating donor-CU 501, 703, 803 (e.g. with the procedure described at the figure 9a) indicating whether the target IAB donor 15 CU 503, 707, 807 has (fully or partially) accepted or rejected or revoked the request for DU migration to the target IAB donor CU 503, 707, 807. Such a response may also include cause information for indicating the cause of the partial acceptance / rejection / revocation of the request for DU migration to the target donor CU as described above. In case of rejection or revocation, the response, whether a Fl setup response sent to the 20 lAB-node 570, 701, 801 or a response sent to the source Fl terminating donor-CU 501, 703, 803, indicates the target Fl terminating donor CU 503, 707, 807 has rejected the Fl setup request relating to the request for DU migration to the target Fl terminating donor CU 503, 707, 807. In this case, the response may also indicate (e.g. via cause information) the cause of the rejection or revocation of the DU migration as described above. 25 Thus, the method / apparatus in accordance with one or more embodiments of the present invention enables the target IAB donor CU to partially accept, reject or revoke the DU migration (and thus, the subsequent handover of UEs served by the IAB node) in the case the target IAB donor CU is not able to accommodate the IAB node DU and the traffic related to the served UEs (because of some lack of processing resources, or some lack of 30 radio / network resources) and to inform the source IAB donor CU so that appropriate action can be taken. With the target IAB donor CU sending a response to the source IAB donor CU to indicate the DU migration has been (fully or partially) accepted or rejected, triggering activation of a second logical DU in the IAB node when DU migration is rejected can be avoided. With the target IAB donor CU sending a response to the IAB node to indicate the 29 05 25 DU migration has been (fully or partially) accepted or rejected, the Fl setup procedure will have already been completed which saves setup time when DU migration is accepted. In other words and as a summary, about acceptance / rej ection of DU migration, it can be observed that when the DU of a mobile lAB-node is migrated from a source Fl donor-CU 5 toward a target Fl donor-CU, the UEs served by the mobile lAB-node shall also be handed over toward this target Fl donor-CU. Upon reception of a handover request for a UE served by the mobile lAB-node, the target Fl donor-CU may reject the handover. If this happens, the cause of handover preparation failure should not be related to the radio network layer as the traffic associated to the UE is handled by the non-Fl donor-CU (or RRC terminating donor- 10 CU) serving the co-located mobile IAB-MT. However, the cause may be a control processing overload as a CU can handle a limited number of connected UEs. In case only a few donor-CUs support mobile IAB, those donor-CUs would handle many mobile lAB-nodes and thus many UEs. A situation where most handovers of UEs served by a mobile lAB-node are rejected by 15 the target Fl donor-CU should be avoided, as these UEs, and especially the onboard UEs, will have to be handed over to another cell and they will lose the benefit of the mobile cell. Thus, it may be useful to get the status at the target Fl donor-CU before initiating the first UE handover. For this purpose, the Fl setup request in the scope of a DU migration may include an 20 information related to the number of UEs served by the mobile lAB-node. This information would help the target donor-CU for the decision to accept or to reject the Fl setup request (due to control processing overload). In case of rejection, another target donor-CU may be selected, or a new attempt may be performed later. Then, it is proposed that in the scope of DU migration of a mobile lAB-node, the Fl 25 setup request sent to the target Fl donor-CU may include the number of connected UEs served by the mobile lAB-node. Besides, the target Fl donor-CU may be allowed to partially accept the DU migration. For instance, the target Fl donor-CU may partially accept the DU migration in the Fl setup response by indicating the number of UEs it can accommodate. 30 Then, it is proposed that the target Fl donor-CU may accept the DU migration of a mobile lAB-node with some conditions, e.g. with a maximum number of UEs that can be served. While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples 29 05 25 and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process 5 so disclosed, may be combined in any combination, except combinations 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 drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic 10 series of equivalent or similar features. In the 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 dependent claims does not indicate that a combination of these features cannot be advantageously used. 15 In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which 20 corresponds to a tangible medium such as data storage media, or communication media including any medium 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 generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media 25 may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media can 30 comprise 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 desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed 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, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, 5 that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations 10 of the above should also be included within the scope of computer-readable media. 29 05 25

Claims

29 05 251. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node, from a source Fl terminating IAB donor Central5 Unit, CU, to a target Fl terminating IAB donor CU, the method at the target Fl terminating IAB donor CU comprising:receiving, from the IAB node, a Fl setup request message for requesting setup of a Fl connection between the target Fl terminating IAB donor CU and the IAB node in a case where the DU of the IAB node is to be migrated to the target Fl terminating IAB donor CU;10 sending a Fl setup response message indicating the target Fl terminating IAB donorCU has accepted Fl setup or sending a Fl setup failure message indicating the target Fl terminating IAB donor CU has rejected Fl setup.

2. The method of claim 1, wherein sending includes sending, to the IAB node, the Fl15 setup response message or the Fl setup failure message.

3. The method of claim 1 or claim 2, wherein sending comprises: sending the Fl setup failure message indicating the target Fl terminating IAB donor CU has rejected the Fl setup for DU migration to the target Fl terminating IAB donor CU.

204. The method of any one of claims 1 to 3, wherein in a case where the Fl setup failure message is sent, the Fl setup failure message includes cause information for indicating the cause of the rejection of the Fl setup.25 5. The method of claim 1 or claim 2, wherein sending comprises: sending the Fl setupresponse message indicating the target Fl terminating IAB donor CU has accepted the Fl setup for DU migration to the target Fl terminating IAB donor CU.

6. The method of any one of the preceding claims, wherein the Fl setup request message 30 includes at least one of:information for identifying a RRC terminating IAB donor CU serving a Mobile Termination, MT, of the IAB node, the RRC terminating IAB donor CU terminating the RRC connection of the IAB node and being a different IAB donor CU to the target Fl terminating IAB donor CU;29 05 25information for identifying a Mobile Termination, MT, of the IAB node in the case where a RRC terminating IAB donor CU terminating the RRC connection of the IAB node is a different IAB donor CU to the target F1 terminating IAB donor CU.5 7. The method of any one of claims 1 to 6, wherein in a case where a first condition issatisfied, the Fl setup response message indicating the target Fl terminating IAB donor CU has accepted the Fl setup is transmitted from the target Fl terminating IAB donor CU, and in a case where a second condition different from the first condition is satisfied, the Fl setup failure message indicating the target Fl terminating IAB donor CU has rejected the Fl setup10 is transmitted from the target Fl terminating IAB donor CU.

8. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source Fl terminating IAB donor Central Unit, CU, to a target Fl terminating IAB donor CU, the method at the source Fl terminating15 IAB donor CU comprising:in a case where the DU of the IAB node is to be migrated to the target Fl terminating IAB donor CU, sending, to the IAB node, a request for establishing a Fl connection between the target F1 terminating IAB donor CU and the IAB node;receiving a response indicating the target Fl terminating IAB donor CU has accepted20 Fl connection establishment between the target Fl terminating IAB donor CU and the IAB node or rejected Fl connection establishment between the target Fl terminating IAB donor CU and the IAB node.

9. The method of claim 8, wherein receiving a response comprises: receiving, from the25 IAB node, a response indicating the target Fl terminating IAB donor CU has accepted or rejected Fl connection establishment between the target Fl terminating IAB donor CU and the IAB node.

10. The method of claim 8 or claim 9, wherein receiving comprises: receiving a response30 indicating the target Fl terminating IAB donor CU has rejected Fl connection establishment for DU migration to the target Fl terminating IAB donor CU.

11. The method of claim 10, further comprising: after receiving a response indicating the target Fl terminating IAB donor CU has rejected Fl connection establishment, terminating29 05 25execution of the migration process for migrating the DU of the IAB node to the target Fl terminating IAB donor CU.

12. The method of claim 8 or claim 9, wherein receiving comprises: receiving a response 5 indicating the target Fl terminating IAB donor CU has accepted Fl connection establishment for DU migration to the target Fl terminating IAB donor CU.

13. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source Fl terminating IAB donor Central10 Unit, CU, to a target Fl terminating IAB donor CU, the method at the IAB node comprising: receiving, from the source Fl terminating IAB donor CU, a request for establishing a Fl connection between the target Fl terminating IAB donor CU and the IAB node for DU migration of the IAB node to the target Fl terminating IAB donor CU;sending, to the target Fl terminating IAB donor CU, a Fl setup request message for15 requesting setup of the Fl connection;receiving a Fl setup response message indicating the target Fl terminating IAB donor CU has accepted the Fl setup or receiving a Fl setup failure message indicating the target Fl terminating IAB donor CU has rejected the Fl setup.20 14. The method of claim 13, further comprising: sending, to the source Fl terminating IABdonor CU, a response indicating the target Fl terminating IAB donor CU has accepted Fl connection establishment between the target Fl terminating IAB donor CU and the IAB node or rejected Fl connection establishment between the target Fl terminating IAB donor CU and the IAB node.2515. The method of claim 13 or claim 14, wherein receiving a Fl setup failure message comprises: receiving a Fl setup failure message indicating the target Fl terminating IAB donor CU has rejected the Fl setup for DU migration to the target Fl terminating IAB donor CU.3016. The method of any one of claims 13 to 15, wherein the Fl setup failure message includes cause information for indicating the cause of the rejection of the Fl setup.29 05 2517. The method of claim 13 or claim 14, wherein receiving a Fl setup response message comprises: receiving a Fl setup response message indicating the target Fl terminating IAB donor CU has accepted the Fl setup for DU migration to the target Fl terminating IAB donor CU.

518. The method of any one of claims 13 to 17, wherein the request for establishing a Fl connection includes context information relating to the context of DU migration to the target F1 terminating IAB donor CU.10 19. The method of claim 18, wherein the request indicates the IAB node is to provide atleast some of the context information to the target Fl terminating IAB donor CU.

20. The method of any one of claims 1 to 19, wherein the Fl setup request message includes context information relating to the context of DU migration to the target Fl15 terminating IAB donor CU.

21. The method of claim 18 or claim 19 or claim 20, wherein the context information includes at least one of:identification information for identifying the IAB node;20 identification information for identifying a RRC terminating IAB donor CU servingthe Mobile Termination, MT, of the IAB node;priority information for indicating a level of priority for the request for DU migration; traffic profile information for indicating a profile of user traffic associated with the IAB node;25 traffic throughput information for indicating the throughput of user traffic associatedwith the IAB node;User Equipment, UE, information for indicating a number of UEs served by the IAB node;onboard UE information for indicating a number of onboard UEs served by the IAB 30 node.

22. The method of claim 18 or claim 19 or claim 20, wherein the context information includes: information known by a RRC terminating IAB donor CU serving the MT of the IAB node for identifying the IAB node.29 05 2523. The method of any one of claims 13 to 18, wherein the Fl setup request message includes at least one of:information for identifying a RRC terminating IAB donor CU serving a Mobile5 Termination, MT, of the IAB node, the RRC terminating IAB donor CU terminating the RRC connection of the IAB node and being a different IAB donor CU to the target Fl terminating IAB donor CU;information for identifying a Mobile Termination, MT, of the IAB node in the case where a RRC terminating IAB donor CU terminating the RRC connection of the IAB node is 10 a different IAB donor CU to the target Fl terminating IAB donor CU.

24. The method of any one of claims 1 to 23, wherein the IAB node is a mobile lAB-node mounted on a vehicle.15 25. An apparatus for an Integrated Access Backhaul, IAB, donor Central Unit, CU, node ofan IAB communication system, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 1 to 12 or claim 24.20 26. An apparatus for an Integrated Access Backhaul, IAB, node of an IAB communicationsystem, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 13 to 24.25 27. A computer program comprising instructions which, when the program is executed by acomputer, cause the computer to carry out the method according to any one of claims 1 to 24.

28. A computer-readable medium carrying a computer program according to claim 27.

Images