Node migration in IAB communication systems.

Abstract

To flexibly perform node migration in an IAB communication system. [Solution] 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 in the source IAB donor CU includes determining that the DU of the IAB node migrates 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 to establish an F1 connection between the IAB node and the target IAB donor CU. The method in the IAB node includes receiving a request from the source IAB donor CU to establish 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 to request setup of the F1 connection.

Description

[Technical Field]

[0001] The present invention relates generally to a method used in a process for migrating nodes and traffic between Integrated Access Backhaul (IAB) topologies of a wireless communication system including mobile IAB nodes, and more particularly to a method used in a migration process in which an IAB node, e.g., a Distributed Unit (DU) of a mobile IAB node, is migrated between IAB topologies. [Background technology]

[0002] Wireless communication systems are being widely deployed to address a wide range of applications, from mobile broadband and massively scaled machine-type communications to ultra-reliable low-latency communications (URLLC). In such systems, multiple user equipments (UEs) or mobile terminals can share a wireless medium to exchange multiple types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) via one or more base stations. The base stations are traditionally wired (e.g., via fiber) to a core network, forming an intermediate network called the backhaul (BH). Summary of the Invention [Problem to be solved by the invention]

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

[0004] Increasing numbers of users and higher throughput requirements are driving the demand for network densification.

[0005] Faced with the high cost and time required to deploy wired backhaul networks with network densification, 3GPP has proposed wireless backhaul, also known as IAB (Integrated Access and Backhaul), from Release 16 of 5G NR, in which a portion of the wireless (i.e., radio) spectrum is used for base station backhaul connections instead of fiber. Wireless backhaul communication (between base stations) may use the same radio resources as access communication (between base stations and UEs).

[0006] IAB is highly scalable and quick to install, eliminating the hassle of laying cables to base stations, making it a competitive alternative to fiber-optic-based backhaul in dense or hard-to-cover areas.

[0007] IAB will most likely operate in the millimeter wave (mmWave) band to achieve the required gigabit per second (Gbps) data rates. However, mmWave is known to suffer from strong attenuation of signal strength in some weather conditions (rain, fog) and to be blocked if there are obstacles in the path between the emitter and receiver.

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

[0009] Additionally, 3GPP allows for inter-donor redundancy, where an IAB node, referred to as a border IAB node, can access two different parent nodes connected to two different IAB donors, each of which manages a different IAB topology (also referred to as an IAB network). Even if a border IAB node belongs to a single IAB topology, i.e., belongs to a single IAB donor for configuration and management purposes, it can route packets from a first IAB topology managed by a first IAB donor to a second IAB topology managed by a second IAB donor. The benefit of such inter-donor redundancy lies in the ability of a first IAB donor to perform offloading by routing some of its packets through the second IAB topology, thereby mitigating congestion issues that may arise in the first IAB topology or overcoming radio link failure issues that may arise in the first IAB topology.

[0010] There are other situations in which an IAB node may become a boundary node. For example, in the case of partial migration of an IAB node decided by an IAB donor, the IAB node's mobile termination (MT) is connected to one parent IAB node belonging to another IAB topology managed by another IAB donor. This situation may also occur when an IAB node that experiences a radio link failure (RLF) recovers through a parent IAB node belonging to another IAB topology. In such cases, the migrated IAB node and its potential descendant IAB nodes still belong to the initial IAB topology, and such partial migration may be referred to as MT migration. To ensure that traffic can be routed through other IAB topologies, MT migration should follow traffic migration in which traffic associated with the boundary node and its descendant IAB nodes is routed through other IAB topologies to the boundary node (i.e., the migrated IAB node).

[0011] A fixed IAB node only requires a single MT migration. Indeed, the backhaul link (defined between two consecutive IAB nodes in the wireless backhaul) may experience radio outages due to fluctuating radio conditions. For a non-mobile IAB node, this is a temporary situation, and the link may recover after some time. Therefore, such a fixed IAB node does not need to perform multiple MT migrations within the same IAB topology or toward a different IAB topology, avoiding the transmission and processing of multiple protocol messages. For the same reason, migrating the IAB node's distributed unit (DU), handing over control of the IAB node to a new IAB donor, is not required for a fixed node. Furthermore, it should be noted that such a DU migration, which may be called a full migration, involves a handover of the UE served by the migrating mobile IAB node.

[0012] Urban environments are typically characterized by a high density of users, along with the presence of a significant number of vehicles (e.g., public / private passenger transport, goods delivery, food trucks, etc.). Some of these vehicles (e.g., buses, trams, trains) may have predictable routes and have UEs (i.e., passenger devices) located in numerous common locations. 3GPP believes that installing onboard base stations (or base station elements) acting as mobile repeaters in such vehicles can provide an opportunity to increase network coverage and connectivity to UEs within or in close proximity to the vehicles. These mobile repeaters rely on 5G wireless backhaul (typically IAB, or integrated access and backhaul) to connect to fixed donor devices.

[0013] Therefore, building on the fixed IAB foundation of Releases 16 and 17, 3GPP is now considering mobile IAB systems and architectures as part of the Release 18 framework to address scenarios focused on mobile IAB nodes mounted on vehicles (buses, trains, taxis, etc.). In such scenarios, the mobile IAB nodes, sometimes referred to as Vehicle Mounted Repeaters (VMRs), provide 5G coverage / capacity to in-vehicle and / or surrounding UEs.

[0014] The technical advantage of using VMR is its ability to provide good radio link conditions to nearby UEs. Additionally, compared to solutions using UEs as repeaters (i.e., sidelink relay solutions), vehicle-mounted IAB nodes are expected to have better RF / antenna performance and less power and battery constraints than relay UEs.

[0015] For a mobile IAB node, it may be worthwhile to perform multiple MT or DU migrations. This is because when a mobile IAB node moves away from its parent IAB node, it may not establish a connection with the parent IAB node belonging to the first IAB topology for a long time, or may never establish a connection again. Furthermore, to achieve flexible IAB network management, MT and DU migrations should be de-correlated; that is, a DU migration for an IAB node may be performed before or after one or more MT migrations for that IAB node. Furthermore, a DU migration for an IAB node may be performed toward an IAB donor that is different from the IAB donor associated with the MT of this IAB node.

[0016] Therefore, a new mechanism is needed to provide such flexibility by supporting DU migration of IAB nodes to any other donor CU without being tied to MT migration of IAB nodes. [Means for solving the problem]

[0017] According to a first aspect of the present invention, there is provided a method for use in a migration process in which a distributed unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method comprising: determining, in the source IAB donor CU, the DU of the IAB node to be migrated from one IAB topology of the source IAB donor CU to the other IAB topology of the target IAB donor CU; and sending, to the IAB node, a request to establish 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 for use in a migration process in which a DU of an IAB node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method being executed in the IAB node, as set forth in the accompanying claims.

[0019] According to a third aspect of the present invention, there is provided a method for use in a migration process in which a DU of an IAB node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method being executed in the target IAB donor CU, as set forth in the accompanying claims.

[0020] Thus, by sending a request to the IAB node to establish an F1 connection between the IAB node and the target IAB donor CU, a source F1 donor CU (e.g., source IAB donor CU) facilitates DU migration of the IAB node with or without MT migration(s). Further, in response to receiving the request to establish the F1 connection, the IAB node can identify the target donor CU (e.g., via identification information sent by the source donor CU, or by determining that a non-F1 donor CU is the target donor CU when no identification information is sent by the source donor CU) to enable handover of a UE served by the IAB node to the target donor CU. A non-F1 (terminating) donor CU is also known as an RRC (terminating) donor CU.

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

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

[0023] According to another aspect, a method for use in a migration process in which a distributed unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method comprising the steps of: determining, by a source IAB donor CU, that a DU of the IAB node is to be migrated from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU; and informing, by the source IAB donor CU, the IAB node of a connection between the IAB node and a previous IAB topology. a step of transmitting a request to establish an F1 connection between the IAB node and the target IAB donor CU; after receiving the request to establish the F1 connection, transmitting an F1 setup request by the IAB node to the target IAB donor CU to request setup of the F1 connection; and after receiving the F1 setup request from the IAB node to request setup of the F1 connection, transmitting a response by the target IAB donor CU to the IAB node, the response including a request for one or more cells to be activated for a second logical DU entity of the IAB node.

[0024] Further exemplary features of the invention are set out in the other independent and dependent claims.

[0025] In the following, we will refer to sources and targets in terms of different elements such as nodes / topologies, however it will be understood that the terms first and second may be used instead of source and target.

[0026] Any element of one aspect of the present invention may be applied to other aspects in any appropriate combination, in particular, method aspects may be applied to apparatus, device or unit aspects, and vice versa.

[0027] Furthermore, functions implemented by hardware may also be implemented by software, and vice versa. References to software functions and hardware functions in this specification should be interpreted accordingly. For example, as another aspect of the present invention, a computer program including instructions that, when executed by one or more processing units, cause the processing units to perform the method according to any of the above aspects or embodiments, or a computer-readable medium having the computer program recorded thereon, may also be provided.

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

[0029] [Figure 1] 1 is a schematic diagram of a communication system in which the present invention may be implemented in accordance with one or more embodiments. [Figure 2a] FIG. 1 illustrates a schematic stack of several protocol layers involved in IAB operation. [Figure 2b] FIG. 1 illustrates a schematic stack of several protocol layers involved in IAB operation. [Figure 3] 1 is a schematic diagram illustrating the format of a BAP protocol data unit (PDU) or packet. [Figure 4] 1 is a block schematic diagram of an exemplary wireless communication device according to an embodiment of the present invention. [Figure 5] 1 is a schematic diagram of an exemplary IAB communication system (or IAB network system) in which embodiments and examples of the present invention may be implemented. [Figure 6] 1 is a schematic and simplified diagram illustrating an example of an IAB node architecture that enables DU migration from a source IAB topology to a target IAB topology. [Figure 7]FIG. 1 is a simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for performing a DU migration of an IAB node including a handover of a UE served by the migrating IAB node. [Figure 8a] FIG. 1 is a simplified diagram illustrating an example message flow of a procedure for performing activation of a logical DU in accordance with one or more embodiments of the present invention. [Figure 8b] FIG. 10 is a simplified diagram illustrating an example message flow of a procedure for setting up a logical DU. [Figure 8c] FIG. 10 is a simplified diagram illustrating an example message flow of a procedure for removing a logical DU. [Figure 8d] FIG. 10 is a simplified diagram illustrating an example message flow of a procedure used by a logical DU to notify a RAN node CU about a change in configuration. [Figure 9a] FIG. 10 is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to report cell activation to another RAN node CU. [Figure 9b] 1 is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage transport migration in coordination with another RAN node CU. [Figure 10a] 1 is a flowchart of an exemplary method, at a source F1 terminating donor CU of an IAB node, for managing DU migration of the IAB node to a target IAB topology, according to an embodiment of the present invention. [Figure 10b] 1 is a flowchart of an exemplary method for managing DU migration to a target IAB topology at an IAB node, according to an embodiment of the present invention. [Figure 10c] 10 is a flowchart illustrating exemplary steps performed at an IAB node to identify a target IAB donor CU, according to one or more embodiments of the present invention. [Figure 10d]1 is a flowchart of an exemplary method, in a target IAB donor CU, for managing DU migration of an IAB node to a target IAB topology managed by the target IAB donor CU, according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0030] 1 illustrates an exemplary communications system 100, particularly a mobile wireless communications system such as a fifth-generation (5G) new radio (NR) system, including a wireless integrated access and backhaul network supporting mobile IAB nodes. In the following description, example embodiments of the present invention will be described with reference to a 5G NR system, but it will be understood that the present invention is not intended to be limited to 5G NR systems and may be used in any wireless communications system having mobile base stations. In particular, the following description primarily uses terminology specific to 5G, but it will be understood that such terminology also applies to elements or processes performing equivalent functions in other communications systems.

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

[0032] The main base station 120, also referred to as the IAB donor 120, is connected to the core network 110 via a wired link 101, preferably optical fiber or any other wired means. In embodiments and examples of the present invention, the IAB donor 120 is a 5G NR gNB with the additional functionality to support IAB functionality as defined in the 3GPP TS 38.300 V17.2.0 specification.

[0033] To extend the network coverage of the IAB donor 120 and reach the remote UEs 132, 133, and 131, IAB stations 121 and 122, also referred to as IAB nodes 121 and 122, are installed by the operator. The IAB nodes 121 and 122 may overcome reachability issues caused by the presence of buildings 108 by acting as relay nodes between the IAB donor 120 and the UEs 132 and 133. The buildings 108 are obstacles that impede radio wave propagation, making it difficult for the UEs to directly connect and communicate with the IAB donor 120. This is especially true when communications between the IAB donor 120 and the UEs 132 and 133 operate at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

[0034] The IAB donor 120 also serves UEs 134 that are directly connected to the IAB donor 120. A mobile IAB station 123, also referred to as a mobile IAB node 123 or mIAB node 123, is an IAB node mounted on a vehicle 105 that provides network coverage and capacity extension, allowing the IAB donor 120 to reach onboard remote UEs, such as remote UE 135, and UEs in the vicinity of the IAB node 123, such as surrounding or remote UE 136.

