Migration of nodes in IAB communication systems

Abstract

A method and apparatus for migration processing in which a mobile terminal (MT) integrating an access and 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 the first IAB topology, and the first parent IAB network node and the second parent IAB network node are managed by a second IAB donor CU of the second IAB topology. The method includes transmitting, at the IAB node, path information associated with one or more routing paths in the second IAB topology to be used to route data associated with the IAB node through the second parent IAB network node to the first IAB donor CU. The method comprises: at a second donor CU, determining that an MT as an IAB node is to migrate from a first parent IAB network node to a second parent IAB network node, the first parent IAB network node and the second parent IAB network node being managed by the second IAB donor CU; path information associated with one or more backhaul paths in a second IAB topology to be used to route data associated with the IAB node through a second parent IAB network node is transmitted to the first IAB donor CU.

Description

Technical Field

[0001] The present invention generally relates to methods used in the handling of migrating nodes and traffic in an integrated access and backhaul (IAB) communication system. In particular, the present invention relates to methods used in a migration process in which a mobile terminal (MT) migrates an IAB node (e.g., a mobile IAB node) in an IAB communication system. Background Art

[0002] Wireless communication systems have been widely deployed to address a wide range of applications from mobile broadband, massive machine type communication to ultra-reliable low latency communication (URLLC). Such systems allow multiple user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g., video, voice, messaging, …) over a radio access network (RAN) via one or more base stations. Traditionally, base stations are wired-connected (e.g., via optical fiber) to a core network, thus forming an intermediate network called backhaul (BH).

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

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

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

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

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

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

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

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

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

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

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

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

[0015] For a mobile IAB node, performing multiple MT migrations or DU migrations may be worthwhile because the connection to the parent IAB node belonging to the first IAB topology may not occur again for a long time as the mobile IAB node moves around, or may never occur again if the mobile IAB node moves away from the parent IAB node. In addition, for flexible IAB network management, MT and DU migrations should be de-correlated, which means that the DU migration for an IAB node can occur independently before or after one or several MT migrations of that IAB node. In addition, the DU migration for an IAB node can be directed towards an IAB donor different from the IAB donor associated with the MT of the same IAB node. However, performing an MT migration simultaneously with the migration of a co-located DU may cause at least one of the migration processes to fail during the migration process, or it may drastically increase the signaling complexity.

[0016] Therefore, some new mechanisms are needed to provide such flexibility by supporting multiple MT migrations of IAB nodes that are de-correlated from their DU migrations. Summary of the Invention

[0017] According to a first aspect of the present invention, there is provided a method for migration processing performed at an IAB node according to claims 1 to 5 in the appended claims, in which a mobile terminal (MT) of the IAB node migrates from a first parent IAB network node to a second parent IAB network node, the IAB node (e.g., the DU of the IAB node) is managed by a first IAB donor central unit (CU) of a first IAB topology, and the first parent IAB network node and the second parent IAB network node 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 for migration processing performed at a second IAB donor CU according to claims 6 to 11 in the appended claims, in which a mobile terminal (MT) of an IAB node migrates in a second IAB topology managed by a second IAB CU, and the IAB node (i.e., the DU of the IAB node) is managed by a first IAB donor CU of a first IAB topology.

[0019] According to a third aspect of the present invention, there is provided a method for handover processing performed at a first IAB donor CU according to claims 12 to 19 in the appended claims, in which a mobile terminal (MT) of an IAB node is handed over from a first parent IAB network node to a second parent IAB network node, the IAB node (i.e., the DU of the IAB node) is managed by the first IAB donor CU, and the first parent IAB network node and the second parent IAB network node are managed by a second IAB donor CU different from the first IAB donor CU.

[0020] Path information sent to the first IAB donor CU (e.g., the F1 terminating donor CU) can be used to inform the F1 terminating donor CU of one or more routing paths to be used for routing data to / from the IAB node (i.e., F1 data, including user traffic, control traffic) in different topologies, and the one or more routing paths are new routing paths when they include the new parent IAB network node. In the case where the handover between the parent IAB network nodes involves a new donor DU (e.g., when the new parent IAB network node is a new IAB donor DU or a parent IAB node (directly or indirectly) connected to the new IAB node DU), the one or more routing paths are used to route data associated with the IAB node through the new IAB donor CU.

[0021] According to a fourth aspect of the present invention, there is provided a method for handover processing performed at an IAB node according to claims 20 to 23 in the appended claims, in which a mobile terminal (MT) of the IAB node is handed over 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, and the IAB node (e.g., the DU of the IAB node) is managed by the first IAB donor CU for managing the first IAB topology.

[0022] According to an example, a method for handover processing is provided, in which a mobile terminal (MT) of an integrated access and 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 being managed by a first IAB donor CU for managing a first IAB topology. The method includes: at the IAB node, receiving, from the third IAB donor CU, one or more addresses associated with a target IAB donor DU of the third IAB topology, wherein data associated with the IAB node will be routed via the target IAB donor DU in the third IAB topology; and sending 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 sent to the first IAB donor CU (e.g., the address information and the identification information may be sent by the IAB node in one message). The IAB node may send 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 following: information element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and one or more (e.g., assigned by one or more RRC donor CUs) BAP addresses assigned to the IAB node.

[0023] According to a fifth aspect of the present invention, a method for handover processing at a second IAB donor CU according to claims 24 to 25 in the appended claims is provided, in which a mobile terminal (MT) of an 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 (i.e., the DU of the IAB node) being managed by a first IAB donor CU for managing a first IAB topology.

[0024] According to a sixth aspect of the present invention, there is provided a method for handover processing performed at a first IAB donor CU as claimed in claims 26 to 30 of the appended claims, in which a mobile terminal (MT) of an 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, and the IAB node (i.e., the DU of the IAB node) is managed by the first IAB donor CU for managing the first IAB topology.

[0025] Thus, using information (e.g., address information such as the address(es) of the third or target donor DU to which the IAB node is going to or has migrated, and / or identification information (such as PCI or NCGI, etc.) for identifying the third IAB donor CU) sent by the second IAB donor CU (non-F1 termination donor CU or RRC termination donor CU) or by the IAB node to the first IAB donor CU (F1 termination donor CU) of the IAB node, the F1 termination donor CU can be informed of the migration of the MT of the IAB node between two different topologies (e.g., from a second IAB topology managed by a second IAB donor central unit (CU) (e.g., source IAB donor CU) to a third IAB topology managed by a third IAB donor CU (e.g., target IAB donor CU)); and at least one new routing path to be used for routing data (e.g., F1 traffic, user traffic, and control traffic) for the migrated IAB node in the third IAB topology controlled by the target non-F1 termination donor CU or target RRC termination donor CU. Then, the F1 termination donor CU can update the 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 routing path and F1-U routing path) to new routing paths for routing data to / from the IAB node via the target donor DU.

[0026] Identity information including at least one identifier of the IAB node can be provided to the first IAB donor CU (F1-terminating donor CU): for example, the identity information can be provided by the IAB node or the second IAB donor CU (non-F1 / RRC-terminating donor CU). The at least one identifier of the IAB node can include one or more than one of the following: the information element F1-TerminatingIAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or the RRC-Terminating IAB-donor UE XnAP ID (assigned by the (one or more) RRC-terminating donor CUs) and the (one or more) BAP addresses assigned to the IAB node (e.g., the BAP addresses assigned by the (one or more) RRC-terminating donor CUs).

[0027] According to a seventh aspect of the present invention, there is provided a method for handover processing performed at a second IAB donor CU according to claims 31 to 35 in the appended claims, in which a mobile terminal (MT) of an IAB node is to be 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, and the IAB node (e.g., the DU of the IAB node) is managed by a first IAB donor CU for managing a first IAB topology.

[0028] According to an eighth aspect of the present invention, there is provided a method for handover processing performed at a first IAB donor CU according to claims 36 to 46 in the appended claims, in which a mobile terminal (MT) of an IAB node is to be 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, and the IAB node (e.g., the DU of the IAB node) is managed by a first IAB donor CU for managing a first IAB topology.

[0029] Thus, by using a handover request, the first donor CU (e.g., the F1-terminating donor CU) can be informed of the migration of the MT of the IAB node between two different topologies (e.g., from a second IAB topology managed by the second IAB donor CU (e.g., the source IAB donor CU) to a third IAB topology managed by the third IAB donor CU (e.g., the target IAB donor CU)).

[0030] The first IAB donor CU can initiate and execute the migration of the MT of the IAB node to the third IAB donor CU. Alternatively, the first IAB donor CU can initiate the MT migration to be performed by the second IAB donor CU.

[0031] In an example, the method further includes: determining whether a migration process for a distributed unit (DU) of the IAB node has been initiated; and in response to determining that the migration process for the DU of the IAB node has been initiated, delaying the migration of the MT of the IAB node to the third IAB donor CU (or delaying the initiation of the 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 is completed.

[0032] In another example, the method further includes: delaying 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, such as until the 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 an example, the method further includes: determining whether a migration process for a distributed unit (DU) of the IAB node has been initiated; and in response to determining that the migration process for the DU of the IAB node has been initiated, sending a handover response for rejecting the handover request to the second IAB donor CU.

[0034] According to a ninth aspect of the present invention, there is provided a method for managing a migration process at a second IAB donor CU according to claims 47 to 51 in the appended claims, in which a mobile terminal (MT) of an integrated access and backhaul (IAB) node is to migrate 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, and a distributed unit (DU) of the IAB node is managed by a first IAB donor CU for managing a first IAB topology.

[0035] According to a tenth aspect of the present invention, there is provided a method for managing the migration of a distributed unit (DU) of an integrated access and backhaul (IAB) node during a mobile terminal (MT) migration process at a first IAB donor CU according to claims 52 to 58 in the appended claims, in which the MT of the IAB node is to migrate 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, and the DU of the IAB node is managed by a first IAB donor CU for managing a first IAB topology.

[0036] According to an eleventh aspect of the present invention, there is provided a method for managing a handover process at a first IAB donor CU according to claims 59 to 64 in the appended claims, in the handover process, a distributed unit (DU) of an integrated access and backhaul (IAB) node is to be handed over 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 a mobile terminal (MT) of the IAB node is managed by a second IAB donor CU for managing a second IAB topology.

[0037] According to a twelfth aspect of the present invention, there is provided a method for managing the handover of a mobile terminal (MT) of an integrated access and backhaul (IAB) node during a distributed unit (DU) handover process at a second IAB donor CU according to claims 65 to 69 in the appended claims, in the DU handover process, the DU of the IAB node is to be handed over 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 a mobile terminal (MT) of the IAB node is managed by a second IAB donor CU for managing a second IAB topology.

[0038] By ensuring that the MT handover is completed before initiating the DU handover (e.g., delaying the initiation or start of the DU handover until the MT handover is completed, or disabling the initiation of the handover process for the DU of the IAB node until after the MT of the IAB node has been handed over), or by checking whether the DU handover has been initiated or started and, if this is the case, by delaying the MT handover until the completion of the DU handover or disabling the initiation of the handover process for the MT of the IAB node until the DU of the IAB node has been handed over, it is possible to avoid performing the MT handover simultaneously with the DU handover. Since performing the MT handover simultaneously with the handover of a co-located DU may result in the failure of at least one of the processes or it may significantly increase the signaling complexity, it is possible to avoid the failure and the increase in signaling complexity. To ensure a safe method, it is desirable to perform and complete the MT handover while the co-located DU remains connected to the same donor, and to perform and complete the DU handover while the co-located MT remains connected to the same donor.

[0039] In another aspect of the present invention, there is provided a method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul (IAB) node handovers from a first parent IAB network node associated with a first IAB donor distributed unit (DU) to a second parent IAB network node associated with a second IAB donor DU, the IAB node being managed by a first IAB donor central unit (CU) of a first IAB topology, and the first IAB donor DU and the second IAB donor DU being managed by a second IAB donor CU of a second IAB topology. The method includes: at the IAB node, sending address information including one or more addresses associated with the second IAB donor DU to the first IAB donor CU, wherein in the second IAB topology, data associated with the IAB node will be routed through the second IAB donor DU.

[0040] According to a thirteenth aspect of the present invention, there is provided an apparatus for an IAB node for use in an IAB communication system as claimed in the appended claims.

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

[0042] In all aspects, the IAB node may be a mobile IAB node.

[0043] Further example features of the present invention are described in other independent claims and dependent claims.

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

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

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

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

[0048] Figure 2 a of Figure 2 b schematically illustrates the stacks of some protocol layers involved in IAB operation;

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

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

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

[0052] Figure 6 is a schematic simplified diagram illustrating an exemplary message flow for supporting (one or more) (consecutive) MT migrations of an IAB node in an IAB topology controlled by a non-F1 terminated donor CU of the IAB node according to an embodiment of the present invention;

[0053] Figure 7a is a flowchart of an exemplary method for managing MT migrations of an IAB node in an IAB topology controlled by a non-F1 terminated donor CU or an RRC terminated donor CU of the IAB node according to one or more embodiments of the present invention;

[0054] Figure 7b is a flowchart of an exemplary method for managing MT migrations of an IAB node at a non-F1 terminated donor CU or an RRC terminated donor CU of the IAB node according to one or more embodiments of the present invention;

[0055] Figure 7c is a flowchart of an exemplary method for managing MT migrations of an IAB node in an IAB topology of a non-F1 terminated donor CU or an RRC terminated donor CU of the IAB node at an F1 terminated donor CU of the IAB node according to one or more embodiments of the present invention;

[0056] Figure 8 is a schematic diagram of another exemplary IAB communication system (or IAB network system) that can implement the embodiments and examples of the present invention;

[0057] Fig. 9It is a schematic simplified diagram illustrating an example message flow for performing continuous MT migration of a mobile IAB node towards a target IAB topology (including setting up a control data path) according to one or more embodiments of the present invention;

[0058] Fig.10 It is a schematic simplified diagram illustrating an example message flow for setting up a user data path used for continuous MT migration of a mobile IAB node towards a target IAB topology according to one or more embodiments of the present invention;

[0059] Fig.11 It is a schematic simplified diagram illustrating an example message flow for performing continuous MT migration of a mobile IAB node towards a target IAB topology after radio link failure (RLF) recovery of an IAB node according to one or more embodiments of the present invention;

[0060] Fig.12a It is a flowchart of an example method according to one or more embodiments of the present invention, the example method being used to manage continuous MT migration of an IAB node towards a target IAB topology different from an IAB topology controlled by its F1-terminated donor CU and its source non-F1-terminated donor CU or source RRC-terminated donor CU at the IAB node;

[0061] Figure 12b It is a flowchart of an example method according to one or more embodiments of the present invention, the example method being used to manage continuous MT migration of an IAB node towards a target IAB topology different from an IAB topology controlled by the F1-terminated donor CU of the IAB node at the source non-F1-terminated donor CU or source RRC-terminated donor CU of the IAB node;

[0062] Fig.12c It is a flowchart of an example method according to one or more embodiments of the present invention, the example method being used to manage continuous MT migration of an IAB node towards a target IAB topology different from an IAB topology controlled by the source non-F1-terminated donor CU or source RRC-terminated donor CU of the IAB node at the F1-terminated donor CU of the IAB node;

[0063] Fig.13 It is a schematic simplified diagram illustrating another example message flow for performing continuous MT migration of a mobile IAB node towards a target IAB topology (including setting up a control data path and a user data path) according to one or more embodiments of the present invention;

[0064] Fig.14ais a flowchart of an example method according to one or more embodiments of the present invention, the example method being for managing continuous MT migration of an IAB node towards a target IAB topology different from the IAB topology controlled by the F1-terminated donor CU of the IAB node at the source non-F1-terminated donor CU or the source RRC-terminated donor CU of the IAB node;

[0065] Fig.14b is a flowchart of an example method according to one or more embodiments of the present invention, the example method being for managing continuous MT migration of an IAB node towards a target IAB topology different from the IAB topology controlled by the source non-F1-terminated donor CU of the IAB node at the F1-terminated donor CU of the IAB node;

[0066] Fig.15 is a schematic simplified diagram illustrating an example message flow according to one or more embodiments of the present invention for avoiding initiating DU migration of an IAB node during continuous MT migration of the IAB node;

[0067] Fig.16a is a flowchart of an example method according to one or more embodiments of the present invention, the example method being for managing continuous MT migration of an IAB node towards a target IAB topology different from the IAB topology controlled by the F1-terminated donor CU of the IAB node at the source non-F1-terminated donor CU or the source RRC-terminated donor CU of the IAB node in a manner that does not compete with DU migration of the IAB node;

[0068] Fig.16b is a flowchart of an example method according to one or more embodiments of the present invention, the example method being performed at the F1-terminated donor CU of the IAB node and for managing DU migration of the IAB node during continuous MT migration of the IAB node;

[0069] Fig.17 is a schematic simplified diagram illustrating an example message flow according to one or more embodiments of the present invention for avoiding initiating continuous MT migration of an IAB node during DU migration of the IAB node;

[0070] Fig.18a is a flowchart of an example method according to one or more embodiments of the present invention as follows, the example method being for managing DU migration of an IAB node in a manner that does not compete with continuous MT migration of the IAB node at the source F1-terminated donor CU of the IAB node;

[0071] Fig.18bIt is a flowchart of an exemplary method according to one or more embodiments of the present invention, the exemplary method being for performing at a non-F1 terminated donor CU or a source RRC terminated donor CU of an IAB node, and for managing the MT migration of the IAB node during the DU migration of the IAB node. Detailed implementation

[0072] Figure 1 Illustrative example communication system 100, in particular a mobile radio communication system such as a fifth generation (5G) new radio (NR) system including a wireless integrated access and backhaul network supporting (one or more) mobile IAB nodes. Although embodiments of the present invention and examples of embodiments will be described below with respect to a 5G NR system, it will be understood that the present invention is not intended to be limited to 5G NR systems and can be used in any wireless communication system having mobile base stations. In particular, the following description mainly uses 5G-specific terms, but it should be understood that such terms are also applicable to elements or processes performing equivalent functions in other communication systems.

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

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

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

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

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

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

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

[0080] - TS 38.300 RAN Architecture (V17.2.0),

[0081] - TS 38.321 MAC Protocol (V17.2.0),

[0082] - TS 38.331 Radio Resource Control (RRC) Protocol (V17.2.0),

[0083] - TS 38.340 Backhaul Adaptation Protocol Layer (V17.2.0),

[0084] - TS 38.401 RAN Architecture (V17.2.0),

[0085] - TS 38.423 Xn Application Protocol (V17.2.0),

[0086] - TS 38.473 F1 Application Protocol (V17.2.0).

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

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

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

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

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

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

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

[0094] The F1 interface supports the exchange of signaling information between endpoints and the transfer of data to each endpoint. From a logical perspective, the F1 interface is a point-to-point interface between endpoints.

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

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

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

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

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

[0100] Figure 2 L1 and L2 on a represent the transport layer and the physical layer suitable for the medium in use, respectively.

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

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

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

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

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

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

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

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

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

[0110] 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 (which can be an access IAB node in the case where the upper layer packet comes from a UE) for upstream transmission), a BAP header with a BAP routing ID is constructed by the node according to the configuration table defined in 3GPP TS 38.340. This table is referred to as the downlink traffic to routing ID mapping configuration table in the IAB donor DU, or the uplink traffic to routing ID mapping configuration table in the initiating IAB node. In an intermediate IAB node, the BAP header fields have been specified in the BAP packet for forwarding.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0128] The memory may include:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0148] Assume that the mobile IAB node 570 initially has a single parent IAB node 520 through the backhaul link 5020, and the IAB node 570 belongs to the IAB topology 5001 controlled by the IAB donor CU 501. When the mobile IAB node 570 is moving and considering its proximity to the IAB topology 5002, especially when at Figure 5 the position shown, it is able to establish a wireless backhaul link 5030 with the IAB node 530. Such a backhaul link is possible for stationary IAB nodes, and such a backhaul link is very likely to occur for mobile IAB nodes such as the IAB node 570 moving in the direction of the IAB topology 5002 (as shown by the arrow 590 in Figure 5 ).

[0149] According to the IAB framework version 17, several scenarios are possible.

[0150] As a first scenario, as described in section 8.17.2 of TS 38.401 V17.2.0, a topology redundancy procedure can be applied, where dual connectivity is established for an IAB node 570 having two parent IAB nodes 520 and 530 belonging to two different IAB topologies.

[0151] Each IAB-DU and IAB donor DU supports wireless communication in (one or more) coverage areas of (one or more) cells referred to as (one or more) cells. In other words, each IAB-DU and IAB donor DU is associated with (one or more) cells. A wireless communication device (such as a UE or other IAB node, etc.) located within a cell can connect to the node (i.e., IAB-DU or IAB donor DU) serving the cell to communicate with other devices (e.g., other UEs, IAB nodes, a server providing access to the Internet, etc.) via that node. When the IAB node 570 is initially connected to a single IAB topology (e.g., IAB topology 5001), as defined in 3GPP TS 38.300, the MT part or unit MT 571 of the IAB node 570 periodically performs a cell search procedure to attempt to detect the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal) of neighboring cells. The IAB node 570 can report the presence of the cell to its donor CU 501 via a measurement report including the identifier of the new cell activated or controlled by the IAB node 530. The identifier of the cell also enables the identification of the IAB donor CU for managing the cell. Based on the analysis of the measurement report, the donor CU 501 can request the donor CU 502 to establish dual connectivity for the IAB node 570 with an additional connection via the IAB node 530. The donor CU 502 can accept the request and continue with the connection of the IAB node 570 according to the procedure described in section 10.2 of TS 37.340 V17.2.0. As a result, the IAB node 570, which still belongs to the IAB topology 5001, is now also connected to the IAB node 530 belonging to the IAB topology 5002, and the IAB node 570 can be referred to as a boundary node between the IAB topology 5001 and the IAB topology 5002. In fact, the IAB node 570 retains its F1 connection and RRC connection to the donor CU 501 (which can be referred to as the F1-terminating IAB-donor-CU), and the IAB node 570 has another RRC connection to the donor CU 502 (which can be referred to as the non-F1-terminating IAB donor CU). The IAB donor CU that terminates the RRC connection of the IAB node can be referred to as the RRC-terminating donor CU or RRC donor CU. The RRC-terminating donor CU can be an F1-terminating donor CU or a non-F1-terminating donor CU.

[0152] Since the IAB node or border node 570 is part of the IAB topology 5001 (from the perspective of the F1 connection), the IAB node or border node 570 is controlled (e.g., configured and managed) by the IAB donor CU 501 of the IAB topology 5001. Through the second RRC connection, the donor CU 502 assigns a second BAP address to be used for routing packets through the IAB topology 5002. Consequently, the IAB node 570 acting as a border node is assigned two BAP addresses: one BAP address for the IAB topology 5001 and one BAP address for the IAB topology 5002. Such a border node can help provide network path diversity by providing alternative routing paths through the IAB topologies 5001 and 5002.

[0153] In fact, the IAB donor CU 501 can utilize the dual connectivity of the IAB node 570 between the IAB topology 5001 and the IAB topology 5002 to balance the traffic load in the IAB topology 5001 by offloading or migrating some traffic (user traffic or control traffic) that was originally planned to be routed through the IAB nodes 510, 520, and the BH link 5020 to the IAB node 570. In the IAB communication system, all traffic communicated through the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Consequently, the offloaded or migrated traffic or backhaul traffic is F1 traffic and can include control traffic and user traffic. In this case, as described in Section 8.17.2 of TS 38.401 V17.2.0, the donor CU 501 triggers the IAB transmission migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0. For example, due to a load problem in the IAB topology 5002, the donor CU 502 can reject requests for some or all of the traffic to be migrated. Consequently, for example, traffic that was originally planned to be routed between the donor CU 501 and the IAB node 570 through a backhaul path (Path 1) including the donor DU 504, the IAB nodes 510, and 520 can be migrated or offloaded to a backhaul path (Path 2) including the donor DU 505 and the IAB node 530.

