GB2624000A

GB2624000A - Migration of nodes in an IAB communication system

Info

Publication number: GB2624000A
Application number: GB2216391.9A
Authority: GB
Inventors: Visa Pierre; Lagrange Pascal
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2022-11-03
Filing date: 2022-11-03
Publication date: 2024-05-08
Also published as: GB2624064A; GB202216391D0; GB202311148D0

Abstract

Methods and apparatus for use in a migration process in which a Distributed Unit (DU) of an Integrated Access Backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor Central Unit (CU) to another IAB topology managed by a target IAB donor CU. The source donor CU facilitates the migration by instigating F1 connection between the IAB node and the target IAB donor CU. A method at the source IAB donor CU comprises determining the DU of the IAB node is to be migrated and sending, to the IAB node, a request for establishing a F1 connection between the IAB node and the target IAB donor CU. A method at the IAB node comprises receiving, from the source IAB donor CU, a request for establishing a F1 connection between a target IAB donor CU and the IAB node, and sending, to the target IAB donor CU, a setup request for the F1 connection. A method at the target IAB donor CU comprises receiving, from the IAB node, a request for establishing a F1 connection, and sending a response including a request for cells to be activated for a second logical DU entity of the IAB node.

Description

MIGRATION OF NODES IN AN IAB COMMUNICATION SYSTEM

Field of the Invention

The present invention generally relates to methods for use in a process for migrating nodes and traffic between Integrated Access and Backhaul, IAB, topologies of a wireless communication system involving mobile JAB nodes. Particularly, the present invention relates to a method for use in a migration process in which a Distributed Unit, DU, of an JAB node, for example a mobile IAB node, is migrated between IAB topologies.

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 (HE) or mobile terminals to share the wireless medium to exchange several types of data 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 -RTIVI) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (SG) 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 network densification, 3GPP has proposed, from release 16 for 5G NR, 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 resources as access communications (between a base station and TJEs).

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 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 JAB framework, where multiple data paths are set up between the JAB base station 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 JAB-node" for the UEs). Several intermediate TAB base stations (also referred to as JAB-nodes) may be involved in each of the several paths between the IAB-donor and the access IAB-node, thus forming alternative data paths within a multi-hop JAB topology.

Besides, 3GPP has been considering inter-donor redundancy, where an JAB-node, referred to as a boundary IAB node, can access two different parent nodes connected to two different IAB-donors, with each of the IAB-donors managing a different IAB topology (also referred to as JAB network). The boundary JAB-node, even though belonging to a single JAB topology, i.e. belonging to a single JAB-donor for configuration and management, is thus able to route packets from a first JAB topology managed by a first JAB-donor to a second JAB 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 JAB topology, thus mitigating congestion issues or overcoming radio link failure issues that may arise in the first IAB topology.

There are other situations where an IAB-node becomes a boundary node. For example, in the case of partial migration of an JAB-node, decided by the JAB-donor, where the Mobile Termination (MT) of the JAB-node becomes connected to a single parent JAB-node belonging to another IAB topology controlled by another IAB-donor. This situation may also happen in the case of an JAB-node that experienced radio link failure (RLF) and that has recovered through a parent JAB-node belonging to another JAB topology. In those cases, the migrated IAB-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 JAB topology, MT migrationshould be followed by traffic migration where the traffic related to the boundary node and its descendant JAB-nodes is routed through the other IAB topology up to the boundary node (i.e. the migrated IAB-node).

Stationary JAB-nodes should only require a single MT migration. Indeed, a backhaul link (defined between two successive JAB-nodes in the wireless backhaul) may experience radio failure due to fluctuations of radio conditions and, for JAB-nodes that do not move, it should be a temporary situation with possible link recovery after some time. Thus, it should not be required for such stationary JAB-nodes to perform multiple MT migrations in the same JAB 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 JAB-node, leaving the control of the JAB-node to a new JAB-Donor, should not 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 JAB-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, 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 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 JAB systems and architecture, as a part of the release 18 framework, in order to address scenarios focusing on mobile IAB-nodes mounted on vehicles (such as buses, trains, taxis). In such scenarios, mobile IAB-nodes can be referred to as Vehicle Mounted Relays (VMR), providing 50 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 HE as relay e. a Sidelink Relay solution), an JAB-node mounted on a vehicle is expected to have better RF/antenna capabilities, and to have less stringent power / battery constraints than a relay UP.

For a mobile JAB-node it may be worth performing multiple MT migrations or DU migration, as the connection to a parent JAB-node belonging to a first JAB topology may not occur again for a long time as the mobile JAB-node moves around or never again in the case where the mobile IAB-node moves away from the parent IAB-node. Besides, for flexible IAB network management, MT and DU migration should be decorrelated, meaning that a DU migration for an JAB-node may occur before or after one or several MT migrations of this IABnode. Moreover, the DU migration for an JAB-node may be performed toward an JAB-donor different to the IA B-donor associated to the MT of this IAB-node.

Therefore, some new mechanisms are required to provide such flexibility by supporting the DU migration of an TAB-node toward any other donor-CU, decorrelated to the MT migration(s) of the 1AB-node.

Summary

In accordance with a first aspect of the present invention, there is provided a method for use in a migration process in which a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node is migrated from one IAB topology managed by a source IAB donor Central Unit, CU, to another JAB topology managed by a target JAB donor CU, the method at the source JAB donor CU comprising: determining the DU of the JAB node is to be migrated from the one IAB topology of the source IAB donor CU to the another IAB topology of the target IAB donor CU; sending, to the IAB node, a request for establishing a Fl connection between the JAB node and the target JAB donor CU.

In accordance with a second aspect of the present invention, there is provided a method, performed at an JAB node, for use in a migration process in which a DU of the 1AB node is migrated from one JAB topology managed by a source TAB donor Central Unit, CU, to another IAB topology managed by a target IAB donor CU, as recited in the accompanying claims.

In accordance with a third aspect of the present invention, there is provided a method, performed at a target IAB donor CU, for use in a migration process in which a DU of an IAB node is migrated from one JAB topology managed by a source JAB donor Central Unit, CU, to another JAB topology managed by the target JAB donor CU, as recited in the accompanying claims.

Thus, by sending a request to the JAB node for establishing a Fl connection between the JAB node and the target JAB donor CU, the source Fl donor CU (e.g. source JAB donor CU) facilitates DU migration of an IAB-node with or without (multiple) MT migration(s). Furthermore, in response to receiving the request to establish a F] connection, the TAB node can identify (e.g. via identification information sent by the source donor CU or when no identification information is sent by the source donor CU, by determining a non-Fl donor CU is the target donor CU) the target donor CU to enable the handover of UEs sewed by the JAB-node to the target donor CU.

In accordance with a fourth aspect of the present invention, there is provided an apparatus for an JAB node for an JAB communication system as recited in the accompanying claims.

