Node migration in IAB communication systems

Abstract

A method and apparatus are disclosed for use in managing transport transition for traffic associated with an Integrated Access and Backhaul (IAB) node. The transport transition is performed after a distributed unit (DU) of the IAB node is migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU. The method at the target IAB donor CU includes receiving a notification including identification information for identifying an IAB donor CU serving a mobile termination (MT) of the IAB node, the IAB donor CU serving the IAB node being a different IAB donor CU from the target IAB donor CU, and performing the transport transition based on the identification information to migrate traffic associated with the IAB node via at least one path between the target IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT after the DU of the IAB node is migrated to the target IAB topology. The target IAB donor CU may receive notification from the source IAB donor CU, from the IAB node, or from the IAB donor CU serving the MT.

Description

[Technical Field]

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

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

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

[0004] The demand for network densification increases due to an increasing number of users and higher throughput requirements.

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

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

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

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

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

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

[0011] A stationary IAB node should only require a single MT transition. Indeed, the backhaul link (defined between two consecutive IAB nodes in the wireless backhaul) may experience signal interference due to fluctuating radio conditions, and for a non-mobile IAB node, this should be a temporary situation in which link restoration may be possible after a certain period of time. Therefore, such a stationary IAB node should not be required to perform multiple MT transitions, either within the same IAB topology or towards another IAB topology, and the transmission and processing of multiple protocol messages may be avoided. For the same reason, a transition of the IAB node's distributed unit (DU) (leaving the IAB node's control to a new IAB donor) should not be required for a stationary node. Furthermore, it should be noted that such a DU transition, which may be called a full transition, also involves a handover of the UE served by the migrating mobile IAB node.

[0012] Urban environments are typically characterized by a high density of users, along with the presence of a significant number of vehicles (e.g., public / private passenger transport, merchandise delivery, food trucks, etc.). Some of these vehicles (e.g., buses, trams, trains) may have predictable routes and a large number of adjacent UEs (i.e., passenger devices). 3GPP is considering the possibility that such vehicles may offer opportunities to improve network coverage and connectivity for UEs within and around the vehicle by equipping them with onboard base stations (or base station elements) that act as mobile relays. These mobile relays will rely on 5G wireless backhaul (typically IAB, or Integrated Access and Backhaul) to connect to fixed donor devices.

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

[0014] The technical advantages of using a VMR include, among others, the VMR's ability to provide good radio link conditions to nearby UEs. Furthermore, compared to solutions using UEs as relays (i.e., sidelink relay solutions), the vehicle-mounted IAB node is expected to have better RF / antenna capabilities and looser power / battery constraints than the relay UE.

[0015] For mobile IAB nodes, it may be worthwhile to perform multiple MT or DU transitions because the connection to the parent IAB node belonging to the initial IAB topology may not re-occur for a long time as the mobile IAB node moves, or may never re-occur if the mobile IAB node moves away from the parent IAB node. Furthermore, for flexible IAB network management, MT and DU transitions should be uncorrelated, which means that a DU transition for an IAB node may occur independently before or after one or more MT transitions for this IAB node. Furthermore, a DU transition for an IAB node may be performed towards an IAB donor different from the IAB donor associated with this IAB node's MT.

[0016] In particular, if an MT transition of an IAB node towards a first IAB donor is followed by a DU transition of this IAB node from the first IAB donor towards a different second IAB donor, the second IAB donor may have to request a transition of traffic associated with the IAB node towards the IAB topology controlled by the first IAB donor.

[0017] Therefore, a new mechanism is required to provide such flexibility by supporting DU migration of an IAB node to any other IAB donor, independent of the MT migration of that IAB node. Summary of the Invention

[0018] According to a first aspect of the present invention, there is provided a method for managing transport migration of traffic associated with an Integrated Access and Backhaul (IAB) node, the transport migration being performed after a distributed unit (DU) of the IAB node is migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method in the target IAB donor CU includes receiving a notification including identification information for identifying an IAB donor CU serving a mobile termination (MT) of the IAB node, the IAB donor CU serving the MT of the IAB node being a different IAB donor CU from the target IAB donor CU, and performing the transport migration for migrating traffic associated with the IAB node based on the identification information and for routing via at least one path between the target IAB donor CU and the IAB node via the IAB topology managed by the IAB donor CU serving the MT after the DU of the IAB node is migrated to the target IAB topology.

[0019] The IAB donor CU (e.g., RRC donor CU) serving the MT may be the source IAB donor CU if the MT at the IAB node has not been migrated from the source IAB donor CU. Alternatively, the IAB donor CU (e.g., a non-F1 donor CU or RRC donor CU) serving the MT may be another or second IAB donor CU that manages a second IAB topology. In this latter case, the path between the target IAB donor CU and the MT at the IAB node is via the second IAB topology.

[0020] The target IAB donor CU may receive notification from the source IAB donor CU, from the IAB node (e.g., in an F1 Setup Request), or from the IAB donor CU serving the MT (e.g., in a Transport Migration Ready message). The notification received from the source IAB donor CU may be received in a DU Transition Notification message (which may be sent by the source IAB donor CU before or after performing a DU transition). In another example, the notification received from the source IAB donor CU may be received in a Configuration Update message. The Configuration Update message may be sent by the source IAB donor CU at any time, for example, before or after performing a DU transition, or when the source IAB donor CU detects a change in the IAB donor CU serving the MT. The advantage of being able to send a Configuration Update message at any time is that if the source IAB Donor CU has already provided the target IAB Donor CU with the address and / or identifier of the "old" IAB Donor CU that previously served the MT of the IAB node and is now "old" because the MT has been migrated to the "new" IAB Donor CU, the source IAB Donor CU can send the update via a Configuration Update message that includes identification information to identify the new IAB Donor CU.

[0021] According to a second aspect of the present invention, there is provided a method, executed in a source IAB donor CU, for use in managing a migration process for migrating a distributed unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, as set out in any one of claims 13 to 19 of the accompanying claims.

[0022] According to a third aspect of the present invention, there is provided a method for use in a migration process for migrating a distributed unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, executed in a source IAB donor CU, as set forth in any one of claims 20 to 24 or claim 44 of the accompanying claims.

[0023] According to a fourth aspect of the present invention, there is provided a method, executed in an IAB node, for use in a migration process for migrating a distributed unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, as set forth in any one of claims 25 to 31 or claim 44 of the accompanying claims.

[0024] According to a fifth aspect of the present invention, there is provided a method, executed on a second IAB donor CU, for use in managing transport migration of traffic associated with an Integrated Access and Backhaul (IAB) node, as set forth in any one of claims 32 to 39 or claim 44 of the accompanying claims, wherein the transport migration is performed after a distributed unit (DU) of the IAB node is migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, and a mobile termination (MT) of the IAB node is migrated to the second IAB donor CU, the second IAB donor CU being an IAB donor CU different from the target IAB donor CU and the source IAB donor CU.

[0025] According to a sixth aspect of the present invention, there is provided a method, executed in an IAB node, for use in a migration process for migrating a Distributed Unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, as set out in any one of claims 40 to 44 of the accompanying claims.

[0026] According to a seventh aspect of the present invention there is provided an apparatus for an IAB donor CU as set out in any one of claims 45 to 50 of the accompanying claims.

[0027] According to an eighth aspect of the present invention, there is provided an apparatus for an IAB node as set out in any one of claims 51 to 56 of the accompanying claims.

[0028] By sending a notification to the target IAB donor CU, whether by the source IAB donor CU or the IAB donor CU serving the IAB node or MT, the notification includes identification information for identifying the IAB donor CU serving the mobile termination (MT) of the IAB node, and the target IAB donor CU is notified of the current IAB donor CU serving the co-located MT of the IAB node, which allows the target IAB donor CU to set up an IAB transport transition towards the topology of the current IAB donor CU serving the MT of the IAB node.

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

[0030] Any feature in one aspect of the invention may be applied to other aspects of the invention in any appropriate combination.

[0031] In particular, method aspects may apply to apparatus / device / unit aspects, and vice versa. Furthermore, hardware-implemented features may be implemented in software, and vice versa. Any references to software and hardware features herein should be construed accordingly. For example, according to another aspect of the present invention, there is provided a computer program comprising instructions that, when executed by one or more processing units, cause the one or more processing units to perform the method of any aspect or example described above, and a computer-readable storage medium carrying the computer program. [Brief explanation of the drawings]

[0032] Different aspects of the present invention will now be described, by way of example only, with reference to the following drawings: [Figure 1] 1 is a schematic diagram of a communication system in which the present invention may be implemented in accordance with one or more embodiments; [Figure 2] Figures 2(a) and (B) show a schematic representation of the stack of several protocol layers involved in IAB operation; [Figure 3] 1 is a schematic diagram illustrating the format of a BAP protocol data unit (PDU) or packet; [Figure 4] 1 is a block schematic diagram of an exemplary wireless communication device according to an embodiment of the present invention; [Figure 5] 1 is a schematic diagram of an exemplary IAB communication system (or IAB network system) in which embodiments and examples of the present invention may be implemented; [Figure 6] FIG. 1 is a schematic and simplified diagram illustrating an example of an IAB node architecture that enables DU migration from a source IAB topology to a target IAB topology; [Figure 7] FIG. 1 is a simplified diagram illustrating an example message flow for performing a DU transition of an IAB node including a handover of a UE served by the transitioning IAB node, in accordance with one or more embodiments of the present invention; [Figure 8]FIG. 1 is a simplified diagram illustrating an example message flow for identifying a non-F1 terminating donor CU (or an RRC terminating donor CU) to a target F1 terminating donor CU for DU transition of an IAB node, in accordance with one or more embodiments of the present invention; [Figure 9a] 1 is a flowchart of an exemplary method according to an embodiment of the present invention for managing a DU transition of an IAB node involving identification of a non-F1 terminating donor CU (or RRC terminating donor CU) at a source F1 terminating donor CU of the IAB node to a target F1 terminating donor CU; [Figure 9b] 1 is a flowchart of another exemplary method according to an embodiment of the present invention for managing a DU transition of an IAB node involving identification of a non-F1 terminating donor CU (or RRC terminating donor CU) at a source F1 terminating donor CU of the IAB node to a target F1 terminating donor CU; [Figure 9c] 1 is a flowchart of an exemplary method according to one or more embodiments of the present invention performed at an IAB node for performing an F1 setup request to a target donor CU while identifying a non-F1 terminating donor CU (or an RRC terminating donor CU); [Figure 9d] 1 is a flowchart of an exemplary method for managing transport transition after DU transition of an IAB node at a target IAB donor CU according to an embodiment of the present invention; [Figure 10] FIG. 10 is a simplified diagram illustrating another example message flow for identifying a non-F1 terminating donor CU (or an RRC terminating donor CU) to a target F1 terminating donor CU of an IAB node's DU transition, in accordance with one or more embodiments of the present invention; [Figure 11a]1 is a flowchart of another exemplary method according to an embodiment of the present invention for managing a DU transition of an IAB node involving identification of a non-F1 terminating donor CU (or RRC terminating donor CU) at a source F1 terminating donor CU of the IAB node to a target F1 terminating donor CU; [Figure 11b] 1 is a flowchart of an exemplary method according to an embodiment of the present invention for managing transport transition in a non-F1 terminating donor CU (or RRC terminating donor CU) of an IAB node in case of DU transition of the IAB node; [Figure 11c] 1 is a flowchart of another exemplary method, according to an embodiment of the present invention, for managing transport transition in a target F1 terminating donor CU of an IAB node in case of DU transition of the IAB node; [Figure 12a] FIG. 1 is a simplified diagram illustrating an example message flow of a procedure for performing activation of a logical DU, according to one or more embodiments of the present invention; [Figure 12b] FIG. 1 is a simplified diagram illustrating an exemplary message flow of a procedure for setting up a logical DU; [Figure 12c] FIG. 1 is a simplified diagram illustrating an example message flow of a procedure for deleting a logical DU; [Figure 12d] 1 is a simplified diagram illustrating an example message flow of a procedure used by a logical DU to notify a RAN node CU about a change in configuration; [Figure 13a] FIG. 1 is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to report configuration information to another RAN node CU; [Figure 13b] FIG. 1 is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage transport transitions in coordination with another RAN node CU; [Figure 14]10 is a flowchart of an exemplary method for managing transport transition after DU transition of an IAB node at a target IAB donor CU, according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0033] 1 illustrates an exemplary communications system 100, particularly a mobile wireless communications system such as a fifth-generation (5G) New Radio (NR) system, including a wireless Integrated Access and Backhaul network supporting mobile IAB nodes. While the following description describes embodiments and examples of the present invention with respect to a 5G NR system, it is understood that the present invention is not intended to be limited to 5G NR systems and may be used in any wireless communications system having mobile base stations. In particular, the following description primarily uses terminology specific to 5G, but it should be understood that such terminology also applies to elements or processes performing equivalent functions in other communications systems.

[0034] The system 100 includes a plurality of UEs (User Equipments) 132, 133, 131, and 134, a remote core network 110, a main base station 120, 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., bus, train, taxi, car, etc.).

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

[0036] To extend the network coverage of the IAB donor 120 and reach the remote UEs 132, 133, and 131, IAB stations 121 and 122, also referred to as IAB nodes 121 and 122, are installed by the operator. By operating as relay nodes between the IAB donor 120 and the UEs 132 and 133, the IAB nodes 121 and 122 make it possible to overcome reachability problems resulting from the presence of buildings 108, which are obstacles to the propagation of radio waves and, therefore, to the direct connection and further communication between the UEs and the IAB donor 120. This is especially true when the communication between the IAB donor 120 and the UEs 132 and 133 is operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

[0037] The IAB donor 120 also serves the UEs 134 that are directly connected to it.

[0038] The mobile IAB station 123, also referred to as the mobile IAB node 123 or mIAB node 123, is an IAB node mounted on a vehicle 105 that provides network coverage and capacity extension, enabling the IAB donor 120 to reach vehicle-mounted remote UEs, such as remote UE 135, as well as UEs around or near the IAB node 123, such as remote UE 136.

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

[0040] The Integrated Access and Backhaul (IAB) standard is spread across several 3GPP specifications, including: - TS 38.300 RAN architecture(V17.2.0), - TS 38.321 MAC protocol(V17.2.0), - TS 38.331 Radio Resource Control (RRC) protocol (V17.2.0), - TS 38.340 Backhaul Adaptation Protocol Layer(V17.2.0), - TS 38.401 RAN architecture(V17.2.0), - TS 38.423 Xn Application Protocol (V17.2.0), - TS 38.473 F1 Application Protocol (V17.2.0).

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

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

[0043] IAB nodes capable of serving multiple radio sectors are wirelessly backhauled to the IAB donor 120 via one or more hops over one or more intermediate IAB nodes. They form a directed acyclic graph (DAG) topology with the IAB donor at its root.

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

[0045] In this DAG topology, the adjacent node on the IAB-DU interface is called the child node, and the adjacent node on the IAB-MT interface is called the parent node. The direction towards the child node is further called downstream, while the direction towards the parent node is called upstream.

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

[0047] 2(a) and 2(b) show a schematic diagram of the stack of several protocol layers involved in IAB operation.

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

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

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

[0051] In the control plane, box 210 denotes the F1AP (F1 Application Protocol) layer, and box 211 denotes the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol provides signaling services between the IAB donor CU and the IAB node DU (as defined in 3GPP TS38.473 and TS38.401) or UE related services. These services include initialization, configuration, etc. The well-known SCTP layer provides reliable in-sequence delivery of messages with congestion control.

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

[0053] The transport between the IAB Donor DU and IAB Donor CU may also use the IP transport layer over various media, such as wired or optical fiber when the IAB Donor CU is remote from the IAB Donor DU, or locally in a virtual instantiation of the IAB Donor CU and IAB Donor DU on the same physical machine. The IAB-specific transport between the IAB Donor CU and IAB Donor DU is specified in 3GPP TS 38.401.

[0054] L1 and L2 in Figure 2(a) represent the transport and physical layers, respectively, appropriate to the medium in use.

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

[0056] In wireless backhaul, the IP layer is itself carried over a Backhaul Adaptation Protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340.

