Node migration in IAB communication systems.

Abstract

To flexibly perform node migration in an IAB communication system. A method and apparatus for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node migrates from a first parent IAB network node to a second parent IAB network node. The IAB node is managed by a first IAB donor central unit (CU) of a first IAB topology, and the first and second parent IAB network nodes are managed by a second IAB donor CU of a second IAB topology. The method in the IAB node includes transmitting, to the first IAB donor CU, path information associated with one or more routing paths in the second IAB topology used to route data associated with the IAB node through the second parent IAB network node. The method in the second donor CU includes determining that the MT of the IAB node is to migrate from the first parent IAB network node to the second parent IAB network node. The first and second parent IAB network nodes are managed by the second IAB donor CU. Transmit to the first IAB donor CU path information associated with one or more backhaul paths in the second IAB topology used to route data associated with the IAB node through the second parent IAB network node.

Description

[Technical Field]

[0001] The present invention relates generally to a method used in a process for migrating nodes and traffic in an Integrated Access and Backhaul (IAB) communication system, and more particularly to a method used in a migration process in which an IAB node, e.g., a Mobile Termination (MT) of a mobile IAB node, is migrated in an IAB communication system. [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-RTM (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 uncorrelated; 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 different from the IAB donor associated with the MT for that IAB node. However, performing an MT migration simultaneously with a co-located DU migration may lead to at least one failure of the migration procedure or dramatically increase signaling complexity.

[0016] Therefore, a new mechanism is needed to provide such flexibility by supporting multiple MT migrations associated with DU migrations for IAB nodes. [Means for solving the problem]

[0017] According to a first aspect of the present invention, there is provided a method executed in an IAB node for use in a migration process in which a mobile termination (MT) of the IAB node migrates from a first parent IAB network node to a second parent IAB network node, as set forth in claims 1 to 5 of the accompanying claims, wherein the IAB node (e.g., a DU of the IAB node) is managed by a first IAB donor central unit (CU) of a first IAB topology, and the first and second parent IAB network nodes are managed by a second IAB donor CU of a second IAB topology.

[0018] According to a second aspect of the present invention, there is provided a method, executed in a second IAB donor CU, for use in a migration process in which a mobile termination MT of an IAB node is migrated in a second IAB topology managed by the second IAB CU, and the IAB node (e.g., a DU of the IAB node) is managed by a first IAB donor CU, as set forth in claims 6 to 11 of the accompanying claims.

[0019] According to a third aspect of the present invention, there is provided a method executed in a first IAB donor CU for use in a migration process in which a mobile termination (MT) of an IAB node migrates from a first parent IAB network node to a second parent IAB network node, as set forth in claims 12 to 19 of the accompanying claims, wherein the IAB node (e.g., a DU of the IAB node) is managed by the first IAB donor CU, and the first and second parent IAB network nodes are managed by a second IAB donor CU different from the first IAB donor CU.

[0020] The path information sent to the first IAB donor CU (e.g., F1 terminating donor CU) may be used to inform the F1 terminating donor CU of one or more routing paths in a different topology to be used to route data (e.g., F1 data, including user traffic, control traffic) to / from the IAB node, where the one or more routing paths include a new parent IAB network node and are therefore new routing paths. If the migration between parent IAB network nodes includes a new donor DU (e.g., if the new parent IAB network node is a new IAB donor DU or a parent IAB node connected (directly or indirectly) to the new IAB donor DU), the one or more routing paths are for routing data associated with the IAB node via the new IAB donor DU.

[0021] According to a fourth aspect of the present invention, there is provided a method executed in an IAB node for use in a migration process in which a mobile termination MT of the IAB node is migrated from a second IAB topology managed by a second IAB donor central unit CU to a third IAB topology managed by a third IAB donor CU, as set forth in claims 20 to 23 of the accompanying claims. An IAB node (e.g., a DU of the IAB node) managed by a first IAB donor CU manages the first IAB topology.

[0022] According to an example, a method is provided for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node migrates from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU. The IAB node is managed by a first IAB donor CU that manages the first IAB topology, and the method in the IAB node includes receiving one or more addresses associated with a target IAB donor DU of the third IAB topology from the third IAB donor CU, routing data associated with the IAB node in the third IAB topology via the addresses, and transmitting address information including the one or more addresses to the first IAB donor CU. Identification information for identifying the third IAB donor CU may be transmitted to the first IAB donor CU (e.g., the address information and the identification information may be transmitted in one message by the IAB node). The IAB node may transmit IAB node identification information including at least one identifier of the IAB node. The at least one identifier of the IAB node may include one or more of the information elements F1-terminated IAB-donor UE XnAP ID and non-F1-terminated IAB-donor UE XnAP ID or RRC-terminated IAB-donor UE XnAP ID and a BAP address assigned to the IAB node (e.g., assigned by the RRC donor CU).

[0023] According to a fifth aspect of the present invention, there is provided a method executed in a second IAB donor central unit (CU) for use in a migration process in which a mobile termination MT of an IAB node is migrated from a second IAB topology managed by the second IAB donor CU to a third IAB topology managed by a third IAB donor CU, as set forth in claims 24 to 25 of the accompanying claims, wherein the IAB node (e.g., a DU of the IAB node) is managed by a first IAB donor CU that manages a first IAB topology.

[0024] According to a sixth aspect of the present invention, there is provided a method executed in a first IAB donor central unit (CU) for use in a migration process in which a mobile termination MT of an IAB node migrates from a second IAB topology managed by a second IAB donor CU to a third IAB topology managed by a third IAB donor CU, as set forth in claims 26 to 30 of the accompanying claims, wherein the IAB node (e.g., a DU of the IAB node) is managed by the first IAB donor CU, which manages the first IAB topology.

[0025] Thus, by means of information (e.g., address information, e.g., address of the third or target donor DU to which the IAB node is already migrated, and / or identification information (e.g., PCI or NCGI) for identifying the third IAB donor CU) sent by the second IAB donor CU (non-F1 terminating donor CU or RRC terminating donor CU) or IAB node to the first IAB donor CU (F1 terminating donor CU) of the IAB node, the F1 terminating donor CU can be notified about the migration of the MT of the IAB node between two different topologies. For example, routing of at least one new routing path used to route data (e.g., F1 traffic, user traffic, and control traffic) of the migrated IAB node in the third IAB topology controlled by the target non-F1 terminated donor CU or target RRC terminated donor CU from a second IAB topology managed by a second IAB donor central unit (CU) (e.g., a source IAB donor CU) to a third IAB topology managed by a third IAB donor CU (e.g., a target IAB donor CU). The F1 terminated donor CU can then update configuration information for the IAB node based on the received information to update the routing paths (e.g., F1-C and F1-U routing paths) associated with or for the IAB node to the new routing path for routing data to / from the IAB node via the target donor DU.

[0026] Identification information including at least one identifier of the IAB node may be provided to the first IAB donor CU (F1-terminated donor CU). For example, the at least one identifier of the IAB node may include one or more of the following information elements: F1-terminated IAB-donor UE XnAP ID, non-F1-terminated IAB-donor UE XnAP ID, or RRC-terminated IAB-donor UE XnAP ID. The RRC-terminated donor CU and the BAP address assigned to the IAB node (e.g., the BAP address assigned by the RRC-terminated donor CU).

[0027] According to a seventh aspect of the present invention, there is provided a method executed in a second IAB donor CU for use in a migration process in which a mobile termination MT of an IAB node is migrated from a second IAB topology managed by the second IAB donor CU to a third IAB topology managed by a third IAB donor CU, wherein the IAB node (e.g. a DU of the IAB node) is managed by a first IAB donor CU managing a first IAB topology, as set out in claims 31 to 35 of the accompanying claims.

[0028] According to an eighth aspect of the present invention, there is provided a method executed in a first IAB donor CU for use in a migration process in which a mobile termination MT of an IAB node is migrated from a second IAB topology managed by a second IAB donor CU to a third IAB topology managed by a third IAB donor CU, as set forth in claims 36 to 46 of the accompanying claims, wherein the IAB node (e.g., a DU of the IAB node) is managed by the first IAB donor CU, which manages the first IAB topology.

[0029] Thus, by the handover request, a first donor CU (e.g., an F1 terminating donor CU) may be notified about the migration of an MT of an IAB node between two different topologies, for example, from a second IAB topology managed by a second IAB donor CU (e.g., a source IAB donor CU) to a third IAB topology managed by a third IAB donor CU (e.g., a target IAB donor CU).

[0030] A first IAB donor CU can initiate and execute migration of an MT of an IAB node to a third IAB donor CU, or the first IAB donor CU can initiate MT migration for execution by a second IAB donor CU.

[0031] In one example, the method further includes determining whether a migration process for a distributed unit (DU) of the IAB node has been initiated. In response to determining that the migration process for the DU of the IAB node has been initiated, delaying the migration (or delaying the initiation of the migration) of the MT of the IAB node to the third IAB donor CU until completion of the migration process for the DU of the IAB node.

[0032] In another example, the method further includes delaying initiation of a migration process for a DU of the IAB node until the migration process for an MT of the IAB node is completed, such as until setup of one or more routing paths (e.g., F1-C and F1-U) for routing data associated with the IAB node in the third IAB topology is completed.

[0033] In one example, the method may include determining whether a migration process has been initiated for a distributed unit (DU) of the IAB node. In response to determining that the migration process has been initiated for the DU of the IAB node, transmitting a handover response to the second IAB donor CU rejecting the handover request.

[0034] According to a ninth aspect of the present invention, there is provided a method, executed in a second integrated access backhaul (IAB) node, for use in managing a migration process in which a mobile termination (MT) of an IAB node is migrated from a first parent IAB node of a second IAB topology managed by a second IAB donor central unit (CU), to which a distributed unit (DU) of the IAB node is managed by the first IAB donor CU managing the first IAB topology, as set forth in claims 47 to 51 of the accompanying claims.

[0035] According to a tenth aspect of the present invention, there is provided a method, executed in a first IAB donor CU, for use in managing migration of a distributed unit (DU) of an integrated access backhaul (IAB) node in a mobile termination (MT), as set forth in claims 52 to 58 of the accompanying claims, wherein the MT of the IAB node is migrated from a first parent IAB node of a second IAB topology managed by a second IAB donor central unit (CU) to a second parent IAB node, the DU of the IAB node being managed by the first IAB donor CU managing the first IAB topology.

[0036] According to an eleventh aspect of the present invention, there is provided a method, executed in a first Integrated Access Backhaul (IAB) node central unit (CU), for use in managing a migration process in which a distribution unit (DU) of an IAB node migrates from a first IAB topology managed by a first IAB donor central unit (CU), to a third IAB topology managed by a third IAB donor CU, wherein a mobile termination (MT) of the IAB node is managed by a second IAB donor CU managing a second IAB topology, as set forth in claims 59 to 64 of the accompanying claims.

[0037] According to a twelfth aspect of the present invention, there is provided a method, executed in a second IAB donor CU, for use in managing migration of a migration terminal (MT) of an integrated access backhaul (IAB) node in a distribution unit (DU), as set out in claims 65 to 69 of the accompanying claims, wherein the migration process involves the DU of the IAB node migrating from a first IAB topology managed by a first IAB donor central unit (CU) towards a third IAB topology managed by a third IAB donor CU, and the mobile termination (MT) of the IAB node being managed by the second IAB donor CU managing the second IAB topology.

[0038] Performing MT migration simultaneously with performing DU migration can be avoided by ensuring that MT migration is completed before initiating DU migration (e.g., by initiating or delaying the initiation of DU migration until MT migration is completed, or by disabling initiating the migration process for the IAB node's DU until after the IAB node's MT has been migrated), or by checking whether DU migration has been initiated or started, and by delaying MT migration until DU migration is completed, or by disabling initiating the migration process for the IAB node's MT until after the IAB node's DU has been migrated. Because performing MT migration simultaneously with the migration of a co-located DU can lead to failure of at least one of the procedures or can dramatically increase signaling complexity, failures and increased signaling complexity can be avoided. To ensure a safe approach, it is desirable that MT migration be performed and completed while the co-located DU remains connected to the same donor, and that DU migration be performed and completed while the co-located MT remains connected to the same donor.

[0039] In another aspect of the present invention, a method is provided for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node migrates from a first parent IAB network node associated with a first IAB donor distribution unit (DU) to a second parent IAB network node associated with a second IAB donor DU, the IAB nodes being managed by a first IAB donor central unit (CU) of a first IAB topology, the first and second IAB donor DUs being managed by a second IAB donor CU of a second IAB topology, and the method in the IAB node transmitting to the first IAB donor CU address information including one or more addresses associated with the second IAB donor DU through which data associated with the second IAB node is routed in the second IAB topology.

[0040] According to a thirteenth 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.

[0041] According to a fourteenth aspect of the present invention, there is provided an apparatus for an IAB donor CU (eg, a source IAB donor CU or a target IAB donor CU) for an IAB communication system as set out in the accompanying claims.

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

[0043] In the following, we refer to sources and targets in terms of different elements such as nodes / topologies.

[0044] 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.

[0045] 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.

[0046] 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]

[0047] [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 exemplary message flow according to an embodiment of the present invention for supporting (multiple consecutive) MT migrations of an IAB node in an IAB topology controlled by the IAB node's non-F1 terminating donor CU. [Figure 7a]1 is a flowchart of an exemplary method for managing MT migration in an IAB topology controlled by its non-F1 terminating donor CU or RRC terminating donor CU in an IAB node, in accordance with one or more embodiments of the present invention. [Figure 7b] 1 is a flowchart of an example method for managing MT migration of an IAB node in a non-F1 terminating donor CU or an RRC terminating donor CU of the IAB node, in accordance with one or more embodiments of the present invention. [Figure 7c] 1 is a flowchart of an exemplary method for managing MT migration of an IAB node in an IAB topology at an F1 terminated donor CU of the IAB node at a non-F1 terminated donor CU or RRC terminated donor CU of the IAB node, in accordance with one or more embodiments of the present invention. [Figure 8] FIG. 2 is a schematic diagram of another exemplary IAB communication system (or IAB network system) in which embodiments and examples of the present invention may be implemented. [Figure 9] 1 is a schematic and simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for performing continuous MT migration of a mobile IAB node to a target IAB topology, including setting up a control data path. [Figure 10] 1 is a schematic and simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for setting up a user data path for continuous MT migration of a mobile IAB node towards a target IAB topology. [Figure 11] 1 is a schematic and simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for performing continuous MT migration of a mobile IAB node towards a target IAB topology following radio link failure (RLF) recovery of the IAB node. [Figure 12a]1 is a flowchart of an exemplary method, in accordance with one or more embodiments of the present invention, for managing successive MT migration at an IAB node toward a target IAB topology that differs from the IAB topology controlled by its F1-terminated donor CU and its source non-F1-terminated donor CU or source RRC-terminated donor CU. [Figure 12b] 1 is a flowchart of an exemplary method, in accordance with one or more embodiments of the present invention, for managing continuous MT migration of an IAB node at a source non-F1 terminated donor CU or source RRC terminated donor CU of the IAB node toward a target IAB topology that differs from the IAB topology controlled by the IAB node's F1 terminated donor CU. [Figure 12c] 1 is a flowchart of an exemplary method, consistent with one or more embodiments of the present invention, for managing, at an F1 terminated donor CU of an IAB node, continuous MT migration of the IAB node toward a target IAB topology that differs from an IAB topology controlled by the IAB node's source non-F1 terminated donor CU or source RRC terminated donor CU. [Figure 13] FIG. 10 is a schematic and simplified diagram illustrating another exemplary message flow according to one or more embodiments of the present invention for performing continuous MT migration of a mobile IAB node to a target IAB topology, including the setup of control and user data paths. [Figure 14a] 1 is a flowchart of an exemplary method, in accordance with one or more embodiments of the present invention, for managing continuous MT migration of an IAB node at a source non-F1 terminated donor CU or source RRC terminated donor CU of the IAB node toward a target IAB topology that differs from the IAB topology controlled by the IAB node's F1 terminated donor CU. [Figure 14b]1 is a flowchart of an exemplary method, in accordance with one or more embodiments of the present invention, for managing, at an F1 terminating donor CU of an IAB node, successive MT migration of an IAB node toward a target IAB topology that differs from the IAB topology controlled by the IAB node's source non-F1 terminating donor CU. [Figure 15] 1 is a schematic and simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for avoiding initiating a DU migration of an IAB node during a continuous MT migration of the IAB node. [Figure 16a] 1 is a flowchart of an exemplary method, in accordance with one or more embodiments of the present invention, for managing successive MT migrations of an IAB node at a source non-F1 terminated donor CU or source RRC terminated donor CU of the IAB node toward a target IAB topology that is different from the IAB topology controlled by the IAB node's F1 terminated donor CU without conflicting with the IAB node's DU migration. [Figure 16b] 1 is a flowchart of an exemplary method according to one or more embodiments of the present invention, executed in an F1 termination donor CU of an IAB node, for use in managing DU migration of the IAB node during continuous MT migration of the IAB node. [Figure 17] 1 is a schematic and simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for avoiding initiating successive MT migrations of an IAB node during DU migration of the IAB node. [Figure 18a] 1 is a flowchart of an exemplary method according to one or more embodiments of the present invention for managing DU migration of an IAB node at a source F1 terminating a donor CU of the IAB node so as not to conflict with successive MT migrations of the IAB node. [Figure 18b]1 is a flowchart of an exemplary method according to one or more embodiments of the present invention, performed in a non-F1 terminated donor CU or source RRC terminated donor CU of an IAB node, for use in managing MT migration of an IAB node during DU migration of the IAB node. DETAILED DESCRIPTION OF THE INVENTION

[0048] 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.

[0049] 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.).

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] The Integrated Access Backhaul (IAB) specifications are described in 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).

[0055] 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.

[0056] The IAB donor 120 is a logical node that provides NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and 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 DU or IAB donor DU) 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.

[0057] 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.

[0058] 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 called 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.).

[0059] 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.

[0060] 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.

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

[0062] The F1 interface supports the exchange of signaling information between endpoints as well as the transmission of data to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between the endpoints.

[0063] In 5G NR, F1-C is a functional interface in the control plane (CP) between the IAB donor CU and the IAB node-DU (e.g., IAB-Node2) and between the IAB donor CU and the IAB donor DU. F1-U is a functional interface in the user plane (UP) for the same 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-Node1, then from IAB-Node1 to IAB-Node2).

[0064] 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.

[0065] 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 between the IAB donor CU and the IAB node DU, or UE-related services. These services are, for example, initialization, configuration, etc. The well-known SCTP layer provides reliable and in-order message delivery with congestion control.

[0066] 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.

[0067] 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.

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

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

[0070] 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.

[0071] 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).

[0072] 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.

[0073] 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.

[0074] 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).

[0075] 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.

[0076] 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).

[0077] 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.

[0078] 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 the downlink traffic-routing ID mapping configuration table in the IAB-donor DU or the 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.).

[0084] 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.

[0085] 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.

[0086] 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.

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

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

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

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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).

[0100] 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.