[0035] Thus, IAB donor 120 and IAB nodes 121, 122, and 123 form a backhaul network or IAB network, or IAB topology, that accommodates UEs 132, 133, 131, 134, 135, and 136. In the following, the terms IAB network and IAB topology are used interchangeably.

[0036] The Integrated Access Backhaul (IAB) specifications are spread across several 3GPP standard documents, including: - TS 38.300 RAN Architecture (V17.2.0), - TS 38.321 MAC Protocol (V17.2.0), - TS38.331 Radio Resource Control (RRC) protocol (V17.2.0), - TS 38.340 Backhaul Application Protocol Layer (V17.2.0), - TS 38.401 RAN Architecture (V17.2.0), - TS38.423 Xn Application Protocol (V17.2.0), - TS 38.473 F1 Application Protocol (V17.2.0).

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

[0038] The IAB donor 120 is a logical node providing NR-based wireless backhaul, consisting of a central unit (CU or gNB-CU functionality) and connected donor distributed units (DU or gNB-DU functionality). The IAB-donor CU or donor CU (hereinafter also referred to as IAB-donor CU or IAB donor CU) hosts higher layer protocols such as the Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) protocols and controls the operation of one or more DUs. One or more IAB-donor DUs or donor DUs (hereinafter also referred to as IAB donor DUs or IAB donor DUs) include lower layer protocols such as RLC, MAC, and physical layer protocols. The IAB-donor CU or donor CU and IAB-donor DU or donor DU may be located remotely from each other or within the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. This is intended to terminate the NR access interface to the UE and next-hop IAB node, as well as the F1 protocol to the IAB donor gNB-CU function, as shown in Figures 2a and 2b, discussed below.

[0039] IAB nodes serving multiple wireless sectors are wirelessly backhauled to the IAB donor 120 via one or more hops over one or more intermediate IAB nodes, forming a directed acyclic graph (DAG) topology with the IAB donor at its root.

[0040] An IAB node consists of an IAB-Distributed Unit (IAB-DU) and an IAB-Mobile Termination (IAB-MT). The gNB-DU function on an IAB node, also referred to as the IAB-DU, enables downstream connectivity to the next-hop IAB or UE (towards the UE). The IAB-MT function includes, for example, physical layer, Layer 2, RRC, and non-access stratum (NAS) functions for connecting to the gNB-DU of an upstream IAB node (including the IAB donor 120, which in this case connects to the IAB donor gNB-CU and therefore to the core network 110 for initialization, registration, configuration, etc.).

[0041] In this DAG topology, the neighboring node on the IAB-DU interface is called a child node, and the neighboring node on the IAB-MT interface is called a parent node. Furthermore, the direction toward the child node is called downstream, and the direction toward the parent node is called upstream.

[0042] The IAB donor 120 (e.g., IAB donor CU) performs centralized management of resources, topology, and routes across the IAB topology, including, for example, configuring IAB nodes according to the network topology to perform proper routing of data packets.

[0043] 2a and 2b show a schematic of the stack of several protocol layers involved in IAB operation.

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

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

[0046] In the user plane, box 210 in the IAB donor CU and IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. A GTP-U tunnel is used to transport encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for more details), here box 210 in the IAB donor CU and IAB node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol that provides a best-effort datagram service and is compatible for use with the IP protocol.

[0047] In the control plane, box 210 denotes the F1 Application Protocol layer, and box 211 denotes the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (defined in 3GPP TS38.473 and TS38.401) provides signaling services or UE-related services between the IAB Donor CU and the IAB Node DU. These services include initialization, configuration, etc. The well-known SCTP layer provides reliable and in-order message delivery with congestion control. F1-U and F1-C rely on the IP transport layer between the IAB Donor CU and the IAB Node DU, as defined in 3GPP TS38.401.

[0048] Transport between the IAB-Donor CU and IAB-Donor DU uses the IP transport layer over a variety of media, such as wired or optical fiber, when the IAB-Donor CU is located remotely from the IAB-Donor DU, or locally when the IAB-Donor CU and IAB-Donor DU are virtually instantiated on the same physical machine. The IAB-specific transport between the IAB-Donor CU and IAB-Donor DU is specified in 3GPP TS 38.401.

[0049] L1 and L2 in Figure 2a represent the transport and physical layers, respectively, appropriate for the medium in use.

[0050] The IP layer may also be used for non-F1 traffic, such as operations, management, and maintenance traffic.

[0051] Over the wireless backhaul, the IP layer is itself transported over the Backhaul Adaptation Protocol (BAP) sublayer, which enables routing across multiple hops. The BAP sublayer is specified in TS 38.340.

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

[0053] In the upstream direction, upper layer packets are encapsulated by the BAP sublayer in the initiator IAB node (which may be the access IAB node if the upper layer packets come from a UE), thereby forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layers of intermediate IAB nodes (corresponding BAP entities in IAB-DUs and IAB-MTs), if any. The BAP packets are finally decapsulated by the BAP sublayer in IAB donor DUs.

[0054] In the BAP sublayer, packets are routed based on the BAP Routing ID contained in the BAP header. The BAP Routing ID is set by the BAP sublayer of the originating IAB donor DU or initiator IAB node (e.g., the network node in the IAB network that generates the BAP packet). Figure 3 shows 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 Release 17.2.0.

[0055] The payload section 307 is typically an IP packet. The header 30 includes fields 301 to 306. Field 301, called the D / C field, is a Boolean that indicates 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).

[0056] Fields 305 and 306 together indicate the BAP routing ID for the BAP packet. The BAP address field 305, also called the DESTINATION field, is located in the leftmost 10 bits, and the BAP path identification field 306, also called the PATH field, is located in the rightmost 10 bits.

[0057] Field 305 carries the BAP address (i.e., on the BAP sublayer) of the destination IAB node or IAB donor DU for the BAP packet. For routing purposes, each IAB node and IAB donor DU in the IAB network is configured with a unique BAP address assigned to it (by the IAB donor CU of the IAB network). Field 306 carries a path ID that identifies the routing path the BAP packet should take to this destination in the IAB topology. For routing purposes, the routing path, including the path ID, is configured in the IAB nodes of the IAB network (by the IAB donor CU of the IAB network).

[0058] The BAP header is added to a packet when it arrives at the BAP layer from higher layers and is stripped by the BAP layer when it reaches the destination node. The selection of a packet's BAP routing ID is configured by the IAB donor CU.

[0059] For example, when a BAP packet is generated by a node, i.e., by an IAB donor DU for downstream transmission or by an initiator for upstream transmission (which may be an access IAB node if the upper layer packet comes from a UE), the BAP header with the BAP routing ID is constructed by this node according to a configuration table defined in 3GPP TS38.340. This table is called a downlink traffic-routing ID mapping configuration table in the IAB donor DU or an uplink traffic-routing ID mapping configuration table in the initiator IAB node. In intermediate IAB nodes, the BAP header fields in the BAP packet to be forwarded are already specified.

[0060] As mentioned above, these configuration tables that define the BAP paths (and therefore the routing strategy and configuration of IAB nodes given the IAB network topology) are typically defined by an IAB donor CU and transmitted to IAB nodes to configure them.

[0061] To transmit messages over the 5G NR wireless medium, each IAB node implements three or more sublayers below the BAP sublayer: RLC, MAC, and PHY. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reassembly. It is also responsible for requesting retransmission of lost packets. The RLC layer is further described in TS 38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for user data and mapping logical channels to transport channels. MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the sender or transmitter side, the MAC encapsulates data packets issued by the RLC. It adds a header that carries information required for the MAC function. On the receiver side, the MAC decapsulates data packets issued by the PHY sublayer, removes their headers, and passes the remaining data to the RLC. The PHY sublayer provides the electrical interface to the transmission medium (air) by converting the information stream into a physical modulated signal and modulating the transmission wave frequency at the transmitter side. At the receiver side, the PHY sublayer converts the physical modulated signal back into an information stream. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, and TS 38.214.

[0062] Two other sublayers are used in the UE and IAB donor CU to pass messages towards the user plane or control plane: the Packet Data Convergence Protocol (PDCP) sublayer and either the Service Data Adaptation Protocol (SDAP) sublayer for user plane communication or the Radio Resource Control (RRC) sublayer for control plane communication.

[0063] The PDCP sublayer is responsible for IP header compression and decompression, encryption and decryption, and integrity protection of data packets as needed. It also ensures packet sequence numbers on the sending side and reorders packets on the receiving side. The PDCP sublayer is described in 3GPP TS38.323.

[0064] The SDAP sublayer 220 for the user plane handles quality of service. This is described in TS38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc. - not shown). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc.).

[0065] The RRC sublayer 220 for the control plane handles the configuration of protocol entities in the user plane protocol stack, as described in TS 38.331. It is responsible for, among other things, broadcasting the information needed for the UE to communicate with cells, sending paging messages, managing connections including bearer setup, mobility functions, configuring and reporting measurements, and handling device capabilities.

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

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

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

[0069] Figure 2b, derived from 3GPP TS 38.300 V17.2.0, shows 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 user equipment or IAB nodes. It manages the establishment of communication sessions and maintains communication as the IAB nodes or user equipment move. 5G NAS is described in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the core network that receives all connection and session-related information from UEs connected to IAB nodes, as well as similar information about the IAB nodes. The AMF is solely responsible for handling connection and mobility management tasks.

