Migration of nodes in IAB communication systems

Abstract

A method and apparatus are disclosed for use in a migration process in which a distributed unit, DU, of an integrated access backhaul, IAB node migrates from one IAB topology managed by a source IAB donor central unit, CU, to another IAB topology managed by a target IAB donor CU. The method includes, at a source IAB donor CU, determining that a DU that is an IAB node is to migrate from one IAB topology of the source IAB donor CU to another IAB topology of a target IAB donor CU; a request to establish an F1 connection between the IAB node and the target IAB donor CU is sent to the IAB node. The method comprises, at an IAB node: receiving a request from a source IAB donor CU for establishing an F1 connection between a target IAB donor CU and the IAB node; and sending an F1 setting request for requesting to set the F1 connection to the target IAB donor CU.

Description

Technical Field

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

[0002] Wireless communication systems are widely deployed to address a wide range of applications from mobile broadband, massive machine type communication to ultra-reliable low latency communication (URLLC). Such systems allow multiple user equipments (UEs) 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) via one or more base stations. Traditionally, base stations are wired-connected (e.g., via optical fibers) to a core network, thus forming an intermediate network called backhaul (BH).

[0003] Examples of such wireless multi-access communication systems include systems based on the 3rd Generation Partnership Project (3GPP-RTM) standards such as the 4th Generation (4G) Long Term Evolution (LTE) or the more recent 5th Generation (5G) New Radio (NR) system, or systems based on the IEEE 802.11 standards such as Wi-Fi.

[0004] Due to the increasing number of users and higher throughput requirements, the demand for network densification has increased.

[0005] Facing the problems of high deployment cost and time of a wired backhaul network with network densification, 3GPP proposed wireless backhaul, also known as integrated access and backhaul (IAB), starting from Release 16 for 5G NR, where instead of optical fibers, a part of the wireless (i.e., radio) spectrum is used for the backhaul connection of base stations. The wireless backhaul communication (between base stations) can use the same radio resources as the access communication (between a base station and a UE).

[0006] IAB has proven to be a competitive alternative to fiber-based backhaul in dense areas or hard-to-cover areas, as IAB allows for scalable and fast installation without the burden of cabling base stations.

[0007] The IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. However, it is known that millimeter waves suffer strong attenuation of signal strength under some weather conditions (rain, fog), and are blocked in cases where obstacles are in the path between the transmitter and the receiver.

[0008] To manage these potential radio link failures, topological redundancy can be provided within the IAB framework, in which multiple data paths are established between an IAB base station directly connected to the core network (also referred to as the "IAB donor") and an IAB base station serving the UE (also referred to as the "access IAB node" used by the UE). Several intermediate IAB base stations (also called IAB nodes) can be involved in each of several paths between the IAB donor and the access IAB node, thereby forming alternative data paths within the multi-hop IAB topology.

[0009] In addition, 3GPP has been considering donor - to - donor redundancy, in which an IAB node called a border IAB node can access two different parent nodes connected to two different IAB donors, where each IAB donor manages a different IAB topology (also referred to as an IAB network). Thus, the border IAB node can route packets from the first IAB topology managed by the first IAB donor to the second IAB topology managed by the second IAB donor even if it belongs to a single IAB topology (i.e., belongs to a single IAB donor for configuration and management). The advantage of such donor - to - donor redundancy is the ability of the first IAB donor to offload by routing some of its packets via the second IAB topology, thereby alleviating congestion problems or overcoming radio link failure problems that may occur in the first IAB topology.

[0010] There are other scenarios where an IAB node becomes a border node. For example, in the case of a partial migration of an IAB node determined by the IAB donor, where the mobile terminal (MT) of the IAB node becomes connected to a single parent IAB node belonging to another IAB topology controlled by another IAB donor. This scenario can also occur in the case of an IAB node that has experienced a radio link failure (RLF) and has been recovered through a parent IAB node belonging to another IAB topology. In those cases, the migrated IAB node and its potential one or more descendant IAB nodes still belong to the initial IAB topology, and such a partial migration can be called an MT migration. To ensure that traffic can be routed through other IAB topologies, traffic migration should follow the MT migration, in which traffic related to the border node and its descendant IAB nodes is routed through other IAB topologies until the border node (i.e., the migrated IAB node).

[0011] A stationary IAB node should only require a single MT relocation. In practice, the backhaul link (defined between two consecutive IAB nodes in the wireless backhaul) may experience radio failures due to fluctuations in radio conditions, and for a non-mobile IAB node, this should be a temporary situation with a possible link recovery after some time. Thus, such a stationary IAB node should not be required to perform multiple MT relocations within the same IAB topology or towards another IAB topology, and the transmission and handling of multiple protocol messages can be avoided. For the same reason, the relocation of the distributed unit (DU) of the IAB node should not be required for a stationary node, leaving the control of the IAB node to the new IAB donor. Additionally, note that such a DU relocation, which can be referred to as a full relocation, also involves the handover of UEs served by the migrating mobile IAB node.

[0012] Urban environments are typically characterized by a high density of users and the presence of a large number of vehicles (e.g., public / private passenger transportation, freight transportation, food trucks, etc.). Some of these vehicles (e.g., buses, trams, or trains) can have predictable routes and a large number of co-located UEs (i.e., the devices of the passengers). 3GPP is considering that by installing on-board base stations (or base station elements) that will act as mobile repeaters on these vehicles, such vehicles can provide opportunities to increase network coverage and connectivity to UEs inside the vehicle or even to UEs near the vehicle. These mobile repeaters will rely on 5G wireless backhaul (usually IAB, or integrated access and backhaul) for connection to a fixed donor device.

[0013] Thus, based on the fixed IAB foundation of Releases 16 and 17, 3GPP is now considering mobile IAB systems and architectures as part of the Release 18 framework to address scenarios focused on mobile IAB nodes mounted on vehicles (such as buses, trains, taxis, etc.). In such scenarios, the mobile IAB node can be referred to as a vehicle-mounted relay (VMR), thus providing 5G coverage / capacity to the on-board and / or surrounding UEs.

[0014] The technical benefits of using a VMR include the ability of the VMR to provide good radio link conditions to nearby UEs. Additionally, compared to solutions that use UEs as relays (i.e., sidelink relay solutions), the IAB nodes mounted on vehicles are expected to have better RF / antenna capabilities and less stringent power / battery constraints compared to relay UEs.

[0015] For a mobile IAB node, performing multiple MT migrations or DU migrations may be worthwhile because the connection to the parent IAB node belonging to the first IAB topology may not occur again for a long time as the mobile IAB node moves around, or may never occur again if the mobile IAB node moves away from the parent IAB node. Additionally, for flexible IAB network management, MT and DU migrations should be de-correlated, which means that the DU migration for an IAB node can occur before or after one or several MT migrations of that IAB node. Additionally, the DU migration for an IAB node can be towards an IAB donor different from the IAB donor associated with the MT of that IAB node.

[0016] Therefore, some new mechanisms are needed to provide such flexibility by supporting DU migrations of an IAB node towards any other donor CU that are de-correlated from (one or more than one) MT migrations of the IAB node. Summary of the Invention

[0017] According to a first aspect of the present invention, there is provided a method used in a migration process, in which a distributed unit (DU) of an integrated access backhaul node, i.e., an IAB node, migrates from one IAB topology managed by a source IAB donor central unit, i.e., a source IAB donor CU, to another IAB topology managed by a target IAB donor CU. The method at the source IAB donor CU includes: determining that the DU of the IAB node is to migrate from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU; sending a request to the IAB node for establishing an F1 connection between the IAB node and the target IAB donor CU.

[0018] According to a second aspect of the present invention, there is provided a method used in a migration process at an IAB node as described in the appended claims, in which the DU of the IAB node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU.

[0019] According to a third aspect of the present invention, there is provided a method used in a migration process at a target IAB donor CU as described in the appended claims, in which the DU of the IAB node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU.

[0020] Thus, by sending a request for establishing an F1 connection between the IAB node and the target IAB donor CU to the IAB node, the source F1 donor CU (e.g., the source IAB donor CU) facilitates the DU migration of the IAB node with or without (multiple) MT migrations. Further, in response to receiving the request for establishing the F1 connection, the IAB node can identify the target donor CU (e.g., via the identification information sent by the source donor CU, or by determining that the non-F1 donor CU is the target donor CU in the case where the source donor CU does not send the identification information), so that the UE served by the IAB node can be handed over to the target donor CU. The non-F1 (terminating) donor CU is also referred to as the RRC (terminating) donor CU.

[0021] According to a fourth aspect of the present invention, there is provided an apparatus for an IAB node used in an IAB communication system as described in the appended claims.

[0022] According to a fifth aspect of the present invention, there is provided an apparatus for an IAB donor CU (i.e., the source IAB donor CU or the target IAB donor CU) used in an IAB communication system as described in the appended claims.

[0023] According to another aspect, there is provided a method used in a migration process, in which a distributed unit (DU) of an integrated access backhaul (IAB) node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU. The method includes: determining by the source IAB donor CU that the DU of the IAB node is to migrate from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU; sending by the source IAB donor CU a request for establishing an F1 connection between the IAB node and the target IAB donor CU to the IAB node; after receiving the request for establishing the F1 connection, sending by the IAB node an F1 setup request for requesting to set up the F1 connection to the target IAB donor CU; after receiving the F1 setup request for requesting to set up the F1 connection from the IAB node, sending by the target IAB donor CU a response to the IAB node, the response including a request for one or more cells to be activated for a second logical DU entity for the IAB node.

[0024] More exemplary features of the present invention are described in other independent claims and dependent claims.

[0025] Hereinafter, reference will be made to sources and targets for different elements such as nodes / topologies, etc. However, it will be understood that, alternatively, the terms first and second can be used instead of sources and targets.

[0026] Any feature in one aspect of the present invention can be applied to other aspects of the present invention in any suitable combination. In particular, method aspects can be applied to device / apparatus / unit aspects and vice versa.

[0027] Furthermore, features implemented in hardware can be implemented in software and vice versa. Any reference to software features and hardware features herein should be interpreted accordingly. For example, according to other aspects of the present invention, there is provided a computer program comprising instructions and a computer-readable storage medium carrying the computer program, the instructions causing one or more processing units to perform the method of any of the above aspects or examples when the program is executed by the one or more processing units. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The different aspects of the present invention will now be described, by way of example only and with reference to the following drawings, in which:

[0029] Figure 1 is a schematic diagram of a communication system that can implement the present invention according to one or more embodiments;

[0030] Figure 2 (a) of Figure 2 and (b) of schematically illustrate the stacks of some protocol layers involved in IAB operation;

[0031] Figure 3 is a schematic diagram illustrating the format of a BAP protocol data unit (PDU) or packet;

[0032] Figure 4 is a block schematic diagram of an example wireless communication device according to an embodiment of the present invention;

[0033] Figure 5 is a schematic diagram of an example IAB communication system (or IAB network system) that can implement the embodiments and examples of the present invention;

[0034] Figure 6 is a schematic simplified diagram of an example of an IAB node architecture enabling DU migration from a source IAB topology to a target IAB topology;

[0035] Figure 7 is a simplified diagram of an example message flow for performing DU migration of an IAB node according to one or more embodiments of the present invention, the DU migration including handover of UEs served by the migrating IAB node;

[0036] Figure 8a is a simplified diagram of an example message flow for performing the activation of a logical DU according to one or more embodiments of the present invention;

[0037] Figure 8b is a simplified diagram of an example message flow illustrating the process for setting up a logical DU;

[0038] Figure 8c is a simplified diagram of an example message flow illustrating the process for removing a logical DU;

[0039] Figure 8d is a simplified diagram of an example message flow illustrating the process used by a logical DU to inform a RAN node CU of a configuration change;

[0040] Figure 9a is a simplified diagram of an example message flow illustrating the process used by a RAN node CU to report the activation of one or more cells to another RAN node CU;

[0041] Figure 9b is a simplified diagram of an example message flow illustrating the process used by a RAN node CU to manage transmission migration in coordination with another RAN node CU;

[0042] Figure 10a is a flowchart of an example method for managing DU migration of an IAB node towards a target IAB topology at a source F1-terminating donor CU of the IAB node according to an embodiment of the present invention;

[0043] Figure 10b is a flowchart of an example method for managing DU migration of an IAB node towards a target IAB topology at the IAB node according to an embodiment of the present invention;

[0044] Figure 10c is a flowchart showing example steps for identifying a target IAB donor CU at an IAB node according to one or more embodiments of the present invention;

[0045] Figure 10d is a flowchart of an example method for managing DU migration of an IAB node towards a target IAB topology managed by a target IAB donor CU at the target IAB donor CU according to an embodiment of the present invention. Detailed implementation manners

[0046] Figure 1Exemplary 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 one or more mobile IAB nodes. Although embodiments and examples of the present invention will be described hereinafter with respect to a 5G NR system, it will be understood that the present invention is not intended to be limited to a 5G NR system and can be used in any wireless communication system having mobile base stations. In particular, the following description mainly uses 5G-specific terms, but it should be understood that such terms are also applicable to elements or processes performing equivalent functions in other communication systems.

[0047] System 100 includes a plurality of UEs (user equipments) 132, 133, 131 and 134, a remote core network 110, a master base station 120, and two integrated access and backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes), and a mobile integrated access and backhaul (IAB) station 123 mounted on a vehicle 105 (e.g., a bus, a train, a taxi, a car, etc.).

[0048] The master base station 120 (also referred to as IAB donor 120) is connected to the core network 110 via a wired link 101 (preferably an optical fiber or any other wired component). In embodiments and examples of the present invention, as defined in the 3GPP TS 38.300 v17.2.0 specification document, the IAB donor 120 is a 5G NR gNB with additional functionality supporting IAB features.

[0049] To extend the network coverage of the IAB donor 120 and reach remote UEs 132, 133, and 131, the operator has installed IAB stations 121 and 122 (also referred to as IAB nodes 121 and 122). By acting as relay nodes between the IAB donor 120 and UEs 132 and 133, the IAB nodes 121 and 122 allow overcoming the reachability problems caused by the presence of a building 108, which is an obstacle to the propagation of radio waves and thus to the direct attachment and further communication between the UE and the IAB donor 120. This is especially true when the communication between the IAB donor 120 and UEs 132 and 133 operates at millimeter wave frequencies that are highly sensitive to shadowing phenomena.

[0050] The IAB donor 120 also serves UE 134, which is directly connected to the IAB donor 120.

[0051] The mobile IAB station 123 (also referred to as the mobile IAB node 123 or mIAB node 123) is an IAB node equipped on the vehicle 105 and provides network coverage and capacity expansion, thereby allowing the IAB donor 120 to reach the remote UEs (such as the remote UE 135), as well as the surrounding UEs or the UEs near the IAB node 123 (such as the remote UE 136).

[0052] The IAB donor 120 and the IAB nodes 121, 122, and 123 thus form a backhaul network or an IAB network or an IAB topology that accommodates the UEs 132, 133, 131, 134, 135, and 136. The terms IAB network and IAB topology will be used interchangeably hereinafter.

[0053] The specifications of integrated access and backhaul (IAB) are extended in several 3GPP standard documents, including:

[0054] - TS 38.300 RAN architecture (V17.2.0),

[0055] - TS 38.321 MAC protocol (V17.2.0),