[0101] The IAB communication system 500 is comprised of two IAB networks or IAB topologies 5001, 5002, each of which comprises a set of IAB nodes (e.g., the 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 two IAB topologies 5001, 5002, the present invention is not limited to two IAB topologies and may be implemented in an IAB communication system comprising more than two IAB topologies, each of which comprises a set of IAB nodes and an IAB donor CU as described above.

[0102] 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 an MT portion or unit 511 and a DU portion 512. IAB node 570 is a mobile IAB node and thus includes a mobile MT (MT) 571 and a mobile DU (DU) 572.

[0103] 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.

[0104] The IAB topology 5002 includes an IAB-donor CU 502 (identified as Donor2-CU in FIG. 5 ) and its associated IAB-donor DUs, IAB-donor DU 505 (identified as Donor2-DU1 in FIG. 5 ) and IAB-donor DU 506 (identified as Donor2-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.

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

[0106] 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.

[0107] 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 .

[0108] Assume that the mobile IAB node 570 initially has a single parent IAB node 520 via a backhaul link 5020, and that the IAB node 570 belongs to an IAB topology 5001 controlled by an IAB donor CU 501. When moving, given the IAB topology 5002, and in particular its proximity to IAB node 530 when the mobile IAB node 570 is in the position shown by the dotted line in FIG. 5, the mobile IAB node 570 may establish a wireless BH link 5030 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 IAB node 570, moving in the direction of the IAB topology 5002 (indicated by arrow 590 in FIG. 5).

[0109] According to the IAB framework in Release 17, several scenarios are possible. In the first scenario, the "Topology Compatibility Procedure" described in TS 38.401 V17.2.0 Chapter 8.17.2 is applied, and an IAB node 570 establishes dual connectivity with two parent IAB nodes (520, 530) that belong to two different IAB topologies.

[0110] Each IAB-DU and IAB donor DU supports wireless communication within a coverage area called a "cell." In other words, each IAB-DU and IAB donor DU is associated with a cell. Wireless communication devices (e.g., UEs or other IAB nodes) present within a cell connect to the node supporting that cell to communicate with other devices (including UEs, IAB nodes, and Internet services). When an IAB node 570 is initially connected to a single IAB topology (e.g., IAB topology 5001), the MT section or unit MT571 of the IAB node 570 periodically performs a cell search procedure defined in 3GPP TS 38.300 to detect the primary synchronization signal (PSS) and secondary synchronization signal (SSS) of neighboring cells. The IAB node 570 can report the existence of new cells controlled or activated by the IAB node 530 to its donor CU 501 via a measurement report containing the cell's identifier. The cell identifier may also identify the IAB donor CU that manages that cell. Based on the analysis of the measurement report, the donor CU 501 may request the donor CU 502 to establish dual connectivity via the IAB node 530 to establish an additional connection with the IAB node 570. The donor CU 502 accepts this request and can proceed with the connection with the IAB node 570 according to the procedure described in TS 37.340 V17.2.0, Chapter 10.2. As a result, the IAB node 570 still belongs to the IAB topology 5001 but is also connected to the IAB node 530 (which belongs to the IAB topology 5002), and may be referred to as a boundary node between the IAB topologies 5001 and 5002. In practice, the IAB node 570 maintains an F1 connection and an RRC connection with the IAB donor CU 501, and the donor CU 501 may be referred to as an F1-terminating IAB donor CU. The IAB node 570 also has another RRC connection with the donor CU 502, which may be referred to as the non-F1 terminated IAB donor CU.Note that an IAB donor CU that terminates an RRC connection of an IAB node is referred to as an RRC terminating donor CU or simply an RRC donor CU. The RRC terminating donor CU may be either an F1 terminating donor CU or a non-F1 terminating donor CU.

[0111] The IAB node or boundary node 570 is part of the IAB topology 5001 (from an F1 connection perspective) and is therefore controlled (e.g., configured and managed) by the IAB donor CU 502 of the IAB topology 5001. Through a second RRC connection, the donor CU 502 assigns a second BAP address to be used for routing packets through the IAB topology 5002. This results in the IAB node 570 (acting as a boundary node) having two BAP addresses: one for the IAB topology 5001 and one for the IAB topology 5002. Such boundary nodes help provide network path diversity by offering alternative routing paths through the IAB topologies 5001 and 5002.

[0112] In fact, the IAB donor CU 501 can balance the traffic load within the IAB topology 5001 by leveraging the dual connectivity between the IAB topologies 5001 and 5002 of the IAB node 570. That is, traffic (user traffic or control traffic) that would have been routed via the IAB node 570 can be offloaded or migrated from the path via the IAB nodes 510 and 520 and the backhaul link 5020. In an IAB communication system, all traffic communicated on the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Therefore, the offloaded or migrated traffic is F1 traffic, which may include both control traffic and user traffic. In this case, the "IAB Transport Migration Management Procedure" described in TS 38.401 V17.2.0 Chapter 8.17.2 is invoked by the donor CU 501. The donor CU 502 may reject migration requests for some or all traffic, for example, due to load issues within the IAB topology 5002. For example, traffic that was to be routed between the donor CU 501 and the IAB node 570 via a backhaul path (path 1) that includes the donor DU 504, IAB nodes 510, and 520 may be migrated or offloaded to a backhaul path (path 2) that includes the donor DU 505 and IAB node 530.

[0113] In a second scenario, the BH link or BH radio link 5020 may experience radio link degradation due to unexpected interference or shadowing. For this reason, the IAB node 570 may lose connection with the IAB node 520 and declare a Radio Link Failure (RLF) for the BH link 5020. In this case, the IAB node 570 may attempt to reestablish connection with the same or another parent IAB node (or donor DU). For example, the IAB node 570 may attempt to join the IAB topology 5002 managed by the IAB donor CU 502 via a new parent IAB node 530 and BH link 5030. In this case, the "Inter-CU Backhaul RLF Recovery Procedure" (described in TS38.401 V17.2.0 Chapter 8.17.4) applies, which allows recovery to a different parent node when an IAB node experiences a backhaul radio link failure (RLF) under a different IAB donor CU. In this procedure, the donor CU 502 sends a request to the donor CU 501 to obtain context information of the IAB node 570. Based on the response from the donor CU 501, the donor CU 502 can accept the connection of the IAB node 570. At this time, the IAB node 570 remains a boundary node belonging to the IAB topology 5001. In practice, the IAB node 570 maintains an F1 connection with the donor CU 501 (an F1-terminated IAB donor CU) and also has an RRC connection with the donor CU 502 (referred to as a non-F1-terminated IAB donor CU or an RRC-terminated donor CU, or an RRC donor CU).

[0114] The IAB donor CU 501 can then issue a request to migrate F1 traffic (user traffic and control traffic) associated with the IAB node 570 to the IAB topology 5002. In this case, the donor CU 501 invokes the "IAB Transport Migration Management Procedure" specified in TS38.423 V17.2.0 Chapter 8.5.2. The donor CU 502 may reject the request to migrate some or all of the traffic due to, for example, load issues within the IAB topology 5002.

[0115] In a third scenario, the IAB node 570 may be partially migrated to the IAB topology 5002. This means that the MT 571 is connected to the donor CU 502 and the RRC connection is migrated from the IAB donor CU 501 to the IAB donor CU 502. Indeed, based on the measurement report provided by the IAB node 570, the donor CU 501 may detect that the IAB node 570 can obtain a better connection via the cell of the IAB node 530, which belongs to the IAB topology 5002. As a result, the donor CU 501 may initiate the "IAB Inter-CU Topology Adaptation Procedure" described in TS38.401 V17.2.0 Chapter 8.17.3.1. In this procedure, the donor CU 501 sends a handover request to the donor CU 502, providing information to establish an RRC connection with the IAB node 570. Based on this information, donor CU 502 accepts the handover request, establishes a connection with IAB node 570, and becomes a boundary node that continues to belong to IAB topology 5001. That is, the F1 connection is maintained with donor CU 501 (F1-terminated donor CU) and the RRC connection is maintained with donor CU 502 (non-F1-terminated donor CU or RRC-terminated donor CU). This procedure may be applied after the first scenario (topology redundancy procedure) is completed, or it may be applied proactively in advance of a connection loss between IAB node 570 and IAB node 520.

[0116] The IAB donor CU 501 can then issue a request to migrate backhaul or F1 traffic associated with the IAB node 570 to the IAB topology 5002. In this case, the donor CU 501 initiates the "IAB Transport Migration Management Procedure" specified in TS38.423 V17.2.0 Chapter 8.5.2. Note that the donor CU2 may reject some or all of the migration requests due to load issues in the IAB topology 5002, etc.

[0117] If the IAB node 570 has child IAB nodes, a similar inter-CU topology adaptation procedure is applied. This procedure, specified in TS38.401 V17.2.0 Chapter 8.17.3.2, involves the donor CU 501 properly configuring the migrating node and its child IAB nodes to ensure that BAP packets are routed correctly.

[0118] In these scenarios, IAB topology 5001 is referred to as the "source IAB network" or "source IAB topology," and topology 5002 is referred to as the "target IAB network" or "target IAB topology." Also, donor CU 501 is referred to as the "source IAB donor CU" or "source donor CU," and donor CU 502 is referred to as the "target IAB donor CU" or "target donor CU."

[0119] The procedures applied in the second and third scenarios result in MT migration, i.e., partial migration, of IAB node 570. Note that in the first scenario, where IAB node 570 has dual connectivity with two parent IAB nodes 520 and 530, the MT of IAB node 570 remains connected to source IAB node 520.

[0120] In all three scenarios described above, the UE 580 connects to the donor CU 501 through the DU part or DU unit 572 of the mobile IAB node 570. Also, if the IAB node 570 has child IAB nodes, the child IAB nodes still belong to the IAB topology 5001 and are fully controlled by the donor CU 501 through F1 and RRC connections.

[0121] As it continues to move, the IAB node 570 may reach a location where the backhaul link 5050 with the IAB node 550 is of better quality than the backhaul link 5030 with the IAB node 530. Also, at some point, the IAB node 570 may experience a radio link failure (RLF) in the backhaul link 5030. Therefore, the above three scenarios may occur again, and in this case, an "intra-CU procedure" is considered instead of an "inter-CU procedure." Specifically, the donor CU 502 must perform one of the following: - "Intra-CU Topology Redundancy Procedure" as described in TS38.401 V17.2.0 Chapter 8.2.4 (resulting in IAB node 570 having dual connectivity with two parent IAB nodes, IAB nodes 530 and 550) - "Intra-CU Backhaul RLF Recovery Procedure" as described in TS38.401 V17.2.0 Chapter 8.2.5 (resulting in MT migration to a new single parent IAB node 550) - "Intra-CU Topology Adaptation Procedure" as described in TS38.401 V17.2.0 Chapter 8.2.3.1 (similarly, MT migration to a new single parent IAB node 550)

[0122] In the case where the MT migration of the IAB node 570 is toward the IAB node 550, the donor CU 502 needs to switch from the first backhaul path including the donor DU 505 and the IAB node 530 to the second backhaul path including the donor DU 506, the IAB node 540, and the IAB node 550. Also, the donor CU 501 needs to be notified to redirect the offloaded traffic (control and user traffic) via the donor DU 506 instead of via the donor DU 505. In the case of dual connectivity, the donor CU 502 can choose to maintain the first backhaul path (via the donor DU 505 and the IAB node 530) or switch to the second backhaul path (via the donor DU 506 and the IAB nodes 540 and 550). If the second backhaul path is selected, this case is also considered as a continuous MT migration for the IAB node 570, and the donor CU 501 needs to be notified.

[0123] As an example of a method according to one or more embodiments of the present invention, the following describes a method in which an F1-terminated donor CU of an IAB node (e.g., a mobile IAB node) is notified of a MT migration of the IAB node (e.g., a continuous MT migration of the IAB node) between IAB nodes in an IAB topology managed by a non-F1-terminated donor CU or an RRC-terminated donor CU, and is further notified of at least one new routing path to be used to route data (e.g., user traffic, control traffic, F1 traffic) associated with the migrated IAB node within the IAB topology managed by the non-F1-terminated donor CU. Note that while the method / apparatus described below is primarily described with respect to a mobile IAB node, it should be understood that the present invention is not limited to mobile IAB nodes. The method according to one or more embodiments of the present invention may also be applied to a fixed IAB node, for example, located at the edge of an IAB topology and in the vicinity of one or more IAB nodes in an adjacent IAB topology. A non-F1-terminated donor CU or a non-F1-terminated donor CU is also known as an RRC-terminated donor CU or an RRC donor CU.

[0124] 6 is a schematic and simplified diagram 600 illustrating an example of message flow for supporting (multiple consecutive) MT migrations of an IAB node in an IAB topology controlled by a non-F1 terminating donor CU, according to one or more embodiments of the present invention. The multiple consecutive MT migrations include multiple new MT migrations between different parent IAB nodes, which are managed by a different donor CU than the donor CU that provides the DU of the IAB node, or at least are connected (directly or indirectly) to different donor DUs that are managed by a different donor CU than the donor CU that provides the DU of the IAB node, or are connected (directly or indirectly) to the same donor DU.

[0125] The diagram illustrates an IAB node 601, which may be a mobile IAB node, such as IAB node 570 of Figure 5 and / or IAB node 123 of Figure 1. When IAB node 601 is a mobile IAB node, it includes a mobile termination (MT) 603 (identified as an IAB-MT) and a distributed unit (DU) 602 (identified as an IAB-DU). The diagram also illustrates a non-F1 terminated donor CU (or non-F1 donor CU) 604 that terminates an RRC connection with IAB node 601 via IAB-MT 603, and an F1 terminated donor CU (or F1 donor CU) 605 that terminates an F1 connection with IAB node 601 via IAB-DU 602. As an example, with respect to the IAB communication system of FIG. 5, the F1 terminating donor CU 605 for the IAB node is donor CU 501, the MT 571 of the IAB node 570 has been migrated to the IAB topology 5002 managed by donor CU 502, and the non-F1 terminating donor CU 604 is donor CU 502.

[0126] At the beginning of flow 600, the following assumption is made: the control path (F1-C) and user path (F1-U) established by the F1 donor CU 605 to the IAB node 601 exist in the IAB topology managed by the non-F1 donor CU 604 (the donor DU is not depicted in FIG. 6). For example, based on FIG. 5, the backhaul path including the donor DU 505 and the IAB node 530 is an example.

[0127] Next, it is assumed that the non-F1 donor CU 604 receives the measurement report 611 from the IAB node 601 and initiates MT migration. This corresponds to the example in FIG. 5 where the MT 571 of the IAB node 570 migrates from the IAB node 530 to a new parent IAB node 550 within the same IAB topology 5002. In this example, the following characteristics exist: The source parent IAB node (IAB node 530) and the target parent IAB node (IAB node 550) are connected to different donor DUs (505, 506). Both donor DUs are controlled by the donor CU 502 that manages the DUs 505 and 506, which is different from the donor CU 501 that manages the DU 572. Therefore, this migration is considered as a "continuous MT migration." In this example, the flow 600 is further explained using an "intra-CU topology adaptation procedure."

[0128] The measurement report 611 is received by the non-F1 donor CU 604 via an F1 message "UL RRC MESSAGE TRANSFER (specified in TS 38.423)" sent by the source parent IAB node of the IAB node 601 (e.g., IAB node 530 in FIG. 5). This F1 message embeds an RRC message containing a measurement report sent by the IAB-MT 603 to the DU part of the source parent IAB node. The measurement report is a measurement result periodically performed by the IAB-MT 603 and is based on signals received from a serving cell and one or more target cells (e.g., signal synchronization blocks (SSBs) transmitted by the serving cell and target cells). The target cell may be a cell neighboring the serving cell (i.e., the current serving cell). When the IAB-MT 603 detects at least one SSB that meets a predetermined criterion (e.g., received power exceeding a predetermined threshold), a measurement report can be generated and transmitted to provide radio link quality information of multiple cells in the vicinity of the IAB node 601. The identification information of each target cell is included in the measurement report, allowing the non-F1 donor CU 604 to identify the target donor CU corresponding to each target cell.

[0129] Based on the received measurement report, the non-F1 donor CU 604 can detect that the IAB node 601 receives better radio signal quality from the cell of the target parent IAB node than from the source serving cell. For example, if the target parent IAB node (e.g., IAB node 550 in FIG. 5) belongs to the same IAB topology as the source parent IAB node (e.g., IAB node 530), the non-F1 donor CU 604 can decide to apply an “intra-CU topology adaptation procedure” to the IAB node 601. Furthermore, in this example, the target parent IAB node is configured to route packets via a new donor DU (e.g., via the new donor DU 506 instead of donor DU 505). While this example illustrates a configuration in which an MT in IAB node 601 is migrated from a parent IAB node 530 connected to a donor DU 505 to a new parent IAB node 550 connected (albeit indirectly) to a new donor DU 506, it is understood that the following (e.g., same intra-CU topology adaptation procedure) is applicable when an MT in IAB node 601 migrates from a parent IAB node to a new parent IAB node, and may also apply when the parent IAB node and new parent IAB node are connected (directly or indirectly) to the same donor DU. In this case, it is still useful to notify the F1 donor CU of such a migration, since the F1 donor CU may need to reconfigure the IAB node to which it migrates. A non-F1 donor CU can notify the F1 donor CU via the "IAB Transport Migration Modification Procedure" described below.

[0130] After requesting UE context creation to the target parent IAB node (e.g., IAB node 550) (this procedure is not shown in FIG. 6 but is specified in TS 38.423 V17.2.0, chapter 8.2.4), the non-F1 donor CU 604 sends an F1 message "UE CONTEXT MODIFICATION REQUEST" to the source parent IAB node, which relays "RRC reconfiguration information" to the IAB node 601. In particular, the RRC reconfiguration message 612 contains the transport network layer (TNL) address (IP address) for packet routing of the target donor DU (e.g., donor DU 506). (In the example of FIG. 5, the address of donor DU 505 is replaced with the address of donor DU 506.)

[0131] After performing a random access procedure with the target parent IAB node (e.g., IAB node 550), the IAB node 601 sends an RRC reconfiguration complete message 613 to the non-F1 donor CU 604 (this transmission is via the target parent IAB node and is encapsulated in the F1 message "UL RRC MESSAGE TRANSFER").

[0132] If an intra-CU topology redundancy procedure or an intra-CU backhaul RLF recovery procedure is used, the message exchange is slightly different, but in either case the identity of the target donor DU is notified to the IAB node 601 via an RRC reconfiguration message (e.g., message 612), etc.

[0133] The next part concerns the process of updating the routing paths (F1-C and F1-U) between the IAB node 601 and the F1 donor CU 605 via the target donor DU.

[0134] The non-F1 donor CU 604 configures the following: a backhaul RLC channel (BH RLC channel) and a routing entry for the BAP sublayer on the target path between the target parent IAB node (e.g., IAB node 550) and the target IAB donor DU (e.g., donor DU 506). Additionally, the non-F1 donor CU 604 may establish an additional BH RLC channel for the migrating IAB-MT (e.g., for the backhaul link between the target parent IAB node and IAB-MT 603 of IAB node 601) via RRC message 614.

[0135] As a first option for informing the F1 donor CU 605 via the IAB node 601 of new path information (e.g., backhaul path) for data routed through the target parent IAB node, the DU portion of the IAB node 601 (i.e., IAB-DU 602) can send a “DU configuration update message” 615 to the F1 donor CU 605. This message is the F1 message “gNB-DU CONFIGURATION UPDATE” specified in TS 38.473 V17.2.0 Chapter 9.2.1.7, and includes information identifying the target donor DU for F1-C and F1-U traffic. This target donor DU information is known by the IAB node 601 upon receiving the message 612. This message 615 is destined for the F1 donor CU 605, and when received by the target donor DU, it is subsequently routed to the F1 donor CU 605 via a wired backhaul (e.g., 508 in FIG. 5 ).

[0136] Upon receiving the identification information of the target donor DU, the F1 donor CU 605 updates its own configuration information and delivers F1 packets addressed to the IAB node 601 via the target donor DU (e.g., donor DU 506). At this time, the path of the F1 control data (F1-C) is also updated.

[0137] To complete the F1 user data (F1-U) path update, the F1 donor CU 605 can initiate the "IAB Transport Migration Management Procedure" specified in TS 38.423 V17.2.0, Chapter 8.5.2. In this procedure, multiple protocol messages (not shown in FIG. 6) are exchanged between the F1 donor CU 605 and the non-F1 donor CU 604. The non-F1 donor CU 604 can provide new configuration parameters (e.g., backhaul RLC channel information) that the IAB node 601 uses to transmit user data packets. These configuration parameters are conveyed from the F1 donor CU 605 to the IAB node 601 via an F1 message (e.g., the "BAP Mapping Configuration Message" specified in TS 38.423 V17.2.0, Chapter 9.2.9.1).

[0138] As a second option for informing the F1 donor CU 605 of the new path information for data routed through the target parent IAB node, the non-F1 donor CU 604 may do so using a configuration update message 616 and a configuration update response message 617. The message 616 sent by the non-F1 donor CU 604 includes the identification information of the target donor DU. Message 617 is an acknowledgment of receipt thereof.

[0139] According to one example, message 616 may be an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message as defined in TS 38.423 V17.2.0 (Xn Protocol) Section 9.1.4.4, and message 617 may be an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message as defined in Section 9.1.4.5, which are used in the IAB transport migration modification procedure. In this example, in message 616, the non-F1 donor CU 604 may also provide new configuration parameters (e.g., backhaul RLC channel information) that the IAB node 601 will use to transmit user data packets. In this case, the F1 donor CU 605 can receive all necessary information about the F1 path with the IAB node 601 in a single message. (In Option 1 described above, the F1 donor CU 605 itself initiated the IAB transport migration management procedure after receiving the DU Configuration Update message 615.)

[0140] As another example, message 616 may be an NG-RAN NODE CONFIGURATION UPDATE message, and message 617 may be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, as specified in TS 38.423 V17.2.0 (Xn Protocol) Chapters 9.1.3.4 and 9.1.3.5. After this "NG-RAN Node Configuration Update Procedure," the F1 donor CU 605 may initiate the "IAB Transport Migration Management Procedure" (specified in TS 38.423 V17.2.0 Chapter 8.5.2) to fully configure the F1 path. In this procedure, the F1 donor CU 605 requests and receives information about the F1 path (e.g., BH RLC channel information) from the non-F1 donor CU 604. Instead of the IAB Transport Migration Management procedure, the non-F1 donor CU 604 may initiate the IAB Transport Migration Modification procedure described in TS 38.423 V17.2.0 Section 8.5.3 for the same purpose (i.e., to complete the F1 path setup after the NG-RAN Node Configuration Update procedure).

[0141] To enable the F1 donor CU 605 to identify the migrating IAB node 601 based on a message received at the F1 donor CU 605 associated with a migrated IAB node in an IAB topology managed by a non-F1 donor CU 604, the message includes one or more identifiers of the migrating IAB node. The message indicates that a new routing / backhaul path should be used to route data associated with the migrating IAB node. For example, in these procedures (NG-RAN Node Configuration Update, IAB Transport Migration Management, and IAB Transport Migration Change), the message includes one or more of the following information elements as identifiers corresponding to the IAB node 601: F1-terminated IAB donor UE XnAP ID, non-F1-terminated IAB donor UE XnAP ID, and RRC-terminated IAB donor UE XnAP ID. These are set during the first MT migration of the IAB node 601. As specified in TS 38.423, Chapter 9.2.3.16, the NG-RAN node UE XnAP ID uniquely identifies the UE on the Xn interface. Therefore, each donor CU assigns an ID to each IAB node in its IAB topology. When the IAB node 601 is first accepted by the F1 donor CU 605, the F1 donor CU 605 assigns the ID. Later, during MT migration, the non-F1 donor CU 604 assigns a new ID. Both IDs are communicated during the exchange of handover request / acknowledge messages. Another identifier of the IAB node 601 is the BAP address. Each IAB donor CU that terminates an RRC connection assigns a BAP address to that IAB node (used to route BAP packets to that IAB node within the IAB topology). The F1 donor CU 605 may have assigned a BAP address to the IAB node 601 if it is authorized in the IAB topology. In MT migration, the non-F1 donor CU or RRC donor CU 604 assigns another BAP address to the IAB node 601.

[0142] 7a-7c illustrate flowcharts of example methods according to one or more embodiments of the present invention, performed at different network nodes in a wireless communication system (e.g., the communication system and IAB communication system shown in and described with reference to FIGS. 1 and 5). In general, the disclosed method is used when a MT of an IAB node (e.g., a mobile IAB node) migrates (e.g., successively migrates) from a first parent IAB network node (e.g., a source IAB network node) to a second parent IAB network node (e.g., a target IAB network node) within a second IAB topology, where the IAB node is managed (or controlled / provided) by a first IAB donor CU (e.g., an F1-terminated donor CU) of the first IAB topology, and the first and second parent IAB network nodes are managed (or controlled / provided) by a second IAB donor CU (e.g., a non-F1-terminated donor CU or an RRC-terminated donor CU). The method includes transmitting, to a first IAB donor CU, path information related to one or more routing paths used to route data (e.g., user traffic and control traffic, F1 traffic) associated with the IAB node in a second topology via a second parent IAB network node. The first parent IAB network node is associated with a first IAB donor DU, and the second parent IAB network node is associated with a second IAB donor DU. The first and second IAB donor DUs are connected to the second IAB donor CU. The first parent IAB network node is either an IAB node or the first IAB donor DU in the second IAB topology, and the second parent IAB network node is likewise either an IAB node or the second IAB donor DU. The path information sent to the first IAB donor CU (F1 terminating donor CU) may be used to inform the F1 terminating donor CU about one or more routing paths to be used to route data (F1 data, user traffic, control traffic, etc.) associated with that IAB node through a new parent IAB network node in a different topology.These one or more routing paths are new routing paths because they include a new parent IAB network node. If the migration between parent IAB network nodes involves a new donor DU (e.g., if the new parent IAB network node is a new IAB donor DU, or if the new parent IAB node is directly or indirectly connected to a new IAB donor DU), the one or more routing paths are for routing data related to the IAB node via the new IAB donor DU.

[0143] The information related to one or more routing paths may be one or more addresses (or address information) (e.g., IP address, TNL address) related to the second or new IAB donor DU. The IAB TNL address is specified in TS38.423, clause 9.2.2.92, and indicates an IPv4 address or IPv6 address prefix assigned to an IAB node. There may be one or more IP addresses for F1-C traffic and one for F1-U traffic (see TS38.331, clause 5.3.5.12a.1.2, "Adding / Modifying IP Addresses"). As an example, identification information including the identifier of at least one IAB node may be transmitted. The identifier may include an identifier of the IAB node known to the F1-terminated donor CU and / or non-F1-terminated donor CU; for example, the message may include an F1-terminated IAB donor UE XnAP ID, a non-F1-terminated IAB donor UE XnAP ID, an RRC-terminated IAB donor UE XnAP ID, and / or a BAP address assigned to the IAB node. The path information and identification information may be sent by the IAB node (e.g., see FIG. 7a below) or by a second IAB donor CU (e.g., a non-F1-terminated donor CU of a mobile IAB node) (e.g., see FIG. 7b below). The second IAB donor CU (e.g., a non-F1-terminated donor CU of a mobile IAB node) may also send configuration information including configuration parameters for each backhaul link (e.g., BH RLC channel information, BAP sublayer routing information). The path information and configuration information may be sent by a second IAB donor CU (eg, a non-F1 terminating donor CU of a mobile IAB node) in the same message.

[0144] Although the following description is primarily focused on mobile IAB nodes, it should be understood that the methods according to one or more embodiments of the present invention are not limited to mobile IAB nodes, but are also applicable to fixed IAB nodes, for example, those located at the edge of one IAB topology and in close proximity to one or more IAB nodes in other adjacent IAB topologies.

[0145] Thus, the address information related to the target donor DU (after migration to a new parent IAB network node) sent by the second IAB donor CU (non-F1 terminating donor CU) or IAB node to the first IAB donor CU (F1 terminating donor CU) can inform the F1 terminating donor CU about the successive MT migrations between parent IAB network nodes within the IAB topology managed by the non-F1 terminating donor CU and the new routing paths for data related to the migrated IAB node (e.g., F1 data, user traffic, control traffic). The F1 terminating donor CU may then update the configuration information for the IAB node based on the received information and update the routing paths for the IAB node (e.g., F1-C and F1-U routing paths) to the new routing paths for routing data to and from the IAB node via the target donor DU.

[0146] FIG. 7a is a flowchart of an exemplary method 700 according to one or more embodiments, performed in an IAB node (e.g., a mobile IAB node or mIAB node) for use in a migration process (or portion thereof) in which an MT of the IAB node is migrated (e.g., continuously) within a second IAB topology, which is different from the first IAB topology. The method 700 is for managing continuous MT migration within an IAB topology managed by a non-F1 terminating donor CU in an IAB node. For example, in the IAB communication system described with respect to FIG. 5, the IAB node performing the method 700 is the mobile IAB node 570, which belongs to the first IAB topology 5001 and is managed by the first IAB donor CU 501 (e.g., an F1 terminating donor CU that maintains an F1 connection with the mobile IAB node 570). The migration process includes the MT 571 of the mIAB node 570 migrating from a first parent IAB node 530 (associated with the donor DU 505) to a second parent IAB node 550 (associated with the donor DU 506) (i.e., the routing path for the mIAB node 570 switches from including the parent IAB node 530 and the donor DU 505 to including the parent IAB node 550, the IAB node 540, and the donor DU 506). The IAB topology 5002 is managed by the IAB donor CU 502 (e.g., a non-F1 terminated donor CU having an RRC connection with the mobile IAB node 570). The method 700 shown and described in FIG. 7a 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 in FIG. 7a may be performed by one or more processing units, such as the central processing unit 411.

[0147] As part of a migration process in which an MT of an IAB node (e.g., mobile IAB node 570) managed by a first IAB donor CU (e.g., F1-terminating donor CU 501 of IAB topology 5001) migrates from a first parent IAB network node (associated with a first donor DU) to a second parent IAB network node (associated with a second donor DU), in step 701, the IAB node (e.g., IAB node 570) receives, from a non-F1-terminating donor CU (e.g., donor CU 502), path information related to one or more routing paths used to route data associated with the IAB node in the second IAB topology through the target parent IAB network node. The path information may include one or more addresses (e.g., IP addresses) associated with the second donor DU (e.g., donor DU 506). For example, the IAB node may receive the address of the target donor DU via a message such as message 612 described above.

[0148] In step 702, the IAB node 570 transmits path information related to one or more routing paths used to route data related to the mobile IAB node 570 (e.g., data sent to or received from the mobile IAB node) through a second IAB donor DU (e.g., donor DU 506). The path information may be transmitted after MT migration of the IAB node 570. The path information related to the one or more routing paths may include address information (e.g., IP address, TNL address), such as one or more addresses (e.g., IP address, TNL address) associated with the second IAB donor DU. As an example, the IAB node 570 may further transmit identification information including an identifier of the IAB node known by both IAB donor CUs (501 and 502). For example, the message may include an F1-terminated IAB donor UE XnAP ID, a non-F1-terminated IAB donor UE XnAP ID, an RRC-terminated IAB donor UE XnAP ID, and / or a BAP address assigned to the IAB node. The IAB node 570 may send the received path information (e.g., the receiving address of the target donor DU) to an F1 terminating donor CU (e.g., donor CU 501), which controls an IAB topology 5001 that is different from the IAB topology 5002 controlled by the IAB donor CU 502. For example, the IAB node 570 may send the receiving address of the target donor DU in a message such as the DU configuration message 615, as described above.

[0149] 7b is a flowchart of an example method 710 according to one or more embodiments, performed by a second IAB donor CU (e.g., a non-F1 terminated donor CU) during (or part of) a migration process of an MT in an IAB node (e.g., a mobile IAB node or mIAB node). The method 710 is for managing continuous MT migration in an IAB node at the non-F1 terminated donor CU. For example, in the IAB communication system described with respect to FIG. 5, the second IAB donor CU performing the method 710 may be the IAB donor CU 502 (e.g., a non-F1 terminated donor CU having an RRC connection with the mobile IAB node 570). The IAB node is the mobile IAB node 570, belongs to a first IAB topology 5001, and is managed by the first IAB donor CU 501 (e.g., an F1 terminated donor CU that maintains an F1 connection). The migration process includes migrating the MT 571 of the mIAB node 570 from the first parent IAB node 530 (associated with the donor DU 505) to the second parent IAB node 550 (associated with the donor DU 506), which belong to the second IAB topology 5002 and are managed by the IAB donor CU 502. The method 710 shown and described in FIG. 7b may be performed by software and / or hardware elements. The non-F1 terminating IAB donor CU may be implemented in the communication device 400 shown in and described with reference to FIG. 4, and the method shown and described in FIG. 7b may be performed by one or more processing units, such as the central processing unit 411.

[0150] In step 711, a non-F1 terminated donor CU (e.g., donor CU 502) of an IAB node (e.g., mobile IAB node 570) determines that an MT (e.g., MT 571) of the IAB node managed by a first IAB donor CU (e.g., F1 terminated donor CU 501) should be migrated from a first parent IAB network node to a second parent IAB network node within the IAB topology managed by the same non-F1 terminated donor CU (e.g., this migration involves a change from IAB donor DU 505 to IAB donor DU 506 within IAB topology 5002), where the first parent IAB network node is associated with a first donor DU (source donor DU), and the first parent IAB network node may be the source donor DU or another IAB node. Also, the second parent IAB network node is associated with a second donor DU (target donor DU), and the second parent IAB network node may be the target donor DU or another IAB node. For example, a non-F1 terminated donor CU (e.g., donor CU 502) determines to execute an intra-CU procedure, which leads to identifying a target donor DU for routing packets to and from the IAB node 570 in the IAB topology controlled by the non-F1 terminated donor CU 502. The intra-CU procedure may be an intra-CU topology adaptation procedure for an IAB node, or an intra-CU topology redundancy procedure, or an intra-CU backhaul RLF recovery procedure, as discussed above.

[0151] In step 712, the non-F1 terminated donor CU 502 sends to the first IAB donor CU (F1 terminated donor CU 501) of the IAB node 570 path information related to one or more routing paths used to route data related to the IAB node 570 to or from the second donor DU 506. The path information may include, for example, address information (e.g., IP address or TNL address) related to the second IAB donor DU. Additionally, the non-F1 terminated donor CU 502 may send identification information including an identifier of the mobile IAB node known by both IAB donor CUs (501 and 502). In one example, the message may include an F1 terminated IAB donor UE XnAP ID, a non-F1 terminated IAB donor UE XnAP ID, an RRC terminated IAB donor UE XnAP ID, and / or a BAP address assigned to the IAB node. The non-F1 terminated donor CU 502 may send the address(es) of the target donor DU to the F1 terminated donor CU 501 of the IAB node 570, along with identifiers of the IAB nodes recognized by the two donor CUs. For example, the non-F1 terminated donor CU 502 may send the received address(es) of the target donor DU in a message such as message 616 described above. Configuration information including one or more configuration parameters of BH RLC channel information and BAP sublayer routing information for each backhaul link in one or more routing paths may also be sent by the non-F1 terminated donor CU. The configuration information may be sent in the same message as the received addresses, as described above.

[0152] 7c is a flowchart of an example method 720 according to one or more embodiments, performed by a first donor CU (e.g., an F1-terminating donor CU of an IAB node) during a migration process (or portion thereof) of an MT of an IAB node. The method 710 is for managing, at an F1-terminating donor CU of an IAB node, continuous MT migration within an IAB topology of a non-F1-terminating donor CU of the IAB node. For example, in the IAB communication system described with respect to FIG. 5, the first IAB donor CU performing the method 720 may be the IAB donor CU 501 (e.g., the F1-terminating donor CU of a mobile IAB node 570). The IAB node is a mobile IAB node 570 belonging to a first IAB topology 5001 and is managed by the IAB donor CU 501. The migration process includes migrating the MT 571 of the mIAB node 570 from a first parent IAB node 530 associated with the IAB donor DU 505 to a second parent IAB node 550 associated with the IAB donor DU 506 within the IAB topology 5002 managed by the IAB donor CU 502 (e.g., a non-F1 terminated donor CU having an RRC connection with the mobile IAB node 570). The method 720 shown and described in FIG. 7c may be performed by software and / or hardware elements. The F1 terminated IAB donor CU may be implemented in the communications device 400 described with respect to FIG. 4, and the method shown and described in FIG. 7c may be performed by one or more processing units, such as the central processing unit 411.

[0153] As part of the migration process, when an MT 571 of an IAB node (e.g., mobile IAB node 570) managed by an F1-terminated donor CU (e.g., IAB donor CU 501) migrates from a parent IAB network node associated with a first IAB donor DU (e.g., source donor DU 505) to another parent IAB network node associated with a second IAB donor DU (e.g., target donor DU 506) within the same IAB topology managed by a non-F1-terminated donor CU (e.g., donor CU 502), in step 721, the F1-terminated donor CU (e.g., IAB donor CU 501) receives path information related to one or more routing paths used to route data associated with the mobile IAB node 570 through the target IAB donor DU (e.g., IAB donor DU 506). The path information may be received from the non-F1-terminated donor CU 502 of the IAB node 570 or from the IAB node 570 itself. After the MT of the IAB node 570 is migrated, path information may be received. The path information associated with one or more routing paths may be or may include address information, such as one or more addresses (e.g., IP address, TNL address) associated with a second IAB donor DU (e.g., target donor DU). As an example, the F1-terminated donor CU may receive identification information including identifiers of mobile IAB nodes known by the two IAB donor CUs 501, 502. For example, the message may include one or more of an F1-terminated IAB donor UE XnAP ID and a non-F1-terminated IAB donor UE XnAP ID, or an RRC-terminated IAB donor UE XnAP ID and a BAP address assigned to the IAB node.For example, the F1-terminated donor CU (e.g., IAB donor CU 501) may receive the address of the target donor DU (e.g., target donor DU 506) as well as identifiers of IAB nodes known by the two donor CUs from the non-F1-terminated donor CU 502 of an IAB node whose MT portion has already been migrated into the IAB topology controlled by the non-F1-terminated donor CU 502 (e.g., in a message such as message 616). Alternatively, the F1-terminated donor CU may receive the address information of the target donor DU from the IAB node itself (e.g., message 615). When receiving a message from the non-F1-terminated donor CU 502, the message may also include configuration parameters for each backhaul link (e.g., BH RLC channel information, BAP sublayer routing information).

[0154] In step 722, the F1 termination donor CU 501 updates configuration information related to the IAB node 570 based on the received information and updates data associated with the IAB node 570 to a new routing path (e.g., F1-C and F1-U routing paths) for routing through the target donor DU 506. For example, the F1 termination donor CU updates the F1 control path and the user data path to reach the IAB node through the target donor DU in the IAB topology managed by the non-F1 termination donor CU. Furthermore, the F1 termination donor CU 501 may send additional configuration information to the IAB node 570 to configure the IAB node 570 based on the configuration parameters (e.g., BH RLC channel information and BAP sublayer routing information) received from the non-F1 termination donor CU 502.

[0155] FIG. 8 illustrates another IAB communication system (or IAB network system) 800 in which an embodiment of the present invention or examples thereof may be implemented. As an example, BH radio links operate in the millimeter wave frequency band (above 30 GHz), which is highly sensitive to wireless channel variations. Here, an IAB network is also referred to as an IAB topology or simply topology, and these terms are used interchangeably herein.

[0156] The IAB communication system 800 is comprised of three IAB networks or IAB topologies 8001, 8002, and 8003. Each IAB topology includes multiple IAB nodes (e.g., an initiating IAB node and a relay IAB node) and an IAB donor CU that controls and manages them. The set of IAB nodes may include one or more IAB nodes, including an initiator IAB node that generates BAP packets and a relay IAB node. Each IAB node communicates with at least one other IAB node via a wireless backhaul (BH) link. While FIG. 8 illustrates three IAB topologies, 8001, 8002, and 8003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system including more than two IAB topologies. Each topology may include a set of IAB nodes and an IAB donor CU, as described above.

[0157] As described above, each IAB node includes a mobile termination (MT) section or unit that is controlled and configured by the IAB donor via RRC messaging (as defined in 3GPP TS 38.331) and a distributed unit (DU) section that is controlled and configured by the IAB donor via F1-AP messaging (as defined in 3GPP TS 38.473). For example, IAB node 810 includes an MT section 811 and a DU section 812. IAB node 870 is a mobile IAB node and includes a mobile MT (MT) 871 and a mobile DU (DU) 872.

[0158] IAB topology 8001 consists of IAB donor CU 801 (denoted as Donor1-CU in FIG. 8 ), its associated IAB donor DU 804 (Donor1-DU1), and IAB nodes 810 and 820 (similar to IAB nodes 121 and 122). IAB topology 8002 includes IAB donor CU 802 (Donor2-CU in FIG. 8 ), its associated IAB donor DU 805 (Donor2-DU1) and IAB donor DU 806 (Donor2-DU2 in FIG. 8 ), as well as IAB nodes 830, 840, and 850 (similar to IAB nodes 121 and 122), and a mobile IAB node 870 (similar to IAB node 123). All IAB nodes are capable of functioning as access nodes for terminals such as user equipment (UE) 880. The IAB topology 8002 is transparent to the UE 880 in that the UE 880 connects to the donor CU 802 via the DU unit 872 of the mobile IAB node 870. While only the UE 880 is shown in FIG. 8, it goes without saying that in practice many UEs are connected to the network nodes of the IAB communication system 800.

[0159] IAB topology 8003 consists of IAB donor CU 803 (Donor3-CU in FIG. 8), its associated IAB donor DU 807 (Donor3-DU1 in FIG. 8), and IAB node 860 (similar to IAB nodes 121 and 122).

[0160] A wired backhaul IP network 808 interconnects IAB donor CUs 801, 802, and 803 and IAB donor DUs 804, 805, 806, and 807. For example, the wired backhaul 808 is comprised of fiber optic cables.

[0161] IAB donor CU 801, IAB donor DU 804, and IAB nodes 810 and 820 are part of an IAB network or IAB topology 8001, which is configured and managed by IAB donor CU 801.

[0162] The IAB donor CU 802, IAB donor DUs 805, 806, and IAB nodes 830, 840, 850 are part of an IAB network or IAB topology 8002, which is configured and managed by the IAB donor CU 802.

[0163] The IAB donor CU 803, IAB donor DU 807, and IAB node 860 are part of an IAB network or IAB topology 8003, which is configured and managed by the IAB donor CU 803.

[0164] Mobile IAB node 870 was initially connected to a single parent IAB node 820 and belonged to IAB topology 8001 (managed by IAB donor CU 801). As it moved, mobile IAB node 870 approached IAB topology 8002, particularly as it approached IAB node 830 at the location indicated by the dotted line in FIG. 8, and potentially established a wireless BH link with IAB node 830. Such a BH link is also possible for fixed IAB nodes, and is even more likely to occur when a node is moving, such as mobile IAB node 870. (The direction of movement is indicated by arrow 890 in FIG. 8.)

[0165] Subsequently, the F1 donor CU 801 may have decided to migrate the MT unit 871 of the IAB node 870 to an IAB topology managed by the donor CU 802. This donor CU 802 becomes a non-F1 donor CU (i.e., the donor CU managing the RRC connection) for the IAB node 870 (i.e., the MT unit 871 of the IAB node 870 is migrated toward the parent IAB node 830). For this purpose, the F1 donor CU 801 may have initiated the inter-CU topology adaptation procedure described in TS38.401 V17.2.0 Chapter 8.17.3.1 or (if the IAB node 870 has a child IAB node) Chapter 8.17.3.2. As a result, the IAB node 870 still belongs to the IAB topology 8001 while maintaining its F1 connection, but its RRC connection has been changed to the donor CU 802. After this procedure, the IAB donor CU 801 may request that backhaul traffic associated with the IAB node 870 be migrated to the IAB topology 8002 (i.e., via the donor DU 805). In this case, the donor CU 801 initiates the IAB transport migration management procedure specified in TS38.423 V17.2.0 Chapter 8.5.2.

[0166] While the mobile IAB node 870 moves further, the MT part 871 of the IAB node 870 may have been migrated by the non-F1 donor CU 802 toward the parent IAB node 850 using the backhaul link 8050 between the IAB node 850 and the IAB node 870. For this purpose, the non-F1 donor CU 802 applies the intra-CU topology adaptation procedure described in TS38.401 V17.2.0 Chapter 8.2.3.1 (or Chapter 8.17.3.2) to perform continuous MT migration of the IAB node 870. Nevertheless, the IAB node 870 remains connected to the IAB donor CU 801 while maintaining its F1 connection, and the RRC connection has been switched to the donor CU 802.

[0167] After being notified to use donor DU 506 instead of donor DU 505 to route F1 traffic related to IAB node 870, donor CU 801 may request migration of traffic related to IAB node 870 to IAB topology 8002. In this case, donor CU 801 initiates the IAB transport migration management procedure specified in TS38.423 V17.2.0 Chapter 8.5.2.

[0168] Moving further, this time toward the IAB topology 8003 managed by the IAB donor CU 803, the IAB node 870 may reach a position where the backhaul link 5060 with the IAB node 860 is of higher quality than the backhaul link 5050 with the IAB node 850. Therefore, the donor CU 802 may apply the inter-CU topology adaptation procedure described in TS38.401 V17.2.0 Chapter 8.17.3.1 or 8.17.3.2. After this successive MT migration, the IAB node 870 remains connected to the donor CU 801 through an F1 connection, but its RRC connection is now switched to the new donor CU 803. However, the donor CU 801 needs to be notified of the new non-F1 donor CU (donor CU 803) of the IAB node 870 and that traffic offloading (control traffic and user traffic) should be switched via the donor DU 807 instead of the donor DU 806.

[0169] In all the above-mentioned MT migration cases, the UE 880 is still connected to the donor CU 801 via the DU part 872 of the mobile IAB node 870. If the IAB node 870 has child IAB nodes, these child IAB nodes also belong to the IAB topology 8001, It remains fully managed by the donor CU801 (through F1 and RRC connections).

[0170] As an example of a method according to one or more embodiments of the present invention, when a MT of an IAB node successively migrates from a first IAB topology (source topology) managed by a non-F1 terminated donor CU or an RRC terminated donor CU to a second IAB topology (target topology) managed by another non-F1 terminated donor CU or an RRC terminated donor CU, the F1 terminated donor CU is notified and also notified of information regarding at least one new routing path to be used for routing data (e.g., F1 traffic, user traffic, control traffic) related to the migrated IAB node in the target IAB topology (the target IAB topology is used, for example, to route data to and from the migrated IAB node or an F1 terminated donor CU in an IAB topology controlled by a non-F1 terminated donor CU). Note that although the method / apparatus shown below are primarily described with respect to a mobile IAB node, the present invention is not limited to mobile IAB nodes. The method according to one or more embodiments of the present invention may also be applicable to fixed IAB nodes located in the vicinity of, for example, neighboring IAB topologies.

[0171] 9 is a simplified diagram 900 illustrating exemplary message flows according to one or more embodiments of the present invention, illustrating an example of performing continuous MT migration (and control data path setup) of an IAB node to a target IAB topology, including new MT migrations between different parent IAB nodes managed by different donor CUs than the donor CU serving the IAB node's DU.

[0172] This figure shows IAB node 901, which is composed of a Mobile Termination (MT) 903 (IAB-MT) and a Distributed Unit (DU) 902 (IAB-DU), similar to mobile IAB node 870 or IAB node 123 of Figure 1. The figure also shows a source non-F1 terminated donor CU (or non-F1 donor CU) 905 that terminates an RRC connection with IAB node 901 via IAB-MT 903, an F1 terminated donor CU (or F1 donor CU) 904 that terminates an F1 connection with IAB node 901 via IAB-DU 902, and a target non-F1 donor CU 906 that becomes the new non-F1 terminated donor CU for IAB node 901 during the described procedure. 8, the F1 terminating donor CU 904 corresponds to the donor CU 801, the MT 871 of the IAB node 870 has been migrated to the IAB topology 8002 (managed by the donor CU 802), and the source non-F1 donor CU 905 corresponds to the donor CU 802. Furthermore, as the IAB node moves toward the IAB topology 8003, the IAB node 860 is identified as the target IAB node, and the target non-F1 donor CU 906 corresponds to the donor CU 803.

[0173] At the start of flow 900, it is assumed that the control path (F1-C) and user path (F1-U) established by F1 donor CU 904 to reach IAB node 901 use one or more backhaul paths via donor DUs (not shown in FIG. 9 ) in the IAB topology managed by source non-F1 donor CU 905. For example, in reference to FIG. 8 , an example of such a backhaul path is a path including donor DU 806 and IAB nodes 840 and 850.

[0174] In the first part of the flowchart, a procedure 910 is used to migrate an IAB-MT 903 from a source non-F1 donor CU 905 to a target non-F1 donor CU 906 and set up a path for new RRC protocol messages.

[0175] Specifically, the source non-F1 donor CU 905 receives a measurement report 911 from the IAB node 901 and initiates successive MT migration, as described above with respect to Figure 8, to migrate the MT 871 (903) of the IAB node 870 (901) from the parent IAB node 850 in the IAB topology 8002 to a new parent IAB node 860 in a different IAB topology 8003. Here, the inter-CU topology adaptation procedure is used as an example to further explain the flow 900 of Figure 9.

[0176] The measurement report 911 is delivered to the source non-F1 donor CU 905 by the source parent IAB node (e.g., parent IAB node 850 in FIG. 8) through an F1 message "UL RRC MESSAGE TRANSFER" (specified in TS38.423) containing an embedded RRC message, transmitted from the DU unit of the IAB node 901. The measurement report is a measurement result periodically performed by the IAB-MT 903 on signals (e.g., signal synchronization block (SSB)) received from the serving cell and one or more target cells. The target cells may be cells neighboring the serving cell (current serving cell). When the IAB-MT 903 finds at least one SSB that meets a predefined criterion (e.g., received power exceeding a predefined threshold), a measurement report is generated and transmitted to provide radio link quality information of different cells in the vicinity of the IAB node 901. The identification information of each cell is included in the measurement report to enable the non-F1 donor CU 905 to identify the target CU associated with the cell. In fact, the identity of the donor CU can be deduced from the Physical Cell Identifier (PCI) broadcast in each cell managed by this donor CU in a synchronization signal and / or from the New Radio Cell Group Identifier (NCGI) also broadcast in each cell managed by this donor CU in a System Information Block (SIB) message. The PCI and / or NCGI can be reported by the IAB node 901 in a measurement report 911.

[0177] Based on the received measurement report, the source non-F1 terminating donor CU 905 can detect that the IAB node 901 is receiving a radio signal with better quality in the target cell of the target parent IAB node than in the source serving cell. For example, when the target parent IAB node (e.g., IAB node 860 in FIG. 8) belongs to a different IAB topology from the source parent IAB node (e.g., parent IAB node 850), the source non-F1 terminating donor CU 905 can decide to apply an inter-CU topology adaptation procedure to the IAB node 901. The target parent IAB node in the target IAB topology includes a new donor DU for routing packets (e.g., donor DU 807 instead of donor DU 806 in FIG. 8). The target parent IAB node may be an IAB node or an IAB donor DU.

[0178] The migration of the IAB-MT 903 is triggered by the handover preparation procedure 912 described in TS38.423 V17.2.0 Section 8.2.1. In this procedure, the source non-F1 terminating donor CU 905 sends a handover request message to the target non-F1 donor CU 906, including the necessary information related to the IAB-MT 903, to enable the handover. For example, this message includes the identifier of the target cell to which the IAB node 901 will switch and, therefore, the identifier of the target parent IAB node that controls the target cell. After requesting UE context setup for the IAB node from the target parent IAB node 901, the target non-F1 donor CU 906 performs admission control and provides new RRC configuration information to the source non-F1 donor CU 905 using a HANDOVER REQUEST ACKNOWLEDGE message. The individual steps of the handover preparation procedure are not shown in FIG. 9; for simplicity, the IAB-MT handover preparation is shown as box 912.

[0179] The source non-F1 donor CU 905 can then relay the RRC configuration information to the IAB-MT 903 via an RRC reconfiguration message 913. In practice, the message 913 is first embedded in an F1 message UE context modification request as specified in TS38.473 and sent from the source non-F1 donor CU 905 to the source parent IAB node of the IAB node 901. This source parent IAB node then sends the RRC reconfiguration message 913 to the IAB-MT 903. In particular, the RRC reconfiguration message 913 includes a transport network layer (TNL) address (e.g., an IP address) that identifies the target donor DU for packet routing (e.g., data routing). In the example of Figure 8, the address of the donor DU 807 is used instead of the address of the donor DU 806.

[0180] After the IAB node 901 performs the random access procedure with the target parent IAB node (e.g., IAB node 860 in FIG. 8 ), the IAB node 901 sends an RRC reconfiguration complete message 914 toward the target non-F1 donor CU 906 (via an F1 message UL RRC message transfer that embeds the target parent IAB node and RRC reconfiguration complete information).

[0181] The procedure 910 ends with an Xn message UE Context Release 915 as specified in TS38.423 sent by the target non-F1 donor CU 906 towards the source non-F1 donor CU 905, however, the identifiers at the F1 donor CU 904 in the IAB node 901 and the source non-F1 donor CU 905 are retained because the F1 path for the IAB node 901 can still be used through the IAB topology controlled by the source non-F1 donor CU 905.

[0182] The next part (messages 921 and 922) relates to the procedure 920 of updating the F1 paths (F1-C and F1-U) between the IAB node 901 and the F1 donor CU 904 via the target donor DU in the IAB topology managed by the target non-F1 donor CU 906.

[0183] The target non-F1 donor CU 906 configures a backhaul RLC channel and BAP layer routing entries on the target path between the target parent IAB node (e.g., IAB node 860 in FIG. 8) and the target IAB donor DU (e.g., IAB donor DU 807 in FIG. 8). The target non-F1 donor CU 906 may also establish additional backhaul RLC channel and BAP settings to the migrated IAB-MT via RRC message 921.

[0184] Subsequently, the DU portion (IAB-DU 902) of the IAB node 901 can send a DU Configuration message 922 to the F1 donor CU 904. This message corresponds to the F1 message "gNB-DU CONFIGURATION UPDATE" specified in TS38.473 V17.2.0, Section 9.2.1.7. This message includes the identifier of the target non-F1 donor CU 906 and the identification information of the target donor DU for F1-C and F1-U traffic. For the target non-F1 donor CU 906 that manages the target cell, the IAB node 901 reports the PCI and / or NCGI associated with that cell to the F1 donor CU 904, allowing the F1 donor CU 904 to identify the target non-F1 donor CU 906. The address information (e.g., IP address) of the target donor DU is already known to the IAB node 901 from receiving message 913. The destination of message 922 is the F1 donor CU 904, and if this IP packet reaches a target donor DU in the IAB topology managed by the target non-F1 donor CU 906, it is routed to the F1 donor CU 904 via the wired backhaul (808 in FIG. 8). By receiving the identification information of the target donor DU, the F1 donor CU 904 updates its configuration (e.g., updates the routing path associated with the IAB node based on the received information) so that it can deliver the F1 packet to the IAB node 901 via the target donor DU (e.g., IAB donor DU 807) in the IAB topology 8003. This updates the path of the F1 control data (F1-C).

[0185] As another option for informing the F1 donor CU 904 of the identifier of the target non-F1 donor CU, the source non-F1 donor CU 905 initiates a procedure using messages "Configuration Update" 923 and "Configuration Update Response" 924. Message 923 is sent from the source non-F1 donor CU 905 to the F1 donor CU 904 and includes the identifier of the target non-F1 donor CU 906. Message 924 is a response (acknowledgment) from the F1 donor CU 904. The identifier of the donor CU is specified by the "Global NG-RAN Node ID" information element defined in TS38.423 V17.2.0 Section 9.2.2.3.

[0186] As an example, message 923 is an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message, and message 924 is an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. These messages are used in the IAB transport migration modification procedure specified in TS38.423 V17.2.0 (Xn Protocol) Sections 9.1.4.4 and 9.1.4.5. Using this procedure, the source non-F1 donor CU 905 can also notify the F1 donor CU 904 to release traffic that was offloaded through the IAB topology managed by the source non-F1 donor CU 905.

[0187] According to another example, message 923 may be an NG-RAN NODE CONFIGURATION UPDATE message and message 924 may be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE, both of which are messages specified in TS38.423 V17.2.0 (Xn Protocol) sections 9.1.3.4 and 9.1.3.5 and used in the NG-RAN node configuration update procedure.

[0188] To enable the F1 donor CU 904 to identify the migrated IAB node 901 by the received message, i.e., to indicate that the IAB node has been migrated from the IAB topology managed by the source non-F1 donor CU 905 to the target IAB topology managed by the target non-F1 donor CU 906 and that there are one or more new routing paths after the migration, the transmitted message includes an identifier associated with the migrated IAB node. For example, in the above-mentioned procedures (NG-RAN Node Configuration Update, IAB Transport Migration Modification), information elements such as "F1 Terminated IAB-Donor UE XnAP ID" and "Non-F1 Terminated IAB-Donor UE XnAP ID" or "RRC Terminated IAB-Donor UE XnAP ID" are included in the message, and the BAP address assigned to the IAB node (e.g., assigned by the source non-F1 / RRC donor CU or the target non-F1 / RRC donor CU) is also included. These identifiers are defined when the IAB node 901 first performs MT migration to an IAB topology controlled by a non-F1 donor CU (between the F1 donor CU 904 and the source non-F1 donor CU 905), and are carried over to subsequent MT migrations to a new IAB topology controlled by the target non-F1 donor CU 906. The target non-F1 donor CU 906 allocates a new identifier for the IAB node 901 and shares it with the source non-F1 donor CU 905 using the "Target NG-RAN Node UE XnAP ID" information element in the HANDOVER REQUEST ACKNOWLEDGE message.

[0189] 10 is a schematic and simplified diagram 1000 according to an embodiment of the present invention illustrating the setup of user data paths in a continuous MT migration of an IAB node to a target IAB topology. FIG. 10 illustrates the next steps following steps 910 and 920 of FIG. 9.

[0190] The figure shows an example of a mobile IAB node, IAB node 1001 (similar to IAB node 870 in FIG. 8 and IAB node 123 in FIG. 1), which is comprised of a mobile termination (MT) 1003 (IAB-MT) and a distribution unit (DU) 1002 (IAB-DU). The figure also shows a source non-F1 donor CU (non-F1 donor CU) 1005 that terminates the RRC connection via IAB-MT 1003, an F1 donor CU (F1 donor CU) 1004 that terminates the F1 connection via IAB-DU 1002, and a target non-F1 donor CU 1006 that becomes the new non-F1 terminating donor CU during the procedure. 8, the F1 terminating donor CU 1004 of IAB node 870 is donor CU 801, and the MT 871 of IAB node 870 is migrated to IAB topology 8002 managed by donor CU 802, so the source non-F1 donor CU 1005 is donor CU 802. As the IAB nodes move towards IAB topology 8003, IAB node 860 is identified as the target IAB node to which the MT of IAB node 870 may be migrated, so the target non-F1 terminating donor CU 1006 is donor CU 803.

[0191] At the start of flow 1000, the control path (F1-C) and user path (F1-U) established by F1 donor CU 1004 to reach IAB node 1001 use one or more backhaul paths through donor DUs (omitted in FIG. 10) in the IAB topology managed by source non-F1 donor CU 1005. For example, based on FIG. 8, the backhaul paths may include donor DU 806 and IAB nodes 840 and 850.

[0192] The continuous MT migration of the mobile IAB node 1001 to the target IAB topology is performed by step 1010, which corresponds to step 910 in Figure 9. Thereafter, a control data path in the target topology is set up by step 1020, which corresponds to step 920 in Figure 9.

[0193] To complete the continuous MT migration, the F1 user data (F1-U) path needs to be updated. The F1 donor CU 1004 initiates the "IAB Transport Migration Management procedure" specified in TS38.423 V17.2.0 Section 8.5.2, which exchanges protocol messages directly between the F1 donor CU 1004 and the target non-F1 donor CU 1006 (without involving the source non-F1 donor CU 1005). The F1 donor CU 1004 sends a message 1031 ("IAB TRANSPORT MIGRATION MODIFICATION REQUEST" specified in TS38.423 V17.2.0 [Xn Protocol] Section 9.1.4.2) to the target non-F1 donor CU 1006, with the purpose of configuring user traffic for the IAB node 1001. In response to this request, the target non-F1 donor CU 1006 can configure or modify BH RLC channels and BAP layer routing entries on the target path between the IAB node 1001 and the target IAB donor DU. In particular, the target non-F1 donor CU 1006 sends message 1032 to the IAB node 1001 to provide the BAP configuration information. Message 1032 can be an RRC reconfiguration message as specified in TS 38.331. The target non-F1 donor CU 1006 then sends message 1033 ("IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE" as specified in TS38.423 V17.2.0 [Xn Protocol] section 9.1.4.3) to the F1 donor CU 1004, providing new configuration parameters (e.g., BH RLC channel) that the IAB node 1001 should use to transmit user data packets within the IAB topology managed by the target non-F1 donor CU 1006. These configuration parameters are provided from the F1 donor CU 1004 to the IAB node 1001 through an F1 message such as "BAP MAPPING CONFIGURATION" as specified in TS38.423 V17.2.0 section 9.2.9.1.

[0194] Finally, if the source non-F1 donor CU 1005 has not used the IAB transport migration modification procedure (i.e., messages 923 and 924 in FIG. 9 ) to request the release of traffic offloaded by the F1 donor CU 1004, the F1 donor CU 1004 initiates an “IAB transport migration management procedure” using I messages 1035 and 1036. By using this procedure, the source non-F1 donor CU 1005 may also notify the F1 donor CU 1004 to release traffic offloaded through the IAB topology controlled by the source non-F1 donor CU 1005. The F1 donor CU 1004 sends a message 1035 corresponding to an IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.2 to the source non-F1 donor CU 1005 for the purpose of releasing traffic to / from the IAB node 1001 that is offloaded in the IAB topology controlled by the target non-F1 donor CU 1006. The source non-F1 donor CU 1005 then responds to the F1 donor CU 1004 with a message 1036 corresponding to an IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE specified in TS 38.423 V17.2.0 (Xn Protocol) section 9.1.4.3.

[0195] In the IAB transport migration management procedure, the identifier of the IAB node 1001 is present in all messages having one or more of the information elements assigned to the IAB node, F1-terminated IAB-donor UE XnAP ID and non-F1-terminated IAB-donor UE XnAP ID or RRC-terminated IAB-donor UE XnAP ID and BAP address, defined at the first MT migration of the IAB node 1001 to a first non-F1 donor CU-controlled IAB topology (at the F1 donor CU 1004 and source non-F1 donor CU 1005) or at the target non-F1 donor CU 1006 during a successive MT migration of the IAB node 1001 to a second non-F1 donor CU-controlled IAB topology (target IAB topology) (step 1010).

[0196] FIG. 11 is a schematic diagram 1100 illustrating some example message flows according to an embodiment of the present invention for continuous MT migration of an IAB node towards a target IAB topology after radio link failure (RLF) recovery of the IAB node.

[0197] 11 illustrates IAB node 1101, which is a mobile IAB node (e.g., similar to IAB node 870 of FIG. 8 and / or IAB node 123 of FIG. 1). IAB node 1101 is comprised of a mobile termination (MT) 1103 (identified as IAB-MT) and a distributed unit (DU) 1102 (identified as IAB-DU). Also shown in the figure are a source non-F1 donor CU (or non-F1 donor CU) 1105, which terminates its RRC connection to IAB node 1101 via IAB-MT 1103, an F1 donor CU (or F1 donor CU) 1104, which terminates its F1 connection via IAB-DU 1102, and a target non-F1 donor CU 1106, which becomes the new non-F1 terminating donor CU for IAB node 1101 during the procedure. 8, the F1 terminating donor CU 1104 of the IAB node is donor CU 801, and the MT 871 of the IAB node 870 is migrated to the IAB topology 8002 managed by donor CU 802, so the source non-F1 donor CU 1105 is donor CU 802. Then, as the IAB node moves to the IAB topology 8003, the IAB node 860 is identified as the target IAB node to which the MT of the IAB node 870 can migrate, and the target non-F1 terminating donor CU 1106 becomes donor CU 803.

[0198] At the start of flow 1100, it is assumed that the control path (F1-C) and user path (F1-U) set up by F1 donor CU 1104 to reach IAB node 1101 use one or more backhaul paths in the IAB topology managed by source non-F1 donor CU 1105 via donor DUs not shown in Figure 11. For example, referring to Figure 8, such backhaul paths may include donor DU 806 and IAB nodes 840 and 850.

[0199] The first part of the flowchart shows a procedure 1110 in which the IAB-MT 1103 is migrated to an IAB topology managed by the target non-F1 donor CU 1106 after RLF recovery (e.g., the IAB-MT 1103 is migrated to an IAB node 860 in the IAB topology 8003). This procedure includes setting up a new path for RRC protocol messages.

[0200] The IAB-MT 1103 of the IAB node 1101 periodically performs measurements on signals received from the serving cell and one or more target cells. For example, the measurements may be performed on signal synchronization blocks (SSBs) transmitted by the serving cell and the target cell. The target cell may be a neighbor cell of the serving cell (i.e., the current serving cell). If the IAB node 1101 is connected by a backhaul link via the IAB node 850, the serving cell or source cell is the cell served by the IAB node 850.

[0201] RLF may be declared for a link between the IAB node 1101 and its source parent IAB node (e.g., link 8050 between IAB node 870 and IAB node 850 in FIG. 8) when an SSB signal in the serving cell meets a predetermined criterion (e.g., received power below a predetermined threshold) and persists for a predetermined time period. The IAB node 1101 may also determine that it has detected an SSB signal that meets a predetermined criterion (e.g., received power above a predetermined threshold) and is sufficient for a new connection attempt in the target cell. In this case, the mobile IAB node 1101 triggers the inter-CU backhaul RLF recovery procedure described in TS38.401 V17.2.0 section 8.17.4. This procedure involves the IAB node 1101 performing a random access procedure to acquire uplink resources and then transmitting an RRC reconfiguration request message 1111 in the target cell. This RRC message is specified in accordance with TS38.331 and is received by the target parent IAB node (for example, IAB node 860 in FIG. 8), which relays the message to the target non-F1 donor CU 1106 (for example, donor CU 807 in FIG. 8) via the F1 message "INITIAL UL RRC MESSAGE TRANSFER" (specified in TS38.401 V17.2.0 section 9.2.3.1).

[0202] After receiving this RRC reconfiguration request 1111, if it contains information for identifying the source non-F1 donor CU 1105 of the IAB node 1101 (e.g., the physical cell ID of the cell to which the IAB node 1101 was previously connected), the target non-F1 donor CU 1106 initiates a procedure 1112 to retrieve the UE context of the IAB node 1101 from the source non-F1 donor CU 1105 (donor CU 806 in FIG. 8). In this procedure, the target non-F1 donor CU 1106 sends an Xn protocol message "RETRIEVE UE CONTEXT REQUEST" as specified in TS38.423 V17.2.0 section 9.1.1.8 to the source non-F1 donor CU 1105. In response, the source non-F1 donor CU 1105 responds with a RETRIEVE UE CONTEXT RESPONSE message as specified in TS38.423 V17.2.0, section 9.1.1.9. After deciding to accept the re-establishment request from the IAB node 1101, the target non-F1 donor CU 1106 sends an RRC reconfiguration message 1113 to the IAB node 1101. This message is embedded in an F1 message "DL RRC MESSAGE TRANSFER" as specified in TS38.423 V17.2.0, section 9.2.3.2, and sent to the target parent IAB node (e.g., IAB node 860 in FIG. 8). Subsequently, the IAB-MT 1103 of the IAB node 1101 sends an RRC reconfiguration complete message 1114 to the target non-F1 donor CU 1106 (sent via the target parent IAB node by an F1 message UL RRC MESSAGE TRANSFER containing RRC reconfiguration complete information).

[0203] After requesting UE context establishment for the IAB node 1101 from the target parent IAB node, the target non-F1 donor CU 1106 sends an Xn message "UE CONTEXT RELEASE" 1115, as specified in TS 38.423, to the source non-F1 donor CU 1105, thereby informing the source non-F1 donor CU 1105 of the new non-F1 donor CU for the IAB node 1101. However, because the F1 path is still considered functional by the F1 donor CU 1104, the identifier for the IAB node 1101 remains retained in the F1 donor CU 1104 and the source non-F1 donor CU 1105 and continues to be retained by the source non-F1 donor CU 1105.

[0204] Additionally, the target non-F1 donor CU 1106 sends an RRC reconfiguration message 1117 to the IAB-MT 1103. This message is embedded in the F1 message "DL RRC MESSAGE TRANSFER" sent to the target parent IAB node. In particular, the RRC reconfiguration message 1117 includes a transport network layer (TNL) address (IP address) that identifies the target donor DU for packet routing (e.g., data routing). In the example of FIG. 8, the address of the donor DU 807 replaces the address of the donor DU 806. In response, the IAB-MT 1103 of the IAB node 1101 sends an RRC reconfiguration complete message 1118 to the target non-F1 donor CU 1106 (sent via the target parent IAB node in an F1 message "UL RRC MESSAGE TRANSFER" containing RRC reconfiguration complete information).

[0205] To complete the continuous MT migration of the IAB node 1101, a control data path is established within the IAB topology managed by the target non-F1 donor CU 1106 in step 1120, which corresponds to step 920 in Figure 9. In this step, the IAB node 1101 or the source non-F1 donor CU 1105 may notify the F1 donor CU 1104 of the identifier of the target non-F1 donor CU 1106 and the address of the target donor DU. A user data path is also established in step 1130, which corresponds to step 1030 in Figure 10.

[0206] 12a-12c are flowcharts illustrating exemplary methods executed in different network nodes according to an embodiment of the present invention. These exemplary methods are used in a process of successively migrating an MT of an IAB node in a wireless communication system (e.g., the communication system shown in FIGS. 1 and 8) from a second IAB topology managed by a source IAB donor CU to a third IAB topology managed by a target IAB donor CU. The illustrated methods in different network nodes are used in a process of migrating an MT of an IAB node from a second IAB topology managed by a second IAB donor central unit to a third IAB topology managed by a third IAB donor CU (e.g., a target IAB donor CU). In this migration process, the IAB node is managed (or controlled or served) by a first IAB donor CU in a first IAB topology (e.g., an F1 terminating donor CU of the IAB node with which the IAB node maintains an F1 connection). The second and third IAB donor CUs are non-F1 terminated donor CUs or RRC terminated donor CUs of the IAB node. The first IAB donor CU or F1 terminated donor CU receives (e.g., from the IAB node) address information including one or more addresses (e.g., IP addresses, TNL addresses) associated with the target IAB donor DU of the third IAB topology, via which or through which data associated with the IAB node (e.g., F1 traffic, user traffic, control traffic) is routed in the third IAB topology (e.g., data to be routed to / from the IAB node in the third IAB topology via the target IAB donor DU). The first IAB donor CU or F1 terminal donor CU also receives identification information (such as a PCI or NCGI) for identifying a third IAB donor CU (e.g., a target non-F1 terminal donor CU) from an IAB node (e.g., described in more detail below with reference to FIG. 12a) or a second IAB donor CU (e.g., a source non-F1 terminal donor CU described in more detail below with reference to FIG. 12b).In one example, the first IAB donor CU or F1-terminated donor CU may also receive identification information from the IAB node or a second IAB donor CU (e.g., a source non-F1-terminated donor CU) including at least one identifier of the IAB node. Such identifiers may include identifiers known to the IAB node's F1-terminated donor CU and non-F1-terminated donor CU. For example, the message may include one or more of the information elements F1-terminated IAB donor UE XnAP ID and non-F1-terminated IAB donor UE XnAP ID or RRC-terminated IAB donor UE XnAP ID and BAP address assigned to the IAB node.

[0207] While the following methods / apparatus are described primarily with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. Methods according to one or more embodiments of the present invention may be applied, for example, to fixed IAB nodes that are at the edge of one IAB topology and are near one or more IAB nodes in an adjacent IAB topology.

[0208] Thus, information (e.g., address information, e.g., address of the target donor DU to which the IAB node is already migrated, and / or identification information (e.g., PCI or NCGI) for identifying the third IAB donor CU) transmitted by the second IAB donor CU (non-F1 terminating donor CU) or IAB node to the first IAB donor CU (F1 terminating donor CU) of the IAB node can inform the F1 terminating donor CU about the migration of the IAB node's MT between two different topologies. For example, from the second IAB topology managed by the second IAB donor central unit (CU) (e.g., source IAB donor CU) to the third IAB topology managed by the third IAB donor CU (e.g., target IAB donor CU), the F1 terminating donor CU can be informed about at least one new routing path to be used for routing data (e.g., user traffic and control traffic) for the migrated IAB node in the third IAB topology controlled by the target non-F1 terminating donor CU. The F1 terminating donor CU may then update configuration information for the IAB node based on the received information to update the routing paths associated with or for the IAB node (e.g., F1-C and F1-U routing paths) to new routing paths for routing data to / from the IAB node via the target donor DU.

[0209] 12a is a flowchart illustrating an exemplary method 1200 performed in an IAB node (e.g., a mobile IAB node or mIAB node) for use in (or for use in part of) a migration process in which an MT of the IAB node is migrated (e.g., continuously migrated) from a second IAB topology to a third topology, both topologies being different from the first IAB topology to which the IAB node belongs. The method 1200 is for managing continuous MT migration in an IAB node toward a target IAB topology that is different from the IAB topology controlled by its F1-terminated donor CU and its source non-F1-terminated donor CU, in accordance with one or more embodiments of the present invention. 8, the IAB node performing method 1200 may be a mobile IAB node 870 belonging to an IAB topology 8001 controlled by an IAB donor CU 801 (e.g., an F1-terminated donor CU of the mobile IAB node 870 with which the mobile IAB node 870 maintains an F1 connection). The migration process may include movement of the MT 871 of the mIAB node 870 from an IAB donor DU 806 in an IAB topology 8002 controlled by an IAB donor CU 802 (e.g., a non-F1-terminated donor CU of the mobile IAB node 870 with which the mobile IAB node 870 has an RRC connection and which is operating as a source non-F1-terminated donor CU) to an IAB donor DU 807 in an IAB topology 8003 controlled by an IAB donor CU 803 (e.g., a non-F1-terminated donor CU of the mobile IAB node 870 which is operating as a target non-F1-terminated donor CU). The migration includes switching the routing path for the mobile IAB node 870 from a routing path that includes the parent IAB node 850, the IAB node 840, and the IAB donor DU 806 to a routing path that includes the parent IAB node 860 and the IAB donor DU 807. The method 1200 shown in and described with respect to Figure 12a may be performed by software and / or hardware elements. The IAB node may be implemented in a communications device 400 as shown in and described with reference to FIG. 4, and the method as shown in and described with reference to FIG. 12a is executed by one or more processing units, such as a central processing unit 411.

[0210] In step 1201, an IAB node, such as IAB node 870, receives address information from a target non-F1 terminated donor CU, such as donor CU 803, including one or more addresses associated with a target IAB donor DU, such as donor DU 807, through which data associated with the IAB node is routed in the third IAB topology 8003. Thus, the IAB node 807 can receive the address of the target donor DU, such as donor DU 807, in the IAB topology controlled by the target non-F1 terminated donor CU. For example, the IAB node 870 may receive the address of the target donor DU in a message such as an RRC reconfiguration message 913 or 1117 as described above.

[0211] In step 1202, an IAB node (e.g., IAB node 870) transmits an identifier of the target non-F1 terminating donor CU to an F1 terminating donor CU (e.g., donor CU 801) that it manages. For example, the IAB node 870 transmits identification information for identifying the target non-F1 terminating donor CU 803. This identification information includes the PCI (Physical Cell ID) or NCGI (New Radio Cell Group Identifier) ​​of the target cell, etc., so that the F1 terminating donor CU 801 can identify the target non-F1 terminating donor CU 803.

[0212] In step 1203, the IAB node transmits the address (e.g., IP address) of the received target donor DU to the F1 terminating donor CU. For example, the IAB node 870 may transmit address information including one or more addresses of the target donor DU 807 in a message such as the DU message 922 described above. Identification information identifying the target non-F1 terminating donor CU 803 may also be transmitted in the same message as the address information (e.g., message 922) or in a separate message.

[0213] As an example, the IAB node 870 (or 570) may also send its own identifier information known to the two IAB donor CUs (F1 terminating donor CU 801 and source non-F1 terminating donor CU 802). For example, the message may include "F1 terminating IAB donor UE XnAP ID", "non-F1 terminating IAB donor UE XnAP ID", "RRC terminating IAB donor UE XnAP ID", and / or a BAP address assigned to the IAB node.

[0214] In an exemplary method (not explicitly shown in the figures) for use in a migration process in which an MT of an IAB node is migrated from a second IAB topology managed by a second IAB donor CU (source non-F1 / RRC terminated donor CU) to a third IAB topology managed by a third IAB donor CU (target non-F1 / RRC terminated donor CU), the IAB node is managed by a first IAB donor CU (F1 terminated donor CU) that manages the first IAB topology, and the IAB node transmits identification information for identifying the target non-F1 / RRC terminated donor CU to its F1 terminated donor CU that controls another IAB topology, such as donor CU 801. For example, IAB node 870 may transmit identification information for identifying the target non-F1 terminated donor CU 803. The identification information may include an identifier, such as the PCI or NCGI, of the target cell by which the F1 terminated donor CU 801 can identify the target non-F1 terminated donor CU 803. The IAB node 870 / 570 may further transmit identification information for identifying the mobile IAB node, such as an identifier associated with the mobile IAB node (e.g., assigned or known by the source non-F1 / RRC terminated donor CU 802 upon migration to a topology controlled by the source non-F1 / RRC terminated donor CU 802, or assigned or known by the target non-F1 / RRC terminated donor CU 803 upon migration to a topology controlled by the source non-F1 / RRC terminated donor CU 803). For example, the message may include one or more of the information elements F1-terminated IAB-donor UE XnAP ID and non-F1-terminated IAB-donor UE XnAP ID or RRC-terminated IAB-donor UE XnAP ID (assigned by the RRC terminated donor CU) and a BAP address assigned to the IAB node (e.g., a BAP address assigned to the IAB node by the source and / or target non-F1 / RRC terminated donor CU).Thus, identification information (e.g., address information, e.g., address of the third or target donor DU to which the IAB node is already migrated, and / or identification information (such as PCI or NCGI) for identifying the third IAB donor CU) sent by the second IAB donor CU (non-F1 terminating donor CU or RRC terminating donor CU) or IAB node to the first IAB donor CU (F1 terminating donor CU) of the IAB node allows the F1 terminating donor CU to be informed of the movement of the MT of the IAB node between two different topologies, and then, based on the received information, can update the routing path for the IAB node 870 to a new routing path for routing data to / from the IAB node via the topology managed by the target non-F1 / RRC terminating donor CU.

[0215] 12b is a flowchart illustrating an example method 1210 performed in a second IAB donor CU (e.g., a source non-F1 terminated donor CU of the IAB node) for use in a migration process (or for use in part of a migration process) for an MT of an IAB node, in accordance with one or more embodiments of the present invention. The method 1210 is for managing, at the source non-F1 terminated donor CU of the IAB node, continuous MT migration of the IAB node to a target IAB topology that differs from the IAB topology controlled by the F1 terminated donor CU of the IAB node. For example, with reference to the IAB communication system shown in and described with respect to FIG. 8, the second IAB donor CU performing method 1210 may be the IAB donor CU 802 (e.g., a non-F1 terminated donor CU of the IAB node 870 with which the IAB node 870 has an RRC connection). The IAB node may be a mobile IAB node 870 belonging to an IAB topology 8001 controlled by an IAB donor CU 801 (e.g., an F1-terminating donor CU of the mobile IAB node 870 to which the mobile IAB node 870 maintains an F1 connection). The migration process may include migration of an MT 871 of the mIAB node 870 from an IAB donor DU 806 in the IAB topology 8002 controlled by an IAB donor CU 802 acting as a source non-F1-terminating donor CU to an IAB donor DU 807 in the IAB topology 8003 controlled by an IAB donor CU 803 acting as a target non-F1-terminating donor CU. The method 1210 as shown in and described with reference to FIG. 12b may be performed by software and / or hardware elements. The non-F1 terminated IAB donor CU may be implemented in a communication device 400 as shown in and described with reference to FIG. 4, and the method as shown in and described with reference to FIG. 12b is executed by one or more processing units, such as a central processing unit 411.

[0216] In step 1211, a source non-F1 terminating donor CU, such as donor CU 802, for an IAB node, such as IAB node 870, detects that the MT portion of the IAB node has migrated to a target non-F1 terminating donor CU, such as donor CU 803. For example, the source non-F1 terminating donor CU 802 determines that the MT 871 of the mobile IAB node 870 should be migrated to the target IAB donor DU 807, where data associated with the IAB node is routed within the IAB topology 8003. This information is either determined by the source non-F1 terminating donor CU 802 itself based on receiving a measurement report from the IAB node 870 (e.g., measurement report 911 described above), or is obtained by receiving a UE context release message related to the IAB node 870 from the target non-F1 terminating donor CU 803 (e.g., messages 915, 1115 described above).

[0217] In step 1212, the source non-F1 termination donor CU 802 transmits an identifier of the target non-F1 termination donor CU 803, along with identifiers of the IAB nodes known by the two donor CUs (the F1 termination donor CU 801 and the source non-F1 termination donor CU 802), to the F1 termination donor CU 801 of an IAB node that controls another IAB topology 8001. For example, the source non-F1 termination donor CU 802 transmits identification information that identifies the target non-F1 termination donor CU 803. The identification information may include an identifier such as the PCI or NCGI of the target cell by which the F1 termination donor CU 801 can identify the target non-F1 termination donor CU 803.

[0218] 12c is a flowchart illustrating an example method 1220 performed in a first donor CU (e.g., an F1-terminated donor CU of an IAB node) for use in a migration process (or for use in part of a migration process) for an MT of an IAB node, in accordance with one or more embodiments of the present invention. The method 1220 is for managing, in the F1-terminated donor CU of the IAB node, continuous MT migration of the IAB node to a target IAB topology that differs from the IAB topology controlled by the source non-F1-terminated donor CU of the IAB node. For example, with reference to the IAB communication system shown in and described with respect to FIG. 8, the first IAB donor CU performing method 1220 may be the IAB donor CU 801 (e.g., the F1-terminated donor CU of the IAB node 870 to which the IAB node 870 maintains an F1 connection). The IAB node may be a mobile IAB node 870 that belongs to an IAB topology 8001 controlled by the IAB donor CU 801. The row process may include migration of an MT 871 of the mIAB node 870 from an IAB donor DU 806 in an IAB topology 8002 controlled by an IAB donor CU 802 acting as a source non-F1 terminating donor CU to an IAB donor DU 807 in an IAB topology 8003 controlled by an IAB donor CU 803 acting as a target non-F1 terminating donor CU. The method 1220 as shown in and described with respect to FIG. 12c may be performed by software and / or hardware elements. The F1 terminating IAB donor CU may be implemented in a communications device 400 as shown in and described with reference to FIG. 4, and the method as shown in and described with reference to FIG. 12c is performed by one or more processing units, such as a central processing unit 411.

[0219] In step 1221, the F1 termination donor CU, like the IAB donor CU 801, receives identification information identifying the target non-F1 termination donor CU 803. The identification information may include an identifier, such as the PCI or NCGI, of the target cell to which the IAB node 870 will move and through which the F1 termination donor CU 801 can identify the target non-F1 termination donor CU 803. For example, an F1 termination donor CU, such as the IAB donor CU 801, receives the identifier of the target non-F1 termination donor CU 803 from the source non-F1 termination donor CU 802 of an IAB node that has already moved within the IAB topology 8002, whose MT portion is controlled by the source non-F1 termination donor CU 802. This information includes the identifiers of the IAB nodes known by the two donor CUs (the F1 termination donor CU 801 and the source non-F1 termination donor CU 802). Alternatively, the identifier of the target non-F1 termination donor CU is received from the IAB node 870 at the F1 termination donor CU 801.

[0220] In step 1222, the F1 termination donor CU801 receives address information from the IAB node 870, including one or more addresses associated with the target IAB donor DU807 of the IAB topology 8003, through which data associated with the IAB node 870 is routed in the IAB topology 8003. For example, an F1 termination donor CU 801 receives the address of a target donor DU 807 in an IAB topology controlled by a target non-F1 termination donor CU 803 for an IAB node.

[0221] In step 1223, the F1 termination donor CU 801 may update the routing path for the IAB node 870 based on the received information to update the routing path for the IAB node 870 (e.g., the F1-C and F1-U routing paths) to a new routing path for routing data to / from the IAB node via the target donor DU 506. For example, the F1 termination donor CU updates the F1 path (control and user data path) to reach the IAB node 870 via the target donor DU 807 in the IAB topology controlled by the target non-F1 termination donor CU 803 of the IAB node.

[0222] FIG. 13 is a simplified diagram 1300 illustrating an exemplary message flow according to one embodiment of the present invention, illustrating a procedure for performing continuous MT migration of IAB nodes to a target IAB topology, including the establishment of control and user data paths.

[0223] This figure shows an example of a mobile IAB node, IAB node 1301 (similar to IAB node 870 of FIG. 8 and IAB node 123 of FIG. 1), which is comprised of a mobile termination (MT) 1303 (IAB-MT) and a distributed unit (DU) 1302 (IAB-DU). Shown are a source non-F1 terminated donor CU (or non-F1 donor CU) 1305 that terminates its RRC connection with IAB node 1301 via IAB-MT 1303, an F1 terminated donor CU (or F1 donor CU) 1304 that terminates its F1 connection with IAB node 1301 via IAB-DU 1302, and a target non-F1 donor CU 1306 that becomes the new non-F1 terminated donor CU for IAB node 1301 during the described procedure. 8, the F1-terminated donor CU 1304 of the IAB node in question is donor CU 801, and the source non-F1-terminated donor CU 1305 is donor CU 802 because the MT 871 of IAB node 870 has been migrated to IAB topology 8002 managed by donor CU 802. As the IAB node moves toward IAB topology 8003, IAB node 860 is identified as the target IAB node to which the MT of IAB node 870 can be migrated, and therefore the target non-F1-terminated donor CU 1306 is donor CU 803.

[0224] At the start of the flowchart 1300, the control path (F1-C) and user path (F1-U) established by the F1 donor CU 1304 to reach the IAB node 1301 use one or more backhaul paths through donor DUs (not shown in FIG. 13) in the IAB topology 8002 managed by the source non-F1 donor CU 1305. For example, based on FIG. 8, the backhaul paths may include the donor DU 806.

[0225] The first part of the flowchart shows a procedure 1310 for achieving migration of the IAB-MT 1303 to the IAB topology 8003 managed by the target non-F1 donor CU 1306. This includes setting up a new path for RRC protocol messages (e.g., setting up a path to support F1-C traffic to the target non-F1 donor CU).

[0226] Specifically, it is assumed that the source non-F1 donor CU 1305 receives a measurement report 1311 from the IAB node 1301 and initiates MT migration or continuous MT migration of the IAB node 1301 to another IAB topology.

[0227] A measurement report 1311 is transmitted from a source parent IAB node (e.g., parent IAB node 850 in FIG. 8) to a source non-F1 donor CU 1305 via the F1 message UL RRC MESSAGE TRANSFER (specified in TS38.423). This message contains a measurement report as an RRC message sent by the IAB-MT 1303 to the DU portion of the source parent IAB node. The measurement report is the result of measurements periodically performed by the IAB-MT 1303 on signals received from the serving cell and one or more target cells, including, for example, signal synchronization blocks (SSBs) transmitted by the serving cell and the target cell. The target cell may be a cell neighboring the serving cell or the source cell (i.e., the current serving cell). When the IAB-MT 1303 detects at least one SSB that satisfies a predetermined condition (e.g., received power above a predetermined threshold), a measurement report may be generated and transmitted to provide radio link quality information for various cells in the vicinity of the IAB node 901. The identifier of each target cell is included in the measurement report, allowing the non-F1 donor CU 1305 to identify the target CU corresponding to each target cell.

[0228] Based on the received measurement report, the source non-F1 donor CU 1305 can detect that the IAB node 1301 is receiving a radio signal of better quality in the target cell controlled by the target parent IAB node than in the source cell. For example, if the target parent IAB node (e.g., IAB node 860 in FIG. 8) belongs to a different IAB topology from the source parent IAB node (e.g., IAB node 850 in FIG. 8), the source non-F1 donor CU 1305 can decide to apply a handover preparation procedure to the IAB node 1301.

[0229] The migration of the IAB-MT 1303 is triggered by a handover request message 1312 sent from the source non-F1 donor CU 1305 to the F1 donor CU 1304 of the IAB node 1301. This message 1312 is a HANDOVER REQUEST message as specified in TS38.423 V17.2.0 Section 9.1.1.1, with a new information element added to indicate that the handover is to be toward the target non-F1 donor CU 1306. Therefore, this message includes, in addition to other information elements specified in TS38.423, the identifier of the IAB node 1301 and the identifier of the target non-F1 donor CU 1306, as known by the two donor CUs (the source non-F1 donor CU 1305 and the F1 donor CU 1304).

[0230] Upon receiving the message 1312, the F1 donor CU 1304 triggers the legacy handover preparation procedure 1313 described in TS38.423 V17.2.0 Section 8.2.1. In this procedure, the F1 donor CU 1304 sends a HANDOVER REQUEST message to the target non-F1 donor CU 1306, including necessary information related to the IAB-MT 1303. For example, this message includes identification information of the target cell to which the IAB node 1301 switches, thereby identifying the target parent IAB node (e.g., IAB node 860) that controls the target cell. After requesting the target parent IAB node to establish a UE context for the IAB node 1301, the target non-F1 donor CU 1306 performs admission control and provides new RRC configuration information to the F1 donor CU 1304 using a HANDOVER REQUEST ACKNOWLEDGE message. The F1 donor CU 1304 then forwards the response to the source non-F1 donor CU 1305 via a Handover Response 1314 message, which may be a copy of the received F1 message HANDOVER REQUEST ACKNOWLEDGE. The individual steps of the handover procedure are not shown in Figure 13, and for simplicity, only box 1313 representing IAB-MT handover preparation is shown.

[0231] Next, the source non-F1 donor CU 1305 can relay the RRC configuration information to the IAB-MT 1303 via an RRC reconfiguration message 1315. In practice, the message 1315 is first embedded in an F1 message "UE CONTEXT MODIFICATION REQUEST" specified in TS38.473 and sent from the source non-F1 donor CU 1305 to a source parent IAB node (e.g., IAB node 850) of the IAB node 1301. This source parent IAB node then sends the RRC reconfiguration message 1315 to the IAB-MT 1303. In particular, the RRC reconfiguration message 1315 includes a transport network layer (TNL) address (e.g., an IP address) that identifies the target donor DU (e.g., for data routing). In the example of FIG. 8, the address of the target donor DU 807 is replaced with the address of the donor DU 806.

[0232] After the IAB node 1301 performs the random access procedure towards the target parent IAB node (e.g., IAB node 860 in FIG. 8 ), the IAB node 1301 sends an RRC reconfiguration complete message 1316 to the target non-F1 donor CU 1306 (via an F1 message UL RRC MESSAGE TRANSFER carrying the target parent IAB node and RRC reconfiguration complete information).

[0233] The procedure 1310 ends with an Xn message UE CONTEXT RELEASE 1315, as specified in TS 38.423, sent from the target non-F1 donor CU 1306 to the F1 donor CU 1304. This message may be forwarded from the F1 donor CU 1304 to the source non-F1 donor CU 1305. However, the identifiers of the IAB node 1301 in the F1 donor CU 1304 and the source non-F1 donor CU 1305 are preserved, and the F1 path for the IAB node 1301 may still be used through the IAB topology managed by the source non-F1 donor CU 1305.

[0234] To complete the continuous MT migration of the IAB node 1301, a control data path in the IAB topology of the target non-F1 donor CU 1306 is established in step 1320, which corresponds to step 920 in Figure 9. In this step, the IAB node 1301 can notify the address information of the target donor DU to the F1 donor CU 1304. Also, a user data path is established in step 1330, which corresponds to step 1030 in Figure 10.

[0235] If the DU migration of the IAB node 1301 is in progress upon receiving the handover request message 1312, the F1 donor CU 1304 may wait for the DU migration to be completed before initiating the MT handover preparation step 1313. Alternatively, the F1 donor CU may reject the handover request and directly send a response indicating the rejection to the source non-F1 donor CU 1305 in a handover response message 1314 (e.g., the handover response is negative, indicating that the MT migration or handover has been rejected). For example, the F1 donor CU 1304 may determine whether the migration process of the DU of the IAB node has been initiated, and if it is determined that it has been initiated, it may delay the migration of the MT of the IAB node until the migration process to the third IAB donor CU is completed. Alternatively, if it is determined that the DU migration process has been initiated, the F1 donor CU 1304 may send a handover response to the second IAB donor CU rejecting the handover request. 13 and until steps 1320 and 1330 are completed, the F1 donor CU may not initiate the DU migration for the IAB node 1301. For example, the F1 donor CU may delay initiating the DU migration process until the MT migration process for the IAB node is complete (e.g., until the routing path for F1 traffic is set up). Each of these steps helps avoid conflicts between the MT and DU migrations and prevent either migration from failing.

[0236] In another example, when the F1 donor CU 1304 receives a handover request message 1312 from the source non-F1 donor CU 1305, the F1 donor CU 1304 may acknowledge the request by sending a handover response message 1314. After receiving the message 1314, the source non-F1 donor CU 1305 performs MT migration with the target non-F1 donor CU 1306, as described with respect to step 912 of FIG. 9 above. Before sending the handover response message 1314 to the source non-F1 donor CU 1305, the F1 donor CU 1304 may check whether DU migration of the co-located DU (IAB-DU 1302) of the IAB node 1301 is in progress. If DU migration is in progress, the F1 donor CU 1304 may wait for the DU migration to complete before sending a positive handover response. That is, after the ongoing DU migration is completed, the F1 donor CU 1304 sends a handover response message 1314 as a positive response, causing the source non-F1 donor CU 1305 to perform MT migration. On the other hand, if the F1 donor CU 1304 determines that a DU migration is in progress, it can send a negative response in the handover response message 1314 (i.e., indicating that the handover request has been rejected).

[0237] 14a and 14b are flowcharts illustrating an exemplary method according to an embodiment of the present invention, performed at different network nodes in a wireless communication system (e.g., the communication system shown and described in FIG. 1 and the IAB communication system shown and described in FIG. 8). The exemplary method at the different network nodes is used in a migration process (or part thereof) in which an MT of an IAB node is migrated from a second IAB topology managed by a second IAB donor CU (e.g., a source IAB donor CU) to a third IAB topology managed by a third IAB donor CU (e.g., a target IAB donor CU), where the IAB node is managed (or controlled, served) in the first IAB topology by a first IAB donor CU (e.g., an F1 terminating donor CU). The second and third IAB donor CUs are non-F1 terminating donor CUs of the IAB node. After the second IAB donor CU decides to migrate the MT of the IAB node from the second IAB topology to a third IAB topology, the first IAB donor CU or the F1 terminating donor CU receives a handover request from the second IAB donor CU. The handover request (e.g., message 1312 described above) includes IAB node identification information for identifying the IAB node having the MT to be migrated and identification information (e.g., PCI or NCGI) for identifying the target cell to which the MT is migrated, thereby identifying the target IAB donor CU that manages the third IAB topology to which the MT is migrated. The F1 terminating donor CU may then initiate a procedure (e.g., a procedure in cooperation with the target IAB donor CU and the source IAB donor CU, such as procedure 1313 described above) to migrate the MT of the IAB node to the target IAB donor CU. Alternatively, the source non-F1 terminating donor CU may initiate a procedure to migrate the MT of the IAB node to the target IAB donor CU.After the migration is complete (e.g., after the handover is accepted by the target IAB donor CU), the F1 terminating donor CU may send a handover response to the source IAB donor CU that includes configuration information related to one or more routing paths for routing data associated with the IAB node within the third IAB topology. This configuration information includes one or more addresses (e.g., IP addresses, TNL addresses) associated with the target IAB donor DU through which data (e.g., F1 traffic, user traffic, control traffic) will be routed to the IAB node in the third IAB topology. The configuration information received at the F1 terminating donor CU may be provided to the IAB node (e.g., via the source IAB donor CU).

[0238] In this way, the handover request and the configuration information received at the first IAB donor CU (F1 terminating donor CU) of the IAB node enable the F1 terminating donor CU to have knowledge of the migration of the MT between two different topologies of the IAB node, i.e., from a second IAB topology (e.g., managed by the source IAB donor CU) to a third IAB topology (e.g., managed by the target IAB donor CU), and at least one new routing path to be used for routing data (e.g., user traffic and control traffic) related to the migrated IAB node within the third IAB topology.

[0239] 14a is a flowchart illustrating an exemplary method 1400 performed in a second IAB donor CU (e.g., a source non-F1 terminated donor CU of an IAB node) for use in an MT migration process (or part thereof) of an IAB node, according to one embodiment of the present invention. The method 1400 is for managing, in a source non-F1 terminated donor CU of an IAB node, the continuous MT migration of the IAB node toward a target IAB topology that differs from the IAB topology controlled by the F1 terminated donor CU. For example, with reference to the IAB communication system shown and described in FIG. 8, the second IAB donor CU performing the method 1400 may be the IAB donor CU 802, which is a non-F1 terminated donor CU of the IAB node 870 (e.g., has an RRC connection with the mobile IAB node 870). The IAB node may be a mobile IAB node 870 belonging to an IAB topology 8001 controlled by an IAB donor CU 801 (e.g., an F1-terminating donor CU that maintains an F1 connection with the mobile IAB node 870). The migration process may include migrating an MT 871 of the mobile IAB node 870 from an IAB donor DU 806 (a source non-F1-terminating donor CU managed by the IAB donor CU 802) in the IAB topology 8002 to an IAB donor DU 807 (a target non-F1-terminating donor CU managed by the IAB donor CU 803) in the IAB topology 8003. The method 1400 shown and described in FIG. 14a may be performed by software and / or hardware elements. The non-F1 terminated IAB donor CU may be implemented within the communication device 400 shown and described in FIG. 4, and the method shown and described in FIG. 14a may be performed by one or more processing units, for example, a central processing unit 411.

[0240] In step 1401, a source non-F1 terminated donor CU (e.g., donor CU 802) of an IAB node (e.g., IAB node 870) detects that a MT portion of the IAB node is to be migrated to a target non-F1 terminated donor CU (e.g., donor CU 803). For example, the source non-F1 terminated donor CU 802 determines, based on a measurement report, that the MT 871 of the IAB node 870 should be migrated to the third IAB topology 8003. This information may be obtained (e.g., the determination is made) through a decision by the source non-F1 terminated donor CU itself based on receipt of a measurement report from the IAB node. For example, the measurement report indicates that the MT 871 of the IAB node 870 should be migrated to a cell of the third IAB topology based on measurements made based on signals received at the IAB node 870.

[0241] In step 1402, the source non-F1 terminating donor CU 802 transmits an IAB node handover request toward the target non-F1 terminating donor CU 803 to the F1 terminating donor CU 801 of the IAB node 870 that controls the other IAB topology 8001. The handover request includes identification information for identifying the target IAB donor CU 803, such as the PCI or NCGI of the target cell. The handover request also includes information for identifying the IAB node having the MT to be migrated. For example, the request includes the identifier of the target non-F1 terminating donor CU 803 as well as the identifiers of the IAB nodes recognized by the two donor CUs (the F1 terminating donor CU and the source non-F1 terminating donor CU). The request may be the handover request 1312 described above.

[0242] In step 1403, the source non-F1 terminating donor CU 802 receives a handover response from the F1 terminating donor CU 801 of the IAB node. The handover response may indicate whether the handover is accepted (positive response) or rejected (negative response). If the handover is accepted, the response includes routing path configuration information for routing data related to the IAB node in the third IAB topology 8003. The configuration information may include one or more addresses related to the target IAB donor DU 807 of the third IAB topology, along which data related to the IAB node 870 in the third IAB topology is routed. The configuration information embedded in the handover response is forwarded to the IAB node 870. The response may be the handover response message 1314 described above.

[0243] As another example, when the F1 terminating donor CU 801 receives a handover request message 1312 from the source non-F1 terminating donor CU 802, the F1 terminating donor CU 801 may respond to this request by sending a handover response (e.g., a handover response message 1314) to the non-F1 terminating donor CU 802. In step 1403, upon receiving the handover response, the non-F1 terminating donor CU 802 performs MT migration with the target non-F1 terminating donor CU 803, as described above in connection with step 912 of FIG. 9 . Before the F1 terminating donor CU 801 sends the handover response (e.g., the handover response message 1314) to the non-F1 terminating donor CU 802, the F1 terminating donor CU 801 may check whether DU migration is in progress for the IAB-DU 872 coexisting in the IAB-MT 871 of the IAB node 870. If there is an ongoing DU migration, the F1 terminating donor CU 801 may wait until the DU migration is completed before sending a positive response in the handover response message 1314. In other words, the F1 terminating donor CU 801 may trigger the non-F1 terminating donor CU 802 to perform an MT migration by sending a handover response as a positive response after the ongoing DU migration is completed. Alternatively, if the F1 donor CU 1304 determines that a DU migration is in progress, the F1 donor CU 1304 may send a handover response in the handover response message 1314 as a negative response indicating that it has rejected the handover request.

[0244] FIG. 14b is a flowchart illustrating an example method 1410 performed in a first donor CU (e.g., an F1-terminated donor CU of an IAB node) used in an MT migration process (or part thereof) of an IAB node. The method 1410 is for managing, in an F1-terminated donor CU of an IAB node, a continuous MT migration of the IAB node toward a target IAB topology that differs from the IAB topology managed by the source non-F1-terminated donor CU of the IAB node. For example, with reference to the IAB communication system shown in and described with reference to FIG. 8, the first IAB donor CU performing the method 1410 may be an IAB donor CU 801, which is an F1-terminated donor CU that maintains an F1 connection with an IAB node 870. The IAB node may be a mobile IAB node 870 that belongs to an IAB topology 8001 managed by the IAB donor CU 801. The migration process may include migrating the MT 871 of the mobile IAB node 870 from the IAB donor DU 806 in the IAB topology 8002 managed by the IAB donor CU 802 acting as a source non-F1 terminating donor CU to the IAB donor DU 807 in the IAB topology 8003 managed by the IAB donor CU 803 acting as a target non-F1 terminating donor CU. The method 1410 shown in and described in FIG. 14b may be performed by software and / or hardware elements. The F1 terminating IAB donor CU 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 reference to FIG. 14b may be performed by one or more processing units, such as the central processing unit 411.

[0245] In step 1411, an F1-terminated donor CU (e.g., donor CU 801) receives a handover request, which is a request to migrate an MT of an IAB node to a third IAB topology. The handover request includes IAB node identification information for identifying an IAB node 870 having an MT to be migrated, and identification information for identifying a target IAB donor CU 803 that manages the third IAB topology 8003 to which the MT of the IAB node 870 will be migrated. For example, the F1-terminated donor CU (e.g., donor CU 801) receives an IAB node handover request from a source non-F1-terminated donor CU (e.g., donor CU 802) of the IAB node (e.g., IAB node 870) toward a target non-F1-terminated donor CU (e.g., donor CU 803). The request includes identifiers of IAB nodes known by the two donor CUs (F1 terminating donor CU 801 and source non-F1 terminating donor CU 802) along with the identifier of the target non-F1 terminating donor CU 803. The request may be the handover request 1312 described above.

[0246] In step 1412, the F1 terminating donor CU 801 may perform MT migration of the IAB node 870 toward the target non-F1 terminating donor CU 803 using a handover procedure (e.g., in response to receiving a handover request from the source non-F1 terminating donor CU 802). For example, the F1 terminating donor CU 801 may initiate and perform the handover procedure 1313 described above. Migrating the MT of the IAB node 870 to the target IAB donor CU 803 includes sending a migration request from the source F1 donor CU 801 to the target IAB donor CU 803 to a target cell of the third IAB topology (e.g., a target cell that is determined to provide better radio quality than the serving cell based on radio signal measurements received by the IAB node). In response, the source F1 donor CU 801 receives a response from the third IAB donor CU 803 that includes configuration information associated with one or more routing paths for routing data related to the IAB node in the third IAB topology.

[0247] In step 1413, the F1 termination donor CU 801 sends a handover response to the source non-F1 termination donor CU 802. This handover response may indicate a positive response if the handover is accepted by the target non-F1 termination donor CU, or a negative response if the handover is rejected. If the handover is accepted, the response includes configuration information related to the IAB node 870 received from the target non-F1 termination donor CU 803 in step 1412. For example, this configuration information is configuration information related to a data routing path related to the mobile IAB node 870 in the third IAB topology 8003, and may include one or more addresses related to the target IAB donor DU (e.g., IAB donor DU 807). The response may be the handover response 1314 described above.

[0248] Although not shown in FIG. 14b, the source F1 donor CU 801 can determine whether a migration process of a DU (e.g., IAB-DU 872) of the IAB node 870 has been initiated (e.g., is in progress). If the source F1 donor CU 801 determines that the migration process of the DU has been initiated, the source F1 donor CU 801 can delay the migration of the MT of the IAB node to the target IAB donor CU 803 until the DU migration process of the IAB node is completed. Alternatively, if the source F1 donor CU 801 determines that the migration process of the DU of the IAB node has been initiated, the source F1 donor CU 801 can send a handover response to the source non-F1 terminating donor CU 802 to reject the handover request. In another example, the F1 donor CU 801 can delay the initiation of the migration process of the DU of the IAB node until the MT migration process of the IAB node 870 is completed (e.g., until one or more routing paths for F1 traffic are set up).

[0249] 14b, step 1412 is indicated by a dashed line. This is because the F1 terminating donor CU 801 may send a handover response in step 1413 without initiating MT migration. For example, upon receiving a handover request (e.g., handover request message 1312) from the source non-F1 terminating donor CU 802 in step 1411, the F1 terminating donor CU 801 may acknowledge the request by sending a handover response (e.g., handover response message 1314) to the source non-F1 terminating donor CU 802. As described above, after receiving the handover response, the source non-F1 terminating donor CU 802 may perform MT migration with the target non-F1 terminating donor CU 803. Before sending a handover response (e.g., handover response message 1314) to the non-F1 terminating donor CU 802, the F1 terminating donor CU 801 may check whether DU migration is in progress for the IAB-DU 872 co-located with the IAB-MT 871 of the IAB node 870. If DU migration is in progress, the F1 terminating donor CU 801 may wait to send an acknowledgement in the handover response message 1314 until the DU migration is completed. In other words, when the ongoing DU migration is completed, the F1 terminating donor CU 801 sends a handover response as an acknowledgement, causing the non-F1 terminating donor CU 802 to perform the migration of the IAB-MT. Alternatively, if the F1 donor CU 1304 determines that a DU migration is in progress, the F1 donor CU 1304 may send a negative response in step 1413 in a handover response message 1314 indicating that the handover request is rejected.

[0250] Therefore, the migration of the MT may be performed by the F1 terminating donor CU801 upon receiving a handover request from the source non-F1 terminating donor CU802 (step 1411), or, as described above, the F1 terminating donor CU801 may initiate the migration after receiving the handover request and the source non-F1 terminating donor CU802 may perform it.

[0251] 15 is a diagram 1500 illustrating, in a simplified and simplified manner, some example message flows for avoiding initiating DU migration of an IAB node during successive MT migrations, in accordance with one or more embodiments of the present invention. Successive MT migrations may involve multiple MT migrations between different parent IAB nodes managed by the same donor CU but connected to different donor DUs than the donor CU that provides the DU of the IAB node. Alternatively, successive MT migrations may involve new MT migrations between different parent IAB nodes managed by different donor CUs than the donor CU that provides the DU of the IAB node.

[0252] 15 shows a source non-F1 terminated donor CU (or non-F1 donor CU) 1505 terminating an RRC connection to an IAB node (not shown), an F1 terminated donor CU (or F1 donor CU) 1504 terminating an F1 connection to the IAB node, and a target non-F1 donor CU 1506 to become the new non-F1 terminated donor CU to the IAB node. By way of example, with respect to the IAB communication system of FIG. 8, the F1 terminated donor CU 1504 to the IAB node is donor CU 801, and MT 871 of IAB node 870 is migrated to IAB topology 8002 managed by donor CU 802, and therefore the source non-F1 terminated donor CU 1505 is donor CU 802. As the IAB nodes move towards the IAB topology 8003, IAB node 860 is identified as the target IAB node to which MT 871 of IAB node 870 can migrate, and target non-F1 terminating donor CU 1506 becomes donor CU 803.

[0253] Reasons for performing DU migration include reducing the processing load on the F1 donor CU 1504 or when the IAB node is geographically distant from the F1 donor CU 1504 and is close to an area where Xn or IP connectivity no longer exists between the F1 donor CU 1504 and the target F1 donor CU. Briefly, the DU migration procedure of an IAB node may be performed according to the following procedure: Based on a determination by a source F1 donor CU to perform DU migration of the IAB node to another IAB topology managed by another donor CU, as a first step, the source F1 donor CU of the IAB node 870 sends a request to the IAB node to establish a new F1 connection between the target F1 donor CU and the IAB node. For example, referring to FIG. 8 , the source F1 donor CU of the IAB node 870 is the donor CU 801, and the source F1 donor CU of the IAB node 870 determines to DU migrate the IAB-DU 872 of the IAB node 870 to the IAB topology 8003, so that the target F1 donor CU becomes the donor CU 803. This process may require activation of a second logical DU entity via a message from the F1 donor CU to the IAB node. Thus, once the second logical DU entity is activated, the IAB node has two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. Each logical DU entity serves one or more cells. The cell of one logical DU entity (e.g., the first logical DU) is identified by an identifier that has a value different from the identifiers (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) of the cell of the other logical DU entity (e.g., the second logical DU). After activation, the second logical DU entity may send an F1 Setup Request message to the target F1 donor CU to request the setup of an F1 connection.In the F1 setup response, the target F1 donor CU may request the second logical DU of the IAB node to activate a new cell and may notify the source F1 donor CU about the activation of the new cell.

[0254] The next step involves handing over the UEs served by the IAB node from the cell of the first logical DU of the IAB node to the cell of the second logical DU. The target F1 donor CU may execute a path switching procedure toward the core network to request that user data associated with the UE be delivered via the second logical DU. The target F1 donor CU then needs to establish a backhaul path between itself and the migrated IAB node. This backhaul path may be directly reachable within the IAB topology managed by the target F1 donor CU or may be via the topology of a non-F1 donor CU of the IAB node. In this latter case, the target F1 donor CU may trigger a procedure to request traffic migration for the non-F1 donor CU of the IAB node. After the handover of all UEs served by the first logical DU of the IAB node is complete, the source F1 donor CU may deactivate the first logical DU of the mobile IAB node. The source F1 donor CU may also release traffic (user traffic, control traffic) associated with the UE that was being served via the first logical DU of the IAB node. If the traffic was offloaded to an IAB topology managed by another donor CU (i.e., a non-F1 donor CU), the source F1 donor CU may apply a procedure to request the non-F1 donor CU to release the traffic.

[0255] MT migration can be considered to include MT handover, such as procedure 910 described with reference to FIG. 9 and procedure 1010 described with reference to FIG. 10, and transport migration (setting up the F1-C / F1-U path), such as procedure 920 described with reference to FIG. 9 and procedures 1020 and 1030 described with reference to FIG. 10. If the F1 donor CU is changed due to DU migration, this does not affect MT handover, but transport migration may fail. The source donor CU of the mobile IAB-MT can send information about the target donor CU of the mobile IAB-MT to the donor CU of the mobile IAB-DU after the IAB-MT handover is completed. However, if the F1 donor CU is changed during MT handover, transport migration may fail because the old F1 donor CU, not the new F1 donor CU, is notified. It is clear that DU migration may be more affected by parallel MT migration because it relies on protocol messages exchanged over the IAB topology managed by the non-F1 donor CU. Therefore, the F1 setup procedure or UE handover may fail because the IAB topology required for communication with IAB nodes is changed by MT migration.

[0256] Based on the above, it seems that if an MT migration is performed during a DU migration, the DU migration procedure may fail or be interrupted midway. Indeed, successive MT migrations of an IAB node may involve the establishment of new backhaul paths through the new IAB topology, and some packet loss may occur before all IAB donor CUs that need to communicate with the mobile IAB node are aware of this change. A safe way to avoid service interruptions for UEs served by an IAB node is to perform and complete the DU migration while the co-located MT remains connected to the same IAB donor CU.

[0257] Assume that the source non-F1 donor CU 1505, having received the measurement report from the IAB node, determines that the MT part of the IAB node needs to be handed over to a parent IAB node belonging to the IAB topology of the target non-F1 donor CU 1506 (e.g., parent IAB node 860 of IAB topology 8003), or to a parent IAB node belonging to the IAB topology of the source non-F1 donor CU 1505 but with a new IAB donor DU to communicate with the IAB node (e.g., when the IAB node 870 is initially connected to the parent IAB node 830 (connected to the donor DU 805), and the non-F1 donor CU 802 migrates the MT 871 of the IAB node 870 to the parent IAB node 850 (connected to the donor DU 806)). Therefore, an MT migration procedure should be performed or initiated, such as the procedure described with reference to Figure 9 (migration to a new IAB topology) or Figure 6 (migration to a parent IAB node with a new IAB donor DU).

[0258] To prevent a DU migration of the IAB node from being initiated during this MT migration procedure (e.g., procedure 910 in FIG. 9 ), the source non-F1 donor CU 1506 sends an MT migration notification to the F1 donor CU 1504 indicating that the IAB node's MT is to be migrated to a new parent IAB node. This MT migration notification (or MT handover notification) may be included in an MT handover notification (or IAB NODE MIGRATION REQUEST) message 1512 sent to the F1 donor CU 1504. This MT migration notification may be sent before the migration of the IAB node's MT to the second parent IAB node is performed (e.g., before the MT migration procedure / process begins).

[0259] As an example, message 1512 is sent before the execution of the IAB-MT handover preparation procedure 912 described with reference to Figure 9 or before the sending of message 612 described with reference to Figure 6. As mentioned above, message 612 includes information identifying the target donor DU (or new donor DU) to be used as a migration destination for the IAB node to set up a new routing path via the target donor DU.

[0260] Assuming that the RRC reconfiguration procedure is triggered by an IAB node, as described with respect to FIG. 11, the source non-F1 donor CU 1505 may, after receiving a message (e.g., a UE context acquisition request message) from the target non-F1 donor CU 1506, send a message 1512 to the F1 donor CU 1504 to notify it as part of the UE context acquisition procedure 1112 of the IAB node.

[0261] The MT migration notification includes IAB node identification information for identifying the IAB node having the MT to be migrated. This identification information may include an identifier of at least one IAB node. If the MT migration is to a new IAB topology, the notification may also include identification information for identifying the target non-F1 donor CU 1506. For example, message 1512 may include identifiers of IAB nodes known by the two donor CUs (F1 donor CU 1504 and source non-F1 donor CU 1505) and may further include an identifier of the target non-F1 donor CU 1506. These IAB node identifiers may include identifiers known to the F1-terminated donor CU and the non-F1-terminated donor CU. For example, the message may include one or more information elements, namely, "F1-terminated IAB-donor UE XnAP ID," "non-F1-terminated IAB-donor UE XnAP ID," "RRC-terminated IAB-donor UE XnAP ID," and "BAP address" assigned to the IAB node. The identifier (or identifying information) of the target non-F1 donor CU 1506 may include the "PCI" or "NCGI" of the target cell in the target IAB topology to which the MT is migrated.

[0262] After receiving this message 1512, the F1 donor CU 1504 may disable the execution of DU migration for the IAB node in operation 1510. For example, the F1 donor CU 1504 may disable the initiation of a migration process for a DU in the IAB node. If the message 1512 indicates that the target non-F1 donor CU 1506 of the MT handover corresponds to the target F1 donor CU for the migration of a co-located DU in the IAB node (i.e., when the DU and MT are migrated to the same donor CU), the F1 donor CU 1504 may determine that the target non-F1 donor CU is capable of processing both MT migration and DU migration simultaneously and may not disable DU migration. However, DU migration to a different target F1 donor CU (e.g., a donor CU different from the donor CU to which the MT is migrated) is disabled.

[0263] Next, the F1 donor CU 1504 may send an MT handover response (or "IAB NODE MIGRATION RESPONSE") message 1513 to the source non-F1 donor CU 1505. The source non-F1 donor CU 1505 may wait for this acknowledgement message 1513 and begin performing an MT migration procedure 1514 (e.g., as described with respect to FIGS. 6, 9, 10, and 11). For example, the F1 donor CU 1504 may perform an MT migration of the IAB node after receiving the MT migration response in message 1513.

[0264] If a DU migration procedure for the IAB node is in progress at the time of receiving the MT handover notification message 1512, the F1 donor CU 1504 may wait to send the MT handover response message 1513 until the DU migration procedure is completed. Alternatively, the F1 donor CU 1504 may send an MT handover response (or "IAB NODE MIGRATION REJECT") message 1513 indicating that the MT handover has been rejected due to an ongoing DU migration (i.e., the reason for the rejection is included in the message 1513).

[0265] Upon completion of the MT migration operation 1514, the source non-F1 donor CU 1505 may send an MT handover complete message 1515 to the F1 donor CU 1504 to indicate that the MT migration is complete. The message 1515 includes identifiers of IAB nodes known by the two donor CUs (the F1 donor CU 1504 and the source non-F1 donor CU 1505) and may also include an identifier of the target non-F1 donor CU 1506.

[0266] After receiving the MT handover complete message 1515, the F1 donor CU 1504 may again enable DU migration for the IAB node in operation 1520.

[0267] The MT migration operation 1514 corresponds to performing the procedure described with respect to FIG. 6, FIG. 9, FIG. 10, or FIG. In each of these procedures, the F1 donor CU 1504 is involved at some point, in which case message 1515 may not be necessary. Therefore, operation 1520 may also be triggered after receiving an IAB transport migration response from the source F1 donor CU 1505 or the target F1 donor CU 1506 (e.g., message 1036 or 1033 in FIG. 10).

[0268] As an example, the MT handover notification message 1512 is a HANDOVER REQUEST message as specified in TS 38.423 V17.2.0 Section 9.1.1.1, but includes a new information element to indicate that it is an IAB node MT handover notification performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes identifiers of the associated IAB nodes known by the two donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and may also include the identifier of the target non-F1 donor CU, in addition to other information elements specified in TS 38.423. The MT handover response message 1513 is also a HANDOVER REQUEST ACKNOWLEDGE message as specified in TS 38.423 V17.2.0 Section 9.1.1.2, but contains a new information element indicating that it is an acknowledgement of the MT handover of the IAB node to be performed between the source non-F1 donor CU and the target non-F1 donor CU. If the MT handover is rejected, the MT handover response message 1513 is a HANDOVER PREPARATION FAILURE message as specified in TS 38.423 V17.2.0 Section 9.1.1.3, but contains a new information element indicating that it is a rejection of the MT handover of the IAB node and includes the reason (e.g., load problem).

[0269] According to another example, the MT handover notification message 1512 is an NG-RAN NODE CONFIGURATION UPDATE message as specified in TS 38.423 V17.2.0 Section 9.1.3.4, but includes a new information element indicating that it is an IAB node MT handover notification performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes identifiers of the associated IAB nodes known by the two donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and possibly the identifier of the target non-F1 donor CU, in addition to other information elements. The MT handover response message 1513 is also the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message specified in TS 38.423 V17.2.0 Section 9.1.3.5, but contains a new information element indicating that it is an acknowledgement of the IAB node MT handover performed between the source non-F1 donor CU and the target non-F1 donor CU. If the MT handover is rejected, message 1513 is the NG-RAN NODE CONFIGURATION UPDATE FAILURE message specified in TS 38.423 V17.2.0 Section 9.1.3.6, but contains a new information element indicating that it is a rejection of the IAB node MT handover and the reason for it (e.g., load problem).

[0270] According to yet another example, the MT handover notification message 1512 is a MOBILITY CHANGE REQUEST message as defined in TS 38.423 V17.2.0 Section 9.1.3.22, but includes a new information element indicating that it is an IAB node MT handover notification performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes identifiers of the associated IAB nodes known by the two donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and possibly also includes an identifier of the target non-F1 donor CU in addition to other information elements. Also, the MT handover response message 1513 is a MOBILITY CHANGE ACKNOWLEDGE message as specified in TS 38.423 V17.2.0 Section 9.1.3.23, but contains a new information element indicating that it is an acknowledgement of the MT handover of the IAB node to be performed between the source non-F1 donor CU and the target non-F1 donor CU. If the MT handover is rejected, message 1513 is a MOBILITY CHANGE FAILURE message as specified in TS 38.423 V17.2.0 Section 9.1.3.24, but contains a new information element indicating that it is a rejection of the MT handover of the IAB node and includes the reason (e.g., load problem).

[0271] 16a is a flowchart of an exemplary method 1600 according to one or more embodiments of the present invention, used in a second IAB donor CU (e.g., a source non-F1 terminating donor CU) of an IAB node to manage successive MT migrations so as not to conflict with DU migrations of the IAB node. The successive MT migrations of the IAB node include migrations of MTs of the IAB node from a first parent IAB node belonging to an IAB topology managed or controlled by the second IAB donor CU (e.g., a source non-F1 terminating donor CU) to a second parent IAB node. As an example, the first parent IAB node uses a first backhaul path including a first IAB donor DU in the second IAB topology to route data related to the IAB node, and the second parent IAB node uses a second backhaul path including a second IAB donor DU to route data related to the IAB node (e.g., when migrations are performed between two different donor DUs in the same topology). In this case, the source non-F1 donor CU may decide to apply an intra-CU topology adaptation procedure to the IAB node, as described above in connection with Figure 6. As another example, the second parent IAB node may be part of a third IAB topology managed by a third IAB donor CU. In this case, the successive MT migration of the IAB node is toward a target IAB topology that is different from the IAB topology controlled by the first IAB donor CU (e.g., F1 terminating donor CU) of the IAB node (e.g., if the target IAB topology, as described above in connection with Figure 9, is not the IAB topology controlled by the F1 terminating donor CU of the IAB node).

[0272] For example, with reference to the IAB communication system shown in and described with respect to FIG. 8, the second IAB donor CU performing procedure 1600 may be a non-F1 terminated donor CU (e.g., IAB donor CU 802) that has an RRC connection with an IAB node 870. The IAB node may be a mobile IAB node 870, which belongs to an IAB topology 8001 controlled by an F1 terminated donor CU (e.g., IAB donor CU 801) that maintains an F1 connection with the mobile IAB node 870. In FIG. 15, the non-F1 terminated donor CU is designated by reference numeral 1505, the F1 terminated donor CU is designated by reference numeral 1504, and the target non-F1 terminated donor CU is designated by reference numeral 1506. As an example, the migration process may include migration of an MT 871 of an IAB node 870 from a first parent IAB node (e.g., IAB node 830) in an IAB topology 8002 to a second IAB node (e.g., IAB node 850) in the same IAB topology 8002, where the first parent IAB node 830 is on a backhaul path that includes a first donor DU 805 and is different from a donor DU 806 on the backhaul path of the second IAB node 850. As another example, the migration process may include migration of an MT 871 of an IAB node 870 from a donor DU 806 in the IAB topology 8002 controlled by an IAB donor CU 802 acting as a donor CU for a source non-F1 termination to a donor DU 807 in the IAB topology 8003 controlled by an IAB donor CU 803 acting as a donor CU for a target non-F1 termination. The procedure 1600 shown in and described with reference to Figure 16a may be performed by software and / or hardware elements. The non-F1 terminated IAB donor CU may be implemented in the communication device 400 shown in and described with reference to Figure 4, where the procedure shown in and described with reference to Figure 16a may be performed by an apparatus for the non-F1 terminated IAB donor CU that includes one or more processing units, such as the central processing unit 411.

[0273] In step 1601, a source non-F1 donor CU, which is a non-F1-terminated donor CU (e.g., donor CU 802) of an IAB node (e.g., IAB node 870), determines that an MT of the IAB node should be migrated to a second parent IAB node. For example, the source non-F1 donor CU 802 determines that an MT 871 of the IAB node 870 should be successively migrated to a target topology (e.g., IAB topology 8003) managed by a target non-F1-terminated donor CU (e.g., donor CU 803). Alternatively, the source non-F1 donor CU 802 determines that an MT 871 of the IAB node 870 should be successively migrated to a parent IAB node (e.g., IAB node 850) in the same IAB topology 8002 managed by the source non-F1 donor CU 802. The parent IAB node to which the MT871 is to be migrated is connected (directly or indirectly) to a different donor DU than the donor DU on the current backhaul path of the IAB node 870.

[0274] In step 1602, the source non-F1 donor CU 802 sends an MT handover notification message identifying the IAB node 870 to an F1 donor CU, such as the donor CU 801. For example, the source non-F1 donor CU 802 sends an MT migration notification (or MT handover notification) indicating that the MT 871 of the IAB node 870 should be migrated. The MT migration notification (or MT handover notification) includes identification information for identifying the IAB node having the MT to be migrated. The MT migration notification may be included in the MT handover notification (or IAB node migration request) message 1512, as described above. The source non-F1 donor CU 802 may send the MT migration notification (or MT handover notification) before performing the migration of the MT of the IAB node, as described above in connection with FIG. 15 and the sending of message 1512.

[0275] In step 1603, the source non-F1 donor CU 802 may receive an MT handover response message (or MT migration response) from the F1 donor CU 801 in response to the MT handover notification message of step 1602. The MT handover response (or MT migration response) may be included in the MT handover response (or IAB node migration response) message 1513, as described above.

[0276] In step 1604, the source non-F1 donor CU 802 performs an MT migration procedure (e.g., including an MT handover) of the IAB node 870. For example, the source non-F1 donor CU 802 may start performing an MT migration procedure 1514 after receiving an MT handover response (or IAB node migration response) message 1513, as described with reference to FIG. 6, FIG. 9, FIG. 10, or FIG. 11.

[0277] In step 1605, the source non-F1 donor CU 802 may send a message to the F1 donor CU 801 indicating that the MT migration of the IAB node 870 is complete. For example, the source non-F1 donor CU 802 may send the MT handover complete message 1515, as described above.

[0278] 16b is a flowchart of an example method 1610 performed in an F1 terminating donor CU of an IAB node for managing DU migration of the IAB node during successive MT migration, in accordance with one or more embodiments of the present invention. The method 1610 is performed in a first IAB donor CU (e.g., F1 terminating donor CU) of the IAB node. The method includes disabling DU migration of the IAB node at the F1 terminating donor CU during successive MT migration of the IAB node. The successive MT migration of the IAB node includes MT migration of the IAB node from a first parent IAB node to a second parent IAB node belonging to an IAB topology managed or controlled by a second IAB donor CU (e.g., a source non-F1 terminating donor CU). As an example, a first parent IAB node may use a first backhaul path including a first IAB donor DU in a second IAB topology managed by a second IAB donor CU to route data related to the IAB node, and the second parent IAB node may use a second backhaul path including a second IAB donor DU in the second IAB topology (e.g., when migration occurs between two different donor DUs in the same topology). In this case, the source non-F1 donor CU may decide to apply an intra-CU topology adaptation procedure to the IAB node, as described above in connection with FIG. 6. As another example, the second parent IAB node may be part of a third IAB topology managed by a third IAB donor CU. In this case, the continuous MT migration of the IAB node is performed towards a target IAB topology that is different from the IAB topology controlled by the first IAB donor CU (e.g., F1 termination donor CU) of the IAB node (e.g., if the target IAB topology is not the IAB topology controlled by the F1 termination donor CU of the IAB node).

[0279] For example, with reference to the IAB communication system shown in and described with respect to Figure 8, the first IAB donor CU performing procedure 1610 may be an F1 terminating donor CU (e.g., IAB donor CU 801) that maintains an F1 connection with an IAB node 870. The IAB node may be a mobile IAB node 870 that belongs to an IAB topology 8001 controlled by the IAB donor CU 801. In Figure 15, the non-F1 terminating donor CU is designated by reference numeral 1505, the F1 terminating donor CU is designated by reference numeral 1504, and the target non-F1 terminating donor CU is designated by reference numeral 1506. As an example, the migration process may include migration of an MT 871 of an IAB node 870 from a first parent IAB node (e.g., IAB node 830) in an IAB topology 8002 controlled by an IAB donor CU 802 to a second IAB node (e.g., IAB node 850) in the same IAB topology 8002, where the first parent IAB node 830 is connected to a first donor DU 805 via a backhaul path and is different from a donor DU 806 to which the second IAB node 850 is connected. As another example, the migration process may include migration of an MT 871 of an IAB node 870 from a donor DU 806 in the IAB topology 8002 controlled by an IAB donor CU 802 acting as a source non-F1 terminating donor CU to a donor DU 807 in the IAB topology 8003 controlled by an IAB donor CU 803 acting as a target non-F1 terminating donor CU. The procedure 1610 shown in and described with reference to Figure 16b may be performed by software and / or hardware elements. The F1-terminated IAB donor CU may be implemented in the communication device 400 shown in and described with reference to Figure 4, where the procedure shown in and described with reference to Figure 16b may be performed by an apparatus for the F1-terminated IAB donor CU that includes one or more processing units, such as the central processing unit 411.

[0280] In step 1611, an F1 terminating donor CU (e.g., IAB donor CU 801) of an IAB node (e.g., IAB node 870) receives an MT handover notification for the IAB node from a source non-F1 terminating donor CU (e.g., donor CU 802). That is, the F1 donor CU 801 receives an MT migration notification (or MT handover notification) indicating that an MT 871 of the IAB node 870 is to be migrated from a first parent IAB node (e.g., a current parent IAB node) to a second parent IAB node (e.g., a new or target parent IAB node). The MT migration notification (or MT handover notification) includes identification information for identifying the IAB node having the MT to be migrated. The MT handover notification may indicate that the MT 871 in the IAB node is to be successively migrated to a target topology (e.g., IAB topology 8003) managed by a target non-F1 terminating donor CU (e.g., IAB donor CU 803). The source non-F1 donor CU may be the IAB donor CU 802, and the target non-F1 donor CU may be the IAB donor CU 803. Alternatively, the MT handover notification may indicate that the MT 871 in the IAB node is to be migrated to a parent IAB node (e.g., IAB node 850) in the same IAB topology 8002 managed by the source non-F1 donor CU 802. The parent IAB node to which the MT 871 is to be migrated is connected (directly or indirectly) to a different donor DU than the donor DU included in the current backhaul path of the IAB node 870. The MT migration notification may be included in the MT handover notification (or IAB node migration request) message 1512, as described above.

[0281] In step 1612, the F1 donor CU disables the initiation of the DU migration procedure for the IAB node. For example, after receiving or in response to the MT migration notification, the F1 donor CU 801 disables the initiation of the migration process for the DU of the IAB node until the migration process for the MT of the IAB node is completed.

[0282] After the MT of the IAB node has been migrated to the second parent IAB node (i.e., the migration process for the MT of the IAB node has been completed), the F1 donor CU 801 enables the initiation of the migration process of the DU for the IAB node (step 1615). The F1 donor CU 801 may determine whether the MT of the IAB node has been migrated to the second parent IAB node, as described in step 1614.

[0283] In step 1613, the F1 donor CU 801 may send an MT handover response message (or MT migration response) to the source non-F1 donor CU 802 in response to the MT handover notification message in step 1611. The MT handover response message (or MT migration response) may be included in the MT handover response (or IAB node migration response) message 1513, as described above.

[0284] In step 1614, the F1 donor CU 801 may receive a message indicating completion of the MT migration of the IAB node from the source non-F1 donor CU 802. For example, the source non-F1 donor CU 802 may send the MT handover complete message 1515, as described above. As an alternative step, the F1 donor CU 801 may detect the completion of the MT migration through a message exchange with the source non-F1 donor CU 802 or the target non-F1 donor CU 803.

[0285] In step 1615, the F1 donor CU enables the initiation of the DU migration procedure for the IAB node.

[0286] 17 is a schematic and simplified diagram 1700 illustrating an example message flow in some embodiments for avoiding the initiation of successive MT migrations of an IAB node during DU migration of that IAB node. Successive MT migrations may include multiple MT migrations between different parent IAB nodes that are directly or indirectly connected to different donor DUs managed by the same donor CU, but where those donor CUs are different from the donor CU that provides the DU of the IAB node. Successive MT migrations may also be new MT migrations between different parent IAB nodes that are managed by different donor CUs that are different from the donor CU that provides the DU of the IAB node.

[0287] 17 shows a non-F1 terminated donor CU (or non-F1 donor CU) 1705 terminating an RRC connection to an IAB node (not shown), which may be a mobile IAB node such as IAB node 870 or IAB node 123 in FIGS. 8 and 1, a source F1 terminated donor CU (or F1 donor CU) 1704 terminating an F1 connection to the IAB node, and a target F1 donor CU 1706 that is to become the new F1 terminated donor CU for the IAB node. For example, referring to the IAB communication system of FIG. 8, the source F1 terminated donor CU 1704 for the IAB node is donor CU 801, and MT 871 of IAB node 870 has migrated to IAB topology 8002 managed by donor CU 802, and therefore, non-F1 terminated donor CU 1705 is donor CU 802. As the IAB node moves toward the IAB topology 8003, this topology is identified as a target IAB topology to which the DU 872 of the IAB node 870 may be migrated (e.g., for load balancing purposes). Thus, the target F1 termination donor CU 1706 is the donor CU 803.

[0288] The DU migration procedure of an IAB node may be performed according to the following procedure: When a source F1 donor CU of an IAB node decides or determines to perform a DU migration to another IAB topology managed by another donor CU, the donor CU becomes a target F1 donor CU. The first step corresponds to sending a request to the IAB node to establish a new F1 connection between the target F1 donor CU and the IAB node. As described above, the source F1 donor CU of an IAB node may decide to perform a DU migration for the purpose of reducing processing load or because the IAB node is geographically distant from the source F1 donor CU and is close to an area where no Xn or IP connection exists between the source F1 donor CU and the target F1 donor CU. For example, referring to FIG. 8 , the source F1 donor CU of IAB node 870 is donor CU 801, which decides to perform DU migration of IAB-DU 872 of IAB node 870 to IAB topology 8003, with donor CU 803 becoming the target F1 donor CU. In this case, a message is required to be sent from the source F1 donor CU to the IAB node to activate a second logical DU entity in the mobile IAB node. Thus, once the second logical DU entity is activated in the IAB node, the IAB node has two logical DU entities that share common hardware for the BAP, RLC, and MAC layers. In one example, both share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. Each logical DU entity serves one or more cells. The cell of the first logical DU entity is identified by an identifier (e.g., Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)) having a different value than another logical DU entity (e.g., a second logical DU). After activation, the second logical DU of the IAB node may send an F1 Setup Request message to the target F1 donor CU to request the establishment of an F1 connection between the IAB node and the target F1 donor CU.In the F1 setup response, the target F1 donor CU may request a new cell activation from the second logical DU of the IAB node, and may notify the source F1 donor CU about the new cell activation.

[0289] The next step is handover of the UE served by the IAB node from the cell of the first logical DU of the IAB node to the cell of the second logical DU. The target F1 donor CU may request the core network to perform a path switching procedure and deliver user data related to the UE via the second logical DU. The target F1 donor CU must then configure a backhaul path to / from the migrated IAB node. This configuration may be performed within the IAB topology managed by the target F1 donor CU, if a backhaul path exists within that topology, or via the IAB topology of the non-F1 donor CU. In the latter case, the target F1 donor CU may trigger a traffic migration request procedure to the non-F1 donor CU of the IAB node. Once the handover of all UEs served by the first logical DU of the IAB node is complete, the source F1 donor CU may deactivate the first logical DU of the mobile IAB node. The source F1 donor CU may also release traffic (user traffic, control traffic) related to the UE that was provided via the first logical DU. If the traffic was offloaded into an IAB topology managed by another donor CU (i.e., a non-F1 donor CU), the source F1 donor CU may apply a procedure to request the non-F1 donor CU to release the traffic.

[0290] According to the above description, it appears that the DU migration procedure may fail or be interrupted at various steps if an IAB node's MT migration is performed during the DU migration. Indeed, an IAB node's MT migration may involve setting up a new backhaul path through the new IAB topology, which may result in packet loss before all IAB donor CUs are notified of the change. As a safe approach to avoid service interruptions for UEs served by an IAB node, the DU migration should be performed and completed while connected to the co-located IAB donor CU.

[0291] To prevent the triggering of MT migration (starting with MT handover) during the DU migration procedure of the IAB node, the source F1 donor CU 1704 sends a DU migration notification to the non-F1 donor CU 1705, indicating that the DU of the IAB node is to be migrated to the IAB topology managed by the target F1 donor CU 1706. The DU migration notification may be included in a DU migration notification (or IAB node migration request) message 1712 sent to the non-F1 donor CU 1705. The message 1712 may be sent before the first step of the DU migration procedure (i.e., activation of the second logical DU in the IAB node). For example, the message 1712 may be sent before the execution of the migration of the DU of the IAB node (i.e., before the implementation of the DU migration procedure / process).

[0292] The message 1712 may include identifiers of IAB nodes recognized by the two donor CUs (the source F1 donor CU 1704 and the non-F1 donor CU 1705) and may further include an identifier of the target F1 donor CU 1706. Thus, the DU migration notification includes IAB node identification information for identifying the IAB node having the DU to be migrated. The identification information may include an identifier of at least one IAB node. Such identifiers may include identifiers known to the F1-terminated donor CU and non-F1-terminated donor CU of the IAB node. For example, the message may include one or more information elements: an F1-terminated IAB donor UE XnAP ID and a non-F1-terminated IAB donor UE XnAP ID, or an RRC-terminated IAB donor UE XnAP ID and a BAP address assigned to the IAB node. The identification information (or identifier) ​​of the target non-F1 donor CU 1706 may include a PCI or NCGI for the target cell of the target IAB topology to which the DU is to be migrated.

[0293] Upon receipt of this message 1712, the non-F1 donor CU 1705 may disable execution of MT handover for this IAB node in operation 1710. For example, the non-F1 donor CU 1705 may disable initiation of the MT migration process for the MT of the IAB node (e.g., including disabling MT handover that is part of the MT migration process). If message 1712 indicates that the target F1 donor CU for the DU migration matches the target non-F1 donor CU for the handover of the co-located MT of the IAB node (e.g., if the DU and MT are migrated to the same donor CU), the non-F1 donor CU 1705 may not disable MT migration because the target non-F1 donor CU (and therefore the target F1 donor CU) can process MT migration and DU migration simultaneously. However, MT handovers to other target non-F1 donor CUs (e.g., donor CUs different from the donor CU to which the DU is migrated) are disabled.

[0294] The non-F1 donor CU 1705 may then respond to the source F1 donor CU 1704 by sending a DU migration response (or IAB node migration response) message 1713. The source F1 donor CU 1704 may wait to start executing the DU handover procedure 1714 until it receives this confirmation message 1713. For example, after receiving the DU migration response in message 1713, the source F1 donor CU 1704 may perform the migration of the DU of the IAB node.

[0295] If an MT migration procedure for the IAB node is in progress at the time of receipt of the DU migration notification message 1712, the non-F1 donor CU 1705 may wait until this ongoing MT migration procedure is complete before sending the DU migration response message 1713. Alternatively, the non-F1 donor CU 1705 may send a DU migration response (or IAB node migration reject) message 1713 indicating that the DU migration has been rejected, and the message 1713 may include the cause of the rejection.

[0296] After the DU migration operation 1714 is completed, the source F1 donor CU 1704 may send a DU migration completion message 1715 to the non-F1 donor CU 1705 to indicate that the migration of the DU is complete. The message 1715 includes identifiers of IAB nodes recognized by the two donor CUs (the source F1 donor CU 1704 and the non-F1 donor CU 1705) and may further include the identifier of the target F1 donor CU 1706.

[0297] After receiving the DU migration complete message 1715, the non-F1 donor CU 1705 may re-enable the MT migration process (e.g., including enabling MT handover, which is part of the MT migration process) for the IAB node in operation 1720.

[0298] In the DU migration procedure, a non-F1 donor CU 1705 may be involved at some point, and the source F1 donor CU 1704 may release traffic that has been migrated toward the IAB topology controlled by the non-F1 donor CU 1705, or the target F1 donor CU 1706 may request traffic migration to the IAB topology controlled by the non-F1 donor CU 1705. Therefore, message 1715 is not necessarily required, and operation 1720 may also be triggered after sending an IAB transport migration response to the source F1 donor CU 1704 or the target F1 donor CU 1706.

[0299] According to one example, the DU migration notification message 1712 may be a HANDOVER REQUEST message as specified in TS 38.423 V17.2.0 Section 9.1.1.1, with a new information element added to indicate that the DU migration of the IAB node is a notification performed between a source F1 donor CU and a target F1 donor CU. This message may include identifiers of the associated IAB nodes recognized by the two donor CUs (the source F1 donor CU that sends the message and the non-F1 donor CU that receives the message) and may further include the identifier of the target F1 donor CU in addition to other information elements included in messages specified in TS 38.423. The DU migration response message 1713 may be a HANDOVER REQUEST ACKNOWLEDGE message as specified in TS 38.423 V17.2.0 Section 9.1.1.2, with a new information element added to indicate that this is an acknowledgment of the DU migration. If the migration is rejected, the response message 1713 may be the HANDOVER PREPARATION FAILURE message of section 9.1.1.3, with new information elements indicating the rejection of the DU migration and the reason (eg, load problems).

[0300] According to another example, the DU migration notification message 1712 may be an NG-RAN NODE CONFIGURATION UPDATE message as specified in TS 38.423 V17.2.0 Section 9.1.3.4, and may include an information element indicating that it is a DU migration notification for an IAB node, including an identifier associated with the IAB node that is known by both the source F1 donor CU sending the message and the non-F1 donor CU receiving the message, and may include an identifier of the target F1 donor CU in addition to other information elements as specified in TS 38.423. Alternatively, the DU migration response message 1713 may be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message as specified in Section 9.1.3.5 of TS 38.423 V17.2.0, and may include a new information element indicating that the message is an acknowledgement response for the DU migration of the IAB node (the DU migration is performed between a source F1 donor CU and a target F1 donor CU). In the case of a rejection of the DU migration, the DU migration response message 1713 may be an NG-RAN NODE CONFIGURATION UPDATE FAILURE message as specified in Section 9.1.3.6 of TS 38.423 V17.2.0, and may include a new information element indicating that the message is a rejection of the DU migration of the IAB node (for example, including a rejection cause due to load).

[0301] As yet another example, the DU migration notification message 1712 may be a MOBILITY CHANGE REQUEST message as defined in TS 38.423 V17.2.0 Section 9.1.3.22, with a new information element added to indicate that the DU migration of the IAB node is a notification performed between a source F1 donor CU and a target F1 donor CU. This message may include identifiers of the associated IAB nodes recognized by the two donor CUs (the source F1 donor CU that sends the message and the non-F1 donor CU that receives the message) and may further include the identifier of the target F1 donor CU in addition to other information elements included in messages defined in TS 38.423. The DU migration response message 1713 may be a MOBILITY CHANGE ACKNOWLEDGE message as defined in Section 9.1.3.23, with a new information element added to indicate that this is an acknowledgment of the DU migration of the IAB node. If the DU migration is rejected, the DU migration response message 1713 may be a MOBILITY CHANGE FAILURE message as specified in Section 9.1.3.24 and may have a new information element containing the cause of the rejection (e.g., load problem).

[0302] 18a is a flowchart of an example method 1800 according to one or more embodiments of the present invention for managing, in a first IAB donor CU (e.g., an F1 terminating donor CU managing or controlling a first IAB topology), a DU migration of an IAB node so as not to conflict with successive MT migrations of the IAB node. The successive MT migrations of the IAB node may include MT migrations of the IAB node from a first parent IAB node to a second parent IAB node belonging to a second IAB topology managed or controlled by a second IAB donor CU (e.g., a non-F1 terminating donor CU). In one example, a first parent IAB node routes data related to the IAB node using a first backhaul path including a first IAB donor DU of a second IAB topology managed by a second IAB donor CU, and a second parent IAB node routes similar data using a second backhaul path including a second IAB donor DU of the second IAB topology (e.g., migration between different donor DUs within the same topology). In this case, the source non-F1 donor CU may choose to apply an intra-CU topology adaptation procedure for the IAB node, as described with respect to FIG. 6. In another example, the second parent IAB node may be part of a third IAB topology managed by a third IAB donor CU. In this case, the continuous MT migration of the IAB node is directed to a target IAB topology that is different from the IAB topology managed by the first IAB donor CU (e.g., F1 termination donor CU) of the IAB node (e.g., the target IAB topology is not the IAB topology managed by the F1 termination donor CU of the IAB node).

[0303] 8, when a first IAB donor CU performs method 1800, the IAB donor CU may be an IAB donor CU 801 that is an F1-terminated donor CU of an IAB node 870 (e.g., the mobile IAB node 870 maintains an F1 connection). The IAB node is a mobile IAB node 870 that belongs to an IAB topology 8001 controlled by the IAB donor CU 801, and the migrated MT is controlled by an IAB donor CU 802 (e.g., a non-F1-terminated donor CU that has an RRC connection with the mobile IAB node 870). The migration process includes migrating a DU 872 of the IAB node 870 from the IAB donor CU 801 acting as a source F1-terminated donor CU to the IAB topology 8003 controlled by an IAB donor CU 803 acting as a target F1-terminated donor CU. In Figure 17, the non-F1 terminating donor CU is designated by reference numeral 1705, the F1 terminating donor CU is designated by reference numeral 1704, and the target F1 terminating donor CU is designated by reference numeral 1706. The method 1800 shown in and described with respect to Figure 18a may be performed by software and / or hardware elements. The source F1 terminating IAB donor CU may be implemented in the communications device 400 shown in and described with respect to Figure 4, and the method shown in and described with respect to Figure 18a is performed by an apparatus of the F1 terminating IAB donor CU that includes one or more processing units, such as central processing unit 411.

[0304] In step 1801, a source F1-terminating donor CU (or source F1-donor CU), e.g., donor CU 801, of an IAB node (e.g., IAB node 870) determines that a DU 872 of the IAB node 870 should be migrated to a target topology (e.g., IAB topology 8003) managed by a target F1-terminating donor CU (or target F1-donor CU) 803. At this time, a MT 871 of the IAB node has already been migrated to a non-F1-terminating donor CU (or non-F1-donor CU) 802.

[0305] In step 1802, the source F1 donor CU 801 sends a DU migration notification message to the non-F1 donor CU, identifying the IAB node 870. For example, the source F1 donor CU 801 sends a DU migration notification indicating that the DU 872 of the IAB node 870 will be migrated. The DU migration notification includes identification information for identifying the IAB node having the DU to be migrated. The DU migration notification may be included in the DU migration notification (or IAB node migration request) message 1712, as described above. The source F1 donor CU 801 may send the DU migration notification before performing the migration of the DU of the IAB node, as described with reference to FIG. 17 and the sending of message 1712.

[0306] In step 1803, the source F1 donor CU 801 may receive a DU migration response message from the non-F1 donor CU 802 as a response to the DU migration notification message of step 1802. The DU migration response may be included in the DU migration response (or IAB NODE MIGRATION RESPONSE) message 1713, as described above. In step 1804, the source F1 donor CU 801 performs a DU migration procedure for the IAB node 870. For example, after receiving the DU migration response (or IAB NODE MIGRATION RESPONSE) message 1713, the source F1 donor CU 801 performs the DU migration procedure / process.

[0307] In step 1805, the source F1 donor CU 801 may send a message to the non-F1 donor CU 802 indicating that the DU migration of the IAB node 870 is complete. For example, the source F1 donor CU 801 may send the DU migration complete message 1715, as described above.

[0308] 18b is a flowchart of an example method 1810 according to one or more embodiments of the present invention for managing MT migration (including handover) of an IAB node from a first IAB topology managed by a first IAB donor CU (e.g., an F1 terminating donor CU) to a third IAB topology managed by a third IAB donor CU (e.g., a target F1 terminating donor CU) during DU migration of the IAB node in a second IAB topology managed by a second IAB donor CU (e.g., a non-F1 terminating donor CU). The method 1810 is performed in the second IAB donor CU (e.g., the non-F1 terminating donor CU). The method includes disabling initiation of MT migration (e.g., including MT handover) of the IAB node at the non-F1 terminating donor CU during DU migration of the IAB node.

[0309] For example, with respect to the IAB communication system shown in and described with respect to FIG. 8, the second IAB donor CU performing method 1810 may be IAB donor CU 802 (e.g., a non-F1 terminated donor CU of IAB node 870) (the IAB node 870 has an RRC connection). The IAB node may be a mobile IAB node 870 belonging to an IAB topology 8001 controlled by IAB donor CU 801. Thus, in this case, the first IAB donor CU is IAB donor CU 801, and the first IAB topology is IAB topology 8001. The third IAB donor CU is IAB donor CU 803. In FIG. 17, the non-F1 terminated donor CU is indicated by reference numeral 1705, the F1 terminated donor CU is indicated by reference numeral 1704, and the target F1 terminated donor CU is indicated by reference numeral 1706. The method 1810 shown in and described with respect to Figure 18b may be performed by software and / or hardware elements. The non-F1 terminated IAB donor CU may be implemented in the communication device 400 shown in and described with respect to Figure 4, and the method shown in and described with respect to Figure 18b may be performed by an apparatus of the non-F1 terminated IAB donor CU that includes one or more processing units, such as the central processing unit 411.

[0310] In step 1811, the IAB donor CU 802 as a non-F1 terminating donor CU (or non-F1 donor CU) receives a DU migration notification of the IAB node 870 from a source F1 terminating donor CU (or source F1 donor CU) of the IAB node 870 toward a target F1 terminating donor CU (or target F1 donor CU) that manages a target topology (e.g., IAB topology 8003). The source F1 donor CU may be the IAB donor CU 801, and the target F1 donor CU may be the IAB donor CU 803. Therefore, the non-F1 donor CU 802 receives a DU migration notification indicating that the DU 872 of the IAB node 870 is to be migrated toward the third IAB topology 8003. This DU migration notification includes identification information identifying the IAB node having the DU to be migrated. The DU migration notification may be included in the DU migration notification (or IAB NODE MIGRATION REQUEST) message 1712 described above.

[0311] In step 1812, the non-F1 donor CU 802 disables initiating the MT migration procedure / process (starting with MT handover) for the IAB node. For example, the non-F1 donor CU 802 disables initiating the MT migration process until the migration process for the MT of the IAB node is completed.

[0312] The non-F1 donor CU 802 may activate the initiation of a migration process for the MT of the IAB node after the DU of the IAB node has been migrated to the third IAB topology (e.g., after the migration process of the DU of the IAB node has been completed) (step 1815). The non-F1 donor CU 802 may determine that the DU of the IAB node has been migrated to the third IAB topology (e.g., the migration process of the DU of the IAB node has been completed), as referenced in step 1814 described below.

[0313] In step 1813, the non-F1 donor CU 802 may send a DU migration response message to the source F1 donor CU 801 in response to the DU migration notification message of step 1811. The DU migration response may be included in the DU migration response (or IAB node migration response) message 1713, as described above.

[0314] In step 1814, the non-F1 donor CU 802 may receive a message from the source F1 donor CU 801 indicating that the migration of the DU of the IAB node has been completed. For example, the source F1 donor CU 801 may send a DU migration completion message 1715 as described above. As an alternative step, the non-F1 donor CU 802 may detect the completion of the DU migration through a message exchange with the source F1 donor CU 801 or the target F1 donor CU 803 at the end of the DU migration process.

[0315] In step 1815, the non-F1 donor CU may activate a migration process for the MT of the IAB node (eg, including activating an MT handover as part of the MT migration process).

[0316] The procedure described with reference to FIG. 15 can be used alone without the procedure described with reference to FIG. 17. Conversely, the procedure described with reference to FIG. 17 can be used alone without the procedure associated with FIG. 15. Furthermore, both procedures can be used complementary to one another. MT migration may be required to avoid service interruptions due to poor radio quality and therefore may take priority over DU migration. Therefore, if the MT handover notification message 1512 and the DU migration notification message 1712 are generated simultaneously or nearly simultaneously, the F1 donor CU 1504 / 1704 should cancel the DU migration upon receipt of the message 1512 or wait for an acknowledgement message 1713 from the non-F1 donor CU 1505 / 1705, indicating to the IAB node that the non-F1 donor CU has acknowledged that the DU migration should be performed between the source F1 donor CU and the target F1 donor CU.

[0317] As described above with respect to Figures 15-18, sending an MT migration notification and / or a DU migration notification provides a relatively simple way to perform and complete an MT migration with a co-located DU still connected to the same donor, or to perform and complete a DU migration with a co-located MT still connected to the same donor, which helps reduce the possibility of failure of at least one migration procedure and avoids complex signaling.

[0318] In other words, in summary, performing a mobile IAB-MT (mIAB-MT) migration simultaneously with a co-located mobile IAB-DU (mIAB-DU) may result in at least one procedure failure or significantly increase signaling complexity. As a safeguard, mIAB-MT migration should be performed and completed with the co-located mIAB-DU connected to the same donor CU, and mIAB-DU migration should also be performed and completed with the co-located mIAB-MT connected to the same donor CU.

[0319] To avoid simultaneous execution of IAB-MT and mIAB-DU migrations, one donor CU should manage the order of mIAB-MT and mIAB-DU migrations for a mobile IAB node. On the one hand, the donor CU providing the mIAB-DU decides whether to perform the mIAB-DU migration, and on the other hand, the donor CU providing the mIAB-DU is notified of the mIAB-MT handover. Therefore, it seems appropriate for the donor CU providing the mIAB-DU to manage the order. Furthermore, the donor CU providing the mIAB-DU can directly exchange Xn IAB Transport Migration messages with the target donor CU, allowing it to know when the mIAB-MT migration is complete.

[0320] Therefore, it is determined that the donor CU suitable for managing the migration order of the IAB-MT and IAB-DU of the mobile IAB node is the F1 terminating donor CU of the IAB node.

[0321] Therefore, when the non-F1 terminating donor CU or the RRC terminating donor CU of the mobile IAB node determines that it is necessary to perform migration of the mobile IAB-MT to connect the mobile IAB-MT to the target non-F1 terminating donor CU, the non-F1 terminating donor CU should cause the F1 terminating donor CU to trigger the migration of the mIAB-MT at the appropriate time.

[0322] Therefore, it is proposed that the non-F1 terminating donor CU of the mobile IAB node should trigger the F1 terminating donor CU to migrate the mIAB-MT between different donors at the appropriate time.

[0323] As a method for controlling the sequence, a non-F1 terminal donor CU that determines that mIAB-MT migration is necessary to connect the mIAB-MT to a target non-F1 terminal donor CU can first notify the F1 terminal donor CU, which then triggers mIAB-MT migration between different donors at the appropriate time and responds to the non-F1 terminal donor CU.

[0324] Analysis of the impact of simultaneous MT handover and DU migration for a mobile IAB node reveals that if a mobile IAB-DU migration occurs simultaneously with a mobile IAB-MT handover, the DU migration may fail because the backhaul path for communication with the IAB node may change. Depending on when the original backhaul path between the mobile IAB node and the source non-F1 terminating donor CU becomes unavailable, the F1 setup procedure or UE handover procedure for the DU migration is likely to fail at some point. On the other hand, simultaneous co-located mobile IAB-DU migration does not affect the mobile IAB-MT (mIAB-MT) handover.

[0325] As a safety measure, mIAB-DU migration should be performed and completed while the co-located mIAB-MT is connected to the same donor CU. However, given the need to not delay the mIAB-MT handover, maintain backhaul connectivity, and prevent service interruptions for the served UE, it is possible to trigger a mIAB-MT handover even while a mIAB-DU migration is in progress. This allows for the suppression of triggering a mIAB-DU migration when a co-located mIAB-MT handover is in progress, thereby limiting the occurrence of simultaneous MT handovers and DU migrations.

[0326] Therefore, when the non-F1 terminating donor CU of the mobile IAB node determines that a handover of the mIAB-MT needs to be performed, the non-F1 terminating donor CU can immediately notify the F1 terminating donor CU.

[0327] Therefore, it is proposed that the non-F1 terminating donor CU of the mobile IAB node notifies the F1 terminating donor CU before performing the MT handover of the mobile IAB node.

[0328] Thereafter, the F1 terminating donor CU may not activate the execution of DU migration for the mobile IAB node until the handover process of the co-located mIAB-MT is completed.

[0329] The aforementioned features allow for effective separation of mIAB-MT handover and mIAB-DU migration.

[0330] Although the present invention has been described with reference to embodiments and examples, it should be understood that the present invention is not limited to the disclosed embodiments and examples. 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.

[0331] 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.

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

[0333] 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 a computer-readable medium.

[0334] 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 mobile termination (MT) of an integrated access backhaul (IAB) node migrates from a first parent IAB network node to a second parent IAB network node, the IAB node being managed by a first IAB donor central unit (CU) of a first IAB topology, and the first and second parent IAB network nodes being managed by a second IAB donor CU of a second IAB topology, the method comprising: transmitting to the first IAB donor CU path information associated with one or more routing paths in the second IAB topology, the path information being used to route data associated with the IAB node through the second parent IAB network node.

2. receiving, from the second IAB donor CU, path information associated with one or more routing paths in the second IAB topology; The method of claim 1 further comprising:

3. the first parent IAB network node is a first parent IAB node connected to a first IAB donor distribution unit (DU), or a first IAB donor DU; the second parent IAB network node is a second parent IAB node connected to a second IAB donor DU or the second IAB donor DU, and the first and second IAB donor DUs are associated with the second IAB donor CU; The method according to claim 1 or 2.

4. The method of claim 3 , wherein the path information includes one or more addresses associated with the second IAB donor DU.

5. The method of claim 1 , further comprising the step of transmitting, to the first IAB donor CU, identification information including at least one identifier of the IAB node.

6. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated in a second IAB topology managed by a second IAB donor central unit (CU), wherein the IAB node is managed by a first IAB donor CU of a first IAB topology, the method comprising: determining that the MT of the IAB node is to be migrated from a first parent IAB network node to a second parent IAB network node, the first and second parent IAB network nodes being managed by a second IAB donor CU; transmitting to the first IAB donor CU path information associated with one or more routing paths in the second IAB topology used to route data associated with the IAB node through a second parent IAB network node.

7. The first parent IAB network node is a first parent IAB node connected to a first IAB donor distribution unit (DU), or a first IAB donor (DU); the second parent IAB network node is a second parent IAB node connected to a second IAB donor DU or a second IAB donor DU, and the first and second IAB donor DUs are associated with the second IAB donor CU; The method of claim 6.

8. The method of claim 7 , wherein the path information includes one or more addresses associated with the second IAB donor DU.

9. The method of claim 7 or 8, wherein the determining step includes identifying the second IAB donor DU as a target donor DU to which the MT of the IAB node is to be migrated.

10. transmitting, to the first IAB donor CU, identification information including at least one identifier of the IAB node; The method of any one of claims 6 to 9, further comprising:

11. transmitting configuration information including configuration parameters for each backhaul link associated with the IAB node in the one or more routing paths; The method of any one of claims 6 to 10, further comprising:

12. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a first parent IAB network node to a second parent IAB network node, the IAB nodes being managed by a first IAB donor central unit (CU), and the first and second parent IAB network nodes being managed by a second IAB donor CU, the method comprising: receiving path information associated with one or more routing paths in a second IAB topology managed by the second IAB donor CU, the path information being used to route data associated with the IAB nodes through the second parent IAB network node.

13. 13. The method of claim 12, wherein the receiving step includes receiving the path information from the IAB node.

14. 13. The method of claim 12, wherein the receiving step includes receiving the path information from the second IAB donor CU.

15. receiving configuration information including configuration parameters for each backhaul link associated with the IAB node in the one or more routing paths; The method of claim 14 further comprising:

16. The first parent IAB network node is a first parent IAB node connected to a first IAB donor distribution unit (DU), or a first IAB donor (DU); the second parent IAB network node is a second parent IAB node connected to a second IAB donor DU or a second IAB donor DU, and the first and second IAB donor DUs are associated with the second IAB donor CU; 16. The method of any one of claims 12 to 15.

17. 17. The method of claim 16, wherein the address information includes one or more addresses associated with the second IAB donor DU.

18. receiving identification information including at least one identifier of the IAB node; 18. The method of any one of claims 12 to 17, further comprising:

19. updating, at the first IAB donor CU, one or more routing paths used to route data associated with the IAB node through a second parent IAB network node based on the received information; 19. The method of any one of claims 12 to 18, further comprising:

20. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, the IAB node being managed by a first IAB donor CU that manages a first IAB topology, the method comprising: transmitting, to the first IAB donor CU, identification information for identifying the third IAB donor CU.

21. receiving from the third IAB donor CU one or more addresses associated with the target IAB donor DU of the third IAB topology, where data associated with the IAB node in the third IAB topology is routed through the target IAB donor DU; 21. The method of claim 20, further comprising: sending address information including the one or more addresses to the first IAB donor CU.

22. 22. The method of claim 21, wherein the address information and the identification information are transmitted by the IAB node in one message.

23. transmitting IAB node identification information including at least one identifier of the IAB node; 23. The method of any one of claims 20 to 22, further comprising:

24. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, the IAB node being managed by a first IAB donor CU that manages a first IAB topology, the method comprising: determining, by the MT of the IAB node, that data associated with the IAB node in a third IAB topology is migrated to a target IAB donor DU of a third IAB topology, where the data is routed via the target IAB donor DU; transmitting, to the first IAB donor CU, identification information for identifying the third IAB donor CU.

25. transmitting IAB node identification information including at least one identifier of the IAB node; 25. The method of claim 24 further comprising:

26. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, wherein the IAB node is managed by a first IAB donor CU that manages a first IAB topology, the method comprising: receiving address information including one or more addresses associated with the target IAB donor DU of the third IAB topology, where data associated with the IAB node in the third IAB topology is routed through the target IAB donor DU; receiving identification information to identify the third IAB donor CU.

27. 27. The method of claim 26, wherein the step of receiving address information includes receiving the address information from the IAB node.

28. 28. The method of claim 26 or 27, wherein the step of receiving identifying information includes receiving identifying information from the IAB node or the second IAB donor CU.

29. updating, at the first IAB donor CU, based on the received information, one or more routing paths used to route data associated with the IAB node through the target IAB donor DU; 29. The method of any one of claims 26 to 28, further comprising:

30. receiving IAB node identification information including at least one identifier of the IAB node; 30. The method of any one of claims 26 to 29, further comprising:

31. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, wherein the IAB node is managed by a first IAB donor CU that manages a first IAB topology, the method comprising: determining that the MT of the IAB node is to be migrated from the second IAB topology to the third IAB topology; and sending to the first IAB donor CU a handover request including identification information identifying the third IAB donor CU that manages the third IAB topology to which the MT of the IAB node is migrated.

32. sending, to the first IAB donor CU, IAB node identification information for identifying the IAB node having the MT to be migrated; 32. The method of claim 31 further comprising:

33. receiving, from the first IAB donor CU, a handover response including configuration information associated with one or more routing paths for routing data associated with the IAB node in the third IAB topology; transmitting the received configuration information to the IAB node; 33. The method of claim 31 or 32, further comprising:

34. the configuration information includes one or more addresses associated with the target IAB donor DU of the third IAB topology, through which data associated with the IAB node in the third IAB topology is routed; 34. The method of claim 33.

35. receiving a handover response from the first IAB donor CU; migrating the MT at the IAB node to the third IAB donor CU in response to the second IAB donor CU receiving a positive handover response indicating initiating migration of the MT at the IAB node; 33. The method of claim 31 or 32, further comprising:

36. 1. A method for use in a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node is migrated from a second IAB topology managed by a second IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, wherein the IAB node is managed by a first IAB donor CU that manages a first IAB topology, the method comprising: receiving a handover request from the second IAB donor CU requesting migration of an MT of the IAB node to the third IAB topology, the handover request including IAB node identification information for identifying the IAB node having the MT to be migrated and identification information for identifying the third IAB donor CU managing the third IAB topology; sending a handover response to the second IAB donor CU.

37. initiating migration of the MT of the IAB node to the third IAB donor CU; 37. The method of claim 36 further comprising:

38. The step of initiating the migration includes: sending a request to the third IAB donor CU to migrate the MT of the IAB node to a target cell of the third IAB topology; receiving a response from the third IAB donor CU, the response including configuration information associated with one or more routing paths for routing data associated with the IAB node in the third IAB topology; 38. The method of claim 37, comprising:

39. 39. The method of claim 38, wherein the handover response includes configuration information associated with one or more routing paths for routing data associated with the IAB node in the third IAB topology based on the configuration information received from the third IAB donor CU.

40. the configuration information includes one or more addresses associated with the target IAB donor DU of the third IAB topology, through which data associated with the IAB node in the third IAB topology is routed; 40. The method of claim 38 or 39.

41. determining whether a migration process has been initiated for a distributed unit (DU) of the IAB node; In response to determining that a migration process for the DU of the IAB node has been initiated, delaying initiation of migration of the MT of the IAB node to the third IAB donor CU until the migration process for the DU of the IAB node has been completed; 41. The method of any one of claims 37 to 40, further comprising:

42. 37. The method of claim 36, wherein the step of transmitting a handover response to the second IAB donor CU includes transmitting a positive handover response indicating that the second IAB donor CU will initiate migration of the MT of the IAB node.

43. determining whether a migration process has been initiated for a distributed unit (DU) of the IAB node; In response to determining that a migration process for the DU of the IAB node has been initiated, delaying sending a positive handover response until the migration process for the DU of the IAB node has been completed; 43. The method of claim 42 further comprising:

44. delaying the initiation of a migration process for the DU of the IAB node until the migration process for the MT of the IAB node is completed; 44. The method of any one of claims 36 to 43, further comprising:

45. setting up one or more routing paths for routing data associated with the IAB node in the third IAB topology based on the received configuration information; delaying the initiation of a migration process for the DU at the IAB node until the setup of the one or more routing paths is complete; 41. The method of any one of claims 38 to 40, further comprising:

46. determining whether a migration process has been initiated for a distributed unit (DU) of the IAB node; In response to determining that a migration process for the DU of the IAB node has been initiated, sending a handover response to the second IAB donor CU rejecting the handover request; 37. The method of claim 36 further comprising:

47. 1. A method for use in managing a migration process in which a mobile termination (MT) of an integrated access backhaul (IAB) node migrates from a first parent IAB node to a second parent IAB node of a second IAB topology managed by a second IAB donor central unit (CU), wherein the distribution unit (DU) of the IAB node is managed by a first IAB donor CU managing a first IAB topology, the method comprising: determining that the MT of the IAB node is to be migrated to a second parent IAB node; sending an MT migration notification to the first IAB donor CU indicating that an MT of an IAB node should be migrated to a second parent IAB node, the MT migration notification including IAB node identification information for identifying the IAB node having the MT to be migrated.

48. performing a migration of the MT of the IAB node to the second parent IAB node; the sending step includes sending the MT migration notification before the IAB node performs migration of the MT to the second parent IAB node; 48. The method of claim 47.

49. After the IAB node has completed the migration of the MT, sending a message to the first IAB donor CU indicating that the IAB node has completed the migration of the MT; 49. The method of claim 48, comprising:

50. receiving an MT migration response from the first IAB donor CU; 50. The method of any one of claims 47 to 49, comprising:

51. performing migration of the MT of the IAB node to the second parent IAB node after receiving the MT migration response; 51. The method of claim 50, comprising:

52. 1. A method for use in managing migration of a distributed unit (DU) of an integrated access backhaul (IAB) node during a mobile termination (MT) migration process in which the MT of the IAB node migrates from a first parent IAB node to a second parent IAB node of a second IAB topology managed by a second IAB donor central unit (CU), the DU of the IAB node being managed by a first IAB donor CU managing a first IAB topology, the method comprising: receiving, from the second IAB donor CU, an MT migration notification indicating that the MT of the IAB node should be migrated to a second parent IAB node, the notification including IAB node identification information for identifying the IAB node having the MT to be migrated; Disabling the IAB node from initiating a migration process for the DU; enabling initiation of a migration process for the DU of the IAB node after the MT of the IAB node has been migrated.

53. determining that the MT of the IAB node has migrated; the enabling step includes enabling initiation of a migration process for the DU of the IAB node in response to determining that the MT of the IAB node has been migrated.

53. The method of claim 52.

54. receiving a completion message from the second IAB donor CU indicating MT migration completion; the determining step includes determining that the MT of the IAB node has migrated based on the received completion message.

54. The method of claim 53.

55. In response to receiving the MT migration notification, sending an MT migration response to the second IAB donor CU; 55. The method of any one of claims 52 to 54, comprising:

56. the first parent IAB node includes a first backhaul path including a first IAB donor DU of the second IAB topology managed by the second IAB donor CU for routing data associated with the IAB node, and the second parent IAB node includes a second backhaul path including a second IAB donor DU of the second IAB topology for routing data associated with the IAB node; 56. A method according to any one of claims 47 to 49 and claims 52 to 55.

57. 56. The method of claim 47, wherein the second parent IAB node is part of a third IAB topology managed by a third IAB donor CU.

58. 58. The method of claim 57, wherein the MT migration notification further includes identification information for identifying the third IAB donor CU.

59. 1. A method for use in managing a migration process in which a distribution unit (DU) of an integrated access backhaul (IAB) node migrates from a first IAB topology managed by a first IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU that is a mobile termination (MT), wherein the mobile termination (MT) of the IAB node is managed by a second IAB donor CU that manages a second IAB topology, the method comprising: determining that the DU of the IAB node is to be migrated to the third IAB topology; sending a DU migration notification to the second IAB donor CU indicating that the DU of the IAB node is to be migrated to a third IAB topology, the notification including IAB node identification information identifying the IAB node having the DU to be migrated.

60. performing a migration of the DU of the IAB node to the third IAB topology; the transmitting step includes transmitting the DU migration notification before performing migration of the DU of the IAB node to the third IAB topology; 60. The method of claim 59.

61. After the IAB node has completed the migration of the DU, sending a completion message to the second IAB donor CU indicating that the IAB node has completed the migration of the DU; 61. The method of claim 60, comprising:

62. receiving a DU migration response from the second IAB donor CU; 62. The method of any one of claims 59 to 61, comprising:

63. performing migration of the DU of the IAB node to a third IAB topology after receiving the DU migration response; 63. The method of claim 62, comprising:

64. 64. The method of any one of claims 59 to 63, wherein the DU migration notification further includes identification information for identifying the third IAB donor CU.

65. 1. A method for use in managing the migration of a mobile termination (MT) of an integrated access backhaul (IAB) node during a distributed unit (DU) migration process in which a DU of the IAB node is migrated from a first IAB topology managed by a first IAB donor central unit (CU) to a third IAB topology managed by a third IAB donor CU, wherein the mobile termination (MT) of the IAB node is managed by a second IAB donor CU managing a second IAB topology, the method comprising: receiving a DU migration notification from the first IAB donor CU indicating that the DU of the IAB node will be migrated to the third IAB topology, the notification including IAB node identification information for identifying the IAB node having the DU to be migrated; Disabling the IAB node from initiating a migration process for the MT; enabling initiation of a migration process for the MT of the IAB node after the DU of the IAB node has been migrated.

66. determining that the DU of the IAB node has been migrated; the enabling step includes enabling the IAB node to initiate a migration process for the MT in response to determining that the DU of the IAB node has been migrated.

66. The method of claim 65.

67. receiving a completion message from the first IAB donor CU indicating completion of DU migration; The determining step includes determining that the DU of the IAB node has been migrated based on the received completion message.

67. The method of claim 66.

68. sending a DU migration response to the first IAB donor CU in response to receiving the DU migration notification; 68. The method of any one of claims 65 to 67, comprising:

69. The DU migration notification further includes identification information for identifying the third IAB donor CU.

69. The method of any one of claims 65 to 68.

70. the IAB node is a mobile IAB node; 10. A method according to any one of the preceding claims.

71. 1. An apparatus for an integrated access backhaul (IAB) node in an IAB communication system, comprising: Apparatus comprising one or more processing units configured to perform the method of any of claims 1 to 5, 20 to 23 and claim 70.

72. 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 6 to 19 and 24 to 70.

73. 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 70.

74. 74. A computer readable medium having recorded thereon the computer program of claim 73.

Images