In accordance with a fifth aspect of the present invention, there is provided an apparatus for an TAB donor CU (e.g. a source TAB donor CU or a target JAB donor CU) for an JAB communication system as recited in the accompanying claims.

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.

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 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 with reference to the following drawings in which: Figure 1 is a 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 into IAB operations, Figure 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit 25 (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 JAB communication system (or JAB 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 JAB-node architecture enabling its DU migration from a source JAB topology to a target JAB topology; Figure 7 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to perform DU migration of an JAB-node including the handover of UEs served by the migrating IAB-node; Figure 8a is a simplified diagram illustrating an example message flow of a procedure to perform the activation of a logical DU according to one or more embodiments of the invention; Figure 8b is a simplified diagram illustrating an example message flow of a procedure to setup a logical DU; Figure 8c is a simplified diagram illustrating an example message flow of a procedure 10 to remove a logical DU; Figure 9a is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to report the activation of cell(s) to another RAN node CU; Figure 9b is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration in coordination with another 15 RAN node CU; Figure 10a 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 IAB-node, the DU migration of the JAB-node toward a target JAB topology; Figure 10b is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at an IAB-node, the DU migration toward a target IAB topology; Figure 10c is a flowchart showing example steps, in accordance with one or more embodiments of the invention, performed at an IAB-node to identify the target IAB donor CU; Figure 10d is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at a target IAB donor CU, the DU migration of an IAB-node toward a target JAB topology managed by the target JAB donor CU.

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 IAB-node(s). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 50 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 50, but it should be appreciated that such terminology also applies to elements or processes performing an equivalent function in other communication systems.

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 IABnodes), and a mobile Integrated Access and Backhaul (JAB) station 123 mounted on a vehicle 105 (for example, a bus, a train, a taxi, a car, etc.).

The main Base Station 120, also referred to as the IAB-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, IAB-donor 120 is a 5GNR gNB with additional functionality to support JAB features, as defined in 3GPP TS

38.300 v17.2.0 specification document.

In order to extend the network coverage of TAB-donor 120 and reach the remote UEs 132, 133 and 131, IAB stations 121 and 122, also referred to as IAB-nodes 121 and 122, have been installed by the operator. By acting as relaying nodes between the IAB-donor 120 and the UEs 132 and 133, IAB-nodes 121 and 122 allow overcoming the reachability issue 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 IAB-donor 120. This is particularly true when the communications between the JAB-donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

The IAB-donor 120 also serves UE 134, which is directly connected to it.

The mobile IAB station 123, also referred to as mobile IAB-node U3 or mIAB node 123, is an TAB-node that is mounted on vehicle 105 and provides network coverage and capacity extension, allowing the IAB-donor 120 to reach onboard remote UEs, like remote UE 135, as well as surrounding UEs or UEs in the vicinity of the JAB-node 123, like remote UP 136.

The LAB-donor 120 and the JAB-nodes 121, 122 and 123 are thus forming a backhaul network or JAB network, or JAB topology, which accommodates UEs 132, 133, 131, 134, 135 and 136. The terms JAB network and JAB topology will be used interchangeably in the following.

The specification of the Integrated Access and Backhaul (JAB) is spread over several 3GPP standard documents, including: - IS 38.300 RAN architecture (V17.2.0), - IS 38.321 MAC protocol (V17.2.0), -IS 38.331 Radio Resource Control (RRC) protocol (V17.2.0), - IS 38.340 Backhaul Adaptation Protocol Layer (V17.2.0), - IS 38.401 RAN architecture (V17.2.0), - IS 38.423 Xn Application Protocol (V17.2.0), - IS 38.473 Fl Application Protocol (V17.2.0).

As JAB-donor 120 and IAB-nodes 121, 122 and 123 are respectively connected to UEs 134, 131, 132, 133, 135 and 136, they are considered as Access IAB-nodes for their respectively connected UEs The JAB-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 unit(s) (DU or gNB-DU functionality). ThelAB-donor-CU or donor-CU (also referred to in the following as JAB-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 JAB-donor-DUs or donor DUs (also referred to in the following as IAB-donor DU or IAB donor DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols. The 1AB-donor-CU or donor-CU and JAB-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 1AB-nodes, and at terminating the Fl protocol to the JAB-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 IAB-donor 120, via one or multiple hops over one or more intermediate JAB nodes. They form a directed acyclic graph (DAG) topology with the JAB-donor at its root.

The JAB nodes each consist of an JAB-DU (JAB-Distributed Unit) and an JAB-MI (IAB-Mobile Termination). The gNB-DU functionality on an IAB-node is also referred to as JAB-DU and allows the downstream (toward the UE) connection to the next-hop JAB or to a UE. The JAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access Stratum (NAS) functionalities to connect to the gNB-DU of an upstream JAB-node (including the IAB-donor 120 in which case it connects to the JAB-donor gNB-CU, hence to the core network 1102 for instance for initialization, registration and configuration).

In this DAG topology, the neighbour node on the 1AB-DU's interface is referred to as child node and the neighbour node on the JAB-MT's interface is referred to as parent node.

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 JAB-donor 120 (e.g. the JAB-donor CU) performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the IAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data 10 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 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 IABdonor -CU and an JAB-node -DU (e.g. of JAB-node 2), and between the IAB-donor-CU and an IAB-donor DU. H-U is the functional interface in the User Plane (UP) for the same units.

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 JAB-donor to JAB-nodel and then from JAB-nodel to IAB-node2).

In the User Plane, boxes 210 at the IAB-donor-CU and the IAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer. GTP-U stands for GPRS Tunnelling 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 TAB-donor-CU and the JAB-node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram service and fit to use with an IP protocol.

In the Control Plane, boxes 210 indicate the FlAP (F1 Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer. The Fl Application Protocol (as defined in 3GPP T538.473 and TS 38.401) provides signalling services between the JAB-donor-CU and the JAB-node DU, or UE associated services. These 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 JAB-donor-CU and the IABnode DU as defined in 3GPP TS 38.401.

The transport between the IAB-donor DU and the IAB-donor-CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the JABdonor-CU is remote from the IAB-donor DU, or locally in a virtual instantiation of the JABdonor-CU and the IAB-donor DU on the same physical machine. IAB-specific transport between JAB-donor-CU and JAB-donor-DU is specified in 3GPP TS 38.401.

Li and L2 on the Figure 2a stand respectively for the transport and physical layers appropriate to the medium in use.

The IP layer can also be used for non-F1 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 specified in TS 38.340.

The IAB-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 IAB-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 JAB-DU and JAB-MT) of the intermediate LAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the destination JAB-node (which may be an access IAB-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 JAB-node (which may be an access JAB-node should the upper layer packets 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 JAB-DU and JAB-MT) of the intermediate JAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the JAB-donor DU.

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 JAB-donor-DU or initiator JAB-node (e.g. a network node in the JAB network generating the BAP packets). Figure 3 illustrates the format of a BAP Data Protocol Data Unit (PDLT) or packet. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 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).

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 IABnode or IAB-donor DU for the BAP packet. For the purpose of routing, each IAB-node and JAB-donor DU in an TAB network is configured (by TAB-donor-CU of the JAB 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 JAB topology. For the purpose of routing, the routing paths, including their path ID, are configured (by JAB-donor-CU of the IAB network) in the IAB-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 IAB-donor-CU.

For instance, when the BAP packet is generated by a node, i.e. either by the JAB-donorDU for downstream transmission or by an initiator (which may be an access TAB-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 IAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the initiator JAB-node. In intermediate TAB-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 IAB-nodes given the IAB network topology) are usually defined by the JAB-donor-CU and transmitted to the JAB-nodes to configure them. To transport messages over the 50 NR radio medium, three more sublayers (RUC, 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 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 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 PHY sublayer converts the physical modulation signals back to a stream of information. The PHY layer is described in IS 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 15 UE and IAB-donor-CU: the PDCP (Packet Data Convergence Protocol) sublayer and either the SDAP (Service Data Adaptation Protocol) sublayer for the User Plane communications or 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.

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 JAB-donor-CU side, the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc) 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; 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 interfaces between the!AB-nodes.

NR-Uu is the interface between the UE and the radio access network, 1.e its access IAB-node (for both CP and UP).

Figure 2b comes from 3GPP TS 38.300 v17.2.0 and illustrates the protocol stack for the support of JAB-MT's RRC and NAS connections. The Non-Access Stratum (NAS) protocol handles the messages between the core network and a user equipment, or an IAB-node. It manages the establishment of communication sessions and maintains communications with the JAB-node or the user equipment as it moves. The 5GNAS is described in 3GPP TS 24.501. The 50 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 connected to the JAB node, as well as similar information for the JAB-node. AMF is only responsible for handling connection and mobility management tasks.

The JAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the JAB-donor-CU. These SRBs are transported between the JAB-MT and its parent node(s) over NR-Uu interface(s).

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 20 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 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 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 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 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 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 JAB node and a UE may be implemented in such a communication device/apparatus 100.

The memory may include: -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 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 1106 or to write data onto said disk; - a screen 409 for displaying decoded data and/or serving as a graphical interface with 25 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 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 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.

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 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 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 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, JAB donor CU). Accordingly, the term 'central processing unit" as used herein may refer to any 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) Figure 5 illustrates an example of an TAB communication system (or TAB 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 JAB nodes and between the IAB nodes and the IAB donor DUs (referred to as BR radio links) are operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance. An TAB network will also be referred to as an JAB topology or topology and so in this application, the terms JAB network and JAB topology and topology will be used interchangeably.

JAB communication system 500 is composed of three JAB networks or JAB topologies 5001, 5002, and 5003 with each JAB topology comprising a set of JAB nodes (e.g. the set may comprise a plurality of JAB nodes or at least one 1AB node) and an JAB-donor-CU for controlling or managing the plurality of JAB nodes. The set of JAB nodes may include one or more IAB-nodes, such as initiator IAB-nodes which generate BAP packets and also intermediate or relay JAB-nodes. Each of the JAB nodes communicate with at least one other JAB node over a wireless backhaul (BH) link. Although Figure 5 shows three JAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an JAB communication system comprising more than two JAB topologies with each topology comprising a set of JAB nodes and an JAB donor-CU as discussed above.

As discussed above, each IAB node comprises a Mobile Termination (MT) part or unit, 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 JAB donor using FI-AP messaging as defined in 3GPP TS 38.473. For example, JAB-node 510 comprises a MT part or unit 5 I I and a DU p art 512.

IAB topology 5001 includes JAB-donor-CU 501 (identified as Donorl-CU in Figure 5), and its associated IAB-donor-DU 504 (identified as Donorl -DUI in Figure 5), and a plurality of JAB-nodes 510 and 520, similar to JAB-nodes 121 and 122.

IAB topology 5002 includes IAB-donor-CU 502 (identified as Donor2-CU in Figure 5), its associated IAB-donor-DUs, IAB-donor-DU 505 (identified as Donor2-DU] in Figure 5) and JAB-donor-DU 506 (identified as Donor2-DU2 in Figure 5), and a plurality of JAB-nodes 530, 540, 550, similar to IAB-nodes 121 and 122, and IAB-node 570, that may be similar to mobile IAB-node 123. All IAB-nodes can be access nodes serving UEs like the UE 580 served by the mobile IAB-node 570. The JAB 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 JAB-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 JAB communication system 500. JAB topology 5003 includes IAB-donor-CU 503 (identified as Donor3-CU in Figure 5), and its associated IAB-donor-DU 507 (identified as Donor3-DUI in Figure 5), and an JAB-node 560, similar to IAB-nodes 121 and 122.

A wired backhaul IP network interconnects the JAB-donor-CUs 501, 502, and 503, and the JAB-donor-DUs 504, 505, 506 and 507 through the wired backhaul 508. For instance, this wired backhaul 508 consists of optical fiber cables.

IAB-Donor-CU 501, IAB-Donor-DU 504 and IAB-nodes 510 and 520 are part of the same TAB network or JAB topology 5001, which is configured and managed or controlled by 1AB-Donor-CU 501.

IAB-Donor-CU 502, IAB-Donor-DUs 505 and 506, and IAB-nodes 530, 540, 550 are part of the same IAB network or IAB topology 5002, which is configured and managed or controlled by IAB-Donor-CU 502.

IAB-Donor-CU 503, IAB-Donor-DU 507, and IAB-node 560 are part of the same LAB network or IAB topology 5003, which is configured and managed or controlled by IABDonor-CU 803.

Each IAB-DU and JAB 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 Donor DU is associated with cell(s). Wireless communication devices (such as UEs, or other JAB-nodes) located within a cell may establish communication links with the node (i.e. JAB-DU or JAB Donor DU) sewing the cell in order to communicate with other devices (e.g. other UEs, 1AB-nodes, servers providing access to the Internet, etc.) via the node.

It is assumed that the mobile IAB-node 570 had initially a single parent IAB-node 520, and that IAB-node 570 belongs to the IAB topology 5001 controlled by the IAB-Donor-CU 501. The JAB-Donor-CU is thus operating as the Fl terminating donor-CU (which may also be referred to as a Fl-terminating IAB-donor-CU or Fl donor-CU). When moving, and in view of its proximity to IAB topology 5002, in particular to the IAB-node 530 when the mobile IAB-node 570 is in the position shown in dotted lines in figure 5, the mobile JAB-node 570 may be able to establish a wireless BH link with the JAB-node 530. Such a BH link is possible for a stationary IAB-node, and it is very likely to happen for a mobile IAB-node like IAB-node 570, moving, for instance, in the direction of the JAB topology 5002 (shown by arrow 590 in figure 5.

Then, the Fl donor-CU 501 may have decided to perform the migration of the MT part 571 of the TAB-node 570 toward the 1AB topology controlled by the donor-CU 502, which became the non-Ft terminating donor-CU (which may also be referred to as a non-F1-terminating TAB-donor-CU or non-Ft donor-CU) for the IAB-node 570 (i.e. the MT part 571 of the IAB-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 IAB-node 570 has descendant IAB-nodes). As a result, the IAB-node 501 still belongs to the JAB topology 5001, with its Fl connection to the donor-CU 501, but its RRC connection is now to the donor-CU2 502. After that procedure, the IAB-donor-CU 501 may request the migration toward the LAB topology 5002 (i.e. through the donor-DU 505) of the backhaul traffic (e.g. user traffic, control traffic) related to the IAB-node 570. In this case, the donor-CU 501 triggers the JAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. In the IAB communication system, all traffic communicated over backhaul links uses a Fl interface (Fl-C or Fl-U) between an JAB 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 IAB-node 870 is still moving in the direction shown by arrow 590, the MT part 571 of the IAB-node 570 may then have been migrated by the non-Fl donor-CU 502 toward the parent IAB-node 550, using the backhaul link 5050 between the IAB-node 550 and the IAB-node 570. For this purpose, the non-El 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 1AB-node) of the IAB-node 570 with a new single parent 1AB-node 550. Still, the IAB-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 IAB-node 570, the donor-CU 501 may request the migration of the traffic related to the IAB-node 570 toward the IAB topology 5002. In this case, the donor-CU 501 triggers the JAB 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 IAB-node 570 may become in a position where a backhaul link 5060 with the IAB-node 560 may have a better quality than the backhaul link 5050 with the JAB-node 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 IAB-node 501 still belongs to the JAB 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 donor-CU 503 becomes the non-Fl terminating donor-CU (or non-Fl donor-CU). However, the donor-CU 501 has to be informed of the new non-Fl donor-CU 503 for the IAB-node 570 and of the new donor-DU 507 to redirect the offloaded traffic (F1 traffic, control and user traffic) through the donor-DU 507 instead of donor-DU 506.

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 IAB-node 570. In case the JAB-node 570 has some child IAB-node(s), such child IAB-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 1AB-node 570, thus regardless of whether the MT part 571 of the IAB-node 570 has migrated to TAB topology 5002 or TAB topology 5003 and so regardless of whether the IAB-node 570 has a non-F1 terminating donor-CU and if it does, whether it's the non-Fl terminating donor-CU 502 or 503, the F 1 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 the Fl donor-CU 501, or because the 1AB-node 570 is geographically far from the H 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 TAB-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 migration toward the current non-F1 terminating donor-CU (i.e. the default choice) if there is a current non-F1 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. For instance, if the TAB-node 570 is 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 1AB-node 570 will soon connect to the network. For instance, while the non-Fl terminating donor-CU of the JAB-node 570 is the donor-CU 502, the Fl donor-CU may decide the DU migration of the JAB-node 570 should be directly toward the donor-CU 503, as the IAB-node 570 may rapidly 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 IABnode 570. When DU migration is performed, handover of the UEs served by the TAB-node 570 must also be performed. Thus, to not perform the DU migration toward the donor-CU 502 will also avoid the intermediate handover of LTEs served by the IAB-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 JAB-node architecture 600 which enables migration of the DU of the JAB-node (I)U migration) from a source JAB topology to a target TAB topology.

The JAB node 601, which may be a mobile JAB-node like the JAB-node 570, is composed of an IAB-MT part or unit IAB-MT 610 (like the MT part 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-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for the BAP, RFC, 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 JAB-node 601, both logical DUs are active: one of the logical DU terminates the Fl interface with a source Fl donor-CU (like 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 JAB operations. As an example and with reference to the JAB communication system of figure 5, the Fl terminating donor CU of the JAB node 601 (i.e. 1AB node 570) may be donor-CU 501 which is thus operating as the source Fl donor-CU. The source Fl-donor CU 501 may identify IAB donor-CU 502 as a suitable target Fl donor-CU when the source Fl-donor CU 501 determines that the IAB-node 570 is moving towards/through the IAB topology 5002 which includes network nodes (e.g. IAB donor DUs 505, 506, IAB nodes 530, 540, 550) managed by the IAB donor-CU 502, which network nodes serve cells in IAB topology 5002 to which the IAB-node 570 will soon connect. Alternatively, for an JAB node which is connected to parent JAB-node or parent JAB donor-DU of the JAB 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 vicinity of one or more JAB nodes in a neighbouring JAB topology, such as JAB topology 5002, the source Fl-donor CU 501 may determine that JAB donor-CU 502 is a suitable target H donor-CU when source H -donor CU 501 determines (e.g, based on signal measurements performed at the JAB-node on radio signals received at the JAB-node from all JAB-nodes in proximity to the JAB-node and which may include JAB-nodes in the neighbouring JAB topology 5002) that the JAB-node may soon connect to an JAB-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 LAB-DU1 611, and the logical DU IAB-DU2 612 is 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 HE 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 8a and 8b. Once the handover of UP 602 is completed from a cell controlled by the logical DU IAB-DU] 611 to a cell controlled by the logical DU IAB-DU2 612, the logical DU IAB-DUI 611 may be deactivated. The deactivation may be triggered by the source Fl donor-CU 501with the procedure described with reference to figure 8c, after the detection of the completion of the handover for all UEs served by the IAB-DU1 611.

Examples of methods, in accordance with one or more embodiments of the present invention, which enable DU migration of an IAB-node to be performed, with or without (multiple) MT migration(s), and which include notifying the IAB-node about the identity of target donor CU to enable the handover of UEs served by the JAB-node to the target donor CU will now be described. Although the following methods/apparatus' will be described primarily with respect to a mobile JAB node, it will be appreciated that it is not intended that the invention is limited to mobile JAB nodes. The methods in accordance with one or more embodiments of the present invention may apply to stationary 1AB nodes e.g. that are at the edge of one JAB topology and in the proximity of or in the vicinity of one or more JAB nodes in a neighbouring 1AB topology.

Figure 7 is a schematic and simplified diagram 700 illustrating some example message flows according to one or more embodiments of the invention, to perform the DU migration of an JAB-node, with or without (multiple) MT migration(s), and which includes informing the IAB-node about the target donor CU to enable the handover of UEs, served by the migrating JAB-node, to the target donor CU.

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, the core network (5GC) 702 like the core network 110 of figure 1. This figure 7 also shows an IAB-node 701 that may be a mobile JAB-node like the JAB-node 570 composed of a MT part or unit JAB-MT 704, a DU part or unit JAB-DU1 705 (e.g. source or first logical DU entity), and a DU part or unit IAB-DU2 706 (e.g. target or second logical DU entity). Each of the first 705 and second 706 DU logical entities serve one or more cells. The cell(s) of the JAB-DU1 705 are identified by different identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)) to the cell(s) of the JAB-DU1 705. JAB-DUI 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 physical layers. The non-F1 donor-CU for the JAB-node 701 may be the source F1 donor-CU 703 itself if the 1AB-MT 704 was not migrated. The non-F1 donor-CU for the JAB-node 701 may be the target Fl donor-CU 707 if the JAB-MT 704 was previously migrated toward the target Fl donor-CU 707, or another donor-CU (not represented in the figure) if the IAB-MT 704 was previously migrated toward this other donor-CU.