[0057] IP traffic in the IAB-DU is routed over the wireless backhaul via the BAP sublayer. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer in the IAB donor DU, thus forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layers or entities of intermediate IAB nodes, if any (and 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 (which may be the access IAB node if the upper layer packets in the BAP packet are destined for the UE).

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

[0059] At the BAP sublayer, packets are carried in the BAP header of a BAP packet and are routed based on the BAP Routing ID set by the BAP sublayer of the emitting IAB donor DU or initiator IAB node (e.g., the network node in the IAB network that generates the BAP packet). Figure 3 shows the format of the BAP Data Protocol Data Unit (PDU) or packet. It is specified in paragraph 6.2 of the standard version of 3GPP TS38.340 Release 17.2.0.

[0060] The payload section 307 is a normal IP packet. The header 30 includes fields 301 to 306. Field 301 is called the D / C field and is a Boolean value that indicates whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302 to 304 are 1-bit reserved fields that are preferably set to 0 (ignored by the receiver).

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

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

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

[0064] For example, when a BAP packet is generated by a node, e.g., either by an IAB donor DU for downstream transmission or by an initiator (which may be an access IAB node if the upper layer packet comes from a UE) for upstream transmission, the BAP header with the BAP routing ID is constructed by this node according to a configuration table defined in 3GPP TS 38.340. This table is called the Downlink Traffic to Routing ID Mapping Configuration table or the Uplink Traffic to Routing ID Mapping Configuration table of the IAB donor DU of the initiator IAB node. In intermediate IAB nodes, the BAP header fields are already defined in the BAP packets they forward.

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

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

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

[0068] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and optionally handles data packet integrity. It essentially numbers packets at the emitter side and re-orders packets at the receiver side. The PDCP sublayer is described in 3GPP TS38.323.

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

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

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

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

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

[0074] Figure 2(b) is derived from 3GPP TS 38.300v17.2.0 and shows the protocol stack for supporting RRC and NAS connections for IAB-MT. The Non-Access Stratum (NAS) protocol handles messages between the core network and user equipment, or IAB nodes. It manages the establishment of communication sessions and maintains communication with IAB nodes or user equipment as they move. 5G NAS is described in 3GPP TS 14.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the core network that receives all connection and session-related information from UEs connected to IAB nodes, as well as similar information for IAB nodes. The AMF is solely responsible for handling connection and mobility management tasks.

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

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

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

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

[0079] The memory may include: - a read-only memory 407, denoted ROM, for storing a computer program for implementing the method according to one or more embodiments of the invention; - a random access memory 412, denoted RAM, that stores the executable code of the methods according to one or more embodiments of the present invention, as well as registers adapted to record variables and parameters necessary for carrying out the methods according to one or more embodiments of the present invention.

[0080] Optionally, the communication device 400 may also include the following components: - a data storage means 404, such as a hard disk, for storing a computer program for implementing the method according to one or more embodiments of the present invention; - a hard disk drive 405 for a hard disk 406, the hard disk drive being adapted to read data from or write data to the disk 1106; A screen 409 for displaying the decoded data and / or serving as a graphical interface with the user by means of a keyboard 410 or any other input / output means.

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

[0082] Disk 406 may optionally be replaced by any information medium, such as a rewritable or non-rewritable compact disk (CD-ROM), a ZIP disk, a USB key or a memory card, and in general any information storage means that can be read by a microcomputer or microprocessor, integrated or not in a communication device, possibly removable, and adapted to store one or more programs that, when executed, can perform the methods according to embodiments of the present invention.

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

[0084] The central processing unit 411 may be adapted to control and direct the execution of a program or part of a program's instructions or software code according to the invention, stored in one of the storage means mentioned above. On power-up, the program or programs stored in a non-volatile memory, for example the hard disk 404 or the read-only memory 407, are transferred to the random access memory 412, which memory contains registers for storing the program or the program's executable code as well as variables and parameters necessary to implement the invention.

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

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

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

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

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

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

[0091] IAB topology 5003 includes IAB donor CU 503 (identified as Donor 3-CU in FIG. 5), its associated IAB donor DU 507 (identified as Donor 3-DU1 in FIG. 5), and IAB node 560, which is similar to IAB nodes 121 and 122.

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

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

[0094] 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 topology 5002 that is configured and managed or controlled by the IAB donor CU 502.

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

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

[0097] It is assumed that the mobile IAB node 570 initially has a single parent IAB node 520, and that the IAB node 570 belongs to the IAB topology 5001 controlled by the IAB donor CU 501. Thus, the IAB donor CU is operating as an F1-terminating donor CU (also referred to as an F1-terminating IAB donor CU or F1 donor CU). When the mobile IAB node 570 is in the position shown by the dotted line in FIG. 5, as it moves in the IAB topology 5002, particularly in proximity to IAB node 530, the mobile IAB node 570 may be able to establish a wireless BH link with the IAB node 530. Such a BH link is possible for stationary IAB nodes and is highly likely when a mobile IAB node such as the IAB node 570 moves, for example, in the direction of the IAB topology 5002 (indicated by arrow 590 in FIG. 5).

[0098] Then, the F1 donor CU 501 may decide to perform a transition of the MT portion 571 of the IAB node 570 toward the IAB topology controlled by the donor CU 502, which has become a non-F1 terminating donor CU (also referred to as a non-F1 terminating IAB donor CU or non-F1 donor CU, or an RRC donor CU, or an RRC terminating donor CU) for the IAB node 570 (i.e., the MT portion 571 of the IAB node 570 is transitioned toward the parent IAB node 530). For this purpose, the F1 donor CU 501 may initiate an inter-CU Topology Adaptation procedure specified in TS 38.401 V17.2.0 Section 8.17.3.1 or Section 8.17.3.2 (when the IAB node 570 has descendant IAB nodes). As a result, the IAB node 570 still belongs to the IAB topology 5001, and its F1 connection is with the donor CU 501, but its RRC connection is now with the donor CU 2 502. After that procedure, the IAB donor CU 501 may request migration of backhaul traffic (e.g., user traffic, control traffic) associated with the IAB node 570 to the IAB topology 5002 (i.e., via the donor DU 505). In this case, the donor CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 Section 8.5.2. In an IAB communication system, all traffic communicated over the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB-DU. Therefore, the offloaded or migrated traffic or backhaul traffic is F1 traffic and can include control and user traffic.

[0099] While the mobile IAB node 570 is still moving in the direction indicated by arrow 590, the MT portion 571 of the IAB node 570 may be transitioned by the non-F1 donor CU 502 toward the parent IAB node 550 using the backhaul link 5050 between the IAB node 550 and the IAB node 570. To this end, the non-F1 donor CU 502 may apply the intra-CU topology adaptation procedure described in TS 38.401 V17.2.0 Section 8.2.3.1 (or Section 8.17.3.2) to perform a continuous MT transition of the IAB node 570 with a new single parent IAB node 550 (or another MT transition to another IAB node). The IAB node 501 still has its F1 connection with the donor CU 501 and its RRC connection with the donor CU 2 502.

[0100] After being notified to use donor DU 506 instead of donor DU 505 for routing F1 traffic related to IAB node 570, donor CU 501 may request migration of traffic related to IAB node 570 towards IAB topology 5002. In this case, donor CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2.

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

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

[0103] In any state of migration of the MT portion 571 of the IAB node 570, therefore, regardless of whether the MT portion 571 of the IAB node 570 has transitioned to IAB topology 5002 or IAB topology 5003, therefore, regardless of whether the IAB node 570 has a non-F1 terminating donor CU, and if so, whether it is a non-F1 terminating donor CU 502 or 503, the F1 donor CU 501 may decide to perform migration of the DU portion of the IAB node 570. The reason for performing DU migration may be to reduce the processing load on the F1 donor CU 501 or because the IAB node 570 is geographically far from the F1 donor CU 501 and close to an area where there is no longer Xn connectivity between the F1 donor CU 501 and the target donor CU. After deciding to perform DU migration of the IAB node 570, the F1 donor CU 501 must also decide which donor CU (referred to as the target F1 donor CU) toward which the DU migration should be performed. It may be a DU transition (i.e., default selection) toward the current non-F1 terminating donor CU if there is a current non-F1 terminating donor CU, in which case the non-F1 terminating donor CU becomes the target F1 donor CU, or another target F1 donor CU. For example, if IAB node 570 is mobile and its trajectory is predictable (e.g., a bus or train), F1 donor CU 501 may recognize an appropriate target F1 donor CU controlled cell where IAB node 570 will soon connect to the network. For example, IAB node 570's non-F1 terminating donor CU is donor CU 502, but the F1 donor CU may determine that IAB node 570's DU transition should be directly toward donor CU 503 because IAB node 570 is rapidly crossing and cannot remain within the IAB topology 5002 controlled by donor CU 502. Not performing DU transition to donor CU 502 and instead performing DU transition to donor CU 503 avoids protocol messages for intermediate DU transition at IAB node 570.When a DU transition is performed, a handover of the UE served by the IAB node 570 must also be performed. Therefore, not performing a DU transition towards the donor CU 502 will also avoid an intermediate handover of the UE served by the IAB node 570 to the donor CU 502 before the new DU transition and UE handover towards the donor CU 503.

[0104] The procedures for performing DU transition and UE handover to the selected target F1 donor CU are described in more detail with reference to subsequent figures.

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

[0106] IAB node 601 is composed of an IAB-MT portion or unit IAB-MT 610 (like MT portion or MT 571 of IAB node 570 in FIG. 5), a portion or unit IAB-DU1 611, and a portion or unit IAB-DU2 612, which may be a mobile IAB node like IAB node 570. IAB-DU1 and IAB-DU2 are two logical DU entities (also called logical DUs) that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. In a DU transition of IAB node 601, both logical DUs are active, with one of the logical DUs terminating its F1 interface with the source F1 donor CU (like donor CU 501 in FIG. 5) and the other logical DU terminating its F1 interface with the target F1 donor CU (like donor CU 502 or 503 in FIG. 5). Otherwise (i.e., if DU migration is not performed), only one logical DU is sufficient for IAB operation. Referring to the IAB communication system of FIG. 5, as an example, the F1 terminating donor CU of IAB node 601 (i.e., IAB node 570) may therefore be the donor CU 501 operating as the source F1 donor CU. The source F1 donor CU 501 may identify the IAB donor CU 502 as a suitable target F1 donor CU when the source F1 donor CU 501 determines that the IAB node 570 is moving toward or through an IAB topology 5002 that includes network nodes managed by the IAB donor CU 502 (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550), which serve the cell in the IAB topology 5002 to which the IAB node 570 will soon connect.Or for an IAB node that is connected to a parent IAB node or parent IAB donor DU of the IAB topology 5001 managed by the donor CU 501 as an F1 terminating donor CU and is stationary but is in close proximity or neighborhood of one or more IAB nodes in an adjacent IAB topology such as IAB topology 5002, if the source F1 donor CU 501 determines (e.g., based on signal measurements performed at the IAB node on wireless signals received at the IAB node from all IAB nodes close to the IAB node, which may include IAB nodes in the adjacent IAB topology 5002) that the IAB node can immediately connect to an IAB node in the adjacent IAB topology 5002, the IAB donor CU 501 may determine that the source F1 donor CU 502 is a suitable target F1 donor CU.

[0107] Before DU transition, UE 602 (such as UE 580 in FIG. 5) is connected to source F1 donor CU 501 via logical DU IAB-DU1 611, for example, using access link 621 in the cell served by logical DU IAB-DU1 611, and logical DU IAB-DU2 612 is deactivated. In DU transition, logical DU IAB-DU2 612 is activated and connects to target F1 donor CU 502, and UE 602 may also connect to link 622 in the cell served by logical DU IAB-DU2 612 via logical DU IAB-DU2 612. Activation of logical DU IAB-DU2 612 is triggered by the source F1 donor CU and may be performed in the procedure described with reference to FIGS. 12a and 12b. Upon completion of handover of UE 602 from the cell controlled by logical DU IAB-DU1 611 to the cell controlled by logical DU IAB-DU2 612, logical DU IAB-DU1 611 may be deactivated. The deactivation may be triggered by source F1 donor CU 501 using the procedure described with reference to Figure 12c after detection of completion of handover for all UEs served by IAB-DU1 611.

[0108] An example method according to one or more embodiments of the present invention is now described that includes informing an IAB node about the identity of a target donor CU to enable a DU transition of the IAB node to be performed with or without MT transition(s) and to enable handover of a UE served by the IAB node to the target donor CU. While the following method / apparatus is described primarily with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. A method according to one or more embodiments of the present invention may be applied, for example, to a stationary IAB node that is at the edge of one IAB topology and in the vicinity or proximity of one or more IAB nodes of an adjacent IAB topology.

[0109] FIG. 7 is a simplified schematic diagram 700 illustrating some example message flows, including setting up a data path for performing a DU transition of an IAB node, with or without MT transition(s), and for routing packets between a target F1 donor CU and the IAB node via an IAB topology controlled by the IAB node's non-F1 donor CU (or RRC donor CU), in accordance with one or more embodiments of the present invention.

[0110] FIG. 7 also shows IAB node 701, which may be a mobile IAB node such as IAB node 570, consisting of an MT portion or unit IAB-MT 704, a DU portion or unit IAB-DU1 705 (e.g., a source or first logical DU entity or DU), and a DU portion or unit IAB-DU2 706 (e.g., a target or second logical DU entity or DU). Each of the first logical DU entity 705 and the second logical DU entity 706 serves one or more cells identified by an identifier (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)). The cells of IAB-DU1 705 are identified by different values ​​for identifiers (e.g., physical cell identifier (PCI), new radio cell group identifier (NCGI)) compared to the values ​​of the cells of IAB-DU2 706. IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), and in another example, they rely on separate physical layers. The non-F1 donor CU 709 for IAB node 701 can be the source F1 donor CU 703 itself (e.g., donor CU 501) if IAB-MT 704 was not migrated. The non-F1 donor CU for IAB node 701 can be the target F1 donor CU 707 (e.g., donor CU 703) if IAB-MT 704 was previously migrated toward the target F1 donor CU 707, or can be another donor CU (e.g., donor CU 502) if IAB-MT 704 was previously migrated toward this other donor CU (e.g., donor CU 502).

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

[0112] The IAB-MT 704 may transmit measurement reports (not shown in FIG. 7) to its non-F1 terminating donor CU 709 as a result of measurements periodically performed by the IAB-MT 704 on signals received from the serving cell and one or more target cells, such as signal synchronization blocks (SSBs) transmitted in the serving and target cells. If the MT has not transitioned from its F1 terminating donor CU, the non-F1 terminating donor CU is the F1 terminating donor CU (e.g., source F1 donor CU 703) for the IAB node. The target cell may be a cell neighboring the serving or source cell (i.e., the current serving cell). When the IAB-MT 704 discovers at least one SSB that meets a predefined criterion (e.g., received power above a predefined threshold), a measurement report may be generated and transmitted to provide radio link quality information to different cells in the vicinity of the IAB node 701. The identity of each cell is included in the measurement report to enable identification of the target donor CU associated with the cell, either the non-F1 donor CU if the IAB-MT 704 has been transitioned, or the F1 terminating donor CU 703 if the IAB-MT 704 has not been transitioned. In practice, the identity of the donor CU can be deduced from the Physical Cell Identity (PCI) broadcast in each cell managed by this donor CU in synchronization signals and / or from the New Radio Cell Group Identifier (NCGI) broadcast in each cell managed by this donor CU in system information block (SIB) messages. The PCI and / or NCGI can be reported by the IAB node 701 in the measurement report.

[0113] Based on the received measurement report, the non-F1 donor CU 709 if the IAB-MT 704 is being transitioned, or the F1 terminating donor CU 703 if the IAB-MT 704 is not being transitioned, may detect that the IAB node 701 receives a radio signal in a target cell of a target parent IAB node that has better quality than the source serving cell. The non-F1 donor CU 709 if the IAB-MT 704 is being transitioned, or the F1 terminating donor CU 703 if the IAB-MT 704 is not being transitioned, may decide to apply a procedure to perform IAB-MT 704 transition toward a target parent IAB node that belongs to either the same IAB topology (intra-CU topology adaptation) or a different IAB topology (inter-CU topology adaptation). In either case, if the IAB-MT 704 is migrated, the source F1 donor CU 703 is notified of this MT migration by the non-F1 donor CU 709; if the IAB-MT 704 is not migrated, the source F1 donor CU 703 is notified to decide to perform MT migration directly from the measurement reports received from the IAB node 701, and this information can be used by the source F1 donor CU 703 to trigger the DU migration of the IAB node 701. In another example, the non-F1 donor CU 709 may relay information in the measurement reports received from the IAB node 701 to the source F1 donor CU 703. Thus, the source F1 donor CU 703 can base its decision about the DU migration of the IAB node 701 directly from these measurement reports relayed by the non-F1 donor CU 709.

[0114] Thus, the source F1 donor CU 703 determines that the DU of the IAB node should be migrated from the IAB topology of the source F1 donor CU 703 (also referred to as the source IAB topology) to another IAB topology of the target IAB donor CU (also referred to as the target IAB topology). This determination may be based on a determination that the migration of the MT of the IAB node to a new parent IAB node is complete. Another example of a triggering event for determining that the DU of the IAB node is migrated may include the DU migration determination being based on the detection of an MT migration from one IAB topology (e.g., a first IAB topology) to another IAB topology (e.g., a second IAB topology) and a known (predefined) trajectory of the IAB node indicating to the source F1 donor CU that the MT will later be migrated to yet another IAB topology (e.g., a third IAB topology). In this case, to avoid signaling messages for DU transition / UE handover to another IAB topology (e.g., a second IAB topology), the DU is directly migrated toward yet another IAB topology (e.g., a third IAB topology). Another example of a trigger event for determining that a DU of an IAB node should be migrated may include a processing load level at a source F1 donor CU being detected above a predefined threshold. Then, DU transition is triggered, and the selection of a target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU.

[0115] When it is decided or determined by the source F1 donor CU 703 to perform a DU transition of the IAB node 701 to another IAB topology managed by another donor CU, which will be the target F1 donor CU 707, a first step 720 corresponds to sending a request to the IAB node 701 to establish a new F1 connection between the target F1 donor CU 707 and the mobile IAB node 701. This may require activation of a second logical DU IAB-DU2 706 in the mobile IAB node 701, and therefore the first step 720 may include activation of the second logical DU IAB-DU2 706 in the mobile IAB node 701. This operation is performed, for example, using the procedure described with reference to Figures 12a and 12b. In particular, a message sent by the source F1 donor CU 703 to the IAB node 701 for activation of IAB-DU2 706 (e.g., 1203 in FIG. 12a) may include identification information to identify the target donor CU, such as the TNL address (i.e., IP address) of the target F1 donor CU 707, so that a new F1 connection or F1 association (e.g., F1 AP interface connection) may be set up with the target donor CU 707 (between IAB-DU2 706 and the target donor CU 707). If the address of the target F1 donor CU is not included in the activation request, by default, and if the IAB-MT 704 has been migrated to a non-F1 donor CU 709, the non-F1 donor CU 709 is considered the target F1 donor CU. In this case, the IAB node 701 has already been notified of the identity (e.g., TNL address / IP address) of the target F1 donor CU when the IAB-MT 704 was migrated to the non-F1 donor CU 709. In other words, the source F1 donor CU 703 may send identification information to identify the target F1 donor CU 707 when the IAB-MT 704 was migrated to a non-F1 donor CU 709 that is different from (i.e., not the same as) the target F1 donor CU 707. Alternatively, the source F1 donor CU 703 may send identification information to identify the non-F1 donor CU 709 as the target IAB donor CU.

[0116] After determining that the DU of the IAB node 701 should be migrated, when the IAB-DU2 706 is activated, the IAB-DU2 706 may send an F1 Setup Request message (e.g., 1213 in FIG. 12b) to the target F1 donor CU 707 to request the setup of an F1 connection between the IAB node 701 and the target F1 donor CU 707. This message may include identification information for identifying the source IAB donor CU, such as the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the source F1 donor CU 703 of the IAB node 701. The destination address of the F1 setup request message is the target F1 donor CU 707, and when this IP packet is received by a donor DU in the F1 path for IAB node 701, it can be routed in the wired backhaul (508 in FIG. 5 ) to the target F1 donor CU 707. For example, in an example where IAB node 701 is IAB node 570 in FIG. 5 connected to IAB node 550 via backhaul link 5050, an MT in IAB node 570 (MT 571 corresponding to IAB-MT 704 in FIG. 7 ) has been migrated to non-F1 donor CU 502, and IAB donor CU 501 is the source F1 donor CU, the F1 path between F1 donor CU 501 and IAB node 570 uses donor DU 506. If the IAB donor CU 503 is identified (by the F1 donor CU 501) as the target F1 donor CU (e.g., target F1 donor CU 707), an F1 setup request message for the target F1 donor CU (e.g., donor CU 503) may be sent to the donor DU 506 via the IAB nodes 550, 540, and from there routed in the wired backhaul (508 in FIG. 5) to the target F1 donor CU 503. In the F1 setup response (e.g., 1214 in FIG. 12b), the target F1 donor CU 707 (e.g., donor CU 503 in the example described above with reference to FIG. 5) may request the IAB-DU2 706 to activate a new cell with associated identifiers (PCI, NCGI).Typically, a DU activates / deactivates cells under the control of the donor CU that controls the DU, see for example TS 38.473 section 8.2.3.2.

