Node migration in IAB communication systems

Abstract

To flexibly perform node migration in an IAB communication system. [Solution] A method and apparatus are disclosed for use in a migration process in which a distributed unit (DU) of an integrated access backhaul (IAB) node migrates from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU. The method in the source IAB donor CU includes determining that the DU of the IAB node migrates from one IAB topology of the source IAB donor CU to another IAB topology of the target IAB donor CU, and sending a request to the IAB node to establish an F1 connection between the IAB node and the target IAB donor CU. The method in the IAB node includes receiving a request from the source IAB donor CU to establish an F1 connection between the target IAB donor CU and the IAB node, and sending an F1 setup request to the target IAB donor CU to request setup of the F1 connection.

Description

Technical Field

[0001] The present invention generally relates to a method used in a process for migrating nodes and traffic between integrated access backhaul (IAB) topologies including mobile IAB nodes. In particular, the present invention relates to a method used in a migration process in which a distributed unit (DU) of an IAB node, such as a mobile IAB node, is migrated between IAB topologies.

Background Art

[0002] Wireless communication systems have been widely deployed to handle a wide range of applications, from mobile broadband, massive machine type communication to ultra-reliable low-latency communication (URLLC). In such systems, multiple user equipment (UE) or mobile terminals share a wireless medium and can exchange multiple types of data content (e.g., video, audio, messaging, etc.) on a radio access network (RAN) via one or more base stations. Base stations have conventionally been wired-connected (e.g., via fiber) to a core network, forming an intermediate network called a backhaul (BH).

Summary of the Invention

Problems to be Solved by the Invention

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

[0004] Due to the increasing number of users and high throughput requirements, the demand for network densification is increasing.

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

[0006] Because IAB eliminates the need to lay cables at base stations and allows for scalable and rapid deployment, it is a competitive alternative to fiber optic-based backhaul in densely populated and hard-to-cover areas.

[0007] IAB is most likely to operate in the millimeter-wave (mmWave) band to achieve the required Gbps (Gbps) data rate. However, millimeter waves are known to suffer significant signal attenuation under certain weather conditions (rain, fog) and can be blocked if there are obstacles in the path between the emitter and receiver.

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

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

[0010] There are other situations in which an IAB node can become a boundary node. For example, in the case of a partial migration of an IAB node determined by an IAB donor, the mobile termination (MT) of that IAB node connects to a parent IAB node belonging to a different IAB topology managed by a different IAB donor. This situation can also occur when an IAB node that has experienced a radio link failure (RLF) recovers via a parent IAB node belonging to a different IAB topology. In such cases, the migrated IAB node and its potential descendant IAB nodes still belong to the original IAB topology, and such a partial migration is sometimes referred to as an MT migration. To ensure that traffic can be routed through the other IAB topology, an MT migration should be followed by a traffic migration in which traffic associated with the boundary node and its descendant IAB nodes is routed through the other IAB topology to the boundary node (i.e., the migrated IAB node).

[0011] A stationary IAB node requires only a single MT migration. In fact, a backhaul link (defined between two consecutive IAB nodes in a wireless backhaul) can experience radio failures due to fluctuations in radio conditions; for a stationary IAB node, this is a temporary situation, and the link may recover after some time. Therefore, such a stationary IAB node does not need to perform multiple MT migrations within the same IAB topology or to a different IAB topology, thus avoiding the transmission and processing of multiple protocol messages. For the same reason, migrating the distributed units (DUs) of an IAB node by handing over control of the IAB node to a new IAB donor is not required for a stationary node. Furthermore, it should be noted that such a DU migration, which may be called a full migration, involves a handover of the UEs that the migrating mobile IAB node will be serving.

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

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

[0014] The technical advantage of using a VMR is its ability to provide good radio link conditions to nearby UEs. In addition, compared to solutions that use UEs as repeaters (i.e., side-link relay solutions), vehicle-mounted IAB nodes are considered to have better RF / antenna performance and fewer power and battery constraints than repeater UEs.

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

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

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

[0018] A second aspect of the present invention provides a method for use in a migration process in which a DU of an IAB node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, as described in the appended claims, the method being performed on the IAB node.

[0019] A third aspect of the present invention provides a method for use in a migration process in which a DU of an IAB node is migrated from one IAB topology managed by a source IAB donor central unit (CU) to another IAB topology managed by a target IAB donor CU, as described in the appended claims, the method being performed in the target IAB donor CU.

[0020] Therefore, by sending a request to the IAB node to establish an F1 connection between the IAB node and the target IAB donor CU, the source F1 donor CU (e.g., the source IAB donor CU) facilitates the DU migration of the IAB node, with or without (multiple) MT migrations. Furthermore, in response to receiving the request to establish an F1 connection, the IAB node can identify the target donor CU (e.g., via identification information sent by the source donor CU, or, when no identification information is sent by the source donor CU, by determining that a non-F1 donor CU is the target donor CU) and enable the handover of the UEs serviced by the IAB node to the target donor CU. Non-F1 (terminating) donor CUs are also known as RRC (terminating) donor CUs.

[0021] A fourth aspect of the present invention provides an apparatus for an IAB node for an IAB communication system, as described in the appended claims.

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

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

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

[0025] Hereinafter, reference is made to sources and targets with respect to different elements such as nodes / topologies. However, it will be understood that the terms first and second may be used instead of source and target.

[0026] Any component in one aspect of the present invention can be applied in a suitable combination to other aspects. In particular, aspects of the method are applicable to aspects related to apparatuses, devices, or units, and vice versa.

[0027] Moreover, functions implemented by hardware can also be implemented by software, and vice versa. The descriptions of software functions and hardware functions in this specification should be interpreted in such a spirit. For example, as another aspect of the present invention, a computer program including instructions for causing a processing unit to execute a method according to any of the above aspects or embodiments by executing the program by one or more processing units, or a computer-readable medium recording the computer program may also be provided.

[0028] Here, different aspects of the present invention will be described by way of example with reference to the following drawings.

Brief Description of Drawings

[0029] [Figure 1] It is a schematic diagram of a communication system in which the present invention can be implemented according to one or more embodiments. [Figure 2a] It is a diagram schematically showing a stack of some protocol layers involved in IAB operation. [Figure 2b] It is a diagram schematically showing a stack of some protocol layers involved in IAB operation. [Figure 3] It is a schematic diagram showing the format of a BAP protocol data unit (PDU) or packet. [Figure 4] It is a block schematic diagram of an exemplary wireless communication device according to an embodiment of the present invention. [Figure 5] It is a schematic diagram of an exemplary IAB communication system (or IAB network system) in which embodiments and examples of the present invention can be implemented. [Figure 6] It is a schematic and simplified diagram showing an example of an IAB node architecture that enables DU migration from a source IAB topology to a target IAB topology. [Figure 7]This is a simplified diagram illustrating an exemplary message flow according to one or more embodiments of the present invention for performing a DU migration of an IAB node, including a handover of UEs served by the IAB node being migrated. [Figure 8a] This is a simplified diagram illustrating an exemplary message flow of a procedure for performing logical DU activation according to one or more embodiments of the present invention. [Figure 8b] This is a simplified diagram illustrating an exemplary message flow for the procedure to set up a logical DU. [Figure 8c] This is a simplified diagram illustrating an example message flow for a procedure to remove logical DUs. [Figure 8d] This is a simplified diagram illustrating the message flow of an example procedure used by a logical DU to notify a RAN node CU of configuration changes. [Figure 9a] This is a simplified diagram illustrating the message flow of an exemplary procedure used by a RAN node CU to report cell activation to another RAN node CU. [Figure 9b] This is a simplified diagram illustrating an exemplary message flow of a procedure used by RAN node CUs to coordinate with other RAN node CUs to manage transport migrations. [Figure 10a] This is a flowchart illustrating an exemplary method according to an embodiment of the present invention for managing the DU migration of an IAB node to a target IAB topology at a source F1 termination donor CU of an IAB node. [Figure 10b] This is a flowchart illustrating an exemplary method according to an embodiment of the present invention for managing DU migration to a target IAB topology at an IAB node. [Figure 10c] This flowchart shows exemplary steps according to one or more embodiments of the present invention, which are performed at an IAB node to identify a target IAB donor CU. [Figure 10d]This is a flowchart illustrating an exemplary method according to an embodiment of the present invention for managing the DU migration of IAB nodes to a target IAB topology managed by a target IAB donor CU in a target IAB donor CU. [Modes for carrying out the invention]

[0030] Figure 1 shows an exemplary communication system 100, in particular a mobile wireless communication 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 will describe embodiments of the present invention in relation to a 5G NR system, the present invention is not intended to be limited to a 5G NR system and should be understood to be applicable to any wireless communication system having a mobile base station. In particular, the following description will primarily use terminology specific to 5G, but it should be understood that such terminology also applies to elements or processes performing equivalent functions in other communication systems.

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

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

[0033] To extend the network coverage of IAB donor 120 and reach remote UEs 132, 133, and 131, IAB stations 121 and 122, also referred to as IAB nodes 121 and 122, have been installed by the operator. IAB nodes 121 and 122 can overcome reachability problems caused by the presence of building 108 by acting as relay nodes between IAB donor 120 and UEs 132 and 133. Building 108 is an obstacle that hinders radio wave propagation, making direct connection and communication between the UEs and IAB donor 120 difficult. This is especially true when communication between IAB donor 120 and UEs 132 and 133 operates at millimeter-wave frequencies, which are highly sensitive to shadowing.