At the beginning of the flow, the IAB-node 701 belongs to the source IAB topology controlled by the source Fl donor-CU 703. The UE 708 is sewed by the IAB-node 701 through a cell of JAB-DUI 705 (e.g. the DU of the IAB-node 701 has an active IAB-DUI 705 having a Fl connection with the source El IAB donor CU 703), while the logical 1ABDU2 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-DUI 705 of the IAB-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 JAB topology controlled by the source Fl donor-CU 703, or in the JAB topology controlled by the non-F1 donor-CU of the 1AB-node 701 (if the 1AB-MT 704 was previously migrated toward this non-F1 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 non-Fl terminating donor-CU if it has been previously migrated toward this non-F1 donor-CU (not shown in figure 7) or if it has not been migrated from its Fl terminating donor-CU, to its Fl terminating donor-CU (e.g. source Fl donor-CU 703), as the result of the measurements regularly performed by IAB-MT 704 on signals received from the sewing 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 target cells may be neighbouring cells to the sewing or source cell (i.e. the current sewing 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 different cells in the vicinity of the 1AB-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 (PC1) broadcasted in each cell managed by this donor-CU in a 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 IAB-node 701 in the measurement report.

Based on the received measurement reports, 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, may detect that the IAB-node 701 receives radio signals in a target cell of a target parent IAB-node with a better quality than in the source serving cell. The non-El 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, may decide to apply a procedure to perform the IAB-MT 704 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 if the IAB-MT 704 has been migrated or the source F1 donor-CU 703 will be informed since it made the decision to perform MT migration directly from the measurement reports received from the IAB-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 IAB-node 701. In another example, the non-F1 donor-CU may relay the information in the measurement reports received from the IAB-node 701 to the source Fl donor-CU 703. Thus, the source H donor-CU 703 may base its decision for DU migration of the IAB-node 701 directly from these measurement reports relayed by the non-Fl donor-CU.

Thus, the source Fl donor-CU 703 determines the DU of the JAB node is to be migrated from the IAB topology of the source Fl donor-CU 703 to another IAB topology of a 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 first IAB topology toward a second IAB topology, and on a known (predefined) trajectory of the IABnode that indicates to the source Fl donor-CU that the MT will be migrated later to a third IAB topology. In this case, to avoid signaling messages for DU migration/UEs handover toward the second IAB topology, the DU is directly migrated toward the 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.

Upon the decision of or determination by the source Fl donor-CU 703 to perform the DU migration of the IAB-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 JAB node 701 to establish a new Fl connection between the target Fl donor-CU 707 and the mobile JAB node 701. This may require activation of the second logical 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 JAB node 701. This operation is performed using, for example, the procedures described with reference to the figures 8a and 8b. In particular, the message sent by the source Fl donor-CU 703 to the IABnode 701 for the activation of the IAB-DU2 706 (e.g. 803 in figure 8a) may include identification information for identifying the target donor CU, such as the TNL address (i.e. IP address) of the target F I 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 has been migrated to a non-F1 donor-CU, the non-Fl Donor-CU is considered as the target Fl donor-CU. In this case, the IAB-node 701 has already been informed of the identity (e.g. the TNL address/IP address) of target donor-CU when the IAB-MT 704 was migrated to the non-Fl Donor-CU. In other words, the source Fl donor-CU 703 may send identification information for identifying the target JAB donor CU unless the IAB-MT 704 has been migrated to a non-El donor-CU. Alternatively, the source Fl donor-CU 703 may send identification information for identifying the non-Fl donor-CU as the target JAB donor CU.

After determining the DU of the JAB node 701 is to be migrated and once the IAB-DU2 706 has been activated, then, the IAB-DU2 706 may send a Fl setup request message (e.g. 813 in figure 8b) to the target Fl donor-CU 707 for requesting set up of the Fl connection between the JAB-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) 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 703 of the IAB-node 701. This message may also include the TNL. address (i.e. the IP address) 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-F1 donor-CU of the IAB-node 701 if the IAB-MT 704 of the IAB-node 701 has been previously migrated toward this non-Fl donor-CU (not shown in figure 7). 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 1AB-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 IAB-node 701 is the IAB-node 570 of figures which is connected to IAB-node 550 via backhaul link 5050 and where the MT (MT 571 which corresponds to IAB-MT 704 in figure 7) of the IAB-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 Ft donor CU 501 to the IAB-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. 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 IAB-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. 814 in figure 8b), the target Fl donor-CU 707 (e.g. donor-CU 503 in the example described above with reference to figure 5) may 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 8b, and using, for example, the procedure described with reference figure 9a, the target Fl donor-CU 707 may inform the source Fl donor-CU 705 about the activation of new cell(s) from the IAB-DU2 706 of the IAB-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 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 TIE 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 LTE 708 to hand 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 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 HE 708 for the handover. The configuration may include radio configuration information indicating the radio configuration to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 of the JAB 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 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 JAB-DUI 705 and relayed by the IAB-DU1 705 to the UE 708. Upon reception of this configuration information, the HE 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 F I 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), 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.