[0117] After the procedure described with reference to FIG. 12b, for example, using the procedure described with reference to FIG. 13a, the target F1 donor CU707 (e.g., in a configuration update message 1303) may notify the source F1 donor CU705 about the activation of the new cell from IAB-DU2 706 of the IAB node 701.

[0118] A next step 730 involves handing over a UE (e.g., UE 708 in FIG. 7) served by the IAB node 701 from the cell of the first logical DU IAB-DU1 705 to the cell of the second logical DU IAB-DU2 706. This procedure may be a standardized procedure described in TS 38.300 section 9.2.3.2 (handover) or a standardized procedure described in TS 38.300 section 9.2.3.4 (conditional handover). In one example, to trigger the handover of the UE 708, the source F1 donor CU 703 sends a HANDOVER REQUEST message to the target F1 donor CU 707, including necessary information related to the UE 708 to be handed over (e.g., identification information identifying the UE, UE context information such as security context (e.g., security parameters such as security keys, UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearers, etc.). TS 38.423 section 9.1.1.1 provides details regarding the contents of the HANDOVER REQUEST message. After an admission control step in which the target F1 donor CU 707 determines whether the donor CU can accept the handover of the UE 708, if the target F1 donor CU 707 accepts the request, the target F1 donor CU 707 sends a handover acknowledgement message to the source F1 donor CU 705, including configuration information for the UE 708 for the handover. The configuration may include radio configuration information indicating the radio configuration to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 of the IAB node 701 in the identified target cell of the second logical DU IAB-DU2 706 (e.g., the radio configuration may include frequency, radio bearer configuration, etc.). The handover acknowledgement may include an identifier for each of one or more new cells (e.g., target cells) activated in the second logical DU IAB-DU2 706.The source F1 donor CU 705 then transmits this configuration information to the UE 708 via the IAB node 701 in an RRC Reconfiguration message, which includes an identifier of the target cell in IAB-DU2 706 to which the UE 708 should connect. The RRC Reconfiguration message (specified in TS 38.331) is embedded in an F1 message DL RRC MESSAGE TRANSFER (specified in TS 38.473) and sent to the IAB-DU1 705, which relays it to the UE 708. Upon receiving this configuration information, the UE 708 performs a random access procedure in the indicated target cell in IAB-DU2 706 to obtain uplink resources, and then transmits an RRC Reconfiguration Complete message to the target F1 donor CU 707. The RRC Reconfiguration Complete message (specified in TS 38.331) is sent to IAB-DU2 706, which then embeds it in an F1 message UL RRC MESSAGE TRANSFER (specified in TS 38.473) and sends it to the target F1 donor CU 707. The source F1 donor CU 705 can be notified about the completion of the handover of the UE 708 via a HANDOVER SUCCESS message (specified in TS 38.423) received from the target F1 donor CU 707.

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

[0120] The source F1 donor CU 705 may also release traffic (user traffic, control traffic) related to UEs served by the IAB node 701 via the IAB-DU1 705 and the source F1 donor CU 705. If traffic is offloaded in an IAB topology controlled by a non-F1 donor CU 709 (e.g., when an MT of the IAB node 701 is migrated to the non-F1 donor CU 709), the source F1 donor CU 705 may request the release of traffic to the non-F1 donor CU 709 by applying the procedure described with reference to FIG. 13b. This is generally represented by procedure 735 in FIG. 7.

[0121] Finally, the target F1 donor CU 707 must set up a data path to / from the migrated IAB node 701 either in the topology it has if there is a backhaul path to reach the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., if the target F1 donor CU 707 is a non-F1 terminating donor CU for the IAB node 701 because the IAB-MT 704 was previously migrated to the target F1 donor CU 707), or via the IAB topology of the non-F1 donor CU 709 of the IAB node 701 if there is no backhaul path to reach the IAB node 701 in the IAB topology controlled by the target F1 donor CU 707 (i.e., if the IAB-MT 704 and the IAB-DU2 706 are connected to different donor CUs). In this latter case, the target F1 donor CU 707 may trigger a transport migration and path switching procedure 731, including a request for traffic migration to the non-F1 donor CU 709 of the IAB node 701 and a path switching procedure towards the core network 702, as described with reference to Figure 13b. As an example of the latter case with reference to Figure 5, IAB node 701 is IAB node 570 of Figure 5 connected to IAB node 550 via backhaul link 5050, an MT of IAB node 570 (MT 571 corresponding to IAB-MT 704 in Figure 7) has been migrated to the non-F1 donor CU 502, and IAB donor CU 501 is an F1 donor CU. When a DU of IAB node 570 (DU 572 corresponding to IAB-DU2 706 in FIG. 7) is migrated to target donor CU 503 and therefore has an F1 connection to F1 donor CU 503, but MT 571 remains connected via an RRC connection to non-F1 donor CU 502 (its RRC connection), a data path or backhaul path to / from IAB node 570 is set up by performing a traffic migration procedure (e.g., as described with reference to FIG. 13b) in IAB topology 5002 controlled by IAB donor CU 502 (i.e., a backhaul path to IAB node 570 via IAB donor DU 506, IAB nodes 540 and 550).The target donor CU 503 may also perform a path switch procedure toward the core network 702 to request delivery of user data associated with the UE 708 / 580. For example, the target donor CU 503 may perform a path switch handshake procedure as described in 3GPP TS 38.413v17.2.0 section 8.4.4.

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

[0123] After the handover of the UE 708 and the setup of the new data path are performed (731), downstream user data is transmitted by the core network 702 via bearer 740 to the target F1 donor CU 707, then via backhaul bearer 741 to the logical DU IAB-DU2 706 of the IAB node 701, and finally via data radio bearer 742 to the UE 708. The backhaul bearer 741 can be established in an IAB topology controlled by the target F1 donor CU 707 or in an IAB topology controlled by a non-F1 donor CU 709 of the IAB node 707 (e.g., depending on whether the IAB-MT 704 and IAB-DU2 706 of the IAB node 701 are connected to different donor CUs). Upstream user data (not shown) is transmitted in the opposite direction via a similar bearer. If the target F1 donor CU 707 is different (i.e., not the same donor CU) from the F1 donor CU of the IAB node (e.g., non-F1 donor CU 709), the target F1 donor CU 707 needs to be able to identify the non-F1 donor CU 709 in order to request traffic migration to the donor CU of the IAB node 701 (non-F1 donor CU 709 if the MT has migrated or F1 donor CU 703 if the MT has not migrated).

[0124] FIG. 14 is a flowchart illustrating an example method 1400 according to one or more embodiments of the present invention, performed at a target IAB donor CU for use in managing transport migration of traffic associated with an IAB node. The transport migration is performed after a DU of the IAB node is migrated from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU. Method 1400 may be performed as part of a DU migration process for migrating a DU of the IAB node. For example, with reference to the IAB communication system 500 shown and described with respect to FIG. 5, the source IAB donor CU performing method 1400 may be the IAB donor CU 501 (e.g., the F1 terminating donor CU of the IAB node 570 to which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (e.g., a source IAB topology) controlled by the IAB donor CU 501 (e.g., a source F1 IAB donor CU). The migration process may involve migration from the IAB topology 5001 of the DU 572 of the IAB node 570 to an IAB topology 5003 (e.g., a target IAB topology) managed by the IAB donor CU 503, which is the target IAB donor CU. The method 1400 shown and described with respect to FIG. 14 may be performed by software and / or hardware elements. The source IAB donor CU may be implemented in the communications device 400 as shown and described with respect to FIG. 4, with the method shown and described with respect to FIG. 14 performed by an apparatus for the target IAB donor CU, including one or more processing units, such as the central processing unit 411.

[0125] Briefly, in step 1402, the target IAB donor CU 503 receives a notification including identification information to identify an IAB donor CU (e.g., an MT, such as MT 571, that is co-located with a DU, such as DU 572, of the IAB node) that serves an MT of the IAB node 570. The IAB donor CU that serves an MT of the IAB node 570 is a different IAB donor CU from the target IAB donor CU. The IAB donor CU that serves an MT of the IAB node 570 may be a source IAB donor CU (e.g., a source F1 IAB donor CU, such as IAB donor CU 501, is a non-F1 IAB donor CU) when the MT of the IAB node 570 has not been migrated from the source IAB donor CU. Alternatively, the IAB donor CU serving the MT of IAB node 570 may be another or second IAB donor CU (e.g., a non-F1 IAB donor CU or an RRC IAB donor CU, such as IAB donor CU 502) when the MT of IAB node 570 is migrated to a second IAB donor CU, such as IAB donor CU 502. Whether the non-F1 IAB donor CU for the migrated MT of IAB node 570 is the source F1 donor CU 501 or the non-F1 IAB donor CU 502, the target IAB donor CU is a different IAB donor CU 503.

[0126] As described in more detail below with reference to Figures 8, 9a through 9d, the target IAB donor CU 503 may receive a notification from the source IAB donor CU 501, such as in a DU transition notification including the identification information, or in a configuration update notification including the identification information, or may receive it from the IAB node 570, such as in an F1 setup request including the identification information. The DU transition notification sent by the source IAB donor CU 501 may be a DU transition notification message 811, described below with reference to Figures 8 and 9a and 9d. The configuration update notification sent by the source IAB donor CU 501 may be a configuration update notification message 817, described below with reference to Figures 8 and 9a and 9d. The F1 setup request sent by the IAB node 570 may be an F1 setup request message 814, as described below with reference to Figures 8 and 9b, 9c, and 9d. The F1 setup request is sent by an IAB node after receiving a request to establish an F1 connection (e.g., a new F1 connection) from the source IAB donor CU 501 to inform the target IAB donor CU of the identity of the IAB donor CU that serves the IAB node's MT. The request from the source IAB donor CU 501 may be sent in a DU activation request 813. The request from the source IAB donor CU 501 may indicate (explicitly or implicitly) to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU that serves the IAB node's MT. For example, the request from the source IAB donor CU 501 may include information to indicate to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU that serves the MT. This information may include an information element (IE) to indicate that the IAB node is notifying the target IAB donor CU of the identity of the IAB donor CU that serves the IAB node's MT, as described below with respect to FIG. 12a and the configuration request message 1203.The presence of the IE in the request to establish an F1 connection may indicate to the IAB node that the IAB node will inform the target IAB donor CU of the identity of the IAB donor CU, or when the IE has a value (e.g., the IE is one bit and the value may be "1" or "0"), it may indicate to the IAB node that the IAB node will inform the target IAB donor CU of the identity of the IAB donor CU. In another example, the information may include identification information for identifying the IAB donor CU that serves the MT of IAB node 570, and the presence of the identification information in the request itself may indicate to the IAB node that the IAB node will inform the target IAB donor CU of the identity of the IAB donor CU.

[0127] As described in more detail below with reference to Figures 10, 11a to 11c, when the IAB donor CU serving the MT of IAB node 570 is another IAB donor CU managing another IAB topology (e.g., when the MT has transitioned to another IAB donor CU, such as a second IAB donor CU 502 managing a second IAB topology 5002), the target IAB donor CU 503 may receive a notification from the second IAB donor CU 502 (e.g., a non-F1 donor CU or an RRC donor CU). In this case, the notification may be sent in a transport transition ready notification including identifying information, such as in a transport transition ready message 1013, as described below with reference to Figures 10 and 11a to 11c.

[0128] The identification information for identifying the IAB donor CU serving the MT of the IAB node 570 may be an identifier such as the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the IAB donor CU serving the MT of the IAB node.

[0129] The notification may also include identification information for identifying the MT 571 of the IAB node 570. For example, the identification information may be an identifier of the MT 571 of the IAB node 570 known to the IAB donor CU serving the MT 571 of the IAB node 570 (e.g., known to the F1 donor CU 501 (when the MT is not migrated) or known to the non-F1 donor CU 502 (when the MT is migrated)). When the MT is migrated, the identifier is known by the non-F1 donor CU 502 through the information element non-F1-Terminating IAB-donor UE XnAP ID defined in TS 38.423 Section 9.2.3.16, or the RRC-Terminating IAB-donor UE XnAP ID information element as the NG-RAN Node UE XnAP ID, which uniquely identifies the UE over the Xn interface in the NG-RAN node. Therefore, each donor CU assigns a value to each MT of an IAB node in its IAB topology (an IAB-MT is considered a UE). Another identifier of an MT of an IAB node known by a non-F1 donor CU (or RRC donor CU) is the BAP address assigned by this non-F1 donor CU. In fact, each IAB donor CU that terminates an RRC connection with an IAB node must assign a BAP address to this IAB node (to use as the destination BAP address of BAP packets routed to this IAB node in the IAB topology controlled by this IAB donor CU).

[0130] In step 1404, the target IAB donor CU 503 performs a transport transition based on the identification information included in the notification (received from the source IAB donor CU 501 or IAB node 570, as described above) to transition traffic related to or associated with the IAB node 570 (e.g., F1 traffic, which may include control and user traffic) for routing via at least one path between the target IAB donor CU 503 and the IAB node 570 through an IAB topology managed by the IAB donor CU serving the MT 571 of the IAB node 570 (e.g., via the IAB topology 5001 managed by the source IAB donor CU 501 when the MT has not been transitioned from the source F1 IAB donor CU 501, or via the IAB topology 5002 managed by the non-F1 IAB donor CU 502 when the MT has been transitioned to the non-F1 IAB donor CU 502) after the DU 572 of the IAB node 570 has been transitioned to the target IAB topology 5003. For example, target IAB donor CU 503 sends a traffic migration request (eg, message 1014 in FIG. 10, message 1313 in FIG. 13b) to the IAB donor CU serving MT 571 of IAB node 570.

[0131] 8 is a simplified diagram 800 illustrating an example message flow for providing identification information identifying an IAB donor CU serving an MT in the IAB node (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU) to a target IAB donor CU (e.g., an F1 terminating donor CU) of a DU transition of the IAB node as part of the IAB node's DU transition process for use in managing or facilitating transport transition, in accordance with one or more embodiments of the present invention. The target IAB donor CU may be provided with the identification information in a notification received from the source IAB donor CU, such as a DU transition notification or a configuration update notification, or in a notification received from the IAB node, such as an F1 setup request. Examples of these are described below.

[0132] FIG. 8 illustrates an IAB node 801, which may be a mobile IAB node such as IAB node 570, consisting of a source F1 donor CU 803, such as donor CU 501, a target F1 donor CU 807, such as donor CU 503, and an MT portion or unit IAB-MT 804, a DU portion or unit IAB-DU1 805 (e.g., a source or first logical DU entity or DU), and a DU portion or unit IAB-DU2 806 (e.g., a target or second logical DU entity or DU). Each of the first logical DU entity 805 and the second logical DU entity 806 serves one or more cells. IAB-DU1 805 and IAB-DU2 806 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers.

[0133] At the start of the flow, the IAB node 801 belongs to a source IAB topology controlled by a source F1 donor CU 803. When the source F1 donor CU 803 decides or determines to perform a DU transition of the IAB node 801 to an IAB topology managed by a target F1 donor CU 807, the first step corresponds to sending a DU activation request message 813 to the IAB node 801 via a second logical DU IAB-DU2 804 to establish a new F1 connection between the target F1 donor CU 807 and the mobile IAB node 801. Activation of the second logical IAB-DU2 806 in the mobile IAB node 801 is performed in operation 810. The message 813 sent by the source F1 donor CU 803 to the IAB node 801 for activation of IAB-DU2 806 is sent to the first logical DU IAB-DU1 805 because the source F1 donor CU 803 has an F1 connection with this first logical DU of the IAB node 801. The DU activation request message 813 may be a configuration request message 1203 as shown in Figure 12a. This message 813 includes a request to establish an F1 connection and a request to inform the target donor CU 807 of the identity of the IAB donor CU serving the MT 804 of the IAB node 801. The request may indicate (explicitly or implicitly) to the IAB node 801 that the IAB node informs the target donor CU 807 of the identity of the IAB donor CU that serves the IAB node's MT (e.g., when the target donor CU 807 is a different IAB donor CU than the IAB donor CU that serves the IAB node's MT).

[0134] After activation of the second logical DU IAB-DU2 806, the information contained in the message 813 may be sent from the first logical DU IAB-DU1 805 to the second logical DU IAB-DU2 806.

[0135] In particular, message 813 may include identification information for identifying the target donor CU 807, such as the TNL address (i.e., IP address) of the target F1 donor CU 807, so that a new F1 connection or F1 association (e.g., F1AP interface connection) can be set up with the target donor CU 807 (between IAB-DU2 806 and target donor CU 807). This message 813 may also include a request to inform the identified target F1 donor CU 807 of the identity of the IAB donor CU serving the MT04 of the IAB node 801, for example, the TNL address (i.e., IP address) and / or the identifier of the IAB donor CU serving the MT804 of the IAB node 801 (i.e., Global NG-RAN Node ID as specified in section 9.2.2.3 of TS 38.423 V17.2.0). Message 813 may include information to inform the IAB node that the IAB node will inform the target IAB donor CU of the identity of the IAB donor CU serving the MT. The information may include an information element (IE) to inform the target IAB donor CU that the IAB node will inform of the identity of the IAB donor CU serving the MT at the IAB node (see FIG. 12a and the following discussion regarding configuration request message 1203). For example, when the MT has not been migrated from the source F1 donor CU 803, the IAB donor CU serving MT 804 is the source F1 donor CU 803 of IAB node 801, and when the MT is being migrated, the IAB donor CU serving MT 804 is a non-F1 / RRC donor CU of IAB node 801 (non-F1 donor CUs are not shown in FIG. 8). The message 813 may also include identification information for identifying the IAB donor CU serving the MT804 of the IAB node 801, such as a TNL address (i.e., IP address) and / or an identifier of the IAB donor CU serving the MT804 of the IAB node 801 (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3).In one example, the information indicating to the IAB node that the IAB node is notifying the target IAB donor CU of the identity of the IAB donor CU serving MT804 may include identification information for identifying the IAB donor CU serving MT804 of IAB node 801, and the presence of the identification information may itself indicate to IAB node 801 that the IAB node is notifying the target F1 donor CU 807 of the identity of the IAB donor CU serving MT804. Further, message 813 may include an identifier of IAB-MT804 as known by the IAB donor CU serving MT804 of IAB node 801. If the IAB donor CU serving MT 804 is a non-F1 donor CU, message 813 may include an identifier with the information element "non-F1-Terminating IAB-donor UE XnAP ID" defined in TS 38.423 Section 9.2.3.16, or an information element "RRC-Terminating IAB-donor UE XnAP ID" as the NG-RAN Node UE XnAP ID, which uniquely identifies the UE via the Xn interface within the NG-RAN node. Thus, each donor CU assigns a value to each MT of the IAB node in its IAB topology (the IAB-MT is considered a UE). The F1 donor CU 803 assigned an ID to the IAB-MT 804 when it was authorized in the IAB topology. During MT transition, the non-F1 donor CU assigns another ID to the IAB-MT 804. Both IDs are exchanged in the handover request / acknowledgement message.