[0034] IAB donor 120 also serves UE 134, which is directly connected to IAB donor 120. Mobile IAB station 123, also referred to as mobile IAB node 123 or mIAB node 123, is an IAB node mounted on vehicle 105 and provides network coverage and capacity expansion. This allows IAB donor 120 to reach onboard remote UEs such as remote UE 135, as well as surrounding UEs or UEs near IAB node 123 such as remote UE 136.

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

[0036] The Integrated Access Backhaul (IAB) specification is described across several 3GPP standard documents, including the following: - TS 38.300 RAN architecture (V17.2.0), - TS 38.321 MAC protocol (V17.2.0), - TS38.331 Wireless Resource Control (RRC) Protocol (V17.2.0) - TS 38.340 Backhaul Application Protocol Layer (V17.2.0), - TS 38.401 RAN architecture (V17.2.0), - TS38.423 Xn Application Protocol (V17.2.0), - TS 38.473 F1 Application Protocol (V17.2.0).

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

[0038] An IAB donor 120 is a logical node that provides NR-based wireless backhaul and consists of a central unit (CU or gNB-CU function) and connected donor distributed units (DU or gNB-DU function). 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 and controls the operation of one or more DUs. One or more IAB-donor DUs or donor DUs (hereinafter also referred to as IAB-donor DU or IAB donor DU) include lower-layer protocols such as RLC, MAC, and physical layer protocols. The IAB-donor CU or donor CU and the IAB-donor DU or donor DU may be located far apart from each other or may be located within the same physical device. The gNB-DU function is defined in 3GPP TS 38.401. This aims to terminate the NR access interface to the UE and the next-hop IAB node, as well as to terminate the F1 protocol to the IAB donor gNB-CU function, as shown in Figures 2a and 2b discussed below.

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

[0040] An 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 called an IAB-DU, enables downstream connectivity to the next-hop IAB or UE (towards the UE). The IAB-MT function includes physical layer, layer 2, RRC, and NAS (Non-Access Stratum) functions for connecting to the gNB-DU of an upstream IAB node (including IAB donor 120, which in this case connects to the IAB donor gNB-CU and is therefore connected to the core network 110 for initialization, registration, and configuration, etc.).

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

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

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

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

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

[0046] In the user plane, box 210 in the IAB donor CU and IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunnelling Protocol User Plane. A GTP-U tunnel is used to transmit encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for more details), which here is 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 best-effort datagram services and is compatible with use with the IP protocol.

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

[0048] Transport between IAB-donor CUs and IAB-donor DUs uses the IP transport layer over various media, such as wired or fiber optic, when the IAB-donor CU is located far from the IAB-donor DU. Alternatively, if the IAB-donor CU and IAB-donor DU are virtually instantiated on the same physical machine, the IP transport layer is used locally. IAB-specific transport between IAB-donor CUs and IAB-donor DUs is specified in 3GPP TS 38.401.

[0049] In Figure 2a, L1 and L2 represent the transport layer and physical layer, respectively, suitable for the medium being used.

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

[0051] On a wireless backhaul, the IP layer is transmitted via a Backhaul Adaptive Protocol (BAP) sublayer. The BAP sublayer enables routing across multiple hops. The BAP sublayer is defined in TS38.340.

[0052] IP traffic from an IAB-DU is routed over the wireless backhaul via a BAP sublayer. Downstream, upper-layer packets are encapsulated by the BAP sublayer at the IAB donor DU, thereby forming a BAP packet or packet data unit (PDU) or data packet. BAP packets are routed by the BAP layer or entities (corresponding BAP entities in IAB-DUs and IAB-MTs), if any, at intermediate IAB nodes. Finally, BAP packets are decapsulated by the BAP sublayer at the destination IAB node (which may be the access IAB node if the upper-layer packets within the BAP packet target a UE).

[0053] Upstream, upper-layer packets are encapsulated by a BAP sublayer at the initiator IAB node (which can be the access IAB node if the upper-layer packets are coming from the UE), thereby forming a BAP packet or data unit (PDU) or data packet. BAP packets are routed by the BAP layer of intermediate IAB nodes, if any (corresponding BAP entities in IAB-DU and IAB-MT). Finally, BAP packets are decapsulated by a BAP sublayer at the IAB donor DU.

[0054] At the BAP sublayer, packets are routed based on the BAP routing ID contained in the BAP header. The BAP routing ID is set by the BAP sublayer of the source 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 a BAP Data Protocol data unit (PDU) or packet. This format is specified in paragraph 6.2 of the standardized version of 3GPP TS38.340 release 17.2.0.

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

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

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

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

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

[0060] As described above, these configuration tables, which define the BAP paths (and therefore the routing strategies and configurations of IAB nodes given an IAB network topology), are typically defined by the IAB donor CU and sent to the IAB nodes for configuration.

[0061] To transmit messages over the 5G NR radio medium, each IAB node implements three or more sublayers (RLC, MAC, and PHY) under the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconfiguration. It also plays a role in requesting the retransmission of lost packets. The RLC layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for user data and mapping logical channels to transport channels. MAC also handles part of the hybrid automatic repetition request scheme. The MAC layer is detailed in TS38.321. On the transmitting or transmitter side, MAC encapsulates data packets issued from the RLC. This adds a header that carries the information necessary for MAC functionality. On the receiver side, MAC decapsulates data packets issued from the PHY sublayer, removes its header, and passes the remaining data to the RLC. The PHY sublayer converts the information stream into a physically modulated signal and modulates the transmission frequency at the transmitter side, thereby providing an electrical interface to the transmission medium (air). At the receiver side, the PHY sublayer converts the physically modulated signal back into the information stream. The PHY layer is described in TS38.201, TS38.211, TS38.212, TS38.213, and TS38.214.

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

[0063] The PDCP sublayer compresses and decompresses IP headers, encrypts and decrypts them, and protects the integrity of data packets as needed. It also assigns sequence numbers to packets at the sending end and reorders them at the receiving end. The PDCP sublayer is described in 3GPP TS38.323.

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

[0065] The RRC sublayer 220 for the control plane handles the configuration of protocol entities in the user plane's protocol stack. This is described in TS38.331. Specifically, it is responsible for broadcasting information necessary for the UE to communicate with the cell, sending paging messages, managing connectivity including bearer configuration, mobility functions, configuration and reporting of measurements, and handling device capabilities.

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

[0067] The interface between nodes (for both CP and UP) that uses Layer BAP, RLC, MAC, and PHY is called a backhaul RLC channel (BH RLC channel). This primarily relates to the interface between IAB nodes.

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

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

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

[0071] Figure 4 shows a schematic diagram of an exemplary communication device (apparatus) or station according to one or more exemplary embodiments of the present disclosure.

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

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

[0074] Memory may include the following: - A read-only memory 407 referred to as ROM for storing a computer program for carrying out a method according to one or more embodiments of the present invention. - Random access memory 412 referred to as RAM for storing executable code for a method according to one or more embodiments of the present invention, and registers adapted to record variables and parameters necessary for implementing a method according to one or more embodiments of the present invention.

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

[0076] In an exemplary configuration, the communication bus 413 provides communication and interoperability between various elements included in or connected to the communication device 400. The representation of the bus is not limited, and in particular, the central processing unit can operate to communicate instructions directly to any element of the communication device 400 or through another element of the communication device 400.

[0077] Disk 406 can be replaced with an information medium such as a compact disc (CD-ROM, whether rewritable or not), a ZIP disc, a USB key, or a memory card. Disk 406 is generally an information storage means readable by a microcomputer or microprocessor, removable whether or not it is integrated into a communication device, and suitable for storing one or more programs that enable the method according to embodiments of the present invention.

[0078] The executable code may optionally be stored in read-only memory 407, hard disk 404, or a removable digital medium such as the aforementioned disk 406. According to any modification, the program's executable code may be received by the communication network 403 via interface 402 so that it is stored in one of the storage means of the communication device 400, such as the hard disk 404, before execution.

[0079] The central processing unit 411 can be adapted to control and direct the execution of instructions or portions of the software code of the program(s) according to the present invention, and these instructions are stored in one of the aforementioned storage means. Upon power-up, the program(s) stored in the non-volatile memory, e.g., the hard disk 404 or the read-only memory 407, is transferred to the random access memory 412. The random access memory includes the executable code of the program(s), as well as registers for storing variables and parameters necessary to carry out the present invention.

[0080] In exemplary implementations, the communication device (apparatus) is a programmable device / apparatus that uses software to implement the present invention. Instructions may be executed by one or more processors of the apparatus, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated circuits or discrete logic circuits, to implement the present invention for network nodes (e.g., IAB nodes, IAB donor DUs, etc.). Thus, the term “central processing unit” as used herein may refer to any of the aforementioned 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 application-specific integrated circuits or ASICs or other logic elements).

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

[0082] The IAB communication system 500 consists of three IAB networks or IAB topologies 5001, 5002, and 5003, each IAB topology comprising a set of IAB nodes (for example, a set may comprise multiple IAB nodes or at least one IAB node) and an IAB donor CU for controlling or managing the multiple IAB nodes. The set of IAB nodes may include an initiator IAB node that generates BAP packets and one or more IAB nodes, such as intermediate or relay IAB nodes. Each IAB node communicates with at least one other IAB node via a wireless backhaul (BH) link. Figure 5 shows three IAB topologies 5001, 5002, and 5003, but the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system comprising two or more IAB topologies, each topology comprising a set of IAB nodes and an IAB donor CU as described above.

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