The target Fl donor-CU 707 may perform a path switch procedure toward the core network 702 to request the delivery of the user data related to the HE 708. For example, target Fl donor-CU 707 may perform the path switch handshake procedure described in 3GPP TS 38.413 v17.2.0 section 8.4.4.

Then, the target Fl donor-CU 707 has to setup the backhaul path(s) to/from the migrated IAB-node 701, either in its own topology if there is a backhaul path to reach the IAB-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 IAB-node 701 as the JAB-MT 704 has previously been migrated to the target Fl donor-CU 707), or through the JAB topology of the non-Fl donor-CU (not shown in figure 7) of the IAB-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 procedure described with reference to figure 9b to request traffic migration to the non-F1 donor-CU of the JAB-node 701. As an example of this latter case with reference to figure 5, the JAB-node 701 is the IAB-node 570 of figure 5 connected to IAB-node 550 via backhaul link 5050 and where the MT (MT 571 which corresponds to IAB-MT 704 in figure 7) of the IAB-node 570 has been migrated to the non-Ft donor CU 502 and the JAB donor CU 501 is the Fl donor CU. When the DU (DU 572 which corresponds to IAB-DU2 706 in figure 7) of the IAB-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 connection), the backhaul path(s) to/from the IAB-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 JAB donor DU 506, JAB nodes 540 and 550) by performing the traffic migration procedure (e.g. as described with reference to figure 9b).