[0136] Upon activation, the IAB-DU2 806 may send an F1 Setup Request message 814 to the target F1 donor CU 807 to request the setup of an F1 connection between the IAB node 801 and the target F1 donor CU 807. This message 814, described at reference 1213 in FIG. 12b, may include identification information for identifying the source F1 donor CU 803, such as a TNL address (i.e., IP address) and / or an identifier of the source F1 donor CU 803 of the IAB node 801 (i.e., a Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3). This message 814 includes identification information for identifying the IAB donor CU serving the MT 804 of the IAB node 801 (e.g., if the target donor CU 807 is a different IAB donor CU from the IAB donor CU serving the MT of the IAB node). If the non-F1 donor CU is different from the target F1 donor CU 807, this message 814 includes the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-F1 donor CU of the IAB node 801. Additionally, the message 814 may include an identifier of the IAB-MT 804 known by the IAB donor CU serving the MT 804 of the IAB node 801. If the IAB donor CU serving the MT 804 is a non-F1 donor CU, the message 814 may include an identifier known by the non-F1 donor CU with the information element non-F1-Terminating IAB-donor UE XnAP ID or RRC terminating IAB-donor UE XnAP ID.Additionally or alternatively, the message 814 may include an identifier of the IAB-MT 804 known by the non-F1 donor CU with the information element BAP address (i.e., a BAP address assigned by the non-F1 donor CU or RRC donor CU when the IAB-MT 804 established an RRC connection and received that BAP address in an RRC Reconfiguration message from the non-F1 / RRC donor CU). The BAP address information element is described, for example, in TS 38.423 V17.2.0, section 9.2.2.89. Finally, the message 814 may include an identifier gNB-DU ID of the second logical DU IAB-DU2 806 of the IAB node 801. As specified in TS 38.423, section 9.3.1.19, the gNB-DU ID uniquely identifies a gNB-DU at least within a gNB-CU. Thus, logical DUs of an IAB node are assigned unique IDs by configuration. The unique ID may be provided to the F1 IAB donor CU that terminates the F1 connection with the logical DU in the F1 setup procedure (described in FIG. 12b).

[0137] In the F1 setup response 815 (also described with reference 1214 in FIG. 12b), the target F1 donor CU 807 may request the IAB-DU2 806 to activate a new cell with associated identifiers (PCI, NCGI). Typically, a DU activates / deactivates a cell under the control of the donor CU controlling the DU. See, for example, TS 38.473 section 8.2.3.2.

[0138] After receiving the F1 Setup Response message 815, the IAB-DU2 806 may inform the IAB-DU1 805 about the result of the activation procedure (i.e., activation of the IAB-DU2 806 and activation of the new cell). The IAB-DU1 805 may then relay this information to the source F1 donor CU 803 via the message DU Activation Response 816. This message 816 may include the gNB-DU ID of the second logical DU IAB-DU2 806 of the IAB node 801. The message 816 is further described with reference to reference numeral 1204 of Figure 12a.

[0139] As another exemplary method for providing identification information identifying an IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) serving an MT in the IAB node to a target F1 terminating donor CU for a DU migration of the IAB node, the source F1 donor CU 803 may directly send a notification to the target donor CU 807 including identification information identifying the IAB donor CU serving an MT in the IAB node (e.g., if the target donor CU 807 is a different IAB donor CU from the IAB donor CU serving an MT in the IAB node). The notification may be sent to the target F1 donor CU 807 in a DU migration notification message 811. The message 811 may be sent before initiating the IAB-DU2 806 setup procedure (reference 720 in FIG. 7 and references 810, 813, 814, 815, 816 in FIG. 8). Message 811 may be followed by a DU migration response message 812 sent by the target F1 donor CU 807 to the source F1 donor CU 803 as an acknowledgement. Messages 811 and 812 may correspond to the procedure described with reference to Figure 13a, where message 811 corresponds to message 1303 and message 812 corresponds to message 1304. In another example, messages 811 and 812 may correspond to the procedure described with reference to Figure 13b, where message 811 corresponds to message 1313 and message 812 corresponds to message 1314. This message 811 includes identification information for identifying the IAB donor CU serving the MT 804 of the IAB node 801. If the MT804 is transitioned to a non-F1 / RRC donor CU and this non-F1 donor CU is different from the target F1 donor CU807, the DU transition notification message 811 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the non-F1 donor CU of the IAB node 801.The message 811 may also include an identifier of the IAB node 801 known by the source F1 donor CU 803 with either the information element F1-Terminating IAB-donor UE XnAP ID, which identifies the MT 804 of the IAB node 801, or the information element gNB-DU ID, which identifies the first logical DU IAB-DU1 805 of the IAB node 801. Furthermore, the message 811 may include an identifier of the IAB node 801 known by the IAB donor CU serving the MT 804 of the IAB node 801. If the IAB donor CU serving the MT 804 is a non-F1 donor CU 803, the message 811 may include an identifier known by the non-F1 donor CU with the information element non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID, which identifies the MT 804 of the IAB node 801. Message 811 may also, or alternatively, include a BAP address assigned by the non-F1 / RRC donor CU, including that this BAP address was previously provided to the F1 donor CU 803 by the non-F1 donor CU when the MT 804 was migrated (e.g., using the procedure described in Figure 13a).

[0140] The F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID (or RRC-Terminating IAB-donor UE XnAP ID) correspond to the NG-RAN node UE XnAP ID specified in TS 38.423 section 9.2.3.16.

[0141] As another exemplary method for providing identification information identifying an IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) serving an MT in the IAB node to a target F1 terminating donor CU for a DU transition of the IAB node, the source F1 donor CU 803 may send a notification including identification information identifying the IAB donor CU serving an MT in the IAB node directly to the target donor CU 807 (e.g., if the target F1 donor CU 807 is a different IAB donor CU from the IAB donor CU serving an MT in the IAB node). The notification may be sent to the target F1 donor CU 807 in a Configuration Update message 817. Message 817 may be sent at any time before or after initiation of the IAB-DU2 806 procedure (reference 720 in FIG. 7 and references 810, 813, 814, 815, 816 in FIG. 8). It may also be sent when the source F1 donor CU 803 detects a change in the non-F1 / RRC donor CU for the IAB node 801. For example, if an MT transition process for the IAB node 801 is performed during the IAB node 801's DU transition and the source F1 donor CU 803 has already provided the target F1 donor CU 807 with the address and / or identifier of the old non-F1 / RRC donor CU, the source F1 donor CU may send an update including the address / identifier of the new non-F1 / RRC donor CU via message 817.

[0142] Thus, the configuration update message 817 includes identification information for identifying the IAB donor CU serving the MT 804 of the IAB node 801. For example, the message 817 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the non-F1 donor CU of the IAB node 801 if this non-F1 donor CU is different from the target F1 donor CU 807. Additionally, the message 817 may include the identifier of the IAB node 801 as known by the IAB donor CU serving the MT 804 of the IAB node 801. If the IAB donor CU serving MT804 is a non-F1 donor CU 803, message 817 may include a non-F1-Terminating IAB-donor UE XnAP ID (or RRC-Terminating IAB-donor UE XnAP ID) identifier, known by the non-F1 donor CU, of an information element identifying MT804 of the IAB node 801. Message 817 may also, or alternatively, include a BAP address assigned by the non-F1 / RRC donor CU, including that this BAP address was previously provided to the F1 donor CU 803 by the non-F1 donor CU (e.g., using the procedure described in FIG. 13a), for example, when MT804 was transitioned. Message 817 may also include a gNB-DU ID identifying a first logical DU IAB-DU1 805 of the IAB node 801 and / or a gNB-DU ID identifying a second logical DU IAB-DU2 806 of the IAB node 801.

[0143] When the target F1 donor CU 807 is an IAB donor CU serving an MT in an IAB node 801, information identifying the IAB donor CU serving the MT in the IAB node and an identifier for the IAB node 801, known as the IAB donor CU serving the MT 804, may also be present in the message 817. This avoids confusion on the part of the target F1 donor CU 807 to understand that the DU transition pertains to the same IAB node 801 as the MT 804.

[0144] Message 817 may be followed by a configuration acknowledgement message 818 sent by target F1 donor CU 807 to source F1 donor CU 803.

[0145] Messages 817 and 818 may correspond to the procedure described in FIG. 13 a, with message 817 corresponding to configuration update message 1303 and message 818 corresponding to configuration acknowledgement message 1304.

[0146] The source F1 donor CU 803 needs to know the identifier of the non-F1 donor CU to communicate this identifier to the target F1 donor CU 807. If the MT 804 of the IAB node 801 was previously migrated and the source F1 donor CU 803 was the source non-F1 / RRC donor CU for this MT transition, or if the MT 804 of the IAB node 801 is migrated during a DU transition and the source F1 donor CU 803 is also the source non-F1 / RRC donor CU for this MT transition, the source F1 donor CU 803 automatically knows the identifier of the target non-F1 / RRC donor CU, which can be indicated to the target F1 donor CU via message 817. In the case of a continuous MT transition, the source non-F1 donor CU for the MT transition is not the source F1 donor CU 803. To be informed of the identifier of the target non-F1 donor CU (i.e., new non-F1 donor CU), the source F1 donor CU 803 may receive a message (not shown in the figure) from the source non-F1 / RRC donor CU, for example, when MT transition is completed. To inform the target F1 donor CU of the identifier of the non-F1 donor CU, the source F1 donor CU 803 may relay the message received from the source non-F1 donor CU. The source non-F1 donor CU for MT transition in the IAB node may inform the F1 donor CU in the IAB node about the identifier of the target non-F1 / RRC donor CU through the procedure described with reference to FIG. 13a.

[0147] In successive MT transitions for a mobile IAB node, the F1 donor CU of the IAB node may not be the source donor CU of the previous MT transition. Furthermore, note that during a DU transition of the IAB node, there may be two different donor CUs serving two logical DUs of the IAB node. Then, a question that may arise is how the source non-F1 donor CU for the MT transition identifies the F1 donor CU for the IAB node.

[0148] It may be proposed that the F1 donor CU for an IAB node is the donor CU that triggered the transport transition management (TMM) procedure for traffic related to the IAB node. In fact, the MT transition process includes an MT handover process similar to a UE handover, followed by a TMM procedure initiated by the F1 donor CU to send / receive packets related to the IAB node via the IAB topology that controls the non-F1 donor CU. The TMM procedure corresponds to the procedure described in Figure 13b.

[0149] However, the specific case must be considered where there is no active transport migration established for the migrated IAB node. Therefore, it is proposed that the source non-F1 donor CU for the MT migration informs the target non-F1 donor CU about the F1 donor CU of the migrated IAB node. This can be done by the procedure described in Figure 13a.

[0150] Furthermore, if a DU transition occurs while there is no active transport transition, the non-F1 donor CU should be notified about the new F1 donor CU. Then, in a DU transition of an IAB node, it may be considered that the source F1 donor CU notifies the non-F1 donor CUs serving the co-located MT about the target F1 donor CU. This may be done by the procedure described in Figure 13a.

[0151] As another exemplary method of providing identification information identifying an IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) serving an MT of the IAB node to a target F1 terminating donor CU for the IAB node's DU transition, the IAB node 801 may send a notification directly to the target F1 donor CU 807 including identification information identifying the IAB donor CU serving an MT of the IAB node (e.g., if the target donor CU 807 is a different IAB donor CU from the IAB donor CU serving an MT of the IAB node). The notification may be sent from IAB-DU2 806 to the target F1 donor CU 807 in a configuration update message 819. Information identifying the IAB donor CU serving an MT of the IAB node may also be present in the configuration update message 819 when the target F1 donor CU 807 is the IAB donor CU serving an MT of the IAB node 801. This avoids confusion at the target F1 donor CU 807 to understand that the DU transition pertains to the same IAB node 801 as the MT 804. The configuration update message 819 may be sent any time after completion of the IAB-DU2 806 setup procedure (reference 720 in FIG. 7 and references 810, 813, 814, 815, 816 in FIG. 8). It may also be sent when the IAB node 801 detects a change in non-F1 / RRC donor CU. For example, when the MT transition process of the IAB node 801 is performed during the DU transition of the IAB node 801. This exemplary method assumes that the IAB-MT 804 informs the IAB-DU2 806 of the current non-F1 donor CU via internal communication in the IAB node 801 between the IAB-MT 804 and the IAB-DU2 806.

[0152] Thus, the configuration update message 819 includes identification information for identifying the IAB donor CU serving MT 804 of the IAB node 801. For example, the configuration update message 819 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the non-F1 donor CU of the IAB node 801. Additionally, the configuration update message 819 may include an identifier of the IAB node 801 known by the IAB donor CU serving MT 804 of the IAB node 801 (e.g., a non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID identifying MT 804, and / or a BAP address identifying MT 804). It may also include a gNB-DU ID identifying the first logical DU IAB-DU1 805 of the IAB node 801 and / or a gNB-DU ID identifying the second logical DU IAB-DU2 806 of the IAB node 801.

[0153] Identification information (i.e., the identifier of the IAB donor CU serving MT804 and the identifier of MT804 known by this IAB donor CU) may be provided to MT804 by the IAB donor CU serving MT804. For example, the IAB donor CU serving MT804 may use the message RRCReconfiguration specified in TS 38.331 V17.2.0 and modify it to include information elements for its TNL address (i.e., IP address) and / or its identifier (i.e., Global NG-RAN Node ID specified in TS 38.423 V17.2.0 Section 9.2.2.3), and its identifier for MT804 (i.e., non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID defined in TS 38.423 Section 9.2.3.16). For example, the RRCReconfiguration message is sent when the IAB node 801 is integrated into the network (i.e., upon initial connection to an IAB donor CU) and following the transition of MT804 of the IAB node 801. In this latter case, the RRCReconfiguration message is sent by the target non-F1 donor CU during the IAB inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 Section 8.17.3. The RRCReconfiguration message may also indicate the BAP address assigned to the IAB node 801 by the non-F1 donor CU.

[0154] The configuration update message 819 may be followed by a configuration acknowledgement message 820 sent by the target F1 donor CU 807 to IAB-DU2 806.

[0155] Messages 819 and 820 may correspond to the procedure described with reference to FIG. 12d, with configuration update message 819 corresponding to configuration update message 1233 and configuration acknowledgement message 820 corresponding to configuration acknowledgement message 1234.

[0156] 9a is a flowchart of an exemplary method 900 according to an embodiment of the present invention for managing a DU transition of an IAB node, which involves informing a target IAB donor CU (e.g., an F1 terminating donor CU) at a source IAB donor CU (e.g., an F1 terminating donor CU) of an IAB donor CU (e.g., a non-F1 / RRC terminating donor CU) that serves an MT at the IAB node. For example, method 900 according to an embodiment of the present invention is performed at the source IAB donor CU and is used in managing or as part of a transition process / procedure for transitioning a DU at the IAB node to the target IAB donor CU, and is used to provide identification information to the target IAB donor CU (e.g., an F1 terminating donor CU) that identifies the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) that serves an MT at the IAB node for use in managing or facilitating a transport transition performed after the DU transition of the IAB node.

[0157] 5, the source IAB donor CU performing method 900 may be an IAB donor CU 501 (e.g., an F1-terminating donor CU or an F1 donor CU of an IAB node 570 with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 that belongs to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migration of a DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by a target IAB donor CU, the IAB donor CU 503. 7 and 8, the IAB node may be IAB node 701, 801, and the migration process may include migration of a DU of IAB node 701, 801 from a source F1 donor CU 703, 803 to a target F1 donor CU 707, 807. Method 900 as shown and described with respect to FIG. 9a may be performed by software and / or hardware elements. The source IAB donor CU may be implemented in communication device 400 as shown and described with respect to FIG. 4, with method as shown and described with respect to FIG. 9a executed by an apparatus for the source IAB donor CU including one or more processing units, such as central processing unit 411.

[0158] In step 901, a source F1 terminating donor CU (703, 803) similar to donor CU 501 in Figure 5 determines that a DU (701, 801) of an IAB node similar to IAB node 570 in Figure 5 should be migrated from source F1 donor CU 501, 703, 803 to a target F1 donor CU (707, 807) similar to donor CU 503 in Figure 5. For example, source F1 donor CU 501, 703, 803 determines the DU migration of an IAB node similar to IAB node 570 toward a target F1 donor CU similar to donor CU 503, 707, 807. For example, the source F1 donor CU 501, 703, 803 may determine that the DU 572 of the IAB node 570, 701, 801 should be migrated in response to determining that the migration of the MT 571, 704, 804 of the IAB node 570, 701, 801 to a new parent IAB node (which may be a new IAB node or a new IAB donor DU) has completed. Other example triggers for determining that a DU should be migrated are described above. Details of how the source F1 donor CU 501, 703, 803 determines the target F1 terminating donor CU 503, 707, 807 are also described above.

[0159] In step 902, the source F1 terminating donor CU 501, 703, 803 may perform or execute the DU transition of the IAB node through the procedure described at reference 720 in Figure 7. Also, step 902 may be performed after step 903 or step 904.

[0160] In step 903, the source F1 terminating donor CU 501, 703, 803 sends a notification to the target F1 donor CU 503, 707, 807, including identification information for identifying the IAB donor CU serving the MT 571 of the IAB node 570. For example, if the MT 571 has been migrated to a non-F1 / RRC terminating donor CU, the notification includes identification information for identifying the non-F1 terminating donor CU of the IAB node 570, 701, 801. The non-F1 / RRC terminating donor CU may be the donor CU 502 in FIG. 5 (donor CU 709 in FIG. 7). Notification of a non-F1 terminating donor CU 502, 709 may be sent only if this non-F1 terminating donor CU 502, 709 is different from the target F1 donor CU 503, 707, 807 (in other words, if the non-F1 donor CU 502, 709 is not the same IAB donor CU as the target F1 donor CU 503, 707, 807). The message sent in step 903 may be message 811 or message 817 of FIG. 8.

[0161] In step 904, the source F1 terminating donor CU 501, 703, 803 may receive an acknowledgment from the target F1 terminating donor CU 503, 707, 807. The message received in step 904 may be message 812 or message 818 in FIG.

[0162] 9b is a flowchart of another exemplary method 910 according to an embodiment of the present invention for managing a DU transition of an IAB node, which involves informing a target IAB donor CU (e.g., an F1 terminating donor CU) at a source IAB donor CU (e.g., an F1 terminating donor CU) of an IAB donor CU (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU) that serves an MT at the IAB node. For example, the method 910 according to an embodiment of the present invention is performed at the source IAB donor CU and is used in managing or as part of a transition process / procedure for transitioning a DU at the IAB node to the target IAB donor CU, and for providing identification information to the target IAB donor CU (e.g., an F1 terminating donor CU) that identifies the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) that serves an MT at the IAB node for use in managing or facilitating a transport transition performed after the DU transition of the IAB node.