[0084] IAB topology 5001 includes IAB donor CU501 (identified as donor 1-CU in Figure 5), its associated IAB donor DU504 (identified as donor 1-DU1 in Figure 5), and several IAB nodes 510 and 520 similar to IAB nodes 121 and 122.

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

[0086] IAB topology 5003 includes IAB-donor CU503 (identified as donor 3-CU in Figure 5), its associated IAB-donor-DU507 (identified as donor 3-DU1 in Figure 5), and IAB-node 560 similar to IAB-nodes 121 and 122.

[0087] The wired backhaul IP network interconnects IAB donors CU501, 502, and 503 with IAB donors DU504, 505, 506, and 507 via the wired backhaul 508. For example, this wired backhaul 508 consists of fiber optic cables.

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

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

[0090] IAB donor CU503, IAB donor DU507, and IAB node 560 are part of the same IAB network or IAB topology 5003, which is configured and managed or controlled by IAB donor CU803.

[0091] Each IAB-DU and IAB donor DU supports wireless communication within a coverage area called a cell (not shown in Figure 5). In other words, each IAB-DU and IAB donor DU is associated with a cell. Wireless communication devices located within a cell (such as UEs or other IAB nodes) can establish communication links with the node providing services to the cell (i.e., the IAB-DU or IAB donor DU) in order to communicate with other devices (e.g., other UEs, IAB nodes, servers providing internet access, etc.) via the node.

[0092] Assume that mobile IAB node 570 initially has a single parent IAB node 520 and belongs to IAB topology 5001 controlled by IAB donor CU 501. Thus, the IAB-donor CU is operating as an F1-terminated donor CU (also referred to as an F1-terminated IAB-donor CU or F1 donor CU). When moving, considering the proximity to IAB node 530 in IAB topology 5002, in particular when mobile IAB node 570 is in the position shown by the dotted line in Figure 5, mobile IAB node 570 can establish a wireless BH link with IAB node 530. Such a BH link is possible for stationary IAB nodes and is very likely to occur for mobile IAB nodes such as IAB node 570 moving in the direction of IAB topology 5002 (indicated by arrow 590 in Figure 5).

[0093] Next, the F1 donor CU 501 may have decided to perform a migration of the MT portion 571 of IAB node 570 toward an IAB topology controlled by donor CU 502. This donor CU 502 became a non-F1 terminated donor CU for IAB node 570 (this may also be referred to as a non-F1 terminated IAB-donor CU, non-F1 donor CU, RRC terminated donor CU, or RRC donor CU) (i.e., the MT portion 571 of IAB node 570 is migrated toward the parent IAB node 530). For this purpose, the F1 donor CU 501 may have initiated the interCU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or section 8.17.3.2 (if IAB node 570 has descendant IAB nodes). As a result, IAB node 501 still belongs to IAB topology 5001 and has its F1 connection to donor CU 501, but its RRC connection is now to donor CU 502. After that procedure, IAB donor CU 501 can request the migration of backhaul traffic associated with IAB node 570 (e.g., user traffic, control traffic) to IAB topology 5002 (i.e., through donor DU 505). In this case, donor CU 501 triggers the IAB transport migration management procedure specified in TS38.423 V17.2.0 section 8.5.2. In the 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 IAB-DU. Therefore, the traffic or backhaul traffic to be offloaded or migrated is F1 traffic and can include control traffic and user traffic.

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

[0095] After being notified to route F1 traffic related to IAB node 570 using donor DU506 instead of donor DU505, donor CU501 can request the migration of traffic related to IAB node 570 to IAB topology 5002. In this case, donor CU501 triggers the IAB transport migration management procedure specified in TS38.423 V17.2.0 section 8.5.2.

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

[0097] In all of the above MT migration cases, the UE580 is still connected to the donor CU501 via the DU portion or unit 572 of the mobile IAB node 570. If the IAB node 570 has several child IAB nodes, such child IAB nodes still belong to the IAB topology 5001 and are still fully controlled by the donor CU501 (via F1 and RRC connections).

[0098] Regardless of the state of migration of the MT portion 571 of IAB node 570, that is, whether or not the MT portion 571 of IAB node 570 has migrated to IAB topology 5002 or IAB topology 5003, and therefore whether or not IAB node 570 has a non-F1 terminated donor CU, and if so, whether or not it has a non-F1 terminated donor CU 502 or 503, the F1 donor CU 501 can decide to perform migration of the DU portion of IAB node 570. Reasons for performing DU migration may be to reduce the processing load on the F1 donor CU 501, or because IAB node 570 is geographically far from the F1 donor CU 501 and is close to an area where there is no Xn connection between the F1 donor CU 501 and the target donor CU. After the decision to perform a DU migration for IAB node 570, F1 donor CU 501 must also decide which donor CU (referred to as the target F1 donor CU) to which the DU migration should be performed. This could be a DU migration to the current non-F1 terminal donor CU (i.e., the default option), or, if a current non-F1 terminal donor CU exists, this non-F1 terminal donor CU could become the target F1 donor CU, or a migration to 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 know the appropriate target F1 donor CU that will control the cell that IAB node 570 will soon connect to the network. For example, while the non-F1 terminal donor CU of IAB node 570 is donor CU 502, the F1 donor CU may decide that the DU migration of IAB node 570 should be performed directly toward donor CU 503. This is because IAB node 570 may quickly pass through IAB topology 5002, which is controlled by donor CU502, and not remain there.By performing a DU migration to donor CU503 instead of DU migration to donor CU502, the protocol messages regarding the intermediate DU migration from IAB node 570 can be avoided. When DU migration is performed, the handover of UEs provided by IAB node 570 must also be performed. Therefore, by not performing a DU migration to donor CU502, the intermediate handover of UEs provided by IAB node 570 to donor CU502 can be avoided.

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

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

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

[0102] Prior to DU migration, for example, UE602 (such as UE580 in Figure 5) is connected to source F1 donor CU501 via access link 621 in a cell serviced by logical DU IAB-DU1 611, and logical DU IAB-DU2 612 is deactivated. During DU migration, logical DU IAB-DU2 612 is activated and connected to target F1 donor CU502. This allows UE602 to connect to target F1 donor CU502 via logical DU IAB-DU2 612 through link 622 in a cell serviced by logical DU IAB-DU2 612. Activation of logical DU IAB-DU2 612 may be triggered by source F1 donor CU and performed using the procedure described with reference to Figures 8a and 8b. Once the handover of UE602 is complete 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. This deactivation may be triggered by source F1 donor CU501 in accordance with the procedure described with reference to Figure 8c, after detecting that all UEs have completed the handover from the cells provided by IAB-DU1 611.

[0103] Examples of methods according to one or more embodiments of the present invention that enable DU migration of an IAB node with or without (multiple) MT migrations, and that notify the IAB node of the identification information of a target donor CU, thereby enabling the handover of UEs provided by the IAB node to the target donor CU, are described below. The following methods / apparatus are described primarily in relation to mobile IAB nodes, but it should be understood that the present invention is not intended to be limited to mobile IAB nodes. Methods according to one or more embodiments of the present invention can also be applied, for example, to a stationary IAB node located at the edge of an IAB topology and in the vicinity or proximity of one or more IAB nodes in an adjacent IAB topology.

[0104] Figure 7 is a schematic and simplified diagram showing an exemplary message flow according to one or more embodiments for performing a DU migration of an IAB node. This migration is performed with or without (multiple) MT migrations and includes notifying the IAB node of information about the target donor CU to enable the handover of the UE provided by the IAB node to the target donor CU during the migration.

[0105] Figure 7 shows UE708 (like UE580), source F1 donor CU703 (like donor CU501), target F1 donor CU707 (like donor CU503), and core network (5GC) 702 (like core network 110 in Figure 1). Figure 7 also shows IAB node 701, which may be a mobile IAB node like IAB node 570, consisting of IAB-MT portion or unit IAB-MT704, DU portion or unit IAB-DU1 705 (e.g., source or first logical DU entity), and DU portion or unit IAB-DU2 706 (e.g., target or second logical DU entity). Each of the first and second DU logical entities 705, 706 serves one or more cells. Cells in IAB-DU1 705 are identified by different identifiers (e.g., Physical Cell Identifier (PCI), New Wireless Cell Group Identifier (NCGI)) than those in IAB-DU1 705. IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for the BAP layer, RLC layer, and MAC layer. In one example, they share the same physical layer (i.e., the same hardware resources), but in another example, they depend on different physical layers. If IAB-MT704 was not migrated, the non-F1 donor CU for IAB node 701 could be the source F1 donor CU 703 itself. The non-F1 donor CU for IAB node 701 could also be the target F1 donor CU 707 if IAB-MT704 was previously migrated toward this other donor CU, or it could be another donor CU (illustrated).

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

[0107] The IAB-MT704 may transmit a measurement report (not shown in Figure 7) as a result of periodic measurements based on signals received from the serving cell and one or more target cells (e.g., signal synchronization blocks (SSBs) transmitted by the serving cell and target cells). This measurement report is transmitted to the non-F1 terminated donor CU if the IAB-MT704 has previously been migrated to that non-F1 terminated donor CU, or to the F1 terminated donor CU (e.g., source F1 donor CU703) if the IAB-MT704 has not been migrated from the F1 terminated donor CU. The target cell may be a cell adjacent to the serving cell or source cell (i.e., the current serving cell). When the IAB-MT704 detects at least one SSB that satisfies a predefined criterion (e.g., received power exceeding a predetermined threshold), a measurement report is generated. The measurement report may be transmitted to provide radio link quality information for different cells in the vicinity of IAB node 701. The measurement report includes an identifier for each cell, which allows the non-F1 donor CU (if IAB-MT704 is migrated) or the F1-terminated donor CU 703 (if IAB-MT704 is not migrated) to identify the target donor CU associated with that cell. In fact, the donor CU can be identified from the physical cell identifier (PCI) broadcast in the synchronization signal in each cell managed by this donor CU, and / or the new radio cell group identifier (NCGI) broadcast in the System Information Block (SIB) message in each cell managed by this donor CU. The PCI and / or NCGI may be reported by IAB node 701 in the measurement report.

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

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