After the handover of UE 708 and the path switch has been performed, the user data in the downstream direction are transmitted by the core network 702 to the target Fl donor-CU 707 through the bearer 740, then they are transmitted to the logical DU IAB-DU2 706 of the IAB-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 1AB topology controlled by the target Fl donor-CU 707, or in the IAB topology controlled by the non-Ft donor-CU of the JAB-node 707 (e.g. depending on whether the JAB-MT 704 and IAB-DU2 706 of JAB 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.

Once the handover of all UEs served by the IAB-DU1 705 of the JAB-node 701 is completed, the source Fl donor-CU 703 may deactivate the logical DU JAB-DUI 705 of the mobile 1AB-node 701 through the procedure described with reference to figure 8c. 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 IAB-node 701 through the IAB-DUI 705. If the traffic was offloaded in an IAB topology controlled by another donor-CU, the source Fl donor-CU 705 may apply the procedure described with reference to figure 9b to request the traffic release to the other donor-CU. This is represented generally by the procedure 735 in figure 7.

Figure 8a is a schematic and simplified diagram 800 flowchart illustrating an example message flow of a procedure to perform the activation of a logical DU according to an embodiment of the invention This figure shows: a RAN node DU 801, that may be DU of an IAB-node like IAB-DU 572 of JAB node 570 of figure 5 (and IAB-DU1 705 of JAB node 701 of figure 7), a RAN node CU 802, that may be an JAB-Donor-CU like LAB-donor-CU 501 of figures (and source Fl donor-CU 703 of figure 7).

The message CONFIGURATION REQUEST 803 is sent by the RAN node CU 802 to the RAN node DU 801 either to request the activation of new cell(s) controlled by the RAN node DU 801, or to request the activation of a logical DU, or to request the deactivation of cell(s) in the RAN node DU 801. In case of a logical DU activation, the message 803 may include the TNT. address (i.e. LP address) of a RAN node CU (e.g. the target Fl donor-CU 707 of figure 7) that will connect to the logical DU once activated. For example, CONFIGURATION _REQUEST 803 may be sent by the source 1AB donor CU to the JAB node (e.g. the first logical DU entity 705 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 JAB node.

The RAN Node DU 801 may acknowledge the request with the message CONFIGURATION RESPONSE 804 sent to the RAN Node CU 802.

According to one example, the flow in figure 8a corresponds to the procedure gNB-CU Configuration Update procedure described in TS 38.473 V17.0.0 section 8.2.5, and the message 803 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, while the message 804 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 VI7.2.0 section 9.2.1.11.

The message GNB-CU CONFIGURATION UPDATE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated at the RAN Node DU 801. For example and with reference to figure 7, the GNB-CU CONFIGURATION UPDATE includes information to activate the new cell(s) indicated in the LE Cells to be Activated List, which new cell(s) may be served by the first logical DU entity 705 at the IAB node 701. The cell(s) to be activated refer to cell(s) controlled by the RAN Node DU 801 receiving the request. The associated PCI and NCGI value(s) to be used by the RAN Node DU 801 may also be provided.

The message GNB-CU CONFIGURATION UPDATE may also include the Information Element (1E) Cells to be Deactivated List to indicate the list cell(s) to be deactivated. The cell(s) to be deactivated refer to cell(s) controlled by the RAN node DU 801 receiving the request. For example and with reference to figure 7, the GNB-CU CONFIGURATION UPDATE may include information to deactivate the cell(s) indicated in the LE, Cells to be Deactivated List which cell(s) are currently served by the first logical DU entity 705 at the IAB node 701.

According to one example, a new IE Second DU -Activation may be added in the message 803 in the form of a Boolean (e.g. a one-bit IF) to request the activation of a second logical DU. One value (i.e. "0" or "1") of the one-bit IE means no specific action related to the second logical DU is requested and another value (i.e. "1" or "0") means activation of a second logical DU is requested. This 1E may be completed by a new IF indicating a number of cells to be activated in the second logical DU. In the absence of this IE, the number of cells to be activated corresponds to the number of cells currently activated in the RAN Node DU 801.

Besides, a new IE may be added (e.g. Target TIVL address IE) to identify the target RAN Node CU with which a Fl connection shall be setup.

To complete the setup of the new logical DU at the TAB node, the procedure described with reference to figure 8b may be used.

Figure 8b is a schematic and simplified diagram 810 illustrating an example message flow of a procedure to setup a logical DU, so as to establish a Fl connection with the target JAB donor CU, according to an embodiment of the invention.

This figure shows: - a RAN node DU 811, that may be a DU of an IAB-node DU like IAB-DU 572 of JAB node 570 of figure 5 (and LAB-DU2 706 of JAB node 701 of figure 7), - a RAN node CU 812, that may be an 1AB-Donor-CU like 1AB-donor-CU 503 of figure 5 (and target Fl donor-CU 707 of figure 7).

The message SETUP REQUEST 813 is sent by the RAN node DU 811 to the RAN node CU 812 to request the Fl setup for the logical DU. For example, SETUP REQUEST 813 may be sent by the 1AB node (e.g. by the second logical DU entity 706 which has been activated at the JAB node 701) to the target JAB donor CU 707 for requesting set up of a Fl connection between a target JAB donor CU and the JAB node (e.g. with the second logical DU entity 706 of the JAB node 701)). The SETUP REQUEST message 813 may be sent after an activation request as described with reference to figure 8a. This SETUP REQUEST message 813 may include the number of cells to be activated along with activation of the logical DU. This SETUP REQUEST message 813 may include the TNL address (i.e. the IP address) 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 RAN node CU terminating the Fl connection of the RAN node DU 811 (e.g. the source 1AB donor CU 703). This message may include the TNL address (i.e. the IP address) 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 RAIN node CU terminating the non-Ft (i.e. RRC) connection of the RAN node DU 811 in the case where the MT (e.g. m1VIT 571 of IAB node 570 or corresponding JAB-MT of 704 of JAB node 701) has been migrated to the RAN node CU (which is now the non-Fl donor CU).

The RAN node CU 812 answers with the message SETUP RESPONSE 814 sent to the RAN node DU 811. It 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.

According to one example, the flow in figure 8b corresponds to the procedure Fl setup described in IS 38.473 V17.2.0 section 8.2.3, and the message 813 corresponds to the message Fl SETUP REQUEST described in TS 38.473 V17.2.0 section 9,2,14, while the message 814 corresponds to the message Fl SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5. The message Fl SETUP RESPONSE includes the Information Element (1E) Cells to he Activated List to indicate the list of new cell(s) to be activated. The cell(s) to be activated refer to cell(s) controlled by the RAN node DU 811 receiving the response.

Figure 8c is a schematic and simplified diagram 820 illustrating an example message flow of a procedure to remove a logical DU.

This figure shows: a RAN node DU 821, that may be a DU of an JAB-node DU like JAB-DU 572 of IAB node 570 of figure 5 (and IAB-DU1 705 of IAB node 701 of figure 7), a RAN node CU 822, that may be an JAB-Donor-CU like TAB-donor-CU 501 of figure 5 (and source Fl donor-CU 703 of figure 7).

The message REMOVAL REQUEST 823 is sent by the RAN node CU 822 to the RAN node DU 821 to request the removal (which is equivalent to deactivation) of the logical DU.

The RAN node DU 821 answers with the message REMOVAL RESPONSE 814 sent to the RAN node CU 822.

According to one example, the flow in Figure 8c corresponds to the procedure Fl removal described in IS 38.473 V17.2.0 section 8.2.8, and the message 823 corresponds to the message Fl REMOVAL REQUEST described in TS 38.473 V17.2.0 section 9.2.1.16, while the message 824 corresponds to the message Fl REIVIOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7.

Figure 9a is a schematic and simplified diagram 900 illustrating an example message flow of a procedure used by a RAN Node CU to report the activation of cell(s) to another RAN Node CU according to an embodiment of the invention.

This figure shows two RAN nodes, RAN node CUa 901 and RAN node CUb 902, that may be two IAB-Donor-CUs, like two of IAB-donor-CUs 501, 502, and 503 of figures. With respect to the example shown in figure 7, RAN node CUa 901 is the target Fl donor-CU 707 and RAN node CUb 902 is the source Fl donor-CU 703.

The message CONFIGURATION UPDATE 903 is 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 TAB-DU2 706 of the IAB-node 701. For example, the source Ft donor-CU 703 receives the CONFIGURATION UPDATE message 903 from the target Fl donor-CU 707 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 705) of the DU of the IAB node 701.

The RAN node CUb 902 answers with the message CONFIGURATION 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, while the message 904 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 schematic and simplified diagram 910 illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration (e.g. migration or release of Fl traffic such as user/control traffic) in coordination with another RAN Node CU according to an embodiment of the invention.

This figure shows two RAN nodes, RAN node CUa 911 and RAN node CUb 912, that may be two IAB-Donor-CUs, like two of IAB-donor-CUs 501, 502, and 503 of figure 5.

The message TRANSPORT MIGRATION REQUEST 913 is sent by the RAN node CUa 911 to the RAN node CUb 912 to request the traffic migration or release in the IAB topology controlled by the RAN node CUb 912. For example, with reference to figure 7, in the case where the MT 704 of the JAB node 701 had been migrated to a non-El donor CU (not shown in figure 7), the source Fl donor-CU 703 may send a TRANSPORT MIGRATION REQUEST 913 to the non-El donor CU to request release of the traffic (e.g. Fl traffic) migrated to the non-F1 donor CU's topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 707 through the IAB topology managed by the non-El donor CU). Alternatively, in the case where the MT 704 of the IAB node 701 had been migrated to a non-Fl donor CU (not shown in figure 7), the target Fl donor-CU 707 may send a TRANSPORT MIGRATION REQUEST 913 to the non-El donor CU to request traffic (e.g. Fl traffic) migration to the non-El donor CU's topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 707 through the IAB topology managed by the non-F1 donor CU) The RAN node CUb 912 answers with the message TRANSPORT MIGRATION RESPONSE 914 sent to the RAN node CUa 901 to accept or reject the request.

Depending on the situation, the figure 9b may correspond to the 1AB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. The message 913 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.2, and the message 914 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.3. The figure 9b may also correspond to the IAB transport migration modification procedure specified in TS 38.423 V17.2.0 section 8.5.3. The message 913 corresponds to the LAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.4, and the message 914 corresponds to the JAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.5.

Figure 10a is a flowchart showing an example method 1000 in accordance with one or more embodiments of the invention, performed at the source JAB donor CU for use in a migration process (or for use in part of a migration process) in which a Distributed Unit, DU, of an JAB node is migrated from one IAB topology managed by the source JAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1000 is for managing, at the source Fl terminating donor-CU of an IAB-node, the DU migration of the IAB-node toward a target IAB topology. For example, with reference to the IAB communication system shown in and described with respect to figure 5, the source IAB donor CU performing the method 1000 may be the IAB donor CU 501 (e.g a Fl terminating donor CU of the IAB node 570 with which the JAB node 570 retains a Fl connection). The JAB node may be mobile IAB-node 570 belonging to JAB topology 5001 controlled by the JAB donor CU 501. The migration process may involve the migration of the DU 572 of the lAB node 570 from JAB topology 5001 to JAB topology 5003 managed by JAB donor CU 503 which is the target JAB donor CU. With reference to figure 7, the IAB node may be IAB-node 701 and the migration process may involve the migration of the DU of the IAB-node 701 from the source Fl donor-CU 703 to the target Fl donor-CU 707. The method 1000 as shown in and described with respect to figure 10a may be performed by software elements and/or hardware elements. The source JAB 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 10a being performed by one or more processing units, such as the central processing unit 411.