[0163] 5, the source IAB donor CU performing method 910 may be the IAB donor CU 501 (e.g., an F1-terminating donor CU or an F1 donor CU of the IAB node 570 with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 that belongs to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migration of the DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by the target IAB donor CU, the IAB donor CU 503. 7 and 8, the IAB node may be IAB node 701, 801, and the migration process may include migration of a DU of IAB node 701, 801 from a source F1 donor CU 703, 803 to a target F1 donor CU 707, 807. The method 910 as shown and described with respect to FIG. 9b may be performed by software and / or hardware elements. The source IAB donor CU may be implemented in communication device 400 as shown and described with respect to FIG. 4, with the method as shown and described with respect to FIG. 9b performed by an apparatus for the source IAB donor CU including one or more processing units, such as central processing unit 411.

[0164] In step 911, a source F1 terminating donor CU (703, 803) similar to donor CU 501 in Figure 5 determines that a DU (701, 801) of an IAB node similar to IAB node 570 in Figure 5 should be migrated from source F1 donor CU 501, 703, 803 to a target F1 donor CU (707, 807) similar to donor CU 503 in Figure 5. For example, source F1 donor CU 501, 703, 803 determines the DU migration of an IAB node similar to IAB node 570, 701, 801 toward a target F1 donor CU similar to donor CU 503, 703, 803. For example, the source F1 donor CU 501, 703, 803 may determine that the DU of the IAB node 570, 701, 801 should be migrated in response to determining that the migration of the MT 571, 704, 804 of the IAB node 570, 701, 801 to a new parent IAB node (which may be a new IAB node or a new IAB donor DU) has completed. Other example triggers for determining that a DU should be migrated are described above. Details of how the source F1 donor CU 501, 703, 803 determines the target F1 terminating donor CU 503, 707, 807 are also described above.

[0165] In step 912, the source F1 terminating donor CU 501, 703, 803 sends a request to the IAB node 570, 701, 801 to establish an F1 connection (i.e., a new F1 connection) between the target IAB donor CU 503, 707, 807 and the IAB node 570, 701, 801 (e.g., a new F1 association with the target IAB donor CU) and to inform the target IAB donor CU of the identity of the IAB donor CU that serves the MT 571, 704, 804 of the IAB node 570, 701, 801. For example, the source F1 terminating donor CU 501, 703, 803 sends a request for a new F1 connection to the migrated IAB node 570, 701, 801. The request from the source F1 terminating donor CU 501, 703, 803 may indicate (explicitly or implicitly) to the IAB node 570, 701, 801 that the IAB node informs the target IAB donor CU 503, 707, 807 of the identity of the IAB donor CU serving the MT 571, 704, 804 of the IAB node 570, 701, 801. For example, the request from the source IAB donor CU 501 may include information to indicate to the IAB node that the IAB node informs the target IAB donor CU of the identity of the IAB donor CU serving the MT. This information may include an information element (IE) to indicate to the IAB node that the IAB node informs the target IAB donor CU of the identity of the IAB donor CU serving the MT, as described below with respect to FIG. 12a and the configuration request message 1203. The presence of the IE in the request to establish an F1 connection may indicate to the IAB node that the IAB node will notify the target IAB donor CU of the identity of the IAB donor CU, or when the IE has a value (e.g., the IE may be 1 bit and the value may be “1” or “0”), it may indicate to the IAB node that the IAB node will notify the target IAB donor CU of the identity of the IAB donor CU.The request may also include identification information for identifying the IAB donor CU serving the MT 571, 704, 804 of the IAB node 570, 701, 801 (such as the non-F1 / RRC terminating donor CU 502 when the MT has been migrated to the IAB donor CU 502, or the F1 terminating donor CU 501 when the MT has not been migrated). In another example, the information may include identification information for identifying the IAB donor CU serving the MT of the IAB node 570, and the presence of the identification information in the request may itself indicate to the IAB node that it will notify the target IAB donor CU of the identity of the IAB donor CU. The request may be message 813 described with reference to FIG. 8. Using this message, the source F1 donor CU 501, 703, 803 may send a request to the IAB node 570, 701, 801 to indicate a non-F1 / RRC terminating donor CU to the target F1 terminating donor CU 503, 707, 807. The non-F1 / RRC terminating donor CU may be the donor CU 502 in FIG. 5 (709 in FIG. 7).

[0166] In step 913, the source F1 terminating donor CU 501, 703, 803 may receive an activation acknowledgement from the IAB node 570, 701, 801. The message received in step 913 may be the message 816 shown and described with respect to FIG.

[0167] 9c is a flowchart of an exemplary method 920 according to one or more embodiments of the present invention performed at an IAB node for performing an F1 setup request to a target donor CU, illustrating an IAB donor CU serving an MT at the IAB node (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU). For example, method 920 according to an embodiment of the present invention may be performed at an IAB node and used in or as part of a transition process / procedure for transitioning a DU at the IAB node to a target IAB donor CU, for providing identification information identifying the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) serving an MT at the IAB node to the target IAB donor CU (e.g., an F1 terminating donor CU) for use in managing or facilitating a transport transition performed after the DU transition at the IAB node.

[0168] For example, with reference to the IAB communication system 500 shown and described with respect to FIG. 5, the IAB node performing method 920 may be a mobile IAB node 570 belonging to an IAB topology 5001 (also referred to as a source IAB topology) controlled by an IAB donor CU 501 that is a source IAB donor CU (e.g., an F1-terminating donor CU of the mobile IAB node 570 with which the mobile IAB node 570 maintains an F1 connection). The migration process may involve migration of a DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by an IAB donor CU 503 that is a target IAB donor CU. With reference to FIGS. 7 and 8, the IAB node may be a mobile IAB node 701, 801, and the migration process may involve migration of a DU of the IAB node 701, 801 from a source F1 donor CU 703, 803 to a target F1 donor CU 707, 807. The method 920 as shown and described with respect to Figure 9c may be performed by software and / or hardware elements. The IAB node may be implemented in the communications device 400 as shown and described with respect to Figure 4, with the method as shown and described with respect to Figure 9c performed by an apparatus for an IAB node including one or more processing units, such as the central processing unit 411.

[0169] In step 921, an IAB node (701, 801), similar to IAB node 570 of Figure 5, receives a request from a source F1 terminating donor CU (703, 803), similar to donor CU 501 of Figure 5, to establish an F1 connection or a new F1 connection (e.g., an F1 connection between IAB node 570, 701, 801 and a target F1 donor CU (707, 807), similar to donor CU 503 of Figure 5), and to notify the target IAB donor CU of the identity of the IAB donor CU serving the IAB node's MT 571, 704, 804. The request may be message 813 described with reference to Figure 8, and includes a request to notify the target F1 donor CU 503, 707, 807 of the IAB donor CU (e.g., a non-F1 / RRC terminating donor CU) serving the IAB node's MT 571, 704, 804. The non-F1 / RRC terminating donor CU may be the donor CU 502 in FIG. 5 or the donor CU 709 in FIG. 7. The request may include identification information for identifying the IAB donor CU serving the MT 571, 704, 804 of the IAB node. Instead of receiving the identification from a request sent by the source F1 terminating donor CU 501, 703, 803, the IAB node may already know the identity of the IAB donor CU serving the MT 571, 704, 804 of the IAB node. For example, the IAB node may obtain this information during MT transition. In another example, the IAB node may obtain an NR cell global identifier (NCGI) from a system information block (SIB) broadcast in a cell controlled by a parent IAB node in an IAB topology controlled by the non-F1 terminating donor CU. This identifier (NCGI) may be sufficient for the target F1 donor CU to identify the non-F1 terminating donor CU.

[0170] In step 922, in response to (or after) receiving the request for the new F1 connection, the IAB node 570, 701, 801 then sends an F1 setup request to the target F1 donor CU 503, 707, 807, requesting the setup of an F1 connection. The F1 setup request message sent by the IAB node includes identification information for identifying the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) serving the MT of the IAB node (e.g., when the target donor CU 807 is a different IAB donor CU from the IAB donor CU serving the MT of the IAB node). The F1 setup request message may also include identification information for identifying the source F1 terminating donor CU 501, 703, 803. The message sent in step 922 may be message 814 of FIG. 8.

[0171] 9d is a flowchart of an exemplary method 930 for managing transport transition after DU transition of an IAB node at a target IAB donor CU, according to an embodiment of the present invention. Method 930 is an example of method 1400 described above.

[0172] For example, with reference to the IAB communication system 500 shown and described with respect to FIG. 5 , the target IAB donor CU performing method 930 may be the IAB donor CU 503 that controls the IAB topology 5003. The IAB node may be a mobile IAB node 570 that belongs to the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve migration of a DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003. With reference to FIGS. 7 and 8 , the IAB node may be an IAB node 701, 801, and the migration process may include migration of a DU of the IAB node 701, 801 from a source F1 donor CU 703, 803 to a target F1 donor CU 707, 807. Method 930 as shown and described with respect to FIG. 9d may be performed by software and / or hardware elements. The target IAB donor CU may be implemented in a communication device 400 as shown and described with respect to FIG. 4 using the method shown and described with respect to FIG. 9d, executed by an apparatus for the target IAB donor CU including one or more processing units, such as a central processing unit 411.

[0173] In step 931, a target F1 terminating donor CU (707, 807), similar to the IAB donor CU 503 in FIG. 5, receives an F1 setup request from an IAB node (701, 801), similar to the IAB node 570 in FIG. 5, requesting the setup of an F1 connection between the target IAB donor CU and the IAB node. The F1 setup request message sent by the IAB node may include identification information for identifying the IAB donor CU serving the MT of the IAB node (e.g., a non-F1 terminating donor CU when the MT of the IAB node has been migrated to a non-F1 terminating donor CU different from the target IAB donor CU, or a source F1 terminating donor CU when the MT of the IAB node has not been migrated). The F1 setup request message may also include identification information for identifying the source F1 terminating donor CU. The non-F1 terminating donor CU may be the donor CU 502 in FIG. 5 or the donor CU 709 in FIG. 7.

[0174] The message received in step 931 may be an F1 setup request message 814 as shown and described with respect to Figure 8. In response to receiving the request in step 931, the target F1 terminating donor CU 503, 707, 807 may send an acknowledgement to the IAB node 570, 701, 801. The acknowledgement may be a message 815 as shown and described with respect to Figure 8.

[0175] In another example, in step 931, a target F1 terminating donor CU (707, 807), similar to IAB donor CU 503 of FIG. 5, receives a notification from a source IAB donor CU (703, 803), similar to IAB donor CU 501 of FIG. 5, with a notification including identification information for identifying the IAB donor CU serving the MT of the IAB node (e.g., a non-F1 terminating donor CU when the MT of the IAB node has been migrated to a non-F1 terminating donor CU different from the target IAB donor CU, or a source F1 terminating donor CU when the MT of the IAB node has not been migrated). The notification may be a DU migration notification, such as a DU migration notification message 811 as shown and described with reference to FIG. 8. Alternatively (not shown in FIG. 9d), the notification may be a configuration update notification, such as a configuration update message 817 as shown and described with reference to FIG. 8.

[0176] In step 932, based on the identification information, the target F1 terminating donor CU 503, 707, 807 performs transport migration to migrate traffic related to or associated with the IAB node for routing via at least one path between the target IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT after the IAB node's DU is migrated to the target IAB topology. For example, the target F1 terminating donor CU 503, 707, 807 sends a traffic migration request (e.g., message 1313 in FIG. 13b) to the non-F1 donor CU to request traffic migration of traffic associated with the IAB node 570, 701, 801 that must be routed via one or more paths in the IAB topology managed by the non-F1 terminating donor CU 502, 709, as indicated in the message received in step 931.

[0177] 10 is a simplified diagram 1000 illustrating another example message flow for providing identification information identifying an IAB donor CU serving an MT at the IAB node (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU serving an MT) to a target IAB donor CU (e.g., an F1 terminating donor CU) of a DU transition of the IAB node as part of the DU transition process of the IAB node for use in managing or facilitating transport transition, in accordance with one or more embodiments of the present invention. The message flow shown and described below with respect to FIG. 10 pertains to the case where an MT at the IAB node has been migrated to another IAB donor CU, e.g., a non-F1 IAB donor CU that is different from the source IAB donor CU (source F1 donor CU) and the target IAB donor CU (target F1 donor CU).

[0178] This FIG. 10 shows a source F1 donor CU 1003 similar to donor CU 501,703, a target F1 donor CU 1007 similar to donor CU 503,707, and a non-F1 / RRC donor CU 1009 similar to donor CU 502,709.

[0179] The start of the flow corresponds to the end of the UE handover procedure 730 in Figure 7, when the source F1 donor CU 1003 of the IAB node can release traffic transition towards the non-F1 donor CU 1009 and the target F1 donor CU 1007 can request traffic transition towards the non-F1 donor CU 1007 after the DU transition of the IAB node, such as IAB node 570, 701. It is assumed that the MT of the IAB node was previously transitioned towards the IAB topology managed by the non-F1 donor CU 1009 and traffic related to the UE served by the IAB node was routed via the IAB topology managed by the non-F1 donor CU 1009.

[0180] Following handover of a UE served by an IAB node toward the target F1 donor CU 1007, the source F1 donor CU 1003 sends a transport transition release message 1011 to the non-F1 donor CU 1009 to request release of traffic associated with the handed over UE, and then to the IAB node with the migrated DU. For example, the transport transition release message 1011 may include a request to request release of the transport transition set up by the source IAB donor CU for traffic associated with the IAB node. The non-F1 donor CU 1009 responds with a transport transition response message 1012 to acknowledge the release operation.

[0181] According to one example, message 1011 may include a notification that the traffic transition release is due to a DU transition of the IAB node towards the target F1 donor CU 1007. Thus, message 1011 may include identifiers of the transitioned IAB nodes known by the source F1 donor CU 1003 and non-F1 donor CU 1009 with 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). The message 1011 may also include an identifier of the target F1 donor CU 1007 (i.e., a TNL / IP address and / or Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) and an identifier of the logical DU of the IAB node served by the target F1 donor CU 1007, the gNB-DU ID (specified in TS 38.423 Section 9.3.1.19).

[0182] Upon receiving the transport transition release message 1011, the non-F1 donor CU 1009 may release the transport transition (e.g., set up by the source IAB donor CU) by deleting the configurations of the IAB nodes involved in routing packets to / from the migrated IAB node in the IAB topology controlled by the non-F1 donor CU 1009. For example, the non-F1 donor CU 1009 may reconfigure the IAB nodes involved in routing traffic to and / or from the IAB nodes (e.g., IAB nodes in the routing path to the IAB node) by sending configuration update information to delete, at each IAB node, configuration information related to routing traffic to and / or from the IAB node. The non-F1 donor CU 1009 may send the updated configuration information (e.g., routing configuration table) to the IAB nodes in the routing path to the migrated IAB node, such that the configurations for routing packets to / from the migrated IAB node in the IAB topology at these IAB nodes in the routing path are deleted. 5 , MT 571 of IAB node 570 is served by IAB donor CU 502, DU 572 of IAB node 570 is migrated to IAB donor CU 503, and IAB node 570 is connected to IAB node 550 via backhaul link 505. After the DU migration, IAB donor CU 502, as a non-F1 donor CU, may release the transport migration by deleting configuration information related to routing traffic to / from IAB node 570 and by reconfiguring configuration information at IAB donor DU 506 and IAB nodes 540 and 550. Alternatively, non-F1 donor CU 1009 can interrupt the traffic migration only by maintaining the configuration of these IAB nodes; for example, IAB nodes in the routing path are not reconfigured to delete configuration information related to routing traffic to / from the migrated IAB node.In fact, since the traffic migration release request is due to the DU migration of the associated IAB node to the target F1 donor CU, this traffic migration request from the target F1 donor CU should be immediately received by the non-F1 donor CU 1009. Also, since the traffic to be migrated by the target F1 donor CU should be equivalent to the traffic migrated by the source F1 donor CU, the same configuration of the IAB nodes in the IAB topology controlled by the non-F1 donor CU 1009 should still be applicable.

[0183] The non-F1 donor CU 1009 then sends a transport migration response 1012 to the source F1 donor CU 1003 to acknowledge the received message 1011 .

[0184] Messages 1011 and 1012 may correspond to the procedure described in FIG. 13b, with message 1011 corresponding to message 1313 and message 1012 corresponding to message 1314.

[0185] The non-F1 donor CU 1009 further sends a notification to the target F1 donor CU 1007 indicating that the second IAB donor CU is ready to support transport migration, where the notification includes identification information for identifying the non-F1 donor CU 1009 and notifies the target F1 donor CU 1007 of the identity of the non-F1 donor CU 1009 so that traffic related to the IAB node can be migrated to a path (or at least one path) between the target F1 donor CU 1007 and the migrated IAB node 570 via the IAB topology managed by the non-F1 donor CU 1009. The notification may be included in the transport migration ready message 1013 sent to the target F1 donor CU 1007 to indicate its role (i.e., non-F1 donor CU for the IAB node) and to indicate its readiness to support traffic migration in that IAB topology. Thus, the message 1013 may include an identifier of the IAB-MT804 known by the non-F1 donor CU 1009 with the information element non-F1-Terminating IAB-donor UE XnAP IDD or RRC-Terminating IAB-donor UE XnAP ID defined in TS 38.423 Section 9.2.3.16, and an identifier of a logical DU having an F1 connection with the target F1 donor CU 1007, gNB-DU ID. The message 1013 may also, or alternatively, include a BAP address assigned by the non-F1 / RRC donor CU 1009. The transport transition ready message 1013 may include characteristics (e.g., throughput, quality of service) of the traffic that is ready to be transitioned by taking the same characteristics as that previously transitioned by the source F1 donor CU 1003.

[0186] When a UE served by an IAB node is handed over to a target F1 donor CU 1007, the target F1 donor CU 1007 sends a transport migration request message 1014 to request migration of traffic associated with the served UE to an IAB topology controlled by a non-F1 donor CU 1009. Upon receiving message 1014, the non-F1 donor CU 1009 can accept the migration and configure the IAB nodes in the IAB topology to route packets to / from the IAB node serving the UE according to the traffic characteristics (e.g., throughput, quality of service) provided by the target F1 donor CU 1007. The non-F1 donor CU 1009 then sends a transport migration response message 1015 to the target F1 donor CU 1007 to acknowledge the transport migration. If the non-F1 donor CU 1009 maintains the IAB node configuration upon receiving message 1011 and the characteristics of the traffic to be migrated are equal to the characteristics of the traffic previously migrated by the source F1 donor CU 1003, the non-F1 donor CU 1009 simply resumes transport migration and sends a response 1015 to the target F1 donor CU 1007.

