Migration of nodes in IAB communication systems

Abstract

Methods and apparatus for managing transport migration of traffic associated with an integrated access backhaul (IAB) node are disclosed. The transport migration is to proceed after a distributed unit (DU) of the IAB node has migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU. The method includes, at a target IAB donor CU, receiving a notification including identification information for identifying an IAB donor CU of a mobile terminal (MT) serving an IAB node, the IAB donor CU of the MT serving the IAB node being a different IAB donor CU from the target IAB donor CU; based on the identification information and after the DU of the IAB node has migrated to the target IAB topology, a transport migration for migrating traffic associated with the IAB node is performed to route on at least one path between the target IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT. The target IAB donor CU may receive a notification from the source IAB donor CU, from the IAB node, or from the IAB donor CU serving the MT.

Description

Technical Field

[0001] The present invention generally relates to methods used in a process for migrating nodes and traffic between integrated access and backhaul (IAB) topologies (involving mobile IAB nodes) of a wireless communication system. In particular, the present invention relates to methods used in a migration process in which a distributed unit (DU) of an IAB node (e.g., a mobile IAB node) is migrated between IAB topologies, and to methods used in managing transport migration following DU migration of an IAB node. Background Art

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

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

[0004] Due to the increase in the number of users and higher throughput requirements, the demand for network densification increases.

[0005] Faced with the high deployment costs and time associated with wired backhaul networks for network densification, 3GPP has proposed wireless backhaul, also known as integrated access and backhaul (IAB), starting with Release 16 for 5G NR. In this approach, a portion of the wireless (i.e., radio) spectrum is used for backhaul connections to base stations, instead of optical fiber. Wireless backhaul communications (between base stations) can use the same radio resources as access communications (between base stations and UEs).

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

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

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

[0009] Furthermore, 3GPP has been considering inter-donor redundancy, in which an IAB node, known as a border IAB node, can access two different parent nodes connected to two different IAB donors, each of which manages a different IAB topology (also known as an IAB network). Thus, even though the border IAB node belongs to a single IAB topology (i.e., belongs to a single IAB donor for configuration and management), it can still 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 inter-donor redundancy is that the first IAB donor can offload some of its packets by routing them through the second IAB topology, thereby alleviating congestion or overcoming radio link failures that may occur in the first IAB topology.

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

[0011] A stationary IAB node should only require a single MT migration. In practice, a backhaul link (defined between two consecutive IAB nodes in a wireless backhaul) may experience radio failures due to fluctuations in radio conditions, and for an IAB node that does not move, this should be a temporary situation with possible link recovery after a period of time. Thus, such a stationary IAB node should not be required to undergo multiple MT migrations within the same IAB topology or towards another IAB topology, and the transmission and handling of multiple protocol messages can be avoided. For the same reason, migration of the distributed unit (DU) of the IAB node should not be required for a stationary node, thereby leaving control of the IAB node to the new IAB donor. Furthermore, note that such a DU migration, which may be referred to as a full migration, also involves the switching of the UE served by the migrating mobile IAB node.

[0012] Urban environments are typically characterized by a high density of users and the presence of a large number of vehicles (e.g., public / private passenger transportation, cargo delivery, food trucks, etc.). Some of these vehicles (e.g., buses, trams, or trains) may have predictable routes and a large number of collocated UEs (i.e., occupants' devices). 3GPP is considering that such vehicles may provide an opportunity to increase network coverage and connectivity to UEs inside the vehicle or even to UEs near the vehicle by installing onboard base stations (or base station elements) on these vehicles that will act as mobile repeaters. These mobile repeaters will rely on 5G wireless backhaul (typically IAB, or Integrated Access and Backhaul) for connection to fixed donor devices.

[0013] Thus, building on the fixed IAB foundation of Releases 16 and 17, 3GPP is now considering a mobile IAB system and architecture as part of the Release 18 framework to address scenarios focusing on mobile IAB nodes mounted on vehicles such as buses, trains, taxis, etc. In such scenarios, the mobile IAB nodes may be referred to as vehicle-mounted repeaters (VMRs), thereby providing 5G coverage / capacity to onboard and / or surrounding UEs.

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

[0015] For a mobile IAB node, performing multiple MT migrations or DU migrations may be desirable because a connection to a parent IAB node belonging to the first IAB topology may not reoccur for a long time as the mobile IAB node moves around, or may never reoccur if the mobile IAB node moves away from the parent IAB node. Furthermore, for flexible IAB network management, MT and DU migrations should be decoupled, meaning that DU migrations for an IAB node can occur independently before or after one or more MT migrations for that IAB node. Furthermore, DU migrations for an IAB node can occur to an IAB donor different from the IAB donor associated with the MT of the IAB node.

[0016] In particular, after an MT migration of an IAB node toward a first IAB donor, followed by a DU migration of the IAB node toward a second IAB donor different from the first IAB donor, the second IAB donor may have to request migration of traffic associated with the IAB node toward the IAB topology controlled by the first IAB donor.

[0017] Therefore, some new mechanism is needed to provide such flexibility by supporting DU migration of an IAB node towards any other IAB donor de-associated with MT migration(s) of the IAB node. Summary of the Invention

[0018] According to a first aspect of the present invention, a method for managing transport migration of traffic associated with an integrated access backhaul (IAB) node is provided. The transport migration is to be performed after a distributed unit (DU) of the IAB node has migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU. The method comprises, at the target IAB donor CU, receiving a notification including identification information for identifying an IAB donor CU of a mobile terminal (MT) serving the IAB node, the IAB donor CU serving the MT of the IAB node being an IAB donor CU different from the target IAB donor CU; and performing, based on the identification information and after the DU of the IAB node has migrated to the target IAB topology, transport migration for migrating traffic associated with the IAB node to be routed over at least one path between the target IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT.

[0019] If the mobile operator (MT) of the IAB node has not yet migrated from the source IAB donor CU, the IAB donor CU (e.g., RRC donor CU) serving the MT may be the source IAB donor CU. Alternatively, the IAB donor CU (e.g., non-F1 donor CU or RRC donor CU) serving the MT may be another IAB donor CU or a second IAB donor CU that manages the second IAB topology. In the latter case, the path between the target IAB donor CU and the MT of the IAB node passes through the second IAB topology.

[0020] The target IAB donor CU may receive notifications from the source IAB donor CU, from an IAB node (e.g., in an F1 setup request), or from the IAB donor CU serving the MT (e.g., in a transport migration ready message). The notification received from the source IAB donor CU may be received in a DU migration notification message (which may be sent by the source IAB donor CU before or after a DU migration). In another example, the notification received from the source IAB donor CU may be received in a configuration update message. The configuration update message may be sent by the source IAB donor CU at any time: for example, before or after a DU migration, when the source IAB donor CU detects a change in the IAB donor CU serving the MT. An advantage of being able to send a configuration update message at any time is that, if the source IAB donor CU has provided the target IAB donor CU with the address and / or identifier of an “old” IAB donor CU (the “old” IAB donor CU had previously served the MT of the IAB node and is now “old” because the MT has migrated to the “new” IAB donor CU), the source IAB donor CU can send an update via a configuration update message that includes identification information for identifying the new IAB donor CU.

[0021] According to a second aspect of the present invention, there is provided a method for managing a migration process at a source integrated access backhaul (IAB) donor central unit (CU) according to any one of claims 13 to 19 of the appended claims, the migration process being used to migrate a distributed unit (DU) of an IAB node from a source IAB topology managed by the source IAB donor CU to a target IAB topology managed by a target IAB donor CU.

[0022] According to a third aspect of the present invention, there is provided a method for migration processing performed at a source integrated access backhaul (IAB) donor central unit (CU) according to any one of claims 20 to 24 and claim 44 of the appended claims, the migration processing being used to migrate a distributed unit (DU) of an IAB node from a source IAB topology managed by the source IAB donor CU to a target IAB topology managed by a target IAB donor CU.

[0023] According to a fourth aspect of the present invention, there is provided a method for migration processing performed at an integrated access backhaul (IAB) node according to any one of claims 25 to 31 and claim 44 of the appended claims, the migration processing being used to migrate a distributed unit (DU) of the IAB node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU.

[0024] According to a fifth aspect of the present invention, there is provided a method for managing transmission migration of traffic related to an integrated access backhaul (IAB) node at a second integrated access backhaul (IAB) donor central unit (CU) according to any one of claims 32 to 39 and claim 44 of the appended claims, wherein the transmission migration is to be performed after a distributed unit (DU) of the IAB node has migrated from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU, and a mobile terminal (MT) of the IAB node has migrated to a second IAB donor CU, which is an IAB donor CU different from the target IAB donor CU and the source IAB donor CU.

[0025] According to a sixth aspect of the present invention, there is provided a method for migration processing performed at an integrated access backhaul (IAB) node according to any one of claims 40 to 44 of the appended claims, the migration processing being used to migrate a distributed unit (DU) of the IAB node from a source IAB topology managed by a source IAB donor central unit (CU) to a target IAB topology managed by a target IAB donor CU.

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

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

[0028] By sending a notification to the target IAB donor CU (the notification including identification information for identifying the IAB donor CU of the mobile terminal (MT) serving the IAB node), whether by the source IAB donor CU, the IAB node, or the IAB donor CU serving the MT, the target IAB donor CU is informed of the current IAB donor CU of the co-located MT serving the IAB node, which enables the target IAB donor CU to set up an IAB transmission migration towards the topology of the current IAB donor CU of the MT serving the IAB node.

[0029] Further exemplary features of the invention are described in the further independent and dependent claims.

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

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

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

[0033] Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more embodiments;

[0034] Figure 2 (a) and Figure 2 (b) schematically illustrates a stack of some protocol layers involved in IAB operation;

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

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

[0037] Figure 5 is a schematic diagram of an example IAB communication system (or IAB network system) in which embodiments and examples of embodiments of the present invention may be implemented;

[0038] Figure 6 is a schematic simplified diagram illustrating an example of an IAB node architecture that enables DU migration from a source IAB topology to a target IAB topology;

[0039] Figure 7 is a simplified diagram illustrating an example message flow for performing DU migration of an IAB node including handover of a UE served by the migrating IAB node according to one or more embodiments of the present invention;

[0040] Figure 8is a simplified diagram illustrating an example message flow for a target F1-terminating donor CU to identify a non-F1-terminating donor CU (or an RRC-terminating donor CU) for DU migration to an IAB node according to one or more embodiments of the present invention;

[0041] Figure 9a is a flowchart of an example method for managing, at a source F1-terminating donor CU of the IAB node, a DU migration of an IAB node to a target F1-terminating donor CU, the DU migration having an identification of a non-F1-terminating donor CU (or an RRC-terminating donor CU) according to an embodiment of the present invention;

[0042] Figure 9b is a flowchart of another example method for managing, at a source F1-terminating donor CU of the IAB node, a DU migration of an IAB node to a target F1-terminating donor CU, the DU migration having an identification of a non-F1-terminating donor CU (or an RRC-terminating donor CU) according to an embodiment of the present invention;

[0043] Figure 9c is a flowchart of an example method performed at an IAB node for making an F1 setup request to a target donor CU while identifying a non-F1 terminating donor CU (or an RRC terminating donor CU) according to one or more embodiments of the present invention;

[0044] Figure 9d is a flow chart of an example method for managing transport migration following DU migration of an IAB node at a target IAB donor CU according to an embodiment of the present invention;

[0045] Figure 10 is a simplified diagram illustrating another example message flow for a target F1-terminating donor CU to identify a non-F1-terminating donor CU (or an RRC-terminating donor CU) for DU migration to an IAB node according to one or more embodiments of the present invention;

[0046] Figure 11a is a flowchart of another example method for managing, at a source F1-terminating donor CU of the IAB node, a DU migration of an IAB node to a target F1-terminating donor CU, the DU migration having an identification of a non-F1-terminating donor CU (or an RRC-terminating donor CU) according to an embodiment of the present invention;

[0047] Figure 11b is a flowchart of an example method for managing transport migration of an IAB node in the case of DU migration at a non-F1 terminating donor CU (or RRC terminating donor CU) of the IAB node according to an embodiment of the present invention;

[0048] Figure 11cis a flowchart of another example method for managing transport migration of an IAB node in case of a DU migration of the IAB node at a target F1 terminating donor CU of the IAB node according to an embodiment of the present invention.

[0049] Figure 12a is a simplified diagram illustrating an example message flow of a process for activating a logical DU according to one or more embodiments of the present invention;

[0050] Figure 12b is a simplified diagram illustrating an example message flow for a process of setting up a logical DU;

[0051] Figure 12c is a simplified diagram illustrating an example message flow for a process to remove a logical DU;

[0052] Figure 12d is a simplified diagram illustrating an example message flow of a procedure used by a logical DU to inform a RAN node CU of a configuration change;

[0053] Figure 13a is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to report configuration information to another RAN node CU;

[0054] Figure 13b is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage transport migration in coordination with another RAN node CU;

[0055] Figure 14 is a flow chart of an example method for managing transport migration following DU migration of an IAB node at a target IAB donor CU according to an embodiment of the present invention. DETAILED DESCRIPTION

[0056] Figure 1 An example communication system 100 is illustrated, in particular, a mobile radio communication system such as a fifth generation (5G) new radio (NR) system that includes a wireless integrated access and backhaul network supporting (one or more) mobile IAB nodes. Although embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system in the following description, it will be understood that the present invention is not intended to be limited to a 5G NR system and can be used in any wireless communication system having a mobile base station. In particular, the following description primarily uses terminology specific to 5G, but it should be understood that such terminology also applies to elements or processes that perform equivalent functions in other communication systems.

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

[0058] The primary 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 embodiments and examples of embodiments of the present invention, the IAB donor 120 is a 5GNR gNB with additional functionality supporting the IAB feature, as defined in the 3GPP TS 38.300 v17.2.0 specification document.

[0059] To extend the network coverage of IAB donor 120 and reach remote UEs 132, 133, and 131, the operator installs IAB stations 121 and 122 (also referred to as IAB nodes 121 and 122). By acting as relay nodes between IAB donor 120 and UEs 132 and 133, IAB nodes 121 and 122 allow overcoming accessibility issues caused by the presence of building 108, which is an obstacle to the propagation of radio waves and, therefore, to direct attachment and further communication between the UEs and IAB donor 120. This is particularly true when the communication between IAB donor 120 and UEs 132 and 133 operates at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

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

[0061] The mobile IAB station 123 (also referred to as the mobile IAB node 123 or the mIAB node 123) is an IAB node mounted on the vehicle 105 and provides network coverage and capacity extension, thereby allowing the IAB donor 120 to reach onboard remote UEs (such as the remote UE 135), as well as surrounding UEs or UEs in the vicinity of the IAB node 123 (such as the remote UE 136).

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

[0063] The specifications for Integrated Access and Backhaul (IAB) expand upon several 3GPP standard documents, including:

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

[0065] -TS 38.321 MAC protocol (V17.2.0),

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

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

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

[0069] -TS 38.423Xn application protocol (V17.2.0),

[0070] -TS 38.473F1 application protocol (V17.2.0).

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

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

[0073] The IAB nodes, which may serve multiple radio sectors, are connected via one or more hop wireless backhauls through one or more intermediate IAB nodes to the IAB donor 120. They form a directed acyclic graph (DAG) topology with the IAB donor at the root.

[0074] Each IAB node consists of an IAB-DU (IAB Distributed Unit) and an IAB-MT (IAB Mobile Terminal). The gNB-DU functionality on an IAB node is also referred to as the IAB-DU and allows for downstream (towards the UE) connectivity to the next-hop IAB or to the UE. The IAB-MT functionality includes, for example, physical layer, layer 2, RRC, and non-access stratum (NAS) functionality to connect to the gNB-DU of an upstream IAB node (including the IAB donor 120, in this case, to the IAB donor gNB-DU and, therefore, to the core network 110 (e.g., for initialization, registration, and configuration).

[0075] In this DAG topology, neighbor nodes on the IAB-DU interface are called child nodes, and neighbor nodes on the IAB-MT interface are called parent nodes. The direction toward the child nodes is also called downstream, while the direction toward the parent node is called upstream.

[0076] The IAB donor 120 (eg, IAB donor CU) centrally manages resources, topology, and routing for the entire IAB topology, including configuring IAB nodes according to the network topology to, for example, perform appropriate routing of data packets.

[0077] Figure 2 (a) and Figure 2 (b) schematically illustrates a stack of some protocol layers involved in IAB operation.

[0078] The F1 interface supports the exchange of signaling information (eg, control traffic) between endpoints, and data transmission (eg, user traffic transmission) to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between endpoints.

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

[0080] In the user plane, block 210 at the IAB Donor CU and IAB Node DU refers to the GTP-U layer, and block 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. A GTP-U tunnel is used to carry encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for more details), here block 210 at 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 service and is suitable for use with the IP protocol.

[0081] In the control plane, block 210 indicates the F1AP (F1 Application Protocol) layer, and block 211 indicates the SCTP (Stream Control Transport Protocol) layer. The F1AP (as defined in 3GPP TS 38.473 and TS 38.401) provides signaling services between the IAB donor CU and the IAB node DU, or UE association services. These services include initialization and configuration. The well-known SCTP layer provides reliable, in-sequence delivery of messages with congestion control.

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

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

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

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

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

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

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

[0089] At the BAP sublayer, packets are routed based on a BAP routing ID, which is carried in the BAP header of the BAP packet and set by the originating IAB node (e.g., a network node in the IAB network that generates the BAP packet) or the BAP sublayer that transmits the IAB Donor DU. Figure 3 The format of a BAP data protocol data unit (PDU) or packet is illustrated. This format is specified in the standardized version of 3GPP TS 38.340 version 17.2.0, paragraph 6.2.

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

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

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

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

[0094] For example, when a BAP packet is generated by a node (i.e., an IAB donor DU for downstream transmission or an initiator (which may be an access IAB node in the case of an upper layer packet from a UE)), the node constructs a BAP header with a BAP routing ID according to the configuration table defined in 3GPP TS 38.340. This table is referred to as the downlink traffic to routing ID mapping configuration table in the IAB donor DU or the uplink traffic to routing ID mapping configuration table in the initiator IAB node. In the intermediate IAB nodes, the BAP header fields are already specified in the BAP packet for forwarding.

[0095] As described above, these configuration tables defining the BAP paths (and thus the routing policies and configuration of the IAB nodes taking into account the IAB network topology) are typically defined by the IAB donor CU and communicated to the IAB nodes to configure them.

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

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

[0098] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and, if necessary, packet integrity. Packets are numbered on the transmitter side and reordered on the receiver side. The PDCP sublayer is described in 3GPP TS 38.323.

[0099] The SDAP sublayer 220 of the user plane handles quality of service. TS 38.324 describes the SDAP sublayer. On the UE side, the SDAP sublayer exchanges payload data with user applications (voice, video, etc., not shown). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (Internet traffic, cloud, etc.).

[0100] The RRC sublayer 220 for the control plane handles the configuration of the protocol entities of the user plane protocol stack. The RRC sublayer is described in TS 38.331. The RRC sublayer is responsible for: broadcasting information required for UE communication with the cell; delivering paging messages; managing connections, including bearer establishment; mobility functions; measurement configuration and reporting; device capabilities; and other functions.

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

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

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

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

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

[0106] Figure 4 Schematic representations showing example communication apparatus (device) or stations according to one or more example embodiments of the present disclosure.

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

[0108] a central processing unit 411 , denoted CPU, such as a microprocessor or the like. The central processing unit 411 may be a single processing unit or processor, or may include two or more processing units or processors that perform the processing required for the operation of the communication device 400. The number of processors and the allocation of processing functions to the central processing unit 411 are a matter of design choice for the skilled person;

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

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

[0111] The donor CU, donor DU, IAB node, and UE may each be implemented in such a communication apparatus / device 400 .

[0112] The memory may include:

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

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

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

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

[0117] a disk drive 405 for a disk 406 , the disk drive being adapted to read data from the disk 406 or to write data onto said disk;

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

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

[0120] The disk 406 can optionally be replaced by any information medium (for example, a rewritable or non-rewritable compact disk (CD-ROM), a ZIP disk, a USB key or a memory card, etc.), and in general, by an information storage component that can be read by a microcomputer or a microprocessor, is integrated or not integrated into a communication device, may be removable, and is adapted to store one or more programs (the execution of which enables the method according to an embodiment of the invention to be carried out).

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

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

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

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

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

[0126] As described above, each IAB node includes a mobile terminal (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 includes an MT portion or unit 511 and a DU portion or unit 512.

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

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

[0129] The IAB topology 5003 includes an IAB donor CU 503 (in Figure 5 Donor3-CU) and its associated IAB donor DU 507 (identified as Donor3-CU in Figure 5 ), and an IAB node 560 similar to the IAB nodes 121 and 122 .

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

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

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

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

[0134] Each IAB-DU and IAB Donor DU supports a cell called (one or more than one) Figure 51 or more) coverage areas of a serving cell (not shown). In other words, each IAB-DU and IAB donor DU is associated with one or more cells. A wireless communication device (such as a UE or other IAB node) located within a cell can establish a communication link with a node (i.e., an IAB-DU or an IAB donor DU) of the serving cell to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the Internet, etc.) via the node.