[0056] - TS 38.331 Radio Resource Control (RRC) protocol (V17.2.0),

[0057] - TS 38.340 Backhaul adaptation protocol layer (V17.2.0),

[0058] - TS 38.401 RAN architecture (V17.2.0),

[0059] - TS 38.423 Xn application protocol (V17.2.0),

[0060] - TS 38.473 F1 application protocol (V17.2.0).

[0061] Since the IAB donor 120 and the IAB nodes 121, 122, and 123 are respectively connected to the UEs 134, 131, 132, 133, 135, and 136, they are considered as access IAB nodes for the UEs to which they are respectively connected.

[0062] The IAB donor 120 is a logical node that provides NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and the connected one or more donor distributed units (DU or gNB-DU functionality). The IAB donor CU or donor CU (hereinafter also referred to as the IAB donor CU (IAB-donor CU / IAB donor CU)) hosts higher layer protocols (such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, etc.) for controlling the operation of one or more DUs, and each of the one or more IAB donor DUs or donor DUs (hereinafter also referred to as the IAB donor DU (IAB-donor DU / IAB donor DU)) includes lower layer protocols such as RLC, MAC, and physical layer protocols. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be located at a distance from each other, or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. Its purpose is to terminate the NR access interface to the UE and the next-hop IAB node, and to terminate the F1 protocol to the IAB donor gNB-CU functionality, as shown in (a) of Figure 2 and Figure 2 (b) as described below.

[0063] The IAB nodes that can serve multiple radio sectors are connected to the IAB donor 120 via a one-hop or multi-hop wireless backhaul through one or more intermediate IAB nodes. They form a directed acyclic graph (DAG) topology with the IAB donor at the root.

[0064] Each IAB node consists of an IAB-DU (IAB distributed unit) and an IAB-MT (IAB mobile terminal). The gNB-DU functionality on the IAB node is also referred to as the IAB-DU and allows a downstream (towards the UE) connection to the next-hop IAB or to the UE. The IAB-MT functionality includes, for example, physical layer, layer 2, RRC, and non-access stratum (NAS) functions to connect to the gNB-DU of the upstream IAB node (including the IAB donor 120, in which case, connecting to the IAB donor gNB-DU and thus to the core network 110 (for initialization, registration, and configuration, for example)).

[0065] In this DAG topology, the neighbor nodes on the IAB-DU interface are called child nodes, and the neighbor nodes on the IAB-MT interface are called parent nodes. The direction towards the child nodes is also referred to as downstream, while the direction towards the parent nodes is called upstream.

[0066] The IAB donor 120 (e.g., the IAB donor CU) performs centralized resource, topology, and routing management for the entire IAB topology. This includes: configuring the IAB nodes according to the network topology for proper routing of data packets, for example.

[0067] Figure 2 (a) of and Figure 2 (b) of schematically illustrate the stacks of some protocol layers involved in IAB operation.

[0068] The F1 interface supports the exchange of signaling information (e.g., control traffic) between endpoints and the transmission of data to each endpoint (e.g., user traffic transmission). From a logical perspective, the F1 interface is a point-to-point interface between endpoints.

[0069] In 5G NR, F1-C is a functional interface in the control plane (CP) between the IAB donor CU and the IAB node DU (e.g., of IAB node 2) and between the IAB donor CU and the IAB donor DU. F1-U is a functional interface in the user plane (UP) for the same cells. F1-C and F1-U are shown by the reference numeral 212 in Figure 2 (a) of. In this example, F1-U and F1-C are carried over two backhaul hops (from the IAB donor to IAB node 1 and then from IAB node 1 to IAB node 2).

[0070] In the user plane, the box 210 at the IAB donor CU and the IAB node DU refers to the GTP-U layer, and the box 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. GTP-U tunnels are used to carry encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (for more details, refer to 3GPP TS29.281), here the boxes 210 at the IAB donor CU and the IAB node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol that provides a best-effort datagram service and is suitable for use with the IP protocol.

[0071] In the control plane, the box 210 indicates the F1AP (F1 Application Protocol) layer, and the box 211 indicates the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS 38.473 and TS 38.401) provides signaling services or UE association services between the IAB donor CU and the IAB node DU. These services are, for example, initialization, configuration, etc. The well-known SCTP layer uses congestion control to provide reliable sequential transmission of messages.

[0072] F1-U and F1-C rely on the IP transport layer between the IAB donor CU and the IAB node DU as defined in 3GPP TS 38.401.

[0073] When the IAB donor CU is far from the IAB donor DU, or in the case of local virtual instantiation where the IAB donor CU and the IAB donor DU are on the same physical machine, the transmission between the IAB donor DU and the IAB donor CU also uses the IP transport layer over various media (e.g., wires or optical fibers). The IAB-specific transmission between the IAB donor CU and the IAB donor DU is specified in 3GPP TS 38.401.

[0074] Figure 2 L1 and L2 in (a) respectively represent the transport layer and the physical layer suitable for the medium in use.

[0075] The IP layer can also be used for non-F1 traffic, such as operations, administration, and maintenance traffic, etc.

[0076] On the wireless backhaul, the IP layer itself is carried on the Backhaul Adaptation Protocol (BAP) sublayer, which enables routing through multiple hops. The BAP sublayer is specified in TS 38.340.