[0154] As a second scenario, the BH link or BH radio link 5020 may also experience radio link failures due to some accidental interference or shadowing phenomena. For this reason, the IAB node 570 may lose its connection with the IAB node 520 and declare a radio link failure (RLF) for the BH link 5020. Then, the IAB node 570 will attempt to re-establish a connection with the same or a different parent IAB node (or donor DU). Thus, for example, the IAB node 570 may attempt to join the IAB topology 5002 managed by the IAB donor CU 502 by leveraging the connection through the new parent IAB node 530 and the BH link 5030. In this case, as described in Section 8.17.4 of TS 38.401 V17.2.0, the inter-CU backhaul RLF recovery process can be applied, which enables the IAB node to be restored to another parent node under a different IAB donor CU when the IAB-MT of the IAB node declares a backhaul RLF. In such a process, the donor CU 502 sends a request to the donor CU 501 to retrieve the context of the IAB node 570. Based on the response from the donor CU 501, the donor CU 502 may accept the connection of the IAB node 570, and the IAB node 570 becomes a border node still belonging to the IAB topology 5001. In fact, the IAB node 570 retains the F1 connection to the donor CU1 (which can be referred to as the F1-terminated IAB donor CU), and the IAB node 570 has an RRC connection to the donor CU 502 (which can be referred to as the non-F1-terminated IAB donor CU or RRC-terminated donor CU or RRC donor CU).

[0155] Then, the IAB donor CU 501 may request the migration of the F1 traffic (user traffic and control traffic) related to the IAB node 570 towards the IAB topology 5002. In this case, the donor CU 501 triggers the IAB transmission migration management process specified in Section 8.5.2 of TS 38.423 V17.2.0. For example, due to the load problem in the IAB topology 5002, the donor CU2 502 may reject the request for some or all of the traffic to be migrated.

[0156] As a third scenario, the IAB node 570 can partially migrate towards the IAB topology 5002, which means that the MT 571 becomes connected to the donor CU 502, and thus the RRC connection migrates from the IAB donor CU 501 to the IAB donor CU 502. In fact, based on the measurement report provided by the IAB node 570, the donor CU 501 can detect that the IAB node 570 will have a better connection through the cell of the IAB node 530 belonging to the IAB topology 5002. Then, the donor CU 501 can trigger the IAB CU - to - CU topology adaptation process described in Section 8.17.3.1 of TS 38.401 V17.2.0. In this process, the donor CU 501 sends a handover request to the donor CU 502 with information for the donor CU 502 to establish an RRC connection with the IAB node 570. Based on this information, the donor CU 502 can accept the handover request and continue with the admission of the IAB node 570 (e.g., set up a connection with the IAB node 570) using its F1 connection with the donor CU 501 (i.e., the F1 - terminated donor CU) and its RRC connection with the donor CU 2502 (i.e., the non - F1 - terminated donor CU or RRC - terminated donor CU), and the IAB node 570 becomes a border node still belonging to the IAB topology 5001. This process can be applied after the topology redundancy process (the first scenario) has been carried out, or applied in advance before the connection between the IAB node 570 and the IAB node 520 is lost.

[0157] Then, the IAB donor CU 501 can request the migration of the backhaul or F1 traffic related to the IAB node 570 towards the IAB topology 5002. In this case, the donor CU 501 also triggers the IAB transmission migration management process specified in Section 8.5.2 of TS 38.423 V17.2.0. For example, due to load issues in the IAB topology 5002, the donor CU2 can reject the request for some or all of the traffic to be migrated.

[0158] In the case where the IAB node 570 has several (one or more than one) sub - IAB nodes, a similar CU - to - CU topology adaptation process applies as specified in Section 8.17.3.2 of TS 38.401 V17.2.0, where the donor CU 501 additionally configures the migrating node and the (one or more than one) sub - IAB nodes to correctly route the BAP packets.

[0159] In these scenarios, the IAB topology 5001 can be referred to as the source IAB network or source IAB topology, and the topology 5002 can be referred to as the target IAB network or target IAB topology. In addition, the donor CU 501 can be referred to as the source IAB donor CU or source donor CU, and the donor CU 502 can be referred to as the target IAB donor CU or target donor CU.

[0160] The result of the procedure applied in the second and third scenarios is the MT relocation (also referred to as partial relocation) of the IAB node 570. In the first scenario of establishing dual connectivity for the IAB node 570 with two parent IAB nodes 520 and 530, the MT remains connected to the source IAB node 520.

[0161] In all the three scenarios described above, the UE 580 remains connected to the donor CU 501 via the DU part or unit DU 572 of the mobile IAB node 570. In the case where the IAB node 570 has several (one or more than one) child IAB nodes, such child IAB nodes still belong to the IAB topology 5001 and are fully controlled by the donor CU 501 (via the F1 connection and the RRC connection).

[0162] When the IAB node 570 is still moving, it can be in a position where the backhaul link 5050 to the IAB node 550 can have better quality compared to the backhaul link 5030 to the IAB node 530. At a certain point in time, the IAB node 570 may also experience an RLF on the backhaul link 5030. Thus, the above three scenarios can be repeated, but this time considering the procedures within the CU. In fact, the donor CU 502 may have to handle:

[0163] - The intra-CU topology redundancy procedure described in section 8.2.4 of TS 38.401 V17.2.0, which results in the dual connectivity of the IAB node 570 with two parent IAB nodes 530 and 550,

[0164] - The intra-CU backhaul RLF recovery procedure described in section 8.2.5 of TS 38.401 V17.2.0, which results in the continuous MT relocation of the IAB node 570 with a new single parent IAB node 550, or

[0165] - The intra-CU topology adaptation procedure described in section 8.2.3.1 of TS 38.401 V17.2.0, which also results in the continuous MT relocation of the IAB node 570 with a new single parent IAB node 550.

[0166] For a case involving the MT migration of the IAB node 570 to the parent IAB node 550, the donor CU 502 has to switch from the first backhaul path including the donor DU 505 and the IAB node 530 to the second backhaul path (which includes the donor DU 506, the IAB nodes 540 and 550) to reach the IAB node 570, and has to inform the donor CU 501 to redirect its offloaded traffic (control traffic and user traffic) via the donor DU 506 instead of the donor DU 505. With dual connectivity, the donor CU 502 can still choose to maintain the first backhaul path via the donor DU 505 and the IAB node 530 to reach the IAB node 570, or switch to the second backhaul path via the donor DU 506 and the IAB nodes 540 and 550. When the donor CU 502 selects the second backhaul path, this case can also be considered as a consecutive MT migration for the IAB node 570, and the donor CU 501 has to be informed.

[0167] Examples of methods according to one or more embodiments of the present invention will now be described, which enable the F1 terminating donor CU of an IAB node (e.g., a mobile IAB node) to be informed of: the migration of the MT of the IAB node (e.g., consecutive MT migrations of the IAB node, where the MT migration is a new MT migration towards a new parent IAB node, where the new parent IAB node is managed by a donor CU different from the donor CU of the DU serving the IAB node, or is at least connected to a different donor DU (compared to the previous parent IAB node) managed by a donor CU different from the donor CU of the DU serving the IAB node, or is a new parent IAB node connected to the same donor DU) between IAB nodes in an IAB topology controlled by a non-F1 terminating donor CU or an RRC terminating donor CU of the IAB node; and at least one new routing path to be used for routing data (e.g., user traffic and control traffic, F1 traffic) associated with the migrated IAB node in the IAB topology controlled by the non-F1 terminating donor CU (e.g., to be used for routing data to / from the migrated IAB node or between the migrated IAB node and the F1 terminating donor CU in the IAB topology controlled by the non-F1 terminating donor CU). Although the following methods / devices will be mainly described with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The methods according to one or more embodiments of the present invention can be applicable to, for example, stationary IAB nodes at the edge of an IAB topology and near one or more IAB nodes in an adjacent IAB topology. The non-F1 terminating donor CU or non-F1 donor CU is also referred to as an RRC terminating donor CU or an RRC donor CU.

[0168] Figure 6FIG. 600 is a schematic simplified diagram illustrating some example message flows for supporting (multiple consecutive) (one or more) MT migrations of an IAB node in an IAB topology controlled by a non-F1 terminating donor CU of the IAB node. The multiple consecutive MT migrations involve multiple new MT migrations between different parent IAB nodes, where these different parent IAB nodes can be managed by a donor CU different from the donor CU of the DU of the serving IAB node, or are at least (directly or indirectly) connected to different donor DUs managed by a donor CU different from the donor CU of the DU of the serving IAB node, or (directly or indirectly) connected to the same donor DU.

[0169] The figure shows an IAB node 601, which can be a mobile IAB node such as Figure 5 IAB node 570 and / or Figure 1 IAB node 123. When the IAB node 601 is a mobile IAB node, the IAB node 601 includes a mobile terminal (MT) 603 (identified as IAB-MT) and a distributed unit (DU) 602 (identified as IAB-DU). The figure also shows a non-F1 terminating donor CU (or non-F1 donor CU) 604 that terminates the RRC connection to the IAB node 601 via the IAB-MT 603, and an F1 terminating donor CU (or F1 donor CU) 605 that terminates the F1 connection to the IAB node 601 via the IAB-DU 602. As an example and referring to Figure 5 the IAB communication system of, the F1 terminating donor CU 605 for the IAB node is donor CU 501, the MT 571 of IAB node 570 has migrated to the IAB topology 5002 managed by donor CU 502, and the non-F1 terminating donor CU 604 is donor CU 502.

[0170] At the start of flow 600, it is assumed that the control path (F1-C) and user path (F1-U) set by the F1 donor CU 605 to reach the IAB node 601 use one or several backhaul paths of the IAB topology controlled by a donor DU not shown in Figure 6 by the non-F1 donor CU 604. For example, referring to Figure 5 one such backhaul path can include donor DU 505 and IAB node 530.

[0171] Then, assuming that the MT 571 of the IAB node 570 migrates from the IAB node 530 to the new parent IAB node 550 (where both the IAB nodes 530 and 550 belong to the same IAB topology 5002 managed by the non-F1 terminating donor CU), the non-F1 donor CU 604 that receives the measurement report 611 from the IAB node 601 initiates the MT migration of the IAB node 601 as described above with reference to Figure 5 the above. In this example, the MT migration can be considered a continuous MT migration because the MT migration from the parent IAB node 530 to the parent IAB node 550 involves a migration between two different donor DUs (505, 506) managed by the donor CU 502, which is different from the donor CU 501 that manages the DU (DU 572) of the IAB node 570. Using the CU-internal topology adaptation process as an example to further illustrate Figure 6 the procedure 600.

[0172] The measurement report 611 is received by the non-F1 donor CU 604 via the F1 message UL RRC MESSAGE TRANSFER (UL RRC message transfer) (specified in TS 38.423) sent by the source parent IAB node of the IAB node 601 (e.g., Figure 5 the IAB node 530 in ) and embedded with the RRC message and the measurement report sent by the IAB-MT 603 to the DU part of the source parent IAB node. The measurement report is the result of the regular measurement by the IAB-MT 603 of the signals received from the serving cell and one or more target cells (such as the signal synchronization block (SSB) transmitted in the serving cell and the target cells, etc.). The target cell can be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). Once the IAB-MT 603 discovers at least one SSB that meets the predefined criteria (e.g., the received power exceeding the predefined threshold), a measurement report can be generated and transmitted to provide radio link quality information to different cells near the IAB node 601. The identification of each target cell is included in the measurement report to allow the non-F1 donor CU 604 to identify the target donor CU associated with each target cell.