[0187] Messages 1014 and 1015 may correspond to the procedure described in FIG. 13b, with message 1014 corresponding to message 1313 and message 1015 corresponding to message 1314.

[0188] FIG. 11 a is a flowchart of another exemplary method 1100 according to an embodiment of the present invention for managing DU transition of an IAB node, which involves notifying a target IAB donor CU (e.g., F1 terminating donor CU) at a source IAB donor CU (e.g., F1 terminating donor CU) of an IAB donor CU, non-F1 terminating donor CU, or RRC terminating donor CU serving an MT of the IAB node.

[0189] 5, the source IAB donor CU performing method 1100 may be an IAB donor CU 501 (e.g., an F1-terminating donor CU or an F1 donor CU of an IAB node 570 with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 that belongs to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The transition process may involve a transition from the IAB topology 5001 of a DU 572 of the IAB node 570 to an IAB topology 5003 (also referred to as a target IAB topology) managed by a target IAB donor CU, the IAB donor CU 503. 7 and 10, the IAB node may be IAB node 701, and the migration process may include migration of a DU of IAB node 701 from a source F1 donor CU 703, 1003 to a target F1 donor CU 707, 1007. The method 1100 as shown and described with respect to FIG. 11a may be performed by software and / or hardware elements. The source IAB donor CU may be implemented in the communication device 400 shown and described with respect to FIG. 4, with the method shown and described with respect to FIG. 11a being performed by an apparatus for the source IAB donor CU including one or more processing units, such as a central processing unit 411.

[0190] In step 1101, a source F1 terminating donor CU (703, 1003) similar to donor CU 501 in Figure 5 determines that a DU (701 in Figure 7) of an IAB node similar to IAB node 570 in Figure 5 should be migrated from source F1 donor CU 501, 703, 1003 to a target F1 donor CU (707, 1007) similar to donor CU 503 in Figure 5. For example, source F1 donor CU 501, 703, 1003 determines the DU migration of an IAB node similar to IAB node 570 toward a target F1 donor CU similar to donor CU 503, 707, 1007. For example, the source F1 donor CU 501, 703, 1003 may determine that the DU of the IAB node 570, 701 should be migrated in response to determining that the migration of the MT of the IAB node 570, 701 to a new parent IAB node (which may be a new IAB node or a new IAB donor DU) has completed. Other example triggers for determining that a DU should be migrated are described above. Details of how the source F1 donor CU 501, 703, 1003 determines the target F1 terminating donor CU 503, 707, 1007 are also described above.

[0191] In step 1102, the source F1 terminating donor CU 501, 703, 1003 performs or executes the DU transition of the IAB node via the procedure described at reference 720 in FIG.

[0192] In step 1103, the source F1 terminating donor CU 501, 703, 1003 sends a transport transition release for traffic associated with the IAB node 570, 701 to the non-F1 terminating donor CU of the IAB node, indicating the target F1 donor CU 503, 707, 1007 for DU transition of this IAB node (e.g., providing identification information for identifying the target F1 donor CU). The notification of the target F1 donor CU 503, 707, 1007 may be sent only if the non-F1 terminating donor CU is different from the target F1 donor CU 503, 707. The message sent in step 1103 may be message 1011 of FIG. 10.

[0193] 11b is a flowchart of an exemplary method 1110 according to an embodiment of the present invention for managing transport transition in a non-F1 / RRC terminating donor CU of an IAB node in the case of DU transition of the IAB node. For example, the method 1110 according to one or more embodiments of the present invention is performed in an IAB donor CU (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU, also referred to as a second IAB donor CU) to which an MT of the IAB node has been transitioned, and is for use in managing transport transition for traffic related to or associated with the IAB node. The transport transition is performed after a DU of the IAB node has been transitioned from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU. The non-F1 terminating donor CU is an IAB donor CU that is different from the target IAB donor CU and the source IAB donor CU.

[0194] 5, the IAB donor CU performing method 1110 may be an IAB donor CU 502 (e.g., a non-F1 / RRC terminating donor CU or a non-F1 / RRC donor CU of an IAB node 570 with which the IAB node 570 maintains an RRC connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The transition process may involve a transition from the IAB topology 5001 of a DU 572 of the IAB node 570 to an IAB topology 5003 (also referred to as a target IAB topology) managed by a target IAB donor CU, the IAB donor CU 503. 7 and 10, the IAB node may be IAB node 701, and the migration process may include migration of a DU of IAB node 701 from a source F1 donor CU 703, 1003 to a target F1 donor CU 707, 1007. The method 1110 as shown in and described with respect to FIG. 11b may be performed by software and / or hardware elements. The source IAB donor CU may be implemented in the communication device 400 shown and described with respect to FIG. 4, with the method shown and described with respect to FIG. 11b being performed by an apparatus for a non-F1 IAB donor CU including one or more processing units, such as a central processing unit 411.

[0195] In step 1111, a non-F1 terminating donor CU (709, 1009) similar to donor CU 502 of FIG. 5 receives a transport transition release (e.g., a transport transition release message 1011) from a source F1 terminating donor CU (703, 1003) similar to donor CU 501 of FIG. 5 in an IAB node (701 of FIG. 7) similar to IAB node 570 of FIG. 5 to request release of the transport transition set up by the source F1 donor CU 501, 703, 1003 for traffic related to or associated with the IAB node. The transport transition release may include identification information to identify or indicate a target F1 terminating donor CU for the DU transition of the IAB node. The target F1 terminating donor CU may be donor CU 503 of FIG. 5, or donor CU 707 of FIG. 7, or donor CU 1007 of FIG. 10.

[0196] In step 1112, the non-F1 terminating donor CU 502, 709, 1009 releases (or suspends) the previously set up transport transition in response to the request of the source F1 terminating donor CU 501, 703, 1003. As described above with reference to Figure 10, when the non-F1 terminating donor CU 502, 709, 1009 releases the transport transition, the terminating donor CU 502, 709, 1009 reconfigures the IAB nodes involved in routing traffic to and / or from the IAB nodes by deleting, at each IAB node, configuration information related to the routing of traffic to and / or from the IAB nodes. When the non-F1 terminating donor CU 502, 709, 1009 suspends the transport transition, the configuration at the IAB nodes involved in routing traffic to and / or from the IAB nodes is retained.

[0197] In step 1113 (e.g., after receiving the transport migration release message 1011), the non-F1 terminating donor CU 502, 709, 1009 sends a notification to the target F1 donor CU 503, 707, 1007 indicating that the second IAB donor CU is ready for transport migration of traffic associated with the IAB node 570, where the notification includes identification information for identifying the non-F1 donor CU 1009. The notification may be sent in a transport migration ready message 1013 sent to the target F1 donor CU 1007, as described above.

[0198] In step 1114, the non-F1 terminating donor CU 501, 703, 1003 receives a transport transition request from the target F1 donor CU 503, 707, 1007 for traffic associated with the IAB node 570. The transport transition request may be sent in a transport transition request message 1014 described above.

[0199] In step 1115, the non-F1 terminating donor CU 501, 703, 1003 activates (or resumes) the transport transition according to the request from the target F1 terminating donor CU 503, 707, 1007, so that traffic related to the IAB node is routed via at least one path between the target F1 terminating donor CU 503, 707, 1007 and the IAB node through the IAB topology managed by the non-F1 terminating donor CU 501, 703, 1003 serving the MT.

[0200] FIG. 11c is a flowchart of another exemplary method 1120 for managing transport transition at a target F1 terminating donor CU of an IAB node in case of a DU transition of the IAB node, according to an embodiment of the present invention.

[0201] For example, with reference to the IAB communication system 500 shown and described with respect to FIG. 5, the target IAB donor CU performing the method 1120 may be the IAB donor CU 503 that controls the IAB topology 5003 (also referred to as the target IAB topology). The IAB node may be a mobile IAB node 570 that belongs to the IAB topology 5001 (also referred to as the source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migration of a DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003. With reference to FIGS. 7 and 10, the IAB node may be the IAB node 701, and the migration process may include migration of a DU of the IAB node 701 from the source F1 donor CU 703, 1003 to the target F1 donor CU 707, 1007. The method 930 as shown and described with respect to FIG. 11c may be performed by software and / or hardware elements. The target IAB donor CU may be implemented in a communication device 400 as shown and described with respect to FIG. 4 using a method as shown and described with respect to FIG. 11c, executed by an apparatus for the target IAB donor CU including one or more processing units, such as a central processing unit 411.

[0202] In step 1121, a target F1 terminating donor CU (707, 1007), similar to IAB donor CU 503 in FIG. 5, receives a message from a non-F1 terminating donor CU (709, 1009), similar to donor CU 502 in FIG. 5, of an IAB node (701 in FIG. 7), similar to IAB node 570 in FIG. 5, indicating that the non-F1 terminating donor CU 502, 709, 1009 is ready for transport migration of traffic associated with IAB node 570. For example, the target F1 terminating donor CU 503, 707, 1007 receives a notification from the non-F1 terminating donor CU 502, 709, 1009 indicating that the non-F1 terminating donor CU 502, 709, 1009 is ready for transport transition of traffic associated with the IAB node 570, where the notification includes identification information for identifying the non-F1 donor CU 1009. The notification may be sent in a transport transition ready message 1013 sent to the target F1 donor CU 1007, as discussed above.

[0203] In step 1122, after the DU transition of the IAB node 570, the target F1 terminating donor CU 503, 707, 1007 performs transport transition of traffic related to the IAB node 570 toward the IAB topology controlled by the non-F1 terminating donor CU 502, 709, 1009. For example, after the DU transition of the IAB node 570, based on the identification information of the non-F1 terminating donor CU 502, 709, 1009, the target F1 terminating donor CU 503, 707, 1007 performs transport transition to transition traffic related to or associated with the IAB node for routing via at least one path between the target F1 terminating donor CU 503, 707, 1007 and the IAB node through the IAB topology managed by the non-F1 terminating donor CU 502, 709, 1009.

[0204] FIG. 12a is a schematic and simplified diagram 1200 illustrating an exemplary message flow of a procedure for performing activation of a logical DU, according to an example.

[0205] This diagram shows: - RAN node DU1 201, which is a DU of an IAB node similar to IAB-DU 572 of IAB node 570 of FIG. 5 (and IAB-DU1 805 of IAB node 801 of FIG. 8); RAN node CU1202, which may be an IAB donor CU similar to IAB donor CU501 in FIG. 5 (and source F1 donor CU803 in FIG. 8).

[0206] Message CONFIGURATION REQUEST 1203 is sent by RAN node CU 1202 to RAN node DU 1201 to request activation of a new cell controlled by RAN node DU 1201, to request activation of a logical DU, or to request deactivation of a cell in RAN node DU 1201. In the case of logical DU activation, message 1203 may include the TNL address (i.e., IP address) of the RAN node CU (e.g., target F1 donor CU 807 in FIG. 8) that will connect to the logical DU when activated. For example, CONFIGURATION REQUEST 1203 may be sent by a source IAB donor CU to an IAB node (e.g., the first logical DU entity 805 having an F1 connection with the source IAB donor CU) to request establishment of an F1 connection between the target IAB donor CU and the IAB node. The message 1203 may also include an information element (IE) requesting the RAN node DU 1201 to transmit the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of a RAN node CU (e.g., a non-F1 IAB donor CU or an RRC IAB donor CU) that, upon activation, will terminate the RRC connection of the RAN node incorporating the RAN node DU 1201 to the RAN node CU (e.g., target F1 donor CU 807 in FIG. 8) that connects to the logical DU. This IE may be limited to one bit: one value (i.e., "0" or "1") of this one-bit IE means that no specific action is requested, and another value (i.e., "1" or "0") means that the address / identifier of the non-F1 donor CU is to be transmitted. This IE may be extended to include the address / identifier of the RAN node CU that terminates the RRC connection.The message 1203 may include the information element non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID defined in TS 38.423 section 9.2.3.16 and the identifier of the Mobile Termination (MT) of the RAN node incorporating the RAN node DU 1201, known by the RAN node CU terminating the RRC connection.

[0207] The RAN node DU 1201 may acknowledge the request with a CONFIGURATION RESPONSE 1204 message sent to the RAN node CU 1202.

[0208] According to one example, the flow of Figure 12a corresponds to the procedure gNB-CU Configuration Update procedure described in TS 38.473 V17.0.0 section 8.2.5, message 1203 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, while message 1204 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11.

[0209] The message GNB-CU CONFIGURATION UPDATE includes an information element (IE) Cells to be Activated List that indicates a list of new cells to be activated in the RAN node DU 1201. For example, referring to Figure 8, the GNB-CU CONFIGURATION UPDATE includes information for activating the new cell indicated in the IE Cells to be Activated List, which may be served by the first logical DU entity 805 in the IAB node 801. The cell to be activated refers to a cell controlled by the RAN node DU 1201 that receives the request. The associated PCI and NCGI values ​​to be used by the RAN node DU 1201 may also be provided.

[0210] The message GNB-CU CONFIGURATION UPDATE may also include an information element (IE) Cells to be Deactivated List to indicate the list cells to be deactivated. The cells to be deactivated refer to cells controlled by the RAN node DU 1201 that receives the request. For example, referring to Figure 8, the GNB-CU CONFIGURATION UPDATE may include information to deactivate cells indicated in the IE Cells to Deactivated List, which are currently served by the first logical DU entity 805 in the IAB node 801.

[0211] According to one example, a new IE Second DU Activation may be added to the message 1203 in the form of a Boolean value (e.g., a one-bit IE) to request activation of the second logical DU. One value of the one-bit IE (i.e., “0” or “1”) means that no specific action related to the second logical DU is requested, while another value (i.e., “1” or “0”) means that activation of the second logical DU is requested. This IE may be completed by a new IE indicating the number of cells to be activated in the second logical DU. In the absence of this IE, the number of cells to be activated corresponds to the number of cells currently activated in the RAN node DU 1201. The presence of this IE may indicate that a BAP address identifying a mobile termination (MT) of the RAN node incorporating the RAN node DU 1201 should be inserted in the request for F1 connection.

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

[0213] Another IE may be added to request transmission of the address and / or identifier of the RAN node CU terminating the RRC connection of the RAN node incorporating the RAN node DU 1201 (e.g., the address and / or identifier of the IAB donor CU serving the MT of the IAB node). This IE may be an address (e.g., a non-F1 TNL address IE or an RRC TNL address IE) or an identifier (e.g., a non-F1 Global NG-RAN Node ID or an RRC Global NG-RAN Node ID), and its presence indicates that it should be included in the request for an F1 connection.

[0214] Another IE may be added to identify the mobile termination (MT) of the RAN node incorporating the RAN node DU 1201 (e.g., non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID), the presence of which indicates that it should be included in the request for F1 connection. The presence of this IE may indicate that a BAP address identifying the mobile termination (MT) of the RAN node incorporating the RAN node DU 1201 should be inserted in the request for F1 connection.

[0215] The message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE may include an information element (IE) for identifying the activated logical DU (e.g., second DU gNB-DU ID).

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

[0217] FIG. 12b is a simplified schematic diagram 1210 illustrating an example message flow of a procedure for setting up a logical DU to establish an F1 connection with a target IAB donor CU, according to an example.

[0218] This diagram shows: RAN node DU 1 211, which may be a DU of an IAB node DU similar to IAB-DU 572 of IAB node 570 of FIG. 5 (and IAB-DU2 806 of IAB node 801 of FIG. 8); RAN node CU1212, which may be an IAB donor CU similar to IAB donor CU503 in FIG. 5 (and target F1 donor CU807 in FIG. 8).

[0219] The message SETUP REQUEST 1213 is sent by the RAN node DU 1211 to the RAN node CU 1212 to request F1 setup of a logical DU. For example, the SETUP REQUEST 1213 may be sent by an IAB node (e.g., by a second logical DU entity 806 activated in the IAB node 801) to the target IAB donor CU 807 to request setup of an F1 connection between the target IAB donor CU and the IAB node (e.g., the second logical DU entity 806 of the IAB node 801). The SETUP REQUEST message 1213 may be sent after a request for activation, as described with reference to FIG. 12a. This SETUP REQUEST message 1213 may include the number of cells to be activated along with the activation of the logical DU. This SETUP REQUEST message 1213 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU that terminates the F1 connection of the RAN node DU 1211 (e.g., source IAB donor CU 803). This message may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU that terminates the non-F1 (i.e., RRC) connection of the RAN node DU 1211 if the MT (e.g., mMT 571 of IAB node 570 or the corresponding IAB-MT 804 of IAB node 801) has been migrated to the RAN node CU (which is now a non-F1 donor CU).

[0220] The message 1213 may also include at least one of the following: - the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the source RAN node CU that requested the F1 setup, - the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID) of the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1211 (e.g., the address and / or identifier of the IAB donor CU serving the MT of the IAB node); - an identifier of the Mobile Termination (MT) of the RAN node incorporating the RAN node DU 1211, known by the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1211 (e.g., non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID); - the BAP address of the MT of the RAN node incorporating the RAN node DU 1211 assigned by the RAN node CU terminating the RRC connection of the RAN node incorporating the RAN node DU 1211; - Identifier of the RAN node DU 1211 gNB-DU ID.

[0221] The RAN node CU 1212 responds with a message SETUP RESPONSE 1214 sent to the RAN node DU 1211. It may contain a list of cells to activate with the logical DU, along with the associated PCI and NCGI values ​​to be used.

[0222] According to one example, the flow of Figure 12b corresponds to the procedure F1 setup (F1 setup) described in TS 38.473 V17.2.0 section 8.2.3, message 1213 corresponds to the message F1 SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4, while message 1214 corresponds to the message F1 SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5. The message F1 SETUP RESPONSE contains an information element (IE) Cells to be Activated List indicating a list of new cells to be activated. The activated cells refer to cells controlled by the RAN node DU 1211 that receives the response.

[0223] FIG. 12c is a schematic and simplified diagram 1220 illustrating an example message flow of a procedure for deleting a logical DU.

[0224] This diagram shows: RAN node DU1 221, which may be a DU of an IAB node DU similar to IAB-DU 572 of IAB node 570 of FIG. 5 (and IAB-DU1 805 of IAB node 801 of FIG. 8); RAN node CU1222, which may be an IAB donor CU similar to IAB donor CU501 in FIG. 5 (and source F1 donor CU803 in FIG. 8).

[0225] The message REMOVAL REQUEST 1223 is sent by the RAN node CU 1222 to the RAN node DU 1221 to request the removal (which is equivalent to deactivation) of the logical DU.

[0226] The RAN node DU 1221 responds with a message REMOVAL RESPONSE 1214 that is sent to the RAN node CU 1222.

[0227] According to one example, the flow of FIG. 12c corresponds to the procedure F1 removal described in TS 38.473 V17.2.0 section 8.2.8, message 1223 corresponds to the message F1 REMOVAL REQUEST described in TS 38.473 V17.2.0 section 9.2.1.16, while message 1224 corresponds to the message F1 REMOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7.

[0228] FIG. 12d is a simplified schematic diagram 1230 illustrating an example message flow of a procedure used by a logical DU to notify an IAB donor CU about a change in configuration, according to one example.

[0229] This diagram shows: a RAN node DU 1231, which may be a DU of an IAB node DU similar to the IAB-DU 572 of the IAB node 570 of FIG. 5 (and the IAB-DU2 806 of the IAB node 801 of FIG. 8); RAN node CU1232, which may be an IAB donor CU similar to IAB donor CU503 in FIG. 5 (and target F1 donor CU807 in FIG. 8).

[0230] The message CONFIGURATION UPDATE 1233 is sent by the RAN node DU 1231 to the RAN node CU 1232 to indicate a configuration change for the RAN node incorporating the RAN node DU 1231. The CONFIGURATION UPDATE message 1233 may be sent by the RAN node DU 1231 to indicate to the RAN node CU 1232 the identifier of the RAN node CU that serves the MT of the RAN node incorporating the RAN node DU 1231. For example, the message 1233 is sent by the second logical DU entity 806 activated in the IAB node 801 to the target IAB donor CU 807 to indicate the IAB donor CU that serves the MT 804 of the IAB node 801. This CONFIGURATION UPDATE message 1233 may include the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1211 (e.g., the address and / or identifier of the IAB donor CU serving the MT of the IAB node). It may also include at least one of the following: - an identifier of the Mobile Termination (MT) of the RAN node incorporating the RAN node DU 1231, known by the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1231 (e.g. non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID); - the BAP address of the MT of the RAN node incorporating the RAN node DU 1231, assigned by the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1231; - Identifier of the RAN node DU 1231 gNB-DU ID.

[0231] The RAN node CU 1232 replies or responds with a message CONFIGURTION ACKNOWLEDGE 1234 sent to the RAN node DU 1231 .

[0232] The identifier for the mobile termination (MT) of the RAN node may be provided by the RAN node CU that terminates the RRC connection of the RAN node incorporating the RAN node DU 1231.

[0233] According to one example, the flow of Figure 12d corresponds to the procedure gNB-DU configuration update described in TS 38.473 V17.2.0 section 8.2.4, modified to include the above-mentioned information elements. Message 1233 corresponds to the message GNB-DU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.7, and message 1234 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.8.

[0234] FIG. 13a is a simplified schematic diagram 1300 illustrating an example message flow of a procedure used by a RAN node CU to report configuration information to another RAN node CU, according to one example.

[0235] This diagram shows two RAN nodes, RAN node CUa 1301 and RAN node CUb 1302, which may be two IAB donor CUs similar to two of IAB donor CUs 501, 502, and 503 of Figure 5. For the example shown in Figure 8, RAN node CUa 1301 may be the target F1 donor CU 807 and RAN node CUb 1302 may be the source F1 donor CU 803, depending on the purpose of the message.

[0236] The message CONFIGURATION UPDATE 1303 is sent by RAN node CUa 1301 to RAN node CUb 1302 to inform it about the activation of a new cell in a logical DU of the RAN node DU similar to IAB-DU2 806 of IAB node 801.

[0237] For example, the source F1 donor CU 803 receives a CONFIGURATION UPDATE message 1303 from the target F1 donor CU 807, and the CONFIGURATION UPDATE message 1303 includes identification information (e.g., PCI, NRGI) identifying one or more new cells activated in the second logical DU entity (IAB-DU2 806) of the DU of the IAB node 801.

[0238] Message CONFIGURATION UPDATE 1303 may also be used from RAN node CUa 1301 to RAN node CUb 1302 to inform RAN node CUb 1302 about the TNL address (i.e., IP address) and / or identifier (i.e., Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the RRC connection of the RAN node incorporating the RAN node DU to be migrated towards RAN node CUb 1302 (e.g., address and / or identifier of the IAB donor CU serving the MT of the IAB node). In this case, RAN node CUa 1301 is the source F1 donor CU 803 and RAN node CUb 1302 is the target F1 donor CU 807.

[0239] The message 1303 may also include at least one of the following: - an identifier of the migrated RAN node known by the RAN node CUa 1301, accompanied by the information element F1-Terminating IAB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node and / or the information element gNB-DU ID identifying the logical DU of the migrated RAN node having an F1 connection with the RAN node CUa 1301; - the identifier of the MT of the migrated RAN node known by the RAN node CU terminating the RRC connection with the migrated RAN node via the information element non-F1-Terminating IAB-donor UE XnAP ID or RRC-Terminating IAB-donor UE XnAP ID, - an identifier of the migrated RAN node known by the RAN node CUb1302, accompanied by the information element target F1-Terminating IAB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node and / or the identifier gNB-DU ID of the logical DU of the migrated RAN node having an F1 connection with the RAN node CUb1302; - BAP address of the MT of the migrated RAN node assigned by the RAN node CU terminating the RRC connection of the migrated RAN node.

[0240] RAN node CUb 1302 responds with message CONFIGURATION ACKNOWLEDGE 1304 to RAN node CUa 1301 sent to acknowledge receipt of message 1303.

[0241] According to one example, Figure 13a corresponds to the procedure NG-RAN node configuration update described in TS 38.423 V17.2.0 section 8.4.2, message 1303 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE modified with the above-listed IEs described in TS 38.423 V17.2.0 section 9.1.3.4, and message 1304 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.5.

[0242] FIG. 13b is a simplified schematic diagram 1310 illustrating an example message flow of a procedure used by a RAN node CU to manage transport transitions (e.g., setup, modification, or release of F1 traffic such as user / control traffic) in coordination with another RAN node CU, according to one example.

[0243] This figure shows two RAN nodes, RAN node CUa 1311 and RAN node CUb 1312, which may be two IAB donor CUs similar to two of IAB donor CUs 501, 502, and 503 of FIG.

[0244] Message MIGRATION REQUEST 1313 is sent by RAN node CUa 1311 to RAN node CUb 1312 to request traffic migration setup, or modification, or release in the IAB topology controlled by RAN node CUb 1312. For example, referring to FIG. 8, if a DU is migrated to target F1 donor CU 807 and MT 804 of IAB node 801 is migrated to a non-F1 / RRC donor CU (not shown in FIG. 8), the source F1 donor CU 803 may send MIGRATION REQUEST 1313 to the non-F1 donor CU to request release of traffic (e.g., F1 traffic) migrated to the topology of the non-F1 donor CU (i.e., F1 traffic is now routed from target F1 donor CU 807 via the IAB topology managed by the non-F1 donor CU). Alternatively, if the DU is migrated to the target F1 donor CU 807 and the MT 804 of the IAB node 801 is migrated to a non-F1 donor CU, the target F1 donor CU 807 may send a MIGRATION REQUEST 1313 to the non-F1 donor CU to request migration of traffic (e.g., F1 traffic) to the topology of the non-F1 donor CU (i.e., F1 traffic is now routed from the target F1 donor CU 807 via the IAB topology managed by the non-F1 donor CU).

[0245] In another example, message MIGRATION REQUEST 1313 is sent by RAN node CUa 1311 to RAN node CUb 1312 to notify the DU migration of the IAB node. When RAN node CUb 1312 responds with message MIGRATION RESPONSE 1314, RAN node CUb 1312 may include an identifier assigned by RAN node CUb 1312 for the migrated IAB node, for example, the information element target F1-Terminating IAB-donor UE XnAP ID, which identifies the mobile termination (MT) of the migrated IAB node.

[0246] The message 1313 may include at least one of the following: - notification of traffic transition release due to DU transition to target F1 donor CU 807 of IAB node 801; - the identifiers of the migrated IAB node known by the source F1 donor CU 803 and the non-F1 donor CU, together with 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 / or the BAP address assigned by the non-F1 donor CU for the migrated IAB node, - Identifier of the target F1 donor CU807 (e.g., TNL / IP address and / or Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3), - Identifier gNB-DU ID of the logical DU of the IAB node 801 served by the target F1 donor CU 807 (as specified in TS 38.473 section 9.3.1.19).

[0247] RAN node CUb 1312 responds with a message MIGRATION RESPONSE 1314 sent to RAN node CUa 1311 to accept or reject the request.

[0248] Depending on the circumstances, Figure 13b may correspond to the IAB transport migration management procedure specified in TS 38.423 V17.2.0, section 8.5.2. Message 1313 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS 38.423 V17.2.0, section 9.1.4.2, and message 1314 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in TS 38.423 V17.2.0, section 9.1.4.3. If the TRANSPORT MIGRATION MANAGEMENT procedure is the one specified in TS 38.423 V17.2.0, section 8.5.2 (which may be referred to as the legacy procedure), the target F1 donor CU 807 should know the UE XnAP ID assigned by the non-F1 donor CU. If the F1 SETUP REQUEST message from the migrated IAB node provides only a BAP address, then both the BAP address and the UE XnAP ID are provided to the target F1 donor CU (via the procedure described in Figure 13a) so that the target F1 donor CU can associate the UE XnAP ID with the BAP address. If the TRANSPORT MIGRATION MANAGEMENT procedure is modified to not provide the UE XnAP ID but allow the BAP address to be used instead, then only the BAP address can be provided to the target F1 donor CU (via the procedure described with reference to Figure 13a).

[0249] 13b may also correspond to the IAB transport migration modification procedure specified in TS 38.423 V17.2.0 section 8.5.3. Message 1313 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.4, and message 1314 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.5.

[0250] In other words, in summary, it should be noted that a mobile IAB node can be partially migrated as any other IAB node according to Release 17. Also, this mobile IAB-MT (mIAB-MT) handover is driven by radio conditions and should not be delayed in order to maintain backhaul connectivity and avoid service interruptions at the served UEs.

[0251] It can therefore be observed that the mIAB-MT handover should not be delayed in order to maintain the backhaul connection and avoid service interruption at the served UE.

[0252] Based on this first observation, it is possible that a mIAB-MT handover is triggered and executed while a co-located mobile IAB-DU (mIAB-DU) transition is in progress. Thus, even if the target donor CU for the mIAB-DU transition is restricted to the donor CU of the mIAB-MT, in some circumstances, the F1-terminating donor CU after the mIAB-DU transition may ultimately differ from the non-F1-terminating donor CU after the handover of the co-located mIAB-MT.

[0253] Therefore, considering that mIAB-MT handover should not be delayed, it may lead to a situation where the mIAB-MT and its co-located mIAB-DU may be handed over / migrated to a different donor CU.

[0254] Furthermore, the criteria for DU transition and MT handover are different: MT handover is driven by radio conditions, while the DU transition decision may, for example, be based on available connectivity between donor CUs and / or for load balancing purposes.

[0255] And it should be noted that the criteria for selecting a target donor CU for a mobile IAB node depends on the transition type, i.e., MT handover or DU transition.

[0256] Therefore, according to the above observations, for the purpose of flexible and smooth IAB network management, it should be supported that the mIAB-MT and its co-located mIAB-DU can be handed over / migrated to different donor CUs.

[0257] Also, if the target F1 donor CU is different from the non-F1 donor CU, the target F1 donor CU should be informed about the current non-F1 donor CU serving the co-located mIAB-MT of the mobile IAB node, which allows the target F1 donor CU to set up an IAB transport transition towards the topology of the non-F1 donor CU.

[0258] And it is proposed that the target F1 donor CU for the migration of the mobile IAB-DU should be informed about the current non-F1 donor CU serving the co-located mobile IAB-MT.

[0259] In the case of a simultaneous MT handover and DU transition for a mobile IAB node, it is the DU transition that may suffer delays or failures due to modifications to the backhaul path for communicating with the mobile IAB node.

[0260] To be more precise about the potential problem, it is possible that a mobile IAB node successfully performs an F1 setup procedure with a target F1 donor CU for DU migration purposes, and this target F1 donor CU is different from the non-F1 donor CU for the mobile IAB node. On the other hand, if an MT migration of the mobile IAB node occurs towards a target non-F1 donor CU (which is still different from the target F1 donor CU), the target F1 donor CU may not be aware of this new non-F1 donor CU for performing a transport migration management (TMM) procedure.

[0261] If the CU of the target logical mIAB-DU is different from the CU of the mIAB-MT, the CU of the target logical mIAB-DU needs to be informed about the CU ID and mIAB-MT ID of the mIAB-MT so that it can initiate an Xn TMM procedure towards the CU of the mIAB-MT.

[0262] However, note that this statement may not be precise enough to prevent deadlock situations in case of simultaneous MT and DU migrations. In fact, it does not say when the target F1 donor CU (i.e., the CU of the target logical mIAB-DU) is notified about the non-F1 donor CU (i.e., the CU ID of the mIAB-MT). If the target F1 donor CU is notified before the MT migration, the target F1 donor CU will trigger a TMM procedure towards the donor CU that may no longer be a non-F1 donor CU.

[0263] Therefore, the above statement can be completed by the following: if the CU of the mIAB-MT changes during DU migration, the CU of the target logical mIAB-DU needs to be informed about the CU ID and mIAB-MT ID of the target mIAB-MT before it can start the TMM procedure towards the CU of the target mIAB-MT.

[0264] From the above examples, it is clear that some adaptations of the MT and DU transition procedures may be required to avoid deadlock situations and limit the impact of simultaneous MT and DU transitions on some delays to complete the procedures.

[0265] Moving forward, you have three options: - Option 1: Consider independent procedures as a working premise, define the procedures accordingly, and (if necessary) in a second step refine the procedures to support simultaneous DU and MT transitions; - Option 2: Consider simultaneous DU and MT migration as a working assumption and then define procedures accordingly; - Option 3: Do not support simultaneous DU and MT transitions, define the procedures independently, and add in a second step the mechanisms necessary to avoid this simultaneous occurrence.

[0266] It can be observed that the mobile IAB-MT transition is driven by radio conditions and should not be delayed in order to maintain backhaul connectivity and avoid service interruptions to the served UE, which means that a mobile IAB-MT handover can be triggered and executed while a co-located mobile IAB-DU transition is in progress.

[0267] Furthermore, Option 2 appears to be more efficient than Option 1 when considering support for simultaneous DU and MT migrations.

[0268] Therefore, if simultaneous DU and MT migration needs to be supported, the MT and DU migration procedures are defined taking into account the possibility of simultaneous DU and MT migration (Option 2).

[0269] Once the target F1 donor CU is provided with the identification information, one issue to be addressed is which node informs the target F1 donor CU for the mobile IAB node's DU transition of the identification information associated with the non-F1 donor CU (i.e., the mIAB-MT's CU ID and mIAB-MT ID).

[0270] There are three options for the provider node: - Option 1: Source F1 Donor CU In this case, the source F1 donor CU may relay to the target F1 donor CU the identification information previously received from the source non-F1 donor CU in the MT transition of the mobile IAB node. - Option 2: Non-F1 donor CU In this case, the source F1 donor CU should provide the non-F1 donor CU with identifying information related to the target F1 donor CU. - Option 3: Migrating IAB nodes In this case, the non-F1 donor CU should provide its identification information to the IAB node.

[0271] Therefore, the following three options are considered to provide the identification information related to the non-F1 donor CU (i.e., the CU ID and mIAB-MT ID of the mIAB-MT) to the target F1 donor CU for the DU transition of the mobile IAB node: - Option 1: Source F1 donor CU, - Option 2: Source non-F1 donor CU, - Option 3: Migrate IAB nodes.

[0272] Option 2 may be a good option as it follows the following statements: The source donor CU for the mIAB-MT HO will provide at least the following to the donor CU serving the mIAB-DU: - gNB ID of the target donor CU for mIAB-MT - ID of mIAB-MT.

[0273] As mentioned above, in the case of a simultaneous MT handover and DU transition for a mobile IAB node, it is the DU transition that may suffer delays or failures due to modifications to the backhaul path for communicating with the mobile IAB node.

[0274] To be more precise about the potential problem, it is possible that a mobile IAB node successfully performs an F1 setup procedure with a target F1 donor CU for DU migration purposes, and this target F1 donor CU is different from the non-F1 donor CU for the mobile IAB node. On the other hand, if an MT migration of the mobile IAB node occurs towards a target non-F1 donor CU (which is still different from the target F1 donor CU), the target F1 donor CU may not be aware of this new non-F1 donor CU for performing a transport migration management (TMM) procedure.

[0275] Note that if the CU of the target logical mIAB-DU is different from the CU of the mIAB-MT, the CU of the target logical mIAB-DU needs to be informed about the CU ID of the mIAB-MT and the mIAB-MT ID so that it can initiate the Xn TMM procedure towards the CU of the mIAB-MT.

[0276] However, this statement may not be precise enough to prevent deadlock situations in case of simultaneous MT and DU migrations. In fact, it does not say when the target F1 donor CU (i.e., the CU of the target logical mIAB-DU) is notified about the non-F1 donor CU (i.e., the CU ID of the mIAB-MT). If the target F1 donor CU is notified before the MT migration, the target F1 donor CU will trigger a TMM procedure towards the donor CU that may no longer be a non-F1 donor CU.

[0277] Therefore, the above statement can be completed by the following: if the CU of the mIAB-MT changes during DU migration, the CU of the target logical mIAB-DU needs to be informed about the CU ID and mIAB-MT ID of the target mIAB-MT before it can start the TMM procedure towards the CU of the target mIAB-MT.

[0278] From the above examples, it is clear that some adaptations of the MT and DU transition procedures may be required to avoid deadlock situations and limit the impact of simultaneous MT and DU transitions on some delays to complete the procedures.

[0279] Assuming that the mIAB-MT handover (or transition) and the mIAB-DU transition are separate procedures, it is not excluded that both transitions may overlap in time. Moving forward, there are three options: - Option 1: Consider simultaneous DU and MT migrations as a working assumption, in a first step define procedures without considering potential simultaneous occurrences, and then in a second step refine procedures to support simultaneous DU and MT migrations (if necessary); - Option 2: Consider simultaneous DU and MT migration as a working assumption and define procedures accordingly; - Option 3: Do not support simultaneous DU and MT transitions, define procedures, and in a second step add the necessary mechanisms to avoid this simultaneous occurrence.

[0280] It can be observed that the mobile IAB-MT transition is driven by radio conditions and should not be delayed in order to maintain backhaul connectivity and avoid service interruptions to the served UE, which means that a mobile IAB-MT handover can be triggered and executed while a co-located mobile IAB-DU transition is in progress.

[0281] Furthermore, Option 2 is likely to be more efficient than Option 1 when considering support for simultaneous DU and MT transitions.

[0282] Therefore, if simultaneous DU and MT transitions need to be supported, the MT and DU transition procedures are defined taking into account the possibility of simultaneous DU and MT transitions (Option 2).

[0283] Once the target F1 donor CU is provided with identification information, one issue to address is which node informs the target F1 donor CU for the mobile IAB node's DU transition of the identification information associated with the non-F1 donor CU (i.e., the mIAB-MT's CU ID and mIAB-MT ID).

[0284] There are two options to provide the target CU of the mIAB-DU with the gNB-ID of the CU of the mIAB-MT and the XnAP UE ID of the mIAB-MT for this CU: Option A: XnAP signaling from the source CU of the mIAB-DU Option B: F1AP signaling from target logical mIAB-DU.

[0285] Note that both options can support simultaneous MT and DU transitions depending on how it is implemented.

[0286] In Option A, the source F1 donor CU may relay to the target F1 donor CU the identity information previously received from the source non-F1 donor CU in the MT transition of the mobile IAB node. In this case, the XnAP procedure NG-RAN node Configuration Update procedure may be appropriate.

[0287] In Option B, providing identification information via the F1 setup procedure may not be sufficient, and if the non-F1 donor CU changes after the F1 setup procedure is completed, the target F1 donor CU will not know the new non-F1 donor CU to perform the TMM procedure. Therefore, the F1AP procedure gNB-DU Configuration Update may be appropriate, as it can be triggered at any time, for example, when the non-F1 donor CU changes.

[0288] In the case of down-selection (i.e., selection of one option between option A and option B), option A appears to be simpler than option B because it does not involve the IAB node as an intermediate node in the transition.

[0289] Therefore, it may be proposed that XnAP signaling from the source CU of the mIAB-DU be used to provide the target CU of the mIAB-DU with the gNB-ID of the CU of the mIAB-MT and the XnAP UE ID of the mIAB-MT in this CU.

[0290] Considering that the identifier of the MT of a mobile IAB node (mIAB-MT) may be a BAP address assigned by the IAB donor CU controlling the mIAB-MT (and sent to the mIAB-MT via an RRC protocol message when the mIAB-MT connects to this IAB donor CU), and that the IAB donor CU controlling the mIAB-MT may be called a non-F1 terminating donor CU or an RRC terminating donor CU, a further question may arise: which ID assigned by the MT's CU for the IAB MT should be used for the TMM procedure, and how this ID can be mapped to the corresponding IAB node.

[0291] In practice, this ID assigned by the RRC terminating donor CU (i.e., the CU of the mIAB-MT) can be a BAP address or a UE XnAP ID.

[0292] The BAP address selected by the RRC terminating donor CU can be provided by the target logical mobile IAB-DU to the target F1 terminating donor CU (i.e., the CU of the mIAB-DU) in a legacy Rel-16 / 17 F1 Setup Request message. If only the BAP address is provided (and not the UE XnAP ID assigned in the RRC terminating donor CU), the TMM request message must be modified to allow the use of the BAP address IE instead of the non-F1 terminating IAB-donor UE XnAP ID IE. Furthermore, the behavior of the RRC terminating donor CU receiving this TMM request message must be adapted accordingly. Indeed, according to the Release 17 standard (TS 38.423), the presence of the UE XnAP ID assigned by the F1 terminating donor CU and the RRC terminating donor CU is mandatory for the TMM procedure.

[0293] To avoid the TMM procedure and modification of the IAB donor CU's behavior, the UE XnAP ID assigned to the RRC terminating donor CU should be provided to the target F1 terminating donor CU. For this purpose, there are two options: - F1AP signaling from the target logical mobile IAB-DU, e.g., using an F1 Setup Request message or a gNB-DU Configuration Update message. This option involves the UE XnAP ID being previously provided to the mobile IAB node, e.g., via RRC by the RRC terminating donor CU. This option does not require the BAP address to be provided in the F1 Setup Request message. - XnAP signaling from the source F1 terminating donor CU. This option may involve the introduction of a new XnAP procedure. Furthermore, to avoid confusion in case of simultaneous DU transitions of several mobile IAB nodes, additional information known by the target F1 terminating donor CU must be provided along with the UE XnAP ID. This additional information may be the BAP address selected by the RRC terminating donor CU for the mobile IAB node. It is assumed that this BAP address is present in the F1 Setup Request message from the target logical mobile IAB-DU to the target F1 terminating donor CU, and that this BAP address is also available in the source F1 terminating donor CU.

[0294] Based on the above considerations, it can be concluded that if F1AP signaling from the target mobile IAB-DU is selected to transfer the identity of the mobile IAB MT to the target F1 terminating donor CU, the impact of the standard is less and it is preferable to use the UE XnAP ID for identifying the mobile IAB-MT.

[0295] Therefore, in case of DU transition of a mobile IAB node, it is proposed that F1AP signaling from the target mobile IAB-DU is selected to transfer the UE XnAP ID (in the RRC terminating donor CU) of the mobile IAB MT to the target F1 terminating donor CU.

[0296] Considering the case of network integration, there are two options for passing the identifying information to the F1 terminating donor CU (i.e., the CU of the mIAB-DU): Option 1: via F1AP signaling, the mobile IAB node provides identification information based on information received from the RRC terminating donor CU (i.e., the CU of the mIAB-MT); - Option 2: Once the RRC terminating donor CU learns the identifier of the F1 terminating donor CU from the mobile IAB node via XnAP signaling, the RRC terminating donor CU provides the identification information.

[0297] With option 2, the RRC Terminating Donor CU must provide an identifier of the mobile IAB node known by the F1 Terminating Donor CU. This identifier may be the BAP address of the mobile IAB-MT selected by the RRC Terminating Donor CU, assuming this BAP address was present in the F1 Setup Request message from the mobile IAB-DU to the F1 Terminating Donor CU.

[0298] In Option 1, F1AP signaling can be the same as for DU transitions, and Option 1 appears to have less impact on standards than Option 2.

[0299] Therefore, in case of network integration of a mobile IAB node, it is proposed that F1AP signaling from the mobile IAB-DU is selected to transfer the gNB-ID of the RRC terminating donor CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor CU) to the F1 terminating donor CU.