At step 1001, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703 of figure 7), determines that the DU of the JAB node, like the JAB-node 570 of figure 5 (701 of figure 7) is to be migrated from the source Fl donor-CU 501, 703 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707 of figure 7). For example, the source Fl donor-CU 503, 707 decides the DU migration of an IAB-node, like the IAB-node 570, toward a target Fl donor-CU, like the donor-CU 503. For example, the source F1 donor-CU 501, 703 may determine that the DU of the IAB node 570, 701 is to be migrated in response to determining the migration of the MT of the IAB node 570, 701 toward a new parent IAB node (which may be a new JAB 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 determines the target Fl donor-CU 503, 707 is also described above At step 1002, the source Fl terminating donor-CU 501, 703 sends to the JAB-node a request for establishing a Fl connection (i.e. a new Fl connection) between the target IAB donor CU 503, 707 and the JAB-node 570, 701 (e.g. a new F 1 association with the target JAB donor CU). For example, the source Fl terminating donor-CU 501, 703 sends to the JAB-node 570, 701 to be migrated, a request for a new Fl connection. The request may be the CONFIGURATION REQUEST 803 described with reference to figure 8a. The source Fl donor-CU 501, 703 may send, to the JAB-node, information indicating a number of cells to be activated at a second logical DU entity of the DU of the JAB-node.

Optionally, at step 1003, the source Fl terminating donor-CU 501, 703 sends, to the IAB node 570, 701, identification information for identifying the target IAB donor CU 503, 707. The identification information may be the TNL address (i.e. IP address) of the target JAB donor CU 503, 707. For example, the source Ft terminating donor-CU 501, 703 sends to the IAB-node to migrate, the address of the target Fl donor-CU for the new Fl connection. In the case where the IAB-MT 704 has been migrated to a non-Fl donor-CU, the identification information sent by the source El terminating donor-CU 501, 703 may include the address of the non-Ft donor-CU (albeit the JAB node 701 may already have this information) to identify the non-Fl donor-CU as the target Fl donor-CU.

The source El terminating donor-CU 703 may receive, from the target Fl donor-CU 707, identification information identifying one or more new cells that have been activated at a second logical DU entity of the DU of the TAB node. As discussed above, the DU of the JAB node has a first logical DU entity with a Fl connection to the source Fl terminating donor-CU 703 and a second logical DU entity is activated in order to perform DU migration (e.g. to establish a new Fl connection between the target Fl donor-CU 707 and the JAB node 701). For example, the identification information may be received in a CONFIGURATION UPDATE message 903 described above.

In an example, the source Fl terminating donor-CU 703 may send, to the target Fl donor-CU 707, a handover request for requesting handover, from the source F 1 terminating donor-CU 703 to the target Fl donor-CU 707, of one or more User Equipment, UE, (such as UE 708) served by the IAB node 701 and for identifying one or more target cells (e.g. candidate target cells) for each UE. In response to receiving a handover acknowledgement from the target Fl donor-CU 707 indicating handover of the one or more UE has been accepted and identifying a target cell for each UE, the source Fl terminating donor-CU 703 sends to the IAB node 701, configuration information for configuring each of the one or more UE for the respective target cell. The handover acknowledgement from the target Fl donor-CU 707 may also include the configuration information for configuring each of the one or more UE for the respective target cell. The Handover procedure 730 discussed above may be performed for these steps.

After handover of the one or more UE 708 to the target Fl donor-CU 707 is completed, the source Fl terminating donor-CU 703 may send, to the JAB node 701, a request for deactivating a first logical DU entity (e.g. IAB-DUI 705) of the DU of the IAB node 701.

The request may be a deactivation request sent in the CONFIGURATION REQUEST message 803 or a removal request sent in the message 823.

After handover of the one or more UE 708 to the target Fl donor-CU 707 is completed and when a Mobile Termination, MT, (e.g. IAB-MT 704) of the IAB node 701 has been migrated to a non-Fl donor CU, the source Fl terminating donor-CU 703 may send, to the non-Fl donor-CU, a traffic migration request (e.g. message 913) for requesting traffic release for the traffic associated with the JAB node that was routed via one or more paths in an IAB topology managed by the non-Ft donor CU.

Figure 10b is a flowchart showing an example method 1010, in accordance with one or more embodiments of the invention, performed at an IAB node (e.g. a mobile JAB node or mIAB node) for use in a migration process (or for use in part of a migration process) in which a Distributed Unit, DU, of the IAB node is migrated from one IAB topology managed by a source JAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1010 is for managing, at an IAB-node, the DU migration toward a target F1 terminating donor-CU. For example, with reference to the IAB communication system shown in and described with respect to figure 5, the IAB node performing the method 1010 may be the mobile IAB-node 570 belonging to JAB topology 5001 controlled by the JAB 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 lAB donor CU. The migration process may involve the migration of the DU 572 of the IAB node 570 from IAB topology 5001 to 1AB topology 5003 managed by IAB donor CU 503 which is the target IAB donor CU. With reference to figure 7, the JAB node may be mobile IAB-node 701 and the migration process may involve the migration of the DU of the IAB-node 701 from the source Fl donor-CU 703 to the target Fl donor-CU 707. The method 1010 as shown in and described with respect to figure 10b may be performed by software elements and/or hardware elements. The JAB 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 10b being performed by one or more processing units, such as the central processing unit 411.

At step 1011, an JAB-node, like the JAB-node 570 of figure 5 (701 of figure 7), receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703 of figure 7), a request for a new Fl connection (for example, a Fl connection between the TAB-node 570, 701 and a target Fl donor CU, like the donor-CU 503 of figure 5 (707 of figure 7)). The request may be the CONFIGURATION REQUEST 803 described with reference to figure 8a.

In response to receiving a request for a new Fl connection, the JAB node 570, 701 then sends, to the target Fl donor CU 503, 707, a Fl setup request requesting set up of the Fl connection (step 1018). For example, the setup request may be the SETUP REQUEST 813 described above. The Fl setup request message sent by the IAB node may include identification information for identifying the source Fl terminating donor-CU or identification information for identifying a non-F1 donor CU when a Mobile Termination, MT, of the IAB node has been migrated to the non-Ft donor CU.

The IAB node 570, 701 may identify or determine the identity of the target Fl donor CU 503, 707 in response to receiving the request for establishing a Fl connection (step 1017) and the Fl setup request is then sent to the identified target Fl donor CU. The JAB node 570, 701 may identify the target Fl donor CU based on identification information for the target Fl donor CU 503, 707, such as the address (e.g. the TNL address/IP address) of the target Fl donor CU 503, 707, received from the source Fl donor-CU 501, 703 (e.g. in the message with the CONFIGURATION REQUEST 803 or sent separately), as shown by optional step 1012. In the case where the IAB-MT 704 has been migrated to a non-Ft donor-CU, the identification information received at the IAB node may include the address of the non-Fl donor-CU in which case, the IAB node will identify the non-Fl donor-CU as the target Fl donor CU. Alternatively, if an address of the target Fl donor CU is not received from the source Fl donor-CU 501, 703, and in the case where the IAB-MT 704 has been migrated to a non-F1 donor-CU, the IAB node 570, 701 identifies or determines the identity of the target donor CU 503, 707 (e.g. following receipt of the request to establish a Fl connection) by considering/identifying the non-Ft Donor-CU as the target Fl donor-CU. For example, in this case, the IAB-node 701 has already been informed of the address (e.g. the TNL address/IP address) of target donor-CU when the IAB-MT 704 was migrated to the non-Ft Donor-CU and so can identify the address of the non-Fl Donor CU as the address of the target donor-CU.

Optionally, at step 1012, the IAB-node 570, 701 receives from the source Fl terminating donor-CU 501, 703 identification information for identifying the target Fl donor CU 503, 707. The identification information may include the address (e.g. the TNL address/IP address) of a target Fl terminating donor-CU for the new Fl connection.

Figure 10c shows example steps, in accordance with one or more embodiments of the invention, performed at an JAB node (e.g. a mobile IAB node or mIAB node) to identify the target IAB donor CU, hit an example, step 1017 of figure 10b may be performed by carrying out the steps 1013-1015, which together are referred to as step 1016, of figure 10c.

At step 1013, the IAB-node 701 determines whether identification information for identifying the target IAB donor CU for the Fl connection has been received from the source IAB donor CU by checking if an address of the target Ft terminating donor-CU for the new Fl connection has been received. If yes, at step 1015, the IAB-node 701 identifies the target Fl terminating donor-CU from the received identification information and the JAB-node sends a Fl setup request to the identified target Fl terminating donor-CU. If no, at step 1014, the IAB-node 701 identifies the non-Ft terminating donor-CU as the target Fl terminating donor-CU from the received identification information and the JAB-node sends a Fl setup request to its non-F1 terminating donor-CU (for instance donor-CU 502).

The request for a new Fl connection received at the JAB node 701 (e.g. in CONFIGURATION REQUEST 803) may include a request for one or more cells to be activated for a second logical DU entity (e.g. 1AB-DU2 706). As discussed above, the DU of the JAB node has a first logical DU entity with a Fl connection to the source Fl terminating donor-CU 703 and a second logical DU entity is activated in order to perform DU migration (e.g. to establish a new Fl connection between the target Fl donor-CU 707 and the IAB node 701). In an example, the IAB node 701 activates a second logical DU entity (e.g. IAB-DU2 706) in response to receiving the request for establishing a Fl connection (e.g. in CONFIGURATION REQUEST 803). In both these cases, the Fl setup request (e.g. message 813) is sent by the second logical DU entity. The F I setup request message sent to the target Fl terminating donor-CU 707 may include information indicating the number of cells to be activated with the activation of a second logical DU at the 1AB node. In an example, after sending the F1 setup request, the IAB node 701 receives, from the target F1 terminating donor-CU 707, a response (such as the SETUP response 814) which includes a request for one or more cells to be activated for the second logical DU entity. The response may include identification information, such as an identifier of each of the cell(s) to be activated.