[0173] Based on the received measurement report, the non-F1 donor CU 604 can detect that the IAB node 601 receives a radio signal with better quality from the target parent IAB node in the target cell compared to the source serving cell. With a target parent IAB node belonging to the same IAB topology as the source parent IAB node (e.g., Figure 5As an example, the non-F1 donor CU 604 may decide to apply the CU-internal topology adaptation procedure for the IAB node 601. Additionally, in this example, the target parent IAB node involves a new donor DU for routing packets (e.g., donor DU 506 instead of Figure 5 the donor DU 505 in). Although in this example, the migration involves migrating the MT of the IAB node 601 from the parent IAB node 530 connected to the donor DU 505 to the new parent IAB node 550 (although indirectly) connected to the new donor DU 506, it will be understood that the following (e.g., the CU-internal topology adaptation procedure) can also be applied in cases where the migration involves migrating the MT of the IAB node 601 from a parent IAB node to a new parent IAB node where both the old parent IAB node and the new parent IAB node are (directly or indirectly) connected to the same donor DU. In such cases, since the F1 donor CU may have to reconfigure the IAB node being migrated, it is still helpful to inform the F1 donor CU of such a migration. The non-F1 donor CU can use the IAB transport migration modification procedure as described below to inform the F1 donor CU.

[0174] After requesting the creation of a UE context for the IAB node 601 from the target parent IAB node (e.g., IAB node 550) (a procedure not represented in Section 8.2.4 of TS 38.423 V17.2.0 Figure 6 ), the non-F1 donor CU 604 sends an RRC reconfiguration message 612 to the IAB-MT 603 via an F1 message UE CONTEXT MODIFICATION REQUEST (UE context modification request) to the source parent IAB node, which will relay the RRC reconfiguration information embedded in this F1 message to the IAB node 601. Specifically, the RRC reconfiguration message 612 contains the (one or more) transport network layer (TNL) addresses (i.e., (one or more) IP addresses) for identifying the target donor DU for packet routing (e.g., data routing). In Figure 5 the example, the (one or more) addresses of the donor DU 506 replace the (one or more) addresses of the donor DU 505.

[0175] After the IAB node 601 performs a random access procedure towards 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 (via the target parent IAB node and an F1 message UL RRC MESSAGE TRANSFER embedded with the RRC reconfiguration complete information).

[0176] In the case of using in-CU topological redundancy or in-CU backhaul RLF recovery procedures, the exchange of messages will be slightly different, but in all cases, the identity of the target donor DU is provided to the IAB node 601 via a message such as message 612 (e.g., an RRC reconfiguration message).

[0177] The following part relates to the update of the routing path (such as F1 paths (F1-C and F1-U), etc.) between the IAB node 601 of the target donor DU and the F1 donor CU 605.

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

[0179] As a first option for informing the F1 donor CU 605 of the path information associated with one or more routing paths (e.g., backhaul paths) to be used for routing data associated with the IAB node through the new parent IAB node (this path information can inform the F1 donor CU 605 of the target donor D), the DU part of the IAB node 601 (IAB-DU 602) can send a DU configuration message 615 to the F1 donor CU 605. This message can be the F1 message gNB-DU CONFIGURATION UPDATE (gNB-DU configuration update) specified in section 9.2.1.7 of TS 38.473 V17.2.0, which includes the identity of the target donor DU for F1-C and F1-U traffic. This information has been known to the IAB node 601 since receiving message 612. The destination address of message 615 is the F1 donor CU 605, and when this IP packet is received by the target donor DU, this IP packet can be routed in the wired backhaul ( Figure 5 at 508) until the F1 donor CU 605.

[0180] By receiving the identity of the target donor DU, the F1 donor CU 605 can update its configuration (e.g., update the routing path associated with the IAB node based on the received information) to deliver F1 packets to the IAB node 601 via the target donor DU (e.g., donor DU 506). Then, the path (F1-C) used for updating the F1 control data is updated.

[0181] To complete the update of the path (F1-U) for F1 user data, the F1 donor CU 605 may initiate the IAB transmission migration management procedure specified in section 8.5.2 of TS 38.423 V17.2.0, where protocol messages (not represented in Figure 6 ) are exchanged between the F1 donor CU 605 and the non-F1 donor CU 604. The non-F1 donor CU 604 may provide a new configuration message (e.g., the BHRLC channel) to be used by the IAB node 601 to send user data packets in the IAB topology controlled by the non-F1 donor CU 604. Then, these configuration parameters may be provided by the F1 donor CU 605 to the IAB node 601 via an F1 message (e.g., using the BAP MAPPING CONFIGURATION message specified in section 9.2.9.1 of TS 38.473 V17.2.0).

[0182] As a second option for informing the F1 donor CU 605 of path information associated with one or more routing paths (e.g., backhaul paths) to be used for routing data associated with the IAB node via the new parent IAB node (the path information may inform the F1 donor CU 605 of the address(es) of the target donor DU(s) (e.g., which represent one or more new paths for routing data for the migrated mobile IAB node 601)), the non-F1 donor CU 604 may provide this information by initiating a process represented by the message configuration update 616 and the configuration update response 617. The message 616 sent by the non-F1 donor CU 604 may include the identification of the target donor DU, and the message 617 may be an acknowledgement from the F1 donor CU.

[0183] According to one example, message 616 can be an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message, and message 617 can be an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE, both of which are specified in Sections 9.1.4.4 and 9.1.4.5 of TS 38.423 V17.2.0 (Xn protocol) and are used for the IAB transport migration modification procedure. Thus, at the same time, the non-F1 donor CU 604 can provide new configuration parameters (e.g., the BH RLC channel) to be used by the IAB node 601 to send user data packets in the IAB topology controlled by the non-F1 donor CU 604 in message 616. According to this example, compared with Option 1 above, the F1 donor CU receives all the required information to update the F1 path with the IAB node 601 in a single message, where after receiving the DU configuration message 615, the F1 donor CU 605 initiates an IAB transport migration management procedure to update the path used for F1 user data.

[0184] According to another example, message 616 can be an NG-RAN NODE CONFIGURATION UPDATE message, and message 617 can be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE, both of which are specified in Sections 9.1.3.4 and 9.1.3.5 of TS 38.423 V17.2.0 (Xn protocol). After this NG-RAN node configuration update procedure and for completing the F1 path setup, the F1 donor CU 605 can perform an IAB transport migration management procedure as described, for example, in Section 8.5.2 of TS 38.423 V17.2.0. With this procedure, the F1 donor CU 605 requests and obtains from the non-F1 donor CU 604 information related to the F1 path (e.g., the BH RLC channel) to be configured in the IAB node 601. Instead of the IAB transport migration management procedure, the non-F1 donor CU 604 can initiate an IAB transport migration modification procedure as described in Section 8.5.3 of TS 38.423 V17.2.0 for the same purpose (i.e., for completing the F1 path setup after the NG-RAN node configuration update procedure).

[0185] To enable the F1 donor CU 605 to identify the migrating IAB node 601 associated with a message received at the F1 donor CU 605 that indicates that an IAB node has migrated within an IAB topology managed by a non-F1 donor CU 604 and that one or more new routing / backhaul paths are to be used for routing data associated with the migrating IAB node, the message sent to the F1 donor CU 605 includes one or more identifiers of the migrating IAB node. For example, in those procedures (NG-RAN node configuration update, IAB transmission migration management, and IAB transmission migration modification), the identifier of the IAB node 601 is present in all messages having one or more of the following: the information elements F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID (both defined at the first MT migration of the IAB node 601). As specified in Section 9.2.3.16 of TS 38.423, the NG-RAN node UE XnAP ID uniquely identifies a UE through the Xn interface within the NG-RAN node. Thus, each donor CU assigns a value to each IAB node in its IAB topology (since the IAB-MT is considered a UE). When the F1 donor CU 605 admits the IAB node 601 into its IAB topology, it will assign an ID to the IAB node 601. At the time of MT migration, the non-F1 donor CU 604 will assign another ID to the IAB node 601. These two IDs are exchanged in the handover request / acknowledgment message. Another identifier of the IAB node 601 is the BAP address assigned to the IAB node. Each IAB donor CU that terminates the RRC connection with the IAB node assigns a BAP address to the IAB node (to use the BAP address as the destination BAP address for routing BAP packets to the IAB node within the IAB topology controlled by that IAB donor CU). In the case where the F1 donor CU 605 admits the IAB node 601 into its IAB topology, it may have assigned a BAP address to the IAB node 601. At the time of MT migration, the non-F1 donor CU or the RRC donor CU 604 will assign another BAP address to the IAB node 601.

[0186] Figures 7a to 7c illustrates one or more embodiments according to the present invention in a wireless communication system such as the communication system shown and described with reference to Figure 1 and the communication system shown and described with reference to Figure 5Flowchart of an example method performed at different network nodes in an IAB communication system as shown and described, etc. Briefly, a method for handover processing (or for a part of the handover processing) is disclosed, in which the MT of an IAB node (such as a mobile IAB node, etc.) is handed over (e.g., continuously handed over) from a first parent IAB network node (such as a source IAB network node, etc.) to a second parent IAB network node (such as a target IAB network node, etc.) in a second IAB topology, where the IAB node is managed (or controlled or served) by a first IAB donor CU of the first IAB topology (e.g., the F1-terminating donor CU of the IAB node that maintains an F1 connection with the IAB node), and the first parent IAB network node and the second parent IAB network node are managed (or controlled or served) by a second IAB donor CU of the second IAB topology (e.g., a non-F1-terminating donor CU or an RRC-terminating donor CU of the IAB node that has an RRC connection with the IAB node). The method includes: sending path information associated with one or more routing paths in the second topology to the first IAB donor CU, the one or more routing paths to be used for routing data associated with the IAB node (e.g., data to be routed to and from the IAB node) via or through the second parent IAB network node. The first parent IAB network node is associated with a first IAB donor distributed unit (DU), and the second parent IAB network node is associated with a second IAB donor DU, the first IAB donor DU and the second IAB donor DU being connected to the second IAB donor CU. The first parent IAB network node is one of the IAB nodes of the second IAB topology and the first IAB donor DU, and the second parent IAB network node is one of the IAB nodes of the second IAB topology and the second IAB donor DU. The path information sent to the F1-terminating donor CU can be used to inform the F1-terminating donor CU of one or more routing paths in different topologies for routing data to / from the IAB node (e.g., F1 data, including user traffic, control traffic), the one or more routing paths being new routing paths as they include a new parent IAB network node. In cases where the handover between parent IAB network nodes involves a new donor DU (e.g., when the new parent IAB network node is a new IAB donor DU or a parent IAB node (directly or indirectly) connected to the new IAB donor DU), one or more routing paths are used to route data associated with the IAB node through the new IAB donor DU.

[0187] The information associated with one or more routing paths may be or may include one or more addresses or address information (such as (one or more) IP addresses, (one or more) TNL addresses, etc.) associated with a second IAB donor DU or a new IAB donor DU. The IAB TNL address is specified in Section 9.2.2.92 of TS 38.423: It represents an IPv4 or IPv6 address or an IPv6 address prefix assigned to an IAB node. There may be one or more IP addresses for F1-C traffic and one or more addresses for F1-U traffic (see Section 5.3.5.12a.1.2 of TS 38.331, IP address addition / modification). In an example, identity information including at least one identifier of the IAB node may be sent. Such an identifier may include an identifier known to the F1-terminating donor CU and / or non-F1-terminating donor CU of the IAB node: For example, the message may include one or more of the following: the information element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the (one or more) BAP addresses assigned to the IAB node (e.g., the BAP addresses assigned by the (one or more) non-F1 / RRC-terminating donor CUs). The path information and identity information may be sent by the IAB node (e.g., as described in more detail below with reference to Figure 7a or by the second IAB donor CU (e.g., the non-F1-terminating donor CU of the mobile IAB node) (e.g., as described in more detail below with reference to Figure 7b ). The second IAB donor CU (e.g., the non-F1-terminating donor CU of the mobile IAB node) may also send configuration information including configuration parameters (such as one or more of BH RLC channel information and BAP sublayer routing information, etc.) for each backhaul link in one or more routing paths. The path information and configuration information may be sent by the second IAB donor CU (e.g., the non-F1-terminating donor CU of the mobile IAB node) in the same message.

[0188] Although the following methods / devices will be mainly described with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The method according to one or more embodiments of the present invention may be applicable to, for example, stationary IAB nodes at the edge of an IAB topology and near one or more IAB nodes in the neighboring IAB topology.

[0189] Thus, by means of information sent by a second IAB donor CU (non-F1 terminating donor CU) or by a first IAB donor CU (F1 terminating donor CU) to an IAB node, the F1 terminating donor CU can be informed of the migration of the MT of the IAB node between the parent IAB network nodes in the IAB topology controlled by the non-F1 terminating donor CU of the IAB node (e.g., consecutive MT migrations of the IAB node), and at least one new routing path to be used for routing data (e.g., F1 data, user traffic, or control traffic) for the migrated IAB node in the IAB topology controlled by the non-F1 terminating donor CU (e.g., for routing data to / from the migrated IAB node or between the migrated IAB node and the F1 terminating donor CU in the IAB topology controlled by the non-F1 terminating donor CU). Then, the F1 terminating donor CU can update the configuration information for the IAB node based on the received information to update the routing paths used by the IAB node (e.g., F1-C routing path and F1-U routing path) to new routing paths for routing data to / from the IAB node via or through the target donor DU.

[0190] Figure 7a is a flowchart showing an example method 700 according to one or more embodiments of the present invention, the example method 700 being performed at an IAB node (e.g., a mobile IAB node or mIAB node) for migration processing (or for a part of the migration processing), in which the MT of the IAB node is migrated (e.g., consecutively migrated) in a second IAB topology different from the first IAB topology to which the IAB node belongs. The method 700 is used to manage consecutive MT migrations in the IAB topology controlled by the non-F1 terminating donor CU of the IAB node. For example, referring to Figure 5 shown in and for Figure 5For the IAB communication system described above, the IAB node performing method 700 may be a mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501 (e.g., the F1 terminating donor CU of the mobile IAB node 570 that maintains an F1 connection with the mobile IAB node 570). The handover process may involve migrating the MT 571 of the mIAB node 570 from the parent IAB node 530 associated with the IAB donor DU 505 to the parent IAB node 550 associated with the IAB donor DU 506 in the IAB topology 5002 controlled by the IAB donor CU 502 (e.g., the non-F1 terminating donor CU of the mobile IAB node 570 that has an RRC connection with the mobile IAB node 570) when the routing path used by the mobile IAB node 570 switches from the routing path including the parent IAB node 530 and the IAB donor DU 505 to the routing path including the parent IAB node 550, the IAB node 540, and the IAB donor DU 505. As Figure 7a shown in and for Figure 7a the method 700 described above may be performed by software elements and / or hardware elements. The IAB node may be implemented in the communication device 400 as Figure 4 shown in and with reference to Figure 4 the communication device 400 described above, where the method as Figure 7a shown in and with reference to Figure 7a described above is performed by one or more processing units (such as the central processing unit 411, etc.).

[0191] As part of a handover process in which an MT (such as MT 571 of mobile IAB node 570) of an IAB node controlled by an F1-terminated donor CU (such as IAB donor CU 501 of IAB topology 5001 etc.) in the same IAB topology controlled by a non-F1-terminated donor CU migrates from one parent IAB network node associated with one IAB donor DU (e.g., source donor DU) to another parent IAB network node associated with another IAB donor DU (e.g., target donor DU) (e.g., from IAB donor CU 502 to IAB donor DU 506 in IAB topology 5002 controlled by IAB donor CU 502), at step 701, the IAB node (such as IAB node 570) may receive from its non-F1-terminated donor CU (such as donor CU 502) path information associated with one or more routing paths in a second IAB topology to be used to route data associated with the IAB node through the target parent IAB network node. The path information may include one or more than one address of a target donor DU (e.g., IP address) such as donor DU 506 in the IAB topology controlled by the non-F1 donor CU. For example, as described above, the IAB node may receive the (one or more than one) address of the target donor DU in a message such as message 612 etc.

[0192] At step 702, the IAB node 570 sends, via the target IAB donor DU (e.g., the IAB donor DU 506), path information associated with one or more routing paths to be used for routing data associated with or for the mobile IAB node 570 (e.g., for routing data to and from the mobile IAB node). The path information can be sent after the MT of the IAB node 570 has migrated. The path information associated with one or more routing paths can be or can include address information, such as one or more addresses (such as (one or more) IP addresses, (one or more) TNL addresses, etc.) associated with a second IAB donor DU (e.g., the target donor DU). In an example, the IAB node 570 can also send identification information including (one or more) identifiers of the mobile IAB node known to two IAB donor CUs 501, 502: for example, the message can include one or more of the following: Information Element F1 - TerminatingIAB - donor UE XnAP ID and non - F1 - Terminating IAB - donor UE XnAP ID or RRC - Terminating IAB - donor UE XnAP ID and (one or more) BAP addresses assigned to the IAB node. The IAB node 570 can send the received path information (e.g., the (one or more) addresses of the received target donor DU) to the F1 - terminating donor CU (such as the donor CU 501) to which it is connected, and the F1 - terminating donor CU controls another IAB topology 5001 to be the IAB topology 5002 controlled by the donor CU 502. For example, as described above, the IAB node 570 can send the (one or more) addresses of the received target donor DU in a message such as the DU configuration message 615.

[0193] Figure 7b is a flowchart showing an example method 710 according to one or more embodiments of the present invention, which example method 710 is performed at a second IAB donor CU (e.g., the non - F1 - terminating donor CU of an IAB node) for the migration process of the MT of an IAB node (e.g., a mobile IAB node or mIAB node) (or for a part of the migration process). The method 710 is used to manage the continuous MT migration of an IAB node at the non - F1 - terminating donor CU of the IAB node. For example, referring to Figure 5 shown in and for Figure 5For the IAB communication system described above, the second IAB donor CU performing method 710 may be IAB donor CU 502 (e.g., a non-F1 terminated donor CU of IAB node 570 that has an RRC connection with IAB node 570). The IAB node may be mobile IAB node 570 belonging to IAB topology 5001 controlled by IAB donor CU 501 (e.g., an F1 terminated donor CU of mobile IAB node 570 that maintains an F1 connection with mobile IAB node 570). The handover process may involve the MT 571 of mIAB node 570 migrating from a parent IAB node 530 associated with IAB donor DU 505 to a parent IAB node 550 associated with IAB donor DU 506 in IAB topology 5002 controlled by IAB donor CU 502. As Figure 7b shown in and for Figure 7b the method 710 described above may be performed by software elements and / or hardware elements. The non-F1 terminated IAB donor CU may be implemented in a communication device 400 as Figure 4 shown in and with reference to Figure 4 wherein the method described as Figure 7b shown in and for Figure 7b is performed by one or more processing units (such as central processing unit 411, etc.).

[0194] At step 711, the non-F1 terminated donor CU (such as donor CU 502) of an IAB node (such as IAB node 570) determines that the MT (such as MT 571 of mobile IAB node 570) of an IAB node controlled by an F1 terminated donor CU (such as IAB donor CU 501 of IAB topology 5001) is to migrate from a first parent IAB network node to a second parent IAB network node in the same IAB topology controlled by the non-F1 terminated donor CU (e.g., the handover involves changing from IAB donor DU505 to IAB donor DU 506 in IAB topology 5002 controlled by IAB donor CU 502). The first parent IAB network node is associated with an IAB donor DU (e.g., a source donor DU), and the first parent IAB network node may be the source donor DU or another IAB node. The second parent IAB network node is associated with a second IAB donor DU (e.g., a target donor DU), and the second parent IAB network node may be the target donor DU or another IAB node. For example, the non-F1 terminated donor CU (such as donor CU 502) determines that the execution of a process within the CU results in the identification of a target donor DU to route packets to or from IAB node 570 in the IAB topology controlled by non-F1 terminated donor CU 502. As described above, the process within the CU may be a CU-internal topology adaptation process or a CU-internal topology redundancy process or a CU-internal backhaul RLF recovery process.

[0195] At step 712, the non-F1-terminating donor CU 502 sends path information associated with one or more than one routing path to be used for routing data associated with or for the IAB node 570 via the second IAB donor DU 506 to the F1-terminating donor CU 501 of the IAB node 570 that controls another IAB topology. The path information associated with one or more than one routing path may be or may include address information, such as one or more than one address (such as (one or more than one) IP address, (one or more than one) TNL address, etc.) associated with the second IAB donor DU (e.g., the target donor DU). In an example, the non-F1-terminating donor CU 502 may send identification information including (one or more than one) identifiers of the mobile IAB nodes known to the two IAB donor CUs 501, 502: for example, the message may include one or more than one of the following: Information Element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and (one or more than one) BAP addresses assigned to the IAB node. Thus, the non-F1-terminating donor CU 502 may send the (one or more than one) address of the target donor DU together with the identifiers of the IAB nodes known to the two donor CUs to the F1-terminating donor CU 501 of the IAB node 570. For example, the non-F1-terminating donor CU 502 may send the received (one or more than one) address of the target donor DU in a message such as message 616 as described above. Configuration information including configuration parameters (such as one or more than one of BH RLC channel information and BAP sublayer routing information, etc.) for each backhaul link in one or more than one routing path may also be sent by the non-F1-terminating donor CU. As described above, the configuration information may be sent in the same message as the received (one or more than one) address.

[0196] Figure 7c is a flowchart showing an example method 720 according to one or more than one embodiment of the present invention. The example method 720 is performed at a first donor CU (e.g., the F1-terminating donor CU of the IAB node) for migration processing (or for a part of the migration processing) of the MT of the IAB node. Method 710 is used to manage the continuous MT migration of the IAB node in the IAB topology of the non-F1-terminating donor CU of the IAB node at the F1-terminating donor CU of the IAB node. For example, refer to Figure 5as shown in and for Figure 5 For the IAB communication system described, the first IAB donor CU for performing method 720 may be IAB donor CU 501 (e.g., the F1 - terminated donor CU of IAB node 570 that maintains an F1 connection with IAB node 570). The IAB node may be mobile IAB node 570 belonging to IAB topology 5001 controlled by IAB donor CU 501. The handover process may involve the MT 571 of mIAB node 570 migrating from a parent IAB node 530 associated with IAB donor DU 505 to a parent IAB node 550 associated with IAB donor DU 506 in IAB topology 5002 controlled by IAB donor CU 502 (e.g., the non - F1 - terminated donor CU of mobile IAB node 570 that has an RRC connection with mobile IAB node 570). As Figure 7c as shown in and for Figure 7c the method 720 described may be performed by software elements and / or hardware elements. The F1 - terminated IAB donor CU may be implemented in a communication device 400 as shown in and with reference to Figure 4 as shown in and with reference to Figure 4 the communication device 400 described, where the method as shown in and for Figure 7c as shown in and for Figure 7c the method described is performed by one or more processing units (such as central processing unit 411, etc.).

[0197] As part of a handover process in which the MT (such as MT 571 of mobile IAB node 570 etc.) of an IAB node controlled by an F1-terminating donor CU (such as IAB donor CU 501 etc. of IAB topology 5001) migrates in the same IAB topology controlled by a non-F1-terminating donor CU from one parent IAB network node associated with one IAB donor DU (e.g., source donor DU) to another parent IAB network node associated with another IAB donor DU (e.g., migrates from IAB donor DU 505 to IAB donor DU 506 in IAB topology 5002 controlled by IAB donor CU 502), at step 721, the F1-terminating donor CU (such as IAB donor DU 501) receives path information associated with one or more routing paths to be used for routing data associated with or for mobile IAB node 507 via or through the target IAB donor DU (e.g., IAB donor DU 506) (such as for routing data to and from the mobile IAB node). This path information can be received from the non-F1-terminating donor CU 502 of IAB node 507 or from IAB node 507. This path information can be received after the MT of IAB node 570 has migrated. The path information associated with one or more routing paths can be or can include address information, such as one or more addresses (such as (one or more) IP addresses, (one or more) TNL addresses etc.) associated with the second IAB donor DU (e.g., target donor DU) etc. In an example, the F1-terminating donor CU may also receive identification information including (one or more) identifiers of the mobile IAB node known to the two IAB donor CUs 501, 502: for example, the message can include one or more of the following: Information Element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and (one or more) BAP addresses assigned to the IAB node. For example, the F1-terminating donor CU (such as IAB donor CU 501) (e.g., in a message such as message 616 etc.) receives from the non-F1-terminating donor CU 502 of an IAB node (the MT part of which has migrated in the IAB topology controlled by the non-F1-terminating donor CU 502) the (one or more) addresses of the target donor DU (e.g., target donor DU 506) and the identifier of the IAB node known to the two donor CUs. Alternatively, (e.g., in a message such as message 615 etc.) the (one or more) addresses of the target donor DU are received from the IAB node.When receiving a message from a non-F1-terminating donor CU 502 of a mobile IAB node, the message may further include configuration parameters for each backhaul link in one or more than one routing path (such as one or more than one of BH RLC channel information and BAP sublayer routing information, etc.).

[0198] At step 722, the F1-terminating donor CU 501 may update the configuration information for the IAB node 570 based on the received information to update the routing paths associated with or used for the IAB node 570 (e.g., F1-C routing path and F1-U routing path) to new routing paths for routing data to / from the IAB node via the target donor DU 506. For example, the F1-terminating donor CU updates the F1 paths (control data path and user data path) to reach the IAB node through the target donor DU in the IAB topology controlled by the non-F1-terminating donor CU of the IAB node. The F1-terminating donor CU 501 may also send the configuration information to the IAB node 570 to configure the IAB node based on the configuration parameters (such as one or more than one of BH RLC channel information and BAP sublayer routing information, etc.) received from the non-F1-terminating donor CU 502.

[0199] Figure 8 An example of another IAB communication system (or IAB network system) 800 that may implement embodiments of the present invention and examples of the embodiments is illustrated. In one example implementation, the BH radio link operates in a millimeter wave band (i.e., above 30 GHz) that is highly sensitive to radio channel interference. The IAB network will also be referred to as an IAB topology or a topology, and thus in this application, the terms IAB network and IAB topology and topology will be used interchangeably.

[0200] The IAB communication system 800 consists of three IAB networks or IAB topologies 8001, 8002, and 8003, where each IAB topology includes a set of IAB nodes (e.g., the set may include multiple IAB nodes or at least one IAB node) and an IAB donor CU for controlling or managing the multiple IAB nodes. The set of IAB nodes may include one or more than one IAB node, such as an initiating IAB node that generates BAP packets and intermediate or relay IAB nodes, etc. Each IAB node communicates with at least one other IAB node via a wireless backhaul (BH) link. Although Figure 8 Three IAB topologies 8001, 8002, and 8003 are shown, 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 (where each topology includes a set of IAB nodes and an IAB donor CU) as described above.

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

[0202] IAB topology 8001 includes IAB donor CU 801 (identified as Donor1-CU in Figure 8 ), its associated IAB donor DU 804 (identified as Donor1-DU1 in Figure 8 ), and a plurality of IAB nodes 810 and 820 similar to IAB nodes 121 and 122.

[0203] IAB topology 8002 includes IAB donor CU 802 (identified as Donor2-CU in Figure 8 ), its associated IAB donor DU, IAB donor DU 805 (identified as Donor2-DU1 in Figure 8 ), and IAB donor DU 806 (identified as Donor2-DU2 in Figure 8 ), and a plurality of IAB nodes 830, 840, and 850 similar to IAB nodes 121 and 122 and an IAB node 870 that can be similar to mobile IAB node 123. All IAB nodes can be access nodes for serving a UE (such as UE 880 served by mobile IAB node 870). IAB topology 8002 is transparent to UE 880 that is connected to donor CU 802 through the DU part or unit DU 872 of mobile IAB node 870. Although Figure 8 only one UE 880 is shown, it will be understood that there will be multiple UEs connected to the network nodes of IAB communication system 800.

[0204] IAB topology 8003 includes IAB donor CU 803 (identified as Donor1-CU in Figure 8 ), its associated IAB donor DU 807 (identified as Donor1-DU1 in Figure 8 ), and an IAB node 860 similar to IAB nodes 121 and 122.

[0205] The wired backhaul IP network interconnects IAB donor CUs 801, 802, and 803 and IAB donor DUs 804, 805, 806, and 807 through the wired backhaul 808. For example, the wired backhaul 808 consists of optical fiber cables.

[0206] The IAB donor CU 801, the IAB donor DU 804, and the IAB nodes 810 and 820 are part of the same IAB network or IAB topology 8001 configured, managed, or controlled by the IAB donor CU 801.

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

[0208] The IAB donor CU 803, the IAB donor DU 807, and the IAB node 860 are part of the same IAB network or IAB topology 8003 configured, managed, or controlled by the IAB donor CU 803.

[0209] Assume that the mobile IAB node 870 initially has a single parent IAB node 820, and the IAB node 870 belongs to the IAB topology 8001 controlled by the IAB donor CU 801. When the mobile IAB node 870 is moving and considering its proximity to the IAB topology 8002, especially when the mobile IAB node 870 is Figure 8 at the position shown by the dashed line in, it can establish a wireless BH link with the IAB node 530 when approaching the IAB node 830. Such a BH link is possible for stationary IAB nodes, and such a BH link is very likely to occur for IAB nodes such as the IAB node 870 moving in the direction of the IAB topology 8002 (shown by the arrow 890 in Figure 8 ).

[0210] Then, the F1 donor CU 801 may have decided to perform a migration of the MT part 871 of the IAB node 870 towards the IAB topology controlled by the donor CU 802 (which becomes the non-F1 donor CU for the IAB node 870) (i.e., the MT part 871 of the IAB node 870 migrates towards the parent IAB node 830). To this end, (when the IAB node 870 has descendant IAB nodes) the F1 donor CU 801 may have initiated the inter-CU topology adaptation procedure described in Section 8.17.3.1 or Section 8.17.3.2 of TS 38.401 V17.2.0. As a result, the IAB node 801 still belongs to the IAB topology 8001, which has an F1 connection with the donor CU 801, but its RRC connection is now connected to the donor CU2 802. After this process, the IAB donor CU 801 may request a migration of the backhaul traffic associated with the IAB node 870 towards the IAB topology 8002 (i.e., via the donor DU 805). In this case, the donor CU 801 triggers the IAB transmission migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0.

[0211] While the mobile IAB node 870 is still moving, then, the MT part 871 of the IAB node 870 may have migrated towards the parent IAB node 850 using the backhaul link 8050 between the non-F1 donor CU 802 and the IAB node 870. To this end, the non-F1 donor CU 802 may have applied the intra-CU topology adaptation procedure described in Section 8.2.3.1 (or Section 8.17.3.2) of TS 38.401 V17.2.0, which results in a successive MT migration of the IAB node 870 to the new single parent IAB node 850. Nevertheless, the IAB node 801 has its F1 connection with the donor CU 801 and its RRC connection with the donor CU2 802.

[0212] After being informed to route the F1 traffic associated with the IAB node 870 using the donor DU 506 instead of the donor DU 505, the donor CU 801 may request a migration of the traffic associated with the IAB node 570 towards the IAB topology 5002. In this case, the donor CU 801 triggers the IAB transmission migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0.

[0213] When further moving (this time in the direction of the IAB topology 8003 controlled by the donor CU 803), the IAB node 870 can become positioned such that the backhaul link 8060 with the IAB node 860 can have better quality compared to the backhaul link 8050 with the IAB node 850. Thus, the donor CU 802 can apply the inter-CU topology adaptation procedure described in Sections 8.17.3.1 or 8.17.3.2 of TS 38.401 V17.2.0. After this continuous MT migration, the IAB node 801 still belongs to the IAB topology 8001, which has an F1 connection with the donor CU 801 but has an RRC connection with the donor CU 3 803. However, the donor CU 801 must be informed of the new non-F1 donor CU 803 for the IAB node 870 and informed of the new donor DU 807 to redirect the offloaded traffic (control traffic and user traffic) through the donor DU 807 instead of the donor DU 806.

[0214] In all of the above MT migration cases, the UE 880 remains connected to the donor CU 801 through the DU part or unit DU 872 of the mobile IAB node 870. In the case where the IAB node 870 has several (one or more than one) sub-IAB nodes, such sub-IAB nodes still belong to the IAB topology 8001 and are still fully controlled by the donor CU 801 (through the F1 connection and the RRC connection).

[0215] Examples of methods according to one or more embodiments of the present invention will now be described. These methods enable the F1-terminating donor CU of an IAB node to be informed of: the migration of the MT of the IAB node between one IAB topology (source topology) controlled by a non-F1-terminating donor CU or an RRC-terminating donor CU of the IAB node and another IAB topology (target topology) controlled by another non-F1-terminating donor CU or an RRC-terminating donor CU of the IAB node (e.g., continuous MT migration of the IAB node between non-F1-terminating topologies); and at least one new routing path to be used for routing data associated with or for the migrated IAB node in the target IAB topology (e.g., F1 traffic, user traffic, and control traffic) (e.g., to be used for routing data to / from the migrated IAB node or between the migrated IAB node and the F1-terminating donor CU in the IAB topology controlled by the non-F1-terminating donor CU). Although the following methods / devices will be mainly described with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The methods according to one or more embodiments of the present invention can be applicable to, for example, stationary IAB nodes at the edge of one IAB topology and near one or more IAB nodes in an adjacent IAB topology.

[0216] Fig. 9 FIG. 900 is a schematic simplified diagram illustrating some example message flows for performing continuous MT migration of an IAB node towards a target IAB topology (including setting up a control data path) according to one or more embodiments of the present invention. The continuous MT migration may involve new MT migrations between different parent IAB nodes managed by different donor CUs that are different from the donor CU of the DU of the serving IAB node.

[0217] The figure shows an IAB node 901, which may be a mobile IAB node such as the IAB node 870 as in Figure 8 and / or the IAB node 123 as in Figure 1 and is composed of a mobile terminal (MT) 903 (identified as IAB-MT) and a distributed unit (DU) 902 (identified as IAB-DU). The figure also shows: a source non-F1 terminating donor CU (or non-F1 donor CU) 905 that terminates the RRC connection to the IAB node 901 through the IAB-MT 903, an F1 terminating donor CU (or F1 donor CU) 904 that terminates the F1 connection to the IAB node 901 through the IAB-DU 902, and a target non-F1 terminating donor CU 906 that becomes the new non-F1 terminating donor CU for the IAB node 901 during the process. As an example and referring to Figure 8 the IAB communication system, the F1 terminating donor CU 904 for the IAB node is the donor CU 801, the MT 871 of the IAB node 870 has migrated to the IAB topology 8002 managed by the donor CU 802, and thus the source non-F1 terminating donor CU 905 is the donor CU 802. When the IAB node moves towards 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 thus the target non-F1 terminating donor CU 906 is the donor CU 803.

[0218] At the start of process 900, it is assumed that the control path (F1-C) and user path (F1-U) set by the F1 donor CU 904 to reach the IAB node 901 use one or several backhaul paths of the IAB topology controlled by the donor DU of the source non-F1 donor CU 905 through Fig. 9 not shown in Figure 8 For example, referring to

[0219] a such backhaul path may include the donor DU 505 and the IAB nodes 840 and 850.

[0220] In fact, assume that when the MT 871 (903) of the IAB node 870 (901) migrates from the parent IAB node 850 of the IAB topology 8002 to the new parent IAB node 860 of a different IAB topology 8003, the source non-F1 donor CU 905 that receives the measurement report 911 from the IAB node 901 initiates a continuous MT migration of the IAB node 901 to another IAB topology as described above with reference to Figure 8 the process 900 for further illustration using the inter-CU topology adaptation process. Fig. 9 as an example.

[0221] The measurement report 911 is received by the source non-F1 donor CU 905 via the F1 message UL RRC MESSAGE TRANSFER (specified in TS 38.423) sent by the source parent IAB node of the IAB node 901 (e.g., the parent IAB node 850 in Figure 8 ), which embeds an RRC message and the measurement report sent by the IAB-MT 903 to the DU part of the source parent IAB node. The measurement report is the result of the measurements regularly made by the IAB-MT 903 on the signals received from the serving cell and one or more target cells (such as the signal synchronization block (SSB) transmitted in the serving cell and the target cell, etc.). The target cell can be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). Once the IAB-MT 903 detects at least one SSB that meets the predefined criteria (e.g., the received power exceeding the predefined threshold), a measurement report can be generated and transmitted to provide radio link quality information about different cells near the IAB node 901. The identification of each cell is included in the measurement report to allow the non-F1 donor CU 905 to identify the target CU associated with that cell. In fact, the identification of the donor CU can be deduced from the physical cell identifier (PCI) broadcast in the synchronization signal in each cell managed by the donor CU and / or from the new radio cell group identifier (NCGI) also broadcast in the system information block (SIB) message in each cell managed by the donor CU. The PCI and / or NCGI can be reported by the IAB node 901 in the measurement report 911.

[0222] Based on the received measurement report, the source non-F1 donor CU 905 can detect that the IAB node 901 receives radio signals with better quality in the target cell of the target parent IAB node compared to the source serving cell. With a target parent IAB node belonging to a different IAB topology from the source parent IAB node (e.g., the parent IAB node 850) (e.g., Figure 8Taking the IAB node 860) in [as an example], the source non-F1 donor CU 905 may decide to apply the inter-CU topology adaptation process to the IAB node 901. The target parent IAB node in the target IAB topology involves a new donor DU for routing packets (e.g., donor DU 807 instead of Figure 8 the donor DU 806) in []. The target parent IAB node may be an IAB node or an IAB donor DU.

[0223] The IAB-MT 903 migration is triggered by the handover preparation process 912 described in Section 8.2.1 of TS 38.423 V17.2.0, where the source non-F1 donor CU 905 sends a HANDOVER REQUEST message including the necessary information related to the IAB-MT 903 to the target non-F1 donor CU 906, enabling the handover to proceed. For example, the message includes the identification of the target cell to which the IAB node 901 will switch, and thus it identifies the target parent IAB node controlling the target cell. After requesting the UE context setup for the IAB node 901 from the target parent IAB node, the target non-F1 donor CU 906 performs admission control and provides the new RRC configuration information together with the HANDOVER REQUEST ACKNOWLEDGE message to the source non-F1 donor CU 905. In Fig. 9 the individual steps of the handover preparation process are not shown, which Fig. 9 shows the box 912 representing the IAB-MT handover preparation for simplicity.

[0224] Then, the source non-F1 donor CU 905 may relay the RRC configuration information to the IAB-MT 903 via the message RRC reconfiguration 913. In fact, the message 913 is first embedded in the F1 message UE CONTEXTMODIFICATION REQUEST specified in TS 38.473 and sent by the source non-F1 donor CU 905 to the source parent IAB node of the IAB node 901. Then, this source parent IAB sends the RRC reconfiguration message 913 to the IAB-MT 903. In particular, the RRC reconfiguration message 913 contains address information, such as the (one or more) transport network layer (TNL) addresses (i.e., (one or more) IP addresses) identifying the target donor DU for packet routing (e.g., data routing), etc. In Figure 8 the example of [], the (one or more) addresses of the donor DU 807 replace the (one or more) addresses of the donor DU 806.

[0225] At the IAB node 901, towards the target parent IAB node (e.g., Figure 8After the random access procedure of IAB node 860) in, IAB node 901 sends RRC reconfiguration complete message 914 to target non-F1 donor CU 906 (via the target parent IAB node and F1 message UL RRCMESSAGE TRANSFER embedded with RRC reconfiguration complete information).

[0226] The process 910 ends with Xn message UE CONTEXT RELEASE (UE context release) 915 specified in TS 38.423 to be sent from target non-F1 donor CU 906 to source non-F1 donor CU 905. However, the identifiers of IAB node 901 at F1 donor CU 904 and at source non-F1 donor CU 905 are reserved by source non-F1 donor CU 905 because the F1 path for IAB node 901 can still be used through the IAB topology controlled by source non-F1 donor CU 905.

[0227] The next part (messages 921 and 922) involves the process 920 of updating the F1 paths (F1-C and F1-U) between IAB node 901 and F1 donor CU 905 by the target donor DU in the IAB topology controlled by target non-F1 donor CU 906.

[0228] Target non-F1 donor CU 906 configures the BH RLC channel and BAP layer routing entries on the target path between the target parent IAB node of IAB node 901 (e.g., Figure 8 IAB node 860) in and the target IAB donor DU (e.g., Figure 8 IAB donor DU 807). Target non-F1 donor CU 906 can establish additional BH RLC channels and BAP configurations for the migrating IAB-MT via RRC message 921.

[0229] Then, the DU part of the IAB node 901 (IAB-DU 902) may send a DU configuration message 922 to the F1 donor CU 904. This message may be the F1 message gNB-DU CONFIGURATION UPDATE specified in Section 9.2.1.7 of TS 38.473 V17.2.0. This F1 message includes the identifier of the target non-F1 donor CU 906 and the identification of the target donor DU for F1-C and F1-U traffic. The PCI and / or NCGI of the target cell managed by the target non-F1 donor CU 906 may be reported by the IAB node 901 to the F1 donor CU 904, so that the F1 donor CU 904 can derive the identifier of the target non-F1 donor CU 906. Since the receipt of the message 913, the IAB node 901 knows the address(es) of the target donor DU, such as the IP address(es), etc. The destination address of the message 922 is the F1 donor CU 904, and when this IP packet is received by the target donor DU in the IAB topology controlled by the target non-F1 donor CU 906, this IP packet may be routed in the wired backhaul ( Figure 8 808 therein) until the F1 donor CU 904. Upon receipt of the identification of the target donor DU, the F1 donor CU 904 may update its configuration (e.g., update the routing path associated with the IAB node based on the received information) to deliver the F1 packet to the IAB node 901 via or through the target donor DU of the IAB topology 8003 (e.g., IAB donor DU 807). Then, the path used for updating the F1 control data (F1-C) is updated.

[0230] As an alternative to informing the F1 donor CU 904 of the identifier of the target non-F1 donor CU, the source non-F1 donor CU 905 may provide this information by initiating a process represented by the configuration update message 923 and the configuration update response 924. The message 923 sent by the source non-F1 donor CU 904 may include the identifier of the target non-F1 donor CU 906, and the message 924 may be an acknowledgement from the F1 donor CU 904. The identifier of the donor CU is specified by the information element Global NG-RAN Node ID in Section 9.2.2.3 of TS 38.423 V17.2.0.

[0231] According to one example, message 923 can be an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message, and message 924 can be an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE, both of which are specified in Sections 9.1.4.4 and 9.1.4.5 of TS 38.423 V17.2.0 (Xn protocol), and are messages used in the IAB transport migration modification procedure. By using this procedure, the source non-F1 donor CU 905 can also inform the F1 donor CU 904 to release the traffic unloaded through the IAB topology controlled by the source non-F1 donor CU 905.

[0232] According to another example, message 923 can be an NG-RAN NODE CONFIGURATION UPDATE message, and message 924 can be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE, both of which are specified in Sections 9.1.3.4 and 9.1.3.5 of TS 38.423 V17.2.0 (Xn protocol), and are messages used in the NG-RAN node configuration update procedure.

[0233] To enable the F1 donor CU 904 to identify the migrating IAB node 901 associated with a message received at the F1 donor CU 904 that indicates that the IAB node has migrated from an IAB topology managed by a source non-F1 donor CU 905 to a target IAB topology managed by a target non-F1 donor CU 906 (new non-F1 donor CU), and that one or more new paths are to be used to route data for the migrating IAB node through the topology of the target non-F1 donor CU 906, the message sent to the F1 donor CU 605 includes the identifier of the migrating IAB node associated with the IAB topology controlled by each non-F1 donor CU. For example, in those procedures (NG-RAN node configuration update, IAB transmission migration modification), the identifier of the IAB node 901 is present in all messages that have one or more of the following: the information elements F1-TerminatingIAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the (one or more) BAP addresses assigned to the IAB node (e.g., the BAP address assigned to the IAB node by the source non-F1 / RRC donor CU and / or the BAP address assigned to the IAB node by the target non-F1 / RRC donor CU) defined at the first MT migration of the IAB node 901 to the IAB topology controlled by the first non-F1 donor CU (at the F1 donor CU 904 and the source non-F1 donor CU 905). At the successive MT migration of the IAB node 901 to the IAB topology (target IAB topology) controlled by the second non-F1 donor CU, the target non-F1 donor CU 906 assigns an identifier to the IAB node 901 that is shared with the source non-F1 donor CU 905 in the HANDOVER REQUEST ACKNOWLEDGE message containing the Target NG-RAN node UE XnAP ID information element.

[0234] Fig.10 FIG. 1000 is a schematic simplified diagram illustrating some example message flows for setting up the user data path for successive MT migrations of an IAB node towards a target IAB topology according to one or more embodiments of the present invention. Fig.10 Shows the (one or more) next steps after the procedure with steps 910 and 920 described in Fig. 9 reference.

[0235] The figure shows an IAB node 1001, which can be an IAB node 870 as in Figure 8 and / or Figure 1A mobile IAB node such as IAB node 123 is composed of a mobile terminal (MT) 1003 (identified as IAB-MT) and a distributed unit (DU) 1002 (identified as IAB-DU). The figure also shows: a source non-F1 terminated donor CU (or non-F1 donor CU) 1005 that terminates the RRC connection to IAB node 1001 through IAB-MT 1003, an F1 terminated donor CU (or F1 donor CU) 1004 that terminates the F1 connection to IAB node 1001 through IAB-DU 1002, and a target non-F1 donor CU 1006 that becomes the new non-F1 terminated donor CU for IAB node 1001 during the process. As an example and with reference to Figure 8 In the IAB communication system, the F1 terminated donor CU 1004 for the IAB node is donor CU 801. The MT 871 of IAB node 870 has migrated to the IAB topology 8002 managed by donor CU 802, and thus the source non-F1 terminated donor CU 1005 is donor CU 802. When the IAB node moves towards IAB topology 8003, IAB node 860 is identified as the target IAB node to which the MT of IAB node 870 can migrate, and thus the target non-F1 terminated donor CU 1006 is donor CU 803.

[0236] At the start of process 1000, it is assumed that the control path (F1-C) and user path (F1-U) set by F1 donor CU 1004 to reach IAB node 1001 use one or several backhaul paths in the IAB topology controlled by the donor DU not shown in Fig.10 For example, with reference to Figure 8 , one such backhaul path may include donor DU 806 and IAB nodes 840 and 850.

[0237] Using step 1010 corresponding to Fig. 9 step 910 of Fig. 9 to perform continuous MT migration of mobile IAB node 1001 towards the target IAB topology. Then, use step 1020 corresponding to

[0238] To complete the continuous MT migration, the path used to update the F1 user data (F1-U) shall be utilized by procedure 1030. The F1 donor CU 1004 may initiate the IAB transport migration management procedure specified in section 8.5.2 of TS 38.423 V17.2.0, where protocol messages are directly exchanged between the F1 donor CU 1004 and the target non-F1 donor CU 1006 without involving the source non-F1 donor CU 1005. For the purpose of configuring the user traffic towards / from the IAB node 1001 in the IAB topology controlled by the target non-F1 donor CU 1006, the F1 donor CU 1004 sends a message 1031 corresponding to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in section 9.1.4.2 of TS 38.423 V17.2.0 (Xn protocol) to the target non-F1 donor CU 1006. According to this request, the target non-F1 donor CU 1006 may configure or modify the BHRLC 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 may send a message 1032 containing BAP configuration information to the IAB node 1001. The message 1032 may be an RRC reconfiguration message specified in TS 38.331. Then, the target non-F1 donor CU 1006 responds to the F1 donor CU 1004 with a message 1033 corresponding to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE specified in section 9.1.4.3 of TS 38.423 V17.2.0 (Xn protocol) to provide new configuration parameters (e.g., BH RLC channels) to be used by the IAB node 1001 to send user data packets in the IAB topology controlled by the target non-F1 donor CU 1006. Then, these configuration parameters may be provided by the F1 donor CU 1005 to the IAB node 1001 through message 1034 (e.g., using the F1 message BAP MAPPING CONFIGURATION message specified in section 9.2.9.1 of TS 38.473 V17.2.0).

[0239] Finally, and in case the source non-F1 donor CU 1005 has not used the IAB transport migration modification procedure to (i.e., by using Fig. 9In the case where messages 923 and 924) request the release of traffic unloaded by the F1 donor CU 1004, the F1 donor CU 1004 may initiate an IAB transport migration management process by using messages 1035 and 1036. By using this process, the source non-F1 donor CU 1005 may also inform the F1 donor CU 1004 to release the traffic unloaded through the IAB topology controlled by the source non-F1 donor CU 1005. For the purpose of releasing the traffic to / from the IAB node 1001 unloaded in the IAB topology controlled by the target non-F1 donor CU 1006, the F1 donor CU 1004 sends a message 1035 corresponding to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in section 9.1.4.2 of TS 38.423 V17.2.0 to the source non-F1 donor CU 1005. Then, the source non-F1 donor CU 1005 responds to the F1 donor CU 1004 by using a message 1036 corresponding to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE specified in section 9.1.4.3 of TS 38.423 V17.2.0 (Xn protocol).

[0240] In the IAB transport migration management process, the identifier of the IAB node 1001 exists in all messages that have one or more of the following: the information elements F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the (one or more) BAP addresses assigned to the IAB node, and these identifiers are defined at the time of the first MT migration of the IAB node 1001 to the IAB topology controlled by the first non-F1 donor CU (at the F1 donor CU 1004 and the source non-F1 donor CU 1005), or at the target non-F1 donor CU 1006 during the consecutive MT migrations of the IAB node 1001 to the IAB topology (target IAB topology) controlled by the second non-F1 donor CU (step 1010).

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

[0242] This figure shows an IAB node 1101, which may be as Figure 8 the IAB node 870 and / or Figure 1 a mobile IAB node such as the IAB node 123, which is composed of a mobile terminal (MT) 1103 (identified as IAB-MT) and a distributed unit (DU) 1102 (identified as IAB-DU). The figure also shows: a source non-F1 terminated donor CU (or non-F1 donor CU) 1105 that terminates the RRC connection to the IAB node 1101 through the IAB-MT 1103, an F1 terminated donor CU (or F1 donor CU) 1104 that terminates the F1 connection to the IAB node 1101 through the IAB-DU 1102, and a target non-F1 donor CU 1106 that becomes the new non-F1 terminated donor CU for the IAB node 1101 during the process. As an example and with reference to Figure 8 in the IAB communication system, the F1 terminated donor CU 1104 for the IAB node is the donor CU 801, the MT 871 of the IAB node 870 has migrated to the IAB topology 8002 managed by the donor CU 802, and thus the source non-F1 terminated donor CU 1105 is the donor CU 802. When the IAB node moves towards 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 thus the target non-F1 terminated donor CU 1106 is the donor CU 803.

[0243] At the start of the process 1100, it is assumed that the control path (F1-C) and user path (F1-U) set by the F1 donor CU 1104 to reach the IAB node 1101 use one or several backhaul paths in the IAB topology controlled by the donor DU that is not represented in Fig.11 . For example, with reference to Figure 8 , one such backhaul path may include the donor DU 806 and the IAB nodes 840 and 850.

[0244] The first part of the flowchart describes the process 1110 that causes the IAB-MT 1103 to migrate to the IAB topology controlled by the target non-F1 donor CU 1106 after RLF recovery (e.g., the IAB-MT 1103 migrates to the IAB node 860 in the IAB topology 8003). It includes the setting of a new path for the RRC protocol message.

[0245] The IAB-MT 1103 of the IAB node 1101 periodically measures signals received at the IAB-MT 1103 from the serving cell and one or more target cells (such as signal synchronization blocks (SSBs) transmitted in the serving cell and in the target cells). The target cell may be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). In the case where the IAB node 1101 is connected to the IAB node 850 via a backhaul link, the serving cell or the source cell is the cell served by the IAB node 850.