[0110] Depending on the decision or determination to perform a DU migration of IAB node 701 by or performed by source F1 donor CU 703 toward another IAB topology managed by another donor CU which will become target F1 donor CU 707, the first step 720 corresponds to sending a request to IAB node 701 to establish a new F1 connection between target F1 donor CU 707 and mobile IAB node 701. This request may require the activation of a second logical IAB-DU2 706 in mobile IAB node 701, and the first step 720 may include the activation of the second logical DU-DU2 706 in mobile IAB node 701. This operation is performed using the procedure described with reference to, for example, Figures 8a and 8b. In particular, the message sent from source F1 donor CU703 to IAB node 701 to activate the second logical IAB-DU2 706 (e.g., 803 in Figure 8a) may include identification information to identify the target donor CU, such as the TNL address (i.e., IP address) of the target F1 donor CU707, thereby enabling the establishment of a new F1 connection or F1 association (e.g., F1AP interface connection) between IAB-DU2 706 and the target donor CU707. If the address of the target F1 donor CU is not included in the activation request, by default, if IAB-MT704 has been migrated to a non-F1 donor CU, that non-F1 donor CU is considered the target F1 donor CU. In this case, IAB node 701 has already been notified of the identification information (e.g., TNL address / IP address) of the target donor CU when IAB-MT704 was migrated to a non-F1 donor CU. In other words, source F1 donor CU703 may transmit identification information to identify the target IAB donor CU, unless IAB-MT704 has been migrated to a non-F1 donor CU. Alternatively, source F1 donor CU703 may transmit identification information to identify a non-F1 donor CU as the target IAB donor CU.

[0111] After the source F1 donor CU703 has decided to migrate the DU of IAB node 701 and IAB-DU2 706 has been activated, IAB-DU2 706 may send an F1 setup request message (e.g., 813 in Figure 8b) to target F1 donor CU707 as a request to establish an F1 connection between IAB node 701 and target F1 donor CU707. This message may include identification information to identify source F1 donor CU703 of IAB node 701, such as the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID as defined in TS 38.423 V17.2.0 Section 9.2.2.3) of source F1 donor CU703. The message may also include a TNL address (i.e., an IP address) or identifier (i.e., the global NG-RAN node ID as defined in section 9.2.2.3 of TS 38.423 V17.2.0) to identify the non-F1 donor CU of IAB node 701 (if IAB-MT704 of IAB node 701 has previously been migrated to this non-F1 donor CU (not shown in Figure 7)). This is the case if IAB-MT704 of IAB node 701 has previously been migrated to this non-F1 donor CU, although this is not shown in Figure 7. The destination address of the F1 setup request message is the target F1 donor CU 707, and when this IP packet is received at the donor DU on the F1 path for IAB node 701, it may be routed to the target F1 donor CU 707 via the wired backhaul (508 in Figure 5). For example, in the case of IAB node 570 (corresponding to IAB node 701) shown in Figure 5, which is connected to IAB node 550 via backhaul link 5050, and where the MT of IAB node 570 (MT571 corresponding to IAB-MT704 in Figure 7) has been migrated to non-F1 donor CU502, and IAB donor CU501 is the source F1 donor CU, the F1 path between F1 donor CU501 and IAB node 570 uses donor DU506.If IAB donor CU503 is identified as target F1 donor CU (e.g., target F1 donor CU707), the F1 setup request message to target F1 donor CU (e.g., donor CU503) is sent to donor DU506 via IAB nodes 550 and 540, and then routed to target F1 donor CU503 via wired backhaul (508 in Figure 5). In the F1 setup response (e.g., 814 in Figure 8b), target F1 donor CU707 (donor CU503 as described in Figure 5 in the above example) may request IAB-DU2 706 on IAB node 701 to activate the new cell along with its identifier (PCI, NCGI). Typically, the DU activates / deactivates the cell under the control of the donor CU controlling the DU. See, for example, TS 38.473 section 8.2.3.2.

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

[0113] The next step, 730, consists of handing over the UE provided by IAB node 701 (for example, UE708 in Figure 7) from the cell of the first logical DU IAB-DU1 705 to the cell of the second logical DU IAB-DU2 706. This procedure may be a standardized procedure as described in TS 38.300 Section 9.2.3.2 (Handover) or a standardized procedure as described in TS 38.300 Section 9.2.3.4 (Conditional Handover). For example, to trigger the handover of UE708, source F1 donor CU703 sends a handover request message to target F1 donor CU707 containing the necessary information about the UE708 to be handed over (e.g., identification information to identify the UE, UE context information (e.g., security context (security parameters and UE security capabilities, etc.), measurement settings, radio settings (UE radio capabilities, etc.), bearer information, etc.)). Section 9.1.1.1 of TS 38.423 provides details regarding the content of the HANDOVER REQUEST message. After an approval control step in which the target F1 donor CU707 determines whether it is able to accept the handover of UE708, if the target F1 donor CU707 accepts the request, it sends a handover acknowledgment message to the source F1 donor CU705 containing configuration information for UE708 for the handover. This configuration information may include radio configuration information (e.g., frequency, radio bearer configuration, etc.) that UE708 will use to connect to the identified target cell of the second logical DU IAB-DU2 706. The handover acknowledgment may also include identifiers for one or more new cells (e.g., target cells) activated in IAB-DU2 706. The source F1 donor CU705 then sends this configuration information to UE708, which should connect to the target cell IAB-DU2 706, in an RRC reconfiguration message.The RRC reconfiguration message (specified in TS 38.331) is embedded in the F1 message DL RRC message transfer (specified in TS 38.473) and sent to IAB-DU1 705, which relays it to UE708. After receiving this configuration information, UE708 performs a random access procedure in the target cell of IAB-DU2 706 to obtain uplink resources, and then sends an RRC reconfiguration complete message to the target F1 donor CU707. The RRC reconfiguration complete message (specified in TS 38.331) is sent to IAB-DU2 706, and further embedded in the F1 message UL RRC MESSAGE TRANSFER (specified in TS 38.473) and sent to the target F1 donor CU707. Source F1 donor CU705 may be notified of the completion of the handover of UE708 via HANDOVER SUCCESS (as defined in TS 38.423) received from target F1 donor CU707.

[0114] The target F1 donor CU707 may execute a path switching procedure toward core network 702 to request the delivery of user data related to UE708. For example, the target F1 donor CU707 may execute the path switching handshake procedure described in section 8.4.4 of 3GPP TS 38.413 v17.2.0.

[0115] Subsequently, the target F1 donor CU 707 must establish a backhaul path to the migrated IAB node 701 either within its own topology (i.e., if the target F1 donor CU 707 is a non-F1 terminating donor CU to IAB node 701 because IAB-MT 704 was previously migrated to the target F1 donor CU 707), or, if there is no backhaul path to IAB node 701 in the IAB topology controlled by the target F1 donor CU 707, it must establish one through a non-F1 donor CU of IAB node 701 (not shown in Figure 7) (i.e., IAB-MT 704 and IAB-DU2 706 are connected to different donor CUs). In the latter case, the target F1 donor CU 707 may trigger the procedure described with reference to Figure 9b to request traffic migration of IAB node 701 to the non-F1 donor CU. Referring to Figure 5, an example of this latter case is given where IAB node 701 is IAB node 570 connected to IAB node 550 via backhaul link 5050, the MT of IAB node 570 (MT571 corresponding to IAB-MT704 in Figure 7) has been migrated to non-F1 donor CU502, and IAB donor CU501 is an F1 donor CU. When the DU of IAB node 570 (DU572, corresponding to IAB-DU2 706 in Figure 7) is migrated to target donor CU503 and has an F1 connection with F1 donor CU503, and MT571 continues to maintain an RRC connection via non-F1 donor CU502, the backhaul path to and from IAB node 570 is configured within IAB topology 5002 controlled by IAB donor CU502 (i.e., a backhaul path reaching IAB node 570 via IAB donor DU506, IAB nodes 540 and 550) and is executed by a traffic migration procedure (for example, the procedure described with reference to Figure 9b).

[0116] After the UE708 handover and path switching, downstream user data is transmitted via bearer 740 to target F1 donor CU 707 by core network 702, then to logical DU IAB-DU2 706 of IAB node 701 via backhaul bearer 741, and finally to UE708 via data radio bearer 742. Backhaul bearer 741 can be established in an IAB topology controlled by target F1 donor CU 707, or in an IAB topology controlled by a non-F1 donor CU of IAB node 707 (for example, depending on whether IAB-MT704 and IAB-DU2 706 of IAB node 701 are connected to different donor CUs). Upstream user data (not shown) is transmitted in the reverse direction via similar bearers.

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

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

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

[0120] This diagram shows the following: - RAN node DU801 could be a DU of an IAB node, such as IAB-DU572 of IAB node 570 in Figure 5 (and IAB-DU1 705 of IAB node 701 in Figure 7). - RAN node CU802 could be an IAB donor CU like IAB donor CU501 in Figure 5 (and source F1 donor CU703 in Figure 7).