[0135] Assume that the mobile IAB node 570 initially has a single parent IAB node 520, and the IAB node 570 belongs to the IAB topology 5001 controlled by the IAB donor CU 501. Therefore, the IAB donor CU is operating as an F1 termination donor CU (which may also be referred to as an F1 termination IAB donor CU or an F1 donor CU). When the mobile IAB node 570 moves, and given its proximity to the IAB topology 5002, particularly when the mobile IAB node 570 is in Figure 5 When the position shown by the dashed line is close to the IAB node 530, the mobile IAB node 570 can establish a wireless BH link with the IAB node 530. This BH link is possible for stationary IAB nodes and for example for nodes in the direction of the IAB topology 5002 (defined by Figure 5 A mobile IAB node (such as IAB node 570) moving on the same node as shown by arrow 590 in FIG. 5 is very likely to occur.

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

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

[0138] After being informed to use donor DU 506 instead of donor DU 505 to route F1 traffic associated with IAB node 570, donor CU 501 can request that traffic associated with IAB node 570 be migrated toward IAB topology 5002. In this case, donor CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 Section 8.5.2.

[0139] While moving further (this time in the direction of the IAB topology 5003 controlled by donor CU 503), IAB node 570 may be in a position where the backhaul link 5060 with IAB node 560 may have better quality than the backhaul link 5050 with IAB node 550. Therefore, donor CU 502 may apply the inter-CU topology adaptation procedure described in TS 38.401 V17.2.0, Section 8.17.3.1 or Section 8.17.3.2. After this continuous MT migration, IAB node 501 still belongs to the IAB topology 5001, its F1 connection is with donor CU 501, but its RRC connection is now with donor CU 503, so donor CU 503 becomes a non-F1 terminating donor CU (or RRC terminating donor CU). However, donor CU 501 must be informed of the new donor DU 507 and the new non-F1 donor CU 503 for IAB node 570 to redirect the offloaded traffic (F1 traffic, control traffic, and user traffic) through donor DU 507 instead of donor DU 506 .

[0140] In all the above MT migration scenarios, the UE 580 is still connected to the donor CU 501 through the DU portion or unit 572 of the mobile IAB node 570. In the case where the IAB node 570 has some (one or more than one) child IAB nodes, such child IAB nodes still belong to the IAB topology 5001 and are still fully controlled by the donor CU 501 (through the F1 connection and the RRC connection).

[0141] In any migration state of the MT portion 571 of the IAB node 570, and therefore regardless of whether the MT portion 571 of the IAB node 570 has been migrated to the IAB topology 5002 or the IAB topology 5003, and therefore regardless of whether the IAB node 570 has a non-F1 termination donor CU and, if so, whether the non-F1 termination donor CU is the non-F1 termination donor CU 502 or 503, the F1 donor CU 501 may decide to perform a migration of the DU portion of the IAB node 570. The reason for performing a DU migration may be to reduce the processing load at the F1 donor CU 501, or because the IAB node 570 is geographically far away from the F1 donor CU 501 and is close to an area where Xn connectivity no longer exists between the F1 donor CU 501 and the target donor CU. After deciding to perform DU migration of the IAB node 570, the F1 donor CU 501 must also decide which donor CU (referred to as the target F1 donor CU) to which the DU migration should be performed. The DU migration can be a DU migration toward the current non-F1 termination donor CU (i.e., the default selection) (if there is a current non-F1 termination donor CU and in this case the non-F1 termination donor CU becomes the target F1 donor CU), or the DU migration can be a DU migration to another target F1 donor CU. For example, if the IAB node 570 is mobile and its trajectory is predictable (e.g., for a bus or train), the F1 donor CU 501 can know a suitable target F1 donor CU for controlling the cell through which the IAB node 570 will soon connect to the network. For example, when the non-F1 terminating 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 directed directly to donor CU 503 because IAB node 570 can quickly traverse without remaining in the IAB topology 5002 controlled by donor CU 502. By not performing the DU migration to donor CU 502 but instead performing the DU migration to donor CU 503, protocol messages for the intermediate DU migration of IAB node 570 are avoided. When the DU migration is performed, a handover of the UE served by IAB node 570 must also be performed. Therefore, not performing the DU migration to donor CU 502 also avoids an intermediate handover of the UE served by IAB node 570 to donor CU 502 before the new DU migration to donor CU 503 and the UE handover.

[0142] The process to perform DU migration and UE handover towards the selected target F1 donor CU is described in more detail with reference to subsequent figures.

[0143] Figure 6An example of an IAB node architecture 600 is illustrated, which enables migration of DUs of an IAB node from a source IAB topology to a target IAB topology (DU migration).

[0144] IAB node 601 (which may be a mobile IAB node such as IAB node 570) is composed of an IAB-MT part or unit IAB-MT 610 (such as Figure 5 571 of the IAB node 570), a part or unit IAB-DU1 611, and a part or unit IAB-DU2 612. IAB-DU1 and IAB-DU2 are two logical DU entities (also referred to as logical DUs) that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. Upon DU migration of the IAB node 601, both logical DUs are active: one logical DU terminates with the source F1 donor CU (e.g., the source F1 donor CU). Figure 5 The F1 interface of the donor CU 501 in the example is terminated by another logical DU, while the F1 interface of the target F1 donor CU (e.g. Figure 5 Otherwise (i.e. when no DU migration is performed), only one logical DU is sufficient for IAB operation. Figure 5In an IAB communication system, the F1 terminating donor CU of the IAB node 601 (i.e., the IAB node 570) may be the donor CU 501, which thus operates as a source F1 donor CU. When the source F1 donor CU 501 determines that the IAB node 570 is moving toward / through the IAB topology 5002, the source F1 donor CU 501 may identify the IAB donor CU 502 as a suitable target F1 donor CU. The IAB topology 5002 includes network nodes managed by the IAB donor CU 502 (e.g., IAB donor DUs 505, 506, IAB nodes 530, 540, 550), which serve cells in the IAB topology 5002 to which the IAB node 570 will soon connect. Alternatively, for an IAB node that is connected to a parent IAB node or a parent IAB donor DU of the IAB topology 5001 managed by the donor CU 501 as an F1 terminating donor CU and is stationary but close to or near one or more IAB nodes in a neighboring IAB topology (such as the IAB topology 5002), when the source F1 donor CU 501 determines (for example, based on signal measurements at the IAB node of radio signals received at the IAB node from all IAB nodes close to the IAB node and which may include IAB nodes in the neighboring IAB topology 5002) that the IAB node may soon be connected to an IAB node in the neighboring IAB topology 5002, the source F1 donor CU 501 may determine that the IAB donor CU 502 is a suitable target F1 donor CU.

[0145] Before DU migration, UE 602 (e.g. Figure 5 For example, the UE 580 is connected to the source F1 donor CU 501 through the logical DU IAB-DU1 611 using the access link 621 in the cell served by the logical DU IAB-DU1 611, and the logical DU IAB-DU2 612 is deactivated. During DU migration, the logical DU IAB-DU2 612 is activated and connected to the target F1 donor CU 502. The UE 602 can also be connected to the target F1 donor CU 502 through the logical DU IAB-DU2 612 using the link 622 in the cell served by the logical DU IAB-DU2 612. The activation of the logical DU IAB-DU2 612 can be triggered by the source F1 donor CU and is activated using the reference DU IAB-DU2 612. Figure 12a and Figure 12bOnce the handover of UE 602 from the cell controlled by logical DU IAB-DU1 611 to the cell controlled by logical DU IAB-DU2 612 is completed, logical DU IAB-DU1 611 may be deactivated. After detecting the handover completion of all UEs served by IAB-DU1 611, the source F1 donor CU 501 may utilize the reference Figure 12c Describes the process to trigger deactivation.

[0146] An example of a method according to one or more embodiments of the present invention will now be described, which example of the method enables DU migration of an IAB node with or without (multiple) MT migrations, and includes notifying the IAB node of the identity of the target donor CU to enable handover of the UE served by the IAB node to the target donor CU. Although the following method / apparatus will be described primarily with respect to mobile IAB nodes, it will be understood that the present invention is not intended to be limited to mobile IAB nodes. The method according to one or more embodiments of the present invention can be applied to, for example, a stationary IAB node at the edge of an IAB topology and close to or in the vicinity of one or more IAB nodes in a neighboring IAB topology.

[0147] Figure 7 is a schematic simplified diagram 700 illustrating some example message flows for DU migration of an IAB node with or without MT migration(s) according to one or more embodiments of the present invention, and the DU migration includes the setup of (one or more) data paths for packet routing between a target F1 donor CU and the IAB node through an IAB topology controlled by a non-F1 donor CU (or RRC donor CU) of the IAB node.

[0148] Should Figure 7 708 such as UE 580, a source F1 donor CU 703 such as donor CU 501, a target F1 donor CU 707 such as donor CU 503, a non-F1 / RRC donor CU 709, Figure 1 The core network (5GC) 702 of the core network 110. Figure 7Also shown is an IAB node 701, which may be a mobile IAB node, such as IAB node 570, consisting of a mobile equipment (MT) portion or unit IAB-MT 704, a DU portion or unit IAB-DU1 705 (e.g., a source or first logical DU entity or DU), and a DU portion or unit IAB-DU2 706 (e.g., a target or second logical DU entity or DU). The first logical DU entity 705 and the second logical DU entity 706 each serve one or more cells, each of which is identified by an identifier (e.g., a physical cell identifier (PCI) or a new radio cell group identifier (NCGI)). The cell(s) of IAB-DU1 705 are identified by different values ​​for the identifiers (e.g., a physical cell identifier (PCI) or a new radio cell group identifier (NCGI)) than the values ​​for the cell(s) of IAB-DU2 706. IAB-DU1 705 and IAB-DU2 706 are two logical DU entities that share the same hardware for the BAP, RLC, and MAC layers. In one example, they share the same physical layer (i.e., the same hardware resources), while in another example, they rely on separate physical layers. If the IAB-MT 704 has not been migrated, the non-F1 donor CU 709 for the IAB node 701 can be the source F1 donor CU 703 itself (e.g., donor CU 501). If the IAB-MT 704 was previously migrated toward the target F1 donor CU 707, the non-F1 donor CU for the IAB node 701 can be the target F1 donor CU 707 (e.g., donor CU 703), or if the IAB-MT 704 was previously migrated toward another donor CU (e.g., donor CU 502), the non-F1 donor CU for the IAB node 701 can be that other donor CU (e.g., donor CU 502).

[0149] At the start of the process, the IAB node 701 belongs to the source IAB topology controlled by the source F1 donor CU 703. The UE 708 is served by the IAB node 701 via the cell of IAB-DU1 705 (e.g., the DU of the IAB node 701 has an active IAB-DU1 705, which has an F1 connection with the source F1 IAB donor CU 703), while the logical IAB-DU2 706 is inactive. User data in the downstream direction is provided by the 5GC 702 to the source F1 donor CU 703 via bearer 710, and then the data is transmitted to the logical DU IAB-DU1 705 of the IAB node 701 via the backhaul bearer 711, and finally transmitted to the UE 708 via the data radio bearer 712. Backhaul bearer 711 can be established in the source IAB topology controlled by source F1 donor CU 703, or in the IAB topology controlled by non-F1 donor CU 709 of IAB node 701 (if IAB-MT 704 has previously migrated to this non-F1 donor CU). User data in the upstream direction (not shown) is transmitted via similar bearers in the reverse direction.

[0150] As a result of periodic measurements performed by the IAB-MT 704 on signals received from the serving cell and one or more target cells (such as signal synchronization blocks (SSBs) transmitted in the serving cell and the target cells), the IAB-MT 704 may send a measurement report ( Figure 7 Not shown). If the MT has not migrated from its F1-terminating donor CU, the non-F1-terminating donor CU will be the F1-terminating donor CU for the IAB node (e.g., source F1 donor CU 703). The target cell may be a serving cell or a neighboring cell of the source cell (i.e., the current serving cell). Once the IAB-MT 704 finds at least one SSB that meets predefined criteria (e.g., a received power exceeding a predefined threshold), a measurement report may be generated and transmitted to provide radio link quality information for different cells in the vicinity of the IAB node 701. The identities of the various cells are included in the measurement report to allow the non-F1 donor CU (if the IAB-MT 704 has migrated) or the F1-terminating donor CU 703 (if the IAB-MT 704 has not migrated) to identify the target donor CU associated with the cell. In practice, the identity of the donor CU can be derived from the physical cell identity (PCI) broadcast in synchronization signals in each cell managed by the donor CU and / or from the new radio cell group identifier (NCGI) also broadcast in system information block (SIB) messages in each cell managed by the donor CU. The PCI and / or NCGI can be reported by the IAB node 701 in the measurement report.

[0151] Based on the received measurement report, the non-F1 donor CU 709 (if the IAB-MT 704 has migrated) or the F1 terminating donor CU 703 (if the IAB-MT 704 has not migrated) can detect that the IAB node 701 is receiving radio signals with better quality in the target cell of the target parent IAB node than in the source serving cell. The non-F1 donor CU 709 (if the IAB-MT 704 has migrated) or the F1 terminating donor CU 703 (if the IAB-MT 704 has not migrated) can decide to apply the procedure for migrating the IAB-MT 704 to a target parent IAB node belonging to the same IAB topology (intra-CU topology adaptation) or to another IAB topology (inter-CU topology adaptation). In any case, if the IAB-MT 704 has migrated, the source F1 donor CU 703 will be informed of the MT migration by the non-F1 donor CU 709, or if the IAB-MT 704 has not migrated, the source F1 donor CU 703 will be informed because it made the decision to perform MT migration directly based on the measurement reports received from the IAB node 701, and this information can be used by the source F1 donor CU 703 to trigger DU migration of the IAB node 701. In another example, the non-F1 donor CU 709 can relay the information in the measurement reports received from the IAB node 701 to the source F1 donor CU 703. Therefore, the source F1 donor CU 703 can decide on DU migration of the IAB node 701 directly based on these measurement reports relayed by the non-F1 donor CU 709.

[0152] Therefore, the source F1 donor CU 703 determines that the DU, which is an IAB node, is to be migrated from the IAB topology of the source F1 donor CU 703 (also referred to as the source IAB topology) to another IAB topology of the target IAB donor CU (also referred to as the target IAB topology). This determination may be based on determining that the migration of the mobile equipment (MT) of the IAB node to the new parent IAB node has been completed. Another example of a triggering event for determining that the DU, which is an IAB node, is to be migrated may include: the decision to migrate the DU may be based on detecting the migration of the MT from one IAB topology (e.g., the first IAB topology) to another IAB topology (e.g., the second IAB topology), and based on a known (predefined) trajectory indicating to the source F1 donor CU that the MT will later migrate to an IAB node of another IAB topology (e.g., the third IAB topology). In this case, to avoid the signaling messages used for DU migration / UE handover to the other IAB topology (e.g., the second IAB topology), the DU is directly migrated to the other IAB topology (e.g., the third IAB topology). Another example of a triggering event for determining that a DU of an IAB node is to be migrated may include detecting a processing load level above a predefined threshold in the source F1 donor CU. DU migration is then triggered, and a target F1 donor CU is selected based on the processing load of other donor CUs connected to the source F1 donor CU.

[0153] When the source F1 donor CU 703 decides or determines to perform a DU migration of the IAB node 701 toward another IAB topology managed by another donor CU that becomes the target F1 donor CU 707, the first step 720 corresponds to sending a request to the IAB node 701 to establish a new F1 connection between the target F1 donor CU 707 and the mobile IAB node 701. This may require activating the second logical IAB-DU2 706 in the mobile IAB node 701, so the first step 720 may include activating the second logical DU IAB-DU2 706 in the mobile IAB node 701. Using, for example, reference Figure 12a and Figure 12b Specifically, the message (e.g., Figure 12aThe activation request 1203 may include identification information for identifying the target donor CU (such as the TNL address (i.e., IP address) of the target F1 donor CU 707), so that a new F1 connection or F1 association (e.g., F1AP interface connection) can be set up with the target donor CU 707 (between the IAB-DU2 706 and the target donor CU 707). If the address of the target F1 donor CU is not included in the activation request, then by default, and in the case where the IAB-MT 704 has migrated to the non-F1 donor CU 709, the non-F1 donor CU 709 is considered to be the target F1 donor CU. In this case, when the IAB-MT 704 migrates to the non-F1 donor CU 709, the IAB node 701 is already informed of the identity of the target F1 donor CU (e.g., TNL address / IP address). In other words, if the IAB-MT 704 has been migrated to a non-F1 donor CU 709 that is different from (i.e., not the same as) the target F1 donor CU 707, the source F1 donor CU 703 may send identification information for identifying the target F1 donor CU. Alternatively, the source F1 donor CU 703 may send identification information for identifying the non-F1 donor CU 709 as the target IAB donor CU.

[0154] After determining that the DU of the IAB node 701 is to be migrated and once the IAB-DU2 706 has been activated, the IAB-DU2 706 may send an F1 setup request message (e.g., Figure 12b 1213 in TS 38.423 V17.2.0) for requesting to set up an F1 connection between the IAB node 701 and the target F1 donor CU 707. The message may include identification information for identifying the source IAB donor CU, such as the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID (Global NG-RAN NodeID) as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the source F1 donor CU 703 of the IAB node 701. The destination address of the F1 setup request message is the target F1 donor CU 707, and when the donor DU receives the IP packet in the F1 path for the IAB node 701, the IP packet may be sent to the target F1 donor CU 707 in the wired backhaul ( Figure 5 508) is routed to the target F1 donor CU 707. For example, when the IAB node 701 is connected to the IAB node 550 via the backhaul link 5050 Figure 5 IAB node 570, MT of IAB node 570 (corresponding to Figure 7In the example where the MT 571 of the IAB-MT 704 in FIG. 5 has been migrated to the non-F1 donor CU 502 and the IAB donor CU 501 is the source F1 donor CU, the F1 path between the F1 donor CU 501 and the IAB node 570 uses the donor DU 506. In the case where the IAB donor CU 503 has been identified (by the F1 donor CU 501) as the target F1 donor CU (e.g., the target F1 donor CU 707), the F1 setup request message for the target F1 donor CU (e.g., the donor CU 503) is sent through the IAB nodes 550, 540 and then sent to the donor DU 506, from which the F1 setup request message can be sent over the wired backhaul ( Figure 5 The message is routed to the target F1 donor CU 503 in 508 of FIG. 504. In F1, a response is set (e.g., Figure 12b 1214 in the example), the target F1 donor CU 707 (e.g., Figure 5 The donor CU 503 in the example depicted can request the IAB-DU 2706 to activate new cell(s) with associated identifiers (PCI, NCGI). Typically, a DU activates / deactivates a cell(s) under the control of the donor CU, which is controlling the DU. See, for example, TS 38.473, Section 8.2.3.2.

[0155] In reference Figure 12b Following the described process, and using e.g. reference Figure 13a Following the described process, the target F1 donor CU 707 may inform the source F1 donor CU 703 (eg, in a configuration update message 1303 ) of the activation of the new cell(s) from the IAB node 701 by the IAB-DU2 706 .

[0156] The next step 730 is to connect the UE (eg, Figure 71 705) from the cell(s) of the first logical DU IAB-DU1 705 to the cell(s) of the second logical DU IAB-DU2 706. The procedure may be a standardized procedure (handover) described in Section 9.2.3.2 of TS 38.300 or a standardized procedure (conditional handover) described in Section 9.2.3.4 of TS 38.300. In the example, to trigger the handover of the UE 708, the source F1 donor CU 703 sends a HANDOVER REQUEST message to the target F1 donor CU 707. The HANDOVER REQUEST message includes necessary information related to the UE 708 to be handed over (e.g., identification information for identifying the UE, UE context information (such as security context (e.g., security parameters such as security keys, UE security capabilities, etc.), measurement configuration, radio configuration (e.g., UE radio capabilities), information related to the bearer, etc.). TS 38.423 Section 9.1.1.1 provides details on the contents of the HANDOVER REQUEST message. After the target F1 donor CU 707 determines whether the donor CU can accept the handover of the UE 708, if the target F1 donor CU 707 accepts the request, the target F1 donor CU 707 sends a HANDOVER CONFIRM message to the source F1 donor CU 703. The HANDOVER CONFIRM message includes configuration information for the UE 708 to be handed over. The configuration may include radio configuration information indicating the radio configuration (e.g., the radio configuration may include frequency, radio bearer configuration, etc.) to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 in the identified target cell of the second logical DU IAB-DU2 706 of the IAB node 701. The HANDOVER CONFIRM may include the identifiers of one or more new cells (e.g., target cell(s)) that have been activated at the second logical DU IAB-DU2 706. The source F1 donor CU 703 then sends this configuration information in an RRC reconfiguration message to the UE 708 via the IAB node 701, including the identifier of the target cell of the IAB-DU2 706 to which the UE 708 is to connect. The RRC reconfiguration message (specified in TS 38.331) is embedded in the F1 message DL RRCMESSAGE TRANSFER (specified in TS 38.473), sent to the IAB-DU1 705, and relayed by the IAB-DU1 705 to the UE 708.Upon receiving the configuration information, UE 708 performs a random access procedure in the target cell indicated by IAB-DU2 706 to obtain uplink resources, and then transmits an RRC Reconfiguration Complete message to the target F1 donor CU 707. The RRC Reconfiguration Complete message (specified in TS 38.331) is sent to IAB-DU2 706 and then embedded in an F1 message UL RRC MESSAGE TRANSFER (specified in TS 38.473) and sent to the target F1 donor CU 707. The completion of the handover for UE 708 may be notified to the source F1 donor CU 703 via a HANDOVER SUCCESS message (specified in TS 38.423) received from the target F1 donor CU 707.

[0157] Once the handover of all UEs served by IAB-DU1 705 of IAB node 701 is completed, the source F1 donor CU 703 can Figure 12c The described process deactivates the logical DU IAB-DU1 705 of the mobile IAB node 701. This is usually done by Figure 7 Process 735 is shown in FIG.

[0158] In addition, the source F1 donor CU 705 may release traffic (user traffic, control traffic) associated with the UE served by the IAB node 701 through the IAB-DU1 705 and the source F1 donor CU 705. If traffic is offloaded in an IAB topology controlled by a non-F1 donor CU 709 (e.g., when the MT of the IAB node 701 migrates to the non-F1 donor CU 709), the source F1 donor CU 705 may apply the reference Figure 13b The process described is to request the release of traffic to a non-F1 donor CU 709. This is typically done by Figure 7 Process 735 is shown in FIG.

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

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

[0161] In order to request traffic migration to the donor CU of the IAB node 701 (such as the non-F1 donor CU 709 if the MT has migrated, or the F1 donor CU 703 if the MT has not migrated) when the target F1 donor CU 707 is different from (i.e., not the same donor CU as) the F1 donor CU of the IAB node (e.g., the non-F1 donor CU 709), the target F1 donor CU 707 needs to be able to identify the non-F1 donor CU 709.

[0162] Figure 14 1 is a flow chart illustrating an example method 1400 for use in transport migration of traffic associated with an IAB node at a target IAB donor CU according to one or more embodiments of the present invention. The transport migration is performed after the DUs of the IAB node have been migrated from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU. The method 1400 may be performed as part of a DU migration process for migrating the DUs of the IAB node. For example, referring to Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the source IAB donor CU performing the method 1400 may be the IAB donor CU 501 (e.g., the F1 termination donor CU of the IAB node 570, wherein the IAB node 570 maintains an F1 connection with the F1 termination donor CU). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (e.g., a source IAB topology) controlled by the IAB donor CU 501 (e.g., a source F1 IAB donor CU). The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003 (e.g., a target IAB topology) managed by the IAB donor CU 503 serving as the target IAB donor CU. Figure 14As shown in and about Figure 14 The described method 1400 may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 14 As shown in and about Figure 14 The described method is implemented by a device for a target IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0163] In short, at step 1402, the target IAB donor CU 503 receives a notification including identification information for identifying the IAB donor CU serving the MT of the IAB node 570 (e.g., an MT (such as MT 571) co-located with the DU of the IAB node (such as DU 572)). The IAB donor CU serving the MT of the IAB node is an IAB donor CU different from the target IAB donor CU. When the MT of the IAB node 570 has not yet migrated from the source IAB donor CU, the IAB donor CU serving the MT of the IAB node 570 may be the source IAB donor CU (e.g., the source F1 IAB donor CU such as IAB donor CU 501 is a non-F1 IAB donor CU). Alternatively, when the MT of the IAB node 570 has migrated to a second IAB donor CU (such as the IAB donor CU 502), the IAB donor CU serving the MT of the IAB node 570 may be another or second IAB donor CU (e.g., a non-F1 IAB donor CU or an RRC IAB donor CU such as the IAB donor CU 502). Regardless of whether the non-F1 IAB donor CU for the migrated MT of the IAB node 570 is the source F1 donor CU 501 or the non-F1 IAB donor CU 502, in either case, the target IAB donor CU is a different IAB donor CU 503.

[0164] As will be referenced below Figure 8 、 Figures 9a to 9d As discussed in more detail, the target IAB donor CU 503 may receive a notification from the source IAB donor CU 501, such as in a DU migration notification including identification information or in a configuration update notification including identification information, or may receive a notification from the IAB node 570, such as in an F1 setup request including identification information. The DU migration notification sent by the source IAB donor CU 501 may be as described below with reference to Figure 8 as well as Figure 9a and Figure 9d The configuration update notification sent by the source IAB donor CU 501 may be as follows: Figure 8 as well as Figure 9a and Figure 9d The configuration update notification message 817 discussed. The F1 setup request sent by the IAB node 570 may be as follows: Figure 8 as well as Figure 9b 、 Figure 9c and Figure 9d The F1 setup request message 814 in question. The F1 setup request is sent by the IAB node after receiving a request from the source IAB donor CU 501 for establishing an F1 connection (e.g., a new F1 connection) and for informing the target IAB donor CU of the identity of the IAB donor CU that serves the MT of the IAB node. The request from the source IAB donor CU 501 may be sent in a DU activation request 813. The request from the source IAB donor CU 501 may indicate (explicitly or implicitly) to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU that serves the MT of the IAB node. For example, the request from the source IAB donor CU 501 may include information for indicating to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU that serves the MT. As described below with respect to Figure 12a As discussed above with respect to configuration request message 1203, the information may include an information element (IE) for indicating that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU serving the MT of the IAB node. The presence of the IE in the request for establishing the F1 connection may indicate to the IAB node that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU, or, when the IE has a certain value (e.g., the IE may be a single bit and the certain value may be "1" or "0"), may indicate to the IAB node that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU. In another example, the information may include identification information for identifying the IAB donor CU serving the MT of the IAB node 570, and the presence of this identification information in the request itself may indicate to the IAB node that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU.

[0165] As will be referenced below Figure 10 、 Figures 11a to 11cAs discussed in more detail, when the IAB donor CU of the MT serving the IAB node 570 is another IAB donor CU that manages another IAB topology (e.g., the MT has migrated to another IAB donor CU, such as the second IAB donor CU 502 that manages the second IAB topology 5002), the target IAB donor CU 503 may receive a notification from the second IAB donor CU 502 (e.g., a non-F1 donor CU or an RRC donor CU). In this case, the notification may be sent in a transport migration ready notification including identification information, such as described below with reference to FIG. Figure 10 and Figures 11a to 11c The notification is sent in the transport migration ready message 1013 in question.

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

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

[0168] At step 1404, the target IAB donor CU 503 then performs transport migration for migrating traffic related or associated with the IAB node 570 (e.g., F1 traffic that may include control traffic and user traffic) to the target IAB topology 5003 through the IAB topology managed by the IAB donor CU serving the MT 571 of the IAB node 570 (e.g., through the IAB topology 5001 managed by the source IAB donor CU 501 when the MT has not yet migrated from the source F1 IAB donor CU 501, or through the IAB topology 5002 managed by the non-F1 IAB donor CU 502 when the MT has migrated to the non-F1 IAB donor CU 502) based on the identification information included in the notification (received from the source IAB donor CU 501 or the IAB node 570 as discussed above) and after the DU 572 of the IAB node 570 has migrated to the target IAB topology 5003. For example, the target IAB donor CU 503 sends a traffic migration request (e.g., Figure 10 Message 1014, Figure 13b Message 1313).

[0169] Figure 8 800 is a simplified diagram illustrating an example message flow for providing identification information identifying an IAB donor CU (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU) serving a MT of the IAB node to a target IAB donor CU (e.g., an F1 terminating donor CU) for DU migration of an IAB node as part of the DU migration processing of the IAB node for use in managing or facilitating transport migration. The identification information can be provided to the target IAB donor CU in a notification received from the source IAB donor CU (e.g., a DU migration notification or a configuration update notification) or in a notification received from the IAB node (e.g., an F1 setup request). These examples are discussed below.

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

[0171] At the beginning of the flow, IAB node 801 belongs to a source IAB topology controlled by a source F1 donor CU 803. When source F1 donor CU 803 decides or determines to perform a DU migration of IAB node 801 toward an IAB topology managed by a target F1 donor CU 807, the first step corresponds to sending a DU activation request message 813 to IAB node 801 to establish a new F1 connection between target F1 donor CU 807 and mobile IAB node 801 via a second logical DU IAB-DU2 804. Activation of the second logical IAB-DU2 806 in mobile IAB node 801 occurs via operation 810. The message 813 sent by source F1 donor CU 803 to IAB node 801 to activate IAB-DU2 806 is sent to the first logical DU IAB-DU1 805 because source F1 donor CU 803 already has an F1 connection with the first logical DU of IAB node 801. The DU activation request message 813 may be as follows: Figure 12a 801. The configuration request message 1203 is shown. This message 813 includes a request for establishing an F1 connection and for informing the target donor CU 807 of the identity of the IAB donor CU serving the MT 804 of the IAB node 801. (For example, when the target donor CU 807 is a different IAB donor CU than the IAB donor CU serving the MT of the IAB node) This request may (explicitly or implicitly) indicate to the IAB node 801 that the IAB node is to inform the target donor CU 807 of the identity of the IAB donor CU serving the MT of the IAB node.

[0172] After the second logical DU IAB-DU2 806 is activated, information contained in a message 813 may be transferred from the first logical DU IAB-DU1 805 to the second logical DU IAB-DU2 806 .

[0173] In particular, the message 813 may include identification information for identifying the target donor CU 807 (such as the TNL address (i.e., IP address) of the target F1 donor CU 807), so that a new F1 connection or F1 association (e.g., F1AP interface connection) can be established with the target donor CU 807 (between the IAB-DU2 806 and the target donor CU 807). The message 813 may also include a request to inform the identified target F1 donor CU 807 of the identification of the IAB donor CU of the MT 804 serving the IAB node 801 (such as the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the IAB donor CU of the MT 804 serving the IAB node 801). The message 813 may include information for indicating to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT. The information may include an information element (IE) for indicating that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT of the IAB node (see below for Figure 12a and configuration request message 1203). For example, when the MT has not yet migrated from the source F1 donor CU 803, the IAB donor CU serving the MT 804 is the source F1 donor CU 803 of the IAB node 801, and when the MT has migrated, the IAB donor CU serving the MT 804 is the non-F1 / RRC donor CU of the IAB node 801 ( Figure 8(a non-F1 donor CU is not shown in the figure). Message 813 may also include identification information for identifying the IAB donor CU of the MT 804 serving the IAB node 801, such as the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the IAB donor CU of the MT 804 serving the IAB node 801. In this example, the information for indicating to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT 804 may include identification information for identifying the IAB donor CU of the MT 804 serving the IAB node 801, and the presence of the identification information itself may indicate to the IAB node 801 that the IAB node is to inform the target F1 donor CU 807 of the identity of the IAB donor CU serving the MT 804. Additionally, message 813 may include an identifier of IAB-MT 804, known to the IAB donor CU serving MT 804 of IAB node 801. If the IAB donor CU serving MT 804 is a non-F1 donor CU, message 813 may include an identifier using the Non-F1 Terminated IAB Donor UE XnAP ID information element or the RRC Terminated IAB Donor UE XnAP ID information element defined in Section 9.2.3.16 of TS 38.423, as the NG-RAN node UE XnAP ID uniquely identifying a UE via the Xn interface within the NG-RAN node. Thus, each donor CU assigns a value to each MT of an IAB node in its IAB topology (since an IAB-MT is considered a UE). The F1 donor CU 803 assigns an ID to IAB-MT 804 when it accepts IAB-MT 804 into its IAB topology. Upon MT migration, the non-F1 donor CU assigns a different ID to IAB-MT 804. The two IDs are exchanged in the handover request / confirmation message.

[0174] Once activated, the IAB-DU2 806 may send an F1 setup request message 814 to the target F1 donor CU 807 to request the setup of an F1 connection between the IAB node 801 and the target F1 donor CU 807. Figure 12bThe message 814, depicted at 1213, may include identification information for identifying the source F1 donor CU 803, such as a TNL address (i.e., IP address) and / or an identifier (i.e., a global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the source F1 donor CU 803 of the IAB node 801. (For example, when the target donor CU 807 is an IAB donor CU different from the IAB donor CU of the MT serving the IAB node) The message 814 includes identification information for identifying the IAB donor CU of the MT 804 serving the IAB node 801. If the non-F1 donor CU is different from the target F1 donor CU 807, the message 814 includes the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the non-F1 donor CU of the IAB node 801. In addition, the message 814 may include an identifier of the IAB-MT 804 known to the IAB donor CU serving the MT 804 of the IAB node 801. In the case where the IAB donor CU serving the MT 804 is a non-F1 donor CU, the message 814 may include an identifier known to the non-F1 donor CU using the information element Non-F1 Terminating IAB Donor UE XnAP ID or RRC Terminating IAB Donor UE XnAP ID. The message 814 may additionally or alternatively include an identifier of the IAB-MT 804 known to the non-F1 donor CU using the information element BAP address (i.e., the BAP address assigned by the non-F1 donor CU or the RRC donor CU when the mIAB-MT 804 has established an RRC connection and has received its BAP address in the RRC reconfiguration message from the non-F1 / RRC donor CU). For example, the BAP address information element is described in TS 38.423 V17.2.0 section 9.2.2.89. Finally, the message 814 may include an identifier gNB-DU ID of the second logical DU IAB-DU2 806 of the IAB node 801. As specified in TS 38.473 section 9.3.1.19, the gNB-DU ID uniquely identifies the gNB-DU at least within the gNB-CU. Therefore, by configuration, the logical DUs of the IAB node are assigned a unique ID. It may be in ( Figure 12b A unique ID is provided to the F1 IAB donor CU that terminates the F1 connection with the logical DU at the F1 setup process described in .

[0175] In F1 setup response 815 (and also using Figure 12b1214 in the figure), the target F1 donor CU 807 may request IAB-DU2 806 to activate (one or more) new cells with associated identifiers (PCI, NCGI). Typically, a DU activates / deactivates (one or more) cells under the control of the donor CU that is controlling the DU. See, for example, TS 38.473, Section 8.2.3.2.

[0176] After receiving the F1 Setup Response message 815, IAB-DU2 806 may inform IAB-DU1 805 of the result of the activation process (i.e., the activation of IAB-DU2 806 and the activation of (one or more) new cells). IAB-DU1 805 may then relay this information to the source F1 donor CU 803 via the message DU Activation Response 816. This message 816 may include the gNB-DU ID of the second logical DU IAB-DU2 806 of the IAB node 801. Figure 12a Message 816 is further described at 1204 in FIG.

[0177] As another example method for providing identification information identifying the IAB donor CU (e.g., non-F1 terminating donor CU or source F1 terminating donor CU) that is serving the MT of the IAB node to the target F1 terminating donor CU for DU migration for the IAB node, (e.g., when the target donor CU 807 is an IAB donor CU different from the IAB donor CU that is serving the MT of the IAB node) the source F1 donor CU 803 may directly send a notification including identification information identifying the IAB donor CU that is serving the MT of the IAB node to the target donor CU 807. The notification may be sent to the target F1 donor CU 807 in a DU migration notification message 811. The message 811 may be sent to the target F1 donor CU 807 when the IAB-DU2 806 setup process is initiated ( Figure 7 Reference numeral 720 in FIG. 1 , and Figure 8 810, 813, 814, 815, 816 in the reference numerals ... Figure 13a In another example, messages 811 and 812 may correspond to the process described in reference to Figure 13b13. The process described above, wherein message 811 corresponds to message 1313 and message 812 corresponds to message 1314. Message 811 includes identification information for identifying the IAB donor CU of MT 804 serving IAB node 801. If MT 804 has migrated to a non-F1 / RRC donor CU and if the non-F1 donor CU is different from the target F1 donor CU 807, the DU migration notification message 811 may include a TNL address (i.e., IP address) and / or an identifier (i.e., a global NG-RAN node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3) of the non-F1 donor CU of the IAB node 801. Message 811 may also include an identifier of IAB node 801 known to the source F1 donor CU 803 using the information element F1-Terminating IAB-donor UE XnAP ID identifying the MT 804 of the IAB node 801 or the information element gNB-DU ID identifying the first logical DU IAB-DU1 805 of the IAB node 801. Additionally, message 811 may include an identifier of IAB node 801 known to the IAB donor CU of the MT 804 serving the IAB node 801. If the IAB donor CU serving the MT 804 is a non-F1 donor CU 803, message 811 may include an identifier known to the non-F1 donor CU using the information element non-F1-terminating IAB-donor UE XnAP ID or RRC-terminating IAB-donor UE XnAP ID identifying the MT 804 of the IAB node 801. The message 811 may also or alternatively include a BAP address allocated by the non-F1 / RRC donor CU. This relates to the BAP address being previously provided to the F1 donor CU 803 (eg, using a non-F1 donor CU) when the MT 804 was migrated. Figure 13a ).

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

[0179] As another example method of providing identification information identifying the IAB donor CU (e.g., non-F1 terminating donor CU or source F1 terminating donor CU) that is serving the MT of the IAB node to the target F1 terminating donor CU of the DU migration for the IAB node, (e.g., when the target F1 donor CU 807 is an IAB donor CU different from the IAB donor CU that is serving the MT of the IAB node) the source F1 donor CU 803 may directly send a notification including the identification information identifying the IAB donor CU that is serving the MT of the IAB node to the target donor CU 807. The notification may be sent to the target F1 donor CU 807 in a configuration update message 817. The message 817 may be sent to the target F1 donor CU 807 when the IAB-DU2 806 process is initiated ( Figure 7 Reference numeral 720 in FIG. 1 , and Figure 8 810, 813, 814, 815, 816 in the reference numerals ...

[0180] Therefore, the configuration update message 817 includes identification information for identifying the IAB donor CU of the MT 804 serving the IAB node 801. For example, if the non-F1 donor CU of the IAB node 801 is different from the target F1 donor CU 807, the message 817 may include the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the non-F1 donor CU. In addition, the message 817 may include an identifier of the IAB node 801 known to the IAB donor CU of the MT 804 serving the IAB node 801. In the case where the IAB donor CU serving the MT 804 is the non-F1 donor CU 803, the message 817 may include an identifier known to the non-F1 donor CU using the information element non-F1 terminated IAB donor UE XnAP ID (or RRC terminated IAB donor UE XnAP ID) identifying the MT 804 of the IAB node 801. The message 817 may also or alternatively include a BAP address allocated by the non-F1 / RRC donor CU. This refers to the BAP address previously provided to the F1 donor CU 803 by the non-F1 donor CU, for example, when the MT 804 was migrated (e.g., using Figure 13a Message 817 may also include a gNB-DU ID identifying a first logical DU IAB-DU1 805 of the IAB node 801 and / or a gNB-DU ID identifying a second logical DU IAB-DU2 806 of the IAB node 801.

[0181] When the target F1 donor CU 807 is the IAB donor CU of the MT serving the IAB node 801, information identifying the IAB donor CU of the MT serving the IAB node and the identifier of the IAB node 801 known to the IAB donor CU serving the MT 804 may also be present in the message 817. This will avoid any confusion in the target F1 donor CU 807 processing that the DU migration is interpreted as being related to the same IAB node 801 as the MT 804.

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

[0183] Messages 817 and 818 may correspond to Figure 13a , where message 817 corresponds to the configuration update message 1303 and message 818 corresponds to the configuration confirmation message 1304.

[0184] In order to communicate the identifier of the non-F1 donor CU to the target F1 donor CU 807, the source F1 donor CU 803 will need to know the identifier. In the case where the MT 804 of the IAB node 801 was previously migrated and the source F1 donor CU 803 was the source non-F1 / RRC donor CU for the MT migration, or in the case where the MT 804 of the IAB node 801 was migrated during DU migration and the source F1 donor CU 803 was also the source non-F1 / RRC donor CU for the MT migration, the source F1 donor CU 803 automatically knows the identifier of the target non-F1 / RRC donor CU, which can be indicated to the target F1 donor CU via message 817. In the case of consecutive MT migration, the source non-F1 donor CU for the MT migration is not the source F1 donor CU 803. In order to be informed of the identifier of the target non-F1 donor CU (i.e., the new non-F1 donor CU), for example, when MT migration is completed, the source F1 donor CU 803 may receive a message (not shown) from the source non-F1 / RRC donor CU. In order to inform the target F1 donor CU of the identifier of the non-F1 donor CU, the source F1 donor CU 803 may relay the message received from the source non-F1 donor CU. The source non-F1 donor CU for MT migration of the IAB node may be informed of the identifier of the non-F1 donor CU by referring to Figure 13a The described process informs the F1 donor CU of the IAB node of the identifier of the target non-F1 / RRC donor CU.

[0185] In the case of consecutive MT migrations for a mobile IAB node, the F1 donor CU of the IAB node may not be the source donor CU of the previous MT migration. Furthermore, it can be noted that during DU migration of an IAB node, there may be two different donor CUs serving two logical DUs of the IAB node. The question that can be raised is how the source non-F1 donor CU for the MT migration can identify the F1 donor CU for the IAB node.

[0186] It can be proposed that the F1 donor CU for the IAB node is a donor CU that has triggered the Transport Migration Management (TMM) process for traffic related to the IAB node. In fact, the MT migration process includes an MT handover process similar to UE handover, followed by a TMM process initiated by the F1 donor CU to transmit / receive packets related to the IAB node by controlling the IAB topology of the non-F1 donor CU. The TMM process corresponds to Figure 13b The process described in .

[0187] However, the specific case where no active transport migration is established for the migrated IAB node must be considered. Therefore, it is proposed that the source non-F1 donor CU for MT migration informs the target non-F1 donor CU of the F1 donor CU of the migrated IAB node. This can be achieved by using Figure 13a The process described is carried out.

[0188] Furthermore, if DU migration occurs without active transport migration, the non-F1 donor CU should be informed of the new F1 donor CU. Then, it can be considered that upon DU migration of an IAB node, the source F1 donor CU informs the non-F1 donor CU serving the co-located MT of the target F1 donor CU. This can be achieved by utilizing Figure 13a The process described is carried out.

[0189] As another example method of providing identification information identifying the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) currently serving the MT of the IAB node to the target F1 terminating donor CU for DU migration of the IAB node, (e.g., when the target donor CU 807 is a different IAB donor CU than the IAB donor CU serving the MT of the IAB node), the IAB node 801 may directly send a notification including identification information identifying the IAB donor CU currently serving the MT of the IAB node to the target F1 donor CU 807. This notification may be sent from IAB-DU2 806 to the target F1 donor CU 807 in a configuration update message 819. When the target F1 donor CU 807 is the IAB donor CU serving the MT of the IAB node 801, information identifying the IAB donor CU currently serving the MT of the IAB node may also be included in the configuration update message 819. This will avoid any confusion in the target F1 donor CU 807 processing as DU migration is related to the same IAB node 801 as MT 804. The configuration update message 819 may be used after completing the IAB-DU2 806 setup process ( Figure 7 Reference numeral 720 in FIG. 1 , and Figure 8 The configuration update message 819 may be sent at any time after the IAB node 801 detects a change in the non-F1 / RRC donor CU. For example, this may occur during DU migration of the IAB node 801 during the MT migration process. This example method assumes that the IAB-MT 804 notifies the IAB-DU2 806 of the current non-F1 donor CU through internal communication between the IAB-MT 804 and IAB-DU2 806 within the IAB node 801.

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

[0191] The identification information (i.e., the identifier of the IAB donor CU serving the MT 804 and the identifier of the MT 804 known to the IAB donor CU) may be provided to the MT 804 by the IAB donor CU serving the MT 804. For example, the IAB donor CU serving the MT 804 may use the message RRCReconfiguration, which is specified in TS 38.331 V17.2.0 and modified to include an information element for the TNL address of the IAB donor CU (i.e., the IP address) and / or its identifier (i.e., the global NG-RAN node ID as specified in TS 38.423 V17.2.0 Section 9.2.2.3), and an identifier for the MT 804 (i.e., the non-F1 terminating IAB donor UE XnAP ID or the RRC terminating IAB donor UE XnAP ID defined in TS 38.423 Section 9.2.3.16). For example, the RRCReconfiguration message is sent when the IAB node 801 is integrated into the network (i.e., when first connected to the IAB donor CU) and after the migration of the MT 804 of the IAB node 801. In the latter case, the RRCReconfiguration message is sent by the target non-F1 donor CU during the inter-IAB CDU topology adaptation procedure described in TS 38.401 V17.2.0, Section 8.17.3. The RRCReconfiguration message may also indicate the BAP address assigned to the IAB node 801 by the non-F1 donor CU.

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

[0193] Messages 819 and 820 may correspond to reference Figure 12d The process described, wherein the configuration update message 819 corresponds to the configuration update message 1233, and the configuration confirmation message 820 corresponds to the configuration confirmation message 1234.

[0194] Figure 9a 1 is a flow chart of an example method 900 for managing, at a source IAB donor CU (e.g., an F1-terminating donor CU) of an IAB node, a DU migration to a target IAB donor CU (e.g., an F1-terminating donor CU) of the IAB node, the DU migration having an indication of an IAB donor CU (e.g., a non-F1 / RRC-terminating donor CU) serving a mobile terminal (MT) of the IAB node. For example, the method 900 according to an embodiment of the present invention is performed at the source IAB donor CU and is used in managing or as part of a migration process / procedure for migrating DUs of the IAB node to the target IAB donor CU and for providing identification information identifying the IAB donor CU (e.g., a non-F1-terminating donor CU or a source F1-terminating donor CU) serving the mobile terminal (MT) of the IAB node to the target IAB donor CU (e.g., an F1-terminating donor CU) for use in managing or facilitating transport migration following the DU migration of the IAB node.

[0195] For example, reference Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the source IAB donor CU performing the method 900 may be the IAB donor CU 501 (e.g., the F1 termination donor CU or the F1 donor CU of the IAB node 570, with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by the IAB donor CU 503 as the target IAB donor CU. Figure 7 and Figure 8 , the IAB node may be the IAB node 701, 801, and the migration process may involve migrating the DU of the IAB node 701, 801 from the source F1 donor CU 703, 803 to the target F1 donor CU 707, 807. Figure 9aAs shown in and about Figure 9a The method 900 described may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 9a As shown in and about Figure 9a The described method is implemented, wherein the method is performed by a device for a source IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0196] At step 901, source F1 terminates the donor CU (703, 803) (e.g. Figure 5 The donor CU 501) is determined as the IAB node (701, 801) (such as Figure 5 The DU of the IAB node 570 of the source F1 donor CU 501, 703, 803 is to be migrated to the target F1 donor CU (707, 807) (e.g. Figure 5 503 of the donor CU 503). For example, the source F1 donor CU 501, 703, 803 determines the DU migration of the IAB node (such as the IAB node 570) toward the target F1 donor CU (such as the donor CU 503, 707, 807). For example, the source F1 donor CU 501, 703, 803 may determine that the DU 572 of the IAB node 570, 701, 801 is to be migrated in response to determining that the migration of the MT 571, 704, 804 of the IAB node 570, 701, 801 toward the new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining that a DU is to be migrated are described above. Details of how the source F1 donor CU 501, 703, 803 determines the target F1 termination donor CU 503, 707, 807 are also described above.

[0197] At step 902, source F1 terminates the donor CU 501, 703, 803 by utilizing Figure 7 The DU migration of the IAB node is performed or carried out according to the process described by reference numeral 720 in FIG.

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

[0199] At step 904, the source F1 terminating donor CU 501, 703, 803 may receive an acknowledgment from the target F1 terminating donor CU 503, 707, 807. The message received at step 904 may be Figure 8 Message 812 or message 818 in.

[0200] Figure 9b 1 is a flow chart of another example method 910 for managing, at a source IAB donor CU (e.g., an F1-terminating donor CU) of an IAB node, a DU migration to a target IAB donor CU (e.g., an F1-terminating donor CU), the DU migration having an indication of an IAB donor CU (e.g., a non-F1-terminating donor CU or an RRC-terminating donor CU) serving a mobile terminal (MT) of the IAB node. For example, the method 910 according to an embodiment of the present invention is performed at the source IAB donor CU and is used in managing a migration process / procedure or as part of a migration process / procedure for migrating DUs of the IAB node to the target IAB donor CU and for providing identification information identifying the IAB donor CU (e.g., a non-F1-terminating donor CU or a source F1-terminating donor CU) serving the mobile terminal (MT) of the IAB node to the target IAB donor CU (e.g., an F1-terminating donor CU) for use in managing or facilitating transport migration following the DU migration of the IAB node.

[0201] For example, reference Figure 5 As shown in and about Figure 5In the described IAB communication system 500, the source IAB donor CU performing the method 910 may be the IAB donor CU 501 (e.g., the F1 termination donor CU or the F1 donor CU of the IAB node 570, with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by the IAB donor CU 503 as the target IAB donor CU. Figure 7 and Figure 8 , the IAB node may be the IAB node 701, 801, and the migration process may involve migrating the DU of the IAB node 701, 801 from the source F1 donor CU 703, 803 to the target F1 donor CU 707, 807. Figure 9b As shown in and about Figure 9b The method 910 described may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 9b As shown in and about Figure 9b The described method is implemented, wherein the method is performed by a device for a source IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0202] At step 911, source F1 terminates the donor CU (703, 803) (e.g. Figure 5 The donor CU 501) is determined as the IAB node (701, 801) (such as Figure 5 The DU of the IAB node 570 of the source F1 donor CU 501, 703, 803 is to be migrated to the target F1 donor CU (707, 807) (e.g. Figure 5503). For example, the source F1 donor CU 501, 703, 803 determines the migration of the DU of the IAB node (such as the IAB node 570, 701, 801) toward the target F1 donor CU (such as the donor CU 503, 703, 803). For example, the source F1 donor CU 501, 703, 803 may determine that the DU of the IAB node 570, 701, 801 is to be migrated in response to determining that the migration of the MT 571, 704, 804 of the IAB node 570, 701, 801 toward the new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining that a DU is to be migrated are described above. Details of how the source F1 donor CU 501, 703, 803 determines the target F1 termination donor CU 503, 707, 807 are also described above.

[0203] At step 912, the source F1 terminating donor CU 501, 703, 803 sends a request to the IAB node 570, 701, 801. The request is used to establish an F1 connection (i.e., a new F1 connection) between the target IAB donor CU 503, 707, 807 and the IAB node 570, 701, 801 (e.g., a new F1 association with the target IAB donor CU), and to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT 571, 704, 804 of the IAB node 570, 701, 801. For example, the source F1 terminating donor CU 501, 703, 803 sends a request for a new F1 connection to the IAB node 570, 701, 801 to be migrated. The request from the source F1 terminating donor CU 501, 703, 803 may indicate (explicitly or implicitly) to the IAB node 570, 701, 801 that the IAB node is to inform the target IAB donor CU 503, 707, 807 of the identity of the IAB donor CU serving the MT 571, 704, 804 of the IAB node 570, 701, 801. For example, the request from the source IAB donor CU 501 may include information indicating to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT. Figure 12aAs discussed above with respect to configuration request message 1203, the information may include an information element (IE) for indicating that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU serving the mobile terminal (MT) of the IAB node. The presence of the IE in the request for establishing an F1 connection may indicate to the IAB node that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU. Alternatively, when the IE has a certain value (e.g., the IE may be a single bit and the value may be "1" or "0"), it may indicate to the IAB node that the IAB node is to notify the target IAB donor CU of the identity of the IAB donor CU. The request may also include identification information for identifying the IAB donor CU serving the mobile terminal (MT) 571, 704, 804 of the IAB node 570, 701, 801 (e.g., the non-F1 / RRC terminating donor CU 502 when the MT has migrated to the IAB donor CU 502, or the F1 terminating donor CU 501 when the MT has not yet migrated). In another example, the information may include identification information for identifying the IAB donor CU of the MT serving the IAB node 570, and the presence of the identification information in the request itself may indicate to the IAB node that the IAB node is to inform the target IAB donor CU of the identification of the IAB donor CU. Figure 8 With this message, the source F1 donor CU 501, 703, 803 may send a request to the IAB node 570, 701, 801 to indicate a non-F1 / RRC terminating donor CU to the target F1 terminating donor CU 503, 707, 807. The non-F1 / RRC terminating donor CU may be Figure 5 Donor CU 502( Figure 7 709 in the .

[0204] At step 913, the source F1 terminating donor CU 501, 703, 803 may receive confirmation of activation from the IAB node 570, 701, 801. The message received at step 913 may be in Figure 8 As shown in and about Figure 8 Message 816 is described.

[0205] Figure 9c1 is a flow chart of an example method 920 according to one or more embodiments of the present invention, the example method 920 being performed at an IAB node to make an F1 setup request to a target donor CU while indicating the IAB donor CU (e.g., a non-F1 terminating donor CU or an RRC terminating donor CU) of a MT serving the IAB node. For example, the method 920 according to an embodiment of the present invention is performed at the IAB node and is used or is part of a migration process / procedure for migrating DUs of the IAB node to a target IAB donor and for providing identification information identifying the IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU) of the MT serving the IAB node to the target IAB donor for use in managing or facilitating transport migration following DU migration of the IAB node.

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

[0207] At step 921, the IAB nodes (701, 801) (e.g. Figure 5IAB node 570) terminates the donor CU (703, 803) from the source F1 (as Figure 5 The donor CU 501 of the target F1 connection receives a request for establishing an F1 connection or a new F1 connection (eg, the IAB node 570, 701, 801 and the target F1 donor CU (707, 807) (eg, Figure 5 The request may be a reference to the F1 connection between the donor CU 503) and used to inform the target IAB donor CU of the identity of the IAB donor CU of the MT 571, 704, 804 serving the IAB node. Figure 8 The message 813 described above includes a request to indicate to the target F1 donor CU 503, 707, 807 the IAB donor CU (e.g., non-F1 / RRC terminating donor CU) serving the MT 571, 704, 804 of the IAB node. The non-F1 / RRC terminating donor CU may be Figure 5 Donor CU 502 or Figure 7 709 in the IAB node. The request may include identification information for identifying the IAB donor CU of the MT 571, 704, 804 serving the IAB node. As an alternative to receiving the identification in the request sent by the source F1 terminating donor CU 501, 703, 803, the IAB node may already know the identification of the IAB donor CU of the MT 571, 704, 804 serving the IAB node. For example, the IAB node may obtain this information when the MT migrates. In another example, the IAB node may obtain the NR cell global identifier (NCGI) from the system information block (SIB) broadcast in the cell controlled by the parent IAB node in the IAB topology controlled by the non-F1 terminating donor CU. This identifier (NCGI) may be sufficient for the target F1 donor CU to identify the non-F1 terminating donor CU.

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

[0209] Figure 9d is a flow chart of an example method 930 for managing transport migration after DU migration of an IAB node at a target IAB donor CU according to an embodiment of the present invention. The method 930 is an example of the method 1400 described above.

[0210] For example, reference Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the target IAB donor CU for performing the method 930 may be the IAB donor CU 503 controlling the IAB topology 5003. The IAB node may be the mobile IAB node 570 belonging to the IAB topology 5001 controlled by the IAB donor CU 501. The migration process may involve the DU 572 of the IAB node 570 migrating from the IAB topology 5001 to the IAB topology 5003. Figure 7 and Figure 8 , the IAB node may be the IAB node 701, 801, and the migration process may involve migrating the DU of the IAB node 701, 801 from the source F1 donor CU 703, 803 to the target F1 donor CU 707, 807. Figure 9d As shown in and about Figure 9d The described method 930 may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 9d As shown in and about Figure 9d The described method is implemented by a device for a target IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0211] At step 931, the target F1 terminates the donor CU (707, 807) (e.g. Figure 5 The IAB donor CU 503) from the IAB node (701, 801) (such as Figure 5 The IAB node 570 of the IAB node receives an F1 setup request for requesting to set up an F1 connection between the target IAB donor CU and the IAB node. The F1 setup request message sent by the IAB node may include identification information for identifying the IAB donor CU that is serving the MT of the IAB node (for example, a non-F1 termination donor CU when the MT of the IAB node has migrated to a non-F1 termination donor CU different from the target IAB donor CU, or a source F1 termination donor CU when the MT of the IAB node has not yet migrated). The F1 setup request message may also include identification information for identifying the source F1 termination donor CU. The non-F1 termination donor CU may be Figure 5 Donor CU 502 or Figure 7 Donor CU 709.

[0212] The message received at step 931 may be as follows Figure 8 As shown in and about Figure 8 In response to receiving the request at step 931, the target F1 termination donor CU 503, 707, 807 may send an acknowledgment to the IAB node 570, 701, 801. The acknowledgment may be as follows: Figure 8 As shown in and about Figure 8 Message 815 is described.

[0213] In another example, at step 931, the target F1 terminates the donor CU (707, 807) (e.g. Figure 5 The IAB donor CU 503 of the source IAB donor CU (703, 803) (such as Figure 5 The notification includes identification information for identifying the IAB donor CU that is serving the MT of the IAB node (e.g., a non-F1 termination donor CU when the MT of the IAB node has migrated to a non-F1 termination donor CU different from the target IAB donor CU, or a source F1 termination donor CU when the MT of the IAB node has not yet migrated). The notification may be a DU migration notification, such as Figure 8 As shown in and about Figure 8 Alternatively (and in Figure 9d Not shown), the notification may be a configuration update notification, such as Figure 8 As shown in and about Figure 8 Configuration update message 817 described above, etc.

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

[0215] Figure 101000 is a simplified diagram illustrating another example message flow for providing identification information for identifying an IAB donor CU (e.g., a non-F1 terminating donor CU or a source F1 terminating donor CU serving an MT) serving the IAB node to a target IAB donor CU (e.g., an F1 terminating donor CU) of a DU migration of an IAB node (as part of the DU migration process of the IAB node) for use in managing or facilitating transport migration. Figure 10 As shown in and below about Figure 10 The described message flows are relevant to the case where the MT of an IAB node has migrated to another IAB donor CU (eg, a non-F1 IAB donor CU that is different from the source IAB donor CU (source F1 donor CU) and the target IAB donor CU (target F1 donor CU)).

[0216] Should Figure 10 Shown are a source F1 donor CU 1003 such as donor CU 501 , 703 , a target F1 donor CU 1007 such as donor CU 503 , 707 , and a non-F1 / RRC donor CU 1009 such as donor CU 502 , 709 .

[0217] When the source F1 donor CU 1003 of the IAB node can release the traffic migration towards the non-F1 donor CU 1009, and when the target F1 donor CU 1007 can request the traffic migration towards the non-F1 donor CU 1007, the start of the flow is the same as after the DU migration of the IAB node (such as the IAB node 570, 701). Figure 7 The UE handover process 730 of FIG1 corresponds to the end of FIG1 . Assume that the MT of the IAB node previously migrated toward the IAB topology managed by the non-F1 donor CU 1009 and traffic related to the UE served by the IAB node was routed via the IAB topology managed by the non-F1 donor CU 1009 .

[0218] After a UE served by an IAB node is handed over to a target F1 donor CU 1007, the source F1 donor CU 1003 sends a transport migration release message 1011 to the non-F1 donor CU 1009 to request the release of traffic associated with the handed-over UE and, therefore, the IAB node with the migrated DU. For example, the transport migration release message 1011 may include a request to release the transport migration set by the source IAB donor CU for traffic associated with the IAB node. The non-F1 donor CU 1009 responds with a transport migration response message 1012 to confirm the release operation.

[0219] According to an example, the message 1011 may include an indication that the traffic migration release is due to DU migration of the IAB node towards the target F1 donor CU 1007. Thus, the message 1011 may include an identifier of the migrated IAB node known to the source F1 donor CU 1003 and the non-F1 donor CU 1009 using the information element F1 terminating IAB donor UE XnAP ID and non-F1 terminating IAB donor UE XnAP ID (or RRC terminating IAB donor UE XnAP ID). The message 1011 may also include an identifier of the target F1 donor CU 1007 (i.e., a TNL / IP address and / or a global NG-RAN node ID as specified in TS 38.423 V17.2.0, section 9.2.2.3), and an identifier of the logical DU of the IAB node served by the target F1 donor CU 1007, gNB-DU ID (as specified in TS 38.473, section 9.3.1.19).

[0220] Upon receiving the transport migration release message 1011, the non-F1 donor CU 1009 may release the transport migration (e.g., set by the source IAB donor CU) by deleting the configuration of the IAB nodes involved in routing packets to / from the migrated IAB node within the IAB topology controlled by the non-F1 donor CU 1009. For example, the non-F1 donor CU 1009 may reconfigure the IAB nodes involved in routing traffic to and / or from the IAB node (e.g., the IAB nodes in the routing path(s) to the IAB node) by sending configuration update information for deleting configuration information associated with routing traffic to and / or from the IAB node at each IAB node. The non-F1 donor CU 1009 may send updated configuration information (e.g., routing configuration table) to the (one or more) IAB nodes in the (one or more) routing paths to the migrated IAB node, so that the configurations at these IAB nodes in the (one or more) routing paths used for routing packets to / from the migrated IAB node within the IAB topology are deleted. Figure 5In the example of FIG5 , wherein MT 571 of IAB node 570 is served by IAB donor CU 502, DU 572 of IAB node 570 has been migrated to IAB donor CU 503, and IAB node 570 is connected to IAB node 550 via backhaul link 505, after the DU migration, IAB donor CU 502, which is a non-F1 donor CU, can release the transport migration by deleting the configuration information associated with routing traffic to / from IAB node 570 and reconfiguring the configuration information at IAB donor CU 506, IAB nodes 540, and 550. Alternatively, the non-F1 donor CU 1009 can simply suspend the traffic migration by maintaining the configuration of these IAB nodes (e.g., the IAB nodes in the routing path are not reconfigured to delete the configuration information associated with routing traffic to / from the migrated IAB node). In fact, because the request for traffic migration release is due to the DU migration of the relevant IAB node toward the target F1 donor CU, the traffic migration request from the target F1 donor CU should be quickly received by the non-F1 donor CU 1009. And because the traffic to be migrated by the target F1 donor CU should be equivalent to the traffic migrated by the source F1 donor CU, the same configuration of the IAB nodes in the IAB topology controlled by the non-F1 donor CU 1009 should still apply.

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

[0222] Messages 1011 and 1012 may correspond to Figure 13b , where message 1011 corresponds to message 1313 and message 1012 corresponds to message 1314.

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

[0224] When a UE served by an IAB node switches toward a target F1 donor CU 1007, the target F1 donor CU 1007 sends a transport migration request message 1014 to request that traffic associated with the served UE be migrated toward the IAB topology controlled by the non-F1 donor CU 1009. Upon receiving the message 1014, the non-F1 donor CU 1009 may accept the migration and may configure the IAB nodes in its IAB topology to route packets to / from the IAB node serving the UE based on the traffic characteristics (e.g., throughput, quality of service) provided by the target F1 donor CU 1007. The non-F1 donor CU 1009 then sends a transport migration response message 1015 to the target F1 donor CU 1007 to confirm the transport migration. In the case that the non-F1 donor CU 1009 maintains the configuration of the IAB node upon receiving the message 1011, and in the case that the characteristics of the traffic to be migrated are equivalent to the characteristics of the traffic previously migrated by the source F1 donor CU 1003, the non-F1 donor CU 1009 simply resumes the transport migration and sends a response 1015 to the target F1 donor CU 1007.

[0225] Messages 1014 and 1015 may correspond to Figure 13b , where message 1014 corresponds to message 1313 and message 1015 corresponds to message 1314.

[0226] Figure 11a 1 is a flow chart of another example method 1100 according to an embodiment of the present invention, the example method 1100 being used to manage, at a source IAB donor CU (e.g., an F1-terminating donor CU) of the IAB node, a DU migration to a target IAB donor CU (e.g., an F1-terminating donor CU), the DU migration having an indication of an IAB donor CU, a non-F1-terminating donor CU, or an RRC-terminating donor CU of an MT serving the IAB node.

[0227] For example, reference Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the source IAB donor CU performing the method 1100 may be the IAB donor CU 501 (e.g., the F1 termination donor CU or the F1 donor CU of the IAB node 570, with which the IAB node 570 maintains an F1 connection). The IAB node may be a mobile IAB node 570 belonging to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by the IAB donor CU 503 serving as the target IAB donor CU. Figure 7 and Figure 10 , the IAB node may be the IAB node 701, and the migration process may involve migrating the DUs of the IAB node 701 from the source F1 donor CU 703, 1003 to the target F1 donor CU 707, 1007. Figure 11a As shown in and about Figure 11a The method 1100 described may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 11a As shown in and about Figure 11a The described method is implemented, wherein the method is performed by a device for a source IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0228] At step 1101, source F1 terminates the donor CU (e.g. Figure 5 The donor CU 501) is determined as the IAB node ( Figure 7 701) (such as Figure 5 The DU of the IAB node 570 of the source F1 donor CU 501, 703, 1003 is to be migrated to the target F1 donor CU (707, 1007) (e.g. Figure 5 For example, the source F1 donor CU 501, 703, 1003 determines the migration of the DU of the IAB node (such as the IAB node 570) toward the target F1 donor CU (such as the donor CU 503, 707, 1007). For example, the source F1 donor CU 501, 703, 1003 may determine that the DU of the IAB node 570, 701 is to be migrated in response to determining that the migration of the MT of the IAB node 570, 701 toward the new parent IAB node (which may be a new IAB node or a new IAB donor DU) has been completed. Examples of other triggers for determining that the DU is to be migrated are described above. Details of how the source F1 donor CU 501, 703, 1003 determines the target F1 termination donor CU 503, 707, 1007 are also described above.

[0229] At step 1102, source F1 terminates the donor CU 501, 703, 1003 by utilizing Figure 7 The DU migration of the IAB node is performed or carried out according to the process described by reference numeral 720 in FIG.

[0230] At step 1103, the source F1 terminating donor CU 501, 703, 1003 sends a transport migration release for traffic related to the IAB node 570, 701 and indicating the target F1 donor CU 503, 707, 1007 (e.g., providing identification information for identifying the target F1 donor CU) for DU migration to the IAB node to the non-F1 terminating donor CU of the IAB node. The indication of the target F1 donor CU 503, 707, 1007 may be sent only when the non-F1 terminating donor CU is different from the target F1 donor CU 503, 707. The message sent at step 1103 may be Figure 10 Message 1011 in.

[0231] Figure 11b1 is a flowchart of an example method 1110 for transport migration in the case of managing DU migration of an IAB node at a non-F1 / RRC termination donor CU of the IAB node according to an embodiment of the present invention. For example, the method 1110 according to one or more embodiments of the present invention is performed at an IAB donor CU (e.g., a non-F1 termination donor CU or an RRC termination donor CU, and also referred to as a second IAB donor CU) to which the MT of the IAB node has migrated, and is used in managing transport migration for traffic related to or associated with the IAB node. Transport migration is to be performed after the DU of the IAB node has migrated from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU. The non-F1 termination donor CU is an IAB donor CU that is different from the target IAB donor CU and the source IAB donor CU.

[0232] For example, reference Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the IAB donor CU that performs the method 1110 may be the IAB donor CU 502 (e.g., a non-F1 / RRC termination donor CU or a non-F1 / RRC donor CU of the IAB node 570, with which the IAB node 570 maintains an RRC connection). The IAB node may be a mobile IAB node 570 that belongs to an IAB topology 5001 (also referred to as a source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to an IAB topology 5003 (also referred to as a target IAB topology) managed by the IAB donor CU 503 serving as the target IAB donor CU. Figure 7 and Figure 10 , the IAB node may be the IAB node 701, and the migration process may involve migrating the DUs of the IAB node 701 from the source F1 donor CU 703, 1003 to the target F1 donor CU 707, 1007. Figure 11b As shown in and about Figure 11b The described method 1110 may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 11b As shown in and about Figure 11b The method described is implemented by a device for a non-F1 IAB donor CU including one or more processing units (such as central processing unit 411).

[0233] At step 1111, non-F1 terminates the donor CU (709, 1009) (e.g. Figure 5 The donor CU 502) from the IAB node ( Figure 7 701) (such as Figure 5 The source F1 of the IAB node 570 terminates the donor CU (703, 1003) (as Figure 5 The transport migration release (e.g., transport migration release message 1011) of the donor CU 501 of the source F1 donor CU 501, 703, 1003) is used to request the release of the transport migration set by the source F1 donor CU 501, 703, 1003 for traffic related to or associated with the IAB node. The transport migration release may include identification information for identifying or indicating the target F1 termination donor CU for DU migration to the IAB node. The target F1 termination donor CU may be Figure 5 Donor CU 503 or Figure 7 Donor CU 707 or Figure 10 Donor CU 1007.

[0234] At step 1112, the non-F1 terminating donor CU 502, 709, 1009 releases (or suspends) the previously set transport migration according to the request of the source F1 terminating donor CU 501, 703, 1003. Figure 10 As discussed, when the non-F1 terminating donor CU 502, 709, 1009 releases transport migration, the terminating donor CU 502, 709, 1009 reconfigures the IAB nodes involved in routing traffic to and / or from the IAB nodes by deleting configuration information associated with routing traffic to and / or from the IAB nodes at each IAB node. When the non-F1 terminating donor CU 502, 709, 1009 suspends transport migration, the configuration at each IAB node involved in routing traffic to and / or from the IAB node is retained.

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

[0236] At step 1114, the non-F1 terminating donor CU 501, 703, 1003 receives a transport migration request for traffic related to the IAB node 570 from the target F1 donor CU 503, 707, 1007. The transport migration request may be sent in the transport migration request message 1014 discussed above.

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

[0238] Figure 11c is a flow chart of another example method 1120 for managing transport migration of an IAB node in the case of a target F1 terminating donor CU of the IAB node according to an embodiment of the present invention.

[0239] For example, reference Figure 5 As shown in and about Figure 5 In the described IAB communication system 500, the target IAB donor CU for performing the method 1120 may be the IAB donor CU 503 controlling the IAB topology 5003 (also referred to as the target IAB topology). The IAB node may be a mobile IAB node 570 belonging to the IAB topology 5001 (also referred to as the source IAB topology) controlled by the IAB donor CU 501. The migration process may involve migrating the DU 572 of the IAB node 570 from the IAB topology 5001 to the IAB topology 5003. Figure 7 and Figure 10 , the IAB node may be the IAB node 701, and the migration process may involve migrating the DUs of the IAB node 701 from the source F1 donor CU 703, 1003 to the target F1 donor CU 707, 1007. Figure 11c As shown in and about Figure 11c The described method 930 may be performed by software elements and / or hardware elements. Figure 4 As shown in and about Figure 4 The communication device 400 described utilizes Figure 11c As shown in and about Figure 11c The described method is implemented by a device for a target IAB donor CU comprising one or more processing units (such as the central processing unit 411).

[0240] At step 1121, the target F1 terminates the donor CU (707, 1007) (e.g. Figure 5 IAB donor CU 503) from IAB node ( Figure 7 701) (such as Figure 5 Non-F1 terminated donor CU (709, 1009) (e.g., Figure 5 terminating donor CU 502) receives a message indicating that the non-F1 terminating donor CU 502, 709, 1009 is ready for transport migration of traffic associated with the IAB node 570. For example, the target F1 terminating donor CU 503, 707, 1007 receives a notification from the non-F1 terminating donor CU 502, 709, 1009 indicating that the non-F1 terminating donor CU 502, 709, 1009 is ready for transport migration of traffic associated with the IAB node 570, wherein the notification includes identification information for identifying the non-F1 terminating donor CU 1009. As discussed above, the notification can be sent in the transport migration ready message 1013 sent to the target F1 donor CU 1007.

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

[0242] Figure 12a is a schematic simplified diagram 1200 illustrating an example message flow for a procedure to perform activation of a logical DU according to an example.

[0243] The diagram shows:

[0244] -RAN node DU 1201, which may be Figure 5 IAB-DU 572 of IAB node 570 (and Figure 8 801 of the IAB node 805) such as the IAB-DU1 of the IAB node 801,

[0245] -RAN node CU 1202, which may be Figure 5IAB Donor CU 501 (and Figure 8 An IAB donor CU like the source F1 donor CU 803).

[0246] The message CONFIGURATION REQUEST 1203 is sent by the RAN node CU 1202 to the RAN node DU 1201 to request the activation of new cell(s) controlled by the RAN node DU 1201, or to request the activation of a logical DU, or to request the deactivation of cell(s) in the RAN node DU 1201. In the case of logical DU activation, the message 1203 may include the RAN node CU (e.g., Figure 8 807). For example, a CONFIGURATION REQUEST 1203 may be sent by the source IAB donor CU to an IAB node (e.g., a first logical DU entity 805 having an F1 connection with the source IAB donor CU) to request the establishment of an F1 connection between the target IAB donor CU and the IAB node. The message 1203 may also include an information element (IE) for requesting the RAN node DU 1201 to send a TNL address (i.e., IP address) to the RAN node CU (e.g., the first logical DU entity 805) that will be connected to the logical DU (once activated). Figure 8 The target F1 donor CU 807 of the RAN node DU 1201 (e.g., a non-F1 IAB donor CU or an RRC IAB donor CU) transmits the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in TS 38.423 V17.2.0, Section 9.2.2.3) of the RAN node CU (e.g., the address and / or identifier of the IAB donor CU of the MT serving the IAB node) that terminates the RRC connection for the RAN node embedded in the RAN node DU 1201 (e.g., the address and / or identifier of the IAB donor CU of the MT serving the IAB node). This IE may be limited to one bit: one value of this one-bit IE (i.e., "0" or "1") means that no specific action is requested, while another value (i.e., "1" or "0") means that the address / identifier of the non-F1 donor CU is sent. This IE may be extended to include the address / identifier of the RAN node CU that terminates the RRC connection. Message 1203 may include the identifier of the mobile terminal (MT) embedded in the RAN node DU 1201 known to the RAN node CU terminating the RRC connection using the information element non-F1 terminating IAB donor UE XnAP ID or RRC terminating IAB donor UE XnAP ID defined in TS 38.423 section 9.2.3.16.

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

[0248] According to an example, Figure 12a The flow in corresponds to the procedure gNB-CU configuration update procedure described in section 8.2.5 of TS 38.473 V17.0.0, and message 1203 corresponds to the message GNB-CU CONFIGURATION UPDATE described in section 9.2.1.10 of TS 38.473 V17.2.0, and message 1204 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in section 9.2.1.11 of TS 38.473 V17.2.0.

[0249] The message GNB-CU CONFIGURATION UPDATE includes an information element (IE) Cells to be Activated List to indicate a list of (one or more than one) new cells to be activated at the RAN node DU 1201. For example and with reference to Figure 8 The GNB-CU CONFIGURATION UPDATE includes information for activating the new cell(s) indicated in the IE's list of cells to be activated. These new cells(s) may be served by the first logical DU entity 805 at the IAB node 801. The cell(s) to be activated are the cell(s) controlled by the RAN node DU 1201 that received the request. The associated PCI and NCGI values ​​to be used by the RAN node DU 1201 may also be provided.

[0250] The message GNB-CU CONFIGURATION UPDATE may also include an information element (IE) Cells to be Deactivated List to indicate the (one or more) cells to be deactivated. The (one or more) cells to be deactivated refer to the (one or more) cells controlled by the RAN node DU 1201 that receives the request. For example and with reference to Figure 8The GNB-CU CONFIGURATION UPDATE may include information for deactivating the cell(s) indicated in the IE to be deactivated cell list, which are currently served by the first logical DU entity 805 at the IAB node 801 .

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

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

[0253] Another IE may be added to request the transmission of the address and / or identifier of the RAN node CU that terminates the RRC connection of the RAN node embedded in the RAN node DU 1201 (e.g., the address and / or identifier of the IAB donor CU of the MT serving the IAB node). This IE may be an address (e.g., a non-F1 TNL address IE or an RRC TNL address IE) or an identifier (e.g., a non-F1 global NG-RAN node ID or an RRC global NG-RAN node ID), and the presence of this IE indicates that it will be included in the request for the F1 connection.

[0254] Another IE may be added to identify the mobile terminal (MT) of the RAN node embedded in the RAN node DU 1201 (e.g., non-F1 terminating IAB donor UE XnAP ID or RRC terminating IAB donor UE XnAP ID), and the presence of this IE indicates that it will be included in the request for the F1 connection. The presence of this IE may indicate that the BAP address identifying the mobile terminal (MT) of the RAN node embedded in the RAN node DU 1201 will be inserted into the request for the F1 connection.

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

[0256] To complete the setup of a new logical DU at the IAB node, you can use the reference Figure 12b Describe the process.

[0257] Figure 12b is a schematic simplified diagram 1210 illustrating an example message flow of a process to set up a logical DU to establish an F1 connection with a target IAB donor CU according to an example.

[0258] The diagram shows:

[0259] -RAN node DU 1211, which may be Figure 5 IAB-DU 572 of IAB node 570 (and Figure 8 801 of the IAB node 801) such as the IAB-DU2 806 of the IAB node 801,

[0260] -RAN node CU 1212, which may be Figure 5 IAB Donor CU 503 (and Figure 8 The target F1 donor CU 807 is an IAB donor CU.

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

[0262] Message 1213 may also include at least one of the following:

[0263] - the TNL address (i.e. IP address) and / or identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the source RAN node CU for which F1 setup has been requested,

[0264] - the TNL address (i.e. IP address) and / or identifier (i.e. global NG-RAN node ID) of the RAN node CU terminating the RRC connection of the RAN node embedded in the RAN node DU 1211 (e.g. the address and / or identifier of the IAB donor CU of the MT serving the IAB node),

[0265] - an identifier of the mobile terminal (MT) for the RAN node embedded in the RAN node DU 1211, made known to the RAN node CU at which the RRC connection of the RAN node embedded in the RAN node DU 1211 is terminated (e.g. a non-F1 terminating IAB donor UE XnAP ID or an RRC terminating IAB donor UE XnAP ID),

[0266] - the BAP address of the MT of the RAN node embedded in the RAN node DU 1211 allocated by the RAN node CU that terminates the RRC connection of the RAN node embedded in the RAN node DU 1211,

[0267] - Identifier of the RAN node DU 1211, gNB-DU ID.

[0268] The RAN node CU 1212 replies with a message SETUP RESPONSE 1214 sent to the RAN node DU 1211. The message SETUP RESPONSE 1214 may include a list of cell(s) to be activated with the logical DU and the associated PCI and NCGI value(s) to be used.

[0269] According to an example, Figure 12b The flow in FIG1 corresponds to the F1 Setup procedure described in Section 8.2.3 of TS 38.473 V17.2.0, and message 1213 corresponds to the F1 SETUP REQUEST message described in Section 9.2.1.4 of TS 38.473 V17.2.0, while message 1214 corresponds to the F1 SETUPRESPONSE message described in Section 9.2.1.5 of TS 38.473 V17.2.0. The F1 SETUP RESPONSE message includes the information element (IE) Cell List to Activate, which indicates a list of new cells to be activated. The cell(s) to be activated are the cells(s) controlled by the RAN node DU 1211 that receives the response.

[0270] Figure 12c is a schematic simplified diagram 1220 illustrating an example message flow for a process to remove a logical DU.

[0271] The diagram shows:

[0272] -RAN node DU 1221, which may be Figure 5 IAB-DU 572 of IAB node 570 (and Figure 8 801 of the IAB node 801) such as the IAB-DU1 805 of the IAB node 801,

[0273] -RAN node CU 1222, which may be Figure 5 IAB Donor CU 501 (and Figure 8 An IAB donor CU like the source F1 donor CU 803).

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

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

[0276] According to an example, Figure 12c The flow in corresponds to the procedure F1 removal described in section 8.2.8 of TS 38.473 V17.2.0, and message 1223 corresponds to the message F1 REMOVALREQUEST described in section 9.2.1.16 of TS 38.473 V17.2.0, while message 1224 corresponds to the message F1 REMOVALRESPONSE described in section 9.2.1.7 of TS 38.473 V17.2.0.

[0277] Figure 12d is a schematic simplified diagram 1230 illustrating an example message flow according to a procedure used by an example logical DU to inform an IAB donor CU of a change in configuration.

[0278] The diagram shows:

[0279] -RAN node DU 1231, which may be Figure 5 IAB-DU 572 of IAB node 570 (and Figure 8 IAB-DU2 805 of the IAB node 801) such as the DU of the IAB node DU,

[0280] -RAN node CU 1232, which may be Figure 5 IAB Donor CU 503 (and Figure 8 The target F1 donor CU 807 is an IAB donor CU.

[0281] The CONFIGURATION UPDATE message 1233 is sent by the RAN node DU 1231 to the RAN node CU 1232 to indicate a configuration change of the RAN node embedded in the RAN node DU 1231. The CONFIGURATION UPDATE message 1233 may be sent by the RAN node DU 1231 to indicate to the RAN node CU 1232 the identifier of the RAN node CU serving the MT of the RAN node embedded in the RAN node DU 1231. For example, the message 1233 is sent by the second logical DU entity 806 activated at the IAB node 801 to the target IAB donor CU 807 to indicate the IAB donor CU serving the MT 804 of the IAB node 801. The CONFIGURATION UPDATE message 1233 may include the TNL address (i.e., IP address) and / or identifier (i.e., the global NG-RAN node ID as specified in Section 9.2.2.3 of TS 38.423 V17.2.0) of the RAN node CU that terminates the RRC connection of the RAN node embedded in the RAN node DU 1211 (e.g., the address and / or identifier of the IAB donor CU of the MT serving the IAB node). The CONFIGURATION UPDATE message 1233 may also include at least one of the following:

[0282] - an identifier of the mobile terminal (MT) for the RAN node embedded in the RAN node DU 1231 (e.g., a non-F1 terminating IAB donor UE XnAP ID or an RRC terminating IAB donor UE XnAP ID), made known to the RAN node CU at which the RRC connection of the RAN node embedded in the RAN node DU 1231 is terminated,

[0283] - the BAP address of the MT of the RAN node embedded in the RAN node DU 1231, assigned by the RAN node CU that terminates the RRC connection of the RAN node embedded in the RAN node DU 1231,

[0284] - Identifier of the RAN node DU 1231 gNB-DU ID.

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

[0286] The identifier of the mobile terminal (MT) for the RAN node may be provided by the RAN node CU that terminates the RRC connection of the RAN node embedded in the RAN node DU 1231.

[0287] According to an example, Figure 12d The flow in

[1234] corresponds to the procedure gNB-DU Configuration Update described in Section 8.2.4 of TS 38.473 V17.2.0, modified to include the above information elements. Message 1233 corresponds to the message GNB-DU CONFIGURATION UPDATE described in Section 9.2.1.7 of TS 38.473 V17.2.0, and message 1234 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in Section 9.2.1.8 of TS 38.473 V17.2.0.

[0288] Figure 13a is a schematic simplified diagram 1300 illustrating an example message flow according to a procedure used by a RAN node CU to report configuration information to another RAN node CU.

[0289] The figure shows two RAN nodes, namely RAN node CUa 1301 and RAN node CUb 1302, which may be as follows Figure 5 Two IAB donor CUs such as two of the IAB donor CUs 501, 502 and 503. Figure 8 In the example shown, the RAN node CUa 1301 may be the target F1 donor CU 807 and the RAN node CUb 1302 may be the source F1 donor CU 803 depending on the purpose of the message.

[0290] The message CONFIGURATION UPDATE 1303 is sent by the RAN node CUa 1301 to the RAN node CUb 1302 to inform the RAN node CUb 1302 of the activation of new cell(s) in a logical DU of the RAN node DU such as IAB-DU2 806 of the IAB node 801 .

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

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

[0293] Message 1303 may also include at least one of the following:

[0294] the identifier of the migrating RAN node known to the RAN node CUa 1301 using the information element F1 terminating IAB donor UE XnAP ID identifying the mobile terminal (MT) of the migrating RAN node and / or using the information element gNB-DU ID identifying the logical DU of the migrating RAN node with which the RAN node CUa 1301 has an F1 connection,

[0295] - Identifier of the MT of the migrated RAN node known by the RAN node CU terminating the RRC connection with the migrated RAN node through the information element non-F1 terminating IAB donor UE XnAP ID or RRC terminating IAB donor UE XnAP ID

[0296] the identifier of the migrated RAN node known to the RAN node CUb 1302 using the information element Target F1 Termination IAB Donor UE XnAP ID identifying the mobile terminal (MT) of the migrated RAN node and / or the identifier gNB-DU ID of the logical DU of the migrated RAN node having F1 connection with the RAN node CUb 1302,

[0297] - The BAP address of the MT of the migrated RAN node assigned by the RAN node CU that terminated the RRC connection of the migrated RAN node.

[0298] The RAN node CUb 1302 replies with a message CONFIGURATION ACKNOWLEDGE 1304 sent to the RAN node CUa 1301 to acknowledge the receipt of the message 1303 .

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

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

[0301] The figure shows two RAN nodes, namely RAN node CUa 1311 and RAN node CUb 1312, which may be as follows Figure 5 Two IAB donor CUs such as two of the IAB donor CUs 501, 502 and 503.

[0302] The message MIGRATION REQUEST 1313 is sent by the RAN node CUa 1311 to the RAN node CUb 1312 to request the traffic migration setup, modification or release in the IAB topology controlled by the RAN node CUb 1312. For example, Figure 8 , after the DU has migrated to the target F1 donor CU 807 and the MT 804 of the IAB node 801 has migrated to the non-F1 / RRC donor CU ( Figure 8In the case where the DU has been migrated to the target F1 donor CU 807 and the MT 804 of the IAB node 801 has been migrated to the non-F1 donor CU, the target F1 donor CU 807 may send a MIGRATION REQUEST 1313 to the non-F1 donor CU to request that traffic (e.g., F1 traffic) be released from the target F1 donor CU 807 through the IAB topology managed by the non-F1 donor CU. Alternatively, in the case where the DU has been migrated to the target F1 donor CU 807 and the MT 804 of the IAB node 801 has been migrated to the non-F1 donor CU, the target F1 donor CU 807 may send a MIGRATION REQUEST 1313 to the non-F1 donor CU to request that traffic (e.g., F1 traffic) be migrated to the non-F1 donor CU's topology (i.e., because the F1 traffic is now to be routed from the target F1 donor CU 807 through the IAB topology managed by the non-F1 donor CU).

[0303] In another example, a MIGRATION REQUEST message 1313 is sent by the RAN node CUa 1311 to the RAN node CUb 1312 to notify the DU migration of the IAB node. When the RAN node CUb 1312 confirms with a MIGRATION RESPONSE message 1314, the RAN node CUb 1312 may include an identifier that the RAN node CUb 1312 has allocated for the migrated IAB node, such as an information element Target F1 terminating IAB donor UE XnAP ID that identifies the mobile terminal (MT) of the migrated IAB node.

[0304] Message 1313 may include at least one of the following:

[0305] - Traffic migration release is an indication caused by DU migration from the IAB node 801 towards the target F1 donor CU 807,

[0306] - the identifier of the migrated IAB node known to the source F1 donor CU 803 and the non-F1 donor CU using the information elements F1-terminating IAB donor UE XnAP ID and non-F1-terminating IAB donor UE XnAP ID (or RRC-terminating IAB donor UE XnAP ID), and / or the BAP address allocated by the non-F1 donor CU for the migrated IAB node,

[0307] - an identifier of the target F1 donor CU 807 (i.e., TNL / IP address and / or global NG-RAN node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3),

[0308] - Identifier gNB-DU ID of the logical DU of the IAB node 801 served by the target F1 donor CU 807 (as specified in TS 38.473 section 9.3.1.19).

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

[0310] Depending on the situation, Figure 13b This may correspond to the IAB transport migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0. Message 1313 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in Section 9.1.4.2 of TS 38.423 V17.2.0, and message 1314 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in Section 9.1.4.3 of TS 38.423 V17.2.0. If the transport migration management procedure is the transport migration management procedure specified in Section 8.5.2 of TS 38.423 V17.2.0 (which may be referred to as a legacy procedure), the target F1 donor CU 807 should know the UE XnAP ID assigned by the non-F1 donor CU. If the F1 Setup Request message from the migrated IAB node provides only the BAP address, then it should (by Figure 13a If the transport migration management process is modified to allow the BAP address to be provided instead of the UE XnAP ID, then it is possible (by referring to Figure 13a The process described in ( ) only provides the BAP address to the target F1 donor CU.

[0311] Figure 13bIt may also correspond to the IAB Transport Migration Modification procedure specified in Section 8.5.3 of TS 38.423 V17.2.0. Message 1313 corresponds to the IAB Transport Migration Modification Request message specified in Section 9.1.4.4 of TS 38.423 V17.2.0, and message 1314 corresponds to the IAB Transport Migration Modification Response message specified in Section 9.1.4.5 of TS 38.423 V17.2.0.

[0312] In other words and as an overview, it can be noted that a mobile IAB node can be partially migrated as other IAB nodes according to Release 17. Furthermore, this mobile IAB-MT (mIAB-MT) handover is driven by radio conditions and should not be delayed in order to maintain backhaul connectivity and avoid service interruption at the served UE.

[0313] Therefore, it can be observed that the mAB-MT handover should not be delayed to maintain the backhaul connectivity and avoid service interruption at the served UE.

[0314] Based on this first observation, it may happen that an mIAB-MT handover is triggered and executed while the migration of a co-located mobile IAB-DU (mIAB-DU) is in progress. Therefore, even if the target donor CU for the mIAB-DU migration is limited to the donor CU of the mIAB-MT, in some cases, the F1-terminating donor CU after the mIAB-DU migration may end up being different from the non-F1-terminating donor CU after the handover of the co-located mIAB-MT.

[0315] Therefore, considering that the mAB-MT switching should not be delayed may lead to a situation where the mAB-MT and its co-located mAB-DU can be switched / migrated to different donor CUs.

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

[0317] Then, it can be noted that the criteria for selecting the target donor CU for the mobile IAB node depends on the migration type, ie MT handover or DU migration.

[0318] Therefore, based on the above observations, for the purpose of flexible and smooth IAB network management, it should be supported that the mAB-MT and its co-located mAB-DU can be switched / migrated to different donor CUs.

[0319] Furthermore, if the target F1 donor CU is different from the non-F1 donor CU, the target F1 donor CU should be informed of the current non-F1 donor CU of the co-located mIAB-MT serving the mobile IAB node. This will allow the target F1 donor CU to set up an IAB transport migration towards the topology of the non-F1 donor CU.

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

[0321] In case of concurrent MT handover and DU migration for a mobile IAB node, the DU migration may suffer from delays or failures due to the modification of the backhaul path used to communicate with the mobile IAB node.

[0322] To be more precise on the potential problem, consider the case where the mobile IAB node has successfully performed an F1 setup procedure with a target F1 donor CU for DU migration purposes, and the target F1 donor CU is different from the non-F1 donor CU for the mobile IAB node. If, in the meantime, an MT migration of the mobile IAB node has occurred towards a target non-F1 donor CU (still different from the target F1 donor CU), the target F1 donor CU may not be aware of the new non-F1 donor CU for transport migration management (TMM) procedures.

[0323] It can be noted that when the CU of the target logical mAB-DU is different from the CU of the mAB-MT, the CU of the target logical mAB-DU needs to be informed of the CU ID and the mAB-MT ID of the mAB-MT so that the Xn TMM process can be initiated towards the CU of the mAB-MT.

[0324] However, this statement may not be accurate enough to prevent any deadlock situations in the case of concurrent MT and DU migrations. In fact, it is not stated when the target F1 donor CU (i.e., the CU of the target logical mAB-DU) is informed of the non-F1 donor CU (i.e., the CU ID of the mAB-MT). If the target F1 donor CU is informed before MT migration, the target F1 donor CU will trigger the TMM process towards the donor CU, which may no longer be the non-F1 donor CU.

[0325] Therefore, the above statement can be completed as follows: if the CU of the mAB-MT changes during DU migration, the CU of the target logical mAB-MT needs to be informed of the CU ID and the mAB-MT ID of the target mAB-MT before the CU of the target logical mAB-MT can initiate the TMM process towards the CU of the target mAB-MT.

[0326] As can be seen from the above examples, some adjustments may be required to the MT and DU migration process to avoid deadlock situations and to limit the impact of concurrent MT and DU migrations to some delay to complete the process.

[0327] To proceed, there are 3 options:

[0328] - Option 1: Consider the independent processes as job assumptions, define the processes accordingly, and then in a second step refine (if necessary) the processes to support concurrent DU and MT migrations,

[0329] - Option 2: Treat concurrent DU and MT migrations as job assumptions and define the process accordingly,

[0330] - Option 3: Do not support concurrent DU and MT migrations, define the procedures independently, and add necessary mechanisms in the second step to avoid such concurrency.

[0331] It can be observed that Mobile IAB-MT migration is driven by radio conditions and should not be delayed to maintain backhaul connectivity and avoid service disruption at the served UE. This means that Mobile IAB-MT handover can be triggered and performed while migration of a co-located Mobile IAB-DU is ongoing.

[0332] Furthermore, option 2 appears to be more efficient than option 1 when considering support for concurrent DU and MT migrations.

[0333] Therefore, if concurrent DU and MT migrations must be supported, the procedures for MT and DU migrations are defined taking into account the possible concurrency of DU and MT migrations (option 2).

[0334] When providing identification information to the target F1 donor CU, one issue to be addressed is which node informs the target F1 donor CU for DU migration of the mobile IAB node of identification information related to non-F1 donor CUs (i.e., CU ID and mLAB-MT ID of mLAB-MT).

[0335] For providing nodes, there are three options to consider:

[0336] - Option 1: Source F1 Donor CU In this case, the source F1 Donor CU may relay the identification information previously received from the source non-F1 Donor CU at the MT migration of the mobile IAB node to the target F1 Donor CU.

[0337] - Option 2: Non-F1 donor CU In this case, the source F1 donor CU should have provided the non-F1 donor CU with identification information related to the target F1 donor CU.

[0338] - Option 3: Migrating IAB Node. In this case, the non-F1 donor CU should have provided identification information to the IAB node.

[0339] Therefore, the following three options may be considered to provide identification information related to the non-F1 donor CU (i.e., CU ID and mIAB-MT ID of the mIAB-MT) to the target F1 donor CU for DU migration of the mobile IAB node:

[0340] - Option 1: Source F1 donor CU,

[0341] - Option 2: Source non-F1 donor CU,

[0342] - Option 3: Migrating IAB nodes.

[0343] Option 2 may be the appropriate option as it fits the following statement:

[0344] The source donor CU for the mAB-MT HO provides at least the following to the donor CU serving the mAB-DU:

[0345] - gNB ID of the target donor CU for mIAB-MT HO.

[0346] - ID(s) of mIAB-MT.

[0347] As described above, in case of concurrent MT handover and DU migration of a mobile IAB node, the DU migration may be delayed or fail due to the modification of the backhaul path for communication with the mobile IAB node.

[0348] To be more precise on the potential problem, consider the following scenario: the mobile IAB node has successfully performed an F1 setup procedure with a target F1 donor CU for DU migration purposes, and the target F1 donor CU is different from the non-F1 donor CU for the mobile IAB node. If, in the meantime, an MT migration of the mobile IAB node has occurred towards a target non-F1 donor CU (still different from the target F1 donor CU), the target F1 donor CU may not be aware of the new non-F1 donor CU for transport migration management (TMM) procedures.

[0349] It can be noted that, if the CU of the target logical mAB-DU is different from the CU of the mAB-MT, the CU of the target logical mAB-DU needs to be informed of the CU ID and the mAB-MT ID of the mAB-MT so that the CUXn TMM procedure toward the mAB-MT can be initiated.

[0350] However, this statement may not be accurate enough to prevent any deadlock situations in the case of concurrent MT and DU migrations. In fact, it is not stated when the target F1 donor CU (i.e., the CU of the target logical mAB-DU) is informed of the non-F1 donor CU (i.e., the CU ID of the mAB-MT). If the target F1 donor CU is informed before MT migration, the target F1 donor CU will trigger the TMM process towards the donor CU, which may no longer be the non-F1 donor CU.

[0351] Therefore, the above statement can be completed as follows: if the CU of the mAB-MT changes during DU migration, the CU of the target logical mAB-MT needs to be informed of the CU ID and the mAB-MT ID of the target mAB-MT before the CU of the target logical mAB-MT can initiate the TMM process towards the CU of the target mAB-MT.

[0352] As can be seen from the above examples, some adjustments may be required to the MT and DU migration process to avoid deadlock situations and to limit the impact of concurrent MT and DU migrations to some delay to complete the process.

[0353] Assuming that the mAB-MT handover (or migration) and the mAB-DU migration are separate processes, it is not excluded that the two migrations may overlap in time. To proceed, there are 3 options:

[0354] - Option 1: Treat concurrent DU and MT migrations as an operational assumption, define the process without considering potential concurrency in the first step, and then refine (if necessary) the process in the second step to support concurrent DU and MT migrations,

[0355] - Option 2: Treat concurrent DU and MT migrations as job assumptions and define the process accordingly,

[0356] - Option 3: Do not support concurrent DU and MT migrations, define the process, and add necessary mechanisms in a second step to avoid such concurrency.

[0357] It can be observed that Mobile IAB-MT migration is driven by radio conditions and should not be delayed to maintain backhaul connectivity and avoid service disruption at the served UE. This means that Mobile IAB-MT handover can be triggered and performed while migration of a co-located Mobile IAB-DU is ongoing.

[0358] Furthermore, option 2 appears to be more efficient than option 1 when considering support for concurrent DU and MT migrations.

[0359] Therefore, if concurrent DU and MT migrations must be supported, the procedures for MT and DU migrations are defined taking into account the possible concurrency of DU and MT migrations (option 2).

[0360] When providing identification information to the target F1 donor CU, one issue to be addressed is which node informs the target F1 donor CU for DU migration of the mobile IAB node of identification information related to non-F1 donor CUs (i.e., CU ID and mLAB-MT ID of mLAB-MT).

[0361] There are two options for providing the gNB-ID of the CU of the mAB-MT and the XnAPUE ID of the mAB-MT at that CU to the target CU of the mAB-DU:

[0362] • Option A: XnAP signaling from the source CU of the mIAB-DU.

[0363] Option B: F1AP signaling from the target logical mAB-DU.

[0364] It may be noted that both options can support concurrent MT and DU migrations, depending on the manner in which they are performed.

[0365] With option A, the source F1 donor CU may relay the identification information previously received from the source non-F1 donor CU at the MT migration of the mobile IAB node to the target F1 donor CU. In this case, the XnAP procedure NG-RAN node configuration update procedure may be appropriate.

[0366] With option B, providing identification information through the F1 setup procedure may not be sufficient: in case the non-F1 donor CU changes after the F1 setup procedure is completed, the target F1 donor CU will not be aware of the new non-F1 donor CU for TMM procedures. Therefore, the F1AP procedure gNB-DU configuration update may be appropriate as it can be triggered at any time (e.g. when the non-F1 donor CU has changed).

[0367] For the downward selection (ie, for selecting an option between Option A and Option B), Option A appears to be more straightforward than Option B because it does not involve the migrating IAB node as an intermediate node.

[0368] Therefore, it can be proposed that the XnAP signaling from the source CU of the mAB-DU is used to provide the gNB-ID of the CU of the mAB-MT and the XnAP UE ID of the mAB-MT at the CU to the target CU of the mAB-DU.

[0369] Considering that the identifier of the MT of the mobile IAB node (mIAB-MT) can be a BAP address assigned by the IAB donor CU controlling the mIAB-MT (and sent to the mIAB-MT via an RRC protocol message when the mIAB-MT is connected to the IAB donor CU), and the IAB donor CU controlling the mIAB-MT can be called a non-F1 terminating donor CU or an RRC terminating donor CU, it can be further inquired which ID assigned by the MT's CU for the IAB MT should be used for the TMM process and how to map the ID to the corresponding IAB node.

[0370] In practice, the ID allocated by the RRC terminating donor CU (ie, the CU of the mlAB-MT) may be the BAP address or the UE XnAPID.

[0371] The BAP address selected by the RRC terminating donor CU can be provided by the target logical mobile IAB-DU to the target F1 terminating donor CU (i.e., the CU of the mIAB-DU) in the legacy Release 16 / 17 F1 Setup Request message. In the case where only the BAP address is provided (instead of the UE XnAP ID allocated at the RRC terminating donor CU), the TMM request message should be modified to allow the use of the BAP Address IE instead of the non-F1 terminating IAB donor UE XnAP ID IE. In addition, the behavior of the RRC terminating donor CU receiving this TMM request message should be adapted accordingly. In fact, according to the Release 17 specification (TS 38.423), the presence of the F1 terminating donor CU and the UE XnAP ID allocated by the RRC terminating donor CU is mandatory for the TMM procedure.

[0372] In order to avoid modification of the TMM process and the behavior of the IAB donor CU, the UE XnAPID allocated at the RRC termination donor CU should be provided to the target F1 termination donor CU. For this purpose, there are two options:

[0373] - F1AP signaling from the target logical mobile IAB-DU, e.g., using an F1 Setup Request message or a gNB-DU Configuration Update message. This option involves pre-provisioning the UE XnAP ID to the mobile IAB node, e.g., via RRC over an RRC-terminating donor CU. With this option, the BAP address does not need to be provided in the F1 Setup Request message.

[0374] - XnAP signaling from the source F1 terminating donor CU. This option may involve the introduction of a new XnAP procedure. Furthermore, to avoid any confusion in the event of simultaneous DU migrations of several mobile IAB nodes, additional information known to the target F1 terminating donor CU should be provided along with the UE XnAP ID. This additional information may be the BAP address selected by the RRC terminating donor CU for the mobile IAB node (assuming this BAP address is present in the F1 Setup Request message from the target logical mobile IAB-DU to the target F1 terminating donor CU, and assuming this BAP address is also available at the source F1 terminating donor CU).

[0375] Based on the above considerations, we can conclude that there is less regulatory impact when choosing F1AP signaling from the target mobile IAB-DU for conveying the ID of the mobile IAB MT to the target F1 terminating donor CU, and it is preferable to use UE XnAP ID for identification of the mobile IAB-MT.

[0376] Therefore, it is proposed that, for the case of DU migration of a mobile IAB node, F1AP signaling from the target mobile IAB-DU is selected for conveying the UE XnAP ID of the mobile IAB MT (at the RRC terminating donor CU) to the target F1 terminating donor CU.

[0377] Considering the network integration scenario, there are two options for delivering the identification information to the F1 terminating donor CU (i.e., the CU of the mAB-DU):

[0378] - Option 1: Through F1AP signaling, the mobile IAB node provides identification information based on the information received from the RRC terminating donor CU (i.e., the CU of the mIAB-MT),

[0379] - Option 2: Through XnAP signaling, once the RRC terminating donor CU knows the identifier of the F1 terminating donor CU from the mobile IAB node, the RRC terminating donor CU provides the identification information.

[0380] With option 2, the RRC terminating donor CU shall provide an identifier of the mobile IAB node known by the F1 terminating donor CU. This identifier may be the BAP address of the mobile IAB-MT selected by the RRC terminating donor CU, assuming that the BAP address is present in the F1 Setup Request message from the mobile IAB-DU to the F1 terminating donor CU.

[0381] With option 1, the F1AP signaling can be the same as that of the DU migration case. In addition, there seems to be less regulatory impact with option 1 than with option 2.

[0382] Therefore, it is proposed that: for the case of network integration of mobile IAB nodes, F1AP signaling from the mobile IAB-DU is selected to be used to convey the gNB-ID of the RRC termination donor CU and the UE XnAP ID of the mobile IAB MT (at the RRC termination donor CU) to the F1 termination donor CU.

[0383] It is assumed that the same F1AP signaling is used to transmit identification information during DU migration and network integration of the mobile IAB node. However, for consistency, the mobile IAB node should also provide identification information related to the target RRC termination donor CU during MT migration.

[0384] Therefore, it is proposed that: for the case of MT integration of the mobile IAB node, F1AP signaling from the mobile IAB-DU is selected to be used to convey the gNB-ID of the target RRC termination donor CU and the UE XnAP ID of the mobile IAB MT (at the RRC termination donor CU) to the F1 termination donor CU.

[0385] In case of MT migration, the F1AP procedure gNB-DU configuration update is applicable to inform F1 of the terminating donor CU.

[0386] The mobile IAB node may then use the gNB-DU Configuration Update procedure to inform the F1 terminating donor CU of the gNB-ID of the RRC terminating donor CU and the UE XnAP ID of the mobile IAB-MT at that CU.

[0387] It can be observed that the source donor CU of the mIAB-MT can send information about the target donor CU of the mIAB-MT to the donor CU of the mIAB-DU after the IAB-MT HO (handover) is completed. In fact, since the source RRC termination donor CU (i.e., the source donor CU of the mIAB-MT) does not pass the information directly to the F1 termination donor CU (i.e., the donor CU of the mIAB-DU) but rather passes it through the mobile IAB node, this proposal is compatible with this statement.

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

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

[0390] In the foregoing embodiments, 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 or transmitted via a computer-readable medium and executed by a hardware-based processing unit.

[0391] 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 facilitates, for example, the transfer of a computer program from one location to another according to a communication protocol. In this manner, computer-readable media may generally correspond to (1) a non-transitory, tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures to implement the techniques described in this disclosure. A computer program product may include computer-readable media.

[0392] As an example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage units, disk storage units or other magnetic storage devices, flash memory or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, 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 a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwave, coaxial cable, optical fiber cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave can be included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connection, carrier wave, signal or other transient media, but point to non-transient tangible storage media. As used herein, disk (disk and disc) include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blue disc, wherein disk (disk) usually reproduces data magnetically, and disk (disc) reproduces data optically with laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for managing transport migration of traffic associated with an IAB node, wherein the transport migration is to be performed after a DU of the IAB node has been migrated from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, and CU stands for Central Unit. The method includes, at the target IAB donor CU: receiving a notification including identification information for identifying an IAB donor CU of a mobile terminal (MT) serving the IAB node, wherein the IAB donor CU of the MT serving the IAB node is different from the target IAB donor CU; Based on the identification information and after the DU of the IAB node has been migrated to the target IAB topology, transport migration for migrating traffic related to the IAB node is performed to be routed on at least one path between the target IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT.

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

3. The method according to claim 1, wherein The IAB donor CU serving the MT is a second IAB donor CU managing a second IAB topology, wherein the path between the target IAB donor CU and the MT of the IAB node passes through the second IAB topology.

4. A method according to any one of the preceding claims, wherein Receiving a notification includes receiving a notification from the source IAB donor CU.

5. The method according to claim 4, wherein The notification is included in the DU migration notification message.

6. The method according to claim 4, wherein: The notification is included in a configuration update message.

7. The method according to any one of claims 1 to 3, wherein Receiving a notification includes receiving a notification from the IAB node.

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

9. The method according to claim 3, wherein: Receiving the notification includes receiving the notification from the second IAB donor CU.

10. The method according to claim 9, wherein: The notification is used to indicate that the second IAB donor CU is ready for transmission migration of traffic of the IAB node, and the notification includes identification information used to identify the second IAB donor CU.

11. The method according to claim 10, wherein: The notification is included in a transport migration ready message.

12. A method according to any one of the preceding claims, wherein The notification further includes identification information of the MT for identifying the IAB node.

13. A method for managing a migration process for migrating a DU of an IAB node from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, and CU stands for Central Unit. The method includes, at the source IAB donor CU: Determining that the DU of the IAB node is to be migrated to the target IAB donor CU; A request for establishing an F1 connection between the target IAB donor CU and the IAB node is sent to the IAB node.

14. The method according to claim 13, wherein: The sending includes sending a request, where the request is used to establish an F1 connection between the target IAB donor CU and the IAB node and to inform the target IAB donor CU of the identity of the IAB donor CU of the MT serving the IAB, wherein the MT is a mobile terminal.

15. The method according to claim 13 or 14, wherein: The request is included in a DU Activation Request message.

16. The method according to claim 13, 14 or 15, wherein: The request includes an IE, which is used to instruct the IAB node to inform the target IAB donor CU of the identifier of the IAB donor CU serving the MT of the IAB node, wherein the IE is an information element.

17. The method according to any one of claims 13 to 16, wherein The request includes identification information for identifying the IAB donor CU serving the MT.

18. The method according to any one of claims 13 to 17, wherein The request includes information for indicating to the IAB node that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT.

19. The method according to claim 18, wherein In a case where the target IAB donor CU is an IAB donor CU different from the IAB donor CU serving the MT of the IAB node, the request includes the information.

20. A method for migration processing, wherein the migration processing is used to migrate a DU of an IAB node from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, and CU stands for Central Unit. The method includes, at the source IAB donor CU: Determining that the DU of the IAB node is to be migrated to the target IAB donor CU; Sending a notification including identification information of the IAB donor CU for identifying the MT serving the IAB node to the target IAB donor CU, where the MT is a mobile terminal; Migrate the DU of the IAB node to the DU of the target IAB topology.

21. The method according to claim 20, wherein The notification is included in the DU migration notification message.

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

23. The method according to any one of claims 20 to 22, wherein The notification further includes identification information of the MT for identifying the IAB node.

24. The method according to any one of claims 20 to 22, wherein The sending includes: when the target IAB donor CU is an IAB donor CU different from the IAB donor CU serving the MT of the IAB node, sending a notification including identification information for identifying the IAB donor CU serving the MT of the IAB node to the target IAB donor CU.

25. A method for migration processing, wherein the migration processing is used to migrate a DU of an IAB node from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, and CU stands for Central Unit. The method includes, at the IAB node: An F1 setup request for requesting to set up an F1 connection is sent to the target IAB donor CU, wherein the F1 setup request includes identification information of the IAB donor CU for identifying the MT serving the IAB node, wherein the MT is a mobile terminal.

26. The method according to claim 25, further comprising: A request for establishing an F1 connection between the target IAB donor CU and the IAB node is received from the source IAB donor CU.

27. The method of claim 25, further comprising: A request is received from the source IAB donor CU, the request being used to establish an F1 connection between the target IAB donor CU and the IAB node and to inform the target IAB donor CU of an identity of the IAB donor CU serving the MT of the IAB node.

28. The method according to claim 26 or 27, wherein The request for establishing the F1 connection includes information indicating that the IAB node is to inform the target IAB donor CU of the identity of the IAB donor CU serving the MT of the IAB node.

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

30. The method according to any one of claims 25 to 29, wherein The F1 setting request includes identification information of the MT for identifying the IAB node.

31. The method according to any one of claims 25 to 30, wherein The sending includes: when the target IAB donor CU is an IAB donor CU different from the IAB donor CU serving the MT of the IAB node, sending the F1 setup request including identification information for identifying the IAB donor CU serving the MT to the target IAB donor CU.

32. A method for managing transport migration of traffic associated with an IAB node, the transport migration being performed after a DU of the IAB node has migrated from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, and a MT of the IAB node has migrated to a second IAB donor CU, the second IAB donor CU being an IAB donor CU different from the target IAB donor CU and the source IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, CU stands for Central Unit, and MT stands for Mobile Terminal. The method at the second IAB donor CU includes: After the DU of the IAB node has been migrated to the target IAB topology, a transport migration release message is received, wherein the transport migration release message is used to request the release of the transport migration set by the source IAB donor CU for traffic related to the IAB node. and sending a notification to the target IAB donor CU, the notification being used to indicate that the second IAB donor CU is ready for transmission migration of traffic related to the IAB node on at least one path between the target IAB donor CU and the IAB node through an IAB topology managed by the second IAB donor CU, the notification including identification information for identifying the second IAB donor CU.

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

34. The method according to claim 32 or 33, wherein After receiving the transport migration release message, the transport migration previously set by the source IAB donor CU is released.

35. The method according to claim 34, wherein The release includes: IAB nodes involved in routing traffic to and / or from the IAB nodes are reconfigured by deleting configuration information associated with routing traffic to and / or from the IAB nodes at each IAB node.

36. The method according to claim 32 or 33, wherein After receiving the transport migration release message, the transport migration previously set by the source IAB donor CU is suspended.

37. The method according to claim 36, wherein The suspending includes: suspending traffic migration and maintaining configuration of one or more IAB nodes in one or more routing paths set by the source IAB donor CU for traffic related to the IAB node.

38. The method according to any one of claims 32 to 37, wherein The notification includes identification information of the MT for identifying the IAB node.

39. The method according to any one of claims 32 to 38, wherein The transport migration release message includes information indicating that the traffic migration release is caused by DU migration of the IAB node toward the target IAB donor CU.

40. A method for migration processing, wherein the migration processing is used to migrate a DU of an IAB node from a source IAB topology managed by a source IAB donor CU to a target IAB topology managed by a target IAB donor CU, wherein: IAB stands for Integrated Access Backhaul, DU stands for Distributed Unit, and CU stands for Central Unit. The method includes, at the IAB node: A notification including identification information of the IAB donor CU for identifying the MT serving the IAB node is sent to the target IAB donor CU, where the MT is a mobile terminal.

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

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

43. The method according to any one of claims 40 to 42, wherein The sending includes: after the F1 connection between the DU of the IAB node and the target IAB donor CU is set up, sending a notification including identification information of the IAB donor CU for identifying the MT serving the IAB node to the target IAB donor CU, where the MT is a mobile terminal.

44. A method according to any one of the preceding claims when dependent on a corresponding one of claims 12, 23, 30, 38 and 41, wherein The identification information for identifying the MT of the IAB node includes at least one of a UE XnAP ID and a BAP address.

45. A device for an IAB donor CU node of an IAB communication system, wherein: IAB stands for Integrated Access Backhaul, and CU stands for Central Unit. The equipment includes: One or more processing units configured to: receiving a notification including identification information for identifying an IAB donor CU of a MT serving an IAB node of the IAB communication system, wherein the IAB donor CU of the MT serving the IAB node is different from the IAB donor CU; Based on the identification information and after the DU of the IAB node has been migrated to the IAB topology managed by the IAB donor CU, transport migration for migrating traffic related to the IAB node is performed to be routed on at least one path between the IAB donor CU and the IAB node through the IAB topology managed by the IAB donor CU serving the MT.

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

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

48. Apparatus according to any one of claims 45 to 47, wherein The notification further includes identification information of the MT for identifying the IAB node.

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

50. A device for an IAB donor CU node of an IAB communication system, wherein: IAB stands for Integrated Access Backhaul, and CU stands for Central Unit. The equipment includes: One or more processing units configured to perform the method according to any one of claims 1 to 24 and claims 32 to 39 and claim 44.

51. A device for an IAB node of an IAB communication system, wherein: IAB stands for Integrated Access Backhaul, and the equipment includes: One or more processing units are configured to send an F1 setup request for requesting to set up an F1 connection to a target IAB donor CU, wherein the F1 setup request includes identification information of the IAB donor CU for identifying the MT serving the IAB node, wherein the MT is a mobile terminal.

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

53. Apparatus according to claim 51 or 52, wherein The F1 setting request includes identification information of the MT for identifying the IAB node.

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

55. Apparatus according to any one of claims 51 to 54, wherein The one or more processing units are configured to, if the target IAB donor CU is an IAB donor CU different from the IAB donor CU serving the MT of the IAB node, send the F1 setup request including identification information for identifying the IAB donor CU serving the MT to the target IAB donor CU.

56. A device for an IAB node of an IAB communication system, wherein: IAB stands for Integrated Access Backhaul, and the equipment includes: One or more processing units configured to perform the method according to any one of claims 25 to 31 and claims 40 to 44.

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

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

Images