[0070] The IAB-MT establishes signaling radio bearers SRBs (bearers that carry RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted between the IAB-MT and its parent node over the NR-Uu interface.

[0071] FIG. 4 illustrates a schematic diagram of an exemplary communications device or station, in accordance with one or more exemplary embodiments of the present disclosure.

[0072] The communication device 400 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The communication device 400 preferably comprises a communication bus 413 to which the following are connected: A central processing unit 411, such as a microprocessor, referred to as a CPU. The central processing unit 411 may be a single processing unit or processor, or may include two or more processing units or processors that perform the processing necessary for the operation of the communications device 400. The number of processors and the allocation of processing functions to the central processing unit 411 are a matter of design choice for those skilled in the art. - Memory for storing data and computer programs containing instructions for operation of the communications device 400. The computer programs may include several different program elements (modules) or subroutines containing instructions for various operations for implementing methods according to one or more embodiments of the present invention. At least one communication interface 402 for communicating with other devices or nodes in a communication system, such as the communication system of Figure 1. The at least one communication interface 402 may be connected to a wireless communication network 403, such as a wireless communication network for 5G NR (e.g., according to Release 17 and / or a subsequent release), over which digital data packets or frames or control frames are transmitted. Frames are written for transmission from a FIFO transmit memory in RAM 412 to the communication interface, or read for reception from the communication interface, and written to a FIFO receive memory in RAM 412 under control of a software application running in CPU 411.

[0073] Each of the donor CU, donor DU, IAB node, and UE may be implemented in such a communication device / apparatus 100.

[0074] The memory may include: a read-only memory 407, called ROM, for storing a computer program for implementing the methods according to one or more embodiments of the invention. a random access memory 412, referred to as RAM, for storing executable code of the methods according to one or more embodiments of the invention, as well as registers adapted to record variables and parameters necessary to implement the methods according to one or more embodiments of the invention.

[0075] Optionally, the communication device 400 may also include the following components: - a data storage means 404, such as a hard disk, for storing a computer program for implementing the method according to one or more embodiments of the present invention. a disk drive 405 for a disk 406, the disk drive being adapted to read data from or write data to the disk 1106; 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 means.

[0076] In the exemplary configuration, the communications bus 413 provides communication and interoperability between various elements included in or connected to the communications device 400. The representation of a bus is not limiting, and in particular, a central processing unit is operable to communicate instructions to any element of the communications device 400 directly or by way of another element of the communications device 400.

[0077] Disk 406 may be replaced by an information carrier such as, for example, a compact disk (CD-ROM, rewritable or not), a ZIP disk, a USB key, or a memory card. Disk 406 is generally an information storage means readable by a microcomputer or microprocessor, whether integrated in a communications device or not, that is removable and that is suitable for storing one or more programs enabling the implementation of the methods according to embodiments of the present invention.

[0078] The executable code may optionally be stored either in a read-only memory 407, on the hard disk 404 or on a removable digital medium such as, for example, the aforementioned disk 406. According to any variant, the executable code of the program may be received by the communications network 403 via the interface 402 so as to be stored in one of the storage means of the communications device 400, such as the hard disk 404, before being executed.

[0079] The central processing unit 411 can be adapted to control and direct the execution of instructions or parts of the software code of the program(s) according to the invention, these instructions being stored in one of the aforementioned storage means. On power-up, the program(s) stored in a non-volatile memory, for example the hard disk 404 or the read-only memory 407, are transferred to the random access memory 412. The random access memory contains registers for storing the executable code of the program(s) as well as variables and parameters necessary to implement the invention.

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

[0081] 5 illustrates an example of an IAB communication system (or IAB network system) 500 in which embodiments and examples of the present invention may be implemented. In one exemplary implementation, the wireless links between IAB nodes and between IAB nodes and IAB donor DUs (referred to as BH wireless links) operate on the millimeter-wave frequency band (i.e., above 30 GHz), which is highly sensitive to wireless channel disturbances. The IAB network is also referred to as an IAB topology or topology, and therefore, in this application, the terms IAB network and IAB topology and topology are used interchangeably.

[0082] The IAB communication system 500 is comprised of three IAB networks or IAB topologies 5001, 5002, and 5003, each of which comprises a set of IAB nodes (e.g., a set may comprise 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 an initiator IAB node that generates BAP packets and one or more IAB nodes, such as intermediate or relay IAB nodes. Each of the IAB nodes communicates with at least one other IAB node via a wireless backhaul (BH) link. While FIG. 5 illustrates three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system with more than two IAB topologies, each of which comprises a set of IAB nodes and an IAB donor CU as described above.

[0083] As described above, each IAB node comprises a mobile termination (MT) portion or unit that is controlled and configured by the IAB donor using RRC messaging as defined in 3GPP TS 38.331, and a distributed unit (DU) portion that is controlled and configured by the IAB donor using F1-AP messaging as defined in 3GPP TS 38.473. For example, IAB node 510 comprises MT portion or unit 511 and DU portion 512.

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

[0085] The IAB topology 5002 includes an IAB donor CU 502 (identified as Donor 2-CU in FIG. 5 ) and its associated IAB donor DUs, IAB donor DU 505 (identified as Donor 2-DU1 in FIG. 5 ) and IAB donor DU 506 (identified as Donor 2-DU2 in FIG. 5 ), multiple IAB-nodes 530, 540, 550 similar to IAB nodes 121 and 122, and an IAB node 570 that may be similar to mobile IAB node 123. All IAB nodes may be access nodes that serve UEs, such as UE 580 served by mobile IAB node 570. The IAB topology 5002 is transparent to a UE 580 that connects to the donor CU 502 through a DU portion or DU unit 572 of the mobile IAB node 570. While FIG. 5 shows only one UE 580, it will be understood that there may be multiple UEs connected to the network nodes of the IAB communication system 500.

[0086] IAB topology 5003 includes IAB-Donor-CU 503 (identified as Donor3-CU in FIG. 5), its associated IAB-Donor-DU 507 (identified as Donor3-DU1 in FIG. 5), and IAB-Node 560, which is similar to IAB-Nodes 121 and 122.

[0087] The wired backhaul IP network interconnects IAB donor CUs 501, 502, and 503 with IAB donor DUs 504, 505, 506, and 507 via wired backhaul 508. For example, this wired backhaul 508 comprises fiber optic cable.

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

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

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

[0091] Each IAB-DU and IAB donor DU supports wireless communication within a coverage area called a cell (not shown in FIG. 5 ). In other words, each IAB-DU and IAB donor DU is associated with a cell. A wireless communication device (such as a UE or other IAB node) located within the cell can establish a communication link with a node serving the cell (i.e., an IAB-DU or IAB donor DU) to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the Internet, etc.) via the node.

[0092] 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 operates as an F1-terminating donor CU (also referred to as an F1-terminating IAB-donor CU or an F1 donor CU). When moving, given the IAB topology 5002, particularly its proximity to the IAB node 530 when the mobile IAB node 570 is in the position indicated by the dotted line in FIG. 5, the mobile IAB node 570 may establish a wireless BH link with the IAB node 530. Such a BH link is possible for fixed IAB nodes and is highly likely to occur for a mobile IAB node, such as the IAB node 570, moving in the direction of the IAB topology 5002 (indicated by the arrow 590 in FIG. 5).

[0093] The F1 donor CU 501 may then have decided to migrate the MT portion 571 of the IAB node 570 toward the IAB topology controlled by the donor CU 502. This donor CU 502 has become a non-F1-terminated donor CU (which may also be referred to as a non-F1-terminated IAB-donor CU or a non-F1 donor CU or an RRC-terminated donor CU or an RRC-donor CU) for the IAB node 570 (i.e., the MT portion 571 of the IAB node 570 is migrated toward the parent IAB node 530). To this end, the F1 donor CU 501 may have initiated the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 Section 8.17.3.1 or Section 8.17.3.2 (if the IAB node 570 has descendant IAB nodes). As a result, the IAB node 501 still belongs to the IAB topology 5001 and has its F1 connection to the donor CU 501, but its RRC connection is now to the donor CU2 502. After that procedure, the IAB donor CU 501 can request migration of backhaul traffic (e.g., user traffic, control traffic) associated with the IAB node 570 to the IAB topology 5002 (i.e., through the donor DU 505). In this case, the donor CU 501 triggers the IAB transport migration management procedure specified in TS38.423 V17.2.0 Section 8.5.2. In an IAB communication system, all traffic communicated over the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Therefore, the traffic or backhaul traffic that is offloaded or migrated is F1 traffic and can include control traffic and user traffic.

[0094] While the mobile IAB node 870 is still moving in the direction indicated by arrow 590, the MT portion 571 of the IAB node 570 may be being migrated by the non-F1 donor CU 502 toward the parent IAB node 550 using the backhaul link 5050 between the IAB node 570 and the IAB node 570. To this end, the non-F1 donor CU 502 may have applied the intra-CU topology adaptation procedure described in TS 38.401 V17.2.0 Section 8.2.3.1 (or Section 8.17.3.2) to result in a successive MT migration of the IAB node 570 to a new single parent IAB node 550 (or another MT migration to another IAB node). Additionally, the IAB node 501 has an F1 connection with donor CU 501 and an RRC connection with donor CU2 502.

[0095] After being notified to use donor DU 506 instead of donor DU 505 to route F1 traffic related to IAB node 570, donor CU 501 can request migration of traffic related to IAB node 570 to IAB topology 5002. In this case, donor CU 501 triggers the IAB transport migration management procedure specified in TS38.423 V17.2.0 Section 8.5.2.

[0096] Furthermore, while moving toward the IAB topology 5003, this time controlled by the donor CU 503, the IAB node 570 may be in a position where the backhaul link 5060 with the IAB node 560 may have better quality than the backhaul link 5050 with the IAB node 550. Therefore, the donor CU 502 may apply the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or 8.17.3.2. After this successive MT migration, the IAB node 501 still belongs to the IAB topology 5001 and has an F1 connection with the donor CU 501, but its RRC connection is now with the donor CU 503, and the donor CU 503 becomes a non-F1 terminating donor CU (or a non-F1 donor CU or an RRC donor CU). However, donor CU501 needs to be notified of the new non-F1 donor CU503 for IAB node 570 and the new donor DU507 to redirect the offloaded traffic (F1 traffic, control traffic, user traffic) through donor DU507 instead of donor DU506.

[0097] In all the above-mentioned MT migration cases, the UE 580 is still connected to the donor CU 501 via the DU part or unit 572 of the mobile IAB node 570. If the IAB node 570 has some child IAB nodes, such child IAB nodes still belong to the IAB topology 5001 and are still fully controlled by the donor CU 501 (via F1 and RRC connections).

[0098] Regardless of the state of migration of the MT portion 571 of the IAB node 570, that is, whether the MT portion 571 of the IAB node 570 has migrated to the IAB topology 5002 or the IAB topology 5003, and therefore regardless of whether the IAB node 570 has a non-F1 terminating donor CU, and if so, whether it has a non-F1 terminating donor CU 502 or 503, the F1 donor CU 501 can decide to perform migration of the DU portion of the IAB node 570. The reason for performing DU migration may be to reduce the processing load on the F1 donor CU 501 or because the IAB node 570 is geographically far from the F1 donor CU 501 and is close to an area where there is no Xn connection between the F1 donor CU 501 and the target donor CU. After deciding to perform DU migration of IAB node 570, F1 donor CU 501 must also decide which donor CU (referred to as target F1 donor CU) to perform DU migration toward. This may be DU migration to the current non-F1 terminating donor CU (i.e., the default choice), or if there is a current non-F1 terminating donor CU, this non-F1 terminating donor CU may become the target F1 donor CU, or migration to another target F1 donor CU. For example, if IAB node 570 is mobile and its trajectory is predictable (e.g., in the case of a bus or train), F1 donor CU 501 may know an appropriate target F1 donor CU that controls the cell where IAB node 570 will soon connect to the network. For example, while the non-F1 terminating donor CU of IAB node 570 is donor CU 502, F1 donor CU may determine that DU migration of IAB node 570 should be performed directly toward donor CU 503. This is because the IAB node 570 may quickly pass through the IAB topology 5002 controlled by the donor CU 502 and not remain there.By not performing DU migration to donor CU 502 and instead performing DU migration to donor CU 503, it is possible to avoid intermediate protocol messages related to DU migration of IAB node 570. When DU migration is performed, handover of the UE being served by IAB node 570 must also be performed. Therefore, by not performing DU migration to donor CU 502, it is possible to avoid intermediate handover of the UE being served by IAB node 570 to donor CU 502.

[0099] The procedure for performing DU migration and UE handover towards the selected target F1 donor CU will be described in more detail with reference to the following figures.

[0100] FIG. 6 illustrates an example IAB node architecture 600 that enables migration of a DU of an IAB node from a source IAB topology to a target IAB topology (DU migration).

[0101] IAB node 601 may be a mobile IAB node, such as IAB node 570, and is composed of an IAB-MT portion or unit, IAB-MT 610 (similar to MT portion 571 of IAB node 570 in FIG. 5), an IAB-DU1 611 portion or unit, and an IAB-DU2 612 portion or unit. IAB-DU1 and IAB-DU2 are two logical DU entities that share the same hardware at the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), but in another example, they rely on separate physical layers. In DU migration of IAB node 601, both logical DUs are active. One logical DU terminates the F1 interface with the source F1 donor CU (such as donor CU 501 in FIG. 5), and the other logical DU terminates the F1 interface with the target F1 donor CU (such as donor CU 502 or 503 in FIG. 5). In other cases (i.e., when DU migration is not performed), only one logical DU is sufficient for IAB operation. For example, referring to the IAB communication system of FIG. 5, the F1-terminating donor CU of IAB node 601 (i.e., IAB node 570) may be donor CU 501 operating as a source F1 donor CU. When the source F1-donor CU 501 determines that IAB node 570 is moving toward or passing through an IAB topology 5002 that includes network nodes (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550) managed by IAB donor CU 502, the source F1-donor CU 501 can identify IAB donor CU 502 as a suitable target F1 donor CU.Alternatively, if an IAB node is connected to a parent IAB node or parent IAB donor DU of an IAB topology 5001 managed by donor CU 501 as an F1 terminating donor CU, and the IAB node is stationary but located so as to be near or in close proximity to one or more IAB nodes in a neighboring IAB topology (e.g., IAB topology 5002), the source F1 donor CU 501 may determine that the IAB node is likely to soon connect to an IAB node in the neighboring IAB topology 5002 (e.g., based on radio signals received at the IAB node, based on signal measurements from all IAB nodes present in the vicinity of the IAB node) and determine that the IAB donor CU 502 is a suitable target F1 donor CU.

[0102] Before DU migration, for example, UE 602 (such as UE 580 in FIG. 5) is connected to source F1 donor CU 501 via access link 621 in the cell served by logical DU IAB-DU1 611, and logical DU IAB-DU2 612 is deactivated. During DU migration, logical DU IAB-DU2 612 is activated and connected to target F1 donor CU 502. This allows UE 602 to be connected to target F1 donor CU 502 through logical DU IAB-DU2 612 via link 622 in the cell served by logical DU IAB-DU2 612. Activation of logical DU IAB-DU2 612 is triggered by the source F1 donor CU and may be performed in the procedure described with reference to FIGS. 8a and 8b. When the handover of the UE 602 is completed from the cell controlled by the logical DU IAB-DU1 611 to the cell controlled by the logical DU IAB-DU2 612, the logical DU IAB-DU1 611 may be deactivated. This deactivation may be triggered by the source F1 donor CU 501 according to the procedure described with reference to Figure 8c after detecting that all UEs have completed handover from the cell served by IAB-DU1 611.

[0103] An example method according to one or more embodiments of the present invention for enabling DU migration of an IAB node with or without MT migration (multiple times) and for informing the IAB node of the identity of a target donor CU to enable handover of a UE to the target donor CU served by the IAB node is described below. While the following method / apparatus is primarily 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 may also be applied to fixed IAB nodes, for example, located at the edge of one IAB topology and in proximity or close to one or more IAB nodes in an adjacent IAB topology.

[0104] 7 is a schematic and simplified diagram 700 illustrating an example message flow according to one or more embodiments for performing a DU migration of an IAB node, which may be performed with or without MT migration(s) and may include informing the IAB node of information regarding a target donor CU to enable handover of a UE being served by the migrating IAB node to the target donor CU.

[0105] 7 shows a UE 708 (such as UE 580), a source F1 donor CU 703 (such as donor CU 501), a target F1 donor CU 707 (such as donor CU 503), and a core network (5GC) 702 (such as core network 110 of FIG. 1). FIG. 7 also shows an IAB node 701, which may be a mobile IAB node such as IAB node 570, consisting of an IAB-MT portion or unit IAB-MT 704, a DU portion or unit IAB-DU1 705 (e.g., a source or first logical DU entity), and a DU portion or unit IAB-DU2 706 (e.g., a target or second logical DU entity). Each of the first and second DU logical entities 705, 706 serves one or more cells. The cell of IAB-DU1 705 is identified by a different identifier (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) than the cell of IAB-DU1 705. IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for the BAP layer, RLC layer, and MAC layer. In one example, they share the same physical layer (i.e., the same hardware resources), but in another example, they rely on separate physical layers. If IAB-MT 704 was not migrated, the non-F1 donor CU for IAB node 701 could be the source F1 donor CU 703 itself. The non-F1 donor CU for IAB node 701 could be the target F1 donor CU 707 if IAB-MT 704 was previously migrated toward the target F1 donor CU 707, or it could be another donor CU (shown in the appended figure) if IAB-MT 704 was previously migrated toward this other donor CU.