[0121] The message CONFIGURATION REQUEST803 is sent by RAN node CU802 to RAN node DU801 to request the activation of a new cell controlled by RAN node DU801, or to request the activation of a logical DU, or to request the deactivation of a cell within RAN node DU801. In the case of logical DU activation, message 803 may include the TNL address (i.e., IP address) of RAN node CU (e.g., target F1 donor CU707 in Figure 7) which will connect to the logical DU once activated. For example, CONFIGURATION REQUEST803 may be sent by source IAB donor CU to an IAB node (e.g., a first logical DU entity 705 having an F1 connection with source IAB donor CU) to request the establishment of an F1 connection between the target IAB donor CU and the IAB node.

[0122] RAN node DU801 may confirm the request by the message CONFIGURATION RESPONSE804 sent to RAN node CU802.

[0123] For example, the flow in Figure 8a corresponds to the procedure GNB-CU Configuration Update Procedure described in TS 38.473 V17.0.0 Section 8.2.5, message 803 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 Section 9.2.1.10, and message 804 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 Section 9.2.1.11.

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

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

[0126] For example, a new IE indicating the activation of a second DU may be added to message 803 in the form of a Boolean value (e.g., a 1-bit IE) to request the activation of a second logical DU. One value of the 1-bit IE (i.e., "0" or "1") means that no specific action related to the second logical DU is requested, and the other value (i.e., "1" or "0") means that the activation of the second logical DU is requested. This IE may be supplemented by a new IE indicating that the F1 setup is for the purpose of DU migration to the target RAN node CU (in other words, an IE indicating a request to establish an F1 connection relates to the DU migration of the DU at the IAB node), and / or by a new IE indicating the number of cells to be activated in the second logical DU. If there is no IE indicating the number of cells, the number of cells to be activated corresponds to the number of cells currently activated at RAN node DU801. Another IE can also provide a list of cell identifiers (e.g., PCI and / or NCGI) controlled by the first logical DU 705 at IAB node 701, with a mapping to the identifiers of the activated cells. For example, the mapping may not be necessary for all active cells controlled by the first logical DU 705, and only the identifiers of cells that map to the identifiers of cells activated and controlled by the second logical DU 706 may be included in message 803.

[0127] Furthermore, a new IE (e.g., target TNL address IE) may be added to identify the target RAN node CU where the F1 connection is set up.

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

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

[0130] This diagram shows the following: - RAN node DU811 could be a DU of an IAB node DU, such as IAB-DU572 of IAB node 570 in Figure 5 (and IAB-DU2 706 of IAB node 701 in Figure 7). - RAN node CU812 could be an IAB donor CU like IAB donor CU503 in Figure 5 (and target F1 donor CU707 in Figure 7).