[0077] Route the IP traffic of the IAB-DU through the wireless backhaul via the BAP sublayer. In the downstream direction, the upper-layer packets are encapsulated by the BAP sublayer at the IAB donor DU, thereby forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity of the intermediate IAB nodes (if any) (and the corresponding BAP entities in the IAB-DU and IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer at the destination IAB node (if the upper-layer packet in the BAP packet is intended for a UE, the destination IAB node can be an access IAB node).

[0078] In the upstream direction, the upper-layer packets are encapsulated by the BAP sublayer at the initiating IAB node (if the upper-layer packet comes from a UE, the initiating IAB node can be an access IAB node), thereby forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layer of the intermediate IAB nodes (if any) (and the corresponding BAP entities in the IAB-DU and IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer at the IAB donor DU.

[0079] On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packet and is set by the initiating IAB node (e.g., a network node in the IAB network that generates the BAP packet) or the BAP sublayer of the transmitting IAB donor DU. Figure 3 Illustrate the format of the BAP data protocol data unit (PDU) or packet. This format is specified in paragraph 6.2 of the standardized version of 3GPP TS38.340 version 17.2.0.

[0080] The payload 307 is typically an IP packet. The header 30 includes fields 301 to 306. Field 301 (referred to as the D / C field) is a boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302 to 304 are 1-bit reserved fields, preferably set to 0 (ignored by the receiver).

[0081] Fields 305 and 306 together indicate the BAP routing ID of the BAP packet. The BAP address field 305 (also referred to as the DESTINATION field) is in the leftmost 10 bits, while the BAP path identification field 306 (also referred to as the PATH field) is in the rightmost 10 bits.

[0082] Field 305 carries the BAP address of the destination IAB node or IAB donor DU of the BAP packet (i.e., at the BAP sublayer). For routing purposes, each IAB node and IAB donor DU in the IAB network (by the IAB donor CU of the IAB network) is configured with a designated and unique BAP address. Field 306 carries the path ID for identifying the routing path that the BAP packet should follow in the IAB topology to reach the destination. For routing purposes, (by the IAB donor CU of the IAB network) the routing paths (including their path IDs) are configured in the IAB nodes of the IAB network.

[0083] When a packet arrives at the BAP layer from the upper layer, a BAP header is added to the packet, and when the packet reaches its destination node, the BAP header is stripped by the BAP layer. The selection of the BAP routing ID of the packet is configured by the IAB donor CU.

[0084] For example, when a BAP packet is generated by a node (i.e., by the IAB donor DU for downstream transmission or by the initiator for upstream transmission, which can be an access IAB node in the case where the upper layer packet comes from a UE), a BAP header with a BAP routing ID is constructed by that node according to the configuration table defined in 3GPP TS 38.340. This table is referred to as the downlink traffic to routing ID mapping configuration table in the IAB donor DU, or the uplink traffic to routing ID mapping configuration table in the initiating IAB node. In an intermediate IAB node, the BAP header fields have been specified in the BAP packet for forwarding.

[0085] As described above, these configuration tables that define the BAP paths (and thus take into account the routing policies of the IAB network topology and the configuration of the IAB nodes) are typically defined by the IAB donor CU and transmitted to the IAB nodes to configure these IAB nodes.

[0086] To transmit messages over the 5G NR radio medium, three additional sublayers (RLC, MAC, and PHY) are implemented at each IAB node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconstruction. The RLC sublayer is also responsible for requesting retransmission of lost packets. The RLC layer is further described in TS38.322. The MAC (Medium Access Control) protocol sublayer is responsible for selecting available transmission formats for user data and for mapping logical channels to transport channels. MAC also disposes of a part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the transmitter or sender side, MAC encapsulates the data packets sent from the RLC. MAC adds a header carrying the information required for MAC functions. On the receiver side, MAC de-encapsulates the data packets sent from the PHY sublayer, removes its header and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (air) by converting the information stream into a physical modulation signal and modulating the carrier frequency on the transmitter side. On the receiver side, the PHY sublayer converts the physical modulation signal back into an information stream. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS38.213, TS 38.214.

[0087] To deliver messages towards the user plane or control plane, two other sublayers are used in the UE and the IAB donor CU: the PDCP (Packet Data Convergence Protocol) sublayer, and the SDAP (Service Data Adaptation Protocol) sublayer for user plane communication or the RRC (Radio Resource Control) sublayer for control plane communication.

[0088] The PDCP sublayer disposes of IP header compression / decompression, encryption / decryption, and disposes of the integrity of data packets when necessary. Mandatorily, packets are numbered on the transmitter side and reordered on the receiver side. The PDCP sublayer is described in 3GPPTS38.323.

[0089] The SDAP sublayer 220 of the user plane disposes of the quality of service. The SDAP sublayer is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc..., not shown in the figure). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (Internet traffic, cloud, etc...).

[0090] The RRC sublayer 220 for the control plane disposes of the configuration of the protocol entities of the user plane protocol stack. The RRC sublayer is described in TS38.331. The RRC sublayer is responsible for disposing of: broadcasting the information required for UE-cell communication; transmitting paging messages, managing connections, including establishing bearers; mobility functions; measurement configuration and reporting; device capabilities; and others.

[0091] The interface (for both CP and UP) between nodes using layers PDCP, RLC, MAC, and PHY is referred to as NR-Uu. This mainly concerns the interface with the UE.

[0092] The interface (for both CP and UP) between nodes using layers BAP, RLC, MAC, and PHY is referred to as the backhaul RLC channel (BH RLC channel). This mainly concerns the interface between IAB nodes.

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

[0094] Figure 2 (b) is from 3GPP TS 38.300 v17.2.0 and illustrates the protocol stack for supporting RRC and NAS connections for IAB-MT. The non-access stratum (NAS) protocol handles messages between the core network and the user equipment (or IAB node). The NAS protocol manages the establishment of communication sessions and maintains communication with the IAB node or user equipment when the user equipment moves. 5G NAS is described in 3GPP TS 24.501. The 5G core access and mobility management function (AMF) is a function within the core network that is used to receive all connection and session-related information from the UE connected to the IAB node and receive similar information from the IAB node. The AMF is only responsible for handling connection and mobility management tasks.

[0095] The IAB-MT establishes a signaling radio bearer (SRB) (a bearer carrying RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted between the IAB-MT and its (one or more than one) parent node via (one or more than one) NR-Uu interfaces.

[0096] Figure 4 Shows a schematic representation of an example communication device (equipment) or station according to one or more example embodiments of the present disclosure.

[0097] The communication device 400 can be a device such as a microcomputer, a workstation, or a lightweight portable device. The communication device 400 can include a communication bus 413, which is preferably connected to:

[0098] - A central processing unit 411 represented as a CPU, such as a microprocessor. The central processing unit 411 can be a single processing unit or processor, or can include two or more than two processing units or processors that perform the processing required for the operation of the communication device 400. The allocation of the number of processors and the processing functions to the central processing unit 411 is a matter of design choice for those skilled in the art;

[0099] - A memory for storing data and a computer program containing instructions for the operation of the communication device 400. The computer program may include many different program elements (modules) or subroutines, which contain instructions for various operations and for implementing a method according to one or more embodiments of the present invention; and

[0100] - At least one communication interface 402 for communicating with other devices or nodes in a communication system (such as Figure 1 the communication system, etc.). The at least one communication interface 402 may be connected to a radio communication network 403 (such as a wireless communication network used by 5G NR (e.g., according to Release 17 and / or subsequent releases)), through which digital data packets or frames or control frames are transmitted. Under the control of a software application running in the CPU 111, frames are sent from the FIFO transmit memory in the RAM 412 to the communication interface for transmission, or read from the communication interface for reception and written to the FIFO receive memory in the RAM 112.

[0101] The donor CU, donor DU, IAB node, and UE may each be implemented in such a communication device / equipment 400.

[0102] The memory may include:

[0103] - A read-only memory 407 represented as ROM for storing a computer program for implementing a method according to one or more embodiments of the present invention;

[0104] - A random access memory 412 represented as RAM for storing executable code for a method according to one or more embodiments of the present invention, and registers adapted to record variables and parameters required to implement a method according to one or more embodiments of the present invention.

[0105] Optionally, the communication device 400 may further include the following components:

[0106] - A data storage component 404 (such as a hard disk, etc.) for storing a computer program for implementing a method according to one or more embodiments of the present invention;

[0107] - A disk drive 405 for a disk 406, which is adapted to read data from or write data to the disk;

[0108] - A screen 409 for displaying the decoded data and / or serving as a graphical interface with the user using a keyboard 410 or any other input / output component.

[0109] In an example arrangement, a communication bus 413 provides communication and interoperability between various elements included in or connected to a communication device 400. The representation of the bus is not restrictive, and in particular, a central processing unit is operable to communicate instructions directly or through other elements of the communication device 400 to any element of the communication device 400.

[0110] The disk 406 can optionally be replaced by any information medium (e.g., a rewritable or non-rewritable compact disk (CD-ROM), ZIP disk, USB key, memory card, etc.), and in general, by an information storage component that can be read by a microcomputer or microprocessor, integrated or not integrated into the communication device, may be removable, and is adapted to store one or more programs (the execution of which enables the methods according to embodiments of the present invention).

[0111] The executable code can optionally be stored in a read-only memory 407, on a hard disk 404, or on a removable digital medium (e.g., the disk 406 as described above, etc.). According to an alternative variant, the executable code of the program can be received via a communication network 403, through an interface 402, and stored in one of the storage components of the communication device 400 (such as the hard disk 404, etc.) before being executed.

[0112] The central processing unit 411 can be adapted to control and direct the execution of instructions or portions of software code of one or more programs according to the present invention, which are stored in one of the aforementioned storage components. Upon power-up, one or more programs stored in a non-volatile memory (e.g., stored in the hard disk 404 or read-only memory 407) are transferred to a random access memory 412, which then contains the executable code of one or more programs and registers for storing variables and parameters required to implement the present invention.

[0113] In an example implementation, the communication device (apparatus) is a programmable device / apparatus that implements the present invention using software. The instructions can be executed by one or more processors of the device (such as one or more digital signal processors (DSPs), general microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry, etc.) to implement the present invention for a network node (e.g., an IAB node, an IAB donor CU). Thus, the term "central processing unit" as used herein can refer to any one of the aforementioned structures or any other structure suitable for implementing the techniques described herein. However, alternatively, the present invention can be implemented in hardware (e.g., in the form of an application-specific integrated circuit or ASIC or other circuit elements).

[0114] Figure 5An example of an IAB communication system (or IAB network system) 500 that can implement embodiments of the present invention and examples of the embodiments is shown. In one example implementation, the radio links (referred to as BH radio links) between IAB nodes and between an IAB node and an IAB donor DU operate in a millimeter wave frequency band (i.e., above 30 GHz) that is highly sensitive to radio channel interference. The IAB network will also be referred to as an IAB topology or a topology, and thus in this application, the terms IAB network and IAB topology and topology will be used interchangeably.

[0115] The IAB communication system 500 is composed of three IAB networks or IAB topologies 5001, 5002, and 5003. Each IAB topology includes a set of IAB nodes (e.g., the set may include multiple IAB nodes or at least one IAB node) and an IAB donor CU for controlling or managing the multiple IAB nodes. The set of IAB nodes may include one or more than one IAB node, such as an initiating IAB node that generates BAP packets and intermediate or relay IAB nodes, etc. Each IAB node communicates with at least one other IAB node via a wireless backhaul (BH) link. Although Figure 5 Three IAB topologies 5001, 5002, and 5003 are shown, but the present invention is not limited to three IAB topologies and can be implemented in an IAB communication system including more than two IAB topologies (where each topology includes a set of IAB nodes and an IAB donor CU) as described above.

[0116] As described above, each IAB node includes a mobile terminal (MT) part or unit controlled and configured by an IAB donor using RRC message passing as defined in 3GPP TS 38.331, and a distributed unit (DU) part controlled and configured by an IAB donor using F1-AP message passing as defined in 3GPP TS 38.473. For example, the IAB node 510 includes an MT part or unit 511 and a DU part or unit 512.

[0117] The IAB topology 5001 includes an IAB donor CU 501 (identified as Donor1-CU in Figure 5 ), its associated IAB donor DU 504 (identified as Donor1-DU1 in Figure 5 ), and multiple IAB nodes 510 and 520 similar to IAB nodes 121 and 122.

[0118] The IAB topology 5002 includes an IAB donor CU 502 (identified as Donor2-CU in Figure 5 ), its associated IAB donor DU, and an IAB donor DU 505 (identified as Donor1-DU1 in Figure 5identified as Donor2-DU1) and IAB donor DU 506 (in Figure 5 identified as Donor2-DU2), as well as a plurality of IAB nodes 530, 540, and 550 similar to IAB nodes 121 and 122 and an IAB node 570 that can be similar to mobile IAB node 123. All IAB nodes can be access nodes for serving UEs (such as UE 580 served by mobile IAB node 570). The IAB topology 5002 is transparent to UE 580 connected to donor CU 502 through the DU part or DU unit 572 of mobile IAB node 570. Although Figure 5 only one UE 580 is shown, it will be understood that there will be multiple UEs connected to the network nodes of IAB communication system 500.

[0119] The IAB topology 5003 includes IAB donor CU 503 (in Figure 5 identified as Donor3-CU) and its associated IAB donor DU 507 (in Figure 5 identified as Donor3-DU1), as well as IAB nodes 560 similar to IAB nodes 121 and 122.

[0120] The wired backhaul IP network interconnects IAB donor CUs 501, 502, and 503 and IAB donor DUs 504, 505, 506, and 507 through wired backhaul 508. For example, the wired backhaul 508 is composed of fiber optic cables.

[0121] IAB donor CU 501, IAB donor DU 504, and IAB nodes 510 and 520 are part of the same IAB network or IAB topology 5001 configured and managed or controlled by IAB donor CU 501.

[0122] 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 configured and managed or controlled by IAB donor CU 502.

[0123] IAB donor CU 503, IAB donor DU 507, and IAB node 560 are part of the same IAB network or IAB topology 5003 configured and managed or controlled by IAB donor CU 803.

[0124] Each IAB-DU and IAB donor DU supports what is referred to as (one or more than one) cell ( Figure 5Wireless communication in one or more coverage areas (not shown in the figure). In other words, each IAB-DU and IAB donor DU is associated with one or more cells. A wireless communication device (such as a UE or other IAB node, etc.) located within a cell can establish a communication link with the node of the serving cell (i.e., the IAB-DU or IAB donor DU) to communicate with other devices (such as other UEs, IAB nodes, servers providing access to the Internet, etc.) via this node.

[0125] Assume that the mobile IAB node 570 initially has a single parent IAB node 520, and the IAB node 570 belongs to the IAB topology 5001 controlled by the IAB donor CU 501. Therefore, the IAB donor CU is operating as an F1 termination donor CU (which can also be referred to as an F1 termination IAB donor CU or an F1 donor CU). When the mobile IAB node 570 moves, and considering its proximity to the IAB topology 5002, especially when the mobile IAB node 570 is in Figure 5 the position shown by the dashed line in the figure and is close to the IAB node 530, the mobile IAB node 570 is able to establish a wireless BH link with the IAB node 530. Such a BH link is possible for stationary IAB nodes and is very likely to occur for mobile IAB nodes (such as the IAB node 570) moving, for example, in the direction of the IAB topology 5002 (shown by Figure 5 the arrow 590 in the figure).

[0126] Then, the F1 donor CU 501 may have decided to perform the migration of the MT part 571 of the IAB node 570 towards the IAB topology controlled by the donor CU 502, and the donor CU 502 becomes the non-F1 terminating donor CU of the IAB node 570 (which may also be referred to as the non-F1 terminating IAB donor CU or non-F1 donor CU or RRC terminating donor CU or RRC donor CU) (i.e., the MT part 571 of the IAB node 570 migrates towards the parent IAB node 530). For this purpose, (in the case where the IAB node 570 has descendant IAB nodes) the F1 donor CU 501 may have initiated the inter-CU topology adaptation procedure described in Section 8.17.3.1 or Section 8.17.3.2 of TS 38.401 V17.2.0. As a result, the IAB node 501 still belongs to the IAB topology 5001, its F1 connection is to the donor CU 501, but its RRC connection is now to the donor CU2 502. After this process, the IAB donor CU 501 may request to migrate the backhaul traffic (e.g., user traffic, control traffic) related to the IAB node 570 towards the IAB topology 5002 (i.e., via the donor DU 505). In this case, the donor CU 501 triggers the IAB transmission migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0. In the IAB communication system, all traffic communicated on the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Therefore, the offloaded or migrated traffic or backhaul traffic is F1 traffic and may include control traffic and user traffic.

[0127] While the mobile IAB node 570 is still moving in the direction shown by the arrow 590, the MT part 571 of the IAB node 570 may then have migrated towards the parent IAB node 550 by the non-F1 donor CU 502 using the backhaul link 5050 between the IAB node 550 and the IAB node 570. For this purpose, the non-F1 donor CU 502 may have applied the intra-CU topology adaptation procedure described in Section 8.2.3.1 (or Section 8.17.3.2) of TS 38.401 V17.2.0, resulting in a continuous MT migration (or another MT migration to another IAB node) of the IAB node 570 with the new single parent IAB node 550. Still, the IAB node 501 has its F1 connection to the donor CU 501 and its RRC connection to the donor CU2 502.

[0128] After being informed to use donor DU 506 instead of donor DU 505 to route the F1 traffic related to IAB node 570, donor CU 501 may request to migrate the traffic related to IAB node 570 towards IAB topology 5002. In this case, donor CU 501 triggers the IAB transmission migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0.

[0129] While further moving (this time in the direction of IAB topology 5003 controlled by donor CU 503), IAB node 570 may be in a position where the backhaul link 5060 with IAB node 560 may have better quality than the backhaul link 5050 with IAB node 550. Therefore, donor CU 502 may apply the inter-CU topology adaptation procedure described in Section 8.17.3.1 or Section 8.17.3.2 of TS 38.401 V17.2.0. After this continuous MT migration, IAB node 501 still belongs to IAB topology 5001, its F1 connection is with donor CU 501, but its RRC connection is now with donor CU 503. Thus, donor CU 503 becomes a non-F1 terminating donor CU (or non-F1 donor CU or RRC donor CU). However, the new donor DU 507 and the new non-F1 donor CU 503 for IAB node 570 must be informed to donor CU 501 to redirect the offloaded traffic (F1 traffic, control traffic, and user traffic) via donor DU 507 instead of donor DU 506.

[0130] In all the above MT migration cases, UE 580 is still connected to donor CU 501 through the DU part or unit 572 of mobile IAB node 570. In the case where IAB node 570 has some (one or more than one) sub-IAB nodes, such sub-IAB nodes still belong to IAB topology 5001 and are still fully controlled by donor CU 501 (through F1 connection and RRC connection).

[0131] In any migration state of the MT part 571 of the IAB node 570, thus regardless of whether the MT part 571 of the IAB node 570 has migrated to the IAB topology 5002 or the IAB topology 5003, and thus regardless of whether the IAB node 570 has a non-F1 terminated donor CU and, in the case where the IAB node 570 has a non-F1 terminated donor CU, whether the non-F1 terminated donor CU is the non-F1 terminated donor CU 502 or 503, the F1 donor CU 501 may decide to perform a migration of the DU part of the IAB node 570. The reason for performing the DU migration may be to reduce the processing load at the F1 donor CU 501, or because the IAB node 570 is geographically far from the F1 donor CU 501 and close to an area where there is no longer Xn connectivity between the F1 donor CU 501 and the target donor CU. After deciding to perform the DU migration of the IAB node 570, the F1 donor CU 501 must also decide to which donor CU (which is referred to as the target F1 donor CU) the DU migration should be directed. The DU migration may be a DU migration towards the current non-F1 terminated donor CU (i.e., the default selection) (if there is a current non-F1 terminated donor CU and in this case the non-F1 terminated donor CU becomes the target F1 donor CU), or the DU migration may be a DU migration to another target F1 donor CU. For example, if the IAB node 570 is mobile and its trajectory is predictable (e.g., for a bus or a train), the F1 donor CU 501 may know the appropriate target F1 donor CU for controlling the cell through which the IAB node 570 will soon connect to the network. For example, when the non-F1 terminated donor CU of the IAB node 570 is the donor CU 502, the F1 donor CU may decide that the DU migration of the IAB node 570 should be directly towards the donor CU 503 because the IAB node 570 can quickly pass through without staying in the IAB topology 5002 controlled by the donor CU 502. Not performing the DU migration towards the donor CU 502 but performing the DU migration towards the donor CU 503 will avoid protocol messages for an intermediate DU migration for the IAB node 570. When performing the DU migration, a handover of the UEs served by the IAB node 570 must also be performed. Thus, not performing the DU migration towards the donor CU 502 will also avoid an intermediate handover of the UEs served by the IAB node 570 to the donor CU 502 before the new DU migration and UE handover towards the donor CU 503.

[0132] The process for performing the DU migration and UE handover towards the selected target F1 donor CU is described in more detail with reference to the subsequent drawings.

[0133] Figure 6An example of the IAB node architecture 600 is illustrated, which enables the migration of the DU of the IAB node from the source IAB topology to the target IAB topology (DU migration).

[0134] The IAB node 601 (which can be a mobile IAB node such as the IAB node 570) consists of the IAB-MT part or unit IAB-MT 610 (such as the MT part 571 of the IAB node 570 as Figure 5 shown), the part or unit IAB-DU1 611, and the part or unit IAB-DU2 612. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. During the DU migration of the IAB node 601, both of these two logical DUs are active: one logical DU terminates the F1 interface with the source F1 donor CU (such as Figure 5 the donor CU 501 as shown), while the other logical DU terminates the F1 interface with the target F1 donor CU (such as Figure 5 the donor CU 502 or 503 as shown). Otherwise (i.e., when DU migration is not performed), only one logical DU is sufficient for IAB operation. As an example and with reference to Figure 5For the IAB communication system, the F1 terminating donor CU of the IAB node 601 (i.e., the IAB node 570) can be the donor CU 501, which thus operates as the source F1 donor CU. When the source F1 donor CU 501 determines that the IAB node 570 is moving towards / passing through the IAB topology 5002, the source F1 donor CU 501 can identify the IAB donor CU 502 as a suitable target F1 donor CU. The IAB topology 5002 includes network nodes (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550) managed by the IAB donor CU 502, and these network nodes serve the cells in the IAB topology 5002 to which the IAB node 570 will soon connect. Alternatively, for an IAB node that is connected to the parent IAB node or the parent IAB donor DU of the IAB topology 5001 managed by the donor CU 501 acting as the F1 terminating donor CU and is stationary but close to one or more IAB nodes in a neighboring IAB topology (such as the IAB topology 5002, etc.) or near the one or more IAB nodes, when the source F1 donor CU 501 (e.g., based on signal measurements of radio signals received at the IAB node from all IAB nodes that are close to the IAB node and may include IAB nodes in the neighboring IAB topology 5002) determines that the IAB node may soon connect to an IAB node in the neighboring IAB topology 5002, the source F1 donor CU 501 can determine that the IAB donor CU 502 is a suitable target F1 donor CU.

[0135] Before the DU migration, the UE 602 (like the Figure 5 UE 580) connects to the source F1 donor CU 501, for example, through the access link 621 in the cell served by the logical DU IAB-DU1 611 using the logical DU IAB-DU1 611, and the logical DU IAB-DU2 612 is deactivated. During the DU migration, the logical DU IAB-DU2 612 is activated and connected to the target F1 donor CU 502. The UE 602 can also connect to the target F1 donor CU 502 through the link 622 in the cell served by the logical DU IAB-DU2 612 using the logical DU IAB-DU2 612. The activation of the logical DU IAB-DU2 612 can be triggered by the source F1 donor CU and uses reference Figure 8a and Figure 8bExecute according to the described process. Once the handover of UE 602 from the cell controlled by logical DU IAB-DU1611 to the cell controlled by logical DU IAB-DU2 612 is completed, logical DU IAB-DU1 611 can be deactivated. After detecting that the handover of all UEs served by IAB-DU1 611 is completed, the source F1 donor CU 501 can use the reference Figure 8c The described process to trigger deactivation.

[0136] Examples of methods according to one or more embodiments of the present invention will now be described. These examples of methods enable DU migration of IAB nodes with or without (multiple) MT migrations and include notifying the IAB node of the identity of the target donor CU to enable the handover of UEs served by the IAB node to the target donor CU. Although the following methods / devices will be mainly described with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The method according to one or more embodiments of the present invention can be applied to, for example, stationary IAB nodes at the edge of an IAB topology and close to or near one or more IAB nodes in an adjacent IAB topology.

[0137] Figure 7 Is a schematic simplified diagram 700 illustrating some example message flows according to one or more embodiments of the present invention. These example message flows are used to perform DU migration of IAB nodes with or without (multiple) MT migrations and include informing the IAB node of the target donor CU to enable the handover of UEs served by the migrating IAB node to the target donor CU.

[0138] The Figure 7 Shows UE 708 such as UE 580, source F1 donor CU 703 such as donor CU 501, target F1 donor CU 707 such as donor CU 503, such as Figure 1 The core network (5GC) 702 of the core network 110. The Figure 7The IAB node 701 is also shown, which can be a mobile IAB node such as the IAB node 570, composed of an MT part or unit IAB-MT 704, a DU part or unit IAB-DU1 705 (e.g., a source or first logical DU entity), and a DU part or unit IAB-DU2 706 (e.g., a target or second logical DU entity). The first DU logical entity 705 and the second DU logical entity 706 each serve one or more cells. The (one or more) cells of IAB-DU1 705 are identified by identifiers different from those of the (one or more) cells of IAB-DU1 705 (e.g., a physical cell identifier (PCI), a new radio cell group identifier (NCGI)). IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for 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 separate physical layers. If the IAB-MT 704 is not migrated, the non-F1 donor CU for the IAB node 701 can be the source F1 donor CU 703 itself. If the IAB-MT 704 was previously migrated towards the target F1 donor CU 707, the non-F1 donor CU for the IAB node 701 can be the target F1 donor CU 707, or if the IAB-MT 704 was previously migrated towards another donor CU (not shown in the figure), the non-F1 donor CU for the IAB node 701 can be that another donor CU.

[0139] At the start of the process, the IAB node 701 belongs to the source IAB topology controlled by the source F1 donor CU 703. The UE 708 is served by the IAB node 701 through the cell of IAB-DU1 705 (e.g., the DU of the IAB node 701 has an active IAB-DU1 705 that has an F1 connection with the source F1 IAB donor CU 703), while the logical IAB-DU2 706 is inactive. User data in the downstream direction is provided by the 5GC 702 to the source F1 donor CU 703 through the bearer 710, then the data is transmitted to the logical DU IAB-DU1 705 of the IAB node 701 through the backhaul bearer 711, and finally transmitted to the UE 708 through the data radio bearer 712. The backhaul bearer 711 can be established in the source IAB topology controlled by the source F1 donor CU 703, or in the IAB topology controlled by the non-F1 donor CU of the IAB node 701 (if the IAB-MT 704 was previously migrated towards this non-F1 donor CU). User data in the upstream direction (not shown in the figure) is transmitted through similar bearers in the opposite direction.

[0140] As a result of the measurements periodically made by the IAB-MT 704 on signals received from the serving cell and one or more target cells (such as signal synchronization blocks (SSBs) transmitted in the serving cell and target cells, etc.), the IAB-MT 704 can send a measurement report to its non-F1 terminated donor CU (if the IAB-MT 704 has previously migrated towards this non-F1 donor CU ( Figure 7 not shown in)), or to its F1 terminated donor CU (e.g., the source F1 donor CU 703) (if the IAB-MT 704 has not migrated from its F1 terminated donor CU) ( Figure 7 not shown in). The target cell can be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). Once the IAB-MT 704 discovers at least one SSB that meets the predefined criteria (e.g., received power exceeding a predefined threshold), a measurement report can be generated and transmitted to provide radio link quality information for different cells near the IAB node 701. The identifier of each cell is included in the measurement report to allow the non-F1 donor CU (if the IAB-MT 704 has migrated) or the F1 terminated donor CU 703 (if the IAB-MT 704 has not migrated) to identify the target donor CU associated with the cell. In fact, the identifier of the donor CU can be derived from the physical cell identifier (PCI) broadcast in the synchronization signal in each cell managed by the donor CU and / or from the new radio cell group identifier (NCGI) also broadcast in the system information block (SIB) message in each cell managed by the donor CU. The PCI and / or NCGI can be reported by the IAB node 701 in the measurement report.

[0141] Based on the received measurement report, the non-F1 donor CU (if the IAB-MT 704 has been migrated) or the F1 terminating donor CU 703 (if the IAB-MT 704 has not been migrated) can detect that the IAB node 701 receives radio signals in the target cell of the target parent IAB node with better quality than in the source serving cell. The non-F1 donor CU (if the IAB-MT 704 has been migrated) or the F1 terminating donor CU 703 (if the IAB-MT 704 has not been migrated) can decide to apply the process for migrating the IAB-MT 704 towards the target parent IAB node belonging to the same IAB topology (intra-CU topology adaptation) or belonging to another IAB topology (inter-CU topology adaptation). In any case, if the IAB-MT 704 has been migrated, the non-F1 donor CU will inform the source F1 donor CU 703 of this MT migration, or if the IAB-MT 704 has not been migrated, the source F1 donor CU 703 will be informed because it directly makes the decision to perform MT migration based on the measurement report received from the IAB node 701, and this information can be used by the source F1 donor CU 703 to trigger the DU migration of the IAB node 701. In another example, the non-F1 donor CU can relay the information in the measurement report received from the IAB node 701 to the source F1 donor CU 703. Therefore, the source F1 donor CU 703 can directly decide on the DU migration of the IAB node 701 based on these measurement reports relayed by the non-F1 donor CU.

[0142] Therefore, the source F1 donor CU 703 determines that the DU of the IAB node is to be migrated from the IAB topology of the source F1 donor CU 703 to another IAB topology of the target IAB donor CU. This determination can be based on the completion of the migration of the MT of the IAB node towards the new parent IAB node. Another example of a triggering event for determining the DU of the IAB node to be migrated can include: the decision for DU migration can be based on the detection of the MT migration from the first IAB topology towards the second IAB topology, and based on the known (predefined) trajectory of the IAB node indicating that the MT will migrate to the third IAB topology at a later time. In this case, in order to avoid the signaling messages used for DU migration / UE handover towards the second IAB topology, the DU migrates directly towards the third IAB topology. Another example of a triggering event for determining the DU of the IAB node to be migrated can include the detection of a processing load level higher than a predefined threshold in the source F1 donor CU. Then the DU migration is triggered, and the target F1 donor CU is selected based on the processing loads of other donor CUs connected to the source F1 donor CU.

[0143] When the source F1 donor CU 703 decides or determines to perform a DU migration of the IAB node 701 towards another IAB topology managed by another donor CU that becomes the target F1 donor CU 707, the first step 720 corresponds to: sending a request to the IAB node 701 to establish a new F1 connection between the target F1 donor CU 707 and the mobile IAB node 701. This may require activating the second logical IAB-DU2 706 in the mobile IAB node 701, so the first step 720 may include activating the second logical DU IAB-DU2 706 in the mobile IAB node 701. This operation is performed using, for example, the procedures described in references Figure 8a and Figure 8b . In particular, the message (e.g., 803 in Figure 8a ) sent by the source F1 donor CU 703 to the IAB node 701 for activating the IAB-DU2 706 may include identification information for identifying the target donor CU (such as the TNL address (i.e., IP address) of the target F1 donor CU 707, etc.), so that a new F1 connection or F1 association (e.g., F1AP interface connection) can be set up between the target donor CU 707 (between the IAB-DU2 706 and the target donor CU 707). If the address of the target F1 donor CU is not included in the request for activation, then by default and in the case where the IAB-MT 704 has migrated to a non-F1 donor CU, the non-F1 donor CU is considered to be the target F1 donor CU. In this case, when the IAB-MT 704 migrates to a non-F1 donor CU, the IAB node 701 has been informed of the identity of the target donor CU (e.g., TNL address / IP address). In other words, unless the IAB-MT 704 has migrated to a non-F1 donor CU, the source F1 donor CU 703 may send the identification information for identifying the target IAB donor CU. Alternatively, the source F1 donor CU 703 may send the identification information for identifying the non-F1 donor CU as the target IAB donor CU.

[0144] After it is determined that the DU of the IAB node 701 is to migrate and once the IAB-DU2 706 has been activated, the IAB-DU2 706 may send an F1 setup request message to the target F1 donor CU 707 (e.g., Figure 8b813 in ), for requesting to set up an F1 connection between the IAB node 701 and the target F1 donor CU 707. The message may include identification information for identifying the source IAB donor CU, such as the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID as specified in TS38.423 V17.2.0 Section 9.2.2.3) of the source F1 donor CU 703 of the IAB node 701. If the IAB-MT 704 of the IAB node 701 has previously moved toward a non-F1 donor CU ( Figure 7 If the F1 setup request message is not shown in the figure, the message may also include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the non-F1 donor CU of the IAB node 701. The destination address of the F1 setup request message is the target F1 donor CU 707, and when the donor DU receives the IP packet in the F1 path for the IAB node 701, the IP packet may be sent to the IAB node 701 in the wired backhaul ( Figure 5 508) is routed to the target F1 donor CU 707. For example, in the case where the IAB node 701 is connected to the IAB node 550 via the backhaul link 5050 Figure 5 IAB node 570, MT of IAB node 570 (corresponding to Figure 7 In the example where the MT 571 of the IAB-MT 704 in FIG. 5 has been migrated to the non-F1 donor CU 502 and the IAB donor CU 501 is the source F1 donor CU, the F1 path between the FI donor CU 501 and the IAB node 570 uses the donor DU 506. In the case where the IAB donor CU 503 has been identified (by the F1 donor CU 501) as the target F1 donor CU (e.g., the target F1 donor CU 707), the F1 setup request message for the target F1 donor CU (e.g., the donor CU 503) is sent through the IAB nodes 550, 540 and then sent to the donor DU 506, from which the donor DU 506 can be connected to the wired backhaul ( Figure 5 The message is routed to the target F1 donor CU 503 in 508 of FIG. 504. In F1, a response is set (e.g., Figure 8b 814 in the example above), the target F1 donor CU 707 (eg, Figure 5 The donor CU 503 in the described example) can request the IAB-DU 2706 to activate (one or more) new cells with associated identifiers (PCI, NCGI). Typically, the DU activates / deactivates (one or more) cells under the control of the donor CU that is controlling the DU. See, for example, TS 38.473 section 8.2.3.2.

[0145] In referenceFigure 8b After the described process and using, for example, the reference Figure 9a After the described process, the target F1 donor CU 707 can inform the source F1 donor CU 703 of the activation of one or more new cells of the IAB-DU2 706 from the IAB node 701.

[0146] The next step 730 consists in the UE served by the IAB node 701 (e.g., Figure 7The handover of the UE 708) from one or more cells of the first logical DUIAB-DU1 705 to one or more cells of the second logical DU IAB-DU2 706. This process can be the standardized process (handover) described in Section 9.2.3.2 of TS 38.300, or the standardized process (conditional handover) described in Section 9.2.3.4 of TS 38.300. In the example, to trigger the handover of the UE 708, the source F1 donor CU 703 sends a HANDOVER REQUEST message to the target F1 donor CU 707. The HANDOVER REQUEST message includes the necessary information related to the UE 708 to be handed over (e.g., identification information for identifying the UE, UE context information (such as security context (e.g., security parameters such as security keys, UE security capabilities, etc.)), measurement configuration, radio configuration (e.g., UE radio capabilities), bearer-related information, etc.). Section 9.1.1.1 of TS 38.423 provides details on the content of the HANDOVER REQUEST message. After the admission control step in which the target F1 donor CU 707 determines whether the donor CU can accept the handover of the UE 708, when the target F1 donor CU 707 accepts the request, the target F1 donor CU 707 sends a handover confirmation message to the source F1 donor CU 703. The handover confirmation message includes the configuration information for the UE 708 for the handover. This configuration may include radio configuration information that indicates the radio configuration to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 in the identified target cell of the second logical DU IAB-DU2 706 of the IAB node 701 (e.g., the radio configuration may include frequency, radio bearer configuration, etc.). The handover confirmation may include the identifier of each of one or more new cells (e.g., one or more target cells) that have been activated at the second logical DU IAB-DU2 706. Then, the source F1 donor CU 703 sends this configuration information to the UE 708 via the IAB node 701 in an RRC reconfiguration message. The configuration information includes the identifier of the target cell of the IAB-DU2 706 to which the UE 708 is to connect. The RRC reconfiguration message (specified in TS 38.331) is embedded in the F1 message DL RRCMESSAGE TRANSFER (DL RRC message transfer) (specified in TS 38.473), sent to the IAB-DU1 705 and relayed by the IAB-DU1 705 to the UE 708.Upon receiving the configuration information, the UE 708 performs a random access procedure in the indicated target cell of the IAB-DU2 706 to obtain uplink resources, and then transmits an RRC reconfiguration complete message to the target F1 donor CU 707. The RRC reconfiguration complete message (specified in TS38.331) is sent to the IAB-DU2 706 and then embedded in an F1 message UL RRC MESSAGE TRANSFER (UL RRC message transfer) (specified in TS 38.473) and sent to the target F1 donor CU 707. The completion of the handover of the UE 708 can be informed to the source F1 donor CU 703 by a HANDOVER SUCCESS message (specified in TS 38.423) received from the target F1 donor CU 707.

[0147] The target F1 donor CU 707 may perform a path conversion procedure towards the core network 702 to request the delivery of user data related to the UE 708. For example, the target F1 donor CU 707 may perform the path conversion handshake procedure described in Section 8.4.4 of 3GPP TS 38.413 v17.2.0.

[0148] Then, the target F1 donor CU 707 must set up (one or more than one) backhaul paths to / from the migrated IAB node 701 in its own topology (if there is a backhaul path to the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., the target F1 donor CU 707 is a non-F1 terminating donor CU of the IAB node 701 because the IAB-MT 704 has previously migrated to the target F1 donor CU 707)), or through the IAB topology of the non-F1 donor CU of the IAB node 701 ( Figure 7 not shown in the figure) (if there is no backhaul path to the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., the IAB-MT 704 and the IAB-DU2 706 are connected to different donor CUs)). In this latter case, the target F1 donor CU 707 may trigger the procedure described in the reference Figure 9b to request traffic migration to the non-F1 donor CU of the IAB node 701. As an example of this latter case of the reference Figure 5 , the IAB node 701 is the IAB node 570 that is connected to the IAB node 550 via the backhaul link 5050 Figure 5 , and where the MT of the IAB node 570 (corresponding to the MT 571 of the IAB-MT 704 in Figure 7 ) has migrated to the non-F1 donor CU 502 and the IAB donor CU 501 is an F1 donor CU. When the DU of the IAB node 570 (corresponding toFigure 7 When the DU 572 of IAB-DU2706 in Figure 9b has been migrated to the target donor CU 503 and thus has an F1 connection to the F1 donor CU 503, but the MT 571 remains connected through its RRC connection (its RRC connection) to the non-F1 donor CU 502, by performing (for example, as described in reference

[0149] After the handover and path conversion of the UE 708 have been performed, the user data in the downstream direction is transmitted by the core network 702 through the bearer 740 to the target F1 donor CU 707, then the user data is transmitted through the backhaul bearer 741 to the logical DU IAB-DU2 706 of the IAB node 701, and finally is transmitted through the data radio bearer 742 to the UE 708. The backhaul bearer 741 can be established in the IAB topology controlled by the target F1 donor CU 707, or in the IAB topology controlled by the non-F1 donor CU of the IAB node 707 (for example, depending on whether the IAB-MT 704 and IAB-DU2 706 of the IAB node 701 are connected to different donor CUs). The user data in the upstream direction (not shown in the figure) is transmitted through similar bearers in the opposite direction.

[0150] Once the handover of all UEs served by the IAB-DU1 705 of the IAB node 701 is completed, the source F1 donor CU 703 can deactivate the logical DU IAB-DU1 705 of the mobile IAB node 701 through the process described in reference Figure 8c . This is typically represented by the process 735 in Figure 7 .

[0151] In addition, the source F1 donor CU 703 can release the traffic (user traffic, control traffic) related to the UEs served by the IAB node 701 through the IAB-DU1 705. If the traffic is offloaded in the IAB topology controlled by another donor CU, the source F1 donor CU 703 can apply the process described in reference Figure 9b to request the traffic release to that another donor CU. This is typically represented by the process 735 in Figure 7 .

[0152] Figure 8a is a schematic simplified diagram 800 flowchart of an example message flow illustrating a process for activating a logical DU according to an embodiment of the present invention.

[0153] The figure shows:

[0154] -RAN node DU 801, which can be the DU of an IAB node such as the IAB-DU 572 of the IAB node 570 (and the IAB-DU1 705 of the IAB node 701 as in Figure 5 ), Figure 7 -RAN node CU 802, which can be an IAB donor CU such as the IAB donor CU 501 (and the source F1 donor CU 703 as in

[0155] ). Figure 5 The message CONFIGURATION REQUEST 803 is sent from the RAN node CU 802 to the RAN node DU 801 to request activation of one or more new cells controlled by the RAN node DU 801, or to request activation of a logical DU, or to request deactivation of one or more cells in the RAN node DU 801. In the case of logical DU activation, the message 803 may include the TNL address (i.e., IP address) of the RAN node CU (e.g., the target F1 donor CU 707 as in Figure 7 ) that will be connected to the logical DU once activated. For example, CONFIGURATION REQUEST 803 may be sent from the source IAB donor CU to an IAB node (e.g., the first logical DU entity 705 having an F1 connection with the source IAB donor CU) to request establishment of an F1 connection between the target IAB donor CU and the IAB node.

[0156] The RAN node DU 801 may confirm the request using the message CONFIGURATION RESPONSE 804 sent to the RAN node CU 802. Figure 7 According to one example, the process in

[0157] corresponds to the process gNB-CU configuration update process described in Section 8.2.5 of TS 38.473 V17.0.0, and the message 803 corresponds to the message GNB-CU CONFIGURATION UPDATE described in Section 9.2.1.10 of TS 38.473 V17.2.0, while the message 804 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in Section 9.2.1.11 of TS 38.473 V17.2.0.

[0158] According to one example, Figure 8a the process in

[0159] The message GNB-CU CONFIGURATION UPDATE includes the information element (IE) To Activate Cell List to indicate a list of the new cell(s) to be activated at the RAN node DU 801. For example and with reference to Figure 7 , the GNB-CU CONFIGURATION UPDATE includes information to activate the new cell(s) indicated in the IE To Activate Cell List, and these 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 the cell(s) controlled by the RAN node DU 801 that receives the request. Associated PCI and NCGI value(s) to be used by the RAN node DU 801 may also be provided.

[0160] The message GNB-CU CONFIGURATION UPDATE may also include the information element (IE) To Deactivate Cell List to indicate a list of the cell(s) to be deactivated. The cell(s) to be deactivated refer to the cell(s) controlled by the RAN node DU 801 that receives 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 IE To Deactivate Cell List, and these cell(s) are currently served by the first logical DU entity 705 at the IAB node 701.

[0161] According to one example, a new IE second DU activation can be added in message 803 in the form of a boolean (e.g., a one-bit IE) to request the activation of the second logical DU. One value of the one-bit IE (i.e., "0" or "1") means that no specific action related to the second logical DU is requested, while the other value (i.e., "1" or "0") means that the activation of the second logical DU is requested. This IE can be completed by a new IE for indicating that the F1 setup is for DU migration towards the target RAN node CU (in other words, an IE for indicating that the request for establishing the F1 connection is related to the DU migration of the DU of the IAB node), and / or by a new IE indicating the number of cells to be activated in the second logical DU. In the absence of this IE indicating the number of cells, the number of cells to be activated corresponds to the number of cells currently activated in the RAN node DU 801. Another IE can also provide a list of identifiers (e.g., PCI and / or NCGI) of the (one or more) cells controlled by the first logical DU 705 at the IAB node 701, and for this list of identifiers of the (one or more) cells, a mapping to the (one or more) identifiers of the (one or more) cells to be activated is to be provided: for example, for all the (one or more) active cells controlled by the first logical DU 705, the mapping may not be necessary, so only the identifiers of the cells that will be mapped to the identifiers of the cells to be activated and controlled by the second logical DU 706 can be included in message 803.

[0162] In addition, a new IE (e.g., a target TNL address IE) can be added to identify the target RAN node CU with which the F1 connection will be set up.

[0163] To complete the setup of the new logical DU at the IAB node, the process described in the reference Figure 8b can be used.

[0164] Figure 8b FIG. 810 is a schematic simplified diagram illustrating an example message flow of a process for setting up a logical DU to establish an F1 connection with a target IAB donor CU according to an embodiment of the present invention.

[0165] This figure shows:

[0166] - A RAN node DU 811, which can be a DU of an IAB node DU such as the IAB-DU 572 of the IAB node 570 as in Figure 5 and the IAB-DU2 706 of the IAB node 701 as in Figure 7 ;

[0167] - A RAN node CU 812, which can be an IAB donor CU 503 as in Figure 5 and Figure 7an IAB donor CU such as the target F1 donor CU 707).

[0168] The message SETUP REQUEST 813 is sent by the RAN node DU 811 to the RAN node CU 812 to request an F1 setup for the logical DU. For example, the SETUP REQUEST 813 can be sent by an IAB node (e.g., by the second logical DU entity 706 that has been activated at the IAB node 701) to the target IAB donor CU 707 to request an F1 connection setup between the target IAB donor CU and the IAB node (e.g., the second logical DU entity 706 of the IAB node 701). It can be in accordance with the reference Figure 8aAfter the described activation request, a SETUP REQUEST message 813 is sent. The SETUP REQUEST message 813 may include an indication related to DU migration of the RAN node embedded in the F1 setup and the RAN node DU 811 (e.g., information for indicating that the request for establishing the F1 connection is related to the DU migration of the DU of the IAB node) and / or the number of cells to be activated together with the activation of the logical DU. The SETUP REQUEST message 813 may optionally include the identifier(s) (e.g., PCI and / or NCGI) of the active cell(s) controlled by the first logical DU 705 and / or the identifier(s) of the active cell(s) controlled by the first logical DU 705 for which the mapping of the identifier(s) of the cell(s) to be activated (as described above) is to be provided (e.g., PCI and / or NCGI). The SETUP REQUEST message 813 may include a request for the mapping between the identifier(s) (e.g., PCI and / or NCGI) of the active cell(s) controlled by the first logical DU and the identifier(s) of the cell(s) to be activated (e.g., at the second logical DU of the IAB node). The SETUP REQUEST message 813 may include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the RAN node CU that terminates the F1 connection of the RAN node DU 811 (e.g., the source IAB donor CU 703). The message may include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the RAN node CU that terminates the non-F1 (i.e., RRC) connection of the RAN node DU 811 in the case where the MT (e.g., the mMT 571 of the IAB node 570 or the corresponding IAB-MT 704 of the IAB node 701) has migrated to the RAN node CU which is now a non-F1 donor CU.

[0169] The RAN node CU 812 responds with a message SETUP RESPONSE 814 sent to the RAN node DU 811. The message SETUP RESPONSE 814 may include a list of (one or more than one) cells to be activated with the logical DU and the associated PCI and (one or more than one) NCGI values to be used. The message SETUP RESPONSE 814 may also include a mapping between the (one or more than one) identifiers (PCI and / or NCGI) of the (one or more than one) cells to be activated by the RAN node DU 811 and the (one or more than one) identifiers of the (one or more than one) active cells controlled by the first logical DU 705.

[0170] According to one example, Figure 8b the process in corresponds to the process F1 setup described in section 8.2.3 of TS 38.473 V17.2.0, and the message 813 corresponds to the message F1 SETUPREQUEST described in section 9.2.1.4 of TS 38.473 V17.2.0, while the message 814 corresponds to the message F1 SETUPRESPONSE described in section 9.2.1.5 of TS 38.473 V17.2.0. The message F1 SETUP RESPONSE includes the information element (IE) list of cells to be activated to indicate a list of (one or more than one) new cells to be activated. The (one or more than one) cells to be activated refer to the (one or more than one) cells controlled by the RAN node DU 811 that receives the response.

[0171] Figure 8c is a schematic simplified diagram 820 illustrating an example message flow for the process of removing a logical DU.

[0172] The figure shows:

[0173] - The RAN node DU 821, which may be a DU of an IAB node DU such as the IAB-DU 572 of the IAB node 570 as Figure 5 and the IAB-DU1 705 of the IAB node 701 as Figure 7 - The RAN node CU 822, which may be an IAB donor CU such as the IAB donor CU 501 as

[0174] - The RAN node CU 822, which may be an IAB donor CU such as the IAB donor CU 501 as Figure 5 and the source F1 donor CU 703 as Figure 7 of the IAB node 701.

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

[0176] The RAN node DU 821 responds with a message REMOVAL RESPONSE 814 sent to the RAN node CU 822.

[0177] According to one example, Figure 8c the process in corresponds to the process F1 removal described in section 8.2.8 of TS 38.473 V17.2.0, and the message 823 corresponds to the message F1 REMOVAL REQUEST described in section 9.2.1.16 of TS 38.473 V17.2.0, while the message 824 corresponds to the message F1 REMOVAL RESPONSE described in section 9.2.1.7 of TS 38.473 V17.2.0.

[0178] Figure 8d is a schematic simplified diagram 830 of an example message flow of a process used by an exemplary logical DU to inform an IAB donor CU of a configuration change.

[0179] The figure shows:

[0180] - a RAN node DU 831, which can be a DU of an IAB node DU such as the IAB-DU 572 of the IAB node 570 as in Figure 5 and the IAB-DU1 705 of the IAB node 701 as in Figure 7 - a RAN node CU 832, which can be an IAB donor CU such as the IAB donor CU 501 as in

[0181] and the source F1 donor CU 703 as in Figure 5 Figure 7

[0182] The message CONFIGURATION UPDATE 833 is sent by the RAN node DU 831 to the RAN node CU 832 to indicate a configuration change of the RAN node (e.g., IAB nodes 570, 701) embedded in the RAN node DU 831. The CONFIGURATION UPDATE message 833 may be sent by the RAN node DU 831 to indicate to the RAN node CU 832 the completion of the F1 setup procedure with the target RAN node CU during the DU migration of the RAN node embedded in the RAN node DU 831, i.e., to report the new F1 connection between the second logical DU activated in the RAN node (e.g., IAB node 701) embedded in the RAN node DU 831 and the target F1 terminating donor CU (e.g., target F1 terminating donor CU 707). The message 833 may include the identifier of the target RAN node CU (e.g., target F1 donor CU 707). The message 833 may also include the identifier(s) (e.g., PCI and / or NCGI) of the cell(s) activated in the second logical DU of the RAN node embedded in the RAN node DU 831. Additionally or alternatively, the message 833 may include the mapping between the identifier(s) of the cell(s) controlled by the RAN node DU 831 and the identifier(s) of the cell(s) activated using the second logical DU. For example, referring to Figure 7 , the message 833 is optionally sent by the first logical DU entity 705 that has been activated at the IAB node 701 to the source IAB donor CU 703, together with the identifier(s) of the cell(s) activated at the second logical DU 706 and optionally together with the mapping between the identifier(s) of the cell(s) activated at the second logical DU 706 and the identifier(s) of the cell(s) controlled by the first logical DU 705, to indicate the completion of the F1 setup procedure towards the target IAB donor CU 707. The CONFIGURATION UPDATE message 833 may include the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the RAN node CU (e.g., target F1 donor CU 707) that terminates the new F1 connection of the RAN node embedded in the RAN node DU 831.

[0183] The message 833 may indicate the success or failure of the F1 setup procedure. In the case where the F1 setup procedure fails (e.g., the F1 connection cannot be set up), the message 833 may also indicate the reason for the failure to set up the F1 connection.

[0184] The RAN node CU 832 may respond or react with a message CONFIGURTION ACKNOWLEDGE 834 sent to the RAN node DU 831.

[0185] According to one example, Figure 8d the procedure in corresponds to the procedure gNB-DU configuration update described in Section 8.2.4 of TS 38.473 V17.2.0, which is modified to include the above information elements. Message 833 corresponds to the message GNB-DU CONFIGURATION UPDATE described in Section 9.2.1.7 of TS 38.473 V17.2.0, and message 834 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in Section 9.2.1.8 of TS 38.473 V17.2.0.

[0186] Message 833 may be sent after the F1 setup procedure described in reference Figure 8c and is triggered by the RAN node CU 832 (using the procedure described in reference Figure 8a ), or is triggered by a RAN node embedded in the RAN node DU 831 using a pre-configured selection of the target RAN node CU. The pre-configuration may occur, for example, during the network integration of the RAN node embedded in the RAN node DU 831. For example, the F1 setup procedure may be determined by the RAN node CU 832 (e.g., the source IAB donor CU 703 / 501) or by a RAN node (IAB node 701 / 570) embedded in the RAN node DU 831 (e.g., IAB-DU1 572) for the RAN node DU 831 to migrate to the target RAN node CU (e.g., the target IAB donor CU 707 / 503).

[0187] Figure 9a FIG. 900 is a schematic simplified diagram illustrating an example message flow of a process used by a RAN node CU according to an embodiment of the present invention to report the activation of one or more cells to another RAN node CU.

[0188] The figure shows two RAN nodes, namely RAN node CUa 901 and RAN node CUB 902, which may be two IAB donor CUs such as two of the IAB donor CUs 501, 502, and 503 as in Figure 5 . Regarding the example shown in Figure 7 , RAN node CUa 901 is the target F1 donor CU 707, and RAN node CUB 902 is the source F1 donor CU 703.

[0189] Message CONFIGURATION UPDATE 903 is sent by RAN node CUa 901 to RAN node CUB 902 to inform RAN node CUB 902 of the activation of one or more new cells in the logical DU of a RAN node DU such as IAB-DU2 706 of IAB node 701. For example, source F1 donor CU 703 receives CONFIGURATION UPDATE message 903 from target F1 donor CU 707, and CONFIGURATION UPDATE message 903 includes identification information (e.g., PCI, NCGI) identifying one or more new cells that have been activated at the second logical DU entity (IAB-DU2 706) of the DU of IAB node 701. Additionally, message 903 may include a mapping between the identifier(s) (PCI and / or NCGI) of the one or more cells activated at the second logical DU (IAB-DU2 706) and the identifier(s) of the one or more active cells controlled by the first logical DU (IAB-DU1 705).

[0190] RAN node CUB 902 responds with message CONFIGURATION ACKNOWLEDGE 904 sent to RAN node CUa 901.

[0191] According to one example, Figure 9a corresponds to the procedure for NG-RAN node configuration update described in Section 8.4.2 of TS 38.423 V17.2.0, and message 903 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE (NG-RAN node configuration update) described in Section 9.1.3.4 of TS 38.423 V17.2.0, while message 904 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE (NG-RAN node configuration update acknowledgement) described in Section 9.1.3.5 of TS 38.423 V17.2.0.

[0192] Figure 9b is a schematic simplified diagram 910 of an example message flow illustrating a process used by a RAN node CU according to an embodiment of the present invention to manage transmission migration (e.g., migration or release of F1 traffic such as user / control traffic) in coordination with another RAN node CU.

[0193] The figure shows two RAN nodes, namely RAN node CUa 911 and RAN node CUB 912, which may be as Figure 5Two IAB donor CUs, such as two of the IAB donor CUs 501, 502, and 503.

[0194] The message TRANSPORT MIGRATION REQUEST 913 is sent by the RAN node CUa 911 to the RAN node CUB 912 to request traffic migration or release in the IAB topology controlled by the RAN node CUB 912. For example, referring to Figure 7 , in the case where the MT 704 of the IAB node 701 has migrated to a non-F1 donor CU ( Figure 7 not shown in), the source F1 donor CU 703 can send a TRANSPORT MIGRATION REQUEST 913 to the non-F1 donor CU to request the release of the traffic (e.g., F1 traffic) of the topology migrated to the non-F1 donor CU (i.e., because the F1 traffic is now to be routed from the target F1 donor CU 707 through the IAB topology managed by the non-F1 donor CU). Alternatively, in the case where the MT 704 of the IAB node 701 has migrated to a non-F1 donor CU ( Figure 7 not shown in), the target F1 donor CU 707 can send a TRANSPORT MIGRATION REQUEST 913 to the non-F1 donor CU to request the migration of traffic (e.g., F1 traffic) to the topology of the non-F1 donor CU (i.e., because the F1 traffic is now to be routed from the target F1 donor CU 707 through the IAB topology managed by the non-F1 donor CU).

[0195] The RAN node CUB 912 responds with a message TRANSPORT MIGRATION RESPONSE 914 sent to the RAN node CUa 901 to accept or reject the request.

[0196] Depending on the situation, Figure 9b it can correspond to the IAB transport migration management process specified in Section 8.5.2 of TS 38.423 V17.2.0. The message 913 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in Section 9.1.4.2 of TS 38.423 V17.2.0, and the message 914 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in Section 9.1.4.3 of TS 38.423 V17.2.0. Figure 9bIt may also correspond to the IAB transmission migration modification procedure specified in Section 8.5.3 of TS 38.423 V17.2.0. Message 913 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in Section 9.1.4.4 of TS 38.423 V17.2.0, and message 914 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in Section 9.1.4.5 of TS 38.423 V17.2.0.

[0197] Figure 10a is a flowchart showing an example method 1000 according to one or more embodiments of the present invention, which is performed at a source IAB donor CU for use in (or as part of) a migration process in which a distributed unit (DU) of an IAB node migrates from one IAB topology managed by the source IAB donor CU to another IAB topology managed by a target IAB donor CU. The method 1000 is used to manage the DU migration of an IAB node towards a target IAB topology at a source F1 terminating donor CU of the IAB node. For example, referring to Figure 5 shown in and regarding Figure 5 the IAB communication system described, the source IAB donor CU performing the method 1000 may be the IAB donor CU 501 (e.g., the F1 terminating donor CU of the IAB node 570, with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003 managed by the IAB donor CU 503 as the target IAB donor CU. Referring to Figure 7 the IAB node may be the IAB node 701, and the migration process may involve migrating the DU of the IAB node 701 from the source F1 donor CU 703 to the target F1 donor CU 707. As Figure 10a shown in and regarding Figure 10a the method 1000 described may be performed by software elements and / or hardware elements. The source IAB donor CU may be implemented in the communication device 400 as shown in Figure 4 and referring to Figure 4 described, where the method as shown in Figure 10a and referring to Figure 10a described is performed by one or more processing units (such as the central processing unit 411, etc.).

[0198] At step 1001, if Figure 5 Donor CU 501( Figure 7 703) as the source F1 terminates the donor CU is determined as Figure 5 IAB node 570 ( Figure 7 DUs of IAB nodes such as 701) need to be migrated from source F1 donor CU 501, 703 to Figure 5 Donor CU 503( Figure 7 707). For example, the source F1 donor CU 503, 707 determines the DU migration of the IAB node (such as the IAB node 570) toward the target F1 donor CU (such as 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 that the migration of the MT of the IAB node 570, 701 toward the new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining that the DU is to be migrated are described above. Details of how the source F1 donor CU 501, 703 determines the target F1 donor CU 503, 707 are also described above.

[0199] At step 1002, the source F1 terminating donor CU 501, 703 sends a request to the IAB node for establishing an F1 connection (i.e., a new F1 connection) between the target IAB donor CU 503, 707 and the IAB node 570, 701 (e.g., establishing a new F1 association with the target IAB donor CU). For example, the source F1 terminating donor CU 501, 703 sends a request for a new F1 connection to the IAB node 570, 701 to be migrated. The request may be a reference Figure 8a CONFIGURATION REQUEST 803 described. The source F1 donor CU 501, 703 may send to the IAB node information indicating that the F1 connection is for the purpose of DU migration towards the target IAB donor CU (e.g., information indicating that the request for establishing the F1 connection is related to DU migration of the DU of the IAB node) and / or information indicating the number of cells to be activated at the second logical DU entity of the DU of the IAB node. The source F1 donor CU 501, 703 may optionally send (one or more) identifiers (e.g., PCI and / or NCGI) of (one or more) active cells controlled by the first logical DU 705, wherein for the (one or more) identifiers of these (one or more) active cells, a mapping with (one or more) identifiers of (one or more) cells to be activated (e.g., to be activated at the second logical DU) is to be provided.

[0200] Optionally, at step 1003, the source F1-terminating donor CUs 501, 703 send identification information for identifying the target IAB donor CUs 503, 707 to the IAB nodes 570, 701. The identification information may be the TNL address (i.e., IP address) of the target IAB donor CUs 503, 707. For example, the source F1-terminating donor CUs 501, 703 send the address of the target F1 donor CU for the new F1 connection to the IAB nodes to be migrated. In the case where the IAB-MT 704 has migrated to a non-F1 donor CU (which may be referred to as an RRC donor CU), the identification information sent by the source F1-terminating donor CUs 501, 703 may include the address of the non-F1 donor CU (although the IAB node 701 may already have this information) to identify the non-F1 donor CU as the target F1 donor CU.

[0201] The source F1-terminating donor CU 703 may receive identification information (e.g., an identifier) identifying one or more new cells activated at the second logical DU entity of the DU of the IAB node, optionally together with mapping information indicating a mapping between the identification information (e.g., (one or more) identifiers) of the one or more new cells or target cells activated at the second logical DU and the identification information (e.g., (one or more) identifiers) of the (one or more) source cells or active cells controlled by the first logical DU, from the target F1 donor CU 707 or from the IAB nodes 570, 701. As described above, the DU of the IAB node has a first logical DU entity (which has an F1 connection to the source F1-terminating donor CU 703), and a second logical DU entity is activated for DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). For example, the identification information and optional mapping information may be received in the above CONFIGURATION UPDATE message 903.

[0202] In the example, the source F1 terminating donor CU 703 may send a handover request to the target F1 donor CU 707. The handover request is used to request one or more user equipments (UEs) (such as UE 708, etc.) served by the IAB node 701 to hand over from the source F1 terminating donor CU 703 to the target F1 donor CU 707, and is used to identify one or more target cells (e.g., candidate target cells) for each UE. The selection of the (one or more) target cells for the UE may be based on a measurement report provided by the UE (e.g., an indication of the signal strength detected by the UE for one or several cells), or based on the mapping between the (one or more) identifiers of the (one or more) target cells activated at the second logical DU and the (one or more) identifiers of the (one or more) source cells controlled by the first logical DU. For example, the source F1 terminating donor CU 703 may select one or more new cells from the new cells activated at the second logical DU entity 706 as one or more candidate target cells for each of the one or more UEs served by the IAB node based on the mapping information received from the target F1 donor CU 707 or the IAB node 701. The use of the mapping avoids waiting for a measurement report from the UE to trigger the handover process. In response to receiving a handover confirmation from the target F1 donor CU 707 indicating that the handover of one or more UEs has been accepted and identifying the target cells for each UE, the source F1 terminating donor CU 703 sends configuration information for configuring each of the one or more UEs for the corresponding target cells to the IAB node 701. The handover confirmation from the target F1 donor CU 707 may also include configuration information for configuring each of the one or more UEs for the corresponding target cells. The handover process 730 discussed above may be performed for these steps.

[0203] After completing the handover of one or more UEs 708 to the target F1 donor CU 707, the source F1 terminating donor CU 703 may send a request to the IAB node 701 to deactivate the first logical DU entity (e.g., IAB-DU1 705) of the DU of the IAB node 701. This request may be a deactivation request sent in the CONFIGURATION REQUEST message 803 or a removal request sent in the message 823.

[0204] After completing the handover of one or more UEs 708 to the target F1 donor CU 707, and when the mobile terminal (MT) of the IAB node 701 (e.g., IAB-MT 704) has migrated to a non-F1 donor CU, the source F1 terminating donor CU 703 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU to request the traffic release of the traffic associated with the IAB node that is routed over one or more paths in the IAB topology managed by the non-F1 donor CU.

[0205] Figure 10b is a flowchart showing an example method 1010 according to one or more embodiments of the present invention. The example method 1010 is performed at an IAB node (e.g., a mobile IAB node or mIAB node) for use in (or as part of) a migration process in which the distributed unit (DU) of the IAB node migrates from one IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1010 is used to manage the DU migration of the IAB node towards the target F1 terminating donor CU. For example, referring to Figure 5 shown in and regarding Figure 5 the IAB communication system described, the IAB node performing method 1010 may be the mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501 (e.g., the F1 terminating donor CU of the mobile IAB node 570, with which the mobile IAB node 570 maintains an F1 connection) as the source IAB donor CU. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003 managed by the IAB donor CU 503 as the target IAB donor CU. Referring to Figure 7 the IAB node may be the mobile IAB node 701, and the migration process may involve migrating the DU of the IAB node 701 from the source F1 donor CU 703 to the target F1 donor CU 707. As Figure 10b shown in and regarding Figure 10b the method 1010 described may be performed by software elements and / or hardware elements. The IAB node may be implemented in the communication device 400 as Figure 4 shown in and referring to Figure 4 described, where the method as Figure 10b shown in and referring to Figure 10b described is performed by one or more processing units (such as the central processing unit 411, etc.).

[0206] At step 1011, the IAB node 570 as Figure 5 ( Figure 7The IAB node such as Figure 5 receives a request for a new F1 connection (e.g., an F1 connection between the IAB nodes 570, 701 and the target F1 donor CU (such as Figure 7 the donor CU 501 of Figure 5 from the source F1 terminating donor CU such as Figure 7 the donor CU 503 of Figure 8a the 707)) as described in the CONFIGURATION REQUEST 803 referred to in

[0207] In response to receiving the request for a new F1 connection, the IAB nodes 570, 701 then send an F1 setup request (step 1018) to the target F1 donor CUs 503, 707 to request setting up the F1 connection. For example, the setup request may be the SETUP REQUEST 813 described above. The F1 setup request message sent by the IAB node may include identification information for identifying the source F1 terminating donor CU or, in the case where the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, identification information for identifying the non-F1 donor CU (which may be referred to as the RRC donor CU).

[0208] The IAB nodes 570, 701 may identify or determine the identities of the target F1 donor CUs 503, 707 in response to receiving a request for establishing an F1 connection (step 1017), and then send an F1 setup request to the identified target F1 donor CUs. The IAB nodes 570, 701 may identify the target F1 donor CUs based on the identification information of the target F1 donor CUs 503, 707 (such as the addresses (e.g., TNL address / IP address) of the target F1 donor CUs 503, 707 received from the source F1 donor CUs 501, 703 (e.g., in a CONFIGURATION REQUEST 803 or a separately sent message) as shown in the optional step 1012, etc.). In the case where the IAB-MT 704 has migrated to a non-F1 donor CU, the identification information received at the IAB node may include the address of the non-F1 donor CU, in which case the IAB node identifies the non-F1 donor CU as the target F1 donor CU. Alternatively, if the address of the target F1 donor CU is not received from the source F1 donor CUs 501, 703 and in the case where the IAB-MT 704 has migrated to a non-F1 donor CU, the IAB nodes 570, 701 identify or determine the identity of the target donor CU 503, 707 by considering / identifying the non-F1 donor CU as the target F1 donor CU (e.g., after receiving a request for establishing an F1 connection). For example, in such a case, when the IAB-MT 704 migrates to a non-F1 donor CU, the IAB node 701 has been informed of the address of the target donor CU (e.g., TNL address / IP address), and thus may identify the address of the non-F1 donor CU as the address of the target donor CU.

[0209] Optionally, at step 1012, the IAB nodes 570, 701 receive identification information for identifying the target F1 donor CUs 503, 707 from the source F1 terminating donor CUs 501, 703. The identification information may include the address (e.g., TNL address / IP address) of the target F1 terminating donor CU for the new F1 connection.

[0210] As another method (not shown in the figures, e.g., instead of steps 1011 and 1012), the IAB nodes 570, 701 can also trigger themselves to send a request for a new F1 connection and identify the target F1 donor CU based on pre-configuration. Thus, the IAB nodes 570, 701 can themselves determine to set up a new F1 connection, and can identify the IAB donor CU with which to set up the connection based on the pre-configuration information pre-configured at the IAB node, and then can send an F1 setup request for requesting the setup of the F1 connection to the identified target IAB donor CU. As a first example, the trigger condition can be that the IAB nodes 570, 701 detect a cell or several cells near the IAB node, and the cell or several cells have an identifier (NCGI) associated with a donor CU belonging to a pre-configured list of target donor CUs. In other words, in response to detecting one or more cells near the IAB nodes 570, 701 or after detecting one or more cells near the IAB nodes 570, 701, the IAB nodes 570, 701 can determine to set up a new F1 connection (e.g., because the DU (e.g., 572) of the IAB node 570 / 701 is to be migrated), and can identify the IAB donor CU with which to set up the connection based on the pre-configuration information, and the one or more cells are associated with an IAB donor CU included in the list of candidate target IAB donor CUs pre-configured at the IAB node. As a second example, the trigger condition is that: during the network integration of the IAB node, after the establishment of the RRC connection between the IAB-MT and the IAB donor CU (which depends on the physical location of the IAB node), a first F1 connection with the IAB donor CU identified by pre-configuration must be set up. In other words, the IAB nodes 570, 701 can determine to set up a new F1 connection during the network integration of the IAB nodes 570 / 701 (e.g., when the IAB nodes 570 / 701 are connected to the network), and the IAB nodes 570 / 701 identify the IAB donor CU with which to set up the F1 connection based on the list of candidate IAB donor CUs pre-configured at the IAB node and the location of the IAB node.

[0211] Figure 10c Illustrate example steps for identifying a target IAB donor CU at an IAB node (e.g., a mobile IAB node or mIAB node) according to one or more embodiments of the present invention. In the example, Figure 10b step 1017 of can be performed by Figure 10cSteps 1013-1015 (which are collectively referred to as step 1016) are performed. In an alternative method where the IAB nodes 570, 701 (in the case where a request for a new F1 connection has not been received) can themselves determine to set up a new F1 connection, steps 1013-1015 can be performed at the IAB node to identify the IAB donor CU with which to set up a connection based on preconfigured information preconfigured at the IAB node.

[0212] At step 1013, the IAB node 701 determines whether it has received identification information for identifying the target IAB donor CU for the F1 connection from the source IAB donor CU (or via preconfiguration) by checking whether the address of the target F1 termination donor CU for the new F1 connection has been received. If "yes", then at step 1015, the IAB node 701 identifies the target F1 termination donor CU based on the received identification information, and the IAB node sends an F1 setup request to the identified target F1 termination donor CU. If "no", then at step 1014, the IAB node 701 identifies the non-F1 termination donor CU (which can be referred to as the RRC donor CU) as the target F1 termination donor CU based on the received identification information, and the IAB node sends an F1 setup request to its non-F1 termination donor CU (e.g., donor CU 502).

[0213] A request for a new F1 connection received at the IAB node 701 (e.g., in the CONFIGURATION REQUEST 803) may include a request for one or more cells to be activated for a second logical DU entity (e.g., IAB-DU2 706), and may optionally include the identifier(s) (e.g., PCI and / or NCGI) of the (one or more) active cells controlled by the first logical DU and / or the identifier(s) (e.g., PCI and / or NCGI) of the (one or more) active cells having a mapping to the identifier(s) of the (one or more) cells to be activated. As described above, the DU of the IAB node has a first logical DU entity (which has an F1 connection to the source F1 terminating donor CU 703), and a second logical DU entity is activated for DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). In an example, the IAB node 701 activates the second logical DU entity (e.g., IAB-DU2 706) in response to a request for establishing an F1 connection (e.g., in the CONFIGURATION REQUEST 803). In both cases, the F1 setup request (e.g., message 813) is sent by the second logical DU entity. The F1 setup request message sent to the target F1 terminating donor CU 707 may include information indicating the number of cells to be activated in the case of activation of the second logical DU at the IAB node and / or information indicating that the request for establishing the F1 connection is related to the DU migration of the DU of the IAB node. Optionally, the F1 setup request message includes a request for a mapping between the identifier(s) (e.g., PCI and / or NCGI) of the (one or more) active cells controlled by the first logical DU and the identifier(s) of the (one or more) cells to be activated. In an example, after sending the F1 setup request, the IAB node 701 receives a response (such as a SETUP response 814 etc.) from the target F1 terminating donor CU 707, which response 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 the identifier of each of the (one or more) cells to be activated, etc.

[0214] The IAB node 701 may receive a request (e.g., a deactivation request in REMOVE REQUEST 823 or CONFIGURATION REQUEST 803) for deactivating a first logical DU entity (e.g., IAB-DU1 705) of the DU of the IAB node 701 from a source F1 donor CU 703, and in response to the request, the IAB node 701 deactivates the first logical DU entity (e.g., IAB-DU1 705).

[0215] Figure 10d is a flowchart showing an example method 1020 according to one or more embodiments of the present invention, which is performed at a target IAB donor CU for use in (or as part of) a handover process, in which a distributed unit (DU) of an IAB node is handed over from one IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. The method 1020 is for managing the DU handover of an IAB node towards a target IAB topology managed by a target F1 terminating donor CU at the target F1 terminating donor CU. For example, referring Figure 5 as shown in Figure 5 and described with respect to Figure 7 the IAB communication system, the target IAB donor CU for performing the method 1020 may be the IAB donor CU 503 that controls the IAB topology 5003. The IAB node may be the mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501. The handover process may involve the DU 572 of the IAB node 570 being handed over from the IAB topology 5001 to the IAB topology 5003. Referring Figure 10d as shown in Figure 10d and described with respect to Figure 4 the method 1020 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 Figure 4 and described with reference to Figure 10d wherein the method as shown in Figure 10d is performed by one or more processing units (such as the central processing unit 411, etc.).

[0216] At step 1021, the target IAB donor CU (such as Figure 5 the IAB donor CU 503 as shown in Figure 7 or Figure 5 the IAB node 570 as shown in Figure 7receive, as in (701) above, an F1 setup request for requesting to setup an F1 connection between a target IAB donor CU and an IAB node. For example, the setup request may be the SETUP REQUEST 813 described above. The F1 setup request message sent by the IAB node may include identification information for identifying a source F1 terminating donor CU or, in the case where a mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, identification information for identifying the non-F1 donor CU (which may be referred to as an RRC donor CU). The F1 setup request message may include information indicating the number of cells to be activated in the case of activation of a second logical DU at the IAB node and / or information indicating that the request for establishing the F1 connection is related to a DU migration of the DU of the IAB node. Optionally, the F1 setup request message may include (one or more) identifiers (e.g., PCI and / or NCGI) of (one or more) active cells controlled by a first logical DU, and / or identifiers (e.g., PCI and / or NCGI) of (one or more) active cells having a mapping to be provided for (one or more) identifiers of (one or more) cells to be activated. The F1 setup request message may additionally or alternatively include a request for a mapping between (one or more) identifiers (e.g., PCI and / or NCGI) of (one or more) active cells controlled by a first logical DU and (one or more) identifiers of (one or more) cells to be activated (e.g., at a second logical DU of the IAB node).

[0217] At step 1022, in response to receiving the F1 setup request, the target IAB donor CUs 503, 707 send a response (such as a SETUP response 814, etc.) to the IAB nodes 570, 701, the response including a request for one or more cells to be activated for the second logical DU entity for the IAB nodes 570, 701. As described above, the DU of the IAB node has a first logical DU entity (which has an F1 connection to the source F1 terminating donor CU 703), and the second logical DU entity is activated for DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). The response may include identification information for identifying each of the one or more cells to be activated (e.g., the identifier of each of the (one or more) cells to be activated). Optionally, the response may further include a mapping between the (one or more) identifiers of the (one or more) active cells controlled by the first logical DU (e.g., PCI and / or NCGI) and the (one or more) identifiers of the (one or more) cells to be activated. The target IAB donor CUs 503, 707 or the IAB nodes 570, 701 may send to the source IAB donor CUs 501, 703 the identification information for identifying each of the one or more new cells that have been activated at the second logical DU entity of the DU of the IAB nodes 570, 701. The target IAB donor CUs 503, 707 or the IAB nodes 570, 701 may also send mapping information to the source IAB donor CUs 501, 703.

[0218] In the example, the target F1 donor CU 707 may receive a handover request from the source F1 terminating donor CU 703, which is used to request one or more user equipments (UEs) (such as UE 708, etc.) served by the IAB node 701 to hand over from the source F1 terminating donor CU 703 to the target F1 donor CU 707, and is used to identify one or more target cells (e.g., candidate target cells) for each UE. The selection of the (one or more) target cells for the UE may be based on a measurement report provided by the UE (e.g., an indication of the signal strength detected by the UE for one or several cells), or based on the mapping between the (one or more) identifiers of the (one or more) target cells activated at the second logical DU and the (one or more) identifiers of the (one or more) source cells controlled by the first logical DU. For example, the source F1 terminating donor CU 703 may select one or more new cells from the new cells activated at the second logical DU entity 706 as one or more candidate target cells for each of the one or more UEs served by the IAB node 701 based on the mapping information received from the target F1 donor CU 707 or the IAB node 701. The use of the mapping avoids waiting for a measurement report from the UE to trigger the handover process. When the target F1 donor CU 707 determines that it can accept the handover of one or more UEs, the target F1 donor CU 707 sends a handover confirmation to the source F1 terminating donor CU 703, indicating that the handover of one or more UEs has been accepted and identifying the target cells for each UE. The handover confirmation may also include configuration information for configuring each of the one or more UEs for the corresponding target cells. The handover process 730 discussed above may be performed for these steps.

[0219] After the handover of one or more UEs 708 to the target F1 donor CU 707 is completed, and when the mobile terminal (MT) of the IAB node 701 (e.g., IAB-MT 704) has migrated to a non-F1 donor CU, the target F1 donor CU 707 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU, for requesting the traffic migration of the traffic associated with the IAB node that is routed through one or more paths in the IAB topology managed by the non-F1 donor CU.

[0220] Therefore, by sending a request to an IAB node for establishing an F1 connection between the IAB node and a target IAB donor CU, a source F1 donor CU (e.g., a source IAB donor CU) facilitates the DU migration of the IAB node with or without (multiple) MT migrations. Further, in response to receiving the request for establishing the F1 connection, the IAB node may identify the target donor CU (e.g., via the identification information sent by the source donor CU or, in the case where the source donor CU does not send the identification information, by determining that a non-F1 donor CU is the target donor CU) such that the UE served by the IAB node can be handed over to the target donor CU.

[0221] Determining that the DU of an IAB node is to be migrated can be triggered by an event. What one or more events trigger the determination that the DU of an IAB node is to be migrated can depend on the implementation. For example, the decision for DU migration can be based on the detection of an MT migration from a first IAB topology towards a second IAB topology and on the known (predefined) trajectory of the IAB node indicating to the source F1 donor CU that the MT will migrate to a third IAB topology later. In this case, to avoid the signaling messages used for DU migration / UE handover towards the second IAB topology, the DU migrates directly towards the third IAB topology. Another triggering event can be when a processing load level higher than a predefined threshold is detected in the source F1 donor CU. Then the DU migration is triggered and the target F1 donor CU is selected based on the processing loads of other donor CUs connected to the source F1 donor CU.

[0222] In other words and as an overview, the triggering events and decision processing for an F1 terminating donor CU to perform the mobility IAB-DU (mIAB-DU) migration of a mobile IAB node can depend on the implementation. Further, for flexible IAB network management, the mIAB-DU should be allowed to migrate towards a different target F1 terminating donor CU than the non-F1 terminating donor CU (which can be referred to as an RRC terminating donor CU) serving the co-located mobile IAB-MT (mIAB-MT).

[0223] Therefore, the IAB-DU of a mobile IAB node can migrate towards a different target F1 terminating donor CU than the non-F1 terminating donor CU serving the co-located IAB-MT.

[0224] Then, when the F1 donor CU serving the mIAB-DU decides whether to perform the mIAB-DU migration, it may request the mobile IAB node to activate a second logical DU to be served by the target F1 donor CU identified in the request.

[0225] For example, the F1 donor CU can trigger a gNB-CU configuration update procedure to request the mobile IAB node to establish a new F1 connection with the identified target F1 donor CU. Then, the active logical DU triggers an F1 setup procedure with the target F1 donor CU. In the case where the request from the F1 donor CU does not identify the target F1 donor CU, the active logical DU triggers an F1 setup procedure with the non-F1 terminating donor CU of the mobile IAB node.

[0226] Therefore, when the serving F1 donor CU of the mobile IAB node requests to establish a new F1 connection, the mobile IAB node can perform an F1 setup procedure with the target F1 donor CU indicated in the request. In the absence of such an indication, the mobile IAB node performs an F1 setup procedure with the non-F1 terminating donor CU.

[0227] To trigger a handover of the UEs served by the mobile IAB node during mIAB-DU migration, the target F1 donor CU can inform the source F1 donor CU of the activation of one or more new cells in the second logical DU of the mobile IAB node. For this purpose, the target F1 donor CU can perform an NG-RAN node configuration update procedure with the source F1 donor CU. Once informed, the source F1 donor CU can send a handover command to the UEs served by the migrating mobile IAB node.

[0228] Therefore, the target F1 terminating donor CU of the mobile IAB node can use the NG-RAN node configuration update procedure to inform the source F1 terminating donor CU of the ID(s) of one or more cell(s) served by the second logical DU of the mobile IAB node.

[0229] Regarding the procedures for triggering, performing, and reporting F1 setup during DU migration, it can be observed that to trigger the DU migration of the mobile IAB node determined by the source F1 donor CU, the following information can be passed to the mobile IAB node:

[0230] - An indication to request DU migration (mandatory), which means that the F1 setup procedure should be initiated with the target logical DU.

[0231] - The identifier of the target F1 donor CU (optional). This information element is relevant when the DU migrates towards a target F1 donor CU different from the non-F1 donor CU serving the co-located mobile IAB-MT. In the absence of such an indication, the mobile IAB node shall perform an F1 setup procedure towards the non-F1 terminating donor CU.

[0232] Given the low number of bits used for this signaling, it may not be necessary to create a new F1AP procedure. Additionally, this is related to F1 interface management, so the gNB-CU configuration update procedure seems suitable for this signaling.

[0233] Then, it is proposed that the source CU can use the gNB-CU configuration update procedure to trigger the F1 setup procedure for the purpose of DU migration towards the target CU.

[0234] In the F1 setup request message, the mobile IAB node shall pass the following information to the target F1 donor CU:

[0235] - An indication that the F1 setup is related to DU migration. Due to this information element, the target F1 donor CU knows the context and can properly handle the request.

[0236] - The (one or more) PCIs of the (one or more) active cells at the source logical DU. This information element helps the target F1 donor CU select the (one or more) appropriate PCIs for the (one or more) cells to be activated at the target logical DU.

[0237] Then, it is proposed that within the scope of DU migration of the mobile IAB node, the F1 setup request sent to the target F1 donor CU shall include a clear indication that the F1 setup is related to the DU migration of the mobile IAB node, and shall include a list of PCIs at the source logical DU of this mobile IAB node.

[0238] For reporting the result of the F1 setup procedure for the purpose of DU migration of the mobile IAB node, the mobile IAB node can pass the following information to the source F1 donor CU:

[0239] - An indication of the success or failure of the F1 setup, and in case of failure, the reason for failure can be indicated.

[0240] - The (one or more) IDs of the (one or more) cells activated by the target F1 donor CU at the target logical DU.

[0241] - The mapping between the IDs of the cells activated at the target logical DU and the IDs of the cells active at the source logical DU, as an optional information element. Due to this mapping, it should be possible to limit the scope of the measurements to be performed at the UE, and even avoid measurement reports from the UE to initiate a handover. Since the gNB-CU configuration update procedure seems suitable for triggering the F1 setup, the gNB-DU configuration update procedure also seems to be a good candidate for the existing F1AP procedure to report the result of the F1 setup.

[0242] Then, it is proposed that the mobile IAB node can use the gNB-DU configuration update procedure to report the result of the F1 setup procedure towards the target CU to the source CU migrating to the DU, and it is proposed that the mapping between the ID of the cell activated at the target logical DU and the ID of the cell active at the source logical DU be included in the report of the F1 setup result as an optional information element.

[0243] Regarding providing identification information to the F1 donor CU, it can be observed that when the mobile IAB node migrates its DU towards a target F1 donor CU different from the non-F1 donor CU of the collocated mobile IAB-MT, the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at this CU should be provided to the target F1 donor CU. Due to these information elements, the target F1 donor CU will be able to perform the transmission migration management procedure towards the non-F1 donor CU.

[0244] Furthermore, during the network integration where the mIAB MT and the co-located mIAB-DU are integrated into different donor CUs, the UE XnAP ID of the mIAB-MT assigned by the CU of the MT and the gNB-ID of the CU of the MT should be known to the CU of the mIAB-DU.

[0245] Considering the network integration scenario, there are two options:

[0246] - Option 1: The mobile IAB node provides the identification information based on the information received from the non-F1 donor CU (i.e., the CU of the mIAB-MT).

[0247] - Option 2: Once the non-F1 donor CU knows the identifier of the F1 donor CU (i.e., the CU of the mIAB-DU) from the mobile IAB node, the non-F1 donor CU provides the identification information.

[0248] The disadvantage of Option 2 is that it requires the F1 donor CU to generate the UE XnAP ID for the mIAB-MT to provide it to the mobile IAB node, which will pass the UE XnAP ID together with the identifier of the F1 donor CU to the non-F1 donor CU. In the case of Option 2, the UE XnAP ID generated by the F1 donor CU will be used by the non-F1 donor CU in the XnAP message sent to the F1 donor CU. Therefore, Option 1 seems to have less impact on the specification than Option 2.

[0249] In the case of adopting Option 1, and for the sake of consistency, the mobile IAB node should also provide the identification information related to the non-F1 donor CU to the target F1 donor CU during the DU migration. This can be done through the same F1AP signaling as for the network integration scenario.

[0250] Furthermore, the mobile IAB node should still use the same F1AP signaling to provide identification information related to the target non-F1 donor CU to its F1 donor CU during (successive) MT relocation.

[0251] To cover all scenarios considered above, the F1AP procedure gNB-DU configuration update is appropriate as it can be triggered at any time.

[0252] Then, it is proposed that the mobile IAB node can use the gNB-DU configuration update procedure to inform the F1 donor CU of the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at that CU. This procedure can be applied during the network integration, DU relocation, and MT relocation of the mobile IAB node.

[0253] It can be noted that the source donor CU of the mIAB-MT can send information related to the target donor CU of the mIAB-MT to the donor CU of the mIAB-DU after the IAB-MT HO is completed.

[0254] In fact, this proposal is consistent with this statement because the source non-F1 donor CU (i.e., the source donor CU of the mIAB-MT) will not directly but through the mobile IAB node pass the information to the F1 donor CU (i.e., the donor CU of the mIAB-DU).

[0255] In addition, this proposal does not exclude that the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at that CU can be included in the F1 setup request sent to the target F1 donor CU during DU relocation. The absence of these information elements in the F1 setup request can indicate that the non-F1 donor CU is also the target F1 donor CU.

[0256] Then, it is proposed that within the scope of the DU relocation of the mobile IAB node, the F1 setup request sent to the target F1 donor CU can also include the identifier of the non-F1 donor CU and the XnAP UE ID of the mobile IAB-MT at that CU.

[0257] Although the present invention has been described with reference to the embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. Those skilled in the art will understand that various changes and modifications can be made without departing from the scope of the present invention as defined in the appended claims. All features disclosed in this specification (including any appended claims, abstract and drawings) and / or all steps of any method or process so disclosed can be combined in any combination except combinations in which at least some of such features and / or steps are mutually exclusive. Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Thus, unless otherwise expressly stated, each feature disclosed is only one example of a generic series of equivalent or similar features.

[0258] 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 defined in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

[0259] In the foregoing embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted through a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit.

[0260] The computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium such as a data storage medium, or a communication medium, which includes, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this way, the computer-readable medium generally may correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or a carrier wave. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures to implement the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0261] By way of example and not limitation, such a computer-readable storage medium can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that is accessible by a computer. Additionally, 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 the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, disk (disk and disc) includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disk typically reproduces data magnetically, while disc reproduces data optically with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method used in handover processing, in which the distributed unit (DU) of an integrated access backhaul node (IAB node) migrates from one IAB topology managed by a source IAB donor central unit (source IAB donor CU) to another IAB topology managed by a target IAB donor CU. The method is performed at the source IAB donor CU comprises: determining that the DU of the IAB node is to migrate from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU; and sending a request to the IAB node for establishing an F1 connection between the IAB node and the target IAB donor CU.

2. The method according to claim 1, further comprises: sending identification information for identifying the target IAB donor CU to the IAB node.

3. The method according to claim 2, wherein the identification information for identifying the target IAB donor CU for the F1 connection includes an address associated with the target IAB donor CU.

4. The method according to any one of claims 1 to 3, further comprises: sending information indicating the number of cells to be activated at a second logical DU entity of the DU of the IAB node to the IAB node.

5. The method according to any one of the foregoing claims, further comprises: sending identification information for identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node to the IAB node.

6. The method according to any one of the foregoing claims, further comprises: sending information indicating that the request for establishing the F1 connection is related to the handover of the DU of the IAB node to the IAB node.

7. The method according to any one of the foregoing claims, further comprises: receiving, from the target IAB donor CU or from the IAB node, identification information for 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.

8. The method according to any one of the foregoing claims, further comprises: receiving, from the target IAB donor CU or from the IAB node, mapping information for indicating a mapping between the identification information of one or more new cells that have been activated at a second logical DU entity of the DU of the IAB node and the identification information of one or more active cells controlled by a first logical DU entity of the DU of the IAB node.

9. The method according to any one of the foregoing claims, further comprises: sending a handover request to the target IAB donor CU, the handover request being for requesting the handover of one or more user equipments (UEs) served by the IAB node from the source IAB donor CU to the target IAB donor CU and for identifying one or more candidate target cells for each UE.

10. The method according to claim 8 or 9, further comprises: select one or more new cells in the new cell set as one or more candidate target cells for each of the one or more UEs served by the IAB node based on the mapping information, wherein the handover request includes information for identifying the selected one or more candidate target cells.

11. The method according to claim 9 or 10, further comprising: in response to receiving a handover confirmation from the target IAB donor CU indicating acceptance of the handover of the one or more UEs and identifying the target cell for each UE, sending configuration information for configuring each of the one or more UEs for the corresponding target cell to the IAB node.

12. The method according to any one of claims 9 to 11, further comprising: after completion of the handover of the one or more UEs to the target IAB donor CU, sending a request to the IAB node to deactivate a first logical DU entity of the DU of the IAB node that has an F1 connection with the source IAB donor CU.

13. The method according to any one of claims 9 to 12, further comprising: after completion of the handover of the one or more UEs to the target IAB donor CU and when the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, sending a traffic migration request to the non-F1 donor CU, the traffic migration request being for requesting traffic release for traffic routed via one or more paths in the IAB topology associated with the IAB node and managed by the non-F1 donor CU.

14. The method according to any one of the preceding claims, wherein determining that the DU of the IAB node is to be migrated comprises: determining that the DU of the IAB node is to be migrated in response to determining that the migration of the MT of the IAB node towards the new parent IAB node has been completed.

15. A method used in a migration process, in which a distributed unit (DU) of an integrated access backhaul node (IAB node) migrates from one IAB topology managed by a source IAB donor central unit (source IAB donor CU) to another IAB topology managed by a target IAB donor CU, the method at the IAB node comprising: receiving, from the source IAB donor CU, a request for establishing an F1 connection between the target IAB donor CU and the IAB node; and sending an F1 setup request to the target IAB donor CU for requesting setup of the F1 connection.

16. The method according to claim 15, further comprising: identifying the target IAB donor CU in response to receiving the request for establishing the F1 connection, wherein the sending comprises sending the F1 setup request to the identified target IAB donor CU.

17. The method according to claim 15 or 16, further comprising: receiving, from the source IAB donor CU, identification information for identifying the target IAB donor CU for the F1 connection.

18. The method according to claim 16 or 17, wherein, identifying the target IAB donor CU includes identifying the target IAB donor CU according to the received identification information.

19. The method according to claim 16, wherein, the identification includes: determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU, identifying the target IAB donor CU according to the received identification information.

20. The method according to claim 16, wherein, the identification includes: determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has not been received from the source IAB donor CU and the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, the identification includes identifying the non-F1 donor CU as the target IAB donor CU, wherein the sending includes sending the F1 setup request to the identified non-F1 donor CU that is the target IAB donor CU.

21. The method according to claim 17, further includes: after receiving the request for establishing the F1 connection, determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; wherein, in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has been received, the sending includes sending the F1 setup request to the target IAB donor CU identified by the received identification information.

22. The method according to claim 15 or 16, further includes: after receiving the request for establishing the F1 connection, determining whether identification information for identifying the target IAB donor CU for the F1 connection has been received from the source IAB donor CU; wherein, in response to determining that identification information for identifying the target IAB donor CU for the F1 connection has not been received from the source IAB donor CU and the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, identifying the non-F1 donor CU as the target IAB donor CU, wherein the sending includes sending the F1 setup request to the identified non-F1 donor CU that is the target IAB donor CU.

23. The method according to any one of claims 17 to 19, 21, wherein, the identification information for identifying the target IAB donor CU for the F1 connection includes an address associated with the target IAB donor CU.

24. The method according to any one of claims 15 to 23, wherein, The DU of the IAB node includes a first logical DU entity having an F1 connection with the source IAB donor CU, and the method further includes: receiving, from the source IAB donor CU, information indicating the number of cells to be activated at a second logical DU entity of the DU of the IAB node.

25. The method according to any one of claims 15 to 24, further including: receiving, from the source IAB donor CU, identification information for identifying one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

26. The method according to any one of claims 15 to 25, further including: receiving, from the source IAB donor CU, information indicating that the request for establishing the F1 connection is related to the migration of the DU of the IAB node.

27. The method according to any one of claims 15 to 26, wherein, the DU of the IAB node includes a first logical DU entity having an F1 connection with the source IAB donor CU, wherein the request for establishing the F1 connection includes a request for one or more cells to be activated for the second logical DU entity, wherein the sending includes the second logical DU entity sending the F1 setup request to the target IAB donor CU.

28. The method according to any one of claims 15 to 26, wherein, the DU of the IAB node includes a first logical DU entity having an F1 connection with the source IAB donor CU, and the method further includes: activating a second logical DU entity for establishing the F1 connection with the target IAB donor CU in response to receiving the request for establishing the F1 connection, wherein the sending includes the second logical DU entity sending the F1 setup request to the target IAB donor CU.

29. The method according to any one of claims 15 to 26, 28, further including: after sending the F1 setup request, receiving a response from the target IAB donor CU, 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.

30. The method according to claim 29, wherein, the response includes identification information for identifying each of the one or more cells to be activated.

31. The method according to claim 29 or 30, further including: sending, to the source IAB donor CU, identification information for identifying each of the one or more new cells activated at the second logical DU entity.

32. The method according to any one of claims 29 to 31, further including: sending, to the source IAB donor CU, mapping information for indicating a mapping between the identification information of the one or more new cells activated at the second logical DU entity and the identification information of the one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

33. The method according to any one of claims 24 to 32, further comprises: receiving, from the source IAB donor CU, a request for deactivating the first logical DU entity of the DU of the IAB node having an F1 connection with the source IAB donor CU.

34. The method according to claim 33, further comprises: deactivating the first logical DU entity in response to receiving the request for deactivating the first logical DU entity.

35. The method according to any one of claims 15 to 34, wherein sending the F1 setup request comprises: sending an F1 setup request message for requesting to setup the F1 connection, wherein the F1 setup request message comprises identification information for identifying the source IAB donor CU or identification information for identifying a non-F1 donor CU when a mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU.

36. The method according to any one of claims 15 to 35, wherein sending the F1 setup request comprises: sending an F1 setup request message for requesting to setup the F1 connection, wherein the F1 setup request message comprises information for indicating the number of cells to be activated in the case of activation of a second logical DU at the IAB node.

37. The method according to any one of claims 15 to 36, wherein sending the F1 setup request comprises: sending an F1 setup request message for requesting to setup the F1 connection, wherein the F1 setup request message comprises identification information for identifying one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

38. The method according to any one of claims 15 to 37, wherein sending the F1 setup request comprises: sending an F1 setup request message for requesting to setup the F1 connection, wherein the F1 setup request message comprises information indicating that the request for establishing the F1 connection is related to the migration of the DU of the IAB node.

39. The method according to any one of claims 15 to 38, wherein sending the F1 setup request comprises: sending an F1 setup request message for requesting to setup the F1 connection, wherein the F1 setup request message comprises a request for a mapping between identification information for identifying one or more new cells to be activated at a second logical DU entity of the DU of the IAB node and identification information for identifying one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

40. A method used in a migration process, in which a distributed unit (DU) of an integrated access backhaul node (IAB node) migrates from one IAB topology managed by a source IAB donor central unit (source IAB donor CU) to another IAB topology managed by a target IAB donor CU, the method at the target IAB donor CU comprises: receiving, from the IAB node, an F1 setup request for requesting to setup an F1 connection between the target IAB donor CU and the IAB node; Send a response to the IAB node, the response including a request for one or more cells to be activated for a second logical DU entity for the IAB node.

41. The method according to claim 40, wherein, receiving the F1 setup request includes: receiving an F1 setup request message for requesting to set up 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-F1 donor CU in the case where the mobile terminal (MT) at the IAB node has migrated to a non-F1 donor CU.

42. The method according to claim 40 or 41, wherein, receiving the F1 setup request includes: receiving an F1 setup request message for requesting to set up the F1 connection, wherein the F1 setup request message includes information indicating the number of cells to be activated in the case of activation of the second logical DU at the IAB node.

43. The method according to any one of claims 40 to 42, wherein, receiving the F1 setup request includes: receiving an F1 setup request message for requesting to set up the F1 connection, wherein the F1 setup request message includes identification information for one or more active cells controlled by a first logical DU entity of the DU of the IAB node.

44. The method according to any one of claims 40 to 43, wherein, receiving the F1 setup request includes: receiving an F1 setup request message for requesting to set up the F1 connection, wherein the F1 setup request message includes information indicating that the request for establishing the F1 connection is related to the migration of the DU of the IAB node.

45. The method according to any one of claims 40 to 44, wherein, receiving the F1 setup request includes: receiving an F1 setup request message for requesting to set up the F1 connection, wherein the F1 setup request message includes a request for a mapping between identification information for one or more new cells to be activated at a second logical DU entity of the DU of the IAB node and identification information for one or more active cells controlled by a first logical DU entity of the DU of the IAB node.

46. The method according to any one of claims 40 to 45, further comprises: sending to the source IAB donor CU identification information for identifying each of the one or more new cells that have been activated at the second logical DU entity of the DU of the IAB node.

47. The method according to any one of claims 40 to 46, wherein, the response includes identification information for identifying each of the one or more cells to be activated.

48. The method according to any one of claims 40 to 47, further comprises: Send mapping information to the source IAB donor CU, where the mapping information is used to indicate the mapping between the identification information of one or more new cells to be activated for the second logical DU entity and the identification information of one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

49. The method according to any one of claims 40 to 48, further comprises: Receive a handover request from the source IAB donor CU, where the handover request is used to request the handover of one or more user equipments (UEs) served by the IAB node, i.e., one or more UEs, from the source IAB donor CU to the target IAB donor CU, and to identify one or more candidate target cells for each UE; Send a handover confirmation to the source IAB donor CU, where the handover confirmation is used to indicate that the handover of the one or more UEs has been accepted by the target IAB donor CU and to identify the target cells for each UE.

50. The method according to claim 49, further comprises: After the handover of one or more UEs to the target IAB donor CU is completed and when the mobile terminal (MT) of the IAB node has migrated to a non-F1 donor CU, send a traffic migration request to the non-F1 donor CU, where the traffic migration request is used to request the traffic migration for the traffic routed through one or more paths in the IAB topology associated with the IAB node and managed by the non-F1 donor CU.

51. The method according to any one of the foregoing claims, wherein the IAB node is a mobile IAB node.

52. A device for an IAB node used in an integrated access and backhaul communication system, i.e., an IAB communication system, the device comprises: One or more processing units configured to perform the method according to any one of claims 15 to 39, 51.

53. A device for an IAB donor central unit, i.e., an IAB donor CU, used in an integrated access and backhaul communication system, i.e., an IAB communication system, the device comprises: One or more processing units configured to perform the method according to any one of claims 1 to 14, 40 to 51.

54. A computer program comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 51.

55. A computer-readable medium carrying the computer program according to claim 54.

Images