[0300] Assuming that the same F1AP signaling is employed to pass identity information during DU transition and network integration of the mobile IAB node, for consistency the mobile IAB node should also provide identity information related to the target RRC terminating donor CU during MT transition.

[0301] Therefore, in case of MT integration of a mobile IAB node, it is proposed that F1AP signaling from the mobile IAB-DU is selected to transfer the gNB-ID of the target RRC terminating donor CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor CU) to the F1 terminating donor CU.

[0302] The F1AP procedure gNB-DU Configuration Update is appropriate to notify the F1 terminating donor CU in case of MT transition.

[0303] Then, a gNB-DU Configuration Update procedure may be used by the mobile IAB node to inform the F1 terminating donor CU of the gNB-ID of the RRC terminating donor CU and the UE XnAP ID of the mobile IAB-MT in this CU.

[0304] It can be observed that the source donor CU of mIAB-MT can send information about the target donor CU of mIAB-MT to the donor CU of mIAB-DU after the completion of IAB-MT HO (handover). In fact, our proposal is compatible with this description because the source RRC terminating donor CU (i.e., source donor CU of mIAB-MT) passes information to the F1 terminating donor CU (i.e., donor CU of mIAB-DU) via the mobile IAB node, not directly.

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

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

[0307] In the foregoing embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof.