[0131] The SETUP REQUEST message 813 is sent by RAN node DU811 to RAN node CU812 to request F1 setup for logical DU. For example, SETUP REQUEST 813 may be sent by an IAB node (e.g., by the second logical DU entity 706 activated in IAB node 701) to target IAB donor CU707 to request the setup of an F1 connection between the target IAB donor CU and the IAB node (e.g., using the second logical DU entity 706 of IAB node 701). The SETUP REQUEST message 813 may also be sent after an activation request, as described with reference to Figure 8a. This SETUP REQUEST message 813 may include an indication that the F1 setup relates to the DU migration of the RAN node embedding RAN node DU811 (e.g., information indicating the request to establish an F1 connection relates to the DU migration of the DU of the IAB node), and / or the number of cells to be activated along with the activation of the logical DU. The SETUP REQUEST message 813 may optionally include the identifier of the active cell controlled by the first logical DU 705 (e.g., PCI and / or NCGI) and / or the identifier of the cell to be activated (as discussed above), which provides a mapping between the identifier of the active cell controlled by the first logical DU 705 (e.g., PCI and / or NCGI). The SETUP REQUEST message 813 may include a request for a mapping between the identifier of the active cell controlled by the first logical DU (e.g., PCI and / or NCGI) and the identifier of the cell to be activated (e.g., in the second logical DU of the IAB node). The SETUP REQUEST message 813 may include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID as defined 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 811 (e.g., source IAB donor CU 703).This message may include the TNL address (i.e., IP address) or identifier (i.e., the global NG-RAN node ID specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the non-F1 (i.e., RRC) connection of RAN node DU 811. This applies when an MT (e.g., mMT571 on IAB node 570 or the corresponding IAB-MT704 on IAB node 701) is being migrated to a RAN node CU (which is now a non-F1 donor CU).

[0132] RAN node CU812 responds with the message SETUP RESPONSE814 sent to RAN node DU811. This may include a list of cells to be activated using the logical DU, along with the relevant PCI and NCGI values ​​used. It may also include a mapping between the identifiers (PCI and / or NCGI) of the cells activated by RAN node DU811 and the identifiers of the active cells controlled by the first logical DU705.

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

[0134] Figure 8c is a schematic and simplified version of Figure 820, illustrating an exemplary message flow for a procedure to remove a logical DU.

[0135] This diagram shows the following: - RAN node DU821 could be a DU of an IAB node DU, such as IAB-DU572 of IAB node 570 in Figure 5 (and IAB-DU1 705 of IAB node 701 in Figure 7). - RAN node CU822 could be an IAB donor CU like IAB donor CU501 in Figure 5 (and source F1 donor CU703 in Figure 7).

[0136] The message REMOVAL REQUEST823 is sent by RAN node CU822 to RAN node DU821 to request the removal (equivalent to deactivation) of the logical DU.

[0137] RAN node DU821 responds to RAN node CU822 with the message REMOVAL RESPONSE814.

[0138] For example, the flow in Figure 8c corresponds to the procedure F1 Removal described in TS 38.473 V17.2.0 Section 8.2.8, message 823 corresponds to the message F1 REMOVAL REQUEST described in TS 38.473 V17.2.0 Section 9.2.1.16, and message 824 corresponds to the message F1 REMOVAL RESPONSE described in TS 38.473 V17.2.0 Section 9.2.1.7.

[0139] Figure 8d is a schematic and simplified version of Figure 830 illustrating an exemplary message flow of a procedure used by a logical DU to notify an IAB donor CU of a configuration change, as an example.

[0140] This diagram shows the following: - RAN node DU831 could be a DU of an IAB-node DU, such as IAB-DU572 of IAB-node 570 in Figure 5 (and IAB-DU1 705 of IAB-node 701 in Figure 7). - RAN node CU832 could be an IAB donor CU like IAB donor CU501 in Figure 5 (and source F1 donor CU703 in Figure 7).

[0141] The message CONFIGURATION UPDATE 833 is sent by RAN node DU831 to RAN node CU832 to indicate a configuration change in the RAN node (e.g., IAB nodes 570, 701) that embeds RAN node DU831. The CONFIGURATION UPDATE message 833 may also be sent by RAN node DU831 to indicate to RAN node CU832 the completion of the F1 setup procedure with target RAN node CU during DU migration of the RAN node embedding RAN node DU831. That is, it is a report of a new F1 connection between the second logical DU activated in the RAN node embedding RAN node DU831 (e.g., IAB node 701) and target F1 terminating the donor CU (e.g., target F1 terminating donor CU707). This message 833 may include an identifier for the target RAN node CU (e.g., target F1 donor CU707). Furthermore, it may include the identifier of the cell activated in the second logical DU of the RAN node embedding the RAN node DU831 (e.g., PCI and / or NCGI). Message 833 may additionally or alternatively include a mapping between the identifier of the cell controlled by the RAN node DU831 and the identifier of the cell activated in this second logical DU. For example, referring to Figure 7, message 833 is sent by the first logical DU entity 705 activated in the IAB node 701 to the source IAB donor CU703, indicating the completion of the F1 setup procedure toward the target IAB donor CU707. Optionally, along with the identifier of the cell activated in the second logical DU 706, optionally, a mapping between the identifier of the cell activated in the second logical DU 706 and the identifier of the cell controlled by the first logical DU 705 is also sent.This configuration update message 833 may include the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as defined in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU (e.g., target F1 donor CU707) that terminates the new F1 connection of the RAN node embedding RAN node DU831.

[0142] Message 833 may indicate the success or failure of the F1 setup procedure. If the F1 setup procedure fails (for example, the F1 connection cannot be set up), message 833 may also indicate the reason why the F1 connection setup failed.

[0143] RAN node CU832 may respond to or reply to the message CONFIGUTION ACKNOWLEDGE834 sent to RAN node DU831. For example, the flow in Figure 8d is modified to include the information elements described above, corresponding to the procedure GNB-DU Configuration Update described in TS 38.473 V17.2.0 Section 8.2.4. Message 833 corresponds to the message GNB-DU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 Section 9.2.1.7, and message 834 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 Section 9.2.1.8.

[0144] Message 833 is sent in accordance with the F1 setup procedure described with reference to Figure 8c and may be triggered by RAN node CU832 (using the procedure described with reference to Figure 8a) or by the RAN node embedding RAN node DU831, along with the selection of a target RAN node CU based on preconfiguration. Preconfiguration may occur, for example, in the network integration of the RAN node embedding RAN node DU831. For example, the F1 setup procedure may be triggered by RAN node CU832 (e.g., source IAB donor CU 703 / 501) or by the RAN node (IAB node 701 / 570) embedding RAN node DU831 (e.g., IAB-DU1 572), and it may be determined that RAN node DU831 is to be migrated to a target RAN node CU (e.g., target IAB donor CU 707 / 503).

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

[0146] This figure shows two RAN nodes, RAN node CUa901 and RAN node CUb902, which could be two of the IAB donor CUs CU501, 502, and 503 in Figure 5. In the example shown in Figure 7, RAN node CUa901 is the target F1 donor CU707, and RAN node CUb902 is the source F1 donor CU703.

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

[0148] RAN node CUb902 responds to RAN node CUa901 by sending the message CONFIGURATION ACKNOWLEDGE904.

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

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

[0151] This figure shows two RAN nodes, RAN node CUa911 and RAN node CUb912, which could be two of the IAB donor CUs shown in Figure 5: CU501, 502, and 503.

[0152] The message TRANSPORT MIGRATION REQUEST913 is sent by RAN node CUa911 to RAN node CUb912 to request the migration or release of traffic in the IAB topology controlled by RAN node CUb912. For example, referring to Figure 7, if MT704 of IAB node 701 is migrated to a non-F1 donor CU (not shown in Figure 7), source F1 donor CU703 may send TRANSPORT MIGRATION REQUEST913 to the non-F1 donor CU to request the release of traffic (e.g., F1 traffic) that has been migrated to the topology of the non-F1 donor CU (i.e., F1 traffic is routed from target F1 donor CU707 through the IAB topology managed by the non-F1 donor CU). Alternatively, if MT704 of IAB node 701 is migrated to a non-F1 donor CU (not shown in Figure 7), the target F1 donor CU 707 may send a TRANSPORT MIGRATION REQUEST 913 to the non-F1 donor CU to request the migration of traffic (e.g., F1 traffic) to the non-F1 donor CU's topology (i.e., F1 traffic is routed from the target F1 donor CU 707 through the IAB topology managed by the non-F1 donor CU).

[0153] RAN node CUb912 responds to the message TRANSPORT MIGRATION RESPONSE914 sent to RAN node CUa901, accepting or rejecting the request.

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

[0155] Figure 10a is a flowchart illustrating an exemplary method 1000 according to one or more embodiments of the present invention, which is performed at a source IAB donor CU for use in a migration process (or part of a migration process) in which a distributed unit DU of an IAB node is migrated from an IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1000 is for managing the DU migration of an IAB node to a target IAB topology at the source F1 termination donor CU of the IAB node. For example, in the IAB communication system described with reference to Figure 5, the source IAB donor CU performing Method 1000 may be an IAB donor CU 501 (e.g., the F1 termination donor CU of IAB node 570, which holds the F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by the IAB donor CU 501. The migration process may include migrating DU572 of IAB node 570 to IAB topology 5003 managed by IAB donor CU 503, which is the target IAB donor CU. Referring to Figure 7, the IAB node may also be IAB node 701, and the migration process may include migrating DU of IAB node 701 from source F1 donor CU 703 to target F1 donor CU 707. Method 1000 shown and described in reference to Figure 10a may be performed by software and / or hardware elements. The source IAB donor CU may be implemented within the communication device 400 shown and described in reference to Figure 4, and the method shown and described in reference to Figure 10a may be performed by one or more processing units, such as a central processing unit 411.

[0156] In step 1001, the source F1 terminal donor CU (e.g., donor CU 501 in Figure 5 (703 in Figure 7)) determines that the DU of the IAB node (e.g., IAB node 570 in Figure 5 (701 in Figure 7)) will be migrated from the source F1 donor CUs 501 and 703 to the target F1 donor CU (e.g., donor CU 503 in Figure 5 (707 in Figure 7)). For example, source F1 donor CUs 501 and 703 decide to migrate the DU of the IAB node (e.g., IAB node 570) toward the target F1 donor CU (e.g., donor CU 503). As another example, source F1 donor CUs 501 and 703 may also decide that the DU of IAB nodes 570 and 701 will be migrated in response to the determination that the migration of the MT of IAB nodes 570 and 701 toward a new parent IAB node (which may be a new IAB node or a new IAB donor DU). Other examples of triggers for determining when a DU is migrated are described above. Details on how source F1 donors CU501 and 703 determine target F1 donors CU503 and 707 are also described above.

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

[0158] Optionally, in step 1003, source F1 termination donor CUs 501 and 703 transmit identification information to IAB nodes 570 and 701 to identify target IAB donor CUs 503 and 707. This identification information may be the TNL addresses (i.e., IP addresses) of target IAB donor CUs 503 and 707. For example, source F1 termination donor CUs 501 and 703 transmit the addresses of the target F1 donor CUs for the new F1 connection to the IAB nodes to be migrated. If IAB-MT704 is being migrated to a non-F1 donor CU (sometimes referred to as an RRC donor CU), the identification information transmitted by source F1 termination donor CUs 501 and 703 may include the addresses of the non-F1 donor CUs (however, IAB node 701 may already possess this information).

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

[0160] For example, source F1 termination donor CU703 may send a handover request to target F1 donor CU707 requesting a handover from source F1 termination donor CU703 to target F1 donor CU707 of one or more user devices (UEs) (e.g., UE708) provided by IAB node 701, which may include information for identifying one or more target cells (e.g., candidate target cells) for each UE. The selection of target cells for a UE may be based on a measurement report provided by the UE (e.g., showing the signal intensity detected by the UE for one or more cells) or on a mapping between identifiers of target cells activated in a second logical DU and identifiers of source cells controlled by a first logical DU. For example, source F1 termination donor CU703 may, based on mapping information received from target F1 donor CU707 or IAB node 701, select one or more of the new cells activated in the second logical DU entity 706 as one or more candidate target cells for each of the one or more UEs provided by the IAB node. This mapping eliminates the need to wait for measurement reports from the UE to trigger the handover procedure. Upon receiving a handover acknowledgment from the target F1 donor CU707 indicating that the handover of one or more UEs has been accepted and identifying the target cell for each UE, the source F1 termination donor CU703 sends configuration information to the IAB node 701 for configuring each UE into its respective target cell. The handover acknowledgment from the target F1 donor CU707 may also include configuration information for configuring each UE into its respective target cell. For these steps, the handover procedure 730 described above may be executed.

[0161] After the handover of one or more UE708s to the target F1 donor CU707 is complete, the source F1 termination donor CU703 may send a request to the IAB node 701 to deactivate the first logical DU entity of the DU of the IAB node 701 (e.g., IAB-DU1 705). The request may be a deactivation request sent in the CONFIGURATION REQUEST message 803, or a removal request sent in the message 823.

[0162] After the handover of one or more UE708s to the target F1 donor CU707 is complete, when the mobile termination MT (e.g., IAB-MT704) of IAB node 701 is migrated to a non-F1 donor CU, the source F1 termination donor CU703 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU requesting traffic release for traffic related to IAB nodes routed through one or more paths in the IAB topology managed by the non-F1 donor CU.

[0163] Figure 10b is a flowchart illustrating an exemplary method 1010 to be performed in an IAB node (e.g., a mobile IAB node or mIAB node) for use in a migration process (or part of a migration process) according to one or more embodiments of the present invention. The migration process involves the migration of distributed units (DUs) of an IAB node from one IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1010 is for managing DU migration toward a target F1 termination donor CU at an IAB node. For example, in the IAB communication system shown and described in relation to Figure 5, the IAB node performing Method 1010 may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501 (e.g., the F1 termination donor CU of a mobile IAB node 570 that maintains an F1 connection with a mobile IAB node 570), where the IAB donor CU 501 is the source IAB donor CU. This migration process may include the migration of DU572 of IAB node 570 from IAB topology 5001 to IAB topology 5003 managed by target IAB donor CU503. In relation to Figure 7, the IAB node may also be a mobile IAB node 701, and the migration process may include the migration of DU of IAB node 701 from source F1 donor CU703 to target F1 donor CU707. Method 1010 shown in and described in reference to Figure 10b may be performed by software and / or hardware elements. The IAB node may be implemented in a communication device 400 shown in and described in reference to Figure 4, and the method shown in and described in reference to Figure 10b may be performed by one or more processing units such as a central processing unit 411.

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

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

[0166] IAB nodes 570 and 701 may identify or specify target F1 donor CUs 503 and 707 as a response to receiving an F1 connection establishment request (step 1017), and then send an F1 setup request to the identified target F1 donor CUs. IAB nodes 570 and 701 may also identify target F1 donor CUs 503 and 707 based on identification information for target F1 donor CUs 503 and 707 received from source F1 donor CUs 501 and 703 (e.g., the addresses of target F1 donor CUs 503 and 707 (TNL address / IP address)) (e.g., in a CONFIGURATION REQUEST 803 message or sent separately). If IAB-MT704 has been migrated to a non-F1 donor CU, the identification information received by the IAB node will include the address of the non-F1 donor CU, in which case the IAB node will identify the non-F1 donor CU as a target F1 donor CU. Alternatively, if the target F1 donor CU addresses are not received from source F1 donor CUs 501 and 703, and IAB-MT704 has been migrated to a non-F1 donor CU, IAB nodes 570 and 701 will identify target donor CUs 503 and 707 by considering the non-F1 donor CU as the target F1 donor CU (for example, after receiving an F1 connection establishment request). In this case, IAB node 701 can identify the address of the non-F1 donor CU as the target donor CU address because it was already notified of the target donor CU's address (TNL address / IP address) when IAB-MT704 was migrated to a non-F1 donor CU.

[0167] Optionally, in step 1012, IAB nodes 570 and 701 receive identification information from source F1 termination donor CUs 501 and 703 to identify target F1 donor CUs 503 and 707. This identification information may include the addresses (TNL addresses / IP addresses) of the target F1 termination donor CUs for the new F1 connection.

[0168] Alternatively (for example, instead of steps 1011 and 1012), although not shown in the diagram, IAB nodes 570 and 701 may trigger themselves to request a new F1 connection and identify a target F1 donor CU based on preconfiguration. That is, IAB nodes 570 and 701 may determine that a new F1 connection should be set up, identify the IAB donor CU to which the connection should be set up based on the preconfiguration information preconfigured on the IAB node, and then send an F1 setup request to the identified target IAB donor CU requesting the setup of the F1 connection. As a first example, the trigger condition may be that IAB node 570 or 701 detects one or more cells in the vicinity of the IAB node that have an identifier (NCGI) belonging to a list of preconfigured target donor CUs. In other words, IAB nodes 570 and 701 may determine that a new F1 connection should be established (for example, because the DU of IAB node 570 / 701 (e.g., 572) is being migrated) and identify the IAB donor CU to which the connection should be established, based on the detection of one or more nearby cells, or subsequently on the detection of cells associated with an IAB donor CU included in the pre-configured target IAB donor CU candidate list. As a second example, the trigger condition may be network integration, where the IAB-MT should establish the first F1 connection with a pre-configured donor CU after establishing the RRC connection (this depends on the physical location of the IAB node). In other words, IAB nodes 570 and 701 determine that a new F1 connection should be established during network integration and identify the IAB donor CU to which the F1 connection should be made, based on the pre-configured candidate donor CU list on the IAB node and the location of the IAB node.

[0169] Figure 10c shows exemplary steps performed on an IAB node (e.g., a mobile IAB node or mIAB node) to identify a target IAB donor CU according to one or more embodiments of the present invention. For example, step 1017 in Figure 10b may be performed by performing steps 1013-1015 in Figure 10c, which are collectively referred to as step 1016. In another manner in which IAB nodes 570, 701 determine on their own that a new F1 connection should be established without receiving a request for a new F1 connection, steps 1013-1015 may be performed on the IAB node to identify the IAB donor CU on which the connection should be established based on preconfiguration information.

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

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

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

[0173] Figure 10d is a flowchart of an exemplary method 1020 performed at a target IAB donor CU, used in a migration process (or part of a migration process) according to one or more embodiments to migrate a distributed unit (DU) of an IAB node from an IAB topology managed by a source IAB donor CU to another IAB topology managed by a target IAB donor CU. Method 1020 is for managing the DU migration of an IAB node to a target IAB topology managed by a target F1 termination donor CU. For example, referring to the IAB communication system shown and described in Figure 5, the target IAB donor CU performing method 1020 may be an IAB donor CU 503 controlling an IAB topology 5003. The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 controlled by an IAB donor CU 501. The migration process may include migrating DU572 of IAB node 570 from IAB topology 5001 to IAB topology 5003. Referring to Figure 7, the IAB node may be IAB node 701, and the migration process may include migrating DU of IAB node 701 from source F1 donor CU703 to target F1 donor CU707. Method 1020 shown in and described in reference to Figure 10d may be performed by software and / or hardware elements. The target IAB donor CU may be implemented in the communication device 400 shown in and described in reference to Figure 4, and the method shown in and described in reference to Figure 10d may be performed by one or more processing units such as a central processing unit 411.

[0174] In step 1021, the target IAB donor CU (e.g., IAB donor CU 503 in Figure 5 (707 in Figure 7)) receives an F1 setup request from the IAB node (e.g., IAB node 570 in Figure 5 (701 in Figure 7)) to establish an F1 connection between the target IAB donor CU and the IAB node. For example, the setup request may be the SETUP REQUEST 813 described above. The F1 setup request message sent from the IAB node may include identification information to identify the source F1 termination donor CU if the mobile termination (MT) of the IAB node has been migrated to a non-F1 donor CU, or identification information to identify the non-F1 donor CU (which may be referred to as an RRC donor CU). The F1 setup request message may also include information indicating the number of cells to be activated by the activation of a second logical DU at the IAB node, and / or information indicating that the request to establish an F1 connection is related to the migration of the DU at the IAB node. Optionally, the F1 setup request message may include an identifier for an active cell controlled by a first logical DU (e.g., PCI and / or NCGI) and / or an identifier for an active cell to which a mapping should be provided. The F1 setup request message may also optionally include a request for a mapping between the identifier for an active cell controlled by a first logical DU and the identifier for a cell to be activated (e.g., a cell in the second logical DU of the IAB node).

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

[0176] For example, target F1 donor CU707 may receive a handover request from source F1 termination donor CU703 requesting that source F1 termination donor CU703 hand over one or more user equipment (UEs) (e.g., UE708) provided by IAB node 701 to target F1 donor CU707. To identify target cells (e.g., candidate target cells) for each UE, target cell selection may be made based on mapping information or measurement reports provided by the UE (e.g., indications of signal strength detected by the UE for one or more cells). For example, source F1 termination donor CU703 may select one or more of the new cells activated in the second logical DU entity 706 as candidate target cells for each UE provided by the IAB node, based on mapping information received from target F1 donor CU707 or IAB node 701. This mapping eliminates the need to wait for measurement reports from the UE to trigger the handover procedure. If the target F1 donor CU707 determines that it can accept the handover of one or more UEs, it sends a handover response to the source F1 terminal donor CU703 that identifies the target cell for each UE. The handover response may also include configuration information for setting the target cell for each UE. For these steps, the handover procedure 730 described above may be executed.

[0177] If the handover of one or more UE708s to target F1 donor CU707 is complete and the mobile termination of IAB node 701 (e.g., IAB-MT704) has been migrated to a non-F1 donor CU, target F1 donor CU707 may send a traffic migration request (e.g., message 913) to the non-F1 donor CU requesting the migration of traffic associated with the IAB node. The traffic in question was routed through one or more paths in an IAB topology managed by a non-F1 donor CU.

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

[0179] The trigger for determining whether an IAB node's DU should be migrated may be triggered by an event. The specific event that triggers this determination is left to the implementation. For example, the DU migration decision may be based on a known (predefined) trajectory of the IAB node, where the IAB node's MT has migrated from a first IAB topology to a second IAB topology, and the source F1 donor CU indicates that the MT will subsequently migrate to a third IAB topology. In this case, the DU is migrated directly to the third IAB topology to avoid sending a signaling message regarding DU migration / UE handover to the second IAB topology. Another trigger event is when the processing load level at the source F1 donor CU is detected to exceed a predetermined threshold. In this case, DU migration is triggered, and the selection of the target F1 donor CU is based on the processing load of other donor CUs connected to the source F1 donor CU.

[0180] In other words, to summarize, the trigger events and decision processes for a source F1-terminated donor CU to perform migration of a mobile IAB-DU (mIAB-DU) may be left to the implementation. Furthermore, to enable flexible IAB network management, it should be permissible for mIAB-DUs to be migrated to a target F1-terminated donor CU different from the non-F1-terminated donor CU (also referred to as an RRC-terminated donor CU) that provides a jointly installed mobile IAB-MT (mIAB-MT).

[0181] Therefore, the IAB-DU of a mobile IAB node may be migrated to a different target F1-terminated donor CU than the non-F1-terminated donor CU that provides the jointly installed IAB-MT.

[0182] Next, if the F1 donor CU providing the mIAB-DU determines that the mIAB-DU migration should be performed, the F1 donor CU may request the mobile IAB node to activate the second logical DU provided by the target F1 donor CU.

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

[0184] Therefore, if a mobile IAB node receives a request from an F1 donor CU to set up a new F1 connection, it may perform the F1 setup procedure with the target F1 donor CU specified in the request. If no such instruction exists, the mobile IAB node may perform the F1 setup procedure with a non-F1 terminating donor CU.

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

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

[0187] Regarding the procedures for triggering, executing, and reporting F1 setup in DU migration, the following is observed: To trigger the DU migration of a mobile IAB node determined by the source F1 donor CU, the following information may be communicated to the mobile IAB node: - Instructions indicating that DU migration is required (mandatory). This means that the F1 setup procedure should be initiated for the target logical DU. - Identifier of the target F1 donor CU (optional). This information element is relevant when a DU is migrated to a different target F1 donor CU than the non-F1 donor CU that provides the jointly installed mobile IAB-MT. If no such instructions exist, the mobile IAB node should perform the F1 setup procedure for the non-F1 terminal donor CU.

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

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

[0190] Therefore, to the extent that it relates to the DU migration of a mobile IAB node, the F1 setup request sent to the target F1 donor CU should include instructions that explicitly indicate that the F1 setup relates to the DU migration of the mobile IAB node, and should include a list of PCIs in the source logical DU of the mobile IAB node.

[0191] To report the results of the F1 setup procedure for the purpose of DU migration of a mobile IAB node, the mobile IAB node may notify the source F1 donor CU of the following information: - Instructions for the success or failure of the F1 setup, and, in the case of failure, the reason for the failure. - The ID of the cell activated by the target F1 donor CU in the target logical DU. - Mapping between the ID of the cell activated in the target logical DU and the ID of the cell active in the source logical DU (optional information element). This mapping allows for limiting the measurement range that should be performed in the UE, potentially enabling handover without measurement reports from the UE. Since the gNB-CU configuration update procedure is considered appropriate for triggering F1 setup, the gNB-DU configuration update procedure is considered a suitable candidate as an existing F1AP procedure for reporting the results of F1 setup.

[0192] Therefore, it is proposed that the gNB-DU configuration update procedure can be used by a mobile IAB node to report the results of the F1 setup procedure to the source CU of a DU migration. It is also proposed that a mapping between the IDs of cells activated in the target logical DU and the IDs of cells active in the source logical DU be included as an optional information element in the reporting of the F1 setup results.

[0193] Regarding the provision of identification information to F1 donor CUs, the following is observed: When a mobile IAB node is DU-migrated to a target F1 donor CU different from the non-F1 donor CU of a jointly installed mobile IAB-MT, the identifier of the non-F1 donor CU and the UE XnAP ID of the mobile IAB-MT in that CU must be provided to the target F1 donor CU. These information elements enable the target F1 donor CU to perform transport migration management procedures for the non-F1 donor CU. Furthermore, if an mIAB-MT and a jointly installed mIAB-DU are integrated into different donor CUs during network integration, the UE XnAP ID assigned by the mIAB-MT's CU and its gNB-ID must be known by the mIAB-DU's CU.

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

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

[0196] If Option 1 is adopted, to maintain consistency, the mobile IAB node should provide the target F1 donor CU with identification information related to the non-F1 donor CU during DU migration. This provision may be performed by F1AP signaling, similar to that used during network integration.

[0197] Furthermore, mobile IAB nodes should also provide identification information related to the target non-F1 donor CU to the F1 donor CU during (sequential) MT migrations. In this case, the same F1AP signaling may be used.

[0198] To cover all the scenarios described above, the gNB-DU configuration update is suitable as an F1AP procedure because it can be triggered at any time.

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

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

[0201] In fact, this proposal is consistent with this description. Source non-F1 donor CUs (i.e., source donor CUs in mIAB-MT) pass their information to F1 donor CUs (i.e., donor CUs in mobile IAB-DU) via mIAB nodes, not directly.

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

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

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

[0205] In a claim, the term “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude the plural. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used to one's advantage.

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

[0207] Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that enables the transfer of computer programs from one location to another in accordance with a communication protocol, for example. Thus, computer-readable media may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described herein. Computer program products may include computer-readable media.

[0208] Such computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead focus on non-temporary tangible storage media. As for disks, here they include CDs (compact discs), laserdiscs, optical discs, DVDs (digital versatile discs), floppy disks (registered trademark), and Blu-ray discs, where a disk typically reproduces data magnetically, and a disc typically reproduces data optically using a laser. Combinations of the above are also included within the scope of computer-readable media.

Claims

1. A method for a source F1-terminated IAB donor central unit (CU) managing IAB nodes in an integrated access backhaul (IAB) communication system, When performing a migration process to migrate the distributed unit (DU) of the IAB node from the source F1-terminated IAB donor CU to the target F1-terminated IAB donor CU, the process includes sending a message to the first logical DU entity of the DU of the IAB node, which is a message intended to establish an F1 connection between the IAB node and the target F1-terminated IAB donor CU, and is addressed to the first logical DU entity of the DU of the IAB node. A method comprising the step of receiving cell identification information of one or more new cells activated in the second logical DU entity of the IAB node.

2. A step of transmitting identification information for identifying the target F1 terminal IAB donor CU to the IAB node, The method according to claim 1, further comprising:

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

4. The method according to claim 1, characterized in that the IAB node is a mobile IAB node.

5. The method according to claim 1, characterized in that the first logical DU entity is a logical DU entity having an F1 connection with the source F1 terminated IAB donor CU.

6. The step of receiving identification information from the target F1 terminal IAB donor CU or the IAB node, identifying each of the one or more new cells activated in the second logical DU entity of the IAB node. The method according to claim 5, further comprising:

7. The method according to claim 5, wherein the cell identification information is received as mapping information from the target F1 terminal IAB donor CU or from the IAB node, and the mapping information shows a mapping between the cell identification information of one or more new cells activated in the second logical DU entity of the IAB node and the cell identification information of one or more active cells controlled by the first logical DU entity of the DU of the IAB node.

8. Steps include sending a handover request to the target F1-terminated IAB donor CU for requesting a handover of one or more user equipment UEs serviced by the IAB node from the source F1-terminated IAB donor CU to the target F1-terminated IAB donor CU, and for identifying one or more candidate target cells for each UE. The method according to claim 7, further comprising:

9. The step of selecting one or more new cells as one or more candidate target cells for each of the one or more UEs that are served by the IAB node, based on the mapping information, The handover request includes information identifying one or more selected candidate target cells. The method according to claim 8.

10. The steps include receiving a handover acknowledgment from the target F1-terminal IAB donor CU indicating that the handover of one or more UEs has been accepted, and in response to identifying the target cell for each UE, transmitting configuration information for each of the one or more UEs to the IAB node for each target cell, The method according to claim 8, further comprising:

11. After the handover of one or more UEs to the target F1-terminated IAB donor CU is completed, the IAB node sends a request to deactivate the first logical DU entity of the DU of the IAB node having an F1 connection with the source F1-terminated IAB donor CU. The method according to claim 8, further comprising:

12. After the handover of one or more UEs to the target F1-terminating IAB donor CU is complete, if the mobile termination (MT) of the IAB node has been migrated to a non-F1 donor CU, the step of sending a traffic migration request to the non-F1 donor CU to request the release of traffic for traffic associated with the IAB node and routed through one or more paths in the IAB topology managed by the non-F1 donor CU, The method according to claim 8, further comprising:

13. The method according to claim 1, further comprising the step of determining whether the DU of the IAB node to be migrated from the IAB topology of the source F1-terminated IAB donor CU to another IAB topology managed by the target F1-terminated IAB donor CU should be migrated in response to determining that the migration of the MT of the IAB node to a new parent IAB node has been completed.

14. A method in an integrated access backhaul (IAB) communication system, in an IAB node managed by a source F1-terminated IAB donor central unit (CU), When the distributed unit (DU) of the IAB node performs a migration process to migrate from the source F1-terminated IAB donor CU to the target F1-terminated IAB donor CU, the DU of the IAB node receives a message from the source F1-terminated IAB donor CU addressed to the DU of the IAB node for establishing an F1 connection between the target F1-terminated IAB donor CU and the IAB node. The step of sending an F1 setup request message to the target F1 termination IAB donor CU to request the setup of the F1 connection, The method is characterized in that the F1 setup request message includes identification information for identifying an RRC-terminated IAB donor CU that is providing services to the mobile termination (MT) of the IAB node.

15. The message is received via a first logical DU entity of the IAB node, and the steps further include initiating a new target logical DU entity prior to the sending step, The method according to 14, characterized in that in the transmission step, the F1 setup request message is transmitted from the newly activated target logical DU entity to the target F1 termination IAB donor CU.

16. The further step is to identify the target F1 termination IAB donor CU after receiving the message for establishing an F1 connection, The transmission step is characterized in that the F1 setup request message is transmitted to the identified target F1 termination IAB donor CU. The method according to claim 15.

17. A step of receiving identification information from the source F1-terminated IAB donor CU for identifying the target F1-terminated IAB donor CU related to the F1 connection, The method according to claim 16, further comprising:

18. The steps of identifying the target F1-terminal IAB donor CU from the received identification information, in accordance with the fact that identification information for identifying the target F1-terminal IAB donor CU relating to the F1 connection has been received from the source F1-terminal IAB donor CU, The method according to claim 17, including the method described in claim 17.

19. The further step includes determining whether, after receiving the message for establishing the F1 connection, identification information identifying the target F1 termination IAB donor CU of the F1 connection has been received from the source F1 termination IAB donor CU, The transmission step includes, in response to determining that identification information for identifying the target F1 termination IAB donor CU related to the F1 connection has been received, transmitting the F1 setup request message to the target F1 termination IAB donor CU identified by the received identification information. The method according to claim 17.

20. The identification information for identifying the target F1-terminated IAB donor CU related to the F1 connection includes an address associated with the target F1-terminated IAB donor CU. The method according to claim 17.

21. The steps include: sending the F1 setup request message, receiving a response from the target F1 termination IAB donor CU that includes a request for one or more cells to be activated for the target logical DU entity; The steps of activating one or more of the cells based on the received response, The method according to claim 15, further comprising:

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

23. The step of transmitting identification information to the source F1 terminating IAB donor CU that identifies each of the one or more new cells activated in the target logical DU entity, The method of claim 22, further comprising:

24. The step of transmitting mapping information to the source F1 terminating IAB donor CU, showing a mapping between the identification information of one or more new cells activated in the target logical DU entity and the identification information of one or more active cells controlled by the first logical DU entity of the DU of the IAB node. The method of claim 22, further comprising:

25. The step of receiving a request from the source F1-terminated IAB donor CU to deactivate a first logical DU entity that constitutes the DU of the IAB node having an F1 connection with the source F1-terminated IAB donor CU, The method according to claim 14, further comprising:

26. Steps of deactivating the first logical DU entity in response to receiving the request to deactivate the first logical DU entity: The method according to claim 25, further comprising:

27. ​​The F1 setup request message includes identification information that identifies the source F1 termination IAB donor CU, The method according to claim 14.

28. The F1 setup request message is characterized in that it includes information indicating that it relates to the migration of the DU of the IAB node, The method according to claim 14.

29. The method according to claim 14, wherein the IAB node is a mobile IAB node.

30. Device for an Integrated Access Backhaul (IAB) node related to an IAB communication system, An apparatus comprising one or more processing units configured to perform the method described in any one of claims 14 to 29.

31. A device for an Integrated Access Backhaul (IAB) Donor Central Unit (CU) related to an IAB communication system, An apparatus comprising one or more processing units configured to perform the method described in any one of claims 1 to 13.

32. A program for causing a computer to perform the method described in any one of claims 1 to 13.

Images