[0246] The following situation may occur: The SSB signal in the serving cell meets a predefined criterion (such as received power below a predefined threshold) during a time period sufficient to declare RLF for the link between the IAB node 1101 and its source parent IAB node (e.g., Figure 8 the link 8050 between the IAB node 870 and the IAB node 850 in the example). In addition, the IAB node 1101 may have detected an SSB signal that meets a predefined criterion (such as received power above a predefined threshold) sufficient to attempt a new connection in the corresponding target cell. In this case, the mobile IAB node 1101 triggers the inter-CU backhaul RLF recovery procedure as described in Section 8.17.4 of TS 38.401 V17.2.0. It includes: The IAB node 1101 performs a random access procedure to obtain uplink resources, and then transmits an RRC reestablishment request message 1111 in the target cell. As specified in TS 38.331, this RRC message is received by the target parent IAB node ( Figure 8 the IAB node 860 in the example), and is relayed to the target non-F1 donor CU 1106 ( Figure 8 the donor CU 807 in the example) through the F1 message INITIAL UL RRC MESSAGE TRANSFER (Initial UL RRC Message Transfer) specified in Section 9.2.3.1 of TS 38.401 V17.2.0.

[0247] Upon receiving this RRC reestablishment request 1111 including information for identifying the source non-F1 donor CU 1105 of the IAB node 1101 (such as the physical cell identifier of the cell to which the IAB node 1101 was connected before the failure), the target non-F1 donor CU 1106 initiates a procedure 1112 to obtain from the source non-F1 donor CU 1105 ( Figure 8In the example of Figure 8 , the donor CU 806 retrieves the UE context of the IAB node 1101. During this process, the target non-F1 donor CU 1106 sends the Xn protocol message RETRIEVE UE CONTEXT REQUEST specified in Section 9.1.1.8 of TS 38.423 V17.2.0 to the source non-F1 donor CU 1105. The source non-F1 donor CU 1105 responds with the Xn message RETRIEVE UE CONTEXT RESPONSE specified in Section 9.1.1.9 of TS 38.423 V17.2.0. After deciding to accept the reconstruction request from the IAB node 1101, the target non-F1 donor CU 1106 sends an RRC reconstruction message 1113 to the IAB node 1101. This RRC reconstruction message 1113 is embedded in the F1 message DL RRC MESSAGE TRANSFER specified in Section 9.2.3.2 of TS 38.473 V17.2.0 and is sent to the target parent IAB node of the IAB node 1101 (e.g., Figure 8 the IAB node 860 in Figure 8 ). Then, the IAB-MT 1103 of the IAB node 1101 (via the target parent IAB node and the F1 message UL RRC MESSAGE TRANSFER embedded with the RRC reconstruction completion information) sends an RRC reconstruction completion message 1114 to the target non-F1 donor CU 1106.

[0248] After requesting the UE context establishment for the IAB node 1101 from the target parent IAB node, the target non-F1 donor CU 1106 sends the Xn message UE CONTEXT RELEASE 1115 specified in TS 38.423 to the source non-F1 donor CU 1105. The source non-F1 donor CU is informed of the new non-F1 donor CU for the IAB node 1101. However, the identifiers of the IAB node 1101 at the F1 donor CU 1104 and at the source non-F1 donor CU 1105 are retained by the source non-F1 donor CU 1105 because the F1 path is still considered functional by the F1 donor CU 1104.

[0249] In addition, the target non-F1 donor CU 1106 sends an RRC configuration message 1117 to the IAB-MT 1103, and the RRC configuration message 1117 is embedded in the F1 message DL RRC MESSAGE TRANSFER sent to the target parent IAB node of the IAB node 1101. Specifically, the RRC reconfiguration message 1117 includes the (one or more) transport network layer (TNL) addresses (i.e., the (one or more) IP addresses) that identify the target donor DU for packet routing (e.g., data routing). In Figure 8 the example of, the (one or more) addresses of the donor DU 807 replace the (one or more) addresses 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 (via the target parent IAB node and the F1 message ULRRC MESSAGE TRANSFER embedded with the RRC reconfiguration complete information).

[0250] To complete the continuous MT migration of the IAB node 1101, step 1120 corresponding to step 920 of Fig. 9 is used to set the control data path in the IAB topology of the target non-F1 donor CU 1106, where the IAB node 1101 can inform the F1 donor CU1104 of the identifier of the target non-F1 donor CU 1106 and the (one or more) addresses of the target donor DU, or where the source non-F1 donor CU 905 can inform the F1 donor CU 1104 of the identifier of the target non-F1 donor CU 1106. In addition, step 1130 corresponding to step 1030 of Fig.10 is used to set the user data path.

[0251] Figures 12a to 12c is a diagram showing in a wireless communication system (such as the communication system shown and described with reference to Figure 1 and the communication system shown and described with reference to Figure 8Flowchart of an example method performed at different network nodes in the IAB communication system shown and described. The example method at different network nodes is for handover processing (or for a part of the handover processing), in which the MT of the IAB node handovers (e.g., continuously handovers) from a second IAB donor central unit (CU) (e.g., the source IAB donor CU) managed second IAB topology to a third IAB topology managed by a third IAB donor CU (e.g., the target IAB donor CU), where the IAB node is managed (or controlled or served) by a first IAB donor CU of the first IAB topology (e.g., the F1 terminating donor CU of the IAB node that maintains an F1 connection with the IAB node). The second IAB donor CU and the third IAB donor CU are non-F1 terminating donor CUs or RRC terminating donor CUs of the IAB node. The first IAB donor CU or the F1 terminating donor CU (e.g., from the IAB node) receives address information that includes one or more addresses (e.g., (one or more) IP addresses, (one or more) TNL addresses) associated with the target IAB donor DU of the third IAB topology, where data associated with the IAB node (e.g., F1 traffic, user traffic, control traffic) will be routed via or through the target IAB donor DU in the third IAB topology (e.g., data routed to / from the IAB node by the target IAB donor DU in the third IAB topology). The first IAB donor CU or the F1 terminating donor CU also receives identification information (such as PCI or NCGI, etc.) for identifying the third IAB donor CU (e.g., the target non-F1 terminating donor CU) from the IAB node (e.g., as described in more detail below with reference to Fig.12a or from the second IAB donor CU (e.g., the source non-F1 terminating donor CU as described in more detail below with reference to Figure 12b . In an example, the first IAB donor CU or the F1 terminating donor CU may also receive identification information including at least one identifier of the IAB node from the IAB node or the second IAB donor CU (e.g., the source non-F1 terminating donor CU). Such an identifier may include an identifier known to the F1 terminating donor CU and the non-F1 terminating donor CU of the IAB node: for example, the message may include one or more of the following: Information Element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the (one or more) BAP addresses assigned to the IAB node.

[0252] Although the following methods / devices will be mainly described with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The method according to one or more embodiments of the present invention may be applicable to, for example, stationary IAB nodes at the edge of an IAB topology and near one or more IAB nodes in the neighboring IAB topology.

[0253] Thus, by means of information (such as address information, such as the (one or more) addresses of the target donor DU to which the IAB node will or has migrated and / or identification information for identifying a third IAB donor CU (such as PCI or NCGI, etc.)) sent by a second IAB donor CU (non-F1 terminated donor CU) or by a first IAB donor CU (F1 terminated donor CU) to an IAB node, the F1 terminated donor CU can be informed of: the migration of the MT of the IAB node between two different topologies (for example, from a second IAB topology managed by a second IAB donor central unit (CU) (such as a source IAB donor CU) to a third IAB topology managed by a third IAB donor CU (such as a target IAB donor CU)); and at least one new routing path to be used for routing data (such as user traffic and control traffic) of the migrated IAB node in the third IAB topology controlled by the target non-F1 terminated donor CU. The F1 terminated donor CU can then update the configuration information for the IAB node based on the received information to update the routing paths (such as F1-C routing path and F1-U routing path) associated with or used for the IAB node to new routing paths for routing data to / from the IAB node via the target donor DU.

[0254] Fig.12a is a flowchart showing an example method 1200 for performing (or for a part of the migration process) at an IAB node (such as a mobile IAB node or mIAB node) for a migration process in which the MT of the IAB node is migrated (such as continuously migrated) from a second IAB topology to a third topology, these topologies being different from the first IAB topology to which the IAB node belongs. Method 1200 is used to manage the continuous MT migration at the IAB node towards a target IAB topology different from the IAB topologies controlled by its F1 terminated donor CU and its source non-F1 terminated donor CU. For example, referring to Figure 8 shown in and for Figure 8For the IAB communication system described above, the IAB node performing method 1200 may be a mobile IAB node 870 belonging to the IAB topology 8001 controlled by the IAB donor CU 801 (e.g., the F1 termination donor CU of the mobile IAB node 870 that maintains an F1 connection with the mobile IAB node 870). The handover process may involve the MT 871 of the mIAB node 870 migrating from the IAB donor DU 806 in the IAB topology 8002 controlled by the IAB donor CU 802 (e.g., the non-F1 termination donor CU of the mobile IAB node 870 that has an RRC connection with the mobile IAB node 870 and is operating as the source non-F1 termination donor CU) to the IAB donor DU 807 in the IAB topology 8003 controlled by the IAB donor CU 803 (e.g., the non-F1 termination donor CU of the mobile IAB node 870 that is operating as the target non-F1 termination donor CU). Such a handover involves switching the routing path used by the mobile IAB node 870 from a routing path including the parent IAB node 850, the IAB node 840, and the IAB donor DU 806 to a routing path including the parent IAB node 860 and the IAB donor DU 807. As Fig.12a shown in and for Fig.12a the method 1200 described above may be performed by software elements and / or hardware elements. The IAB node may be implemented in a communication device 400 as Figure 4 shown in and with reference to Figure 4 the communication device 400 described above, where as Fig.12a shown in and for Fig.12a the method described above is performed by one or more processing units (such as the central processing unit 411, etc.).

[0255] At step 1201, the IAB node (such as the IAB node 870) receives address information from the target non-F1 termination donor CU (such as the donor CU 803), where the address information includes one or more addresses associated with the target IAB donor DU (such as the donor DU 807, etc.) of the third IAB topology 8003 (where data associated with the IAB node is to be routed via the target IAB donor DU in the third IAB topology). Thus, the IAB node 807 may receive the (one or more) addresses of the target donor DU (such as the donor DU 807) in the IAB topology controlled by the target non-F1 termination donor CU. For example, the IAB node 870 may receive the (one or more) addresses of the target donor DU in a message (such as the RRC reconfiguration message 913 or 1117 described above, etc.).

[0256] In step 1202, the IAB node may send the identifier of the target non-F1 terminating donor CU to its F1 terminating donor CU (such as donor CU 801) that controls another IAB topology. For example, the IAB node 870 may send identification information for identifying the target non-F1 terminating donor CU 803. The identification information may include identifiers such as PCI or NCGI for the target cell, based on which the F1 terminating donor CU 801 can identify the target non-F1 terminating donor CU 803.

[0257] In step 1203, the IAB node sends the (one or more than one) address(es) of the received target donor DU to its F1 terminating donor CU. For example, the IAB node 870 may send address information including one or more than one address of the target donor DU 807 in a message (such as the DU message 922 as described above). The identification information for identifying the target non-F1 terminating donor CU 803 may also be sent in the same message as the address information (for example, message 922) or in a separate message.

[0258] In the example, the IAB node 870 / 570 may also send identification information including the (one or more than one) identifier(s) of the mobile IAB node known to two IAB donor CUs (the F1 terminating donor CU 801 and the source non-F1 terminating donor CU 802). For example, the message may include one or more than one of the following: the information element F1-Terminating IAB-donor UEXnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donorUE XnAP ID and the (one or more than one) BAP address(es) assigned to the IAB node.

[0259] In an example method (not explicitly shown in the drawings) for handover handling in which the MT of an IAB node is handed over from a second IAB donor CU (source non-F1 / RRC-terminating donor CU) managing a second IAB topology to a third IAB donor CU (target non-F1 / RRC-terminating donor CU) managing a third IAB topology (where the IAB node is managed by a first IAB donor CU (F1-terminating donor CU) managing a first IAB topology), the IAB node sends identification information for identifying the target non-F1 / RRC-terminating donor CU to its F1-terminating donor CU (such as donor CU 801) that controls another IAB topology. For example, the IAB node 870 may send identification information for identifying the target non-F1-terminating donor CU 803. The identification information may include an identifier such as PCI or NCGI for the target cell, based on which the F1-terminating donor CU 801 can identify the target non-F1-terminating donor CU 803. The IAB node 870 / 570 may further send identification information for identifying the mobile IAB node, such as (one or more) identifiers associated with the mobile IAB node (e.g., assigned or known by the source non-F1 / RRC-terminating donor CU 802 when migrating to a topology controlled by the source non-F1 / RRC-terminating donor CU 802, or assigned or known by the target non-F1 / RRC-terminating donor CU 803 when migrating to a topology controlled by the target non-F1 / RRC-terminating donor CU 803). For example, the message may include one or more of the following: information element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID (assigned by (one or more) RRC-terminating donor CUs) or RRC-Terminating IAB-donor UE XnAP ID and (one or more) BAP addresses assigned to the IAB node (e.g., BAP addresses assigned to the IAB node by the source and / or target non-F1 / RRC-terminating donor CUs).Thus, by means of identification information (e.g., address information (such as the address(es) of the third or target donor DU to which the IAB node will or has migrated, etc.) and / or identification information for identifying the third IAB donor CU (such as PCI or NCGI, etc.)) sent by the second IAB donor CU (non-F1 terminated donor CU or RRC terminated donor CU) or the first IAB donor CU (F1 terminated donor CU) to the IAB node, the F1 terminated donor CU can be informed of the migration of the MT of the IAB node between two different topologies, and then the routing path used by the IAB node 870 based on the received information can be updated to a new routing path for routing data to / from the IAB node via the topology managed by the target non-F1 / RRC terminated donor CU.

[0260] Figure 12b FIG. is a flowchart showing an example method 1210 for performing (or a part of) a migration process for the MT of an IAB node at a second IAB donor CU (e.g., the source non-F1 terminated donor CU of the IAB node) according to one or more embodiments of the present invention. The method 1210 is used to manage the continuous MT migration of the IAB node towards a target IAB topology different from the IAB topology controlled by the F1 terminated donor CU of the IAB node at the source non-F1 terminated donor CU of the IAB node. For example, referring to Figure 8 shown in and for Figure 8 the IAB communication system described, the second IAB donor CU for performing the method 1210 can be the IAB donor CU 802 (e.g., the non-F1 terminated donor CU having an RRC connection with the IAB node 870 of the IAB node 870). The IAB node can be the mobile IAB node 870 belonging to the IAB topology 8001 controlled by the IAB donor CU 801 (e.g., the F1 terminated donor CU maintaining an F1 connection with the mobile IAB node 870 of the mobile IAB node 870). The migration process may involve the MT 871 of the mIAB node 870 migrating from the IAB donor DU 806 in the IAB topology 8002 controlled by the IAB donor CU 802 operating as the source non-F1 terminated donor CU to the IAB donor DU 807 in the IAB topology 8003 controlled by the IAB donor CU 803 operating as the target non-F1 terminated donor CU. As Figure 12b shown in and for Figure 12b the method 1210 described can be performed by software elements and / or hardware elements. The non-F1 terminated IAB donor CU can be implemented in the communication device 400 as shown in and referring to Figure 4 shown in and Figure 4 described, where as Figure 12b shown in and for Figure 12bThe method described above is performed by one or more processing units (such as the central processing unit 411, etc.).

[0261] At step 1211, the source non-F1 terminating donor CU (such as donor CU 802) of the IAB node (such as IAB node 870) detects the migration of the MT part of the IAB node to the 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 is to migrate to the target IAB donor DU 807 of the IAB topology 8003, where data associated with the IAB node is to be routed via the target IAB donor DU 807 in the IAB topology 8003. This information can be obtained by the source non-F1 terminating donor CU 802 itself through a decision (such as the determination made) when receiving a measurement report from the IAB node 870 (such as the measurement report 911 described above, etc.), or this information can be obtained by receiving a UE context release message related to the IAB node 870 (such as the messages 915, 1115 described above, etc.) from the target non-F1 terminating donor CU 803 of the IAB node.

[0262] At step 1212, the source non-F1 terminating donor CU 802 sends the identifier of the target non-F1 terminating donor CU 803 and the identifier of the IAB node known to the two donor CUs (the F1 terminating donor CU 801 and the source non-F1 terminating donor CU 802) to the F1 terminating donor CU 801 that controls another IAB topology 8001. For example, the source non-F1 terminating donor CU 802 sends identification information for identifying the target non-F1 terminating donor CU 803. The identification information may include identifiers such as PCI or NCGI for the target cell, based on which the F1 terminating donor CU 801 can identify the target non-F1 terminating donor CU 803.

[0263] Fig.12c is a flowchart showing an example method 1220 performed at a first donor CU (for example, the F1 terminating donor CU of an IAB node) for the migration process of the MT of the IAB node (or for a part of the migration process). The method 1220 is used to manage the continuous MT migration of the IAB node towards a target IAB topology different from the IAB topology controlled by the source non-F1 terminating donor CU of the IAB node. For example, referring to Figure 8 shown in and for Figure 8For the IAB communication system described above, the first IAB donor CU performing method 1220 may be IAB donor CU 801 (e.g., the F1-terminating donor CU of IAB node 870 that maintains an F1 connection with IAB node 870). The IAB node may be mobile IAB node 870 belonging to IAB topology 8001 controlled by IAB donor CU 801. The handover process may involve the MT 871 of mIAB node 870 migrating from IAB donor DU 806 in IAB topology 8002 controlled by IAB donor CU 802 operating as a source non-F1-terminating donor CU to IAB donor DU 807 in IAB topology 8003 controlled by IAB donor CU 803 operating as a target non-F1-terminating donor CU. As Fig.12c shown and for Fig.12c the method 1220 described above may be performed by software elements and / or hardware elements. The F1-terminating IAB donor CU may be implemented in the communication device 400 as Figure 4 shown and with reference to Figure 4 the communication device 400 described above, where the method as Fig.12c shown and for Fig.12c described above is performed by one or more processing units (such as central processing unit 411, etc.).

[0264] At step 1221, the F1-terminating donor CU (such as IAB donor CU 801) receives identification information for identifying the target non-F1-terminating donor CU 803. The identification information may include an identifier such as PCI or NCGI for the target cell to which IAB node 870 has migrated, based on which the F1-terminating donor CU 801 can identify the target non-F1-terminating donor CU 803. For example, the F1-terminating donor CU (such as IAB donor CU 801) receives the identifier of the target non-F1-terminating donor CU 803 from the source non-F1-terminating donor CU 802 of the IAB node whose MT has migrated in IAB topology 8002 controlled by the source non-F1-terminating donor CU 802, as well as the identifier of the IAB node known to both donor CUs (F1-terminating donor CU 801 and source non-F1-terminating donor CU 802). Alternatively, the identifier of the target non-F1-terminating donor CU is received at the F1-terminating donor CU 801 from IAB node 870.

[0265] At step 1222, the F1-terminating donor CU 801 terminates the receipt by the donor CU 801 from the IAB node 870 of address information including one or more addresses associated with the target IAB donor DU 807 of the IAB topology 8003, wherein data associated with the IAB node 870 is to be routed via the target IAB donor DU 807 in the IAB topology 8003. For example, the F1-terminating donor CU 801 receives the (one or more) addresses of the target donor DU 807 in the IAB topology controlled by the target non-F1-terminating donor CU 803 for the IAB node.

[0266] At step 1223, the F1-terminating donor CU 801 may update the routing path used by the IAB node 870 based on the received information to update the routing path used by the IAB node 870 (e.g., the F1-C routing path and the F1-U routing path) to a new routing path for routing data to / from the IAB node via the target donor DU 506. For example, the F1-terminating donor CU updates the F1 path (control plane data path 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-terminating donor CU 803 of the IAB node.

[0267] Fig.13 FIG. 1300 is a schematic simplified diagram illustrating some example message flows for performing continuous MT migration of an IAB node towards a target IAB topology (including the setup of control data paths and user data paths) according to one or more embodiments of the present invention.

[0268] The figure shows an IAB node 1301, which may be a mobile IAB node such as the IAB node 870 and / or Figure 8 the IAB node 123 as Figure 1 constituted by a mobile terminal (MT) 1303 (identified as IAB-MT) and a distributed unit (DU) 1302 (identified as IAB-DU). The figure also shows: a source non-F1-terminating donor CU (or non-F1 donor CU) 1305 that terminates the RRC connection to the IAB node 1301 via the IAB-MT 1303, an F1-terminating donor CU (or F1 donor CU) 1304 that terminates the F1 connection to the IAB node 1301 via the IAB-DU 1302, and a target non-F1 donor CU 1306 that becomes the new non-F1-terminating donor CU for the IAB node 1301 during the process. By way of example and with reference to Figure 8For the IAB communication system, the F1 terminating donor CU 1304 for the IAB node is 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 thus the source non-F1 terminating donor CU 1305 is the donor CU 802. When the IAB node moves towards 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 be migrated, and thus the target non-F1 terminating donor CU 1306 is the donor CU 803.

[0269] At the start of the flowchart 1300, it is assumed that the control path (F1-C) and user path (F1-U) set by the F1 donor CU 1304 to reach the IAB node 1301 use one or several backhaul paths in the IAB topology 8002 controlled by a donor DU not shown in Fig.13 For example, referring to Figure 8 , one such backhaul path may include the donor DU 806.

[0270] The first part of the flowchart describes the process 1310 that causes the IAB-MT 1303 to migrate to the IAB topology 8003 controlled by the target non-F1 donor CU 1306. It includes the establishment of a new path for the RRC protocol message (e.g., setting up a path to support F1-C traffic to / from the target non-F1 donor CU).

[0271] In fact, it is assumed that the source non-F1 donor CU 1305 that receives the measurement report 1311 from the IAB node 1301 initiates the MT migration or consecutive MT migrations of the IAB node 1301 to another IAB topology.

[0272] The measurement report 1311 is sent by the source non-F1 donor CU 1305 through the IAB node 1301 (e.g., Figure 8The F1 message UL RRC MESSAGE TRANSFER sent by the source parent IAB node of the parent IAB node 850 in (specified in TS 38.423) is received. The F1 message UL RRC MESSAGE TRANSFER embeds an RRC message and a measurement report sent by the IAB-MT 1303 to the DU part of the source parent IAB node. The measurement report is the result of regular measurements made by the IAB-MT 1303 on signals received from the serving cell and one or more target cells (such as signal synchronization blocks (SSBs) transmitted in the serving cell and target cells, etc.). The target cell can be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). Once the IAB-MT 1303 detects at least one SSB that meets the predefined criteria (e.g., received power exceeding a predefined threshold), a measurement report can be generated and transmitted to provide radio link quality information to different cells near the IAB node 901. The identification of each target cell is included in the measurement report to allow the non-F1 donor CU 1305 to identify the target CU associated with each target cell.

[0273] Based on the received measurement report, the source non-F1 donor CU 1305 can detect that the IAB node 1301 receives radio signals with better quality in the target cell controlled by the target parent IAB node compared to the source serving cell. Taking the target parent IAB node (e.g., Figure 8 the IAB node 860 in) that belongs to a different IAB topology from the source parent IAB node (e.g., Figure 8 the IAB node 850 in) as an example, the source non-F1 donor CU 1305 can decide to apply the handover preparation process to the IAB node 1301.

[0274] The migration of the IAB-MT 1303 is triggered by the handover request 1312 message sent by the source non-F1 donor CU 1305 to the F1 donor CU 1304 of the IAB node 1301. This message 1312 can be the HANDOVER REQUEST message specified in Section 9.1.1.1 of TS 38.423 V17.2.0, but with a new information element indicating the handover to be performed by the F1 donor CU 1304 towards the target non-F1 donor CU 1306. Thus, in addition to the other information elements existing in the message as specified in TS 38.423, this message also includes the identifier of the IAB node 1301 known to the two donor CUs (source non-F1 donor CU 1305 and F1 donor CU 1304) and the identifier of the target non-F1 donor CU 1306.

[0275] Upon receiving message 1312, the F1 donor CU 1304 triggers the conventional handover preparation procedure 1313 as described in Section 8.2.1 of TS 38.423 V17.2.0, where the F1 donor CU 1304 sends a HANDOVER REQUEST message including the necessary information related to the IAB-MT 1303 to the target non-F1 donor CU 1306, enabling the handover to proceed. For example, the message includes the identity of the target cell to which the IAB node 1301 will hand over, and thus its identity is used to control the target parent IAB node of the target cell (e.g., IAB node 860). After requesting the UE context setup for the IAB node 1301 from the target parent IAB node, the target non-F1 donor CU 1306 performs admission control and provides the new RRC configuration information together with the HANDOVER REQUEST ACKNOWLEDG message to the F1 donor CU 1304. Then, the F1 donor CU 1304 forwards this response to the source non-F1 donor CU 1305 via the message handover response 1314 (which can be a copy of the received F1 message HANDOVER REQUEST ACKNOWLEDGE). In Fig.13 the individual steps of the handover process are not shown, and the Fig.13 box 1313 representing the IAB-MT handover preparation is shown for simplicity.

[0276] Then, the source non-F1 donor CU 1305 can relay the RRC configuration information to the IAB-MT 1303 via the RRC reconfiguration message 1315. In fact, the message 1315 is first embedded in the F1 message UE CONTEXTMODIFICATION REQUEST (UE context modification request) specified in TS 38.473 and sent by the source non-F1 donor CU 1305 to the source parent IAB node of the IAB node 1301 (e.g., IAB node 850). Then, this source parent IAB sends the RRC reconfiguration message 1315 to the IAB-MT 1303. In particular, the RRC reconfiguration message 1315 contains the (one or more) transport network layer (TNL) addresses (i.e., (one or more) IP addresses) identifying the target donor DU for packet routing (e.g., data routing). In Figure 8 the example, the (one or more) addresses of the donor DU 807 replace the (one or more) addresses of the donor DU 806.

[0277] At the IAB node 1301, towards the target parent IAB node (e.g., Figure 8After the random access procedure of the IAB node 860) in, the IAB node 1301 sends an RRC reconfiguration complete message 1316 to the target non-F1 donor CU 1306 (via the target parent IAB node and the F1 message UL RRCMESSAGE TRANSFER embedded with RRC reconfiguration complete information).

[0278] Procedure 1310 ends with the Xn message UE CONTEXT RELEASE 1315 specified in TS 38.423 sent by the target non-F1 donor CU 1306 to the F1 donor CU 1304. This message can be forwarded by the F1 donor CU 1304 to the source non-F1 donor CU 1305. However, the identifiers of the IAB node 1301 at the F1 donor CU 1304 and the source non-F1 donor CU 1305 are retained by these two donor CUs because the F1 path used by the IAB node 1301 can still be used through the IAB topology controlled by the source non-F1 donor CU 1305.

[0279] To complete the continuous MT migration of the IAB node 1301, the control data path in the IAB topology of the target non-F1 donor CU 1306 is set using step 1320 corresponding to step 920 of Fig. 9 In this step 1320, the IAB node 1301 can inform the F1 donor CU 1304 of the address(es) of the target donor DU(s). In addition, the user data path is set using step 1330 corresponding to Fig.10 step 1030 of

[0280] In the case where the DU migration of the IAB node 1301 is in progress when the handover request message 1312 is received, the F1 donor CU 1304 can wait for the completion of the DU migration before starting or initiating the MT handover preparation step 1313. Alternatively, the F1 donor CU can reject the handover request and directly respond to the source non-F1 donor CU 1305 with a handover response message 1314 indicating the rejection (e.g., the handover response is negative, which indicates that the migration or handover of the MT has been rejected). For example, the F1 donor CU 1304 can determine whether the migration process for the DU of the IAB node 1301 (e.g., IAB-DU 1102) has been initiated (e.g., and is in progress), and in response to determining that the migration process for the DU of the IAB node has been initiated, the F1 donor CU 1304 can delay the MT migration of the IAB node to the third IAB donor CU until the migration process for the DU of the IAB node is completed. Alternatively, in response to determining that the migration process for the DU of the IAB node has been initiated, the F1 donor CU 1304 can send a handover response for rejecting the handover request to the second IAB donor CU. In Fig.13During the execution of the process and until steps 1320 and 1330 are completed, the F1 donor CU can avoid initiating the DU migration of the IAB node 1301. For example, the F1 donor CU can delay 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, such as until the establishment of one or more routing paths (e.g., for F1 traffic) is completed. Each of these steps helps to avoid the concurrency of the MT migration process and the DU migration process that may cause at least one of the migrations to fail.

[0281] As an alternative 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 can confirm the request by sending a handover response message 1314 to the non-F1 donor CU 1305. Upon receiving this message 1314, the non-F1 donor CU 1305 performs the MT migration (with the target non-F1 donor CU 1306) as described in step 912 above for Fig. 9 Before sending the handover response message 1314 to the non-F1 donor CU 1305, the F1 donor CU 1304 can check whether the co-located IAB-DU 1302 of the IAB-MT 1303 for the IAB node 1301 and the DU migration are in progress. If the DU migration is in progress, the F1 donor CU 1304 can wait for the completion of the DU migration before sending the handover response message 1314 with an affirmative response. In other words, the F1 donor CU 1304 sends a handover response as an affirmative response in the handover response message 1314 when the ongoing DU migration is completed to trigger the non-F1 donor CU 1305 to perform the MT migration. Alternatively, when the F1 donor CU 1304 determines that the DU migration is in progress, the F1 donor CU 1304 can send a handover response as a negative response in the handover response message 1314 (e.g., indicating that the F1 donor CU 1304 has rejected the handover request).

[0282] Figure 14a to Figure 14b is a diagram showing, according to one or more embodiments of the present invention, in a wireless communication system (such as the communication system shown and described with reference to Figure 1 shown and described, and with reference to Figure 8Flowchart of an example method performed at different network nodes in the IAB communication system shown and described. The example methods at different network nodes are for handover processing (or for a part of the handover processing), in which the MT of an IAB node migrates (e.g., continuously migrates) 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), where the IAB node is managed (or controlled or served) by a first IAB donor CU of a first IAB topology (e.g., the F1 termination donor CU of the IAB node that maintains an F1 connection with the IAB node). The second IAB donor CU and the third IAB donor CU are non-F1 termination donor CUs of the IAB node. After the source IAB donor CU determines that the MT of the IAB node is to migrate from the second IAB topology to the third IAB topology, the first IAB donor CU or the F1 termination donor CU receives a handover request from the source IAB donor CU. The handover request (e.g., the above-mentioned message 1312) includes IAB node identification information for identifying the IAB node having the MT to be migrated, and identification information such as the PCI or NCGI of the target cell to which the MT is to migrate, which is used to identify the target IAB donor CU that manages the third IAB topology to which the MT of the IAB node is to migrate. Then, the F1 termination donor CU can initiate a process for migrating the MT of the IAB node to the target IAB donor CU (e.g., a process 1313 such as described above, which involves the F1 termination donor CU collaborating with the target IAB donor CU and the source IAB donor CU). Alternatively, the source non-F1 termination donor CU can initiate a process for migrating the MT of the IAB node to the target IAB donor CU. After the migration is completed (e.g., the handover has been accepted by the target IAB donor CU), the F1 termination donor CU sends a handover response to the source IAB donor CU, which may include configuration information associated with one or more routing paths for routing data associated with the IAB node in the third IAB topology. The configuration information includes one or more addresses (such as (one or more) IP addresses, (one or more) TNL addresses) associated with the target IAB donor DU of the third IAB topology, where data (e.g., F1 traffic, user traffic, control traffic) is to be routed for the IAB node via / through the target IAB donor DU in the third IAB topology (e.g., data will be routed to / from the IAB node in the third IAB topology through the target IAB donor DU). The configuration information received at the F1 termination donor CU can be provided to the IAB node (e.g., via the source IAB donor CU).

[0283] Thus, by means of a handover request and configuration information received at a first IAB donor CU (F1-terminating donor CU) of an IAB node, the F1-terminating donor CU can be informed of the migration of the MT of the IAB node between two different topologies (e.g., 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)); and at least one new routing path that is to be used to route data (e.g., user traffic and control traffic) associated with or for the migrated IAB node in a third IAB topology controlled by a target non-F1-terminating donor CU.

[0284] Fig.14a is a flowchart of an example method 1400 that illustrates, according to one or more embodiments of the present invention, the performance at a second IAB donor CU (e.g., a source non-F1-terminating donor CU of an IAB node) for a handover process (or for a part of the handover process) for the MT of the IAB node. The method 1400 is used to manage the continuous MT handover of an IAB node at a source non-F1-terminating donor CU of the IAB node towards a target IAB topology different from the IAB topology controlled by the F1-terminating donor CU of the IAB node. For example, referring to Figure 8 shown in and for Figure 8 the IAB communication system described, the second IAB donor CU performing the method 1400 can be the IAB donor CU 802 (e.g., a non-F1-terminating donor CU having an RRC connection with the IAB node 870 of the IAB node 870). The IAB node can be the mobile IAB node 870 belonging to the IAB topology 8001 controlled by the IAB donor CU 801 (e.g., an F1-terminating donor CU maintaining an F1 connection with the mobile IAB node 870 of the mobile IAB node 870). The handover process can involve the MT 871 of the mIAB node 870 migrating from the IAB donor DU 806 in the IAB topology 8002 controlled by the IAB donor CU 802 operating as a source non-F1-terminating donor CU to the IAB donor DU 807 in the IAB topology 8003 controlled by the IAB donor CU803 operating as a target non-F1-terminating donor CU. As Fig.14a shown in and for Fig.14a the method 1400 described can be performed by software elements and / or hardware elements. The non-F1-terminating IAB donor CU can be implemented in a communication device 400 as shown in and referring to Figure 4 shown in and referring to Figure 4 wherein as Fig.14a shown in and for Fig.14aThe method described above is performed by one or more processing units (such as the central processing unit 411, etc.).

[0285] At step 1401, the source non-F1 terminating donor CU (such as donor CU 802) of the IAB node (such as IAB node 870) detects the migration of the MT part of the IAB node to the 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 IAB node 870 is to migrate from the second IAB topology 8002 to the third IAB topology 8003. This information can be obtained by the source non-F1 terminating donor CU's own decision (such as the determination made) when receiving a measurement report from the IAB node. For example, based on the measurement of the signal received at the IAB node 870, the measurement report indicates that the MT 871 of the IAB node 870 should migrate to a cell in, for example, the third IAB topology.

[0286] At step 1402, the source non-F1 terminating donor CU 802 sends a handover request for the IAB node towards the target non-F1 terminating donor CU 803 to the F1 terminating donor CU 801 that controls the other IAB topology 8001. The handover request includes identification information such as PCI or NCGI of the target cell in the third IAB topology to which the MT is to be migrated, and this identification information is used to identify the target IAB donor CU 803 that manages the third IAB topology 8003 to which the MT of the IAB node 870 is to migrate. The handover request may also include identification information for identifying the IAB node 870 having the MT to be migrated. For example, the request includes the identifier of the target non-F1 terminating donor CU 803 and the identifier of the IAB node known to 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.

[0287] At step 1403, the source non-F1 terminating donor CU 802 may receive a handover response from the F1 terminating donor CU 801 of the IAB node. The handover response may indicate that the handover has been accepted (positive handover response) when the handover has been accepted by the target non-F1 terminating donor CU 803, and may indicate that the handover has been rejected (negative handover response) when the handover has been rejected by the target non-F1 terminating donor CU. When the handover has been accepted, the handover response may include configuration information associated with one or more routing paths for routing data associated with the mobile IAB node in the third IAB topology 8003. The configuration information may include one or more addresses associated with the target IAB donor DU 807 of the third IAB topology, where data associated with the IAB node 870 is to be routed via or through the target IAB donor DU 807 in the third IAB topology. The configuration information embedded in the handover response is forwarded to the IAB node 870. The response may be the handover response 1314 described above.

[0288] In an alternative example, when the F1 terminating donor CU 801 receives the handover request message 1312 from the source non-F1 terminating donor CU 802, the F1 terminating donor CU 801 may confirm the request by sending a handover response (e.g., handover response message 1314) to the non-F1 terminating donor CU 802. When receiving the handover response at step 1403, the non-F1 terminating donor CU 802 performs an MT migration (with the target non-F1 terminating donor CU 803) as described for step 912 above for Fig. 9 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 a co-located IAB-DU 872 of the IAB-MT 871 for the IAB node 870, a DU migration is in progress. If there is an ongoing DU migration, the F1 terminating donor CU 801 may wait for the completion of the DU migration before sending the handover response in the handover response message 1314 with a positive response. In other words, the F1 terminating donor CU 801 sends the handover response as a positive response when the ongoing DU migration is completed to trigger the non-F1 terminating donor CU 802 to perform an MT migration. Alternatively, when the F1 donor CU 1304 determines that a DU migration is in progress, the F1 donor CU 1304 may send a handover response as a negative response (e.g., indicating that the F1 donor CU 1304 has rejected the handover request) in the handover response message 1314.

[0289] Fig.14bis a flowchart illustrating an example method 1410 that is performed at a first donor CU (e.g., the F1-terminating donor CU of an IAB node) for a handover process (or for a part of the handover process) for a MT of an IAB node. Method 1410 is for managing a continuous MT handover of an IAB node towards a target IAB topology that is different from an IAB topology controlled by a source non-F1-terminating donor CU of the IAB node. For example, referring to Figure 8 as shown in and for Figure 8 the IAB communication system described, the first IAB donor CU for performing method 1410 can be IAB donor CU 801 (e.g., the F1-terminating donor CU of IAB node 870 that maintains an F1 connection with IAB node 870). The IAB node can be a mobile IAB node 870 belonging to an IAB topology 8001 controlled by IAB donor CU 801. The handover process can involve the MT 871 of mIAB node 870 being handed over from an IAB donor DU 806 in an IAB topology 8002 controlled by IAB donor CU 802 operating as a source non-F1-terminating donor CU to an IAB donor DU 807 in an IAB topology 8003 controlled by IAB donor CU 803 operating as a target non-F1-terminating donor CU. As Fig.14b shown in and for Fig.14b the method 1410 described can be performed by software elements and / or hardware elements. The F1-terminating IAB donor CU can be implemented in a communication device 400 as Figure 4 shown in and for Figure 4 the communication device described, where the method as Fig.14b shown in and for Fig.14b described is performed by one or more processing units (such as central processing unit 411, etc.).

[0290] At step 1411, the F1-terminating donor CU (such as IAB donor CU 801) receives a handover request for requesting the migration of the MT of the IAB to the third IAB topology. The handover request includes IAB node identification information for identifying the IAB node 870 having the MT to be migrated and identification information for identifying the target IAB donor CU 803 of the third IAB topology 8003 to which the MT of the IAB node 870 is to be migrated. For example, the F1-terminating donor CU (such as donor CU 801) receives, from the source non-F1-terminating donor CU (such as donor CU 802) of the IAB node (such as IAB node 870), a handover request for the IAB node towards the target non-F1-terminating donor CU (such as donor CU 803). The request includes the identifier of the target non-F1-terminating donor CU 803 and the identifier of the IAB node known to the two donor CUs (the F1-terminating donor CU 801 and the source non-F1-terminating donor CU 802). The request may be the handover request 1312 described above.

[0291] At step 1412, the F1-terminating donor CU 801 may (e.g., in response to receiving a handover request from a source non-F1-terminating donor CU such as donor CU 802) use the handover procedure to perform the MT migration of the IAB node 870 towards the target non-F1-terminating donor CU 803. For example, the F1-terminating donor CU 801 may use the handover procedure 1313 described above to initiate and perform the MT migration of the IAB node 870. Migrating the MT of the IAB node 870 to the target IAB donor CU 803 may include the source F1 donor CU 801 sending a request to the target IAB donor CU 803 to migrate the MT of the IAB node 870 to the target cell of the third IAB topology (e.g., the target cell of the IAB node of the third IAB topology, where, by measurement of the radio signal received at the IAB node, the target cell is determined to provide a better quality radio signal compared to that in the source serving cell). In response, the source F1 donor CU 801 receives from the third IAB donor CU 803 a response including configuration information associated with one or more routing paths for routing data associated with the IAB node in the third IAB topology.

[0292] At step 1413, F1 terminating donor CU 801 terminates the transfer response sent by the source non-F1 terminating donor CU 802 to the target non-F1 terminating donor CU 803. The transfer response may indicate that the transfer has been accepted (positive transfer response) when the transfer has been accepted by the target non-F1 terminating donor CU 803, and may indicate that the transfer has been rejected (negative transfer response) when the transfer has been rejected by the target non-F1 terminating donor CU. When the transfer has been accepted, the transfer response may include the configuration information for the IAB node 870 received from the target non-F1 terminating donor CU 803 at step 1412. For example, the configuration information is associated with one or more routing paths for routing data associated with the mobile IAB node 870 in the third IAB topology 8003 based on the configuration information received from the target IAB donor CU 803, and may include one or more addresses associated with the target IAB donor DU (such as IAB donor DU 807, etc.) of the third IAB topology, where the data for the mobile IAB node 870 is to be routed via the one or more addresses in the third IAB topology. The response may be the transfer response 1314 described above.

[0293] Although Fig.14b not shown in the figure, the source F1 donor CU 801 may determine whether the migration process of the DU (e.g., IAB-DU 872) for the IAB node 870 has been initiated (e.g., and is in progress), and in response to determining that the migration process of the DU for the IAB node has been initiated, the source F1 donor CU 801 may delay migrating the MT of the IAB node to the target IAB donor CU 803 until the migration process of the DU for the IAB node is completed. Alternatively, in response to determining that the migration process of the DU for the IAB node has been initiated, the source F1 donor CU 801 may send a transfer response to the source non-F1 terminating donor CU 802 for rejecting the transfer request. In another example, the source F1 donor CU 801 may delay the initiation of the migration process of the DU for the IAB node 870 until the migration process of the MT for the IAB node is completed, such as until the setting of one or more routing paths (e.g., for F1 traffic) is completed.

[0294] Since the transfer response sent by the F1 terminating donor CU 801 in step 1413 can be sent without initiating the migration of the MT, step 1412 is Fig.14bIt is shown by a dashed line in the figure. For example, when the F1-terminated donor CU 801 receives a handover request (e.g., in the handover request message 1312) from the source non-F1-terminated donor CU 802 at step 1410, the F1-terminated donor CU 801 can confirm the request at step 1413 by sending a handover response (e.g., handover response message 1314) to the non-F1-terminated donor CU 802. As described above, upon receiving the handover response, the non-F1-terminated donor CU 802 performs the MT migration (with the target non-F1-terminated donor CU 803) as described in step 912 for Fig. 9 Before sending the handover response (e.g., handover response message 1314) to the non-F1-terminated donor CU 802, the F1-terminated donor CU 801 can check whether the co-located IAB-DU 872 of the IAB-MT 871 for the IAB node 870 and the DU migration are in progress. If there is an ongoing DU migration, the F1-terminated donor CU 801 can wait for the completion of the DU migration before sending the handover response in the handover response message 1314 with a positive response. In other words, the F1-terminated donor CU 801 sends the handover response as a positive response when the ongoing DU migration is completed to trigger the non-F1-terminated donor CU 802 to perform the MT migration. Alternatively, when the F1 donor CU 1304 determines that the DU migration is in progress, the F1 donor CU 1304 can send a handover response in the handover response message 1314 at step 1413, and the handover response is a negative response (e.g., indicating that the F1 donor CU 1304 has rejected the handover request).

[0295] Thus, the migration of the MT can be performed by the F1-terminated donor CU 801 in response to receiving a handover request from the source non-F1-terminated donor CU 802 (at step 1411), or as described above, the migration of the MT can be initiated by the F1-terminated donor CU 801 in response to receiving a handover request from the source non-F1-terminated donor CU 802 (at step 1411), but is performed by the source non-F1-terminated donor CU 802.

[0296] Fig.15 FIG. 1500 is a schematic simplified diagram illustrating some example message flows according to one or more embodiments of the present invention for avoiding initiating a DU migration of an IAB node during consecutive MT migrations of the IAB node. Consecutive MT migrations can involve multiple MT migrations between different parent IAB nodes (directly or indirectly) connected to different donor DUs, where these different donor DUs are all managed by the same donor CU but are different from the donor CU of the DU of the serving IAB node. Consecutive MT migrations can alternatively involve new MT migrations between different parent IAB nodes managed by different donor CUs different from the donor CU of the DU of the serving IAB node.

[0297] The Fig.15 shows: a source non-F1 terminated donor CU (or non-F1 donor CU) 1505 that terminates the RRC connection to an IAB node (not shown), where the IAB node can be a mobile IAB node such as the IAB node 870 as in Figure 8 and / or Figure 1 the IAB node 123, which is composed of a mobile terminal (MT) and a distributed unit (DU); an F1 terminated donor CU (or F1 donor CU) 1504 that terminates the F1 connection to the IAB node; and a target non-F1 donor CU 1506 that should become the new non-F1 terminated donor CU for the IAB node. As an example and referring to Figure 8 the IAB communication system, the F1 terminated donor CU 1504 for the IAB node is the donor CU 801, the MT 871 of the IAB node 870 has migrated to the IAB topology 8002 managed by the donor CU 802, and thus the source non-F1 terminated donor CU 1505 is the donor CU 802. When the IAB node moves towards the IAB topology 8003, the IAB node 860 is identified as the target IAB node to which the MT 871 of the IAB node 870 can migrate, and thus the target non-F1 terminated donor CU 1506 is the donor CU 803.

[0298] The reasons for performing DU migration can be to reduce the processing load at the F1 donor CU 1504, or because the IAB node is geographically far from the F1 donor CU 1504 and close to an area where there is no longer Xn or IP connectivity between the F1 donor CU 1504 and the target F1 donor CU.

[0299] In short, the process for DU migration for an IAB node can be carried out according to the following process. When it is decided or determined by the source F1 donor CU of the IAB node to perform DU migration towards another IAB topology managed by another donor CU (which becomes the 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. For example, referring to Figure 8, the source F1 donor CU for the IAB node 870 can be the donor CU 801, which determines the DU migration of the IAB-DU 872 of the IAB node 870 towards the IAB topology 8003, and thus, the donor CU 803 is the target F1 donor CU. This may require activating a second logical DU entity in the IAB node via a message sent by the F1 donor CU to the IAB node. Thus, once the second logical DU entity in the IAB node is activated, the IAB node has two logical DU entities that share the same hardware for the BAP layer, RLC layer, and MAC layer. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. Each logical DU entity serves one or more cells. The (one or more) cells of one logical DU entity (e.g., the first logical DU) are identified by the identifier (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) of the (one or more) cells having a different value from the identifier of the other logical DU entity (e.g., the second logical DU). After activation, the second logical DU of the IAB node can send an F1 setup request message to the target F1 donor CU to request setting up an F1 connection between the IAB node and the target F1 donor CU. In the F1 setup response, the target F1 donor CU can request the second logical DU of the IAB node to activate the (one or more) new cells and can inform the source F1 donor CU of the activation of the (one or more) new cells.

[0300] The next step is to hand over the UEs served by the IAB node from the cell(s) of the first logical DU of the IAB node to the cell(s) of the second logical DU. The target F1 donor CU can perform a path switching procedure towards the core network to request the delivery of user data related to the UE via the second logical DU. Then, the target F1 donor CU must set up the (one or more) backhaul paths to / from the migrated IAB node in its own topology or, in the case where there is a backhaul path to an IAB node in the IAB topology controlled by the target F1 donor CU, through the IAB topology of the non-F1 donor CU of the IAB node. In the latter case, the target F1 donor CU can trigger a procedure to request traffic migration 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 completed, the source F1 donor CU can deactivate the first logical DU of the mobile IAB node. In addition, the source F1 donor CU can release the traffic (user traffic, control traffic) related to the UEs served by the IAB node through the first logical DU. If the traffic is offloaded in the IAB topology controlled by another donor CU (i.e., non-F1 donor CU), the source F1 donor CU can apply a procedure to request traffic release to the non-F1 donor CU.

[0301] The MT migration can be considered to include MT handover (such as for Fig. 9 the process 910 described or for Fig.10 the process 1010 described, etc.) and transport migration (F1-C / F1-U path setup) (such as for Fig. 9 the process 920 described and for Fig.10 the processes 1020 and 1030 described, etc.). If the F1 donor CU has changed during the DU migration, the MT handover should not be affected, but the transport migration may fail. The source donor CU of the mobile IAB-MT can send information related to the target donor CU of the mobile IAB-MT to the donor CU of the mobile IAB-DU after the IAB-MT handover (HO) is completed. However, if the F1 donor CU has changed during the MT handover, the old F1 donor CU will be informed instead of the new F1 donor CU, and a transport migration may occur. Since the protocol messages exchanged to support the DU migration are transmitted through the IAB topology managed by the non-F1 donor CU, it seems that the DU migration may be more affected by the concurrent MT migration. Therefore, the F1 setup process or the UE handover may fail due to a change in the IAB topology communicating with the migrated IAB node (the IAB topology change caused by the MT migration).

[0302] Therefore, based on the above description, it seems that if an MT migration is performed during a DU migration, the DU migration process may fail or may be interrupted at different steps. In fact, consecutive MT migrations of IAB nodes may involve setting up a new backhaul path through the new IAB topology, which results in some packet loss before all IAB donor CUs that have to communicate with the mobile IAB node are informed of the change. As a safety method to avoid service interruption at the UEs served by the IAB nodes, the DU migration should be performed and completed while the co-located MT remains connected to the same IAB donor CU.

[0303] Suppose the source non-F1 donor CU 1505 that receives the measurement report from the IAB node determines that the MT part of the IAB node needs to be handed over to the parent IAB node belonging to the IAB topology of the target non-F1 donor CU 1506 (e.g., the parent IAB node 860 of the IAB topology 8003), or (e.g., in the case where the IAB node 870 is initially connected to the parent IAB node 830 connected to the donor DU 805, and when the MT 871 of the IAB node 870 is migrated by the non-F1 donor CU 802 towards the parent IAB node 850 connected to the donor DU 806) towards the parent IAB node belonging to the IAB topology of the source non-F1 donor CU 1505 but involving a new IAB donor DU that communicates with the IAB node. Therefore, the MT migration process should be executed or initiated as described in the process Fig. 9 (for migration towards the new IAB topology) or Figure 6 (for migration towards the parent IAB node with the new IAB donor DU).

[0304] To prevent the triggering of a DU migration of the IAB node during this MT migration process (which starts from an MT handover process such as the process 910 etc. described Fig. 9 ), the source non-F1 donor CU 1506 sends an MT migration notification to the F1 donor CU 1504 for indicating that the MT of the IAB node is to be migrated to a new parent IAB node. The MT migration notification (or MT handover notification) can be included in the MT handover notification (or IAB NODE MIGRATION REQUEST message 1512) sent to the F1 donor CU 1504. The MT migration notification can be sent before performing the migration of the MT of the IAB node to the second parent IAB node (e.g., before the MT migration process / processing, e.g., before starting the MT handover process / processing).

[0305] In the example, before performing the IAB-MT handover preparation process 912 described in the reference Fig. 9 or before sending the reference Figure 6Before the aforementioned message 612, message 1512 is sent. As described above, message 612 includes information for identifying the target donor DU (or new donor DU) to which the IAB node is to be migrated to establish a new routing path via the target donor DU.

[0306] Assume that as referenced Fig.11 in the case where the IAB node triggers an RRC reconstruction procedure, the source non-F1 donor CU 1505 may inform the F1 donor CU 1504 of message 1512, which is sent after receiving, as part of the context retrieval procedure 1112 as referenced Fig.11 above, a message (e.g., RETRIEVE UE CONTEXT REQUEST message) for requesting the UE context of the IAB node from the target non-F1 donor CU 1506.

[0307] The MT migration notification includes IAB node identification information for identifying the IAB node having the MT to be migrated. The identification information may include at least one identifier of the IAB node. In the case of MT migration towards a new IAB topology, the notification may further include identification information for identifying the target non-F1 donor CU 1506. For example, message 1512 includes the (one or more than one) identifier(s) of the IAB node known to two donor CUs (F1 donor CU 1504 and source non-F1 donor CU 1505), and it may include the identifier of the target non-F1 donor CU 1506. Such (one or more than one) identifier(s) of the IAB node may include identifiers known to the F1-terminating donor CU and non-F1-terminating donor CU of the IAB node: for example, the message may include one or more than one of the following: Information Element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the (one or more than one) BAP address(es) assigned to the IAB node. The identification information (or the identifier for 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 to be migrated.

[0308] Upon receiving the 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 the migration process for the DU of the IAB node. In the case where the message 1512 indicates that the target non-F1 donor CU 1506 for MT handover corresponds to the target F1 donor CU for the migration of the co-located DU of the IAB node (e.g., the DU and the MT are to be migrated to the same donor CU), since the target non-F1 donor CU (and thus also the target F1 donor CU) is capable of concurrently handling the MT migration and the DU migration, the F1 donor CU 1504 may not disable the DU migration. However, the DU migration to another target F1 donor CU (e.g., a donor CU different from the donor CU to which the MT is to be migrated) is disabled.

[0309] Then, the F1 donor CU 1504 may respond to the source non-F1 donor CU 1505 by sending an MT handover response (or IAB NODE MIGRATION RESPONSE) message 1513. The source non-F1 donor CU 1505 may wait for this acknowledgment message 1513 to initiate the execution of the MT migration process 1514 (e.g., as described for Figure 6 , Fig. 9 , Fig.10 or Fig.11 ). For example, the F1 donor CU 1504 may perform the migration of the MT of the IAB node after receiving the MT migration response in the message 1513.

[0310] When the MT handover notification message 1512 is received and the DU migration process for the IAB node is in progress, the F1 donor CU 1504 may wait for the completion of the DU migration process before sending the MT handover response message 1513. As an alternative, the F1 donor CU 1504 may send an MT handover response (or IAB NODE MIGRATION REJECT) message 1513, which indicates that the MT handover is rejected because the DU migration is in progress (i.e., the reason for the rejection is included in the message 1513).

[0311] Once the MT migration operation 1514 is completed, the source non-F1 donor CU 1505 may send an MT handover completion message 1515 to the F1 donor CU 1505 (e.g., to indicate the completion of the migration of the MT of the IAB node). The message 1515 includes the identifier(s) of the IAB node known to both donor CUs (the F1 donor CU 1504 and the source non-F1 donor CU 1505), and it may include the identifier of the target non-F1 donor CU 1506.

[0312] After receiving the MT handover completion message 1515, the F1 donor CU 1504 may re-enable the DU migration of the IAB node at operation 1520.

[0313] Operation MT migration 1514 may correspond to the reference Figure 6 , Fig. 9 , Fig.10 or Fig.11 the execution of the processes described. In each of these processes, the F1 donor CU 1504 is involved at some point in time, and then the message 1515 may not be necessary. Therefore, operation 1520 may also be triggered after receiving an IAB transmission migration response (e.g., Fig.10 message 1036 or 1033 in

[0314] from the source F1 donor CU 1505 or the target F1 donor CU 1506). According to one example, the MT handover notification message 1512 may be the HANDOVER REQUEST message specified in section 9.1.1.1 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of an MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes the identifier of the relevant IAB node known to both donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and in addition to the other information elements present in the message as specified in TS 38.423, it may also include the identifier of the target non-F1 donor CU. Furthermore, the MT handover response message 1513 may be the HANDOVER REQUEST ACKNOWLEDGE message specified in section 9.1.1.2 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement of an MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. In the case of a rejection of the MT handover, the MT handover response message 1513 may be the HANDOVER PREPARATION FAILURE message specified in section 9.1.1.3 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of an MT handover of an IAB node including the reason for the rejection (e.g., due to a load problem).

[0315] According to another example, the MT handover notification message 1512 can be the NG-RAN NODE CONFIGURATION UPDATE message specified in section 9.1.3.4 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of the MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes the identifier of the relevant IAB node known to both donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and in addition to the other information elements present in the message as specified in TS 38.423, it may also include the identifier of the target non-F1 donor CU. Furthermore, the MT handover response message 1513 can be the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message specified in section 9.1.3.5 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement of the MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. In the case of a rejection of the MT handover, the MT handover response message 1513 can be the NG-RAN NODE CONFIGURATION UPDATE FAILURE message specified in section 9.1.3.6 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of the MT handover of an IAB node including the reason for the rejection (e.g., due to a load issue).

[0316] According to another example, the MT handover notification message 1512 can be the MOBILITY CHANGE REQUEST message specified in section 9.1.3.22 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of an MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. The message includes the identifier of the relevant IAB node known to two donor CUs (the source non-F1 donor CU sending the message and the F1 donor CU receiving the message), and in addition to other information elements present in the message as specified in TS 38.423, it may also include the identifier of the target non-F1 donor CU. Furthermore, the MT handover response message 1513 can be the MOBILITY CHANGE ACKNOWLEDGE message specified in section 9.1.3.23 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement of an MT handover of an IAB node to be performed between a source non-F1 donor CU and a target non-F1 donor CU. In the case of a rejection of the MT handover, the MT handover response message 1513 can be the MOBILITY CHANGE FAILURE message specified in section 9.1.3.24 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of an MT handover of an IAB node including the reason for the rejection (e.g., due to a load problem).

[0317] Fig.16a is a flowchart of an example method 1600 for managing the continuous MT migration of an IAB node at a second IAB donor CU (e.g., a source non-F1 terminating donor CU) of the IAB node in a manner that does not compete with the DU migration of the IAB node. The continuous MT migration of the IAB node involves the migration of the MT of the IAB node from a first parent IAB node of an IAB topology managed or controlled by the second IAB donor CU (e.g., a source non-F1 terminating donor CU) towards a second parent IAB node. In the example, the first parent IAB node involves or uses a first backhaul path including a first IAB donor DU of a second IAB topology managed by the second IAB donor CU to route data associated with the IAB node, and the second parent IAB node involves or uses a second backhaul path including a second IAB donor DU of the second IAB topology to route data associated with the IAB node (e.g., migrating between two different donor DUs in the same topology). In this case, as referred to above Figure 6As described above, the source non-F1 donor CU may determine to apply the CU-internal topology adaptation process for the IAB node. In another example, the second parent IAB node is part of a third IAB topology managed by a third IAB donor CU. In this case, for example, as described above with reference to Fig. 9 As described, the continuous MT migration of the IAB node is towards a target IAB topology different from the IAB topology controlled by the first IAB donor CU (e.g., the F1 termination donor CU) of the IAB node (e.g., the target IAB topology is not the IAB topology controlled by the F1 termination donor CU of the IAB node).

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

[0319] At step 1601, the source non-F1 terminated donor CU (or source non-F1 donor CU) (such as donor CU 802) of an IAB node (such as IAB node 870) determines that the MT of the IAB node is to migrate towards a second parent IAB node. For example, the source non-F1 donor CU 802 determines that the MT 871 of the IAB node 870 is to migrate continuously towards a target topology (such as IAB topology 8003) managed by a target non-F1 terminated donor CU (or target non-F1 donor CU) (such as donor CU 803, etc.). Alternatively, the source non-F1 donor CU 802 determines that the MT 871 of the IAB node 870 is to migrate continuously towards a parent IAB node (such as 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 of the IAB node 870 is to migrate is (directly or indirectly) connected to a donor DU different from the donor DU in the current backhaul path used by the IAB node 870.

[0320] At step 1602, the source non-F1 donor CU 802 sends an MT handover notification message for identifying the MT handover of the IAB node 870 to an F1 donor CU (such as donor CU 801, etc.). For example, the source non-F1 donor CU 802 sends an MT handover notification (or MT handover notice) indicating that the MT 871 of the IAB node 870 is to be migrated. The MT handover notification (or MT handover notice) includes identification information for identifying the IAB node having the MT to be migrated. As described above, the MT handover notification can be included in an MT handover notice (or IAB NODE MIGRATION REQUEST) message 1512. Referring to Fig.15 and the sending of message 1512, the source non-F1 donor CU 802 can send an MT handover notification (or MT handover notice) before performing the migration of the MT of the IAB node as described above.

[0321] At step 1603, the source non-F1 donor CU 802 can receive an MT handover response message (or MT migration response) from the F1 donor CU 801 as a response to the MT handover notification message in step 1602. As described above, the MT handover response (or MT migration response) can be included in an MT handover response (or IAB NODE MIGRATION RESPONSE) message 1513.

[0322] At step 1604, the source non-F1 donor CU 802 performs an MT migration process (e.g., including MT handover) for the IAB node 870. For example, the source non-F1 donor CU 802 may initiate the execution of the MT migration process 1514 starting from the MT handover after receiving the MT handover response (or IAB NODE MIGRATION RESPONSE) message 1513 (e.g., as described for Figure 6 , Fig. 9 , Fig.10 or Fig.11 ).

[0323] At step 1605, the source non-F1 donor CU 802 may send a message to the F1 donor CU 801 for indicating the completion of the MT migration for the IAB node 870. For example, as described above, the source non-F1 donor CU 802 may send the MT handover completion message 1515.

[0324] Fig.16b is a flowchart of an example method 1610 for migrating the DU of an IAB node during continuous MT migration of the IAB node according to one or more embodiments of the present invention. The method 1610 is performed at the first IAB donor CU (e.g., F1 terminating donor CU) of the IAB node. The method involves: disabling the DU migration of the IAB node during continuous MT migration of the IAB node at the F1 terminating donor CU of the IAB node. The continuous MT migration of the IAB node involves the migration of the MT of the IAB node from the first parent IAB node of the IAB topology managed or controlled by the second IAB donor CU (e.g., source non-F1 terminating donor CU) towards the second parent IAB node. In an example, the first parent IAB node involves or uses a first backhaul path including the first IAB donor DU of the second IAB topology managed by the second IAB donor CU to route data associated with the IAB node, and the second parent IAB node involves or uses a second backhaul path including the second IAB donor DU of the second IAB topology to route data associated with the IAB node (e.g., migrating between two different donor DUs in the same topology). In this case, as referred to above Figure 6 . The source non-F1 donor CU may decide to apply the in-CU topology adaptation process for the IAB node. In another example, the second parent IAB node is 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 towards a target IAB topology different from the IAB topology controlled by the first IAB donor CU (e.g., F1 terminating donor CU) of the IAB node (e.g., the target IAB topology is not the IAB topology controlled by the F1 terminating donor CU of the IAB node).

[0325] For example, referring to Figure 8 shown in and for Figure 8 the IAB communication system described, the first IAB donor CU for performing method 1610 may be IAB donor CU 801 (e.g., the F1-terminating donor CU of IAB node 870 that maintains an F1 connection with IAB node 870). The IAB node may be mobile IAB node 870 belonging to IAB topology 8001 controlled by IAB donor CU 801. In Fig.15 it, the non-F1-terminating donor CU is denoted by reference numeral 1505, the F1-terminating donor CU is denoted by reference numeral 1504, and the target non-F1-terminating donor CU is denoted by reference numeral 1506. In the example, the handover process may involve the MT 871 of IAB node 870 migrating from a first parent IAB node (e.g., IAB node 830) of IAB topology 8002 controlled by IAB donor CU 802 to a second IAB node (e.g., IAB node 850) of the same IAB topology 8002 controlled by IAB donor CU 802, where the first parent IAB node 830 is in a backhaul path having a first donor DU 805 (which is different from the donor DU806 in the backhaul path used by the second IAB node 850). In another example, the handover process may involve the MT 871 of IAB node 870 migrating from IAB donor DU 806 in IAB topology 8002 controlled by IAB donor CU 802 operating as a source non-F1-terminating donor CU to IAB donor DU 807 in IAB topology 8003 controlled by IAB donor CU 803 operating as a target non-F1-terminating donor CU. As Fig.16b shown in and for Fig.16b the method 1610 described may be performed by software elements and / or hardware elements. The F1-terminating IAB donor CU may be implemented in a communication device 400 as Figure 4 shown in and with reference to Figure 4 the communication device 400 described, where the method as Fig.16b shown in and for Fig.16b described is performed by a device for the F1-terminating IAB donor CU that includes one or more processing units (such as central processing unit 411, etc.).

[0326] At step 1611, the F1 terminating donor CU (or F1 donor CU) (such as IAB donor CU 801) receives an MT handover notification of the IAB node from a source non-F1 terminating donor CU (or source non-F1 donor CU) 802 of the IAB node, such as IAB node 870. Thus, the F1 donor CU 801 receives an MT handover notification (or MT handover notice) for indicating that the MT 871 of the IAB node 870 is to be migrated from a first parent IAB node (e.g., the current parent IAB node) to a second parent IAB node (e.g., a new or target parent IAB node). The MT handover notification (or MT handover notice) includes identification information for identifying the IAB node having the MT to be migrated. The MT handover notification of the IAB node may indicate that the MT 871 of the IAB node 870 is to be continuously migrated towards a target topology (e.g., IAB topology 8003) managed by a target non-F1 terminating donor CU (or target non-F1 donor CU), and this MT handover notification is used to identify the IAB node. 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 of the IAB node may indicate that the MT 871 of the IAB node 870 is to be continuously migrated towards 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 of the IAB node 870 is to be migrated is (directly or indirectly) connected to a donor DU different from the donor DU in the current backhaul path used by the IAB node 870. As described above, the MT handover notification may be included in the MT handover notice (or IAB NODEMIGRATION REQUEST) message 1512.

[0327] At step 1612, the F1 donor CU disables the initiation of the DU migration process for the IAB node. For example, after receiving the MT handover notification or in response to receiving the MT handover 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.

[0328] After the MT of the IAB node has been migrated to the second parent IAB node (e.g., after the migration process for the MT of the IAB node is completed), the F1 donor CU 801 enables the initiation of the migration process for the DU of the IAB node (step 1615). As described with reference to step 1614 below, the F1 donor CU 801 may determine that the MT of the IAB node has been migrated to the second parent IAB node (e.g., the migration process for the MT of the IAB node has been completed).

[0329] At 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 as a response to the MT handover notification message of step 1611. As described above, the MT handover response message (or MT migration response) may be included in the MT handover response (or IAB NODE MIGRATION RESPONSE) message 1513.

[0330] At step 1614, the F1 donor CU 801 may receive a message from the source non-F1 donor CU 802 for indicating the completion of MT migration for the IAB node. For example, as described above, the source non-F1 donor CU 802 may send an MT handover completion message 1515. As an alternative step, the F1 donor CU 801 may detect the completion of MT migration by exchanging messages with the source non-F1 donor CU 802 or the target non-F1 donor CU 803 at the end of the MT migration process.

[0331] At step 1615, the F1 donor CU enables the initiation of the DU migration process for the IAB node.

[0332] Fig.17 FIG. 1700 is a schematic simplified diagram illustrating some example message flows according to one or more embodiments of the present invention for avoiding the initiation of consecutive MT migrations of an IAB node during the DU migration of the IAB node. Consecutive MT migrations may involve multiple MT migrations between different parent IAB nodes (directly or indirectly) connected to different donor DUs, where these different donor DUs are all managed by the same donor CU but are different from the donor CU of the DU serving the IAB node. Consecutive MT migrations may alternatively involve new MT migrations between different parent IAB nodes managed by different donor CUs different from the donor CU of the DU serving the IAB node.

[0333] The Fig.17 shows: a non-F1 terminating donor CU (or non-F1 donor CU) 1705 that terminates the RRC connection to an IAB node (not shown), and the IAB node may be a mobile IAB node such as the IAB node 870 and / or Figure 8 the IAB node 123 as Figure 1 composed of a mobile terminal (MT) and a distributed unit (DU); a source F1 terminating donor CU (or F1 donor CU) 1704 that terminates the F1 connection to the IAB node; and a target F1 donor CU 1706 that should become the new F1 terminating donor CU for the IAB node. As an example and with reference to Figure 8For the IAB communication system, the source F1 terminating donor CU 1704 for the IAB node is donor CU 801. The MT 871 of the IAB node 870 has been migrated to the IAB topology 8002 managed by donor CU 802, and thus the non-F1 terminating donor CU 1705 is donor CU 802. When the IAB node moves towards the IAB topology 8003, this topology is recognized as the target IAB topology to which the DU 872 of the IAB node 870 can be migrated (e.g., for load balancing purposes), and thus the target F1 terminating donor CU 1706 is donor CU 803.

[0334] In short, the process for DU migration for an IAB node can be carried out according to the following process. When it is decided or determined by the source F1 donor CU of the IAB node to migrate the DU towards another IAB topology managed by another donor CU (which becomes the 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 the IAB node can decide to perform DU migration to reduce the processing load at the source F1 donor CU, or because the IAB node is geographically far from the source F1 donor CU and close to an area where there is no longer an Xn or IP connection between the source F1 donor CU and the target F1 donor CU. For example, refer to Figure 8, the source F1 donor CU for the IAB node 870 can be the donor CU 801, which determines the DU migration of the IAB-DU 872 of the IAB node 870 towards the IAB topology 8003, and thus, the donor CU 803 is the target F1 donor CU. This may require activating the second logical DU entity in the mobile IAB node via a message sent from the source F1 donor CU to the IAB node. Thus, once the second logical DU entity in the IAB node is activated, the IAB node has two logical DU entities that share the same hardware for the BAP layer, RLC layer, and MAC layer. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. Each logical DU entity serves one or more cells. The (one or more) cells of one logical DU entity (e.g., the first logical DU) are identified by the identifier (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) of the (one or more) cells having a different value from the identifier of the other logical DU entity (e.g., the second logical DU). After activation, the second logical DU of the IAB node can send an F1 setup request message to the target F1 donor CU to request setting up an F1 connection between the IAB node and the target F1 donor CU. In the F1 setup response, the target F1 donor CU can request the second logical DU of the IAB node to activate the (one or more) new cells and can inform the source F1 donor CU of the activation of the (one or more) new cells.

[0335] The next step is to hand over the UEs served by the IAB node from the (one or more) cells of the first logical DU of the IAB node to the (one or more) cells of the second logical DU. The target F1 donor CU may perform a path switching procedure towards the core network to request the delivery of user data related to the UE via the second logical DU. Then, the target F1 donor CU must set up the backhaul path to / from the migrated IAB node in its own topology, or via the IAB topology of the non-F1 donor CU of the IAB node, if there is a backhaul path to the IAB node in the IAB topology controlled by the target F1 donor CU. In the latter case, the target F1 donor CU may trigger a process to request traffic migration 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 completed, the source F1 donor CU may deactivate the first logical DU of the mobile IAB node. In addition, the source F1 donor CU may release the traffic (user traffic, control traffic) related to the UEs served by the IAB node via the first logical DU. If the traffic is offloaded in the IAB topology controlled by another donor CU (i.e., non-F1 donor CU), the source F1 donor CU may apply a process to request traffic release to the non-F1 donor CU.

[0336] Based on the above description, it seems that if the MT migration of the IAB node is performed during the DU migration, the DU migration process may fail or may be interrupted at different steps. In fact, the MT migration of the IAB node may involve setting up a new backhaul path through the new IAB topology, which results in some packet losses before all the IAB donor CUs that have to communicate with the mobile IAB node are informed of the change. As a safety method to avoid service interruption at the UEs served by the IAB node, the DU migration should be performed and completed while the co-located MT remains connected to the same IAB donor CU.

[0337] To prevent the MT migration of the IAB node (starting from the MT handover) from being triggered during the DU migration process / handling, the source F1 donor CU 1704 sends a DU migration notification to the non-F1 donor CU 1705 for 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 the 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 process (i.e., activating the second logical DU in the IAB node). For example, the message 1712 may be sent before performing the migration of the DU of the IAB node (e.g., before conducting the DU migration process / handling).

[0338] Message 1712 includes the identifier(s) of the IAB node(s) known to two donor CUs (source F1 donor CU 1704 and non-F1 donor CU 1705), and it may include the 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 MT to be migrated. The identification information may include at least one identifier of the IAB node. Such identifier(s) of the IAB node may include the identifier(s) known to the F1-terminating donor CU and non-F1-terminating donor CU of the IAB node: for example, the message may include one or more of the following: Information Element F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID and the BAP address(es) assigned to the IAB node. The identification information (or identifier) for the target non-F1 donor CU 1706 may include the PCI or NCGI of the target cell in the target IAB topology to which the DU is to be migrated.

[0339] Upon receiving this message 1712, the non-F1 donor CU 1705 may disable the execution of the MT handover for the IAB node in operation 1710. For example, the non-F1 donor CU 1705 may disable the initiation of the MT migration process for the IAB node (e.g., which includes disabling the MT handover as part of the MT migration process). In the case where message 1712 indicates that the target F1 donor CU for the DU migration corresponds to the target non-F1 donor CU for the handover of the co-located MT of the IAB node (e.g., the DU and the MT are to be migrated to the same donor CU), since the target non-F1 donor CU (and thus also the target F1 donor CU) is capable of concurrently handling the MT migration and the DU migration, the non-F1 donor CU 1705 may not disable the MT migration. However, the MT handover towards another target non-F1 donor CU (e.g., a donor CU different from the donor CU to which the DU is to be migrated) is disabled.

[0340] Then, the non-F1 donor CU 1705 may 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 for this acknowledgment message 1713 to initiate the execution of the DU handover process 1714. For example, the source F1 donor CU 1704 may perform the migration of the DU of the IAB node after receiving the DU migration response in message 1713.

[0341] When receiving the DU migration notification message 1712 and in the case where the MT migration process for the IAB node is in progress, the non-F1 donor CU 1705 may wait for the completion of the ongoing MT migration process before sending the DU migration response message 1713. As an alternative, the non-F1 donor CU 1705 may send a DU migration response (or IAB NODE MIGRATION REJECT) message 1713, which indicates that the DU migration is rejected due to the ongoing MT migration (i.e., the reason for rejection is included in the message 1713).

[0342] Once 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 (e.g., to indicate the completion of the migration of the DU of the IAB node). The message 1715 includes the identifier(s) of the IAB node known to the two donor CUs (the source F1 donor CU 1704 and the non-F1 donor CU 1705), and it may include the identifier of the target F1 donor CU 1706.

[0343] After receiving the DU migration completion message 1715, at operation 1720, the non-F1 donor CU 1705 may re-enable the MT migration process of the IAB node (e.g., which includes enabling the MT handover as part of the MT migration process).

[0344] During the process for DU migration, when the source F1 donor CU 1704 releases the traffic towards the IAB topology migration controlled by the non-F1 donor CU 1705 and in the case where the target F1 donor CU 1706 requests the traffic towards the IAB topology migration controlled by the non-F1 donor CU 1705, the non-F1 donor CU 1705 is involved at a certain point in time. Thus, the message 1715 may then not be necessary, and the 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.

[0345] According to one example, the DU relocation notification message 1712 can be the HANDOVER REQUEST message specified in section 9.1.1.1 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of DU relocation of an IAB node to be performed between a source F1 donor CU and a target F1 donor CU. The message includes the identifier of the relevant IAB node known to both donor CUs (the source F1 donor CU sending the message and the non-F1 donor CU receiving the message), and in addition to the other information elements present in the message as specified in TS 38.423, it may also include the identifier of the target F1 donor CU. Furthermore, the DU relocation response message 1713 can be the HANDOVER REQUEST ACKNOWLEDGE message specified in section 9.1.1.2 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement for the DU relocation of an IAB node to be performed between a source F1 donor CU and a target F1 donor CU. In the case of rejection of the DU relocation, the DU relocation response message 1713 can be the HANDOVER PREPARATION FAILURE message specified in section 9.1.1.3 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of the DU relocation of an IAB node including the reason for rejection (e.g., due to a load issue).

[0346] According to another example, the DU migration notification message 1712 can be the NG-RAN NODE CONFIGURATION UPDATE message specified in section 9.1.3.4 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of DU migration of an IAB node to be performed between the source F1 donor CU and the target F1 donor CU. The message includes the identifier of the relevant IAB node known to both donor CUs (the source F1 donor CU sending the message and the non-F1 donor CU receiving the message), and in addition to the other information elements present in the message as specified in TS 38.423, it can also include the identifier of the target F1 donor CU. Furthermore, the DU migration response message 1713 can be the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message specified in section 9.1.3.5 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement for the DU migration of an IAB node to be performed between the source F1 donor CU and the target F1 donor CU. In the case of rejection of the DU migration, the DU migration response message 1713 can be the NG-RAN NODE CONFIGURATION UPDATE FAILURE message specified in section 9.1.3.6 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of the DU migration of an IAB node including the reason for rejection (e.g., due to a load issue).

[0347] According to another example, the DU relocation notification message 1712 can be the MOBILITY CHANGE REQUEST message specified in section 9.1.3.22 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a notification of DU relocation of an IAB node to be performed between a source F1 donor CU and a target F1 donor CU. The message includes the identifier of the relevant IAB node known to both donor CUs (the source F1 donor CU sending the message and the non-F1 donor CU receiving the message), and in addition to the other information elements present in the message as specified in TS 38.423, it may also include the identifier of the target F1 donor CU. Furthermore, the DU relocation response message 1713 can be the MOBILITY CHANGE ACKNOWLEDGE message specified in section 9.1.3.23 of TS 38.423 V17.2.0, but with a new information element that indicates that it is an acknowledgement of the DU relocation of an IAB node to be performed between a source F1 donor CU and a target F1 donor CU. In the case of a rejection of the DU relocation, the DU relocation response message 1713 can be the MOBILITY CHANGE FAILURE message specified in section 9.1.3.24 of TS 38.423 V17.2.0, but with a new information element that indicates that it is a rejection of the DU relocation of an IAB node including the reason for the rejection (e.g., due to a load issue).

[0348] Fig.18a is a flowchart of an example method 1800 according to one or more embodiments of the present invention, the example method 1800 being for managing the sequential DU relocation of an IAB node at a first IAB donor CU (e.g., a source F1 terminating donor CU) that manages or controls a first IAB topology in a manner that does not compete with the sequential MT relocation of the IAB node. The sequential MT relocation of the IAB node can involve the relocation of the MT of the IAB node from a first parent IAB node of a second IAB topology managed or controlled by a second IAB donor CU (e.g., a source non-F1 terminating donor CU) towards a second parent IAB node. In the example, the first parent IAB node involves or uses a first backhaul path including a first IAB donor DU of a second IAB topology managed by the second IAB donor CU to route data associated with the IAB node, and the second parent IAB node routes data associated with the IAB node in a second backhaul path including a second IAB donor DU of the second IAB topology (e.g., relocation between two different donor DUs in the same topology). In this case, as referred to above Figure 6As described above, the source non-F1 donor CU may determine to apply the CU-internal topology adaptation process for the IAB node. In another example, the second parent IAB node is 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 towards a target IAB topology different from the IAB topology controlled by the first IAB donor CU of the IAB node (e.g., the target IAB topology is not the IAB topology controlled by the F1 terminating donor CU of the IAB node).

[0349] For example, referring to Figure 8 shown in and for Figure 8 the IAB communication system described above, the first IAB donor CU for performing method 1800 may be IAB donor CU 801 (e.g., the F1 terminating donor CU that maintains an F1 connection with IAB node 870 of IAB node 870). The IAB node may be a mobile IAB node 870 belonging to the IAB topology 8001 controlled by IAB donor CU 801, where the migrated MT is controlled by IAB donor CU 802 (e.g., the non-F1 terminating donor CU that has an RRC connection with mobile IAB node 870 of mobile IAB node 870). The migration process involves migrating the DU 872 of IAB node 870 from IAB donor CU 801, which is operating as the source F1 terminating donor CU, to IAB donor CU 803, which is operating as the target F1 terminating donor CU and controls the IAB topology 8003. In Fig.17 it, the non-F1 terminating donor CU is referred to by reference numeral 1705, the F1 terminating donor CU is referred to by reference numeral 1704, and the target F1 terminating donor CU is referred to by reference numeral 1706. As Fig.18a shown in and for Fig.18a the method 1800 described above may be performed by software elements and / or hardware elements. The source F1 terminating IAB donor CU may be implemented in the communication device 400 as shown in Figure 4 and referring to Figure 4 the communication device described above, where as Fig.18a shown in and for Fig.18a the method described above is performed by a device for the F1 terminating IAB donor CU that includes one or more processing units (such as central processing unit 411, etc.).

[0350] At step 1801, the source F1 terminating donor CU (or source F1 donor CU) (such as donor CU 801) of the IAB node (such as IAB node 870) determines that the DU 872 of the IAB node 870 is to be migrated towards a target topology (e.g., IAB topology 8003) managed by the target F1 terminating donor CU (or target F1 donor CU) 803, while the MT 871 of the IAB node has been migrated towards the non-F1 terminating donor CU (or non-F1 donor CU) 802.

[0351] At step 1802, the source F1 donor CU 801 sends a DU migration notification message for identifying the DU migration of the IAB node 870 to the non-F1 donor CU. For example, the source F1 donor CU 801 sends a DU migration notification indicating that the DU 872 of the IAB node 870 is to be migrated. The DU migration notification includes identification information for identifying the IAB node having the DU to be migrated. As described above, the DU migration notification may be included in the DU migration notification (or IAB NODE MIGRATION REQUEST) message 1712. Refer to Fig.17 As well as the sending of the message 1712, 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 above.

[0352] At 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 in step 1802. As described above, the DU migration response may be included in the DU migration response (or IAB NODE MIGRATION RESPONSE) message 1713.

[0353] At step 1804, the source F1 donor CU 801 performs the DU migration process for the IAB node 870. For example, the source F1 donor CU 801 performs the DU migration process / processing after receiving the DU migration response (or IAB NODE MIGRATION RESPONSE) message 1713.

[0354] At step 1805, the source F1 donor CU 801 may send a message to the non-F1 donor CU 802 for indicating the completion of the DU migration for the IAB node 870. For example, as described above, the source F1 donor CU 801 may send the DU migration completion message 1715.

[0355] Fig.18bis a flowchart of an example method 1810 according to one or more embodiments of the present invention. The example method 1810 is used to manage the migration (including handover) of the IT of an IAB node during the DU migration of the IAB node managed by a second IAB donor CU (e.g., a non-F1 terminated donor CU) for managing a second IAB topology from a first IAB topology managed by a first IAB node CU (e.g., an F1 terminated donor CU) towards a third IAB topology managed by a third IAB donor CU (e.g., a target F1 terminated donor CU). The method 1810 is performed at the second IAB donor CU (e.g., a non-F1 terminated donor CU). The method involves disabling the MT migration (e.g., including disabling the MT handover) of the IAB node at the non-F1 terminated donor CU of the IAB node during the DU migration of the IAB node.

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

[0357] At step 1811, a non-F1 terminating donor CU (or non-F1 donor CU) (such as IAB donor CU 802) receives from a source F1 terminating donor CU (or source F1 donor CU) of the IAB node 870 a DU migration notification for the IAB node towards a target topology managed by a target F1 terminating donor CU (or target F1 donor CU), and this DU migration notification is used to identify the IAB node. The source F1 donor CU can be IAB donor CU 801, and the target F1 donor CU can be IAB donor CU 803. Thus, the non-F1 donor CU 802 receives a DU migration notification for indicating that the DU 872 of the IAB node 870 is to migrate towards the third IAB topology 8003. The DU migration notification includes identification information for identifying the IAB node having the DU to be migrated. As described above, the DU migration notification can be included in a DU migration notification (or IAB NODE MIGRATION REQUEST) message 1712.

[0358] At step 1812, the non-F1 donor CU 802 disables the initiation of the MT migration process / processing (starting from the MT handover) for the IAB node. For example, the non-F1 donor CU 802 disables the initiation of the MT migration processing for the IAB node until the migration processing of the DU for the IAB node is completed.

[0359] After the DU of the IAB node has been migrated to the third IAB topology (for example, after the migration processing of the DU for the IAB node is completed), the non-F1 donor CU 802 enables the initiation of the migration processing for the MT of the IAB node (step 1815). As described in reference to step 1814 below, the non-F1 donor CU 802 can determine that the DU of the IAB node has been migrated to the third IAB topology (for example, the migration processing of the DU for the IAB node has been completed).

[0360] At step 1813, the non-F1 donor CU 802 can send a DU migration response message to the source F1 donor CU 801 as a response to the DU migration notification message in step 1811. As described above, the DU migration response can be included in a DU migration response (or IAB NODE MIGRATION RESPONSE) message 1713.

[0361] At step 1814, the non-F1 donor CU 802 can receive from the source F1 donor CU 801 a message for indicating the completion of the DU migration for the IAB node. For example, as described above, the source F1 donor CU 801 can send a DU migration completion message 1715. As an alternative step, the non-F1 donor CU 802 can detect the completion of the DU migration by exchanging messages with the source F1 donor CU 801 or the target F1 donor CU 803 at the end of the DU migration process.

[0362] At step 1815, a non-F1 donor CU enables the initiation of the MT handover process for the IAB node (e.g., it includes enabling the MT handover as part of the MT handover process).

[0363] It can be noted that the reference Fig.17 the described process can be used alone without using Fig.15 the described process. Conversely, the reference Fig.15 the described process can be used alone without using Fig.17 the described process. In addition, these two processes can be used in a complementary manner. Since MT handover may be required to avoid service interruption due to poor radio conditions, MT handover can be prioritized over DU handover. Then, in the case where the MT handover notification message 1512 and the DU handover notification message 1712 are generated simultaneously or substantially simultaneously, the F1 donor CU 1504 / 1704 shall cancel the DU handover upon receiving the message 1512, or it shall wait for an acknowledgment message 1713 from the non-F1 donor CU 1505 / 1705 (which is an acknowledgment from the non-F1 donor CU for the DU handover of the IAB node to be performed between the source F1 donor CU and the target F1 donor CU) before initiating the DU handover.

[0364] As referred to above Figure 15 to Figure 18b sending the MT handover notification and / or the DU handover notification provides a relatively simple way to ensure that the MT handover is executed and completed while the co-located DU remains connected to the same donor, and / or that the DU handover is executed and completed while the co-located MT remains connected to the same donor. This helps to reduce the likelihood of at least one failure during the handover process and also avoids complex signaling.

[0365] In other words and as a summary, it can be noted that performing the mobile IAB-MT (mIAB-MT) handover simultaneously with the co-located mobile IAB-DU (mIAB-DU) handover may cause at least one of these processes to fail, or it may significantly increase the complexity of the signaling. As a safe approach, the mIAB-MT handover should be executed and completed while the co-located mIAB-DU remains connected to the same donor CU, and the mIAB-DU handover should be executed and completed while the co-located mIAB-MT remains connected to the same donor CU.

[0366] To avoid concurrent migrations of mIAB-MT and mIAB-DU, a single donor CU shall control the sequence of mIAB-MT migration and mIAB-DU migration for a mobile IAB node. Since on the one hand the donor CU serving the mIAB-DU decides whether to perform mIAB-DU migration and on the other hand the donor CU serving the mIAB-DU is informed of the mIAB-MT handover, the donor CU serving the mIAB-DU emerges as the appropriate donor CU to control the sequence. In addition, since the donor CU serving the mIAB-DU can directly exchange Xn IAB transport migration messages with the target donor CU, this donor CU can know when the mIAB-MT migration is completed.

[0367] Therefore, it can be observed that the F1 terminating donor CU of the IAB node is the appropriate donor CU to control the sequence of IAB-MT migration and IAB-DU migration for the mobile IAB node.

[0368] Thus, when the non-F1 terminating donor CU or the RRC terminating donor CU of the mobile IAB node detects the need to perform mIAB-MT migration to connect the mIAB-MT to the target non-F1 terminating donor CU, the non-F1 terminating donor CU shall cause the F1 terminating donor CU to trigger the mIAB-MT migration at an appropriate time.

[0369] Then, it is proposed that the non-F1 terminating donor CU of the mobile IAB node shall cause the F1 terminating donor to trigger the inter-donor mIAB-MT at an appropriate time.

[0370] As a possible way of controlling the sequence, the non-F1 terminating donor CU for detecting the need for mIAB-MT migration to connect the mIAB-MT to the target non-F1 terminating donor CU may first inform the F1 terminating donor CU. Then, the F1 terminating donor CU will trigger the inter-donor mIAB-MT migration at an appropriate time and will respond to the non-F1 terminating donor CU.

[0371] When analyzing the impact of concurrent MT handover and DU migration for a mobile IAB node, it seems that the DU migration may fail due to possible modifications of the backhaul path for communicating with the mobile IAB node. Depending on when the original backhaul path between the mobile IAB node and the source non-F1 terminating donor CU is no longer available, the F1 setup procedure or the UE handover procedure in the DU migration may fail at some point. On the other hand, the handover of the mobile IAB-MT (mIAB-MT) should not be affected by the concurrent migration of the co-located mobile IAB-DU (mIAB-DU).

[0372] As a safe method, the mIAB-DU migration should be performed and completed while the co-located mIAB-MT remains connected to the same donor CU. However, assuming that the mIAB-MT handover should not be delayed to maintain the backhaul connection and avoid service interruption at the served UE, the mIAB-MT handover can be triggered while the mIAB-DU migration is in progress. The cases of concurrent MT handover and DU migration can be restricted by preventing the mIAB-DU migration from being triggered while the handover of the co-located mIAB-MT is in progress.

[0373] Therefore, when the non-F1-terminating donor CU of the mobile IAB node detects the need to perform an mIAB-MT handover, the non-F1-terminating donor CU can immediately inform the F1-terminating donor CU.

[0374] Then it is proposed that the non-F1-terminating donor CU of the mobile IAB node can inform the F1-terminating donor before performing the MT handover of the mobile IAB node.

[0375] Then, the F1-terminating donor CU can disable the execution of the DU migration for the mobile IAB node until the handover process for the co-located mIAB-MT is completed.

[0376] Several of the foregoing features enable the effective decoupling of the mIAB-MT handover and the mIAB-DU migration.

[0377] Although the present invention has been illustrated 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 understand that various changes and modifications can be made without departing from the scope of the present invention as defined in the appended claims. All features (including any appended claims, abstract, and drawings) disclosed in this specification and / or all steps of any method or process so disclosed can be combined in any combination other than at least some mutually exclusive combinations of such features and / or steps. Unless otherwise explicitly stated, each feature disclosed in this specification (including any appended claims, abstract, and drawings) can be replaced by alternative features serving the same, equivalent, or similar purpose. Thus, unless otherwise explicitly stated, each disclosed feature is only an example of a general series of equivalent or similar features.

[0378] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The fact that different features are defined only in mutually different dependent claims does not mean that a combination of these features cannot be used advantageously.

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

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

[0381] By way of example, and not limitation, such computer-readable storage media may include 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 the desired program code in the form of instructions or data structures and that can be accessed by a computer. In addition, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted using coaxial cables, fiber optic cables, twisted pairs, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cables, fiber optic cables, twisted pairs, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but rather refer to non-transitory tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disk generally magnetically reproduces data, while disc optically reproduces data with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node (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 (first IAB donor CU) of a first IAB topology, and the first parent IAB network node and the second parent IAB network node are managed by a second IAB donor CU of a second IAB topology. The method comprises: at the IAB node, sending path information associated with one or more routing paths in the second IAB topology to the first IAB donor CU, where the one or more routing paths are to be used to route data associated with the IAB node through the second parent IAB network node.

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

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

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

5. The method according to any one of claims 1 to 4, further comprises: sending identification information including at least one identifier of the IAB node to the first IAB donor CU.

6. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node (IAB node) migrates in a second IAB topology managed by a second IAB donor central unit (second IAB donor CU). The IAB node is managed by a first IAB donor CU of a first IAB topology. The method comprises: at the second IAB donor CU, determining that the MT of the IAB node is to migrate from a first parent IAB network node to a second parent IAB network node, where the first parent IAB network node and the second parent IAB network node are managed by the second IAB donor CU; sending path information associated with one or more routing paths in the second IAB topology to the first IAB donor CU, where the one or more routing paths are to be used to route data associated with the IAB node through the second parent IAB network node.

7. The method according to claim 6, wherein The first parent IAB network node is one of a first parent IAB node connected to a first IAB donor distributed unit, i.e., a first IAB donor DU, and the first IAB donor DU, and wherein the second parent IAB network node is one of a second parent IAB node connected to a second IAB donor DU and the second IAB donor DU, and the first IAB donor DU and the second IAB donor DU are associated with the second IAB donor CU.

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

9. The method according to any one of claims 7 to 8, wherein, the determination 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. The method according to any one of claims 6 to 9, further comprises: sending identification information including at least one identifier of the IAB node to the first IAB donor CU.

11. The method according to any one of claims 6 to 10, further comprises: sending configuration information, where the configuration information includes configuration parameters for each backhaul link associated with the IAB node in the one or more routing paths.

12. A method for migration processing, in which a mobile terminal, i.e., an MT, of an integrated access and backhaul node, i.e., an 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, i.e., a first IAB donor CU, and the first parent IAB network node and the second parent IAB network node are managed by a second IAB donor CU, the method comprises: at the first IAB donor CU, receiving path information associated with one or more routing paths in a second IAB topology managed by the second IAB donor CU, the one or more routing paths to be used to route data associated with the IAB node through the second parent IAB network node.

13. The method according to claim 12, wherein, the receiving includes: receiving the path information from the IAB node.

14. The method according to claim 12, wherein, the receiving includes: receiving the path information from the second IAB donor CU.

15. The method according to claim 14, further comprises: receiving configuration information, where the configuration information includes configuration parameters for each backhaul link associated with the IAB node in the one or more routing paths.

16. The method according to any one of claims 12 to 15, wherein, the first parent IAB network node is one of a first parent IAB node connected to a first IAB donor distributed unit, i.e., a first IAB donor DU, and the first IAB donor DU, and Wherein, the second parent IAB network node is one of a second parent IAB node connected to a second IAB donor DU and the second IAB donor DU, and the first IAB donor DU and the second IAB donor DU are associated with the second IAB donor CU.

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

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

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

20. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node (IAB node) migrates from a second IAB topology managed by a second IAB donor central unit (second IAB donor CU) to a third IAB topology managed by a third IAB donor CU, and the IAB node is managed by a first IAB donor CU that manages a first IAB topology. The method comprises: at the IAB node, sending identification information for identifying the third IAB donor CU to the first IAB donor CU.

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

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

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

24. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node (IAB node) migrates from a second IAB topology managed by a second IAB donor central unit (second IAB donor CU) to a third IAB topology managed by a third IAB donor CU, and the IAB node is managed by a first IAB donor CU that manages a first IAB topology. The method comprises: at the second IAB donor CU, determining a target IAB donor DU to which the MT of the IAB node is to be migrated to the third IAB topology, wherein data associated with the IAB node is to be routed through the target IAB donor DU in the third IAB topology; Send identification information for identifying the third IAB donor CU to the first IAB donor CU.

25. The method according to claim 24, further comprising: Sending IAB node identification information including at least one identifier of the IAB node.

26. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node, i.e., an IAB node, migrates from a second IAB topology managed by a second IAB donor central unit, i.e., a second IAB donor 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: At the first IAB donor CU, Receiving address information, the address information including one or more addresses associated with a target IAB donor DU of the third IAB topology, wherein in the third IAB topology, data associated with the IAB node is to be routed via the target IAB donor DU; Receiving identification information for identifying the third IAB donor CU.

27. The method according to claim 26, wherein, Receiving the address information includes: receiving the address information from the IAB node.

28. The method according to claim 26 or 27, wherein, Receiving the identification information includes: receiving the identification information from the IAB node or the second IAB donor CU.

29. The method according to any one of claims 26 to 28, further comprising: At the first IAB donor CU and based on the received information, updating one or more routing paths to be used for routing data associated with the IAB node via the target IAB donor DU.

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

31. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node, i.e., an IAB node, is to migrate from a second IAB topology managed by a second IAB donor central unit, i.e., a second IAB donor 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: At the second IAB donor CU, Determining that the MT of the IAB node is to migrate from the second IAB topology to the third IAB topology; Sending a handover request including identification information to the first IAB donor CU, the identification information being used to identify the third IAB donor CU of the third IAB topology to which the MT of the IAB node to be migrated is to be transferred.

32. The method according to claim 31, further comprising: Sending IAB node identification information to the first IAB donor CU, the IAB node identification information being used to identify the IAB node having the MT to be migrated.

33. The method according to claim 31 or 32, further comprising: Receive a handover response from the first IAB donor CU, the 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; Send the received configuration information to the IAB node.

34. The method according to claim 33, wherein, the configuration information includes one or more addresses associated with a target IAB donor DU of the third IAB topology, wherein data associated with the IAB node is to be routed via the target IAB donor DU in the third IAB topology.

35. The method according to claim 31 or 32, further comprising: Receive a handover response from the first IAB donor CU; In response to receiving an affirmative handover response for indicating that a second IAB donor CU is to initiate migration of the MT of the IAB node, cause the MT of the IAB node to migrate to the third IAB donor CU.

36. A method for handover processing, in which a mobile terminal (MT) of an integrated access and backhaul node (IAB node) is to migrate from a second IAB topology managed by a second IAB donor central unit (second IAB donor 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: At the first IAB donor CU, Receive a handover request from the second IAB donor CU for requesting migration of the 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 that manages the third IAB topology; Send a handover response to the second IAB donor CU.

37. The method according to claim 36, further comprising: Initiate migration of the MT of the IAB node to the third IAB donor CU.

38. The method according to claim 37, wherein, initiating the migration includes: Send a request to the third IAB donor CU to migrate the MT of the IAB node to a target cell in the third IAB topology; Receive 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.

39. The method according to 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 method according to claim 38 or 39, wherein, The configuration information includes one or more addresses associated with a target IAB donor DU of the third IAB topology, wherein data associated with the IAB node is to be routed via the target IAB donor DU in the third IAB topology.

41. The method according to any one of claims 37 to 40, further comprises: determining whether a migration process for a distributed unit, i.e., 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 initiation of the 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 is completed.

42. The method according to claim 36, wherein, sending a handover response to the second IAB donor CU includes: sending an affirmative handover response for instructing the second IAB donor CU to initiate the migration of the MT of the IAB node.

43. The method according to claim 42, further comprises: determining whether a migration process for a distributed unit, i.e., 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 sending of the affirmative handover response until the migration process for the DU of the IAB node is completed.

44. The method according to any one of claims 36 to 43, further comprises: delaying 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.

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

46. The method according to claim 36, further comprises: determining whether a migration process for a distributed unit, i.e., 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, sending a handover response to the second IAB donor CU for rejecting the handover request.

47. A method for managing a migration process, in which a mobile terminal, i.e., MT, of an integrated access and backhaul node, i.e., IAB node, is to migrate from a first parent IAB node of a second IAB topology managed by a second IAB donor central unit, i.e., second IAB donor CU, to a second parent IAB node, and a distributed unit, i.e., DU, of the IAB node is managed by a first IAB donor CU that manages a first IAB topology, the method comprises: at the second IAB donor CU, determining that the MT of the IAB node is to migrate towards the second parent IAB node; Send an MT migration notification to the first IAB donor CU, where the MT migration notification is used to indicate that the MT of the IAB node is to be migrated to the second parent IAB node, and the MT migration notification includes IAB node identification information for identifying the IAB node having the MT to be migrated.

48. The method according to claim 47, comprising: performing the migration of the MT of the IAB node to the second parent IAB node, where the sending includes: sending the MT migration notification before performing the migration of the MT of the IAB node to the second parent IAB node.

49. The method according to claim 48, comprising: after the execution of the migration of the MT of the IAB node is completed, sending a message to the first IAB donor CU for indicating the completion of the migration of the MT of the IAB node.

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

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

52. A method for managing the migration of a distributed unit (DU) of an integrated access and backhaul node (IAB node) during a mobile terminal migration process (MT migration process), where in the MT migration process, the MT of the IAB node is to be migrated from a first parent IAB node of a second IAB topology managed by a second IAB donor central unit (second IAB donor CU) to a second parent IAB node, and the DU of the IAB node is managed by a first IAB donor CU that manages a first IAB topology, the method comprising: at the first IAB donor CU, receiving an MT migration notification from the second IAB donor CU, where the MT migration notification is used to indicate that the MT of the IAB node is to be migrated to the second parent IAB node, and the MT migration notification includes IAB node identification information for identifying the IAB node having the MT to be migrated; disabling the initiation of the migration process for the DU of the IAB node; after the MT of the IAB node has been migrated, enabling the initiation of the migration process for the DU of the IAB node.

53. The method according to claim 52, comprising: determining that the MT of the IAB node has been migrated, where the enabling includes: in response to determining that the MT of the IAB node has been migrated, enabling the initiation of the migration process for the DU of the IAB node.

54. The method according to claim 53, comprising: receiving a completion message from the second IAB donor CU for indicating the completion of the MT migration, where the determining includes: based on the received completion message, determining that the MT of the IAB node has been migrated.

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

56. The method according to any one of claims 47 to 55, Wherein, the first parent IAB node is related to a first backhaul path, the first backhaul path includes a first IAB donor DU of the second IAB topology managed by the second IAB donor CU to route data associated with the IAB node, and the second parent IAB node is related to a second backhaul path, the second backhaul path includes a second IAB donor DU of the second IAB topology to route data associated with the IAB node.

57. The method according to any one of claims 47 to 55, wherein, the second parent IAB node is a part of a third IAB topology managed by a third IAB donor CU.

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

59. A method for managing a migration process, in which a distributed unit (DU) of an integrated access and backhaul node (IAB node) is to migrate from a first IAB topology managed by a first IAB donor central unit (first IAB donor CU) to a third IAB topology managed by a third IAB donor CU, and a mobile terminal (MT) of the IAB node is managed by a second IAB donor CU that manages a second IAB topology. The method comprises: at the first IAB donor CU, determining that the DU of the IAB node is to migrate towards the third IAB topology; sending a DU migration notification to the second IAB donor CU, the DU migration notification being used to indicate that the DU of the IAB node is to migrate towards the third IAB topology, and the DU migration notification includes IAB node identification information for identifying the IAB node having the DU to be migrated.

60. The method according to claim 59, comprises: performing the migration of the DU of the IAB node towards the third IAB topology, wherein the sending includes: sending the DU migration notification before performing the migration of the DU of the IAB node towards the third IAB topology.

61. The method according to claim 60, comprises: after the execution of the migration of the DU of the IAB node is completed, sending a completion message to the second IAB donor CU for indicating the completion of the migration of the DU of the IAB node.

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

63. The method according to claim 62, comprises: after receiving the DU migration response, performing the migration of the DU of the IAB node towards the third IAB topology.

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

65. A method for managing the migration of a mobile terminal (MT) of an integrated access and backhaul node (IAB node) during distributed unit migration processing (DU migration processing), where in the DU migration processing, the DU of the IAB node is to migrate from a first IAB topology managed by a first IAB donor central unit (first IAB donor CU) towards a third IAB topology managed by a third IAB donor CU, and the MT of the IAB node is managed by a second IAB donor CU that manages a second IAB topology. The method includes: at the second IAB donor CU, receiving a DU migration notification from the first IAB donor CU, the DU migration notification being used to indicate that the DU of the IAB node is to migrate towards the third IAB topology, and the DU migration notification including IAB node identification information for identifying the IAB node having the DU to be migrated; disabling the initiation of the migration processing for the MT of the IAB node; after the DU of the IAB node has been migrated, enabling the initiation of the migration processing for the MT of the IAB node.

66. The method according to claim 65, includes: determining that the DU of the IAB node has been migrated, where the enabling includes: in response to determining that the DU of the IAB node has been migrated, enabling the initiation of the migration processing for the MT of the IAB node.

67. The method according to claim 66, includes: receiving a completion message from the first IAB donor CU for indicating the completion of the DU migration, where the determining includes: determining that the DU of the IAB node has been migrated based on the received completion message.

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

69. The method according to any one of claims 65 to 68, wherein, the DU migration notification further includes identification information for identifying the third IAB donor CU.

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

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

72. An apparatus for an IAB donor central unit (IAB donor CU) used in an integrated access and backhaul communication system (IAB communication system), the apparatus includes: one or more processing units configured to perform the method according to any one of claims 6 to 19 and claims 24 to 70.

73. A computer program including instructions that, when the computer executes the program, cause the computer to perform the method according to any one of claims 1 to 70.

74. A computer-readable medium carrying the computer program according to claim 73.

Images