The IAB node 701 may receive from the source Fl donor-CU 703 a request (e.g. a Removal Request 823 or a deactivation request in the CONFIGURATION REQUEST 803) for deactivating a first logical DU entity (e.g. LAB-DU1 705) of the DU of the JAB node 701 and in response to the request, the TAB node 701 deactivates the first logical DU entity (e.g. IAB-DUI 705).

Figure 10d is a flowchart showing an example method 1020 in accordance with one or more embodiments of the invention, performed at the target JAB donor CU for use in a migration process (or for use in part of a migration process) in which a Distributed Unit, DU, of an IAB node is migrated from one IAB topology managed by a source IAB donor CU to another JAB topology managed by the target JAB donor CU. Method 1020 is for managing, at the target Fl terminating donor-CU, the DU migration of the JAB-node toward a target JAB topology managed by the target F1 terminating donor-CU. For example, with reference to the IAB communication system shown in and described with respect to figure 5, the target JAB donor CU performing the method 1020 may be the JAB donor CU 503 which controls JAB topology 5003. The JAB node may be mobile IAB-node 570 belonging to JAB topology 5001 controlled by the 1AB donor CU 501. The migration process may involve the migration of the DU 572 of the JAB node 570 from JAB topology 5001 to JAB topology 5003. With reference to figure 7, the 1AB node may be IAB-node 701 and the migration process may involve the migration of the DU of the IAB-node 701 from the source Fl donor-CU 703 to the target F I donor-CU 707. The method 1020 as shown in and described with respect to figure 10d 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 10d being performed by one or more processing units, such as the central processing unit 411.

At step 1021, the target JAB donor CU, like JAB donor CU 503 of figure 5 (707 of figure 7), receives from an JAB node, like JAB node 570 of figure 5 (701 of figure 7), a Fl setup request for requesting set up of a Fl connection between the target JAB donor CU and the JAB node. For example, the setup request may be the SETUP REQUEST 813 described above. The H setup request message sent by the 1AB node may include identification information for identifying the source Fl terminating donor-CU or identification information for identifying anon-Fl donor CU when a Mobile Termination, MT, of the 1AB node has been migrated to the non-F1 donor CU. The Fl setup request message may include information indicating the number of cells to be activated with the activation of a second logical DU at the JAB node.

At step 1022, the target IAB donor CU 503, 707, in response to receiving the Fl setup request, sends a response (such as the SETUP response 814) to the JAB node 570, 701, which response includes a request for one or more cells to be activated for a second logical DU entity of the IAB node 570, 701. As discussed above, the DU of the IAB node has a first logical DU entity with a Fl connection to the source Fl terminating donor-CU 703 and a second logical DU entity is activated in order to perform DU migration (e.g. to establish a new F1 connection between the target F1 donor-CU 707 and the JAB node 701). The response may include identification information identifying each of the one or more cells to be activated (e.g. an identifier for each of the cell(s) to be activated). The target JAB donor CU 503, 707 may send, to the source IAB donor CU 501, 703, identification information identifying each of one or more new cells that have been activated at the second logical DU entity of the DU of the 1AB node 570, 701.

In an example, the target Fl donor-CU 707 may receive, from the source Fl terminating donor-CU 703, a handover request for requesting handover, from the source F 1 terminating donor-CU 703 to the target Fl donor-CU 707, of one or more User Equipment, UE, (such as UE 708) served by the JAB node 701 and for identifying one or more target cells (e.g. candidate target cells) for each UE. When the target H donor-CU 707 determines the handover of the one or more UE can be accepted, the target Fl donor-CU 707 sends, to the source Fl terminating donor-CU 703, a handover acknowledgement indicating handover of the one or more UE has been accepted and identifying a target cell for each UE. The handover acknowledgement may also include configuration information for configuring each of the one or more UE for the respective target cell. The Handover procedure 730 discussed above may be performed for these steps.

After handover of the one or more UE 708 to the target Fl donor-CU 707 is completed and when a Mobile Termination, MT, (e.g. IAB-MT 704) of the JAB node 701 has been migrated to a non-F1 donor CU, the target Fl donor-CU 707 may send, to the non-Fl donor-CU, a traffic migration request (e.g. message 913) for requesting traffic migration for the traffic associated with the JAB node that was routed via one or more paths in an IAB topology managed by the non-Fl donor CU.

Thus, by sending a request to the TAB node for establishing a Fl connection between the IAB node and the target IAB donor CU, the source F 1 donor CU (e.g. source IAB donor CU) facilitates DU migration of an IAB-node with or without (multiple) MT migration(s).

Furthermore, in response to receiving the request to establish a Fl connection, the JAB node can identify (e.g. via identification information sent by the source donor CU or when no identification information is sent by the source donor CU, by determining a non-Fl donor CU is the target donor CU) the target donor CU to enable the handover of UEs sewed by the JAB-node to the target donor CU.

The determination that the DU of an IAB node is to be migrated may be triggered by an event. What event or events trigger the determination that the DU of an 1AB node is to be migrated may be left to implementation. For example, the decision for DU migration may be based on the detection of a MT migration from a first TAB topology toward a second JAB topology, and on a known (predefined) trajectory of the IAB-node that indicates to the source Fl donor-CU that the MT will be migrated later to a third JAB topology. In this case, to avoid signaling messages for DU migration/UEs handover toward the second IAB topology, the DU is directly migrated toward the third JAB topology. Another triggering event may be when the processing load level is 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 In other words and as a summary, the triggering events and the decision process for a Fl terminating donor CU to execute the mobile IAB-DU (mIAB-DU) migration for a mobile IAB-node may be left to implementation. Besides, for flexible IAB network management, it should be allowed to migrate the mIAB-DU towards a target Fl terminating donor-CU different from the non-Fl terminating donor-CU serving the co-located mobile JAB-MT (mIAB-MT).

Thus, the JAB-DU of a mobile JAB-node may be migrated towards a target Fl terminating donor-CU different from the non-Fl terminating donor-CU serving the co-located IA B-MT.

Then, when the H donor CU serving the m IA B-DU decides whether to execute mIAB-DU migration, it may request the mobile JAB-node to activate a second logical DU to be sewed by a target Fl donor-CU identified in the request.

For instance, the Fl donor-CU may trigger the gNB-CU Configuration Update procedure to request the mobile JAB-node to setup a new Fl connection with an identified target Fl donor-CU. Then, the activated logical DU triggers a Fl setup procedure with the target Fl donor-CU. In case the request from the Fl donor-CU does not identify a target Fl donor-CU, then the activated logical DU triggers a F] setup procedure with the non-Fl terminating donor-CU of the mobile IAB-node.

Thus, when requested by its serving Fl donor CU to setup a new Fl connection, a mobile JAB-node may execute a F I setup procedure with the target Fl donor-CU indicated in the request. In the absence of such indication, the mobile IAB-node executes the Fl setup procedure with the non-Fl terminating donor-CU.

To trigger the handoyer of UEs sewed by the mobile JAB-node during the mIAB-DU migration, the target Fl donor-CU may inform the source H donor-CU about the activation of new cell(s) in the second logical DU of the mobile TAB-node. For this purpose, the target Fl donor-CU may execute the NG-RAN node configuration update procedure with the source Fl donor-CU. Once informed, the source Fl donor-CU can send a handover command to the UEs sewed by the migrating mobile IAB-node Thus, the NG-RAN node configuration update procedure may be used by the target Fl terminating donor-CU of a mobile JAB-node to inform the source Fl terminating donor-CU about the 1D(s) of the cell(s) served by the second logical DU of the mobile JAB-node.

While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed 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 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 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.

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 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 (I) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave. Data storage media 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 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 are included in the definition of medium. It should be understood, however, 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 of the above should also be included within the scope of computer-readable media.

Claims