[0106] At the start of the flow, IAB node 701 belongs to a source IAB topology controlled by source F1 donor CU 703. UE 708 is served by IAB node 701 via the cell of IAB-DU1 705 (e.g., a DU of IAB node 701 has an active IAB-DU1 705 with an F1 connection with source F1 IAB donor CU 703), while logical IAB-DU2 706 is inactive. User data in the downstream direction is provided from 5GC 702 to source F1 donor CU 703 via bearer 710, then transmitted via backhaul bearer 711 to logical DU IAB-DU1 705 of IAB node 701, and finally transmitted to UE 708 via data radio bearer 712. The backhaul bearer 711 may be established in the source IAB topology controlled by the source F1 donor CU 703, or (if the IAB-MT 704 was previously migrated towards this non-F1 donor CU) in the IAB topology controlled by a non-F1 donor CU of the IAB node 701. Upstream user data (not shown) is transmitted in the reverse direction over this same bearer.

[0107] The IAB-MT704 may transmit a measurement report (not shown in FIG. 7) as a result of measurements performed periodically based on signals received from the serving cell and one or more target cells (e.g., signal synchronization blocks (SSBs) transmitted by the serving cell and target cells). This measurement report is sent to a non-F1 terminated donor CU if the IAB-MT704 has previously migrated to that non-F1 terminated donor CU, or to an F1 terminated donor CU (e.g., source F1 donor CU703) if the IAB-MT704 has not migrated from an F1 terminated donor CU. The target cell may be a cell neighboring the serving cell or the source cell (i.e., the current serving cell). The measurement report is generated when the IAB-MT704 detects at least one SSB that meets a predefined criterion (e.g., received power exceeding a predetermined threshold), The measurement report may be transmitted to provide radio link quality information of different cells in the vicinity of the IAB node 701. The measurement report includes an identifier for each cell, allowing 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, to identify the target donor CU associated with that cell. In fact, the identity of the donor CU can be deduced from the Physical Cell Identifier (PCI), which is broadcast in each cell managed by this donor CU in synchronization signals, and / or from the New Radio Cell Group Identifier (NCGI), which is also broadcast in each cell managed by this donor CU in system information block (SIB) messages. The PCI and / or NCGI may be reported by the IAB node 701 in the measurement report.

[0108] Based on the received measurement report, the non-F1 donor CU, if the IAB-MT 704 is migrated, or the F1 terminating donor CU 703, if the IAB-MT 704 is not migrated, may detect that the IAB node 701 is receiving radio signals with better quality in the target cell of the target parent IAB node than in the source serving cell. The non-F1 donor CU, if the IAB-MT 704 is migrated, or the F1 terminating donor CU 703, if the IAB-MT 704 is not migrated, may decide to apply a procedure to perform migration of the IAB-MT 704 towards the target parent IAB node, which may belong to the same IAB topology (intra-CU topology adaptation) or a different IAB topology (inter-CU topology adaptation). In either case, if the IAB-MT 704 has been migrated, the source F1 donor CU 703 is notified of this MT migration by the non-F1 donor CU; if the IAB-MT 704 has not been migrated, the source F1 donor CU 703 is aware of this information itself because it made the decision to perform MT migration directly based on the measurement report received from the IAB node 701. This information may be used by the source F1 donor CU 703 to trigger DU migration of the IAB node 701. In another example, the non-F1 donor CU may relay information in the measurement report received from the IAB node 701 to the source F1 donor CU 703. In this way, the source F1 donor CU 703 may make a DU migration decision for the IAB node 701 directly based on the measurement report relayed by the non-F1 donor CU.

[0109] In this manner, the source F1 donor CU 703 decides to migrate the DU of the IAB node from the IAB topology of the source F1 donor CU 703 to another IAB topology of the target IAB donor CU. This decision may be based on determining that the MT of the IAB node has completed migration toward a new parent IAB node. Another example of a trigger event for deciding to migrate the DU of the IAB node may be based on detecting that the MT of the IAB node has migrated from a first IAB topology to a second IAB topology and a known (predefined) trajectory of the IAB node, which indicates to the source F1 donor CU that the MT will later migrate to a third IAB topology. In this case, to avoid signaling messages for DU migration / UE handover to the second IAB topology, the DU is directly migrated toward the third IAB topology. Another example of a trigger event for deciding to migrate a DU of an IAB node may include detecting a processing load level at a source F1 donor CU that exceeds a predetermined threshold, in which case DU migration is triggered and the selection of a target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU.

[0110] In response to a decision or determination by or made by the source F1 donor CU 703 to perform DU migration of the IAB node 701 to another IAB topology managed by another donor CU, which will be the target F1 donor CU 707, a 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 request may require activation of a second logical IAB-DU2 706 in the mobile IAB node 701, and the first step 720 may include activation of the second logical DU-DU2 706 in the mobile IAB node 701. This operation is performed using, for example, the procedure described with reference to Figures 8a and 8b. In particular, the message (e.g., 803 in FIG. 8a) sent from the source F1 donor CU 703 to the IAB node 701 to activate the second logical 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, so that a new F1 connection or F1 association (e.g., F1 AP interface connection) can be established with the target donor CU 707 (between the IAB-DU2 706 and the target donor CU 707). If the address of the target F1 donor CU is not included in the activation request, then by default, if the IAB-MT 704 has been migrated to a non-F1 donor CU, the non-F1 donor CU is considered the target F1 donor CU. In this case, the IAB node 701 has already been informed of the identification information (e.g., TNL address / IP address) of the target donor CU when the IAB-MT 704 was migrated to the non-F1 donor CU. In other words, the source F1 donor CU 703 may transmit identification information to identify the target IAB donor CU unless the IAB-MT 704 has been migrated to a non-F1 donor CU. Alternatively, the source F1 donor CU 703 may transmit identification information to identify the non-F1 donor CU as the target IAB donor CU.