[0308] 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. Computer-readable media may include computer-readable storage media, which correspond to tangible media such as data storage media, or communication media, including any medium that facilitates transfer of a computer program from one place to another, for example, according to a communications protocol. Thus, computer-readable media may generally correspond to (1) tangible computer-readable storage media that are non-transitory, or (2) communication media such as signals or carrier waves. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0309] 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 desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio waves, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio waves, and microwaves may be included within the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, and instead cover non-transitory tangible storage media. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically and discs reproduce data optically with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. 1. A method for use in managing a transport transition for traffic associated with an Integrated Access and Backhaul (IAB) node, the transport transition being performed after a distribution unit (DU) of the IAB node has transitioned from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method at the target IAB donor CU comprising: receiving a notification including identification information for identifying an IAB donor CU serving a mobile termination (MT) of the IAB node, wherein the IAB donor CU serving the MT of the IAB node is an IAB donor CU different from the target IAB donor CU; and performing a transport transition to transition traffic associated with the IAB node routing via at least one path between the target IAB donor CU and the IAB node through an IAB topology managed by the IAB donor CU serving the MT based on the identification information and after the DU of the IAB node has been transitioned to the target IAB topology.

2. The method of claim 1 , wherein the IAB donor CU serving the MT is the source IAB donor CU.

3. 2. The method of claim 1, wherein the IAB donor CU serving the MT is a second IAB donor CU managing a second IAB topology, and the path between the target IAB donor CU and the MT at the IAB node is via the second IAB topology.

4. 10. The method of any one of the preceding claims, wherein receiving notification comprises receiving notification from the source IAB donor CU.

5. The method of claim 4 , wherein the notification is included in a DU transition notification message.

6. The method of claim 4 , wherein the notification is included in a configuration update message.

7. The method of claim 1 , wherein receiving a notification comprises receiving a notification from the IAB node.

8. The method of claim 7 , wherein the notification is included in an F1 setup request message or a configuration update message.

9. The method of claim 3 , wherein receiving notification comprises receiving notification from the second IAB donor CU.

10. 10. The method of claim 9, wherein the notification is for indicating that the second IAB donor CU is ready for transport transition of the traffic for the IAB node, and the notification includes identification information for identifying the second IAB donor CU.

11. The method of claim 10 , wherein the notification is included in a transport migration ready message.

12. 10. The method of claim 1, wherein the notification further includes identification information for identifying the MT of the IAB node.

13. 1. A method for use in managing a migration process for migrating a distribution unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method in the source IAB donor CU comprising: determining that the DU of the IAB node should be migrated to the target IAB donor CU; sending a request to the IAB node to establish an F1 connection between the target IAB donor CU and the IAB node.

14. 14. The method of claim 13, wherein transmitting includes transmitting a request to establish an F1 connection between the target IAB donor CU and the IAB node and to inform the target IAB donor CU of the identification of an IAB donor CU that serves the mobile termination (MT) of the IAB.

15. The method of claim 13 or 14, wherein the request is included in a DU activation request message.

16. 16. The method of claim 13, wherein the request includes an information element (IE) for indicating the IAB node that will notify the target IAB donor CU of the identity of the IAB donor CU that serves the MT at the IAB node.

17. The method of claim 13 , wherein the request includes identification information for identifying the IAB donor CU serving the MT.

18. 18. The method of claim 13, wherein the request includes information to indicate to the IAB node that the IAB node will notify the target IAB donor CU of the identity of the IAB donor CU serving the MT.

19. 20. The method of claim 18, wherein the request includes the information when the target IAB donor CU is a different IAB donor CU than the IAB donor CU serving the MT at the IAB node.

20. 1. A method for use in a migration process for migrating a distribution unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method in the source IAB donor CU comprising: determining that the DU of the IAB node should be migrated to a target IAB donor CU; sending a notification to a target IAB donor CU including identification information for identifying an IAB donor CU serving a mobile termination of said IAB node; and performing a DU transition of the DU of the IAB node to the target IAB topology.

21. The method of claim 20, wherein the notification is included in a DU transition notification message.

22. The method of claim 20 , wherein the notification is included in a configuration update message.

23. 23. The method of claim 20, wherein the notification further includes identification information for identifying the MT of the IAB node.

24. 23. The method of claim 20, wherein sending includes, when the target IAB donor CU is a different IAB donor CU from the IAB donor CU serving the MT of the IAB node, sending a notification to the target IAB donor CU including identification information for identifying the IAB donor CU serving the MT of the IAB node.

25. 1. A method for use in a migration process for migrating a distributed unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method at the IAB node comprising: a method for transmitting an F1 setup request to the target IAB donor CU to request the setup of an F1 connection, the F1 setup request including identification information for identifying an IAB donor CU that serves a mobile termination (MT) of the IAB node.

26. 26. The method of claim 25, further comprising receiving a request from the source IAB donor CU to establish an F1 connection between the target IAB donor CU and the IAB node.

27. 26. The method of claim 25, further comprising receiving a request from the source IAB donor CU to establish an F1 connection between the target IAB donor CU and the IAB node and to inform the target IAB donor CU of the identification of the IAB donor CU that serves the MT of the IAB node.

28. 28. The method of claim 26 or claim 27, wherein the request to establish an F1 connection includes information for indicating the IAB node to notify the target IAB donor CU of the identification of the IAB donor CU serving the MT at the IAB node.

29. 29. The method of any one of claims 26 to 28, wherein the request includes identification information for identifying the IAB donor CU serving the MT.

30. 30. The method of claim 25, wherein the F1 setup request includes identification information for identifying the MT of the IAB node.

31. 31. The method of claim 25, wherein sending includes sending, to the target IAB donor CU, the F1 setup request including identification information for identifying the IAB donor CU serving the MT when the target IAB donor CU is a different IAB donor CU from the IAB donor CU serving the MT of the IAB node.

32. 1. A method for use in managing transport transition for traffic associated with an Integrated Access and Backhaul (IAB) node, the transport transition being performed after a distribution unit (DU) of the IAB node is transitioned from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, and a mobile termination (MT) of the IAB node is transitioned to a second IAB donor CU, the second IAB donor CU being a different IAB donor CU from the target IAB donor CU and the source IAB donor CU, the method at the second IAB donor CU comprising: receiving a transport transition release message to request release of a transport transition set up by a source IAB donor CU for traffic associated with the IAB node after the DU of the IAB node has been migrated to the target IAB topology; and sending a notification to the target IAB donor CU indicating that the second IAB donor CU is ready for transport transition of traffic associated with the IAB node via at least one path between the target IAB donor CU and the IAB node via an IAB topology managed by the second IAB donor CU, wherein the notification includes identification information for identifying the second IAB donor CU.

33. 33. The method of claim 32, wherein the notification is included in a transport migration ready notification message.

34. 34. The method of claim 32 or 33, further comprising releasing the transport transition previously set up by the source IAB donor CU after receiving the transport transition release message.

35. 35. The method of claim 34, wherein releasing includes reconfiguring IAB nodes involved in routing traffic to and / or from the IAB node by deleting, at each IAB node, configuration information related to routing traffic to and / or from the IAB node.

36. 34. The method of claim 32 or claim 33, further comprising suspending the transport transition previously set up by the source IAB donor CU after receiving the transport transition release message.

37. 37. The method of claim 36, wherein suspending includes suspending traffic transition and maintaining configuration of one or more IAB nodes in the one or more routing paths set up by the source IAB donor CU for traffic associated with the IAB nodes.

38. 38. The method of claim 32, wherein the notification includes identification information for identifying the MT of the IAB node.

39. 39. The method of claim 32, wherein the transport transition release message includes information indicating that the traffic transition release is due to a DU transition of the IAB node toward the target IAB donor CU.

40. 1. A method for use in a migration process for migrating a distributed unit (DU) of an Integrated Access and Backhaul (IAB) node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, the method at the IAB node comprising: sending a notification to the target IAB donor CU including identification information for identifying an IAB donor CU serving a mobile termination (MT) of the IAB node.

41. 41. The method of claim 40, wherein the notification further includes identification information for identifying the MT of the IAB node.

42. The method of claim 40 or claim 41, wherein the notification is included in a configuration update message.

43. 43. The method of claim 40, wherein transmitting includes, after completion of setup of an F1 connection between the DU of the IAB node and the target IAB donor CU, transmitting a notification to the target IAB donor CU including identification information for identifying an IAB donor CU serving a mobile termination (MT) of the IAB node.

44. 42. A method according to any one of the preceding claims depending on a respective one of claims 12, 23, 30, 38 or 41, wherein the identification information for identifying the MT of the IAB node comprises at least one of a UE XnAP ID and a BAP address.

45. 1. An apparatus for an IAB donor central unit (CU) node of an Integrated Access and Backhaul (IAB) communication system, comprising: receiving a notification including identification information for identifying an IAB donor CU serving a mobile termination (MT) of an IAB node of the IAB communication system, the IAB donor CU serving the MT of the IAB node being a different IAB donor CU from the IAB donor CU; Based on the identification information, and after the DU of the IAB node is migrated to the IAB topology managed by the IAB donor CU, performing a transport transition to transition traffic associated with the IAB node routing via at least one path between the IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT.

10. An apparatus comprising: one or more processing units configured to:

46. 46. ​​The apparatus of claim 45, wherein the one or more processing units are configured to receive the notification from the IAB node.

47. 47. The apparatus of claim 46, wherein the notification is included in an F1 setup request message or a configuration update message.

48. 48. The apparatus of claim 45, wherein the notification further includes identification information for identifying the MT of the IAB node.

49. 49. The apparatus of claim 48, wherein the identification information for identifying the MT to the IAB node includes at least one of a UE XnAP ID and a BAP address.

50. 1. An apparatus for an IAB donor central unit (CU) node of an Integrated Access and Backhaul (IAB) communication system, comprising:

10. An apparatus comprising one or more processing units configured to carry out the method of any one of claims 1 to 24 and claims 32 to 39 or claim 44.

51. 1. An apparatus for an Integrated Access and Backhaul (IAB) node of an IAB communication system, comprising:

1. An apparatus comprising: one or more processing units configured to send an F1 setup request to a target IAB donor CU to request the setup of an F1 connection, the F1 setup request including identification information for identifying an IAB donor CU that serves a mobile termination (MT) of the IAB node.

52. 52. The apparatus of claim 51, wherein the one or more processing units are further configured to receive, from a source IAB donor CU, a request to establish an F1 connection between the target IAB donor CU and the IAB node.

53. 53. The apparatus of claim 51 or 52, wherein the F1 setup request includes identification information for identifying the MT of the IAB node.

54. 54. The apparatus of claim 53, wherein the identification information for identifying the MT to the IAB node includes at least one of a UE XnAP ID and a BAP address.

55. 55. The apparatus of claim 51, wherein the one or more processing units are configured to, when the target IAB donor CU is a different IAB donor CU from the IAB donor CU serving the MT of the IAB node, send the F1 setup request to the target IAB donor CU, the F1 setup request including identification information for identifying the IAB donor CU serving the MT.

56. 1. An apparatus for an Integrated Access and Backhaul (IAB) node of an IAB communication system, comprising:

45. An apparatus comprising one or more processing units configured to carry out the method of any one of claims 25 to 31 and claims 40 to 44.

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

58. 58. A computer readable medium carrying a computer program according to claim 57.

Images