Claims A method for use in a migration process in which a Distributed Unit, DU, of an Integrated Access Backhaul, JAB, node is migrated from one JAB topology managed by a source IAB donor Central Unit, CU, to another IAB topology managed by a target IAB donor CU, the method at the source JAB donor CU comprising: determining the DU of the JAB node is to be migrated from the one JAB topology of the source IAB donor CU to the another IAB topology of the target IAB donor CU; sending, to the JAB node, a request for establishing a Fl connection between the JAB 10 node and the target JAB donor CU.
2. The method of claim 1, further comprising sending, to the IAB node, identification information for identifying the target JAB donor CU.
3. The method of claim 2, wherein the identification information for identifying the target JAB donor CU for the Fl connection includes an address associated with the target JAB donor CU.
4 The method of any one of claims Ito 3, further comprising, sending, to the IAB node, information indicating a number of cells to be activated at a second logical DU entity of the DU of the JAB node.
S. The method of any one of claims I to 4, further comprising receiving, from the target JAB donor CU, identification information identifying each of one or more new cells that have 25 been activated at a second logical DU entity of the DU of the JAB node.
6. The method of claim any one of the preceding claims, further comprising: sending, to the target JAB donor CU, a handover request for requesting handover, from the source JAB donor CU to the target JAB donor CU, of one or more User Equipment, UE, served by the IAB node and for identifying one or more candidate target cells for each UE.
7. The method of claim 6, further comprising: in response to receiving a handover acknowledgement from the target JAB donor CU indicating handover of the one or more UE has been accepted and identifying a target cell for each UE, sending to the IAB node, configuration information for configuring each of the one or more LIE for the respective target cell
8. The method of claim 6 or claim 7, further comprising: after handover of the one or more UE to the target IAB donor CU is completed, sending, to the JAB node, a request for deactivating a first logical DU entity of the DU of the JAB node having a Fl connection with the source JAB donor CU.
9. The method of any one of claims 6 to 8, further comprising: after handover of the one or more UE to the target JAB donor CU is completed and when a Mobile Termination, MT, of the IAB node has been migrated to a non-F1 donor CU, sending, to the non-F1 donor-CU, a traffic migration request for requesting traffic release for the traffic associated with the JAB node and that was routed via one or more paths in an JAB topology managed by the non-Fl donor CU
10. The method of any one of the preceding claims, wherein determining the DU of the 1AB node is to be migrated comprises determining the DU of the 1AB node is to be migrated in response to determining a migration of a MT of the JAB node toward a new parent JAB node has been completed.
11. A method for use in a migration process in which a Distributed Unit, DU, of an Integrated Access Backhaul, JAB, node is migrated from one JAB topology managed by a source IAB donor Central Unit, CU, to another IAB topology managed by a target 1AB donor CU, the method at the JAB node comprising: receiving, from the source JAB donor CU, a request for establishing a Fl connection between a target 1AB donor CU and the IAB node; sending, to the target JAB donor CU, a Fl setup request for requesting set up of the Fl connection.
12. The method of claim 11, further comprising: identifying the target JAB donor CU in response to receiving the request for establishing a Fl connection, wherein sending comprises sending the Fl setup request to the identified target JAB donor CU.
13 The method of claim 11 or claim 12, further comprising receiving, from the source lAB donor CU, identification information for dentifying the target JAB donor CU for the Fl connection.
14. The method of claim 12 and claim 13, wherein identifying the target JAB donor CU comprises identifying the target JAB donor CU from the received identification information.
The method of claim 12, wherein identifying comprises: determining whether identification information for identifying the target JAB donor CU for the H connection has been received from the source IAB donor CU; in response to determining that identification information for identifying the target IAB donor CU for the Fl connection has been received from the source JAB donor CU, identifying the target IAB donor CU from the received identification information.
16 The method of claim 12, wherein identifying comprises: determining whether identification information for identifying the target IAB donor CU for the Fl connection has been received from the source JAB donor CU; in response to determining that identification information for identifying the target IAB donor CU for the Fl connection has not been received from the source IAB donor CU and that a Mobile Termination, NIT, of the JAB node has been migrated to a non-Ft donor CU, identifying comprises identifying the non-F1 donor CU as the target JAB donor CU, wherein sending comprises sending, to the identified non-Fl donor CU as the target JAB donor CU, the Fl setup request.
17 The method of claim 13, further comprising: after receiving the request for establishing a Fl connection, determining whether identification information for identifying the target IAB donor CU for the Fl connection has been received from the source IAB donor CU; wherein in response to determining that identification information for identifying the target JAB donor CU for the Fl connection has been received, sending comprises sending, to the target JAB donor CU identified by the received identification information, the Fl setup request.
18 The method of claim 11 or claim 12, further comprising: after receiving the request for establishing a Fl connection, determining whether identification information for identifying the target IAB donor CU for the Fl connection has been received from the source JAB donor CU; wherein in response to determining that identification information for identifying the target JAB donor CU for the Fl connection has not been received from the source JAB donor CU and that a Mobile Termination, MT, of the JAB node has been migrated to a non-Fl donor CU, identifying the non-F1 donor CU as the target IAB donor CU, wherein sending comprises sending, to the identified non-Fl donor CU as the target IAB donor CU, the Fl setup request.
19 The method of any one of claims 13 to 15 or claim 17, wherein the identification information for identifying the target JAB donor CU for the Fl connection includes an address associated with the target JAB donor CU
20. The method of any one of claims 11 to 19, wherein the DU of the JAB-node comprises a first logical DU entity having a Fl connection with the source IAB donor CU, the method further comprising receiving from source JAB donor CU, information indicating a number of cells to be activated at a second logical DU entity of the DU of the IAB node.
21. The method of any one of claims 11 to 20, wherein the DU of the JAB-node comprises a first logical DU entity having a Fl connection with the source JAB donor CU, wherein the request for establishing a Fl connection includes a request for one or more cells to be activated for a second logical DU entity, wherein sending comprises sending, by the second logical DU entity to the target JAB donor CU, the Fl setup request.
22. The method of any one of claims 11 to 20, wherein the DU of the JAB-node comprises a first logical DU entity having a Fl connection with the source TAB donor CU, the method further comprising: in response to receiving the request for establishing a Fl connection, activating a second logical DU entity, for establishing the Fl connection with the target JAB donor CU, wherein sending comprises sending, by the second logical DU entity to the target JAB donor CU, the Fl setup request.
23 The method of any one of claims 11 to 20 or claim 22, further comprising: after sending the Fl setup request, receiving, from the target 1AB donor CU, a response, the response including a request for one or more cells to be activated for the second logical DU entity; activating the one or more cells based on the received response.
24. The method of claim 23, wherein the response includes identification information identifying each of the one or more cells to be activated.
The method of any one of claims 20 to 24, further comprising: receiving, from the source IAB donor CU, a request for deactivating the first logical DU entity of the DU of the JAB node having a Fl connection with the source JAB donor CU
26 The method of claim 25, further comprising: in response to receiving the request for deactivating the first logical DU entity, deactivating the first logical DU entity.
27. The method of any one of claims 11 to 26, wherein sending the Fl setup request comprises sending a H setup request message for requesting set up of the Fl connection, wherein the Fl setup request message includes identification information for identifying the source JAB donor CU or identification information for identifying a non-Fl donor CU when a Mobile Termination, MT, of the IAB node has been migrated to a non-F1 donor CU.
28. The method of any one of claims 11 to 27, wherein sending the F1 setup request comprises sending a Fl setup request message for requesting set up of the Fl connection, wherein the Fl setup request message includes information indicating the number of cells to be activated with the activation of a second logical DU at the JAB node.
29. A method for use in a migration process in which a Distributed Unit, DU, of an Integrated Access Backhaul, JAB, node is migrated from one JAB topology managed by a source JAB donor Central Unit, CU, to another JAB topology managed by a target JAB donor CU, the method at the target JAB donor CU comprising: receiving, from the JAB node, a Fl setup request for requesting set up of a Fl connection between the target JAB donor CU and the JAB node; sending, to the 1AB node, a response, the response including a request for one or more cells to be activated for a second logical DU entity of the JAB node.
30. The method of claim 29, wherein receiving the Fl setup request comprises receiving a Fl setup request message for requesting set up of the F1 connection, wherein the F1 setup request message includes identification information for identifying the source IAB donor CU or identification information for identifying a non-Fl donor CU when a Mobile Termination, MT, of the IAB node has been migrated to a non-Fl donor CU.
31. The method of claim 29 or claim 30, wherein receiving the F I setup request comprises receiving a Fl setup request message for requesting set up of the Fl connection, wherein the Fl setup request message includes information indicating the number of cells to be activated with the activation of a second logical DU at the JAB node.
32. The method of any one of claims 29 to 31, further comprising sending, to the source JAB donor CU, identification information identifying each of one or more new cells that have been activated at a second logical DU entity of the DU of the IAB node.
33. The method of any one of claims 29 to 32, wherein the response includes identification information identifying each of the one or more cells to be activated.
34 The method of any one of claims 29 to 33, further comprising: receiving, from the source JAB donor CU, a handover request for requesting handover, from the source IAB donor CU to the target IAB donor CU, of one or more User Equipment, UE, sewed by the JAB node and for identifying one or more candidate target cells for each UE, sending, to the source JAB donor CU, a handover acknowledgement indicating handover of the one or more UE has been accepted by the target IAB donor CU and identifying a target cell for each UE.
35. The method of claim 34, further comprising: after handover of one or more UE to the target JAB donor CU is completed and when a Mobile Termination, MT, of the JAB node has been migrated to a non-Fl donor CU, sending, to the non-Fl donor-CU, a traffic migration request for requesting traffic migration for the traffic associated with the JAB node and that was routed via one or more paths in an JAB topology managed by the non-Fl donor CU.
36. The method of any one of the preceding claims, wherein the JAB node is a mobile IAB node.
37. An apparatus for an Integrated Access and Backhaul, JAB, node for an JAB communication system, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims 11 to 26 and claim 36.
38. An apparatus for an Integrated Access and Backhaul, JAB, donor Central Unit, CU, for an JAB communication system, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims Ito 10, and claims 29 to 36.
39. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 36
40. A computer-readable medium carrying a computer program according to claim 39.