[0111] After the source F1 donor CU 703 decides to migrate the DU of the IAB node 701 and the IAB-DU2 706 is activated, the IAB-DU2 706 may send an F1 setup request message (e.g., 813 in FIG. 8b) to the target F1 donor CU 707 as a request to establish an F1 connection between the IAB node 701 and the target F1 donor CU 707. This message may include identification information for identifying the source F1 donor CU 703 of the IAB node 701, such as the TNL address (i.e., IP address) or identifier (i.e., global NG-RAN node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the source F1 donor CU 703. This message may also include a TNL address (i.e., IP address) or identifier (i.e., global NG-RAN node ID as specified in section 9.2.2.3 of TS 38.423 V17.2.0) to identify the non-F1 donor CU of the IAB node 701 if the IAB-MT 704 of the IAB node 701 has previously migrated to this non-F1 donor CU (not shown in FIG. 7). This is the case if the IAB-MT 704 of the IAB node 701 has previously migrated to this non-F1 donor CU (not shown in FIG. 7). The destination address of the F1 Setup Request message is the target F1 donor CU 707, and when this IP packet is received at a donor DU on the F1 path for the IAB node 701, it can be routed to the target F1 donor CU 707 through the wired backhaul (508 in FIG. 5). For example, in the case of IAB node 570 (corresponding to IAB node 701) shown in FIG. 5, which is connected to IAB node 550 via backhaul link 5050, and an MT of IAB node 570 (MT 571 corresponding to IAB-MT 704 in FIG. 7) is migrated to a non-F1 donor CU 502, and IAB donor CU 501 is the source F1 donor CU, the F1 path between F1 donor CU 501 and IAB node 570 uses donor DU 506.If the IAB donor CU 503 is identified as the target F1 donor CU (e.g., target F1 donor CU 707), an F1 setup request message for the target F1 donor CU (e.g., donor CU 503) is sent to the donor DU 506 via the IAB nodes 550, 540, and then routed from there to the target F1 donor CU 503 through the wired backhaul (508 in FIG. 5). In an F1 setup response (e.g., 814 in FIG. 8b), the target F1 donor CU 707 (the donor CU 503 in the example above described with reference to FIG. 5) may request the IAB-DU2 706 of the IAB node 701 to activate a new cell with its identifiers (PCI, NCGI). Typically, a DU activates / deactivates a cell under the control of the donor CU that controls the DU. See, for example, TS 38.473 section 8.2.3.2.

[0112] After the procedure described with reference to FIG. 8b, the target F1 donor CU707 may notify the source F1 donor CU705 about the activation of the new cell from IAB-DU2706 of the IAB node 701, for example using the procedure described with reference to FIG. 9a.

[0113] A next step 730 consists of handing over a UE served by the IAB node 701 (e.g., the UE 708 in FIG. 7 ) from the cell of the first logical DU IAB-DU1 705 to the cell of the second logical DU IAB-DU2 706. This procedure may be the standardized procedure described in TS 38.300 Section 9.2.3.2 (Handover) or the standardized procedure described in TS 38.300 Section 9.2.3.4 (Conditional Handover). As an example, to trigger the handover of the UE 708, the source F1 donor CU 703 sends a handover request message to the target F1 donor CU 707, including necessary information about the UE 708 to be handed over (e.g., identification information for identifying the UE, UE context information (e.g., security context (e.g., security parameters and UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearers, etc.). TS 38.423 Section 9.1.1.1 provides details about the contents of the HANDOVER REQUEST message. After an admission control step in the target F1 donor CU 707 to determine whether the handover of the UE 708 is acceptable, if the target F1 donor CU 707 accepts the request, the target F1 donor CU 707 sends a HANDOVER ACKNOWLEDGE message to the source F1 donor CU 705, which includes configuration information of the UE 708 for the handover. This configuration information may include radio configuration information (e.g., frequency, radio bearer configuration, etc.) that the UE 708 uses to connect to the identified target cell of the second logical DU IAB-DU2 706. The HANDOVER ACKNOWLEDGE may include respective identifiers of one or more new cells (e.g., target cells) activated in IAB-DU2 706. The source F1 donor CU 705 then sends this configuration information in an RRC RECONFIGURATION message to the UE 708 to connect to the target cell IAB-DU2 706.The RRC reconfiguration message (specified in TS 38.331) is embedded in an F1 message DL RRC message transfer (specified in TS 38.473) and sent to IAB-DU1 705, which relays it to the UE 708. After receiving this configuration information, the UE 708 performs a random access procedure in the target cell in IAB-DU2 706 to obtain uplink resources, and then sends an RRC reconfiguration complete message to the target F1 donor CU 707. The RRC reconfiguration complete message (specified in TS 38.331) is sent to IAB-DU2 706, and further embedded in an F1 message UL RRC MESSAGE TRANSFER (specified in TS 38.473) and sent to the target F1 donor CU 707. The source F1 donor CU 705 may be notified of the handover completion of the UE 708 via a HANDOVER SUCCESS (specified in TS 38.423) received from the target F1 donor CU 707.

[0114] The target F1 donor CU 707 may perform a path switch procedure toward the core network 702 to request delivery of user data associated with the UE 708. For example, the target F1 donor CU 707 may perform the path switch handshake procedure described in section 8.4.4 of 3GPP TS 38.413 v17.2.0.

[0115] The target F1 donor CU 707 must then establish a backhaul path between it and the migrated IAB node 701 either within its own topology (i.e., if the target F1 donor CU 707 is a non-F1 terminating donor CU for the IAB node 701 because the IAB-MT 704 was previously migrated to the target F1 donor CU 707), or through the IAB node 701's non-F1 donor CU (not shown in FIG. 7) if no backhaul path to reach the IAB node 701 exists in the IAB topology controlled by the target F1 donor CU 707 (i.e., the IAB-MT 704 and IAB-DU2 706 are connected to different donor CUs). In this latter case, the target F1 donor CU 707 may trigger the procedure described with reference to FIG. 9b to request traffic migration to the IAB node 701's non-F1 donor CU. To give an example of this latter case with reference to Figure 5, IAB node 701 is IAB node 570 connected to IAB node 550 via backhaul link 5050, and the MT of IAB node 570 (MT 571 corresponding to IAB-MT 704 in Figure 7) has been migrated to non-F1 donor CU 502, and IAB donor CU 501 is an F1 donor CU. When a DU of IAB node 570 (DU 572 corresponding to IAB-DU2 706 in FIG. 7) is migrated to target donor CU 503 and has an F1 connection with F1 donor CU 503, and MT 571 continues to maintain an RRC connection via non-F1 donor CU 502, the backhaul path between IAB node 570 is configured within IAB topology 5002 controlled by IAB donor CU 502 (i.e., a backhaul path reaching IAB node 570 via IAB donor DU 506, IAB nodes 540 and 550) and is performed by a traffic migration procedure (e.g., the procedure described with reference to FIG. 9b).

[0116] After handover and path switching of the UE 708, user data in the downstream direction is transmitted by the core network 702 via bearer 740 to the target F1 donor CU 707, then via backhaul bearer 741 to the logical DU IAB-DU2 706 of the IAB node 701, and finally via data radio bearer 742 to the UE 708. The backhaul bearer 741 may be established in an IAB topology controlled by the target F1 donor CU 707 or in an IAB topology controlled by a non-F1 donor CU of the IAB node 707 (e.g., depending on whether the IAB-MT 704 and IAB-DU2 706 of the IAB node 701 are connected to different donor CUs). User data in the upstream direction (not shown) is transmitted in the reverse direction via a similar bearer.

[0117] Once the handover of all UEs served by IAB-DU1 705 of IAB node 701 is complete, the source F1 donor CU 703 may deactivate the logical DU IAB-DU1 705 of the mobile IAB node 701 through the procedure described with reference to Figure 8c. This is generally represented by procedure 735 in Figure 7.

[0118] The source F1 donor CU 705 may also release traffic (user traffic, control traffic) associated with UEs served by the IAB node 701 via the IAB-DU1 705. If the traffic is offloaded in an IAB topology controlled by another donor CU, the source F1 donor CU 705 may request traffic release from the other donor CUs by applying the procedure described with reference to Figure 9b. This is generally represented by procedure 735 in Figure 7.

[0119] FIG. 8a is a schematic and simplified diagram 800 flow chart illustrating an exemplary message flow of a procedure for performing activation of a logical DU according to one embodiment of the present invention.

[0120] This diagram shows: The RAN node DU 801 may be a DU of an IAB node, such as the IAB-DU 572 of the IAB node 570 in FIG. 5 (and the IAB-DU1 705 of the IAB node 701 in FIG. 7). The RAN node CU802 may be an IAB donor CU, such as the IAB donor CU501 in FIG. 5 (and the source F1 donor CU703 in FIG. 7).

[0121] The message CONFIGURATION REQUEST 803 is sent by the RAN node CU 802 to the RAN node DU 801 to request activation of a new cell controlled by the RAN node DU 801, or to request activation of a logical DU, or to request deactivation of a cell 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 in FIG. 7) that will connect to the logical DU once activated. For example, the CONFIGURATION REQUEST 803 may be sent by 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.

[0122] The RAN node DU 801 may confirm the request with a CONFIGURATION RESPONSE 804 message sent to the RAN node CU 802 .

[0123] As an example, the flow of Figure 8a corresponds to the procedure GNB-CU CONFIGURATION UPDATE PROCEDURE described in TS 38.473 V17.0.0 section 8.2.5, message 803 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, and message 804 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11.

[0124] The message GNB-CU CONFIGURATION UPDATE includes an information element (IE) "Cells to be activated List" indicating a list of new cells to be activated in the RAN node DU 801. For example, referring to FIG. 7, the GNB-CU CONFIGURATION UPDATE includes information for activating the new cells indicated in the IE "Cells to be Activated List". The new cells may be served by the first logical DU entity 705 in the IAB node 701. The activated cells indicate cells controlled by the RAN node DU 801 that received the request. The associated PCI and NCGI values ​​to be used by the RAN node DU 801 may also be provided.

[0125] The message GNB-CU CONFIGURATION UPDATE may also include an information element (IE) "Cells to be Deactivated List" indicating the list cells to be deactivated. The cells to be deactivated indicate cells controlled by the RAN node DU 801 that received the request. For example, referring to Figure 7, the GNB-CU CONFIGURATION UPDATE may include information to deactivate cells currently served by the first logical DU entity 705 at the IAB node 701.

[0126] According to one example, a new IE, Second DU Activation, may be added to the message 803 in the form of a Boolean value (e.g., a one-bit IE) to request activation of a 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 another value (i.e., “1” or “0”) means that activation of the second logical DU is requested. This IE may be complemented by a new IE indicating that the F1 setup is for the purpose of DU migration to the target RAN node CU (in other words, the IE indicating a request to establish an F1 connection is related to DU migration of a DU of an 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 an 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 may also provide a list of identifiers (e.g., PCI and / or NCGI) of cells controlled by the first logic DU 705 at the IAB node 701, with mapping provided with identifiers of cells to be activated. For example, a mapping may not be needed for all active cells controlled by the first logic DU 705, and only identifiers of cells that are mapped to identifiers of cells activated and controlled by the second logic DU 706 may be included in the message 803.

[0127] Additionally, a new IE (eg, Target TNL Address IE) may be added to identify the target RAN node CU to which the F1 connection is to be set up.

[0128] To complete the setup of the new logical DU in the IAB node, the procedure described with reference to Figure 8b may be used.

[0129] FIG. 8b is a schematic and simplified diagram 810 illustrating an exemplary message flow of a procedure for setting up a logical DU to establish an F1 connection with a target IAB donor CU, according to one embodiment of the present invention.

[0130] This diagram shows: The RAN node DU 811 may be a DU of an IAB-node DU, such as the IAB-DU 572 of the IAB node 570 in FIG. 5 (and the IAB-DU2 706 of the IAB node 701 in FIG. 7). RAN node CU812 may be an IAB donor CU such as IAB donor CU503 in FIG. 5 (and target F1 donor CU707 in FIG. 7).

[0131] The SETUP REQUEST message 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 may be sent by the IAB node (e.g., by the second logical DU entity 706 activated in the IAB node 701) to the target IAB donor CU 707 to request the setup of an F1 connection between the target IAB donor CU and the IAB node (e.g., using the second logical DU entity 706 of the IAB node 701). The SETUP REQUEST message 813 may be sent after an activation request, as described with reference to FIG. 8a. This SETUP REQUEST message 813 may include an indication that the F1 setup relates to a DU migration of the RAN node embedding the RAN node DU 811 (e.g., information to indicate the request to establish an F1 connection related to the DU migration of the DU of the IAB node) and / or the number of cells to be activated along with the activation of the logical DU. This SETUP REQUEST message 813 may optionally include identifiers (e.g., PCI and / or NCGI) of active cells controlled by the first logical DU 705 and / or identifiers (e.g., PCI and / or NCGI) of active cells controlled by the first logical DU 705 for which a mapping with an identifier of a cell to be activated is provided (as discussed above). This SETUP REQUEST message 813 may include a request for mapping between identifiers (e.g., PCI and / or NCGI) of active cells controlled by the first logical DU and identifiers of cells to be activated (e.g., in the second logical DU of the IAB node). This SETUP REQUEST message 813 may include a TNL address (i.e., IP address) or identifier (i.e., global NG-RAN node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of a RAN node CU that terminates the F1 connection of the RAN node DU 811 (e.g., source IAB donor CU 703).This message may contain the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU that will terminate the non-F1 (i.e., RRC) connection of the RAN node DU 811. This is the case when a MT (e.g., mMT 571 of IAB node 570 or the corresponding IAB-MT 704 of IAB node 701) is being migrated to a RAN node CU (which is now a non-F1 donor CU).

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

[0133] According to one example, the flow of Figure 8b corresponds to the procedure F1 SETUP described in TS 38.473 V17.2.0 section 8.2.3, message 813 corresponds to the message F1 SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4, and message 814 corresponds to the message F1 SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5. The message F1 SETUP RESPONSE contains an information element (IE) "Cells to be Activated List" indicating a list of new cells to be activated. The activated cells are cells controlled by the RAN node DU 811 that received the response.

[0134] FIG. 8c is a schematic and simplified diagram 820 illustrating an example message flow of a procedure for removing a logical DU.

[0135] This diagram shows: The RAN node DU 821 may be a DU of an IAB-node DU, such as the IAB-DU 572 of the IAB node 570 in FIG. 5 (and the IAB-DU1 705 of the IAB node 701 in FIG. 7). The RAN node CU 822 may be an IAB donor CU, such as the IAB donor CU 501 in FIG. 5 (and the source F1 donor CU 703 in FIG. 7).

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

[0137] RAN node DU 821 responds with message REMOVAL RESPONSE 814 sent to RAN node CU 822.

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

[0139] FIG. 8d is a schematic and simplified diagram 830 illustrating an example message flow of a procedure used by a logical DU to notify an IAB donor CU of a configuration change, according to one example.

[0140] This diagram shows: The RAN node DU 831 may be a DU of an IAB-node DU, such as the IAB-DU 572 of the IAB-node 570 in FIG. 5 (and the IAB-DU1 705 of the IAB node 701 in FIG. 7). The RAN node CU 832 may be an IAB donor CU, such as the IAB donor CU 501 in FIG. 5 (and the source F1 donor CU 703 in FIG. 7).

[0141] The CONFIGURATION UPDATE 833 message is sent by the RAN node DU 831 to the RAN node CU 832 to indicate a configuration change of the RAN node (e.g., IAB node 570, 701) that embeds the RAN node DU 831. The CONFIGURATION UPDATE message 833 may also 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 upon DU migration of the RAN node that embeds the RAN node DU 831. That is, it is a report of a new F1 connection between a second logical DU activated in the RAN node (e.g., IAB node 701) that embeds the RAN node DU 831 and a target F1 terminating donor CU (e.g., target F1 terminating donor CU 707). This message 833 may include an identifier of the target RAN node CU (e.g., target F1 donor CU 707). The message 833 may also include identifiers (e.g., PCI and / or NCGI) of cells activated in a second logical DU of the RAN node that embeds the RAN node DU 831. The message 833 may additionally or alternatively include a mapping between identifiers of cells controlled by the RAN node DU 831 and identifiers of cells activated in this second logical DU. For example, with reference to FIG. 7 , the message 833 is sent by the first logical DU entity 705 activated in the IAB node 701 to the source IAB donor CU 703 to indicate completion of the F1 setup procedure towards the target IAB donor CU 707. Optionally, a mapping between identifiers of cells activated in the second logical DU 706 and identifiers of cells controlled by the first logical DU 705 is sent together with identifiers of cells activated in the second logical DU 706.This configuration update message 833 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU (e.g., target F1 donor CU 707) that will terminate the new F1 connection of the RAN node embedding the RAN node DU 831.

[0142] Message 833 may indicate the success or failure of the F1 setup procedure. In the event of a failure of the F1 setup procedure (e.g., an inability to establish an F1 connection), message 833 may also indicate the cause of the failure to set up the F1 connection.

[0143] The RAN node CU 832 may reply or respond with a message CONFIGURTION ACKNOWLEDGE 834 sent to the RAN node DU 831. According to one example, the flow of Figure 8d corresponds to the procedure gNB-DU CONFIGURATION UPDATE as described in TS 38.473 V17.2.0 section 8.2.4, modified to include the information elements described above. Message 833 corresponds to the message GNB-DU CONFIGURATION UPDATE as described in TS 38.473 V17.2.0 section 9.2.1.7, and message 834 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE as described in TS 38.473 V17.2.0 section 9.2.1.8.

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

[0145] FIG. 9a is a schematic and simplified diagram 900 illustrating an example message flow of a procedure used by a RAN node CU to report cell activation to another RAN node CU, according to an embodiment of the present invention.

[0146] This figure shows two RAN nodes, RAN node CUa 901 and RAN node CUb 902, which may be two IAB donor CUs among IAB donor CUs 501, 502, and 503 in Figure 5. For 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.

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

[0148] RAN node CUb 902 responds by sending message CONFIGURATION ACKNOWLEDGE 904 to RAN node CUa 901.

[0149] According to one example, Figure 9a corresponds to the procedure NG-RAN node configuration update as described in TS 38.423 V17.2.0 section 8.4.2, message 903 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE as described in TS 38.423 V17.2.0 section 9.1.3.4, and message 904 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE as described in TS 38.423 V17.2.0 section 9.1.3.5.

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

[0151] This figure shows two RAN nodes, RAN node CUa 911 and RAN node CUb 912, which may be two IAB donor CUs among IAB donor CUs 501, 502 and 503 shown in FIG.

[0152] Message TRANSPORT MIGRATION REQUEST 913 is sent by RAN node CUa 911 to RAN node CUb 912 to request migration or release of traffic in the IAB topology controlled by RAN node CUb 912. For example, referring to Figure 7, if MT 704 of IAB node 701 is migrated to a non-F1 donor CU (not shown in Figure 7), the source F1 donor CU 703 may send TRANSPORT MIGRATION REQUEST 913 to the non-F1 donor CU to request release of traffic (e.g., F1 traffic) that has been migrated to the topology of the non-F1 donor CU (i.e., the F1 traffic is now routed from the target F1 donor CU 707 via the IAB topology managed by the non-F1 donor CU). Alternatively, if the MT 704 of the IAB node 701 is migrated to a non-F1 donor CU (not shown in FIG. 7 ), the target F1 donor CU 707 may send a TRANSPORT MIGRATION REQUEST 913 to the non-F1 donor CU to request traffic (e.g., F1 traffic) migration to the topology of the non-F1 donor CU (i.e., F1 traffic is now routed from the target F1 donor CU 707 via the IAB topology managed by the non-F1 donor CU).

[0153] RAN node CUb 912 responds with a message TRANSPORT MIGRATION RESPONSE 914 sent to RAN node CUa 901, accepting or rejecting the request.

[0154] Optionally, Figure 9b may correspond to the IAB transport migration management procedure specified in TS38.423 V17.2.0 section 8.5.2. Message 913 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS38.423 V17.2.0 section 9.1.4.2, and message 914 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in TS38.423 V17.2.0 section 9.1.4.3. Figure 9b may also correspond to the IAB transport migration modification procedure specified in TS38.423 V17.2.0 section 8.5.3. Message 913 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.4, and message 914 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.5.

[0155] 10a is a flowchart illustrating an exemplary method 1000 according to one or more embodiments of the present invention, performed at a source IAB donor CU for use in a migration process (or part of a migration process) in which a distributed unit (DU) of an IAB node migrates from an IAB topology managed by the source IAB donor CU to another IAB topology managed by a target IAB donor CU. The method 1000 is for managing, at a source F1-terminating donor CU of the IAB node, the DU migration of the IAB node to the target IAB topology. For example, in the IAB communication system described with reference to FIG. 5, the source IAB donor CU performing method 1000 may be the IAB donor CU 501 (e.g., the F1-terminating donor CU of the IAB node 570 to 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 include migrating the DU 572 of the IAB node 570 to the IAB topology 5003 managed by the IAB donor CU 503, which is the target IAB donor CU. With reference to FIG. 7 , the IAB node may be the IAB node 701, and the migration process may include migrating the DU of the IAB node 701 from the source F1 donor CU 703 to the target F1 donor CU 707. The method 1000 shown in and described with respect to FIG. 10 a may be performed by software and / or hardware elements. The source IAB donor CU may be implemented within the communications device 400 shown in and described with reference to FIG. 4, and the method shown in and described with respect to FIG. 10 a may be performed by one or more processing units, such as the central processing unit 411.

[0156] In step 1001, a source F1 terminating donor CU (e.g., donor CU 501 in FIG. 5 (703 in FIG. 7)) determines that a DU of an IAB node (e.g., IAB node 570 in FIG. 5 (701 in FIG. 7)) is to be migrated from the source F1 donor CU 501, 703 to a target F1 donor CU (e.g., donor CU 503 in FIG. 5 (707 in FIG. 7)). For example, the source F1 donor CU 501, 703 determines that a DU of an IAB node (e.g., IAB node 570) is to be migrated toward the target F1 donor CU (e.g., donor CU 503). As a further example, the source F1 donor CU 501, 703 may determine that a DU of an IAB node 570, 701 is to be migrated in response to determining that migration of an MT of the IAB node 570, 701 has been completed toward a new parent IAB node (which may be a new IAB node or a new IAB donor DU). Other example triggers for determining that a DU is to be migrated are described above, as are details of how the source F1 donor CU 501, 703 determines the target F1 donor CU 503, 707.

[0157] In step 1002, the source F1 terminating donor CU 501, 703 sends a request to the IAB node 570, 701 to establish an F1 connection between the target IAB donor CU 503, 707 and the IAB node 570, 701 (i.e., a new F1 connection). For example, the source F1 terminating donor CU 501, 703 sends a request for a new F1 connection (e.g., a new F1 connection with the target IAB donor CU) to the IAB node 570, 701 to be migrated. This request may be the CONFIGURATION REQUEST 803 described with reference to FIG. 8a. The source F1 donor CU 501, 703 may send to the IAB node information indicating that the F1 connection is for a DU migration to the target IAB donor CU (e.g., information indicating that the F1 connection establishment request is related to the migration of a DU of the IAB node) and / or information indicating the number of cells to be activated in the second logical DU entity of the DU of the IAB node. The source F1 donor CU 501, 703 may also optionally transmit identifiers (e.g., PCI and / or NCGI) of active cells controlled by the first logical DU 705, for which a mapping is provided with identifiers of cells to be enabled (e.g., cells in the second logical DU to be enabled).

[0158] Optionally, in step 1003, the source F1 terminating donor CU 501, 703 sends identification information to the IAB node 570, 701 to identify the target IAB donor CU 503, 707. This identification information may be the TNL address (i.e., IP address) of the target IAB donor CU 503, 707. For example, the source F1 terminating donor CU 501, 703 sends the address of the target F1 donor CU for the new F1 connection to the IAB node to be migrated. If the IAB-MT 704 is migrated to a non-F1 donor CU (sometimes referred to as an RRC donor CU), the identification information sent by the source F1 terminating donor CU 501, 703 may include the address of the non-F1 donor CU (although the IAB node 701 may already have this information).

[0159] The source F1 terminating donor CU 703 may receive, from the target F1 donor CU 707 or the IAB node 570, 701, identification information (e.g., identifiers) identifying one or more new cells activated in the second logical DU entity of the DU. Optionally, along with the mapping information, mapping information between the identification information of the one or more target cells activated in the second logical DU and the identification information of the cells that were controlled by the first logical DU may also be received. As described above, the DU of the IAB node comprises a first logical DU entity having an F1 connection with the source F1 terminating donor CU 703, and the second logical DU entity is activated to perform DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). For example, the identification information and optional mapping information may be received in the CONFIGURATION UPDATE message 903 described above.

[0160] As an example, the source F1 termination donor CU 703 may send a handover request to the target F1 donor CU 707 to request handover of one or more user equipment (UE) (e.g., UE 708) served by the IAB node 701 from the source F1 termination donor CU 703 to the target F1 donor CU 707, and the request may include information for identifying one or more target cells (e.g., candidate target cells) for each UE. The selection of a target cell for the UE may be based on a measurement report provided by the UE (e.g., indicating signal strength detected by the UE for one or more cells) or based on a mapping between identifiers of target cells activated in the second logical DU and identifiers of source cells controlled by the first logical DU. For example, the source F1 termination donor CU 703 may select one or more of the new cells activated in the second logical DU entity 706 as one or more candidate target cells for each of the one or more UEs served by the IAB node based on mapping information received from the target F1 donor CU 707 or the IAB node 701. Using this mapping, it is not necessary to wait for measurement reports from the UEs to trigger the handover procedure. In response to receiving a handover acknowledgment from the target F1 donor CU 707 indicating that the handover of one or more UEs has been accepted and identifying a target cell for each UE, the source F1 terminating donor CU 703 sends configuration information to the IAB node 701 for configuring the respective target cell for each UE. The handover acknowledgment from the target F1 donor CU 707 may also include configuration information for configuring each UE to the respective target cell. For these steps, the handover procedure 730 described above may be performed.

[0161] After the handover of one or more UEs 708 to the target F1 donor CU 707 is completed, 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. The request may be a deactivation request sent in a CONFIGURATION REQUEST message 803 or a removal request sent in a message 823.

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

[0163] FIG. 10b is a flowchart illustrating an example method 1010 performed in an IAB node (e.g., a mobile IAB node or mIAB node) for use in a migration process (or part of a migration process) in which a 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. The method 1010 is for managing DU migration in the IAB node toward a target F1 terminating donor CU. For example, in the IAB communication system shown in and described with respect to FIG. 5, the IAB node performing method 1010 may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501 (e.g., an F1 terminating donor CU of the mobile IAB node 570 that maintains an F1 connection with the mobile IAB node 570), which is the source IAB donor CU. The migration process may include migrating a DU 572 of an IAB node 570 from an IAB topology 5001 to an IAB topology 5003 managed by a target IAB donor CU 503. With reference to FIG. 7, the IAB node may be a mobile IAB node 701, and the migration process may include migrating a DU of the IAB node 701 from a source F1 donor CU 703 to a target F1 donor CU 707. The method 1010 shown in and described with respect to FIG. 10b may be performed by software and / or hardware elements. The IAB node may be implemented in the communications device 400 shown in and described with reference to FIG. 4, and the method shown in and described with respect to FIG. 10b may be performed by one or more processing units, such as the central processing unit 411.

[0164] In step 1011, an IAB node, such as IAB node 570 of Figure 5 (701 of Figure 7), receives a request for a new F1 connection (e.g., an F1 connection between IAB node 570, 701 and a target F1 donor CU, such as donor CU 503 of Figure 5 (707 of Figure 7)), from a source F1 terminating a donor CU, such as donor CU 501 of Figure 5 (703 of Figure 7). The request may be a CONFIGURATION REQUEST 803 as described with reference to Figure 8a.

[0165] In response to receiving the request for the new F1 connection, the IAB node 570, 701 sends an F1 setup request to the target F1 donor CU 503, 707 requesting the establishment of the F1 connection (step 1018). For example, the setup request may be the SETUP REQUEST 813 described above. The F1 setup request message sent by the IAB node may include identification information for identifying the source F1 terminated donor CU, or for identifying a non-F1 donor CU (sometimes referred to as an RRC donor CU) if the IAB node's mobile termination (MT) has migrated to a non-F1 donor CU.

[0166] The IAB node 570, 701 may identify or specify the target F1 donor CU 503, 707 in response to receiving the request for F1 connection establishment (step 1017), and then send an F1 setup request to the identified target F1 donor CU. The IAB node 570, 701 may identify the target F1 donor CU 503, 707 based on the identification information of the target F1 donor CU 503, 707 received from the source F1 donor CU 501, 703 (e.g., the address (TNL address / IP address) of the target F1 donor CU 503, 707) (e.g., sent in the CONFIGURATION REQUEST 803 message or separately). If the IAB-MT 704 has migrated to a non-F1 donor CU, the identification information received at the IAB node includes 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 CU 501, 703, and the IAB-MT 704 has been migrated to a non-F1 donor CU, the IAB node 570, 701 will consider the non-F1 donor CU as the target F1 donor CU and identify the target donor CU 503, 707 (e.g., after receiving an F1 connection establishment request). In this case, the IAB node 701 can identify the address of the non-F1 donor CU as the address of the target donor CU because it was already informed about the address (TNL address / IP address) of the target donor CU when the IAB-MT 704 was migrated to the non-F1 donor CU.

[0167] Optionally, in step 1012, the IAB node 570, 701 receives identification information for identifying the target F1 donor CU 503, 707 from the source F1 terminating donor CU 501, 703. This identification information may include the address (TNL address / IP address) of the target F1 terminating donor CU for the new F1 connection.

[0168] Alternatively (e.g., instead of steps 1011 and 1012), although not shown in the figure, the IAB node 570, 701 may trigger itself to request a new F1 connection and identify a target F1 donor CU based on preconfiguration. That is, the IAB node 570, 701 may determine itself that a new F1 connection should be established, identify an IAB donor CU to which the connection should be established based on preconfiguration information preconfigured in the IAB node, and then transmit an F1 setup request to the identified target IAB donor CU to request establishment of an F1 connection. As a first example, the trigger condition may be when the IAB node 570 or 701 detects one or more cells in its vicinity that have an identifier (NCGI) belonging to the list of preconfigured target donor CUs. In other words, the IAB node 570, 701 may determine that a new F1 connection should be established (e.g., because a DU (e.g., 572) of the IAB node 570 / 701 is migrating) and identify an IAB donor CU to which the connection should be established in response to, or after, detecting one or more nearby cells, based on detecting a cell associated with an IAB donor CU included in a preconfigured target IAB donor CU candidate list. As a second example, a trigger condition may be upon network integration, when an initial F1 connection should be established with a preconfigured donor CU after the IAB-MT establishes an RRC connection (which depends on the physical location of the IAB node). In other words, the IAB node 570, 701 may determine that a new F1 connection should be established during network integration and identify an IAB donor CU to which the F1 connection should be established based on the IAB node's preconfigured candidate donor CU list and the location of the IAB node.

[0169] Figure 10c shows exemplary steps performed at an IAB node (e.g., a mobile IAB node or mIAB node) to identify a target IAB donor CU in accordance with one or more embodiments of the present invention. By way of example, step 1017 of Figure 10b may be implemented by performing steps 1013-1015 of Figure 10c, collectively referred to as step 1016. In an alternative method in which the IAB node 570, 701 determines on its own that a new F1 connection should be established without receiving a request for a new F1 connection, steps 1013-1015 may be performed at the IAB node to identify an IAB donor CU to which a connection should be established based on pre-configuration information.

[0170] In step 1013, the IAB node 701 determines whether it has received identification information (or pre-configuration) from the source IAB donor CU to identify the target IAB donor CU. Specifically, it checks whether it has received the address of the target F1 terminating donor CU for the new F1 connection. If YES, in step 1015, the IAB node 701 identifies the target F1 terminating donor CU from the received identification information and sends an F1 setup request to the identified target F1 terminating donor CU. If NO, in step 1014, the IAB node 701 identifies a non-F1 terminating donor CU (also referred to as an RRC donor CU) as the target F1 terminating donor CU from the received identification information and sends an F1 setup request to the non-F1 terminating donor CU (e.g., donor CU 502).

[0171] A request for a new F1 connection (e.g., CONFIGURATION REQUEST 803) received at the IAB node 701 may include a request to activate one or more cells for a second logical DU entity (e.g., IAB-DU2 706). It may also optionally include identifiers (e.g., PCI and / or NCGI) of active cells controlled by the first logical DU, and identifiers of active cells for which a mapping with the identifiers of the activated cells should be provided. As described above, the DU of the IAB node has a first logical DU entity with an F1 connection to the source F1-terminated donor CU 703, and a second logical DU entity is activated to perform DU migration (e.g., to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701). In one example, the IAB node 701 activates a second logical DU entity (e.g., IAB-DU2 706) in response to receiving an F1 connection establishment request (e.g., CONFIGURATION REQUEST 803). In either of these cases, an 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 termination donor CU 707 may include information regarding the number of cells to be activated with the activation of the second logical DU in the IAB node and information indicating that the F1 connection establishment request is related to the migration of a DU in the IAB node. Optionally, the F1 setup request message may include a mapping request between the identifiers of the active cells (e.g., PCI and / or NCGI) controlled by the first logical DU and the identifiers of the cells to be activated. In one example, after sending the F1 setup request, the IAB node 701 receives a response (e.g., SETUP RESPONSE 814) from the target F1 termination donor CU 707 requesting activation of one or more cells to the second logical DU entity. The response may include identification information, such as an identifier for each cell to be activated.

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

[0173] 10d is a flowchart of an example method 1020 performed in a target IAB donor CU for use in migrating a distributed unit (DU) of an IAB node from an IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU during a migration process (or part of a migration process) in accordance with one or more embodiments. The method 1020 is for managing, at the target F1 terminating donor CU, the DU migration of the IAB node toward the target IAB topology managed by the target F1 terminating donor CU. For example, with reference to the IAB communication system shown and described in FIG. 5, the target IAB donor CU performing the method 1020 may be the IAB donor CU 503 that controls the IAB topology 5003. The IAB node may be a mobile IAB node 570 that belongs to the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may include migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003. Referring to FIG. 7, the IAB node may be the IAB node 701, and the migration process may include migrating the DU of the IAB node 701 from the source F1 donor CU 703 to the target F1 donor CU 707. The method 1020 shown in and described in connection with FIG. 10d may be performed by software and / or hardware elements. The target IAB donor CU may be implemented within the communications device 400 shown in and described with reference to FIG. 4, and the method shown in and described in connection with FIG. 10d may be performed by one or more processing units, such as the central processing unit 411.

[0174] In step 1021, the target IAB donor CU (e.g., IAB donor CU 503 in FIG. 5 (707 in FIG. 7)) receives an F1 setup request from an IAB node (e.g., IAB node 570 in FIG. 5 (701 in FIG. 7)) to establish an F1 connection between the target IAB donor CU and the IAB node. For example, the setup request may be the SETUP REQUEST 813 described above. The F1 setup request message sent from the IAB node may include identification information for identifying the source F1-terminating donor CU when the mobile termination (MT) of the IAB node has migrated to a non-F1 donor CU, or 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 by the activation of the second logical DU in the IAB node and / or information indicating that the request to establish an F1 connection is related to the migration of a DU of the IAB node. Optionally, the F1 setup request message may include an identifier of an active cell controlled by the first logical DU (e.g., PCI and / or NCGI) and / or an identifier of an active cell for which a mapping with an identifier of a cell to be activated is to be provided. The F1 setup request message may also or alternatively include a request for mapping between an identifier of an active cell controlled by the first logical DU and an identifier of a cell to be activated (e.g., a cell in a second logical DU of the IAB node).

[0175] In step 1022, the target IAB donor CU 503, 707 transmits a response (e.g., setup response 814) to the IAB node 570, 701 in response to receiving the F1 setup request. The response includes a request for one or more cells to be activated for a second logical DU entity of the IAB node 570, 701. As described above, the DU of the IAB node comprises a first logical DU entity having an F1 connection with the source F1 termination donor CU 703, and the second logical DU entity is activated to establish a new F1 connection between the target F1 donor CU 707 and the IAB node 701. The response may include identification information such as an identifier of each cell to be activated (e.g., an identifier of each cell to be activated). Optionally, the response may also include a mapping between identifiers of active cells controlled by the first logical DU (e.g., PCI and / or NCGI) and the identifiers of the cells to be activated. The target IAB donor CU 503, 707 or IAB node 570, 701 may send identification information of one or more new cells activated in the second logical DU entity to the source IAB donor CU 501, 703. The target IAB donor CU 503, 707 or IAB node 570, 701 may also send mapping information to the source IAB donor CU 501, 703.

[0176] As an example, the target F1 donor CU 707 may receive a handover request from the source F1 terminating donor CU 703 requesting handover of one or more user equipments (UEs) (e.g., UEs 708) served by the IAB node 701 to the target F1 donor CU 707. To identify target cells (e.g., candidate target cells) for each UE, target cell selection may be performed based on mapping information or measurement reports (e.g., indications of signal strength detected by the UE for one or more cells) provided from the UE. For example, the source F1 terminating donor CU 703 may select one or more of the new cells activated in the second logical DU entity 706 as candidate target cells for each UE served by the IAB node based on mapping information received from the target F1 donor CU 707 or the IAB node 701. Utilizing this mapping eliminates the need to wait for measurement reports from the UE to trigger the handover procedure. If the target F1 donor CU 707 determines that handover for one or more UEs is acceptable, the target F1 donor CU 707 sends a handover response to the source F1 terminating donor CU 703, identifying a target cell for each UE. The handover response may also include configuration information for setting the target cell for each UE. For these steps, the handover procedure 730 described above may be performed.

[0177] When the handover of one or more UEs 708 to the target F1 donor CU 707 is completed and the mobile termination of the IAB node 701 (e.g., IAB-MT 704) has been 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 requesting migration of traffic associated with the IAB node. The traffic in question is traffic that was routed via one or more paths in the IAB topology managed by a non-F1 donor CU.

[0178] In this manner, by sending a request to the IAB node requesting the establishment of an F1 connection between the IAB node and the target IAB donor CU, the source F1 donor CU (e.g., source IAB donor CU) facilitates the DU migration of the IAB node, with or without one or more MT migrations. Furthermore, upon receiving the request to establish an F1 connection, the IAB node identifies the target donor CU (e.g., by identification information sent by the source donor CU, or, if identification information was not sent from the source donor CU, by determining that a non-F1 donor CU is the target donor CU) and enables handover of the UE being served by the IAB node to the target donor CU.

[0179] The determination that a DU in an IAB node should be migrated may be triggered by an event. The type of event that triggers the determination that a DU in an IAB node should be migrated may be left to the implementation. For example, the decision to migrate a DU may be made based on the detection that a MT in the IAB node has migrated from a first IAB topology to a second IAB topology and the known (predefined) trajectory of the IAB node, which indicates to the source F1 donor CU that the MT will later be migrated to a third IAB topology. In this case, to avoid sending signaling messages related to DU migration / UE handover to the second IAB topology, the DU is directly migrated to the third IAB topology. Another triggering event may be the detection that the processing load level in the source F1 donor CU exceeds a predetermined threshold. In this case, DU migration is triggered, and the selection of a target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU.

[0180] In other words, in summary, the triggering event and decision process for the source F1 terminating donor CU to perform migration of the mobile IAB-DU (mIAB-DU) may be left to the implementation. Also, to enable flexible IAB network management, the mIAB-DU should be allowed to migrate to a target F1 terminating donor CU that is different from the non-F1 terminating donor CU (also referred to as RRC terminating donor CU) that provides the co-located mobile IAB-MT (mIAB-MT).

[0181] Thus, the IAB-DU of a mobile IAB node may be migrated to a target F1 terminating donor CU that is different from the non-F1 terminating donor CU that serves the co-located IAB-MT.

[0182] Next, when the F1 donor CU providing the mIAB-DU decides to perform the mIAB-DU migration, the F1 donor CU may request the mobile IAB node to activate the second logical DU provided by the target F1 donor CU.

[0183] For example, the F1 donor CU may trigger a gNB-CU configuration update procedure to request the mobile IAB node to set up a new F1 connection with the identified target F1 donor CU. The activated logical DU then triggers the F1 setup procedure with the target F1 donor CU. If the request from the F1 donor CU does not identify a target F1 donor CU, the activated logical DU may trigger the F1 setup procedure with a non-F1 terminating donor CU of the mobile IAB node.

[0184] Thus, when requested by a serving F1 donor CU to set up a new F1 connection, the mobile IAB node may perform the F1 setup procedure with the target F1 donor CU indicated in the request. In the absence of such indication, the mobile IAB node may perform the F1 setup procedure with a non-F1 terminating donor CU.

[0185] To trigger handover of serving UEs during the mobile IAB node's mIAB-DU migration, the target F1 donor CU may notify the source F1 donor CU of new cells activated in the mobile IAB node's second logical DU. For this purpose, the target F1 donor CU may perform an NG-RAN node configuration update procedure with the source F1 donor CU, which allows the source F1 donor CU to send handover commands to UEs served by the mobile IAB node.

[0186] Therefore, the NG-RAN node configuration update procedure may be used by the target F1 terminating donor CU of the mobile IAB node to inform the source F1 terminating donor CU of the ID of the cell provided by the second logical DU of the mobile IAB node.

[0187] Regarding the procedures for triggering, executing, and reporting F1 setup for DU migration, the following observations are made: To trigger DU migration of a mobile IAB node as determined by the source F1 donor CU, the mobile IAB node may be notified of the following information: - A required indication that a DU migration is being requested. This means that the F1 setup procedure should be initiated for the target logical DU. - Identifier of the target F1 donor CU (optional). This information element is relevant when a DU migrates to a target F1 donor CU that is different from the non-F1 donor CU that serves the co-located mobile IAB-MT. In the absence of such an indication, the mobile IAB node should perform the F1 setup procedure towards the non-F1 terminating donor CU.

[0188] Considering the small number of bits required for this signaling, it may not be necessary to create a new F1AP procedure. Furthermore, since this is related to F1 interface management, the gNB-CU configuration update procedure appears appropriate for this signaling. Therefore, it is proposed that the source CU uses the gNB-CU configuration update procedure to trigger the F1-setup procedure for the purpose of DU migration.

[0189] In the F1 Setup Request message, the mobile IAB node should pass the following information to the target F1 donor CU: - An indication that the F1 setup request is related to a DU migration. This information element allows the target F1 donor CU to understand the context and process the request appropriately. - PCI(s) of active cells in the source logical DU. This information element helps the target F1 donor CU to select the appropriate PCI of the cell to be activated in the target logical DU.

[0190] Therefore, to the extent related to the DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU should include an indication explicitly indicating that the F1 setup is related to the DU migration of a mobile IAB node and should include a list of PCIs in the source logical DU of the mobile IAB node.

[0191] To report the results of the F1 setup procedure for the purpose of DU migration of the mobile IAB node, the mobile IAB node may notify the source F1 donor CU of the following information: - An indication of the success or failure of the F1 setup and, in case of failure, the reason for the failure. - ID of the cell that the target F1 donor CU has activated in the target logical DU. - Mapping between IDs of cells activated in the target logical DU and IDs of cells active in the source logical DU (optional information element). This mapping makes it possible to limit the scope of measurements to be performed in the UE, potentially enabling handover to be triggered without measurement reports from the UE. Since the gNB-CU configuration update procedure is considered appropriate for triggering F1 setup, the gNB-DU configuration update procedure is considered a good candidate as an existing F1AP procedure for reporting the results of F1 setup.

[0192] Therefore, it is proposed that the gNB-DU configuration update procedure can be used by a mobile IAB node to report the result of the F1 setup procedure to the source CU of a DU migration. It is also proposed that 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 be included as an optional information element in the reporting of the F1 setup result.

[0193] Regarding the provision of identification information to the F1 donor CU, the following observations can be made: During DU migration of a mobile IAB node to a target F1 donor CU that is different from the non-F1 donor CU of the co-located mobile IAB-MT, the identifier of the non-F1 donor CU and the UE XnAP ID of this CU of the mobile IAB-MT must be provided to the target F1 donor CU. These information elements enable the target F1 donor CU to perform the transport migration management procedure towards the non-F1 donor CU. Furthermore, during network integration, if the mIAB-MT and the co-located mIAB-DU are integrated into different donor CUs, the UE XnAP ID assigned by the CU of the mIAB-MT and the gNB-ID of that CU must be known by the CU of the mIAB-DU.

[0194] Considering the case of network integration, there are two options: - Option 1: The mobile IAB node provides identification information based on information received from a non-F1 donor CU (i.e., a CU of the mIAB-MT). - Option 2: The non-F1 donor CU provides the identification information after obtaining the identifier of the F1 donor CU (i.e., the CU of the mIAB-DU) from the mobile IAB node.

[0195] The disadvantage of Option 2 is that the F1 donor CU must generate a UE XnAP ID for the mIAB-MT and pass it to the mobile IAB node, which then passes it along with the F1 donor CU's identifier to the non-F1 donor CU. The UE XnAP ID thus generated by the F1 donor CU is used in the XnAP message sent by the non-F1 donor CU to the F1 donor CU. Therefore, Option 1 appears to have less impact on the specifications than Option 2.

[0196] If Option 1 is adopted, for consistency, the mobile IAB node should provide the target F1 donor CU with the identity information associated with the non-F1 donor CU during DU migration, which may be performed by F1 AP signaling similar to that during network integration.

[0197] Furthermore, the mobile IAB node should also provide the target non-F1 donor CU with associated identification information for its F1 donor CU during (subsequent) MT migrations, and the same F1 AP signaling may be used in this case.

[0198] To cover all the scenarios mentioned above, the gNB-DU configuration update is a suitable F1AP procedure since it can be triggered at any time.

[0199] Therefore, it is proposed that a gNB-DU configuration update procedure can be used by a mobile IAB node to inform an F1 donor CU of the identifier of the non-F1 donor CU and the UE XnAP ID of the mobile IAB-MT at that CU. This procedure may be applied during network integration, DU migration, and MT migration.

[0200] The source donor CU of the mobile IAB-MT can send information about the target donor CU of the mIAB-MT to the donor CU of the mIAB-DU after the IAB-MT handover is completed.

[0201] In fact, the present proposal is consistent with this description, since the source non-F1 donor CU (i.e., the source donor CU of the mIAB-MT) passes its information to the F1 donor CU (i.e., the donor CU of the mobile IAB-DU) via the mIAB node, not directly.

[0202] Furthermore, this proposal does not prevent the identifier of the non-F1 donor CU and the UE XnAP ID of the mobile IAB-MT on that CU from being included in the F1 setup request sent to the target F1 donor CU during DU migration. If these information elements are not included in the F1 setup request, it may indicate that the non-F1 donor CU is also the target F1 donor CU.

[0203] Therefore, it is proposed that in DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU may include the identifier of the non-F1 donor CU and the UE XnAP ID of the mobile IAB-MT on that CU.

[0204] Although the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. Those skilled in the art will recognize 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 the appended claims, abstract, and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including the appended claims, abstract, and drawings), unless expressly stated otherwise, may be replaced by an alternative feature serving the same, equivalent, or similar purpose. Thus, unless expressly stated otherwise, each disclosed feature is merely an example of a generic series of equivalent or similar features.

[0205] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

[0206] 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 over a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit.

[0207] Computer-readable media may include computer-readable storage media, which correspond to tangible media such as data storage media, or communication media, including any medium that enables transfer of a computer program from one place to another, for example, according to a communications protocol. In this manner, computer-readable media may generally correspond to (1) tangible computer-readable storage media that are non-transitory, or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include computer-readable media.

[0208] By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. Disks, as referred to herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically and discs reproduce data optically with a laser. Combinations of the above are also included within the scope of computer-readable media.

Claims

1. 1. A method for use in a migration process in which a distribution unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, comprising: determining the DU of the IAB node to be migrated from one IAB topology of the source IAB donor CU to the other IAB topology of the target IAB donor CU; sending a request to the IAB node to establish an F1 connection between the IAB node and the target IAB donor CU.

2. sending identification information to the IAB node to identify the target IAB donor CU; The method of claim 1 further comprising:

3. the identification information for identifying the target IAB donor CU associated with the F1 connection includes an address associated with the target IAB donor CU; The method of claim 2.

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

5. transmitting, to the IAB node, identification information identifying one or more active cells controlled by a first logical DU entity of the DU at the IAB node; 10. The method of any one of the preceding claims, further comprising:

6. sending information indicating that the request to establish an F1 connection is related to a migration of the DU of the IAB node; 10. The method of any one of the preceding claims, further comprising:

7. receiving, from the target IAB donor CU or from the IAB node, identification information identifying each of one or more new cells activated in a second logical DU entity of the DU at the IAB node; 10. The method of any one of the preceding claims, further comprising:

8. receiving, from the target IAB donor CU or from the IAB node, mapping information indicating a mapping between identities of one or more new cells activated in a second logical DU entity of the DU of the IAB node and identities of one or more active cells controlled by a first logical DU entity of the DU of the IAB node; 10. The method of any one of the preceding claims, further comprising:

9. sending a handover request to the target IAB donor CU to request handover of one or more user equipments UE served by the IAB node from the source IAB donor CU to the target IAB donor CU, and to identify one or more candidate target cells for each UE; 10. The method of any one of the preceding claims, further comprising:

10. selecting one or more new cells as one or more candidate target cells for each UE of one or more UEs served by the IAB node based on the mapping information; the handover request includes information identifying the selected one or more candidate target cells.

10. The method according to claim 8 or 9.

11. transmitting configuration information to the IAB node for configuring each of the one or more UEs for a respective target cell in response to receiving a handover acknowledgment from the target IAB donor CU indicating that handover of one or more UEs has been accepted and identifying a target cell for each UE; The method of claim 9 or 10, further comprising:

12. After the handover of the one or more UEs to the target IAB donor CU is completed, sending a request to the IAB node having an F1 connection with the source IAB donor CU to deactivate a first logical DU entity of the DU of the IAB node; The method of any one of claims 9 to 11 further comprising:

13. After the handover of the one or more UEs to the target IAB donor CU is completed, if a mobile termination (MT) of the IAB node has migrated to a non-F1 donor CU, sending a traffic migration request to the non-F1 donor CU to request traffic release for traffic associated with the IAB node and routed via one or more paths in an IAB topology managed by the non-F1 donor CU; The method of any one of claims 9 to 12, further comprising:

14. the determining that the DU of the IAB node is migrated includes determining that the DU of the IAB node is migrated in response to determining that migration of the MT of the IAB node to a new parent IAB node is complete.

10. A method according to any one of the preceding claims.

15. 1. A method for use in a migration process in which a distribution unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, the method in the IAB node comprising: receiving a request from the source IAB donor CU to establish an F1 connection between the target IAB donor CU and the IAB node; sending an F1 setup request to the target IAB donor CU to request setup of the F1 connection.

16. identifying the target IAB donor CU in response to receiving a request to establish an F1 connection; the transmitting step includes transmitting the F1 setup request to the identified target IAB donor CU.

16. The method of claim 15.

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

18. the step of identifying the target IAB donor CU includes identifying the target IAB donor CU from the received identification information; 18. The method of claim 16 or 17.

19. The identifying step includes: determining whether identification information for identifying the target IAB donor CU related to 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 associated with the F1 connection has been received from the source IAB donor CU, identifying the target IAB donor CU from the received identification information; 17. The method of claim 16, comprising:

20. determining whether identification information for identifying a target IAB donor CU of the F1 connection has been received from the source IAB donor CU; the identifying step includes, in response to determining that identification information for identifying the target IAB donor CU associated with the F1 connection has not been received from the source IAB donor CU and that a mobile termination (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; the transmitting step includes transmitting the F1 setup request to the non-F1 donor CU identified as the target IAB donor CU.

17. The method of claim 16.

21. after receiving the request to establish the F1 connection, determining whether identification information identifying the target IAB donor CU of the F1 connection has been received from the source IAB donor CU; the transmitting step includes, in response to determining that identification information for identifying the target IAB donor CU associated with the F1 connection has been received, transmitting the F1 setup request to the target IAB donor CU identified by the received identification information.

18. The method of claim 17.

22. After receiving a request to establish an F1 connection, determining whether identification information identifying the target IAB donor CU related to 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 related to the F1 connection has not been received from the source IAB donor CU and that a mobile termination (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; the transmitting step includes transmitting the F1 setup request to the non-F1 donor CU identified as the target IAB donor CU.

17. The method of claim 15 or 16.

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

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

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

26. receiving information from the source IAB donor CU indicating that a request to establish an F1 connection relates to a migration of the DU at the IAB node; 26. The method of any one of claims 15 to 25, further comprising:

27. the DU of the IAB node comprises a first logical DU entity having an F1 connection with the source IAB donor CU; the request to establish an F1 connection includes a request for one or more cells to be activated for a second logical DU entity; the transmitting step includes transmitting the F1 setup request to the target IAB donor CU by the second logical DU entity; 27. The method of any one of claims 15 to 26.

28. the DU of the IAB node comprises a first logical DU entity having an F1 connection with the source IAB donor CU; activating a second logical DU entity to establish the F1 connection with the target IAB donor CU in response to receiving the request to establish the F1 connection; the transmitting step includes transmitting the F1 setup request to the target IAB donor CU by the second logical DU entity; 27. The method of any one of claims 15 to 26.

29. receiving, after sending the F1 setup request, 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; 29. The method of any one of claims 15 to 26 and 28, further comprising:

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

31. transmitting to the source IAB donor CU identification information identifying each of the one or more new cells activated in the second logical DU entity; 31. The method of claim 29 or 30, further comprising:

32. transmitting to the source IAB donor CU mapping information indicating a mapping between identities of one or more new cells activated in the second logical DU entity and identities of one or more active cells controlled by a first logical DU entity of the DU of the IAB node; 32. The method of any one of claims 29 to 31, further comprising:

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

34. deactivating the first logical DU entity in response to receiving the request to deactivate the first logical DU entity; 34. The method of claim 33 further comprising:

35. the step of transmitting an F1 setup request includes transmitting an F1 setup request message to request the setup of the F1 connection; The F1 setup request message includes identification information for identifying the source IAB donor CU or identification information for identifying the non-F1 donor CU when the mobile termination (MT) of the IAB node is terminated to a non-F1 donor CU.

35. The method of any one of claims 15 to 34.

36. the step of transmitting an F1 setup request includes transmitting an F1 setup request message to request the setup of the F1 connection; The F1 setup request message includes information indicating the number of cells to be activated by the activation of the second logical unit at the IAB node; 36. The method of any one of claims 15 to 35.

37. the step of transmitting an F1 setup request includes transmitting an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes identification information identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node; 37. The method of any one of claims 15 to 36.

38. the step of transmitting an F1 setup request includes transmitting an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes information indicating that the request to establish an F1 connection is related to migration of the DU of the IAB node; 38. The method of any one of claims 15 to 37.

39. the step of transmitting an F1 setup request includes transmitting an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes a request for mapping between identities of one or more new cells to be activated in a second logical DU entity of the DU of the IAB node and identities of one or more active cells controlled by a first logical DU entity of the DU of the IAB node.

39. The method of any one of claims 15 to 38.

40. 1. A method for use in a migration process in which a distribution unit (DU) of an integrated access backhaul (IAB) node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, comprising: receiving an F1 setup request from the IAB node to request setup of an F1 connection between the target IAB donor CU and the IAB node; and sending a response to the IAB node including a request for one or more cells to be activated for a second logical DU entity of the IAB node.

41. the step of receiving an F1 setup request includes receiving an F1 setup request message to request the setup of the F1 connection; The F1 setup request message includes identification information identifying the source IAB donor CU or identification information identifying a non-F1 donor CU when a mobile termination (MT) of the IAB node has migrated to a non-F1 donor CU.

41. The method of claim 40.

42. the step of receiving an F1 setup request includes receiving an F1 setup request message to request the setup of the F1 connection; The F1 setup request message includes information indicating the number of cells to be activated by the activation of the second logical unit at the IAB node; 42. The method of claim 40 or 41.

43. the step of receiving an F1 setup request includes receiving an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes identification information identifying one or more active cells controlled by a first logical DU entity of the DU of the IAB node; 43. The method of any one of claims 40 to 42.

44. the step of receiving an F1 setup request includes receiving an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes information indicating that the request to establish an F1 connection is related to migration of the DU of the IAB node; 44. The method of any one of claims 40 to 43.

45. the step of receiving an F1 setup request includes receiving an F1 setup request message to request the setup of the F1 connection; the F1 setup request message includes a request for mapping between identities of one or more new cells to be activated in a second logical DU entity of the DU of the IAB node and identities of one or more active cells controlled by a first logical DU entity of the DU of the IAB node.

45. The method of any one of claims 40 to 44.

46. transmitting to the source IAB donor CU identification information identifying each of one or more new cells activated in a second logical DU entity of the DU at the IAB node; 46. ​​The method of any one of claims 40 to 45, further comprising:

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

48. sending, to the source IAB donor CU, mapping information indicating a mapping between identities of the one or more new cells to be activated for the second logical DU entity and identities of one or more active cells controlled by a first logical DU entity of the DU at the IAB node; 48. The method of any one of claims 40 to 47, further comprising:

49. receiving a handover request from the source IAB donor CU to request handover of one or more user equipments (UEs) served by the IAB node to the target IAB donor CU, and identifying one or more candidate target cells for each UE; sending a handover acknowledgement to the source IAB donor CU indicating that handover of one or more UEs has been accepted by the target IAB donor CU and identifying a target cell for each of the UEs; 49. The method of any one of claims 40 to 48, further comprising:

50. After the handover of one or more UEs to the target IAB donor CU is completed, if a mobile termination (MT) of the IAB node has migrated to a non-F1 donor CU, sending a traffic migration request to the non-F1 donor CU to request traffic migration for traffic associated with the IAB node and routed via one or more paths in an IAB topology managed by the non-F1 donor CU; 50. The method of claim 49, further comprising:

51. 10. The method of claim 1, wherein the IAB node is a mobile IAB node.

52. 1. An apparatus for an integrated access backhaul (IAB) node in an IAB communication system, comprising:

52. Apparatus comprising one or more processing units configured to perform the method of any one of claims 15 to 39 and claim 51.

53. 1. An apparatus for an integrated access backhaul (IAB) donor central unit (CU) for an IAB communication system, comprising: Apparatus comprising one or more processing units configured to perform the method of any of claims 1 to 14 and claims 40 to 51.

54. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 51.

55. 55. A computer readable medium having recorded thereon the computer program of claim 54.

Images