Nothing Special   »   [go: up one dir, main page]

WO2024170232A1 - Migration of nodes in an iab communication system - Google Patents

Migration of nodes in an iab communication system Download PDF

Info

Publication number
WO2024170232A1
WO2024170232A1 PCT/EP2024/051544 EP2024051544W WO2024170232A1 WO 2024170232 A1 WO2024170232 A1 WO 2024170232A1 EP 2024051544 W EP2024051544 W EP 2024051544W WO 2024170232 A1 WO2024170232 A1 WO 2024170232A1
Authority
WO
WIPO (PCT)
Prior art keywords
lab
donor
node
iab
target
Prior art date
Application number
PCT/EP2024/051544
Other languages
French (fr)
Inventor
Pierre Visa
Pascal Lagrange
Original Assignee
Canon Kabushiki Kaisha
Canon Europe Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB2302171.0A external-priority patent/GB2627227A/en
Application filed by Canon Kabushiki Kaisha, Canon Europe Limited filed Critical Canon Kabushiki Kaisha
Publication of WO2024170232A1 publication Critical patent/WO2024170232A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/14Relay systems
    • H04B7/15Active relay systems
    • H04B7/155Ground-based stations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/06Reselecting a communication resource in the serving access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • H04W36/087Reselecting an access point between radio units of access points
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/34Modification of an existing route
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/34Modification of an existing route
    • H04W40/36Modification of an existing route due to handover
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • H04W84/042Public Land Mobile systems, e.g. cellular systems
    • H04W84/047Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/04Terminal devices adapted for relaying to or from another terminal or user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08Access point devices
    • H04W88/085Access point devices with remote components
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/20Interfaces between hierarchically similar devices between access points

Definitions

  • the present invention generally relates to methods for use in a process for migrating nodes and traffic between Integrated Access and Backhaul, IAB, topologies of a wireless communication system involving mobile lAB-nodes.
  • the present invention relates to a method for use in a migration process in which a Distributed Unit, DU, of an lAB-node, for example a mobile lAB-node, is migrated between IAB topologies and a method for use in managing transport migration after DU migration of an lAB-node.
  • DU Distributed Unit
  • Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC).
  • Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations.
  • the base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH).
  • BH backhaul
  • wireless multiple-access communication systems examples include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi.
  • 3GPP - RTM 3rd generation partnership project
  • 4G fourth-generation Long Term Evolution
  • 5G fifth-generation
  • NR New Radio
  • 3GPP has proposed, from release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber.
  • the wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs).
  • IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations.
  • IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate.
  • mmWave millimeter wave
  • Gbps gigabits per second
  • millimeter waves are known to be subject to strong attenuations of signal strength in some weather conditions (rain, fog), and to blockage in case of obstacles located in the path between the emitter and the receiver.
  • a topological redundancy can be provided within the IAB framework, where multiple data paths are set up between the IAB base station directly connected to the core network (also referred to as the “IAB-donor”) and the IAB base station serving UEs (also referred to as the “access lAB-node” for the UEs).
  • IAB-donor the IAB base station directly connected to the core network
  • IAB base station serving UEs also referred to as the “access lAB-node” for the UEs.
  • Several intermediate IAB base stations also referred to as lAB-nodes
  • 3 GPP has been considering inter-donor redundancy, where an lAB-node, referred to as a boundary lAB-node, can access two different parent nodes connected to two different lAB-donors, with each of the lAB-donors managing a different IAB topology (also referred to as IAB network).
  • the boundary lAB-node even though belonging to a single IAB topology, i.e. belonging to a single IAB-donor for configuration and management, is thus able to route packets from a first IAB topology managed by a first IAB-donor to a second IAB topology managed by a second IAB-donor.
  • inter-donor redundancy lies in the ability for the first IAB-donor to perform offloading by routing some of its packets through the second IAB topology, thus mitigating congestion issues or overcoming radio link failure issues that may arise in the first IAB topology.
  • an lAB-node becomes a boundary node.
  • the IAB-donor where the Mobile Termination (MT) of the lAB-node becomes connected to a single parent lAB-node belonging to another IAB topology controlled by another IAB-donor.
  • MT Mobile Termination
  • This situation may also happen in the case of an lAB-node that experienced radio link failure (RLF) and that has recovered through a parent lAB-node belonging to another IAB topology.
  • RLF radio link failure
  • the migrated lAB-node and its potential descendant lAB-node(s) still belong to the initial IAB topology, and such partial migration may be called MT migration.
  • MT migration should be followed by traffic migration where the traffic related to the boundary node and its descendant lAB-nodes is routed through the other IAB topology up to the boundary node (i.e. the migrated lAB-node).
  • Stationary lAB-nodes should only require a single MT migration.
  • Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public/private passengers transportation, goods delivery, food trucks ). Some of these vehicles (e.g. buses, trams, trains), may have predictable routes and a significant number of collocated UEs (i.e. passengers’ devices). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as mobile relays. These mobile relays would rely on 5G wireless backhaul (typically IAB, or Integrated Access & Backhaul) for connecting to a fixed donor device.
  • 5G wireless backhaul typically IAB, or Integrated Access & Backhaul
  • VMR Vehicle Mounted Relays
  • VMRs The technical benefits of using VMRs include, among others, is the ability of the VMR to offer good radio link conditions to the nearby UEs. Additionally, comparing with a solution using a UE as relay (i.e. a Sidelink Relay solution), an lAB-node mounted on a vehicle is expected to have better RF/antenna capabilities, and to have less stringent power / battery constraints than a relay UE.
  • a solution using a UE as relay i.e. a Sidelink Relay solution
  • an lAB-node mounted on a vehicle is expected to have better RF/antenna capabilities, and to have less stringent power / battery constraints than a relay UE.
  • MT and DU migration should be decorrelated, meaning that a DU migration for an lAB-node may independently occur before or after one or several MT migrations of this lAB-node.
  • the DU migration for an lAB-node may be performed toward an lAB-donor different to the lAB-donor associated to the MT of this lAB-node.
  • the second lAB-donor may have to request a migration of the traffic related to the IAB- node toward the IAB topology controlled by the first lAB-donor.
  • a method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node the transport migration to be performed after a Distributed Unit, DU, of the IAB- node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, the method at the target lAB-donor-CU comprising: receiving a notification including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node, the lAB-donor-CU serving the MT of the lAB-node being a different lAB-donor- CU to the target lAB-donor-CU; based on the identification information and after the DU of the lAB-node has been migrated to the target IAB topology, performing transport migration for
  • the lAB-donor-CU (e.g. RRC donor-CU) serving the MT may be the source IAB- donor-CU if the MT of the lAB-node has not been migrated from the source lAB-donor-CU.
  • the lAB-donor-CU (e.g. non-Fl donor-CU or RRC donor-CU) serving the MT may be another or second lAB-donor-CU managing a second IAB topology. In this latter case, the path between the target lAB-donor-CU and the MT of the lAB-node is through the second IAB topology.
  • the target lAB-donor-CU may receive the notification from the source lAB-donor-CU, from the lAB-node (e.g. in a Fl setup request) or from the lAB-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 lAB-donor-CU before or after performing DU migration).
  • the notification received from the source lAB-donor-CU may be received in a configuration update message.
  • the configuration update message may be sent by the source lAB-donor-CU at any time: for example, before or after performing DU migration, when the source lAB- donor-CU detects a change in the lAB-donor-CU serving the MT.
  • An advantage of being able to send the configuration update message at any time is that the if the source IAB- donor-CU has already provided, to the target lAB-donor-CU, the address and/or identifier of an ‘old’ lAB-donor-CU that had previously served the MT of the lAB-node and which is now ‘old’ because the MT has been migrated to a ‘new’ lAB-donor-CU, then the source IAB- donor-CU can send an update through the configuration update message including identification information for identifying the new lAB-donor-CU.
  • a method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node the transport migration is to be performed after a Distributed Unit, DU, of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, a Mobile Termination, MT, of the lAB-node having been migrated to a second lAB-donor-CU , the second lAB-donor-CU being a different lAB-donor-CU to the target lAB-donor-CU and the source lAB-donor-CU, performed at the second lAB-donor-CU, as recited in any one of claims 32 to 39 or claim 44 of the accompanying claims.
  • the target lAB-donor-CU By sending, whether it’s by the source lAB-donor-CU or the lAB-node or the IAB- donor-CU serving the MT, a notification to the target lAB-donor-CU, which notification includes identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node, the target lAB-donor-CU is informed of the current IAB- donor-CU serving the co-located MT of the lAB-node which enables the target lAB-donor- CU to setup the IAB transport migration toward the topology of the current lAB-donor-CU serving the MT of the lAB-node.
  • any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination.
  • method aspects may be applied to apparatus/device/unit aspects, and vice versa.
  • features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.
  • a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.
  • Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more embodiments
  • FIGa and 2b schematically illustrate stacks of some protocol layers involved into IAB operations
  • FIG. 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet;
  • PDU Protocol Data Unit
  • FIG. 4 is a block schematic diagram of an example wireless communication device in accordance with embodiments of the present invention.
  • FIG. 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;
  • Figure 6 is a schematic and simplified diagram illustrating an example of lAB-node architecture enabling its DU migration from a source IAB topology to a target IAB topology;
  • Figure 7 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to perform DU migration of an lAB-node including the handover of UEs served by the migrating lAB-node;
  • Figure 8 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to identify the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU for the DU migration of an lAB-node;
  • Figure 9a is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an lAB-node, the DU migration of the lAB-node with the identification of a non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
  • Figure 9b is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- node, the DU migration of the lAB-node with the identification of a non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
  • Figure 9c is a flowchart of an example method in accordance with one or more embodiments of the invention, performed at an lAB-node to perform Fl setup request to a target donor-CU while identifying a non-Fl terminating donor-CU (or RRC terminating donor-CU);
  • Figure 9d is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, the transport migration after DU migration of an lAB-node;
  • Figure 10 is a simplified diagram illustrating another example message flow, according to one or more embodiments of the invention, to identify the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU of the DU migration of an lAB-node;
  • Figure 1 la is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- node, the DU migration of the lAB-node with the identification of the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
  • Figure 1 lb is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the non-Fl terminating donor-CU (or RRC terminating donor-CU) of an lAB-node, the transport migration in case of DU migration of the lAB-node;
  • Figure 11c is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an IAB- node, the transport migration in case of DU migration of the lAB-node.
  • Figure 12a is a simplified diagram illustrating an example message flow of a procedure to perform the activation of a logical DU according to one or more embodiments of the invention
  • Figure 12b is a simplified diagram illustrating an example message flow of a procedure to setup a logical DU
  • Figure 12c is a simplified diagram illustrating an example message flow of a procedure to remove a logical DU;
  • Figure 12d is a simplified diagram illustrating an example message flow of a procedure used by a logical DU to inform RAN node CU about a change of configuration
  • 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;
  • Figure 13b is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration in coordination with another RAN node CU;
  • Figure 14 is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, transport migration after DU migration of an lAB-node.
  • Figure 1 illustrates an example communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network supporting mobile lAB-node(s).
  • 5G fifth-generation
  • NR New Radio
  • FIG. 1 illustrates an example communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network supporting mobile lAB-node(s).
  • 5G fifth-generation
  • NR New Radio
  • the system 100 comprises 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 lAB-nodes 121 and 122 (also referred to in the following as IAB- nodes), and a mobile Integrated Access and Backhaul (IAB) station 123 mounted on a vehicle 105 (for example, a bus, a train, a taxi, a car, etc.).
  • UEs User Equipment
  • lAB-nodes also referred to in the following as IAB- nodes
  • IAB- nodes Integrated Access and Backhaul station 123 mounted on a vehicle 105 (for example, a bus, a train, a taxi, a car, etc.).
  • vehicle 105 for example, a bus, a train, a taxi, a car, etc.
  • the main Base Station 120 also referred to as the lAB-donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means.
  • lAB-donor 120 is a 5G NR gNB with additional functionality to support IAB features, as defined in 3GPP TS 38.300 vl7.2.0 specification document.
  • IAB stations 121 and 122 also referred to as lAB-nodes 121 and 122, have been installed by the operator.
  • lAB-nodes 121 and 122 By acting as relaying nodes between the lAB-donor 120 and the UEs 132 and 133, lAB-nodes 121 and 122 allow overcoming the reachability issue resulting from presence of building 108, which is an obstacle to the propagation of radio waves and hence to the direct attachment and further communications between the UEs and the lAB-donor 120. This is particularly true when the communications between the IAB- donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.
  • the lAB-donor 120 also serves UE 134, which is directly connected to it.
  • the mobile IAB station 123 also referred to as mobile lAB-node 123 or mlAB-node 123, is an lAB-node that is mounted on vehicle 105 and provides network coverage and capacity extension, allowing the lAB-donor 120 to reach onboard remote UEs, like remote UE 135, as well as surrounding UEs or UEs in the vicinity of the lAB-node 123, like remote UE 136.
  • the lAB-donor 120 and the lAB-nodes 121, 122 and 123 are thus forming a backhaul network or IAB network, or IAB topology, which accommodates UEs 132, 133, 131, 134, 135 and 136.
  • IAB network and IAB topology will be used interchangeably in the following.
  • IAB Integrated Access and Backhaul
  • RRC Radio Resource Control
  • the lAB-donor 120 is a logical node that provides the NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed unit(s) (DU or gNB-DU functionality).
  • CU central unit
  • DU donor distributed unit
  • the lAB-donor-CU or donor-CU hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling operation of one or more DUs and each of the one or more lAB-donor-DUs or donor-DUs (also referred to in the following as lAB-donor-DU or lAB-donor-DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols.
  • the lAB-donor- CU or donor-CU and lAB-donor-DU or donor-DU may be located far from the other or may be located in the same physical device.
  • the gNB-DU functionality is defined in 3GPP TS 38.401. It aims at terminating the NR access interface to the UEs and next-hop lAB-nodes, and at terminating the Fl protocol to the lAB-donor gNB-CU functionality as shown in Figures 2a and 2b discussed below.
  • the lAB-nodes which may serve multiple radio sectors, are wireless backhauled to the lAB-donor 120, via one or multiple hops over one or more intermediate lAB-nodes. They form a directed acyclic graph (DAG) topology with the lAB-donor at its root.
  • DAG directed acyclic graph
  • the lAB-nodes each consist of an IAB-DU (I AB -Distributed Unit) and an IAB-MT (lAB-Mobile Termination).
  • IAB-DU I AB -Distributed Unit
  • IAB-MT lAB-Mobile Termination
  • the gNB-DU functionality on an lAB-node is also referred to as IAB-DU and allows the downstream (toward the UE) connection to the next-hop IAB or to a UE.
  • the IAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access Stratum (NAS) functionalities to connect to the gNB-DU of an upstream lAB-node (including the lAB-donor 120 in which case it connects to the lAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration).
  • NAS Non Access Stratum
  • the neighbour node on the IAB-DU’ s interface is referred to as child node and the neighbour node on the IAB-MT’ s interface is referred to as parent node.
  • the direction toward the child node is further referred to as downstream while the direction toward the parent node is referred to as upstream.
  • the lAB-donor 120 (e.g. the lAB-donor-CU) performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the lAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data packets.
  • FIGS 2a and 2b schematically illustrate stacks of some protocol layers involved in IAB operations.
  • Fl interface supports the exchange of signalling information (e.g. control traffic) between the endpoints, as well as the data transmission (e.g. user traffic transmission) to the respective endpoints.
  • signalling information e.g. control traffic
  • data transmission e.g. user traffic transmission
  • Fl interface is a point-to-point interface between the endpoints.
  • Fl-C is the functional interface in the Control Plane (CP) between the IAB- donor -CU and an I AB -node -DU (e.g. of I AB -node 2), and between the lAB-donor-CU and an lAB-donor-DU.
  • Fl-U is the functional interface in the User Plane (UP) for the same units.
  • UP User Plane
  • Fl-C and Fl-U are shown by reference 212 in Figure 2a. In this example, Fl-U and Fl-C are carried over two backhaul hops (from I AB -donor to I AB -node 1 and then from I AB -node 1 to IAB-node2).
  • boxes 210 at the lAB-donor-CU and the lAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer.
  • GTP-U stands for GPRS Tunnelling Protocol User Plane.
  • GTP-U Tunnels are used to carry encapsulated PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints (refer to 3GPP TS 29.281 for more details), here boxes 210 at the lAB-donor-CU and the lAB-node DU.
  • the well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram service and fit to use with an IP protocol.
  • boxes 210 indicate the F1AP (Fl Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer.
  • the Fl Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signalling services between the lAB-donor-CU and the lAB-node DU, or UE associated services. These services are for example initialization, configuration, and so on.
  • the well-known SCTP layer provides reliable, in sequence transport of messages with congestion control.
  • Fl-U and Fl-C rely on an IP transport layer between the lAB-donor-CU and the IAB- node DU as defined in 3 GPP TS 38.401.
  • the transport between the lAB-donor-DU and the lAB-donor-CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the lAB- donor-CU is remote from the lAB-donor-DU, or locally in a virtual instantiation of the IAB- donor-CU and the lAB-donor-DU on the same physical machine.
  • IP transport Layer over various media, like for example wires or optical fiber when the lAB- donor-CU is remote from the lAB-donor-DU, or locally in a virtual instantiation of the IAB- donor-CU and the lAB-donor-DU on the same physical machine.
  • lAB-specific transport between lAB-donor-CU and lAB-donor-DU is specified in 3GPP TS 38.401.
  • LI and L2 on the Figure 2a stand respectively for the transport and physical layers appropriate to the medium in use.
  • the IP layer can also be used for non-Fl traffic, such as Operations, Administration and Maintenance traffic.
  • the IP layer On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops.
  • BAP backhaul adaptation protocol
  • the BAP sublayer is specified in TS 38.340.
  • the lAB-DU’s IP traffic is routed over the wireless backhaul via the BAP sublayer.
  • upper layer packets are encapsulated by the BAP sublayer at the lAB-donor-DU, thus forming BAP packets or packet data units (PDUs) or data packets.
  • the BAP packets are routed by the BAP layer or entity (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any.
  • the BAP packets are finally de-encapsulated by the BAP sublayer at the destination lAB-node (which may be an access lAB-node should the upper layer packets in the BAP packets be intended for a UE).
  • upper layer packets are encapsulated by the BAP sublayer at an initiator lAB-node (which may be an access lAB-node should the upper layer packets come from a UE), thus forming BAP packets or data units (PDUs) or data packets.
  • the BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any.
  • the BAP packets are finally deencapsulated by the BAP sublayer at the lAB-donor-DU.
  • FIG. 3 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 17.2.0.
  • PDU BAP Data Protocol Data Unit
  • the payload section 307 is usually an IP packet.
  • the header 30 includes fields 301 to 306.
  • Field 301 is a Boolean indicating whether the corresponding BAP packet is a BAP Data packet or a BAP Control packet.
  • Fields 302-304 are 1 -bit reserved fields, preferably set to 0 (to be ignored by the receiver).
  • Fields 305 and 306 indicate together the BAP routing ID for the BAP packet.
  • BAP address field 305 also referred to as DESTINATION field, is located in the leftmost 10 bits while BAP path identity field 306, also referred to as PATH field, is located in the rightmost 10 bits.
  • Field 305 carries the BAP address (i.e. on the BAP sublayer) of the destination IAB- node or lAB-donor-DU for the BAP packet.
  • each lAB-node and lAB-donor-DU in an IAB network is configured (by lAB-donor-CU of the IAB network) with a designated and unique BAP address.
  • Field 306 carries a path ID identifying the routing path the BAP packet should follow to this destination in the IAB topology.
  • the routing paths including their path ID, are configured (by lAB-donor-CU of the IAB network) in the lAB-nodes of the IAB network.
  • the BAP header is added to the packet when it arrives from upper layers to the BAP layer, and it is stripped off by the BAP layer when it has reached its destination node.
  • the selection of the packet’s BAP routing ID is configured by the lAB-donor-CU.
  • the BAP header with the BAP Routing ID is built by this node according to a configuration table defined in 3GPP TS 38.340. This table is called Downlink Traffic to Routing ID Mapping Configuration table in the lAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the initiator lAB-node.
  • the BAP header fields are already specified in the BAP packet to forward.
  • these configuration tables defining the BAP paths are usually defined by the lAB-donor-CU and transmitted to the lAB-nodes to configure them.
  • the RLC Radio Link Control
  • the MAC Media Access Channel protocol sublayer is responsible for selecting available transmission formats for the user data and for the mapping of logical channel to the transport channels.
  • the MAC handles also a part of the Hybrid Automated Repetition request scheme.
  • the MAC layer is detailed in TS 38.321. On the emitter or transmitter side, the MAC encapsulates the data packet issued from the RLC.
  • the MAC decapsulates the data packet issued from the PHY sublayer, deletes its header and passes the remaining data to the RLC.
  • the PHY sublayer provides an electrical interface to the transmission medium (the air) by converting the stream of information into physical modulation signals, modulating a carrier frequency at emitter side.
  • the PHY sublayer converts the physical modulation signals back to a stream of information.
  • the PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214.
  • the PDCP Packet Data Convergence Protocol
  • SDAP Service Data Adaptation Protocol
  • RRC Radio Resource Control
  • the PDCP sublayer handles IP Header compression/decompression, ciphering/deciphering, and handles the integrity on the data packet if necessary. It mandatorily numbers the packets on the emitter side and reorders the packets on the receiver side.
  • the PDCP sublayer is described in 3GPP TS38.323.
  • SDAP sublayer 220 for the User Plane handles the Quality of Service. It is described in TS38.324.
  • the SDAP sublayer exchanges the payload data with the user’s application (voice, video, etc. . . - not shown in the Figure).
  • the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc).
  • RRC sublayer 220 for the Control Plane handles the configuration of the protocol entities of the User Plane protocol stack. It is described in TS38.331. It is responsible for the handling of, inter alia, broadcasting information necessary to a UE to communicate with a cell; transmitting paging messages, managing connection, including setting up bearers; mobility functions; measurement configuration and reporting; devices capabilities.
  • the interface (for both CP and UP) between nodes using the layers PDCP, RLC, MAC and PHY is referenced NR-Uu. This mainly concerns the interface with the UE.
  • NR-Uu is the interface between the UE and the radio access network, i.e. its access I AB -node (for both CP and UP).
  • Figure 2b comes from 3GPP TS 38.300 vl7.2.0 and illustrates the protocol stack for the support of lAB-MT’s RRC and NAS connections.
  • the Non-Access Stratum (NAS) protocol handles the messages between the core network and a user equipment, or an lAB-node. It manages the establishment of communication sessions and maintains communications with the lAB-node or the user equipment as it moves.
  • the 5G NAS is described in 3GPP TS 24.501.
  • the 5G Core Access and Mobility Management Function is a function within the Core Network that receives all connection and session related information from the UEs connected to the lAB-node, as well as similar information for the lAB-node. AMF is only responsible for handling connection and mobility management tasks.
  • the IAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the lAB-donor-CU. These SRBs are transported between the IAB-MT and its parent node(s) over NR-Uu interface(s).
  • SRBs Radio Bearers
  • Figure 4 shows a schematic representation of an example communication device (apparatus) or station, in accordance with one or more example embodiments of the present disclosure.
  • the communication device 400 may be a device such as a micro-computer, a workstation or a light portable device.
  • the communication device 400 may comprise a communication bus 413 to which there are preferably connected:
  • central processing unit 411 such as a microprocessor, denoted CPU.
  • the central processing unit 411 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out 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 is a matter of design choice for a skilled person;
  • the computer programs may contain a number of different program elements (modules) or sub-routines containing instructions for a variety of operations and for implementing the methods in accordance with one or more embodiments of the invention.
  • the at least one communication interface 402 may be connected to the radio communication network 403, such as a wireless communication network for 5GNR (e g. according to release 17 and/or subsequent releases), over which digital data packets or frames or control frames are transmitted.
  • the frames are written from a FIFO sending memory in RAM 412 to the communication interface for transmission or are read from the communication interface for reception and writing into a FIFO receiving memory in RAM 412 under the control of a software application running in the CPU 411.
  • a donor-CU, a donor-DU, an lAB-node and a UE may be implemented in such a communication device/apparatus 100.
  • the memory may include:
  • ROM read only memory
  • RAM random-access memory 412, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to one or more embodiments of the invention.
  • the communication device 400 may also include the following components:
  • a data storage means 404 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention
  • the communication bus 413 provides communication and interoperability between the various elements included in the communication device 400 or connected to it.
  • the representation of the bus is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by means of another element of the communication device 400.
  • the disk 406 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the communication device, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented.
  • CD-ROM compact disk
  • ZIP disk a ZIP disk
  • USB key or a memory card
  • an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the communication device, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented.
  • the executable code may optionally be stored either in read only memory 407, on the hard disk 404 or on a removable digital medium such as for example a disk 406 as described previously.
  • the executable code of the programs can be received by means of the communication network 403, via the interface 402, in order to be stored in one of the storage means of the communication device 400, such as the hard disk 404, before being executed.
  • the central processing unit 411 may be adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means.
  • the program or programs that are stored in a non-volatile memory are transferred into the random-access memory 412, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.
  • the communication device is a programmable device/apparatus which uses software to implement the invention. Instructions may be executed by one or more processors of the apparatus, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry to implement the invention for a network node (e.g. lAB-node, IAB- donor-CU).
  • DSPs digital signal processors
  • ASICs application specific integrated circuits
  • FPGAs field programmable logic arrays
  • the term “central processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.
  • the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC or other logic element).
  • FIG. 5 illustrates an 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.
  • the radio links between the lAB-nodes and between the lAB-nodes and the lAB-donor-DUs (referred to as BH radio links) are operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance.
  • An IAB network will also be referred to as an IAB topology or topology and so in this application, the terms IAB network and IAB topology and topology will be used interchangeably.
  • IAB communication system 500 is composed of three IAB networks or IAB topologies 5001, 5002, and 5003 with each IAB topology comprising a set of lAB-nodes (e.g. the set may comprise a plurality of lAB-nodes or at least one lAB-node) and an lAB-donor-CU for controlling or managing the plurality of lAB-nodes.
  • the set of lAB-nodes may include one or more lAB-nodes, such as initiator lAB-nodes which generate BAP packets and also intermediate or relay lAB-nodes.
  • Each of the lAB-nodes communicate with at least one other lAB-node over a wireless backhaul (BH) link.
  • BH wireless backhaul
  • Figure 5 shows three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system comprising more than two IAB topologies with each topology comprising a set of lAB-nodes and an lAB-donor-CU as discussed above.
  • each lAB-node comprises a Mobile Termination (MT) part or unit, controlled and configured by the lAB-donor using RRC messaging as defined in 3 GPP TS 38.331, and a Distributed Unit (DU) part, controlled and configured by the lAB-donor using Fl-AP messaging as defined in 3GPP TS 38.473.
  • lAB-node 510 comprises a MT part or unit 511 and a DU part 512.
  • IAB topology 5001 includes lAB-donor-CU 501 (identified as Donor 1-CU in Figure 5), and its associated lAB-donor-DU 504 (identified as Donor 1-DU1 in Figure 5), and a plurality of lAB-nodes 510 and 520, similar to lAB-nodes 121 and 122.
  • IAB topology 5002 includes lAB-donor-CU 502 (identified as Donor2-CU in Figure 5), its associated lAB-donor-DUs, lAB-donor-DU 505 (identified as Donor2-DUl in Figure 5) and lAB-donor-DU 506 (identified as Donor2-DU2 in Figure 5), and a plurality of IAB- nodes 530, 540, 550, similar to lAB-nodes 121 and 122, and lAB-node 570, that may be similar to mobile lAB-node 123. All lAB-nodes can be access nodes serving UEs like the UE 580 served by the mobile lAB-node 570.
  • the IAB topology 5002 is transparent for the UE 580 that connects to the donor-CU 502 through the DU part or unit 572 of the mobile IAB- node 570.
  • figure 5 shows only one UE 580, it will be appreciated that there will be a plurality of UEs connected to the network nodes of the IAB communication system 500.
  • IAB topology 5003 includes lAB-donor-CU 503 (identified as Donor3-CU in Figure 5), and its associated lAB-donor-DU 507 (identified as Donor3-DUl in Figure 5), and an IAB- node 560, similar to lAB-nodes 121 and 122.
  • a wired backhaul IP network interconnects the lAB-donor-CUs 501, 502, and 503, and the lAB-donor-DUs 504, 505, 506 and 507 through the wired backhaul 508.
  • this wired backhaul 508 consists of optical fiber cables.
  • lAB-donor-CU 501, lAB-donor-DU 504 and lAB-nodes 510 and 520 are part of the same IAB network or IAB topology 5001, which is configured and managed or controlled by lAB-donor-CU 501.
  • lAB-donor-CU 502 lAB-donor-DUs 505 and 506, and lAB-nodes 530, 540, 550 are part of the same IAB network or IAB topology 5002, which is configured and managed or controlled by lAB-donor-CU 502.
  • lAB-donor-CU 503, lAB-donor-DU 507, and lAB-node 560 are part of the same IAB network or IAB topology 5003, which is configured and managed or controlled by IAB- donor-CU 803.
  • Each IAB-DU and lAB-donor-DU supports wireless communication in a coverage area(s) referred to as cell(s) (not shown in figure 5).
  • each IAB-DU and IAB- donor-DU is associated with cell(s).
  • Wireless communication devices such as UEs, or other lAB-nodes located within a cell may establish communication links with the node (i.e. IAB- DU or lAB-donor-DU) serving the cell in order to communicate with other devices (e.g. other UEs, lAB-nodes, servers providing access to the Internet, etc.) via the node.
  • the mobile lAB-node 570 had initially a single parent lAB-node 520, and that lAB-node 570 belongs to the IAB topology 5001 controlled by the lAB-donor-CU 501.
  • the lAB-donor-CU is thus operating as the Fl terminating donor-CU (which may also be referred to as a Fl-terminating lAB-donor-CU or Fl donor-CU).
  • the mobile IAB- node 570 may be able to establish a wireless BH link with the lAB-node 530.
  • a wireless BH link is possible for a stationary lAB-node, and it is very likely to happen for a mobile lAB-node like lAB-node 570, moving, for instance, in the direction of the IAB topology 5002 (shown by arrow 590 in figure 5.
  • the Fl donor-CU 501 may have decided to perform the migration of the MT part 571 of the lAB-node 570 toward the IAB topology controlled by the donor-CU 502, which became the non-Fl terminating donor-CU (which may also be referred to as a non-Fl - terminating lAB-donor-CU or non-Fl donor-CU, or RRC donor-CU, or RRC terminating donor-CU) for the lAB-node 570 (i.e. the MT part 571 of the lAB-node 570 is migrated toward the parent lAB-node 530).
  • the non-Fl terminating donor-CU which may also be referred to as a non-Fl - terminating lAB-donor-CU or non-Fl donor-CU, or RRC donor-CU, or RRC terminating donor-CU
  • the lAB-node 570 i.e. the MT part 571 of the lAB-node
  • the Fl donor-CU 501 may have initiated 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 (when the lAB-node 570 has descendant lAB-nodes).
  • the lAB-node 570 still belongs to the IAB topology 5001, with its Fl connection to the donor-CU 501, but its RRC connection is now to the donor-CU2 502.
  • the lAB-donor-CU 501 may request the migration toward the IAB topology 5002 (i.e. through the donor-DU 505) of the backhaul traffic (e.g. user traffic, control traffic) related to the lAB-node 570.
  • the backhaul traffic e.g. user traffic, control traffic
  • the donor-CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2.
  • all traffic communicated over backhaul links uses a Fl interface (Fl- C or Fl-U) between an lAB-donor-CU and an IAB-DU.
  • Fl interface Fl- C or Fl-U
  • the traffic or backhaul traffic that is offloaded or migrated is Fl traffic and can include control and user traffic.
  • the MT part 571 of the lAB-node 570 may then have been migrated by the non-Fl donor-CU 502 toward the parent lAB-node 550, using the backhaul link 5050 between the lAB-node 550 and the lAB-node 570.
  • the non-Fl 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 consecutive MT migration (or another MT migration to another lAB-node) of the lAB-node 570 with a new single parent lAB-node 550.
  • the lAB-node 501 has its Fl connection with the donor-CU 501 and its RRC connection with the donor-CU2 502.
  • the donor-CU 501 may request the migration of the traffic related to the lAB-node 570 toward the IAB topology 5002. In this case, the donor-CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2.
  • the donor-CU 502 may apply the inter-CU Topology Adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or 8.17.3.2.
  • the lAB-node 501 still belongs to the IAB topology 5001, with its Fl connection with the donor-CU 501, but its RRC connection is now with the donor-CU 503 and thus, the donor-CU 503 becomes the non-Fl terminating donor-CU (or RRC terminating donor-CU).
  • the donor-CU 501 has to be informed of the new non-Fl donor-CU 503 for the lAB-node 570 and of the new donor-DU 507 to redirect the offloaded traffic (Fl traffic, control and user traffic) through the donor-DU 507 instead of donor-DU 506.
  • the UE 580 still connects to the donor- CU 501 through the DU part or unit 572 of the mobile lAB-node 570.
  • the lAB-node 570 has some child lAB-node(s)
  • such child lAB-node still belongs to the IAB topology 5001, and it is still fully controlled (through Fl and RRC connections) by the donor-CU 501.
  • the Fl donor-CU 501 may decide to perform the migration of the DU part of the lAB-node 570.
  • the reason for performing DU migration may be to reduce the processing load at the Fl donor- CU 501, or because the lAB-node 570 is geographically far from the Fl donor-CU 501 and close to an area where there is no more Xn connectivity between the Fl donor-CU 501 and a target donor-CU.
  • the Fl donor-CU 501 has also to decide toward which donor-CU (which is referred to as the target Fl donor-CU) the DU migration shall be performed. It may be a DU migration toward the current non-Fl terminating donor-CU (i.e.
  • the Fl donor-CU 501 may be aware of a suitable target Fl -donor-CU controlling cells through which the lAB-node 570 will soon connect to the network.
  • the Fl donor-CU may decide the DU migration of the IAB- node 570 should be directly toward the donor-CU 503, as the lAB-node 570 may rapidly cross and not stay in the IAB topology 5002 controlled by the donor-CU 502.
  • DU migration is performed, handover of the UEs served by the lAB-node 570 must also be performed.
  • Figure 6 illustrates an example of lAB-node architecture 600 which enables migration of the DU of the lAB-node (DU migration) from a source IAB topology to a target IAB topology.
  • the lAB-node 601 which may be a mobile lAB-node like the lAB-node 570, is composed of an IAB-MT part or unit IAB-MT 610 (like the MT part or MT 571 of the IAB- node 570 of figure 5), 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 separated physical layers.
  • both logical DUs are active: one of the logical DU terminates the Fl interface with a source Fl donor-CU (like donor-CU 501 in figure 5), while the other logical DU terminates the Fl interface with a target Fl donor-CU (like donor-CU 502 or 503 in figure 5). Otherwise (i.e. when DU migration is not to be performed), only one logical DU is sufficient for IAB operations.
  • the Fl terminating donor-CU of the lAB-node 601 i.e. lAB-node 570
  • the source Fl -donor-CU 501 may identify lAB-donor- CU 502 as a suitable target Fl donor-CU when the source Fl -donor-CU 501 determines that the lAB-node 570 is moving towards/through the IAB topology 5002 which includes network nodes (e.g. lAB-donor-DUs 505, 506, lAB-nodes 530, 540, 550) managed by the lAB-donor- CU 502, which network nodes serve cells in IAB topology 5002 to which the lAB-node 570 will soon connect.
  • network nodes e.g. lAB-donor-DUs 505, 506, lAB-nodes 530, 540, 550
  • the source Fl -donor-CU 501 may determine that lAB-donor-CU 502 is a suitable target Fl donor-CU when source Fl -donor-CU 501 determines (e.g.
  • Examples of methods, in accordance with one or more embodiments of the present invention, which enable DU migration of an lAB-node to be performed, with or without (multiple) MT migration(s), and which include notifying the lAB-node about the identity of target donor-CU to enable the handover of UEs served by the lAB-node to the target donor- CU will now be described. Although the following methods/apparatus’ will be described primarily with respect to a mobile lAB-node, it will be appreciated that it is not intended that the invention is limited to mobile lAB-nodes.
  • the methods in accordance with one or more embodiments of the present invention may apply to stationary lAB-nodes e.g. that are at the edge of one IAB topology and in the proximity of or in the vicinity of one or more lAB-nodes in a neighbouring IAB topology.
  • Figure 7 is a schematic and simplified diagram 700 illustrating some example message flows according to one or more embodiments of the invention, to perform the DU migration of an lAB-node, with or without (multiple) MT migration(s), and which includes the setup of data path(s) for packets routing between the target Fl donor-CU and the lAB-node through an IAB topology controlled by the non-Fl donor-CU (or RRC donor-CU) of the lAB-node.
  • This figure 7 shows a UE 708 like the UE 580, a source Fl donor-CU 703 like the donor-CU 501, a target Fl donor-CU 707 like the donor-CU 503, a non-Fl /RRC donor-CU 709, the core network (5GC) 702 like the core network 110 of figure 1.
  • This figure 7 also shows an lAB-node 701 that may be a mobile lAB-node like the lAB-node 570 composed of a MT part or unit IAB-MT 704, a DU part or unit IAB-DU1 705 (e.g. source or first logical DU entity or DU), and a DU part or unit IAB-DU2 706 (e.g.
  • Each of the first 705 and second 706 logical DU entities serve one or more cells which are identified by identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)).
  • the cell(s) of the IAB-DU1 705 are identified by different values for the identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)) compared to the values for the cell(s) of the 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.
  • the non-Fl donor-CU 709 for the lAB-node 701 may be the source Fl donor-CU 703 itself (e.g. donor- CU 501) if the IAB-MT 704 was not migrated.
  • the non-Fl donor-CU for the lAB-node 701 may be the target Fl donor-CU 707 (e.g. donor-CU 703) if the IAB-MT 704 was previously migrated toward the target Fl donor-CU 707, or another donor-CU (e.g. donor-CU 502) if the IAB-MT 704 was previously migrated toward this other donor-CU (e.g. donor-CU 502).
  • the lAB-node 701 belongs to the source IAB topology controlled by the source Fl donor-CU 703.
  • the UE 708 is served by the lAB-node 701 through a cell of IAB -DU 1 705 (e.g. the DU of the lAB-node 701 has an active IAB -DU 1 705 having a Fl connection with the source Fl lAB-donor-CU 703), while the logical IAB- DU2 706 is inactive.
  • the user data in the downstream direction are provided by the 5GC 702 to the source Fl donor-CU 703 through the bearer 710, then the data are transmitted to the logical DU IAB-DU1 705 of the lAB-node 701 through the backhaul bearer 711, and finally to the UE 708 through the data radio bearer 712.
  • the backhaul bearer 711 may be established in the source IAB topology controlled by the source Fl donor-CU 703, or in the IAB topology controlled by the non-Fl donor-CU 709 of the lAB-node 701 (if the IAB-MT 704 was previously migrated toward this non-Fl donor-CU).
  • User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction.
  • the IAB-MT 704 may send measurement reports (not represented in the figure 7) to its non-Fl terminating donor-CU 709 as the result of the measurements regularly performed by IAB-MT 704 on signals received from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells.
  • the non-Fl terminating donor-CU will be the Fl terminating donor-CU for the lAB-node (e.g. source Fl donor-CU 703) if the MT has not been migrated from its Fl terminating donor-CU.
  • the target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell).
  • a measurement report may be generated and transmitted to provide radio link quality information for different cells in the vicinity of the lAB-node 701. The identity of each cell is included in the measurement report to allow the non-Fl donor-CU if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, to identify the target donor-CU associated with the cell.
  • the identification of a donor-CU can be deduced from the Physical Cell identity (PCI) broadcasted in each cell managed by this donor-CU in a synchronization signal, and/or from the New Radio Cell Group Identifier (NCGI) also broadcasted in each cell managed by this donor-CU in a System Information Block (SIB) message.
  • PCI Physical Cell identity
  • NCGI New Radio Cell Group Identifier
  • SIB System Information Block
  • the PCI and/or the NCGI may be reported by the lAB-node 701 in the measurement report.
  • the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated may detect that the lAB-node 701 receives radio signals in a target cell of a target parent lAB-node with a better quality than in the source serving cell.
  • the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, may decide to apply a procedure to perform the IAB-MT 704 migration toward a target parent lAB-node that belongs either to the same IAB topology (intra-CU topology adaptation), or to another IAB topology (inter-CU topology adaptation).
  • the source Fl donor-CU 703 will be informed about this MT migration by the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated or the source Fl donor-CU 703 will be informed since it made the decision to perform MT migration directly from the measurement reports received from the lAB-node 701 if the IAB-MT 704 has not been migrated, and this information may be used by the source Fl donor-CU 703 to trigger a DU migration of the lAB-node 701.
  • the non-Fl donor-CU 709 may relay the information in the measurement reports received from the lAB-node 701 to the source Fl donor-CU 703.
  • the source Fl donor-CU 703 may base its decision for DU migration of the lAB-node 701 directly from these measurement reports relayed by the non-Fl donor-CU 709.
  • the source Fl donor-CU 703 determines the DU of the lAB-node is to be migrated from the IAB topology (also referred to as the source IAB topology) of the source Fl donor-CU 703 to another IAB topology (also referred to as the target IAB topology) of a target lAB-donor-CU.
  • the determination may be based on determining that a migration of a MT of the lAB-node toward a new parent lAB-node has been completed.
  • Another example of a triggering event for determining the DU of the lAB-node is to be migrated may include the decision for DU migration may be based on the detection of a MT migration from a one IAB topology (e.g. first IAB topology) towards another IAB topology (e.g. second IAB topology), and on a known (predefined) trajectory of the lAB-node that indicates to the source Fl donor- CU that the MT will be migrated later to a yet another IAB topology (e.g. third IAB topology).
  • a known trajectory of the lAB-node that indicates to the source Fl donor- CU that the MT will be migrated later to a yet another IAB topology (e.g. third IAB topology).
  • the another IAB topology e.g.
  • the DU is directly migrated toward the yet another IAB topology (e.g. third IAB topology).
  • Another example of a triggering event for determining the DU of the lAB-node is to be migrated may include the processing load level being detected above a predefined threshold in the source Fl donor-CU. Then DU migration is triggered and the choice of target Fl donor-CU is based on the processing load of other donor-CUs connected to the source Fl donor-CU.
  • the first step 720 corresponds to sending a request to the lAB-node 701 to establish a new Fl connection between the target Fl donor- CU 707 and the mobile lAB-node 701. This may require activation of the second logical IAB-DU2 706 in the mobile lAB-node 701 and thus the first step 720 may include the activation of the second logical DU IAB-DU2 706 in the mobile lAB-node 701.
  • the message sent by the source Fl donor-CU 703 to the lAB-node 701 for the activation of the IAB-DU2 706 may include identification information for identifying the target donor-CU, such as the TNL address (i.e. IP address) of the target Fl donor-CU 707, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may be set up with the target donor-CU 707 (between the IAB-DU2 706 and the target donor-CU 707).
  • the non-Fl donor-CU 709 is considered as the target Fl donor-CU.
  • the lAB-node 701 has already been informed of the identity (e.g. the TNL address/IP address) of the target Fl donor-CU when the IAB-MT 704 was migrated to the non-Fl donor-CU 709.
  • the source Fl donor-CU 703 may send identification information for identifying the target Fl donor-CU 707 if the IAB-MT 704 has been migrated to a non-Fl donor-CU 709 different from (i.e. not the same as) the target Fl donor-CU 707.
  • the source Fl donor-CU 703 may send identification information for identifying the non-Fl donor-CU 709 as the target lAB-donor-CU.
  • the IAB-DU2 706 may send a Fl setup request message (e.g. 1213 in figure 12b) to the target Fl donor-CU 707 for requesting set up of the Fl connection between the lAB-node 701 and the target Fl donor-CU 707.
  • This message may include identification information for identifying the source lAB-donor-CU, such as the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • the destination address of the Fl setup request message is the target Fl donor-CU 707, and when this IP packet is received by the donor-DU in the Fl path for the lAB-node 701, it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 707.
  • the lAB-node 701 is the lAB-node 570 of figure 5 which is connected to lAB-node 550 via backhaul link 5050 and where the MT (MT 571 which corresponds to IAB-MT 704 in figure 7) of the lAB-node 570 has been migrated to the nonFl donor-CU 502 and the lAB-donor-CU 501 is the source Fl donor-CU
  • the Fl path between the Fl donor-CU 501 to the lAB-node 570 uses the donor-DU 506.
  • the lAB-donor-CU 503 has been identified (by Fl donor-CU 501) as the target Fl donor-CU (e.g.
  • the Fl setup request message for the target Fl donor-CU (for instance donor-CU 503) is sent through the lAB-nodes 550, 540 and then to the donor-DU 506 from where it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 503.
  • the target Fl donor-CU 707 e.g. donor-CU 503 in the example described above with reference to figure 5
  • the target Fl donor-CU 707 may request the IAB-DU2 706 to activate new cell(s) with associated identifiers (PCI, NCGI).
  • PCI identifiers
  • NCGI identifiers
  • the DU activates/deactivates 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.
  • the target Fl donor-CU 707 may inform the source Fl donor-CU 705 about the activation of new cell(s) from the IAB-DU2 706 of the lAB-node 701.
  • the next step 730 consists in the handover of UEs (e.g. UE 708 in figure 7) served by the lAB-node 701, from the cell(s) of the first logical DU IAB-DU1 705 to the cell(s) of the second logical DU IAB-DU2 706.
  • This procedure may be the standardized procedure described in TS 38.300 section 9.2.3.2 (handover), or the standardized procedure described in TS 38.300 section 9.2.3.4 (conditional handover).
  • the source Fl donor-CU 703 sends a HANDOVER REQUEST message to the target Fl donor-CU 707 including the necessary information related to the UE 708 to hand over (e.g.
  • UE context information such as the security context (e.g. security parameters such as security key, UE security capabilities), measurement configuration, radio configuration (e.g. UE radio capability), information about bearers, etc.).
  • TS 38.423, section 9.1.1.1 provides details as to the content of a HANDOVER REQUEST message.
  • the configuration may include radio configuration information indicating the radio configuration to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 of the lAB-node 701 in an identified target cell of the second logical DU IAB-DU2 706 (e.g. the radio configuration may include frequency, radio bearer configuration, etc.).
  • the handover acknowledgement may include an identifier for each of the one or more new cells (e.g. the target cell(s)) that have been activated at the second logical DU IAB-DU2 706.
  • the source Fl donor-CU 705 sends this configuration information to the UE 708 via the lAB-node 701 in a RRC Reconfiguration message, including the identifier of the target cell of IAB-DU2 706 to which the UE 708 is to connect.
  • the RRC Reconfiguration message (specified in TS 38.331) is embedded in a Fl message DL RRC MESSAGE TRANSFER (specified in TS 38.473), sent to the IAB- DU1 705 and relayed by the IAB-DU1 705 to the UE 708.
  • the UE 708 Upon reception of this configuration information, the UE 708 performs a random-access procedure in the indicated target cell of IAB-DU2 706 to obtain uplink resources, and then to transmit a RRC Reconfiguration Complete message to the target Fl donor-CU 707.
  • the RRC Reconfiguration Complete message (specified in TS 38.331) is sent to the IAB-DU2 706, and then embedded in a Fl message UL RRC MESSAGE TRANSFER (specified in TS 38.473), sent to the target Fl donor-CU 707.
  • the source Fl donor-CU 705 may be informed about the completion of the UE 708 handover through the HANDOVER SUCCESS message (specified in TS 38.423) received from the target Fl donor-CU 707.
  • the source Fl donor-CU 703 may deactivate the logical DU IAB-DU1 705 of the mobile lAB-node 701 through the procedure described with reference to figure 12c. This is represented generally by the procedure 735 in figure 7.
  • the source Fl donor-CU 705 may release the traffic (user traffic, control traffic) related to the UEs that were served by the lAB-node 701 through the I AB -DU 1 705 and the source Fl donor-CU 705. If the traffic was offloaded in an IAB topology controlled by the non-Fl donor-CU 709 (e.g. when the MT of the lAB-node 701 is migrated to the non-Fl donor-CU 709), the source Fl donor-CU 705 may apply the procedure described with reference to figure 13b to request the traffic release to the non-Fl donor-CU 709. This is represented generally by the procedure 735 in figure 7.
  • the target Fl donor-CU 707 has to setup the data path(s) to/from the migrated lAB-node 701, either in its own topology if there is a backhaul path to reach the lAB-node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e.
  • the target Fl donor- CU 707 is a non-Fl terminating donor-CU for the lAB-node 701 as the IAB-MT 704 has previously been migrated to the target Fl donor-CU 707), or through the IAB topology of the non-Fl donor-CU 709 of the lAB-node 701 if there is no backhaul path to reach the IAB- node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e. IAB-MT 704 and IAB-DU2 706 are connected to different donor-CUs).
  • the target Fl donor-CU 707 may trigger the transport migration and path switch procedure 731 including the request of traffic migration to the non-Fl donor-CU 709 of the lAB-node 701, described with reference to figure 13b, and the path switch procedure toward the core network 702.
  • the lAB-node 701 is the lAB-node
  • the lAB-donor-CU 501 is the Fl donor-CU.
  • the DU (DU 572 which corresponds to IAB-DU2 706 in figure 7) of the lAB-node 570 has been migrated to the target donor-CU 503, and so has a Fl connection to the Fl donor-CU 503, but the MT 571 remains connected through its RRC connection to the non-Fl donor-CU 502, (its RRC connection), the data path(s) or backhaul path(s) to/from the lAB-node 570 is set up in the IAB topology 5002 controlled by the lAB-donor-CU 502 (i.e.
  • target donor- CU 503 may perform a path switch procedure toward the core network 702 to request the delivery of the user data related to the UE 708/580.
  • target donor-CU 503 may perform the path switch handshake procedure described in 3GPP TS 38.413 vl7.2.0 section 8.4.4.
  • the user data in the downstream direction are transmitted by the core network 702 to the target Fl donor-CU 707 through the bearer 740, then they are transmitted to the logical DU IAB-DU2 706 of the lAB-node 701 through the backhaul bearer 741, and finally to the UE 708 through the data radio bearer 742.
  • the backhaul bearer 741 may be established in the IAB topology controlled by the target Fl donor-CU 707, or in the IAB topology controlled by the non-Fl donor-CU 709 of the lAB-node 707 (e.g. depending on whether the IAB-MT 704 and IAB-DU2 706 of lAB-node 701 are connected to different donor-CUs).
  • User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction.
  • the target Fl donor-CU 707 needs to be able to identify the non-Fl donor-CU 709.
  • Figure 14 is a flowchart showing an example method 1400 in accordance with one or more embodiments of the invention, performed at a target lAB-donor-CU for use in managing transport migration for traffic related to an lAB-node.
  • the transport migration is to be performed after a DU of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor-CU to a target IAB topology managed by the target IAB- donor-CU.
  • Method 1400 may be performed as part of a DU migration process for migrating the DU of the lAB-node.
  • the source lAB-donor-CU performing the method 1400 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU of the IAB- node 570 with which the lAB-node 570 retains a Fl connection).
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (e.g. source IAB topology) controlled by the lAB-donor-CU 501 (e.g. the source Fl lAB-donor-CU).
  • the target lAB-donor-CU 503 receives a notification including identification information for identifying an lAB-donor-CU serving a MT of the lAB-node 570 (e.g. the MT, such as MT 571, that is co-located with the DU of the lAB-node, such as DU 572).
  • the lAB-donor-CU serving the MT of the lAB-node is a different lAB-donor-CU to the target lAB-donor-CU.
  • the lAB-donor-CU serving the MT of the lAB-node 570 may be the source lAB-donor-CU (e.g.
  • the source Fl lAB-donor-CU such as lAB-donor-CU 501 is the non-Fl lAB-donor-CU) when the MT of the lAB-node 570 has not been migrated from the source lAB-donor-CU).
  • the lAB-donor-CU serving the MT of the IAB- node 570 may be another or a second lAB-donor-CU (e.g.
  • the non-Fl lAB-donor-CU or RRC I AB -donor CU such as lAB-donor-CU 502 when the MT of the lAB-node 570 has been migrated to the second lAB-donor-CU, such as lAB-donor-CU 502.
  • the non-Fl lAB-donor-CU for the migrated MT of the lAB-node 570 is the source Fl -donor-CU 501 or the non-Fl lAB-donor-CU 502, in either case, the target lAB-donor-CU is the different IAB- donor-CU 503.
  • the target lAB-donor-CU 503 may receive the notification from the source lAB-donor-CU 501, such as in a DU migration notification which includes the identification information or in a configuration update notification which includes the identification information or from the lAB-node 570, such as in a Fl setup request which includes the identification information.
  • the DU migration notification sent by the source lAB-donor-CU 501 may be the DU migration notification message 811 as discussed below with reference to figure 8 and figures 9a and 9d.
  • the configuration update notification sent by the source lAB-donor-CU 501 may be the configuration update notification message 817 as discussed below with reference to figure 8 and figures 9a and 9d.
  • the Fl setup request sent by the lAB-node 570 may be the Fl setup request message 814 as discussed below with reference to figure 8 and figures 9b, 9c and 9d.
  • the Fl setup request is sent, by the lAB-node, after receiving, from the source IAB- donor-CU 501, a request for establishing a Fl connection (e.g. a new Fl connection) and for informing the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node.
  • the request from the source lAB-donor-CU 501 may be sent in the DU activation request 813.
  • the request from the source lAB-donor-CU 501 may indicate (explicitly or implicitly) to the lAB-node that the lAB-node is to inform the target IAB- donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node.
  • the request from the source lAB-donor-CU 501 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT.
  • the information may include an Information Element, IE, for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node as discussed below with respect to figure 12a and the configuration request message 1203.
  • the presence of the IE in the request for establishing a Fl connection may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU, or when the IE has a certain value (e.g.
  • the IE may be one bit and the certain value may be ‘ 1’ or ‘0’), it may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB- donor-CU.
  • the information may include identification information for identifying the lAB-donor-CU serving the MT of the lAB-node 570 and the presence of the identification information in the request may itself indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU.
  • the target lAB-donor-CU 503 may receive the notification from the second lAB-donor-CU 502 (e.g. a non-Fl donor-CU or RRC donor-CU).
  • the notification may be sent in a transport migration ready notification which includes the identification information, such as in a transport migration ready message 1013 as discussed below with reference to figure 10 and figures 1 la-11c.
  • the identification information for identifying an lAB-donor-CU serving the MT of the lAB-node 570 may be an identifier such as the TNL address (i.e. IP address) of the IAB- donor-CU serving the MT of the lAB-node and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3).
  • the notification may also include identification information for identifying the MT 571 of the lAB-node 570.
  • the identification information may be an identifier of the MT 571 of the lAB-node 570 known by the lAB-donor-CU serving the MT 571 of the IAB- node 570 (e.g. known by the Fl donor-CU 501 (when the MT has not been migrated) or by the non-Fl donor-CU 502 (when the MT has been migrated)).
  • the identifier is known by the non-Fl donor-CU 502 by the information element non-F 1 -Terminating I AB -donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16, or VAIC-Ter mi noting IAB -donor UE XnAP ID information element, as a NG-RAN node UE XnAP ID that uniquely identifies a UE over the Xn interface within the NG-RAN node.
  • each donor-CU assigns a value to each MT of an lAB-node in its IAB topology (as the IAB-MT is considered as a UE).
  • Another identifier of the MT of an lAB-node known by the non-Fl donor-CU is the BAP address that is assigned by this non-Fl donor-CU. Indeed, each lAB-donor-CU that terminates a RRC connection with an lAB-node has to assign a BAP address to this lAB-node (to use it as the destination BAP address for the BAP packets to be routed to this lAB-node in the IAB topology controlled by this IAB- donor-CU).
  • the target lAB-donor-CU 503 then, based on the identification information included in the notification (received from the source lAB-donor-CU 501 or the lAB-node 570 as discussed above) and after the DU 572 of the lAB-node 570 has been migrated to the target IAB topology 5003, performs transport migration for migrating traffic (e.g.
  • Fl traffic which may include control and user traffic
  • Fl traffic which may include control and user traffic
  • the lAB-node 570 for routing over at least one path between the target lAB-donor-CU 503 and the lAB-node 570 through the IAB topology managed by the lAB-donor-CU serving the MT 571 of the lAB-node 570 (e.g. through IAB topology 5001 managed by source lAB-donor- CU 501 when the MT has not been migrated from the source Fl lAB-donor-CU 501 or through IAB topology 5002 managed by non-Fl lAB-donor-CU 502 when the MT has been migrated to the non-Fl lAB-donor-CU 502).
  • the target lAB-donor-CU 503 sends, to the lAB-donor-CU serving the MT 571 of the lAB-node 570, a traffic migration request (e.g. message 1014 in figure 10, message 1313 in figure 13b).
  • a traffic migration request e.g. message 1014 in figure 10, message 1313 in figure 13b.
  • FIG 8 is a simplified diagram 800 illustrating example message flows, according to one or more embodiments of the invention, for providing identification information identifying a lAB-donor-CU that is serving a MT of a lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU) to a target lAB-donor-CU (e.g. the Fl terminating donor-CU) of a DU migration of the lAB-node, as part of a DU migration process of the lAB-node for use in managing or facilitating transport migration.
  • a lAB-donor-CU e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU
  • a target lAB-donor-CU e.g. the Fl terminating donor-CU
  • the target lAB-donor-CU may be provided the identification information in a notification received from the source lAB-donor-CU, such as in a DU migration notification or a configuration update notification, or in a notification received from the lAB-node, such as in a Fl setup request. These examples are discussed below.
  • This figure 8 shows a source Fl donor-CU 803 like the donor-CU 501, a target Fl donor-CU 807 like the donor-CU 503, and an lAB-node 801 that may be a mobile lAB-node like the lAB-node 570 composed of a MT part or unit IAB-MT 804, a DU part or unit IAB- DU1 805 (e.g. source or first logical DU entity or DU), and a DU part or unit IAB-DU2 806 (e.g. target or second logical DU entity or DU).
  • Each of the first 805 and second 806 logical DU entities 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 separated physical layers.
  • the lAB-node 801 belongs to the source IAB topology controlled by the source Fl donor-CU 803.
  • the first step corresponds to sending a DU activation request message 813 to the lAB-node 801, to establish a new Fl connection between the target Fl donor-CU 807 and the mobile lAB-node 801, through the second logical DU IAB-DU2 804.
  • the activation of the second logical IAB-DU2 806 in the mobile lAB-node 801 is performed with the operation 810.
  • the message 813 sent by the source Fl donor-CU 803 to the lAB-node 801 for the activation of the IAB-DU2 806 is sent to the first logical DU IAB-DU1 805 as the source Fl donor-CU 803 has a Fl connection with this first logical DU of the lAB-node 801.
  • the DU activation request message 813 may be a configuration request message 1203 as shown in figure 12a.
  • This message 813 includes a request for establishing a Fl connection and for informing the target donor-CU 807 of the identity of the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the request may indicate (explicitly or implicitly) to the lAB-node 801 that the lAB-node is to inform the target donor-CU 807 of the identity of the lAB-donor-CU serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
  • the information contained in the message 813 may be transmitted from the first logical DU IAB-DU1 805 to the second logical DU IAB-DU2 806.
  • 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 Fl donor-CU 807, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may be set up with the target donor-CU 807 (between the IAB-DU2 806 and the target donor-CU 807).
  • This message 813 may also include a request to inform the identified target Fl donor- CU 807 of the identity of the lAB-donor-CU that is serving the MT 804 of the lAB-node 801, such as the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • the message 813 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB- donor-CU serving the MT.
  • the information may include an Information Element (IE) for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the IAB- donor-CU serving the MT of the lAB-node (see discussions below with respect to figure 12a and configuration request message 1203).
  • IE Information Element
  • the lAB-donor-CU serving the MT 804 is the source Fl donor-CU 803 of the lAB-node 801 and when the MT has been migrated, the lAB-donor-CU serving the MT 804 is a non-Fl/RRC donor-CU of the lAB-node 801 (the non-Fl donor-CU is not shown in figure 8).
  • the message 813 may also include identification information for identifying the lAB-donor-CU that is serving the MT 804 of the lAB-node 801, such as the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • the information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT 804 may include the identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801 and the presence of the identification information may itself indicate to the lAB-node 801 that the lAB-node is to inform the target Fl donor- CU 807 of the identity of the lAB-donor-CU serving the MT 804.
  • the message 813 may include the identifier of the IAB-MT 804 known by the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the message 813 may include the identifier with the information element nonFl -Terminating I AB-donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16, or RRC- Terminating lAB-donor UE XnAP ID information element, as a NG-RAN node UE XnAP ID that uniquely identifies a UE over the Xn interface within the NG-RAN node.
  • each donor-CU assigns a value to each MT of an lAB-node in its IAB topology (as the IAB-MT is considered as a UE).
  • the Fl donor-CU 803 will have assigned an ID to the IAB-MT 804 when it was admitted in its IAB topology.
  • the non-Fl donor-CU will assign another ID to IAB-MT 804. Both IDs are exchanged in handover request/acknowledge messages.
  • the IAB-DU2 806 may send a Fl setup request message 814 to the target Fl donor-CU 807 for requesting the setup of the Fl connection between the lAB-node 801 and the target Fl donor-CU 807.
  • This message 814 may include identification information for identifying the source Fl donor-CU 803, such as the TNL address (i.e. the IP address) and/or the 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 Fl donor- CU 803 of the lAB-node 801.
  • This message 814 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801 (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the IAB- node).
  • this message 814 includes the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801.
  • the message 814 may include the identifier of the IAB-MT 804 known by lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the message 814 may include the identifier known by the non-Fl donor-CU with the information element non-F 1 -Terminating lAB-donor UE XnAP ID or RRC terminating I AB -donor UEXnAP ID.
  • the message 814 may additionally or alternatively include the identifier of the IAB-MT 804 known by the non-Fl donor-CU with the information element BAP address (i.e.
  • the BAP address information element is, for instance, described in TS 38.423 V17.2.0 section 9.2.2.89.
  • the message 814 may include the identifier gNB- DU ID of the second logical DU IAB-DU2 806 of the lAB-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 a gNB-CU.
  • a logical DU of an lAB-node is assigned a unique ID by configuration.
  • the unique ID may be provided to the Fl lAB-donor-CU terminating the Fl connection with the logical DU at Fl setup procedure (described in the figure 12b).
  • the target Fl donor-CU 807 may request the IAB-DU2 806 to activate new cell(s) with associated identifiers (PCI, NCGI).
  • PCI identifiers
  • the DU activate s/deactivates 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.
  • the IAB-DU2 806 may inform the IAB-DU1 805 about the result of the activation procedure (i.e. activation of IAB- DU2 806 and activation of new cell(s)).
  • the IAB-DU1 805 may relay this information to the source Fl donor-CU 803 through 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 lAB-node 801. The message 816 is further described with the reference 1204 in figure 12a.
  • the source Fl donor-CU 803 may directly send a notification to the target donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
  • the notification may be sent in a DU migration notification message 811 to the target Fl -donor-CU 807.
  • the message 811 may be sent prior to launching the IAB-DU2 806 setup procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8).
  • the message 811 may be followed by the DU migration response message 812 sent by the target Fl donor-CU 807 to the source Fl donor-CU 803 as an acknowledgment.
  • the messages 811 and 812 may correspond to the procedure described with reference to figure 13a where message 811 corresponds to message 1303 and message 812 corresponds to message 1304.
  • the messages 811 and 812 may correspond to the procedure described with reference to figure 13b where message 811 corresponds to message 1313 and message 812 corresponds to message 1314.
  • This message 811 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801. If the MT 804 has been migrated to a non-Fl/RRC donor-CU and if this non-Fl donor-CU is different from the target Fl donor-CU 807, the DU migration notification message 811 may include the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • the message 811 may also include the identifier of lAB-node 801 as known by the source Fl donor-CU 803, either with the information element F 1 -Terminating 1 AB -donor UE XnAP ID identifying the MT 804 of the lAB-node 801, or with the information element gNB-DU ID identifying the first logical DU IAB-DU1 805 of the lAB-node 801.
  • the message 811 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the message 811 may include the identifier as known by the non-Fl donor- CU, with the information element non-F 1 -Terminating lAB-donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID identifying the MT 804 of the lAB-node 801.
  • the message 811 may also or alternatively include the BAP address assigned by the non-F 1/RRC donor-CU. This involves that this BAP address was previously provided to the Fl donor-CU 803, for instance by the non-Fl donor-CU when the MT 804 was migrated (for instance using the procedure described at the figure 13a).
  • F 1 -Terminating lAB-donor UE XnAP ID and non-F 1 -Terminating lAB-donor UEXnAP ID correspond to a NG-RAN node UE XnAP ID as specified in TS 38.423 section 9.2.3.16.
  • the source Fl donor-CU 803 may directly send a notification to the target donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target Fl donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
  • the notification may be sent in a configuration update message 817 to the target Fl -donor-CU 807.
  • the message 817 may be sent at any time, before or after the launching of IAB-DU2 806 procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8). It may also be sent when the source Fl donor-CU 803 has detected a change of non-F 1/RRC donor-CU for the lAB-node 801.
  • the source Fl donor-CU 803 can send an update through the message 817 including the address/identifier of the new non-F 1/RRC donor-CU.
  • the configuration update message 817 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the message 817 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801 if this non-Fl donor-CU is different from the target Fl donor-CU 807.
  • the message 817 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the message 817 may include the identifier as known by the non-Fl donor-CU, with the information element non-Fl- Terminating lAB-donor UE XnAP ID (or RRC-Terminating lAB-donor UE XnAP ED) identifying the MT 804 of the lAB-node 801.
  • the message 817 may also or alternatively include the BAP address assigned by the non-Fl/RRC donor-CU. This involves that this BAP address was previously provided to the Fl donor-CU 803, for instance by the non-Fl donor- CU when the MT 804 was migrated (for instance using the procedure described at the figure 13a).
  • the message 817 may also include the gNB-DU ID identifying the first logical DU IAB-DU1 805 of the lAB-node 801 and/or the gNB-DU ID identifying the second logical DU IAB-DU2 806 of the lAB-node 801.
  • the information identifying the lAB-donor-CU that is serving the MT of the lAB-node and the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 may also be present in the message 817 when the target Fl donor-CU 807 is the lAB-donor-CU serving the MT of the lAB-node 801. This would avoid any confusion at the target Fl donor- CU 807 to understand that the DU migration is related to the same lAB-node 801 as the MT 804.
  • the message 817 may be followed by the configuration acknowledgment message 818 sent by the target Fl donor-CU 807 to the source Fl donor-CU 803.
  • the messages 817 and 818 may correspond to the procedure described at the figure 13a with message 817 corresponding to configuration update message 1303 and message 818 corresponding to configuration acknowledge message 1304.
  • the source non- Fl donor-CU for the MT migration is not the source Fl donor-CU 803.
  • the source Fl donor-CU 803 may receive a message (not represented in the figure) from the source non- Fl/RRC donor-CU, for instance when the MT migration is completed.
  • the source Fl donor-CU 803 may relay the message received from the source non-Fl donor-CU.
  • the source non-Fl donor-CU for the MT migration of an lAB-node may inform the Fl donor-CU of the lAB-node about the identifier of the target non-Fl/RRC donor-CU through the procedure described with reference to the figure 13 a.
  • the Fl donor-CU of an IAB- node may not be the source donor-CU of the previous MT migration.
  • the question that can be raised is how does the source non-Fl donor-CU for a MT migration identify the Fl donor-CU for the lAB-node.
  • a Fl donor-CU for an lAB-node is a donor-CU that has triggered a transport migration management (TMM) procedure for traffic related to the IAB- node.
  • TMM transport migration management
  • a MT migration process includes a MT handover process similar to a UE handover, followed by a TMM procedure initiated by the Fl donor-CU to transmit/receive packets related to the lAB-node through the IAB topology controlling the non-Fl donor-CU.
  • the TMM procedure corresponds to the procedure described in the figure 13b.
  • the source non- Fl donor-CU for a MT migration informs the target non-Fl donor-CU about the Fl donor- CU of the migrated lAB-node. This can be performed through the procedure described with the figure 13 a.
  • the non- Fl donor-CU should be informed about the new Fl donor-CU. Then, it may be considered that at DU migration of an lAB-node, the source Fl donor-CU informs the non-Fl donor-CU serving the collocated MT about the target-Fl donor-CU. This can be performed through the procedure described with the figure 13a.
  • the lAB-node 801 may directly send a notification to the target Fl donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different IAB- donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
  • the notification may be sent in a configuration update message 819 from the IAB-DU2 806 to the target Fl -donor- CU 807.
  • the information identifying the lAB-donor-CU that is serving the MT of the IAB- node may also be present in the configuration update message 819 when the target Fl donor- CU 807 is the lAB-donor-CU serving the MT of the lAB-node 801. This would avoid any confusion at the target Fl donor-CU 807 to understand that the DU migration is related to the same lAB-node 801 as the MT 804.
  • the configuration update message 819 may be sent at any time after the completion of IAB-DU2 806 setup procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8). It may also be sent when the lAB-node 801 has detected a change of non-Fl/RRC donor-CU. For instance, if a MT migration process of the lAB-node 801 is performed during the DU migration of the lAB-node 801. This example method assumes that the IAB-MT 804 informs the IAB-DU2 806 of the current nonFl donor-CU through an internal communication in the lAB-node 801 between IAB-MT 804 and IAB-DU2 806.
  • the configuration update message 819 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • the configuration update message 819 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801.
  • the configuration update message 819 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801 (e.g.
  • the identification information (i.e. the identifier of the lAB-donor-CU serving the MT 804 and the identifier of the MT 804 as known by this lAB-donor-CU) may be provided to the MT 804 by the lAB-donor-CU serving the MT 804.
  • the lAB-donor-CU serving the MT 804 may use the message RRCReconfiguration, specified in TS 38.331 V17.2.0, and amended to include an information element for its TNL address (i.e. the IP address) and/or its identifier (i.e.
  • the RRCReconfiguration message is sent when the lAB-node 801 is integrated to the network (i.e. at the first connection to an lAB-donor-CU), and following a migration of the MT 804 of the lAB-node 801.
  • RRCReconfiguration message is sent by the target non-Fl donor-CU during the IAB inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.
  • RRCReconfiguration message may also indicate the BAP address assigned to the lAB-node 801 by the non-Fl donor-CU.
  • the configuration update message 819 may be followed by a configuration acknowledgment message 820 sent by the target Fl donor-CU 807 to IAB-DU2 806.
  • the messages 819 and 820 may correspond to the procedure described with reference to the figure 12d with the configuration update message 819 corresponding to configuration update message 1233 and the configuration acknowledgment message 820 corresponding to configuration acknowledge message 1234.
  • Figure 9a is a flowchart of an example method 900 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor- CU) of an lAB-node, the DU migration of the lAB-node with the indication of a lAB-donor- CU that is serving the MT of the lAB-node (e.g. a non-Fl/RRC terminating donor-CU) to the target lAB-donor-CU (e.g. Fl terminating donor-CU).
  • the source lAB-donor-CU e.g. Fl terminating donor- CU
  • the DU migration of the lAB-node with the indication of a lAB-donor- CU that is serving the MT of the lAB-node (e.g. a non-Fl/RRC terminating donor-CU) to the target lAB-donor-CU (e.g.
  • method 900 in accordance with embodiments of the present invention is performed at the source lAB-donor- CU and is for use in managing, or as part of, a migration process/procedure for migrating a DU of an lAB-node to a target lAB-donor-CU and for providing identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor-CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
  • a migration process/procedure for migrating a DU of an lAB-node to a target lAB-donor-CU and for providing identification information identifying the lAB-donor-CU that is serving the MT of the lAB-no
  • the source lAB-donor-CU performing the method 900 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the lAB-node 570 with which the lAB-node 570 retains a Fl connection).
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target IAB- donor-CU.
  • the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807.
  • the method 900 as shown in and described with respect to figure 9a may be performed by software elements and/or hardware elements.
  • the source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9a being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the source Fl terminating donor-CU determines that the DU of the lAB-node, like the lAB-node 570 of figure 5 (701, 801) is to be migrated from the source Fl donor-CU 501, 703, 803 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 807).
  • the source Fl donor-CU 501, 703, 803 decides the DU migration of an lAB-node, like the lAB-node 570, toward a target Fl donor-CU, like the donor-CU 503, 707, 807.
  • the source Fl donor-CU 501, 703, 803 may determine that the DU 572 of the lAB-node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the lAB-node 570, 701, 801 toward a new parent lAB-node (which may be a new lAB-node or a new lAB-donor- DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above.
  • the source Fl terminating donor-CU 501, 703, 803 may execute or perform the DU migration of the lAB-node through the procedure described with the reference 720 in figure 7. Besides, the step 902 may be executed after the step 903 or step 904.
  • the source Fl terminating donor-CU 501, 703, 803 sends to the target Fl donor-CU 503, 707, 807 a notification including identification information for identifying the lAB-donor-CU serving the MT 571 of the lAB-node 570.
  • the notification includes identification information for identifying the non-Fl terminating donor-CU of the lAB-node 570, 701, 801.
  • the non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 (the donor-CU 709 in figure 7).
  • the indication of the non-Fl terminating donor-CU 502, 709 may be sent only if this non-Fl terminating donor-CU 502, 709 is different from the target Fl donor-CU 503, 707, 807 (in other words, when the non-Fl donor-CU 502, 709 is not the same lAB-donor-CU as the target Fl donor-CU 503, 707, 807).
  • the message sent at step 903 may be the message 811 or the message 817 in figure 8.
  • the source Fl terminating donor-CU 501, 703, 803 may receive an acknowledgment from the target Fl terminating donor-CU 503, 707, 807.
  • the message received at step 904 may be the message 812 or the message 818 in figure 8.
  • Figure 9b is a flowchart of another example method 910 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor-CU) of an lAB-node, the DU migration of the lAB-node with the indication of a lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU) to the target lAB-donor-CU (e.g. Fl terminating donor-CU).
  • a lAB-donor-CU e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU
  • method 910 in accordance with embodiments of the present invention is performed at the source lAB-donor-CU and is for use in managing, or as part, of a migration process/procedure for migrating a DU of an lAB-node to a target lAB- donor-CU and for providing identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor-CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
  • identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU
  • the target lAB-donor-CU e.g.
  • the source lAB-donor-CU performing the method 910 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the lAB-node 570 with which the lAB-node 570 retains a Fl connection).
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target IAB- donor-CU.
  • the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807.
  • the method 910 as shown in and described with respect to figure 9b may be performed by software elements and/or hardware elements.
  • the source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9b being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the source Fl donor- CU 501, 703, 803 may determine that the DU of the lAB-node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the lAB-node 570, 701, 801 toward a new parent lAB-node (which may be a new lAB-node or a new IAB- donor-DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above.
  • the source Fl terminating donor-CU 501, 703, 803 sends to the lAB-node 570, 701, 801 a request for establishing a Fl connection (i.e. a new Fl connection) between the target lAB-donor-CU 503, 707, 807 and the lAB-node 570, 701, 801 (e.g. a new Fl association with the target lAB-donor-CU) and for informing the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801.
  • a Fl connection i.e. a new Fl connection
  • the source Fl terminating donor-CU 501, 703, 803 sends to the lAB-node 570, 701, 801 to be migrated, a request for a new Fl connection.
  • the request from the source Fl terminating donor-CU 501, 703, 803 may indicate (explicitly or implicitly) to the lAB-node 570, 701, 801 that the lAB-node is to inform the target lAB-donor-CU 503, 707, 807 of the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801.
  • the request from the source lAB-donor-CU 501 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT.
  • the information may include an Information Element, IE, for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node as discussed below with respect to figure 12a and the configuration request message 1203.
  • the presence of the IE in the request for establishing a Fl connection may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU or when the IE has a certain value (e.g. the IE may be one bit and the certain value may be ‘ 1’ or ‘0’) may indicate to the IAB- node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor- CU.
  • the IE may be one bit and the certain value may be ‘ 1’ or ‘0’
  • the request may also include identification information for identifying an lAB-donor- CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801 (such as the non-Fl/RRC terminating donor-CU 502 when the MT has been migrated to the lAB-donor-CU 502 or the Fl terminating donor-CU 501 when the MT has not been migrated).
  • identification information for identifying an lAB-donor- CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801 such as the non-Fl/RRC terminating donor-CU 502 when the MT has been migrated to the lAB-donor-CU 502 or the Fl terminating donor-CU 501 when the MT has not been migrated.
  • the information may include identification information for identifying the lAB-donor-CU serving the MT of the lAB-node 570 and the presence of the identification information in the request may itself indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU.
  • the request may be the message 813 described with reference to figure 8. With this message, the source Fl donor-CU 501, 703, 803 may send, to the lAB-node 570, 701, 801 the request to indicate a non-Fl/RRC terminating donor-CU to the target Fl terminating donor-CU 503, 707, 807.
  • the non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 (709 in figure 7).
  • the source Fl terminating donor-CU 501, 703, 803 may receive an acknowledgment of activation from the lAB-node 570, 701, 801.
  • the message received at step 913 may be the message 816 shown in and described with respect to figure 8.
  • Figure 9c is a flowchart of an example method 920 in accordance with one or more embodiments of the invention, performed at an lAB-node to perform Fl setup request to a target donor-CU while indicating the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU).
  • the lAB-donor-CU e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU.
  • method 920 in accordance with embodiments of the present invention is performed at the lAB-node and is for use in, or as part of, a migration process/procedure for migrating a DU of an IAB- node to a target lAB-donor and for providing identification information identifying the IAB- donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor- CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
  • the IAB- donor-CU e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU
  • the target lAB-donor-CU e.g. the Fl terminating donor- CU
  • the lAB-node performing the method 920 may be the mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501 (e.g. a Fl terminating donor-CU of the mobile lAB-node 570 with which the mobile lAB-node 570 retains a Fl connection) which is the source lAB-donor-CU.
  • IAB topology 5001 also referred to as source IAB topology
  • the lAB-donor-CU 501 e.g. a Fl terminating donor-CU of the mobile lAB-node 570 with which the mobile lAB-node 570 retains a Fl connection
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU.
  • the lAB-node may be mobile lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807.
  • the method 920 as shown in and described with respect to figure 9c may be performed by software elements and/or hardware elements.
  • the lAB-node may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9c being performed by an apparatus for the lAB-node including one or more processing units, such as the central processing unit 411.
  • an lAB-node like the lAB-node 570 of figure 5 (701, 801), receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), a request for establishing a Fl connection or a new Fl connection (for example, a Fl connection between the lAB-node 570, 701, 801 and a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 807)) and for informing the target lAB-donor-CU of the identity of the IAB- donor-CU serving the MT 571, 704, 804 of the lAB-node.
  • a source Fl terminating donor-CU like the donor-CU 501 of figure 5 (703, 803
  • a request for establishing a Fl connection or a new Fl connection for example, a Fl connection between the lAB-node 570, 701, 801 and a target Fl donor-CU, like the donor-CU 503 of figure 5
  • the request may be the message 813 described with reference to figure 8, and the request includes a request to indicate the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node (e.g. a non-Fl/RRC terminating donor-CU) to the target Fl donor-CU 503, 707, 807.
  • the non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 or the donor-CU 709 in figure 7.
  • the request may include identification information for identifying the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node.
  • the lAB-node may already know the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the IAB- node. For example, the lAB-node may obtain this information at MT migration. In another example, the lAB-node may obtain the NR Cell Global Identifier (NCGI) from a System Information Block (SIB) broadcasted in a cell controlled by the parent lAB-node in the IAB topology controlled by the non-Fl terminating donor-CU. This identifier (NCGI) may be sufficient for the target Fl donor-CU to identify the non-Fl terminating donor-CU.
  • SIB System Information Block
  • the lAB-node 570, 701, 801 then sends, to the target Fl donor-CU 503, 707, 807, a Fl setup request requesting the setup of the Fl connection.
  • the Fl setup request message sent by the lAB-node includes identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
  • the Fl setup request message may also include identification information for identifying the source Fl terminating donor-CU 501, 703, 803.
  • the message sent at the step 922 may be the message 814 in figure 8.
  • Figure 9d is a flowchart of an example method 930 in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, the transport migration after DU migration of an lAB-node.
  • Method 930 is an example of method 1400 described above.
  • the target lAB-donor-CU performing the method 930 may be the lAB-donor-CU 503 which controls IAB topology 5003.
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003.
  • the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807.
  • the method 930 as shown in and described with respect to figure 9d may be performed by software elements and/or hardware elements.
  • the target lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9d being performed by an apparatus for the target lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the target Fl terminating donor-CU like lAB-donor-CU 503 of figure 5 (707, 807), receives from an lAB-node, like lAB-node 570 of figure 5 (701, 801), a Fl setup request for requesting set up of a Fl connection between the target lAB-donor-CU and the lAB-node.
  • the Fl setup request message sent by the lAB-node may include identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g.
  • the Fl setup request message may also include identification information for identifying the source Fl terminating donor- CU.
  • the non-Fl terminating donor-CU may be the donor-CU 502 in figure 5 or the donor- CU 709 in figure 7.
  • the message received at the step 931 may be the Fl setup request message 814 as shown in and described with respect to figure 8.
  • the target Fl terminating donor-CU 503, 707, 807 in response to receiving the request at step 931, may send an acknowledgment to the lAB-node 570, 701, 801.
  • the acknowledgment may be the message 815 as shown in and described with respect to figure 8.
  • the target Fl terminating donor-CU like lAB-donor- CU 503 of figure 5 (707, 807), receives a notification from the source lAB-donor-CU, such as lAB-donor-CU 501 of figure 5 (703, 803) with the notification including identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g.
  • the notification may be a DU migration notification such as the DU migration notification message 811 as shown in and described with respect to figure 8.
  • the notification may be a configuration update notification, such as the configuration update message 817 as shown in and described with respect to figure 8.
  • the target Fl terminating donor-CU 503, 707, 807 based on the identification information and after the DU of the lAB-node has been migrated to the target IAB topology, performs transport migration for migrating traffic related to or associated with the lAB-node for routing over at least one path between the target lAB-donor-CU and the lAB-node through an IAB topology managed by the lAB-donor-CU serving the MT.
  • the target Fl terminating donor-CU 503, 707, 807 sends, to the non-Fl donor-CU, a traffic migration request (e.g.
  • Figure 10 is a simplified diagram 1000 illustrating another example message flows, according to one or more embodiments of the invention, for providing identification information identifying the lAB-donor-CU that is serving a MT of a lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU serving the MT) to a target lAB-donor-CU (e.g. the Fl terminating donor-CU) of a DU migration of the lAB-node, as part of a DU migration process of the lAB-node for use in managing or facilitating transport migration.
  • a lAB-node e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU serving the MT
  • a target lAB-donor-CU e.g. the Fl terminating donor-CU
  • the message flows shown in and described below with respect to figure 10 relate to the case where the MT of the lAB-node has been migrated to another lAB-donor-CU, e.g. a non-Fl lAB-donor-CU, which is different to the source lAB-donor-CU (source Fl donor- CU) and the target lAB-donor-CU (target Fl donor-CU).
  • a non-Fl lAB-donor-CU which is different to the source lAB-donor-CU (source Fl donor- CU) and the target lAB-donor-CU (target Fl donor-CU).
  • This figure 10 shows a source Fl donor-CU 1003 like the donor-CU 501, 703, a target Fl donor-CU 1007 like the donor-CU 503, 707, and a non-Fl /RRC donor-CU 1009 like the donor-CU 502, 709.
  • the beginning of the flow corresponds to the end of UEs handover procedure 730 of the figure 7 after the DU migration of an lAB-node, like the lAB-node 570, 701, when the source Fl donor-CU 1003 of the lAB-node can release the traffic migration toward the non- Fl donor-CU 1009, and when the target Fl donor-CU 1007 can request traffic migration toward the non-Fl donor-CU 1007. It is assumed that the MT of the lAB-node was previously migrated toward the IAB topology managed by the non-Fl donor-CU 1009, and that the traffic related to the UEs served by the lAB-node was routed via the IAB topology managed by the non-Fl donor-CU 1009.
  • the source Fl donor-CU 1003 sends a transport migration release message 1011 to the non-Fl donor-CU 1009 to request the release of traffic related to the handed over UEs, and thus to the lAB-node with migrated DU.
  • the transport migration release message 1011 may include a request for requesting release of transport migration set up by the source lAB-donor-CU for traffic related to the lAB-node.
  • the non-Fl donor-CU 1009 responds with the transport migration response message 1012 to acknowledge the release operation.
  • the message 1011 may include the indication that the traffic migration release is due to the DU migration of an lAB-node toward a target Fl donor-CU 1007.
  • the message 1011 may include the identifiers of the migrated lAB-node known by the source Fl donor-CU 1003 and the non-Fl donor-CU 1009, with the information elements F 1 -Terminating lAB-donor UE XnAP ID and non-F I -Terminating IAB -donor UE XnAP ID (or RRC-Terminating lAB-donor UE XnAP ID).
  • the message 1011 may also include the identifier of the target Fl donor-CU 1007 (i.e.
  • the non-Fl donor-CU 1009 may release the transport migration (e.g. set up by the source lAB-donor-CU) by deleting the configuration of lAB-nodes involved in the routing of packets to/from the migrated lAB-node within the IAB topology controlled by the non-Fl donor-CU 1009.
  • the non-Fl donor-CU 1009 may reconfigure the lAB-nodes involved in routing traffic to and/or from the lAB-node (e.g. the lAB-nodes in the routing path(s) to the IAB- node) by sending configuration update information for deleting, at each lAB-node, configuration information associated with routing traffic to and/or from the lAB-node.
  • the non-Fl donor-CU 1009 may send updated configuration information (e.g.
  • routing configuration tables to the lAB-node(s) in the routing path(s) to the migrated lAB-node so that the configuration at these lAB-node(s) in the routing path(s) for routing of packets to/from the migrated lAB-node within the IAB topology is deleted.
  • the DU 572 of IAB- node 570 has been migrated to lAB-donor-CU 503 and the lAB-node 570 is connected to lAB-node 550 via backhaul link 505, after DU migration, the lAB-donor-CU 502 as the non- Fl donor-CU may release the transport migration by reconfiguring the configuration information at lAB-donor-DU 506, and lAB-nodes 540 and 550 by deleting the configuration information associated with routing traffic to/from the lAB-node 570.
  • the non-Fl donor-CU 1009 may only suspend the traffic migration by maintaining the configuration of these lAB-nodes e.g. the lAB-nodes in the routing path are not reconfigured to delete the configuration information associated with routing traffic to/from the migrated lAB-node. Indeed, as the request for traffic migration release is due to a DU migration of the related lAB-node toward a target Fl donor-CU, a request for traffic migration from this target Fl donor-CU should be soon received by the non-Fl donor-CU 1009.
  • the non-Fl donor-CU 1009 sends a transport migration response 1012 to the source Fl donor-CU 1003 to acknowledge the received message 1011.
  • the messages 1011 and 1012 may correspond to the procedure described at the figure 13b where message 1011 corresponds to message 1313 and message 1012 corresponds to message 1314.
  • the non-Fl donor-CU 1009 further sends, to the target Fl donor-CU 1007, a notification for indicating the second lAB-donor-CU is ready to support transport migration, with the notification including identification information for identifying the non-Fl donor- CU 1009 in order to notify the target Fl donor-CU 1007 of the identity of the non-Fl donor- CU 1009 so that traffic, related to the lAB-node, can be migrated to a path (or at least one path) between the target Fl donor-CU 1007 and the migrated lAB-node 570 through the IAB topology managed by the non-Fl donor-CU 1009.
  • the notification may be included in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 to indicate its role (i.e. the non-Fl donor-CU for the lAB-node), and to indicate the readiness to support the migration of traffic in its IAB topology.
  • the message 1013 may include the identifier of the IAB-MT 804 known by the non-Fl donor-CU 1009 with the information element non-Fl- Terminating lAB-donor UE XnAP 7D, defined in TS 38.423 section 9.2.3.16, or RRC- Terminating IAB -donor UE XnAP ID, and the identifier gNB-DU ID of the logical DU having a Fl connection with the target Fl donor-CU 1007.
  • the message 1013 may also or alternatively include the BAP address assigned by the non-Fl/RRC donor-CU. 1009.
  • the transport migration ready message 1013 may include the characteristics (e.g. throughput, quality of service) of the traffic ready to be migrated, by taking the same characteristics that was previously migrated by the source Fl donor-CU 1003.
  • this target Fl donor-CU 1007 sends a transport migration request message 1014 to request the migration of traffic related to the served UEs toward the IAB topology controlled by the non-Fl donor-CU 1009.
  • the non-Fl donor-CU 1009 may accept the migration and may configure the lAB-nodes in its lAB-topology to route packets to/from the lAB-node serving the UEs, according to the traffic characteristics (e.g. throughput, quality of service) provided by the target Fl -donor-CU 1007.
  • traffic characteristics e.g. throughput, quality of service
  • the non- Fl donor-CU 1009 sends a transport migration response message 1015 to the target Fl donor- CU 1007 to acknowledge the transport migration.
  • the non-Fl donor-CU 1009 had maintained the configuration of lAB-nodes upon reception of the message 1011, and in case the characteristics of the traffic to migrate are equivalent to the characteristics of the traffic that was previously migrated by the source Fl donor-CU 1003, the non-Fl donor-CU 1009 has just to resume the transport migration and to send the response 1015 to the target Fl donor-CU 1007.
  • the messages 1014 and 1015 may correspond to the procedure described at the figure 13b with message 1014 corresponding to message 1313 and message 1015 corresponding to message 1314.
  • Figure 1 la is a flowchart of another example method 1100 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor-CU) of an lAB-node, the DU migration of the lAB-node with the indication of the lAB-donor-CU that is serving the MT of the lAB-node, the non-Fl terminating donor-CU or RRC terminating donor-CU, to the target lAB-donor-CU (e.g. the Fl terminating donor-CU).
  • the source lAB-donor-CU e.g. Fl terminating donor-CU
  • the DU migration of the lAB-node with the indication of the lAB-donor-CU that is serving the MT of the lAB-node
  • the non-Fl terminating donor-CU or RRC terminating donor-CU to the target lAB-donor-CU (e.g. the Fl terminating donor
  • the source lAB-donor-CU performing the method 1100 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the IAB- node 570 with which the lAB-node 570 retains a Fl connection).
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU.
  • the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the lAB-node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707 1007.
  • the method 1100 as shown in and described with respect to figure I la may be performed by software elements and/or hardware elements.
  • the source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure I la being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the source Fl terminating donor-CU determines that the DU of the lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7) is to be migrated from the source Fl donor-CU 501, 703, 1003 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 1007).
  • the source Fl donor- CU 501, 703, 1003 decides the DU migration of an lAB-node, like the lAB-node 570, toward a target Fl donor-CU, like the donor-CU 503, 707, 1007.
  • the source Fl donor- CU 501, 703, 1003 may determine that the DU of the lAB-node 570, 701 is to be migrated in response to determining the migration of the MT of the lAB-node 570, 701 toward a new parent lAB-node (which may be a new lAB-node or a new lAB-donor-DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 1003 determines the target Fl terminating donor-CU 503, 707, 1007 is also described above.
  • the source Fl terminating donor-CU 501, 703, 1003 executes or performs the DU migration of the lAB-node through the procedure described with the reference 720 in figure 7.
  • the source Fl terminating donor-CU 501, 703, 1003 sends to the non-Fl terminating donor-CU of the lAB-node a transport migration release for the traffic related to the lAB-node 570, 701, and indicating the target Fl donor-CU 503, 707, 1007 for the DU migration of this lAB-node (e.g. providing identification information for identifying the target Fl donor-CU).
  • the indication of the target Fl donor-CU 503, 707, 1007 may be sent only if the non-Fl terminating donor-CU is different from the target Fl donor-CU 503, 707.
  • the message sent at step 1103 may be the message 1011 in figure 10.
  • Figure 1 lb is a flowchart of an example method 1110 in accordance with embodiments of the present invention, for managing, at the non-Fl/RRC terminating donor-CU of an IAB- node, the transport migration in case of DU migration of the lAB-node.
  • method 1110 in accordance with one or more embodiments of the invention is performed at a IAB- donor-CU to which a MT of the lAB-node has been migrated (e.g. non-Fl terminating donor- CU or RRC terminating donor-CU, and also referred to as a second lAB-donor-CU) and is for use in managing transport migration for traffic related to or associated with an lAB-node.
  • the transport migration is to be performed after a DU of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor-CU to a target IAB topology managed by the target lAB-donor-CU.
  • the non-Fl terminating donor-CU is a different IAB- donor-CU to the target lAB-donor-CU and the source lAB-donor-CU.
  • the lAB-donor-CU performing the method 1110 may be the lAB-donor-CU 502 (e.g a non-Fl/RRC terminating donor-CU or non-Fl/RRC donor-CU of the lAB-node 570 with which the lAB-node 570 retains a RRC connection).
  • the IAB- node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU.
  • the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the IAB- node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707, 1007.
  • the method 1110 as shown in and described with respect to figure 1 lb may be performed by software elements and/or hardware elements.
  • the source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 1 lb being performed by by an apparatus for the non-Fl lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the non-Fl terminating donor-CU receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 1003) of an lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7), a transport migration release (e.g. the transport migration release message 1011) for requesting release of transport migration set up by the source Fl donor-CU, 501, 703, 1003 for the traffic related to or associated with the lAB-node.
  • the transport migration release may include identification information for identifying or indicating the target Fl terminating donor-CU for the DU migration of the lAB-node.
  • the target Fl terminating donor-CU may be the donor-CU 503 in figure 5 or the donor-CU 707 in figure 7 or the donor-CU 1007 in figure 10.
  • the non-Fl terminating donor-CU 502, 709, 1009 releases (or suspends) the transport migration previously setup upon the request of the source Fl terminating donor- CU 501, 703, 1003.
  • the terminating donor- CU 502, 709, 1009 reconfigures the lAB-nodes involved in routing traffic to and/or from the lAB-node by deleting, at each lAB-node, configuration information associated with routing traffic to and/or from the lAB-node.
  • the configurations at the lAB-nodes involved in routing traffic to and/or from the lAB-node are kept.
  • the non-Fl terminating donor-CU 502, 709, 1009 sends to the target Fl donor-CU 503, 707, 1007, a notification for indicating the second lAB-donor-CU is ready for transport migration for the traffic related to the lAB-node 570, with the notification including identification information for identifying the non-Fl donor-CU 1009.
  • the notification may be sent in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 as discussed above.
  • the non-Fl terminating donor-CU 501, 703, 1003 receives from the target Fl donor-CU 503, 707, 1007 a transport migration request for the traffic related to the IAB- node 570.
  • the transport migration request may be sent in the transport migration request message 1014 discussed above.
  • the non-Fl terminating donor-CU 501, 703, 1003 activates (or resumes) the transport migration according to the request from the target Fl terminating donor-CU 503, 707, 1007 so that traffic related to the lAB-node is routed over at least one path between the target Fl terminating donor-CU 503, 707, 1007 and the lAB-node through the IAB topology managed by non-Fl terminating donor-CU 501, 703, 1003 serving the MT.
  • Figure 11c is a flowchart of another example method 1120 in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an lAB-node, the transport migration in case of DU migration of the lAB-node.
  • the target lAB-donor-CU performing the method 1120 may be the lAB-donor-CU 503 which controls IAB topology 5003 (also referred to as target IAB topology).
  • the lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501.
  • the migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003.
  • the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the IAB- node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707, 1007.
  • the method 930 as shown in and described with respect to figure 11c may be performed by software elements and/or hardware elements.
  • the target lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 11c being performed by an apparatus for the target lAB-donor-CU including one or more processing units, such as the central processing unit 411.
  • the target Fl terminating donor-CU like lAB-donor-CU 503 of figure 5 (707, 1007), receives from the non-Fl terminating donor-CU, like the donor-CU 502 of figure 5 (709, 1009), of an lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7), a message indicating the non-Fl terminating donor-CU 502, 709, 1009 is ready for transport migration for the traffic related to the lAB-node 570.
  • the target Fl terminating donor-CU 503, 707, 1007 receives, from the non-Fl terminating donor-CU 502, 709, 1009, a notification for indicating the non-Fl terminating donor-CU 502, 709, 1009 is ready for transport migration for the traffic related to the lAB-node 570, with the notification including identification information for identifying the non-Fl donor-CU 1009.
  • the notification may be sent in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 as discussed above
  • the target Fl terminating donor-CU 503, 707, 1007 performs the transport migration for the traffic related to the IAB- node 570 toward the IAB topology controlled by the non-Fl terminating donor-CU 502, 709, 1009.
  • the target Fl terminating donor-CU 503, 707, 1007 performs transport migration for migrating traffic related to or associated with the lAB-node for routing over at least one path between the target Fl terminating donor-CU 503, 707, 1007 and the lAB-node through the IAB topology managed by the non-Fl terminating donor-CU 502, 709, 1009.
  • Figure 12a is a schematic and simplified diagram 1200 illustrating an example message flow of a procedure to perform the activation of a logical DU according to an example.
  • a RAN node DU 1201 that may be DU of an lAB-node like IAB-DU 572 of IAB- node 570 of figure 5 (and IAB-DU1 805 of lAB-node 801 of figure 8),
  • RAN node CU 1202 that may be an lAB-donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8).
  • the message CONFIGURATION REQUEST 1203 is sent by the RAN node CU 1202 to the RAN node DU 1201 either 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.
  • the message 1203 may include the TNL address (i.e. IP address) of a RAN node CU (e.g. the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated.
  • CONFIGURATION REQUEST 1203 may be sent by the source lAB-donor-CU to the lAB-node (e.g. the first logical DU entity 805 having a Fl connection with the source lAB-donor-CU) for requesting establishment of a Fl connection between a target lAB-donor- CU and the lAB-node.
  • the message 1203 may also include an information element (IE) requesting the RAN node DU 1201 to transmit to the RAN node CU (e.g. the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated, the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • This IE may be limited to one bit: one value (i.e. “0” or “1”) of this one-bit IE means no specific action is requested and another value (i.e.
  • the message 1203 may include the identifier of the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201, as known by the RAN node CU terminating the RRC connection with the information element non-F 1 -Terminating I AB -donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16 or RRC-Terminating 1 AB-donor UE XnAP ID.
  • MT Mobile Termination
  • the RAN Node DU 1201 may acknowledge the request with the message CONFIGURATION RESPONSE 1204 sent to the RAN Node CU 1202.
  • the flow in figure 12a corresponds to the procedure gNB- CU Configuration Update procedure described in TS 38.473 V17.0.0 section 8.2.5
  • the message 1203 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10
  • the message 1204 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11.
  • the message GNB-CU CONFIGURATION UPDATE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated at the RAN Node DU 1201.
  • the GNB-CU CONFIGURATION UPDATE includes information to activate the new cell(s) indicated in the IE Cells to be Activated List, which new cell(s) may be served by the first logical DU entity 805 at the lAB-node 801.
  • the cell(s) to be activated refer to cell(s) controlled by the RAN Node DU 1201 receiving the request.
  • the associated PCI and NCGI value(s) to be used by the RAN Node DU 1201 may also be provided.
  • the message GNB-CU CONFIGURATION UPDATE may also include the Information Element (IE) Cells to be Deactivated List to indicate the list cell(s) to be deactivated.
  • the cell(s) to be deactivated refer to cell(s) controlled by the RAN node DU 1201 receiving the request.
  • the GNB-CU CONFIGURATION UPDATE may include information to deactivate the cell(s) indicated in the IE Cells to be Deactivated List which cell(s) are currently served by the first logical DU entity 805 at the lAB-node 801.
  • a new IE Second DU Activation may be added in the message 1203 in the form of a Boolean (e.g. a one-bit IE) to request the activation of a second logical DU.
  • a Boolean e.g. a one-bit IE
  • One value (i.e. “0” or “1”) of the one-bit IE means no specific action related to the second logical DU is requested and another value (i.e. “1” or “0”) means activation of a second logical DU is requested.
  • This IE may be completed by a new IE indicating a number of cells to be activated in the second logical DU. In the absence of this IE, the number of cells to be activated corresponds to the number of cells currently activated in the RAN Node DU 1201. The presence of this IE may indicate that the BAP address that identifies the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 shall
  • a new IE may be added (e.g. Target TNL address IE) to identify the target RAN Node CU with which a Fl connection shall be setup.
  • Another IE may be added to request to send the address and/or identifier of the RAN node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1201 (e.g. the address and/or identifier of the lAB-donor-CU serving the MT of the IAB- node).
  • This IE may be the address (e.g. non-Fl TNL address IE or RRC TNL address IE) or the identifier of (e.g. non-Fl Global NG-RAN Node ID or RRC Global NG-RAN Node ID), and its presence indicates that it shall be included in the request for Fl connection.
  • Another IE may be added to identify the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 (e.g. non-F I -Terminating 1 AB -donor UE XnAP ID or RRC-Terminating lAB-donor UE XnAP ID), and its presence indicates that it shall be included in the request for Fl connection.
  • the presence of this IE may indicate that the BAP address that identifies the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 shall be inserted in the request for Fl connection.
  • 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.
  • IE Information Element
  • Figure 12b is a schematic and simplified diagram 1210 illustrating an example message flow of a procedure to setup a logical DU, so as to establish a Fl connection with the target lAB-donor-CU, according to an example.
  • a RAN node DU 1211 that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU2 806 of lAB-node 801 of figure 8),
  • RAN node CU 1212 that may be an lAB-donor-CU like lAB-donor-CU 503 of figure 5 (and target Fl donor-CU 807 of figure 8).
  • the message SETUP REQUEST 1213 is sent by the RAN node DU 1211 to the RAN node CU 1212 to request the Fl setup for the logical DU.
  • SETUP REQUEST 1213 may be sent by the lAB-node (e.g. by the second logical DU entity 806 which has been activated at the lAB-node 801) to the target lAB-donor-CU 807 for requesting set up of a Fl connection between a target lAB-donor-CU and the lAB-node (e.g. with the second logical DU entity 806 of the lAB-node 801)).
  • the SETUP REQUEST message 1213 may be sent after an activation request as described with reference to figure 12a.
  • This SETUP REQUEST message 1213 may include the number of cells to be activated along with activation of the logical DU.
  • This SETUP REQUEST message 1213 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the Fl connection of the RAN node DU 1211 (e.g. the source lAB-donor-CU 803).
  • This message may include the TNL address (i.e. the IP address) and/or the identifier (i.e.
  • the message 1213 may also include at least one of:
  • the TNL address i.e. the IP address
  • the identifier i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3
  • TNL address i.e. the IP address
  • the identifier i.e. Global NG-RAN Node RD
  • the identifier for the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1211 e.g.
  • non-F 1 -Terminating 1 AB -donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID known by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211, the BAP address of the MT of the RAN node embedding the RAN node DU 1211, assigned by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211, the identifier gNB-DU ID of the RAN node DU 1211.
  • the RAN node CU 1212 answers with the message SETUP RESPONSE 1214 sent to the RAN node DU 1211. It may include a list of cell(s) to activate with the logical DU, along with the associated PCI and NCGI value(s) to be used.
  • the flow in figure 12b corresponds to the procedure Fl setup described in TS 38.473 V17.2.0 section 8.2.3
  • the message 1213 corresponds to the message Fl SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4
  • the message 1214 corresponds to the message Fl SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5
  • the message Fl SETUP RESPONSE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated.
  • the cell(s) to be activated refer to cell(s) controlled by the RAN node DU 1211 receiving the response.
  • Figure 12c is a schematic and simplified diagram 1220 illustrating an example message flow of a procedure to remove a logical DU.
  • a RAN node DU 1221 that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU1 805 of lAB-node 801 of figure 8),
  • RAN node CU 1222 that may be an lAB-donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8).
  • the message REMOVAL REQUEST 1223 is sent by the RAN node CU 1222 to the RAN node DU 1221 to request the removal (which is equivalent to deactivation) of the logical DU.
  • the RAN node DU 1221 answers with the message REMOVAL RESPONSE 1214 sent to the RAN node CU 1222.
  • the flow in Figure 12c corresponds to the procedure Fl removal described in TS 38.473 V17.2.0 section 8.2.8
  • the message 1223 corresponds to the message Fl REMOVAL REQUEST described in TS 38.473 VI 7.2.0 section 9.2.1.16
  • the message 1224 corresponds to the message Fl REMOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7.
  • Figure 12d is a schematic and simplified diagram 1230 illustrating an example message flow of a procedure used by a logical DU to inform an lAB-donor-CU about a change of configuration, according to an example.
  • a RAN node DU 1231 that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU2 806 of lAB-node 801 of figure 8),
  • RAN node CU 1232 that may be an lAB-donor-CU like lAB-donor-CU 503 of figure 5 (and target Fl donor-CU 807 of figure 8).
  • CONFIGURATION UPDATE 1233 is sent by the RAN node DU 1231 to the RAN node CU 1232 to indicate a configuration change for the RAN node embedding the RAN node DU 1231.
  • CONFIGURATION UPDATE message 1233 may be sent by the RAN node DU 1231 for indicating to the RAN node CU 1232 the identifier of the RAN node CU serving the MT of the RAN node embedding the RAN node DU 1231.
  • the message 1233 is sent by the second logical DU entity 806 that has been activated at the IAB- node 801 to the target lAB-donor-CU 807 to indicate the lAB-donor-CU serving the MT 804 of the lAB-node 801.
  • This CONFIGURATION UPDATE message 1233 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211 (e.g.
  • the address and/or identifier of the lAB-donor-CU serving the MT of the lAB-node may also include at least one of the identifier for the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1231 (e.g.
  • MT Mobile Termination
  • non-F 1 -Terminating 1 AB -donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID known by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231, the BAP address of the MT of the RAN node embedding the RAN node DU 1231, assigned by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231, the identifier gNB-DU ID of the RAN node DU 1231.
  • the RAN node CU 1232 answers or responds with the message CONFIGURTION ACKNOWLEDGE 1234 sent to the RAN node DU 1231.
  • the identifier for the Mobile Termination (MT) of the RAN node may be provided by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231.
  • the flow in figure 12d corresponds to the procedure gNB- DU configuration update described in TS 38.473 V17.2.0 section 8.2.4, amended to include the information elements described above.
  • the message 1233 corresponds to the message GNB-DU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.7
  • the message 1234 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.8.
  • Figure 13a is a schematic and simplified diagram 1300 illustrating an example message flow of a procedure used by a RAN Node CU to report configuration information to another RAN Node CU according to an example.
  • This figure shows two RAN nodes, RAN node CUa 1301 and RAN node CUb 1302, that may be two lAB-donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5.
  • RAN node CUa 1301 may be the target Fl donor-CU 807
  • RAN node CUb 1302 may be the source Fl donor-CU 803 depending on the purpose of the messages.
  • 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 about the activation of new cell(s) in a logical DU of a RAN node DU like the IAB-DU2 806 of the lAB-node 801.
  • the source Fl donor-CU 803 receives the CONFIGURATION UPDATE message 1303 from the target Fl donor-CU 807 and the CONFIGURATION UPDATE message 1303 includes identification information (e.g. PCI, NRGI) identifying one or more new cells that have been activated at a second logical DU entity (IAB-DU2 806) of the DU of the lAB-node 801.
  • identification information e.g. PCI, NRGI
  • the message CONFIGURATION UPDATE 1303 can also be used by the RAN node CUa 1301 to the RAN node CUb 1302 to inform the RAN node CUb 1302 about the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of a RAN node CU terminating the RRC connection of a RAN node embedding a RAN node DU (e.g. the address and/or identifier of the lAB-donor- CU serving the MT of the lAB-node) that is to be migrated toward the RAN node CUb 1302.
  • RAN node CUa 1301 is the source Fl donor-CU 803
  • RAN node CUb 1302 is the target Fl donor-CU 807.
  • the messages 1303 may also include at least one of:
  • the identifier of the migrated RAN node as known by the RAN node CUb 1302, with the information element target F 1-Terminating lAB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node, and/or the identifier gNB-DU ID of a logical DU of the migrated RAN node having a Fl connection with the RAN node CUb 1302,
  • the RAN node CUb 1302 answers with the message CONFIGURATION ACKNOWLEDGE 1304 sent to the RAN node CUa 1301 to acknowledge the reception of the message 1303.
  • the Figure 13a corresponds to the procedure NG-RAN node configuration update described in TS 38.423 V17.2.0 section 8.4.2
  • the message 1303 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 9.1.3.4, amended with IES listed above
  • the message 1304 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.5.
  • Figure 13b is a schematic and simplified diagram 1310 illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration (e.g. setup, modification, or release of Fl traffic such as user/control traffic) in coordination with another RAN Node CU according to an example.
  • This figure shows two RAN nodes, RAN node CUa 1311 and RAN node CUb 1312, that may be two lAB-donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5.
  • 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, or modification, or release in the IAB topology controlled by the RAN node CUb 1312.
  • the source Fl donor-CU 803 may send a MIGRATION REQUEST 1313 to the non-Fl donor-CU to request release of the traffic (e.g.
  • the target Fl donor-CU 807 may send a MIGRATION REQUEST 1313 to the non-Fl donor-CU to request traffic (e.g. Fl traffic) migration to the non-Fl donor-CU’ s topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 807 through the IAB topology managed by the non-Fl donor-CU).
  • the target Fl donor-CU 807 may send a MIGRATION REQUEST 1313 to the non-Fl donor-CU to request traffic (e.g. Fl traffic) migration to the non-Fl donor-CU’ s topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 807 through the IAB topology managed by the non-Fl donor-CU).
  • the message MIGRATION REQUEST 1313 is sent by the RAN node CUa 1311 to the RAN node CUb 1312 to notify the DU migration of an lAB-node.
  • the RAN node CUb 1312 acknowledges with the message MIGRATION RESPONSE 1314, the RAN node CUb 1312 may include an identifier the RAN node CUb 1312 has assigned for the migrated lAB-node, for instance the information element target Fl- Terminating I AB -donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated lAB-node.
  • MT Mobile Termination
  • the message 1313 may include at least one of
  • the identifier of the target Fl 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
  • the identifier gNB-DU ID (as specified in TS 38.473 section 9.3.1.19) of the logical DU of the lAB-node 801 served by the target Fl donor-CU 807.
  • the RAN node CUb 1312 answers with the message MIGRATION RESPONSE 1314 sent to the RAN node CUa 1311 to accept or reject the request.
  • the figure 13b may correspond to the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2.
  • the message 1313 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.2
  • the message 1314 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4 3.
  • the TRANSPORT MIGRATION MANAGEMENT procedure is the one specified in TS 38.423 V17.2.0 section 8.5.2 (which can be referred to as the legacy procedure)
  • the target Fl donor-CU 807 should know the UE XnAP ID assigned by the non-Fl donor-CU.
  • both BAP address and UE XnAP ID shall be provided to the target Fl donor-CU (through the procedure described at the figure 13a), so that the target Fl donor-CU can associate the UE XnAP ID with the BAP address.
  • the TRANSPORT MIGRATION MANAGEMENT procedure is amended to allow not providing a UE XnAP ID but the BAP address instead, then only the BAP address may be provided to the target Fl donor-CU (through the procedure described with reference to the figure 13a).
  • the figure 13b may also correspond to the IAB transport migration modification procedure specified in TS 38.423 V17.2.0 section 8.5.3.
  • the message 1313 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.
  • the message 1314 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.5.
  • a mobile lAB-node can be partially migrated as other lAB-nodes according to Release 17.
  • this mobile IAB-MT (mlAB-MT) handover is driven by the radio conditions, and it should not be delayed to maintain backhaul connection and to avoid service interruption at the served UEs.
  • a mlAB-MT handover should not be delayed to maintain backhaul connection and to avoid service interruption at the served UEs.
  • MT handover is driven by the radio conditions while DU migration decision may be based, for instance, on the available connectivity between donor-CUs and/or for load balancing purpose.
  • the criteria to select a target donor-CU for a mobile lAB-node depend on the migration type, i.e., MT handover or DU migration.
  • the target Fl donor-CU should be informed about the current non-Fl donor-CU serving the co-located mlAB-MT of the mobile lAB-node. This would allow the target Fl donor-CU to setup the IAB transport migration toward the non-Fl donor-CU’ s topology.
  • the target Fl donor-CU for the migration of a mobile IAB-DU should be informed about the current non-Fl donor-CU serving the co-located mobile IAB- MT.
  • the mobile IAB- node has successfully performed the Fl setup procedure with a target Fl donor-CU for DU migration purpose, and that this target Fl donor-CU is different from the non-Fl donor-CU for the mobile lAB-node. If meanwhile, a MT migration of the mobile lAB-node has occurred toward a target non-Fl donor-CU (still different from the target Fl donor-CU), the target Fl donor-CU may not be aware of this new non-Fl donor-CU to perform the transport migration management (TMM) procedure.
  • TMM transport migration management
  • the target logical mlAB-DU’s CU needs to be informed about the mlAB- MT’s CU ID and the mlAB-MT ID so that it can initiate the Xn TMM procedures towards mlAB-MT’s CU,
  • this statement may not be accurate enough to prevent any deadlock situation in case of concurrent MT and DU migrations. Indeed, it does not say when the target Fl donor-CU (i.e. the target logical mlAB-DU’s CU) is informed about the non-Fl donor-CU (i.e the mlAB-MT’s CU ID). If the target Fl donor-CU was informed before the MT migration, then the target Fl donor-CU will trigger the TMM procedures toward a donor-CU that may no longer be the non-Fl donor-CU.
  • the target Fl donor-CU i.e. the target logical mlAB-DU’s CU
  • the above statement could be completed by the following: if the mlAB-MT’s CU is changed during a DU migration, the target logical mlAB-DU’s CU needs to be informed about the target mlAB-MT’s CU ID and the mlAB-MT ID, before it can initiate the TMM procedures towards the target mlAB-MT’s CU.
  • a mobile IAB-MT migration is driven by the radio conditions, and it should not be delayed to maintain backhaul connectivity and to avoid service interruption at the served UEs. It means that a mobile IAB-MT handover may be triggered and executed while a migration of the co-located mobile IAB-DU is on-going.
  • option 2 seems more efficient than option 1 when considering the support of concurrent DU and MT migrations. Therefore, if concurrent DU and MT migrations have to be supported, then the procedures for MT and DU migrations are defined taking into account the possible concurrence of DU and MT migrations (option 2).
  • one question to address is which node informs the target Fl donor-CU for the DU migration of a mobile lAB-node about the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID).
  • the source Fl donor-CU may relay to the target Fl donor-CU the identification information previously received from the source non-Fl donor-CU at the MT migration of the mobile lAB-node.
  • the non-Fl donor-CU the non-Fl donor-CU.
  • the source Fl donor-CU should have provided to the non-Fl donor-CU the identification information related to the target Fl donor-CU.
  • the migrating lAB-node In this case, the non-Fl donor-CU should have provided the identification information to the lAB-node.
  • the 3 following options may be considered to provide the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID) to the target Fl donor-CU for the DU migration of a mobile lAB-node:
  • Option 2 may be a suitable option as it is in line with the following statement:
  • the source donor CU for the mlAB-MT HO provides to the donor CU serving the mlAB-DU at least the: gNB ID of the target donor CU for the ml AB -MT HO.
  • the mobile IAB- node has successfully performed the Fl setup procedure with a target Fl donor-CU for DU migration purpose, and that this target Fl donor-CU is different from the non-Fl donor-CU for the mobile lAB-node. If meanwhile, a MT migration of the mobile lAB-node has occurred toward a target non-Fl donor-CU (still different from the target Fl donor-CU), the target Fl donor-CU may not be aware of this new non-Fl donor-CU to perform the transport migration management (TMM) procedure.
  • TMM transport migration management
  • the target logical mlAB-DU’s CU needs to be informed about the mlAB-MT’s CU ID and the mlAB-MT ID so that it can initiate the Xn TMM procedures towards mlAB-MT’s CU.
  • this statement may not be accurate enough to prevent any deadlock situation in case of concurrent MT and DU migrations. Indeed, it does not say when the target Fl donor- CU (i.e. the target logical mlAB-DU’s CU) is informed about the non-Fl donor-CU (i.e the mlAB-MT’s CU ID). If the target Fl donor-CU was informed before the MT migration, then the target Fl donor-CU will trigger the TMM procedures toward a donor-CU that may no longer be the non-Fl donor-CU.
  • the target Fl donor- CU i.e. the target logical mlAB-DU’s CU
  • the above statement could be completed by the following: if the mlAB-MT’s CU is changed during a DU migration, the target logical mlAB-DU’s CU needs to be informed about the target mlAB-MT’s CU ID and the mlAB-MT ID, before it can initiate the TMM procedures towards the target mlAB-MT’s CU.
  • - option 3 to not support concurrent DU and MT migrations, to define the procedures, and in a second step to add the necessary mechanisms to avoid this concurrence. It can be observed that a mobile IAB-MT migration is driven by the radio conditions, and it should not be delayed to maintain backhaul connectivity and to avoid service interruption at the served UEs. It means that a mobile IAB-MT handover may be triggered and executed while a migration of the co-located mobile IAB-DU is on-going.
  • option 2 seems more efficient than option 1 when considering the support of concurrent DU and MT migrations.
  • one question to address is which node informs the target Fl donor-CU for the DU migration of a mobile lAB-node about the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID).
  • Option A XnAP signalling from the mlAB-DU’s source CU.
  • Option B F1AP signalling from the target logical mlAB-DU.
  • both options can support concurrent MT and DU migrations according to the way it is performed.
  • the source Fl donor-CU may relay to the target Fl donor-CU the identification information previously received from the source non-Fl donor-CU at the MT migration of the mobile lAB-node.
  • the XnAP procedure NG-RAN node Configuration Update procedure may be appropriate.
  • the F1AP procedure gNB-DU Configuration Update may be appropriate as it can be triggered at any time, for instance when the non-Fl donor-CU has changed.
  • option A seems more straight forward than option B as it does not involve the migrating lAB-node as intermediate node.
  • XnAP signalling from the mlAB-DU’s source CU is used for providing the gNB-ID of the mlAB-MT’s CU and the XnAP UE ID of the mlAB-MT at this CU to the mlAB-DU’s target CU.
  • the identifier of the MT of the mobile lAB-node may be the BAP address assigned by the lAB-donor-CU controlling the mlAB-MT (and sent to the mlAB-MT via RRC protocol message when the mlAB-MT connects to this lAB-donor- CU), and that the lAB-donor-CU controlling the mlAB-MT may be referred to as the non-Fl terminating donor-CU or RRC terminating donor-CU, it can be further questioned which ID assigned by the MT’s CU for the IAB MT should be used for the TMM procedure and how this ID can be mapped to a corresponding IAB node.
  • this ID assigned by the RRC terminating donor-CU may be a BAP address or a UE XnAP ID.
  • the BAP address selected by the RRC terminating donor-CU can be provided by the target logical mobile IAB-DU to the target Fl terminating donor-CU (i.e. the mlAB-DU’s CU) in the legacy Rel-16/17 Fl setup request message.
  • the TMM request message shall be amended to allow the use of the BAP address IE instead of the non-Fl terminating lAB-donor UE XnAP ID IE.
  • the behavior of the RRC terminating donor-CU receiving this TMM request message shall be adapted accordingly. Indeed, according to the Release 17 specifications (TS 38.423), the presence of UE XnAP IDs allocated by the Fl terminating donor-CU and by the RRC terminating donor-CU is mandatory for the TMM procedure.
  • the UE XnAP ID allocated at the RRC terminating donor-CU should be provided to the target Fl terminating donor-CU.
  • the target Fl terminating donor-CU there are two options:
  • This option involves that the UE XnAP ID is provided to the mobile lAB-node beforehand, e.g. through RRC by the RRC terminating donor-CU. With this option, it is not needed to provide a BAP address in the Fl setup request message.
  • This option may involve the introduction of a new XnAP procedure.
  • an additional piece of information known by the target Fl terminating donor-CU shall 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 lAB-node, assuming this BAP address was present in the Fl setup request message from the target logical mobile IAB-DU to the target Fl terminating donor-CU, and assuming this BAP address is also available at the source Fl terminating donor-CU.
  • F1AP signalling from the target mobile IAB-DU is selected for transferring the UE XnAP ID of the mobile IAB MT (at the RRC terminating donor-CU) to the target Fl terminating donor-CU.
  • the mobile lAB-node provides the identification information based on information received from the RRC terminating donor-CU (i.e. the mlAB-MT’s CU),
  • the RRC terminating donor-CU provides the identification information once the RRC terminating donor-CU knows the identifier of the Fl terminating donor-CU from the mobile lAB-node.
  • the RRC terminating donor-CU shall provide an identifier of the mobile lAB-node known by the Fl terminating donor-CU.
  • This identifier may be the BAP address of the mobile IAB-MT selected by the RRC terminating donor-CU, assuming this BAP address was present in the Fl setup request message from the mobile IAB-DU to the Fl terminating donor-CU.
  • the F1AP signalling can be the same as for the case of DU migration. Moreover, it seems there is less specifications impact with option 1 than with option 2.
  • F1AP signalling from the mobile IAB-DU is selected for transferring the gNB-ID of the RRC terminating donor-CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor-CU) to the F 1 terminating donor-CU.
  • the mobile lAB-node should also provide identification information related to the target RRC terminating donor-CU at MT migration.
  • F1AP signalling from the mobile IAB-DU is selected for transferring the gNB-ID of the target RRC terminating donor-CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor-CU) to the F 1 terminating donor-CU.
  • the F1AP procedure gNB-DU Configuration Update is appropriate to inform the Fl terminating donor-CU in the case of MT migration.
  • the gNB-DU Configuration Update procedure can be used by a mobile lAB-node to inform the Fl terminating donor-CU about the gNB-ID of the RRC terminating donor-CU and the UE XnAP ID of the mobile IAB-MT at this CU.
  • the mlAB-MT’s source donor CU can send the info on the mlAB- MT’s target donor CU to the mlAB-DU’s donor CU after the completion of IAB-MT HO (handover).
  • the proposal is compatible with this statement as the source RRC terminating donor-CU (i.e. the mlAB-MT’s source donor CU) would pass the information to the Fl terminating donor-CU (i.e. the mlAB-DU’s donor CU), not directly, but through the mobile lAB-node.
  • 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 advantageously used.
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.
  • Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol.
  • computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave.
  • Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure.
  • a computer program product may include a computer- readable medium.
  • such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • any connection is properly termed a computer-readable medium.
  • a computer-readable medium For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium.
  • DSL digital subscriber line
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method and apparatus for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node, is disclosed. The transport migration to be performed after a Distributed Unit, DU, of the IAB-node has been 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. A method at the target IAB-donor-CU comprises: receiving a notification including identification information for identifying an IAB-donor-CU serving a Mobile Termination, MT, of the IAB-node, the IAB-donor-CU serving the MT of the IAB-node being a different IAB-donor-CU to 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, performing transport migration for migrating traffic related to the IAB-node for routing over at least one path between the target IAB-donor-CU and the IAB-node through an IAB topology managed by the IAB-donor-CU serving the MT. The target IAB- donor-CU may receive the notification from the source IAB-donor-CU, from the IAB-node or from the IAB-donor-CU serving the MT.

Description

MIGRATION OF NODES IN AN IAB COMMUNICATION SYSTEM
Field of the Invention
The present invention generally relates to methods for use in a process for migrating nodes and traffic between Integrated Access and Backhaul, IAB, topologies of a wireless communication system involving mobile lAB-nodes. Particularly, the present invention relates to a method for use in a migration process in which a Distributed Unit, DU, of an lAB-node, for example a mobile lAB-node, is migrated between IAB topologies and a method for use in managing transport migration after DU migration of an lAB-node.
Background
Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations. The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH).
Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi.
The demand for network densification increases due to the rising number of users and higher throughput requirement.
Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, from release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs).
IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations. IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. However, millimeter waves are known to be subject to strong attenuations of signal strength in some weather conditions (rain, fog), and to blockage in case of obstacles located in the path between the emitter and the receiver.
To manage these potential radio link failures, a topological redundancy can be provided within the IAB framework, where multiple data paths are set up between the IAB base station directly connected to the core network (also referred to as the “IAB-donor”) and the IAB base station serving UEs (also referred to as the “access lAB-node” for the UEs). Several intermediate IAB base stations (also referred to as lAB-nodes) may be involved in each of the several paths between the IAB-donor and the access lAB-node, thus forming alternative data paths within a multi-hop IAB topology.
Besides, 3 GPP has been considering inter-donor redundancy, where an lAB-node, referred to as a boundary lAB-node, can access two different parent nodes connected to two different lAB-donors, with each of the lAB-donors managing a different IAB topology (also referred to as IAB network). The boundary lAB-node, even though belonging to a single IAB topology, i.e. belonging to a single IAB-donor for configuration and management, is thus able to 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 lies in the ability for the first IAB-donor to perform offloading by routing some of its packets through the second IAB topology, thus mitigating congestion issues or overcoming radio link failure issues that may arise in the first IAB topology.
There are other situations where an lAB-node becomes a boundary node. For example, in the case of partial migration of an lAB-node, decided by the IAB-donor, where the Mobile Termination (MT) of the lAB-node becomes connected to a single parent lAB-node belonging to another IAB topology controlled by another IAB-donor. This situation may also happen in the case of an lAB-node that experienced radio link failure (RLF) and that has recovered through a parent lAB-node belonging to another IAB topology. In those cases, the migrated lAB-node and its potential descendant lAB-node(s) still belong to the initial IAB topology, and such partial migration may be called MT migration. In order to ensure that traffic can be routed through the other IAB topology, MT migration should be followed by traffic migration where the traffic related to the boundary node and its descendant lAB-nodes is routed through the other IAB topology up to the boundary node (i.e. the migrated lAB-node). Stationary lAB-nodes should only require a single MT migration. Indeed, a backhaul link (defined between two successive lAB-nodes in the wireless backhaul) may experience radio failure due to fluctuations of radio conditions and, for lAB-nodes that do not move, it should be a temporary situation with possible link recovery after some time. Thus, it should not be required for such stationary lAB-nodes to perform multiple MT migrations in the same IAB topology or toward another IAB topology, and the transmission and the handling of multiple protocol messages can be avoided. For the same reason, the migration of the Distributed Unit (DU) of the lAB-node, leaving the control of the lAB-node to a new lAB-donor, should not be required for stationary nodes. Moreover, it is noted that such DU migration, that may be called full migration, also involves the handover of UEs served by the migrating mobile lAB-node.
Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public/private passengers transportation, goods delivery, food trucks ...). Some of these vehicles (e.g. buses, trams, trains), may have predictable routes and a significant number of collocated UEs (i.e. passengers’ devices). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as mobile relays. These mobile relays would rely on 5G wireless backhaul (typically IAB, or Integrated Access & Backhaul) for connecting to a fixed donor device.
Thus, based upon the fixed IAB foundations of releases 16 and 17, 3GPP is now considering Mobile IAB systems and architecture, as a part of the release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles (such as buses, trains, taxis). In such scenarios, mobile lAB-nodes can be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage/capacity to on-board and/or surrounding UEs.
The technical benefits of using VMRs include, among others, is the ability of the VMR to offer good radio link conditions to the nearby UEs. Additionally, comparing with a solution using a UE as relay (i.e. a Sidelink Relay solution), an lAB-node mounted on a vehicle is expected to have better RF/antenna capabilities, and to have less stringent power / battery constraints than a relay UE.
For a mobile lAB-node it may be worth performing multiple MT migrations or DU migration, as the connection to a parent lAB-node belonging to a first IAB topology may not occur again for a long time as the mobile lAB-node moves around or never again in the case where the mobile lAB-node moves away from the parent lAB-node. Besides, for flexible IAB network management, MT and DU migration should be decorrelated, meaning that a DU migration for an lAB-node may independently occur before or after one or several MT migrations of this lAB-node. Moreover, the DU migration for an lAB-node may be performed toward an lAB-donor different to the lAB-donor associated to the MT of this lAB-node.
In particular, after the MT migration of an lAB-node toward a first lAB-donor, followed by a DU migration of this lAB-node toward a second lAB-donor different from the first lAB- donor, the second lAB-donor may have to request a migration of the traffic related to the IAB- node toward the IAB topology controlled by the first lAB-donor.
Therefore, some new mechanisms are required to provide such flexibility by supporting the DU migration of an lAB-node toward any other lAB-donor, decorrelated to the MT migration(s) of the lAB-node.
Summary
In accordance with a first aspect of the present invention, there is provided a method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node, the transport migration to be performed after a Distributed Unit, DU, of the IAB- node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, the method at the target lAB-donor-CU comprising: receiving a notification including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node, the lAB-donor-CU serving the MT of the lAB-node being a different lAB-donor- CU to the target lAB-donor-CU; based on the identification information and after the DU of the lAB-node has been migrated to the target IAB topology, performing transport migration for migrating traffic related to the lAB-node for routing over at least one path between the target lAB-donor-CU and the lAB-node through an IAB topology managed by the IAB- donor-CU serving the MT.
The lAB-donor-CU (e.g. RRC donor-CU) serving the MT may be the source IAB- donor-CU if the MT of the lAB-node has not been migrated from the source lAB-donor-CU. Alternatively, the lAB-donor-CU (e.g. non-Fl donor-CU or RRC donor-CU) serving the MT may be another or second lAB-donor-CU managing a second IAB topology. In this latter case, the path between the target lAB-donor-CU and the MT of the lAB-node is through the second IAB topology. The target lAB-donor-CU may receive the notification from the source lAB-donor-CU, from the lAB-node (e.g. in a Fl setup request) or from the lAB-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 lAB-donor-CU before or after performing DU migration). In another example, the notification received from the source lAB-donor-CU may be received in a configuration update message. The configuration update message may be sent by the source lAB-donor-CU at any time: for example, before or after performing DU migration, when the source lAB- donor-CU detects a change in the lAB-donor-CU serving the MT. An advantage of being able to send the configuration update message at any time, is that the if the source IAB- donor-CU has already provided, to the target lAB-donor-CU, the address and/or identifier of an ‘old’ lAB-donor-CU that had previously served the MT of the lAB-node and which is now ‘old’ because the MT has been migrated to a ‘new’ lAB-donor-CU, then the source IAB- donor-CU can send an update through the configuration update message including identification information for identifying the new lAB-donor-CU.
In accordance with a second aspect of the present invention, there is provided a method for use in managing a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, performed at the source lAB-donor-CU, as recited in any one of claims 13 to 19 of the accompanying claims.
In accordance with a third aspect of the present invention, there is provided a method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, performed at the source lAB-donor-CU, as recited in any one of claims 20 to 24 or claim 44 of the accompanying claims.
In accordance with a fourth aspect of the present invention, there is provided a method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, performed at the lAB-node, as recited in any one of claims 25 to 31 or claim 44 of the accompanying claims. In accordance with a fifth aspect of the present invention, there is provided a method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node, the transport migration is to be performed after a Distributed Unit, DU, of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, a Mobile Termination, MT, of the lAB-node having been migrated to a second lAB-donor-CU , the second lAB-donor-CU being a different lAB-donor-CU to the target lAB-donor-CU and the source lAB-donor-CU, performed at the second lAB-donor-CU, as recited in any one of claims 32 to 39 or claim 44 of the accompanying claims.
In accordance with a sixth aspect of the present invention, there is provided a method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, performed at the lAB-node, as recited in any one of claims 40 to 44 of the accompanying claims.
In accordance with a seventh aspect of the present invention, there is provided an apparatus for an lAB-donor-CU as recited in any one of claims 45 to 50 of the accompanying claims.
In accordance with a eighth aspect of the present invention, there is provided an apparatus for an lAB-node as recited in any one of claims 51 to 56 of the accompanying claims.
By sending, whether it’s by the source lAB-donor-CU or the lAB-node or the IAB- donor-CU serving the MT, a notification to the target lAB-donor-CU, which notification includes identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node, the target lAB-donor-CU is informed of the current IAB- donor-CU serving the co-located MT of the lAB-node which enables the target lAB-donor- CU to setup the IAB transport migration toward the topology of the current lAB-donor-CU serving the MT of the lAB-node.
Further example features of the invention are described in other independent and dependent claims.
Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus/device/unit aspects, and vice versa. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.
Brief Description of the Drawings
Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which:
Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more embodiments;
Figure 2a and 2b schematically illustrate stacks of some protocol layers involved into IAB operations;
Figure 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet;
Figure 4 is a block schematic diagram of an example wireless communication device in accordance with embodiments of the present invention;
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;
Figure 6 is a schematic and simplified diagram illustrating an example of lAB-node architecture enabling its DU migration from a source IAB topology to a target IAB topology;
Figure 7 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to perform DU migration of an lAB-node including the handover of UEs served by the migrating lAB-node;
Figure 8 is a simplified diagram illustrating example message flows, according to one or more embodiments of the invention, to identify the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU for the DU migration of an lAB-node;
Figure 9a is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an lAB-node, the DU migration of the lAB-node with the identification of a non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
Figure 9b is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- node, the DU migration of the lAB-node with the identification of a non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
Figure 9c is a flowchart of an example method in accordance with one or more embodiments of the invention, performed at an lAB-node to perform Fl setup request to a target donor-CU while identifying a non-Fl terminating donor-CU (or RRC terminating donor-CU);
Figure 9d is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, the transport migration after DU migration of an lAB-node;
Figure 10 is a simplified diagram illustrating another example message flow, according to one or more embodiments of the invention, to identify the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU of the DU migration of an lAB-node;
Figure 1 la is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the source Fl terminating donor-CU of an IAB- node, the DU migration of the lAB-node with the identification of the non-Fl terminating donor-CU (or RRC terminating donor-CU) to the target Fl terminating donor-CU;
Figure 1 lb is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at the non-Fl terminating donor-CU (or RRC terminating donor-CU) of an lAB-node, the transport migration in case of DU migration of the lAB-node;
Figure 11c is a flowchart of another example method in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an IAB- node, the transport migration in case of DU migration of the lAB-node.
Figure 12a is a simplified diagram illustrating an example message flow of a procedure to perform the activation of a logical DU according to one or more embodiments of the invention;
Figure 12b is a simplified diagram illustrating an example message flow of a procedure to setup a logical DU; Figure 12c is a simplified diagram illustrating an example message flow of a procedure to remove a logical DU;
Figure 12d is a simplified diagram illustrating an example message flow of a procedure used by a logical DU to inform RAN node CU about a change of configuration;
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;
Figure 13b is a simplified diagram illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration in coordination with another RAN node CU;
Figure 14 is a flowchart of an example method in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, transport migration after DU migration of an lAB-node.
Detailed Description
Figure 1 illustrates an example communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network supporting mobile lAB-node(s). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having a mobile base station. In particular, the following description predominantly uses terminology specific to 5G, but it should be appreciated that such terminology also applies to elements or processes performing an equivalent function in other communication systems.
The system 100 comprises 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 lAB-nodes 121 and 122 (also referred to in the following as IAB- nodes), and a mobile Integrated Access and Backhaul (IAB) station 123 mounted on a vehicle 105 (for example, a bus, a train, a taxi, a car, etc.).
The main Base Station 120, also referred to as the lAB-donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, lAB-donor 120 is a 5G NR gNB with additional functionality to support IAB features, as defined in 3GPP TS 38.300 vl7.2.0 specification document.
In order to extend the network coverage of lAB-donor 120 and reach the remote UEs 132, 133 and 131, IAB stations 121 and 122, also referred to as lAB-nodes 121 and 122, have been installed by the operator. By acting as relaying nodes between the lAB-donor 120 and the UEs 132 and 133, lAB-nodes 121 and 122 allow overcoming the reachability issue resulting from presence of building 108, which is an obstacle to the propagation of radio waves and hence to the direct attachment and further communications between the UEs and the lAB-donor 120. This is particularly true when the communications between the IAB- donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.
The lAB-donor 120 also serves UE 134, which is directly connected to it.
The mobile IAB station 123, also referred to as mobile lAB-node 123 or mlAB-node 123, is an lAB-node that is mounted on vehicle 105 and provides network coverage and capacity extension, allowing the lAB-donor 120 to reach onboard remote UEs, like remote UE 135, as well as surrounding UEs or UEs in the vicinity of the lAB-node 123, like remote UE 136.
The lAB-donor 120 and the lAB-nodes 121, 122 and 123 are thus forming a backhaul network or IAB network, or IAB topology, which accommodates UEs 132, 133, 131, 134, 135 and 136. The terms IAB network and IAB topology will be used interchangeably in the following.
The specification of the Integrated Access and Backhaul (IAB) is spread over several 3 GPP standard documents, including:
- TS 38.300 RAN architecture (V17.2.0),
- TS 38.321 MAC protocol (V17.2.0),
- TS 38.331 Radio Resource Control (RRC) protocol (V17.2.0),
- TS 38.340 Backhaul Adaptation Protocol Layer (V17.2.0),
- TS 38.401 RAN architecture (V17.2.0),
- TS 38.423 Xn Application Protocol (V17.2.0),
- TS 38.473 Fl Application Protocol (V17.2.0).
As lAB-donor 120 and lAB-nodes 121, 122 and 123 are respectively connected to UEs 134, 131, 132, 133, 135 and 136, they are considered as Access lAB-nodes for their respectively connected UEs. The lAB-donor 120 is a logical node that provides the NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed unit(s) (DU or gNB-DU functionality). The lAB-donor-CU or donor-CU (also referred to in the following as lAB-donor-CU or lAB-donor-CU) hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling operation of one or more DUs and each of the one or more lAB-donor-DUs or donor-DUs (also referred to in the following as lAB-donor-DU or lAB-donor-DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols. The lAB-donor- CU or donor-CU and lAB-donor-DU or donor-DU may be located far from the other or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. It aims at terminating the NR access interface to the UEs and next-hop lAB-nodes, and at terminating the Fl protocol to the lAB-donor gNB-CU functionality as shown in Figures 2a and 2b discussed below.
The lAB-nodes, which may serve multiple radio sectors, are wireless backhauled to the lAB-donor 120, via one or multiple hops over one or more intermediate lAB-nodes. They form a directed acyclic graph (DAG) topology with the lAB-donor at its root.
The lAB-nodes each consist of an IAB-DU (I AB -Distributed Unit) and an IAB-MT (lAB-Mobile Termination). The gNB-DU functionality on an lAB-node is also referred to as IAB-DU and allows the downstream (toward the UE) connection to the next-hop IAB or to a UE. The IAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access Stratum (NAS) functionalities to connect to the gNB-DU of an upstream lAB-node (including the lAB-donor 120 in which case it connects to the lAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration).
In this DAG topology, the neighbour node on the IAB-DU’ s interface is referred to as child node and the neighbour node on the IAB-MT’ s interface is referred to as parent node. The direction toward the child node is further referred to as downstream while the direction toward the parent node is referred to as upstream.
The lAB-donor 120 (e.g. the lAB-donor-CU) performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the lAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data packets.
Figures 2a and 2b schematically illustrate stacks of some protocol layers involved in IAB operations. Fl interface supports the exchange of signalling information (e.g. control traffic) between the endpoints, as well as the data transmission (e.g. user traffic transmission) to the respective endpoints. From a logical standpoint, Fl interface is a point-to-point interface between the endpoints.
In 5G NR, Fl-C is the functional interface in the Control Plane (CP) between the IAB- donor -CU and an I AB -node -DU (e.g. of I AB -node 2), and between the lAB-donor-CU and an lAB-donor-DU. Fl-U is the functional interface in the User Plane (UP) for the same units. Fl-C and Fl-U are shown by reference 212 in Figure 2a. In this example, Fl-U and Fl-C are carried over two backhaul hops (from I AB -donor to I AB -node 1 and then from I AB -node 1 to IAB-node2).
In the User Plane, boxes 210 at the lAB-donor-CU and the lAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer. GTP-U stands for GPRS Tunnelling Protocol User Plane. GTP-U Tunnels are used to carry encapsulated PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints (refer to 3GPP TS 29.281 for more details), here boxes 210 at the lAB-donor-CU and the lAB-node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram service and fit to use with an IP protocol.
In the Control Plane, boxes 210 indicate the F1AP (Fl Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer. The Fl Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signalling services between the lAB-donor-CU and the lAB-node DU, or UE associated services. These services are for example initialization, configuration, and so on. The well-known SCTP layer provides reliable, in sequence transport of messages with congestion control.
Fl-U and Fl-C rely on an IP transport layer between the lAB-donor-CU and the IAB- node DU as defined in 3 GPP TS 38.401.
The transport between the lAB-donor-DU and the lAB-donor-CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the lAB- donor-CU is remote from the lAB-donor-DU, or locally in a virtual instantiation of the IAB- donor-CU and the lAB-donor-DU on the same physical machine. lAB-specific transport between lAB-donor-CU and lAB-donor-DU is specified in 3GPP TS 38.401.
LI and L2 on the Figure 2a stand respectively for the transport and physical layers appropriate to the medium in use. The IP layer can also be used for non-Fl traffic, such as Operations, Administration and Maintenance traffic.
On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340.
The lAB-DU’s IP traffic is routed over the wireless backhaul via the BAP sublayer. In a downstream direction, upper layer packets are encapsulated by the BAP sublayer at the lAB-donor-DU, thus forming BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the destination lAB-node (which may be an access lAB-node should the upper layer packets in the BAP packets be intended for a UE).
In an upstream direction, upper layer packets are encapsulated by the BAP sublayer at an initiator lAB-node (which may be an access lAB-node should the upper layer packets come from a UE), thus forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate lAB-nodes, if any. The BAP packets are finally deencapsulated by the BAP sublayer at the lAB-donor-DU.
On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packets, and which is set by the BAP sublayer of the emitting lAB-donor-DU or initiator lAB-node (e.g. a network node in the IAB network generating the BAP packets). Figure 3 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 17.2.0.
The payload section 307 is usually an IP packet. The header 30 includes fields 301 to 306. Field 301, named D/C field, is a Boolean indicating whether the corresponding BAP packet is a BAP Data packet or a BAP Control packet. Fields 302-304 are 1 -bit reserved fields, preferably set to 0 (to be ignored by the receiver).
Fields 305 and 306 indicate together the BAP routing ID for the BAP packet. BAP address field 305, also referred to as DESTINATION field, is located in the leftmost 10 bits while BAP path identity field 306, also referred to as PATH field, is located in the rightmost 10 bits. Field 305 carries the BAP address (i.e. on the BAP sublayer) of the destination IAB- node or lAB-donor-DU for the BAP packet. For the purpose of routing, each lAB-node and lAB-donor-DU in an IAB network is configured (by lAB-donor-CU of the IAB network) with a designated and unique BAP address. Field 306 carries a path ID identifying the routing path the BAP packet should follow to this destination in the IAB topology. For the purpose of routing, the routing paths, including their path ID, are configured (by lAB-donor-CU of the IAB network) in the lAB-nodes of the IAB network.
The BAP header is added to the packet when it arrives from upper layers to the BAP layer, and it is stripped off by the BAP layer when it has reached its destination node. The selection of the packet’s BAP routing ID is configured by the lAB-donor-CU.
For instance, when the BAP packet is generated by a node, i.e. either by the lAB-donor- DU for downstream transmission or by an initiator (which may be an access lAB-node should the upper layer packets come from a UE) for upstream transmission, the BAP header with the BAP Routing ID is built by this node according to a configuration table defined in 3GPP TS 38.340. This table is called Downlink Traffic to Routing ID Mapping Configuration table in the lAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the initiator lAB-node. In intermediate lAB-nodes, the BAP header fields are already specified in the BAP packet to forward.
As mentioned above, these configuration tables defining the BAP paths (hence the routing strategy and the configuration of the lAB-nodes given the IAB network topology) are usually defined by the lAB-donor-CU and transmitted to the lAB-nodes to configure them.
To transport messages over the 5G NR radio medium, three more sublayers (RLC, MAC and PHY) are implemented at each lAB-node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for the segmentation or reconstruction of packets. It is also responsible for requesting retransmissions of missing packets. The RLC layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for the user data and for the mapping of logical channel to the transport channels. The MAC handles also a part of the Hybrid Automated Repetition request scheme. The MAC layer is detailed in TS 38.321. On the emitter or transmitter side, the MAC encapsulates the data packet issued from the RLC. It adds a header carrying information necessary to the MAC function. On the receiver side, the MAC decapsulates the data packet issued from the PHY sublayer, deletes its header and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (the air) by converting the stream of information into physical modulation signals, modulating a carrier frequency at emitter side. At the receiver side, the PHY sublayer converts the physical modulation signals back to a stream of information. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214.
To pass messages towards the user or control plane, two other sublayers are used in the UE and lAB-donor-CU: the PDCP (Packet Data Convergence Protocol) sublayer and either the SDAP (Service Data Adaptation Protocol) sublayer for the User Plane communications or the RRC (Radio Resource Control) sublayer for the Control Plane communications.
The PDCP sublayer handles IP Header compression/decompression, ciphering/deciphering, and handles the integrity on the data packet if necessary. It mandatorily numbers the packets on the emitter side and reorders the packets on the receiver side. The PDCP sublayer is described in 3GPP TS38.323.
SDAP sublayer 220 for the User Plane handles the Quality of Service. It is described in TS38.324. On the UE side, the SDAP sublayer exchanges the payload data with the user’s application (voice, video, etc. . . - not shown in the Figure). On the lAB-donor-CU side, the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc...).
RRC sublayer 220 for the Control Plane handles the configuration of the protocol entities of the User Plane protocol stack. It is described in TS38.331. It is responsible for the handling of, inter alia, broadcasting information necessary to a UE to communicate with a cell; transmitting paging messages, managing connection, including setting up bearers; mobility functions; measurement configuration and reporting; devices capabilities.
The interface (for both CP and UP) between nodes using the layers PDCP, RLC, MAC and PHY is referenced NR-Uu. This mainly concerns the interface with the UE.
The interface (for both CP and UP) between nodes using the layers BAP, RLC, MAC and PHY is named BackHaul RLC Channel (BH RLC channel). This mainly concerns the interfaces between the lAB-nodes.
NR-Uu is the interface between the UE and the radio access network, i.e. its access I AB -node (for both CP and UP).
Figure 2b comes from 3GPP TS 38.300 vl7.2.0 and illustrates the protocol stack for the support of lAB-MT’s RRC and NAS connections. The Non-Access Stratum (NAS) protocol handles the messages between the core network and a user equipment, or an lAB-node. It manages the establishment of communication sessions and maintains communications with the lAB-node or the user equipment as it moves. The 5G NAS is described in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the Core Network that receives all connection and session related information from the UEs connected to the lAB-node, as well as similar information for the lAB-node. AMF is only responsible for handling connection and mobility management tasks.
The IAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the lAB-donor-CU. These SRBs are transported between the IAB-MT and its parent node(s) over NR-Uu interface(s).
Figure 4 shows a schematic representation of an example communication device (apparatus) or station, in accordance with one or more example embodiments of the present disclosure.
The communication device 400 may be a device such as a micro-computer, a workstation or a light portable device. The communication device 400 may comprise a communication bus 413 to which there are preferably connected:
- a central processing unit 411, such as a microprocessor, denoted CPU. The central processing unit 411 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out 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 is a matter of design choice for a skilled person;
- memory for storing data and computer programs containing instructions for the operation of the communication device 400. The computer programs may contain a number of different program elements (modules) or sub-routines containing instructions for a variety of operations and for implementing the methods in accordance with one or more embodiments of the invention; and
- at least one communication interface 402 for communicating with other devices or nodes in a communication system, such as the communication system of Figure 1. The at least one communication interface 402 may be connected to the radio communication network 403, such as a wireless communication network for 5GNR (e g. according to release 17 and/or subsequent releases), over which digital data packets or frames or control frames are transmitted. The frames are written from a FIFO sending memory in RAM 412 to the communication interface for transmission or are read from the communication interface for reception and writing into a FIFO receiving memory in RAM 412 under the control of a software application running in the CPU 411. Each of a donor-CU, a donor-DU, an lAB-node and a UE may be implemented in such a communication device/apparatus 100.
The memory may include:
- a read only memory 407, denoted ROM, for storing computer programs for implementing methods in accordance with one or more embodiments of the invention;
- a random-access memory 412, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to one or more embodiments of the invention.
Optionally, the communication device 400 may also include the following components:
- a data storage means 404 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention;
- a disk drive 405 for a disk 406, the disk drive being adapted to read data from the disk 1106 or to write data onto said disk;
- a screen 409 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 410 or any other input/output means.
In an example arrangement, the communication bus 413 provides communication and interoperability between the various elements included in the communication device 400 or connected to it. The representation of the bus is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by means of another element of the communication device 400.
The disk 406 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the communication device, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented.
The executable code may optionally be stored either in read only memory 407, on the hard disk 404 or on a removable digital medium such as for example a disk 406 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 403, via the interface 402, in order to be stored in one of the storage means of the communication device 400, such as the hard disk 404, before being executed. The central processing unit 411 may be adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 404 or in the read only memory 407, are transferred into the random-access memory 412, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.
In an example implementation, the communication device (apparatus) is a programmable device/apparatus which uses software to implement the invention. Instructions may be executed by one or more processors of the apparatus, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry to implement the invention for a network node (e.g. lAB-node, IAB- donor-CU). Accordingly, the term “central processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC or other logic element).
Figure 5 illustrates an 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. In one example implementation, the radio links between the lAB-nodes and between the lAB-nodes and the lAB-donor-DUs (referred to as BH radio links) are operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance. An IAB network will also be referred to as an IAB topology or topology and so in this application, the terms IAB network and IAB topology and topology will be used interchangeably.
IAB communication system 500 is composed of three IAB networks or IAB topologies 5001, 5002, and 5003 with each IAB topology comprising a set of lAB-nodes (e.g. the set may comprise a plurality of lAB-nodes or at least one lAB-node) and an lAB-donor-CU for controlling or managing the plurality of lAB-nodes. The set of lAB-nodes may include one or more lAB-nodes, such as initiator lAB-nodes which generate BAP packets and also intermediate or relay lAB-nodes. Each of the lAB-nodes communicate with at least one other lAB-node over a wireless backhaul (BH) link. Although Figure 5 shows three IAB topologies 5001, 5002, and 5003, the present invention is not limited to three IAB topologies and may be implemented in an IAB communication system comprising more than two IAB topologies with each topology comprising a set of lAB-nodes and an lAB-donor-CU as discussed above.
As discussed above, each lAB-node comprises a Mobile Termination (MT) part or unit, controlled and configured by the lAB-donor using RRC messaging as defined in 3 GPP TS 38.331, and a Distributed Unit (DU) part, controlled and configured by the lAB-donor using Fl-AP messaging as defined in 3GPP TS 38.473. For example, lAB-node 510 comprises a MT part or unit 511 and a DU part 512.
IAB topology 5001 includes lAB-donor-CU 501 (identified as Donor 1-CU in Figure 5), and its associated lAB-donor-DU 504 (identified as Donor 1-DU1 in Figure 5), and a plurality of lAB-nodes 510 and 520, similar to lAB-nodes 121 and 122.
IAB topology 5002 includes lAB-donor-CU 502 (identified as Donor2-CU in Figure 5), its associated lAB-donor-DUs, lAB-donor-DU 505 (identified as Donor2-DUl in Figure 5) and lAB-donor-DU 506 (identified as Donor2-DU2 in Figure 5), and a plurality of IAB- nodes 530, 540, 550, similar to lAB-nodes 121 and 122, and lAB-node 570, that may be similar to mobile lAB-node 123. All lAB-nodes can be access nodes serving UEs like the UE 580 served by the mobile lAB-node 570. The IAB topology 5002 is transparent for the UE 580 that connects to the donor-CU 502 through the DU part or unit 572 of the mobile IAB- node 570. Although figure 5 shows only one UE 580, it will be appreciated that there will be a plurality of UEs connected to the network nodes of the IAB communication system 500.
IAB topology 5003 includes lAB-donor-CU 503 (identified as Donor3-CU in Figure 5), and its associated lAB-donor-DU 507 (identified as Donor3-DUl in Figure 5), and an IAB- node 560, similar to lAB-nodes 121 and 122.
A wired backhaul IP network interconnects the lAB-donor-CUs 501, 502, and 503, and the lAB-donor-DUs 504, 505, 506 and 507 through the wired backhaul 508. For instance, this wired backhaul 508 consists of optical fiber cables. lAB-donor-CU 501, lAB-donor-DU 504 and lAB-nodes 510 and 520 are part of the same IAB network or IAB topology 5001, which is configured and managed or controlled by lAB-donor-CU 501. lAB-donor-CU 502, lAB-donor-DUs 505 and 506, and lAB-nodes 530, 540, 550 are part of the same IAB network or IAB topology 5002, which is configured and managed or controlled by lAB-donor-CU 502. lAB-donor-CU 503, lAB-donor-DU 507, and lAB-node 560 are part of the same IAB network or IAB topology 5003, which is configured and managed or controlled by IAB- donor-CU 803.
Each IAB-DU and lAB-donor-DU supports wireless communication in a coverage area(s) referred to as cell(s) (not shown in figure 5). In other words, each IAB-DU and IAB- donor-DU is associated with cell(s). Wireless communication devices (such as UEs, or other lAB-nodes) located within a cell may establish communication links with the node (i.e. IAB- DU or lAB-donor-DU) serving the cell in order to communicate with other devices (e.g. other UEs, lAB-nodes, servers providing access to the Internet, etc.) via the node.
It is assumed that the mobile lAB-node 570 had initially a single parent lAB-node 520, and that lAB-node 570 belongs to the IAB topology 5001 controlled by the lAB-donor-CU 501. The lAB-donor-CU is thus operating as the Fl terminating donor-CU (which may also be referred to as a Fl-terminating lAB-donor-CU or Fl donor-CU). When moving, and in view of its proximity to IAB topology 5002, in particular to the lAB-node 530 when the mobile lAB-node 570 is in the position shown in dotted lines in figure 5, the mobile IAB- node 570 may be able to establish a wireless BH link with the lAB-node 530. Such a BH link is possible for a stationary lAB-node, and it is very likely to happen for a mobile lAB-node like lAB-node 570, moving, for instance, in the direction of the IAB topology 5002 (shown by arrow 590 in figure 5.
Then, the Fl donor-CU 501 may have decided to perform the migration of the MT part 571 of the lAB-node 570 toward the IAB topology controlled by the donor-CU 502, which became the non-Fl terminating donor-CU (which may also be referred to as a non-Fl - terminating lAB-donor-CU or non-Fl donor-CU, or RRC donor-CU, or RRC terminating donor-CU) for the lAB-node 570 (i.e. the MT part 571 of the lAB-node 570 is migrated toward the parent lAB-node 530). For this purpose, the Fl donor-CU 501 may have initiated 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 (when the lAB-node 570 has descendant lAB-nodes). As a result, the lAB-node 570 still belongs to the IAB topology 5001, with its Fl connection to the donor-CU 501, but its RRC connection is now to the donor-CU2 502. After that procedure, the lAB-donor-CU 501 may request the migration toward the IAB topology 5002 (i.e. through the donor-DU 505) of the backhaul traffic (e.g. user traffic, control traffic) related to the lAB-node 570. In this case, the donor-CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. In the IAB communication system, all traffic communicated over backhaul links uses a Fl interface (Fl- C or Fl-U) between an lAB-donor-CU and an IAB-DU. Thus, the traffic or backhaul traffic that is offloaded or migrated is Fl traffic and can include control and user traffic.
While the mobile lAB-node 570 is still moving in the direction shown by arrow 590, the MT part 571 of the lAB-node 570 may then have been migrated by the non-Fl donor-CU 502 toward the parent lAB-node 550, using the backhaul link 5050 between the lAB-node 550 and the lAB-node 570. For this purpose, the non-Fl 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 consecutive MT migration (or another MT migration to another lAB-node) of the lAB-node 570 with a new single parent lAB-node 550. Still, the lAB-node 501 has its Fl connection with the donor-CU 501 and its RRC connection with the donor-CU2 502.
After being informed to use the donor-DU 506 instead of donor-DU 505 to route the Fl traffic related to the lAB-node 570, the donor-CU 501 may request the migration of the traffic related to the lAB-node 570 toward the IAB topology 5002. In this case, the donor-CU 501 triggers the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2.
While further moving, this time in the direction of IAB topology 5003 controlled by the donor-CU 503, the lAB-node 570 may become in a position where a backhaul link 5060 with the lAB-node 560 may have a better quality than the backhaul link 5050 with the lAB-node 550. Thus, the donor-CU 502 may apply the inter-CU Topology Adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3.1 or 8.17.3.2. After this consecutive MT migration, the lAB-node 501 still belongs to the IAB topology 5001, with its Fl connection with the donor-CU 501, but its RRC connection is now with the donor-CU 503 and thus, the donor-CU 503 becomes the non-Fl terminating donor-CU (or RRC terminating donor-CU). However, the donor-CU 501 has to be informed of the new non-Fl donor-CU 503 for the lAB-node 570 and of the new donor-DU 507 to redirect the offloaded traffic (Fl traffic, control and user traffic) through the donor-DU 507 instead of donor-DU 506.
In all the MT migration cases described above, the UE 580 still connects to the donor- CU 501 through the DU part or unit 572 of the mobile lAB-node 570. In case the lAB-node 570 has some child lAB-node(s), such child lAB-node still belongs to the IAB topology 5001, and it is still fully controlled (through Fl and RRC connections) by the donor-CU 501. At any state of migration of the MT part 571 of the lAB-node 570, thus regardless of whether the MT part 571 of the lAB-node 570 has migrated to IAB topology 5002 or IAB topology 5003 and so regardless of whether the lAB-node 570 has a non-Fl terminating donor-CU and if it does, whether it’s the non-Fl terminating donor-CU 502 or 503, the Fl donor-CU 501 may decide to perform the migration of the DU part of the lAB-node 570. The reason for performing DU migration may be to reduce the processing load at the Fl donor- CU 501, or because the lAB-node 570 is geographically far from the Fl donor-CU 501 and close to an area where there is no more Xn connectivity between the Fl donor-CU 501 and a target donor-CU. After the decision to perform the DU migration of the lAB-node 570, the Fl donor-CU 501 has also to decide toward which donor-CU (which is referred to as the target Fl donor-CU) the DU migration shall be performed. It may be a DU migration toward the current non-Fl terminating donor-CU (i.e. the default choice) if there is a current non-Fl terminating donor-CU and in this case the non-Fl terminating donor-CU becomes the target Fl donor-CU, or to another target Fl donor-CU. For instance, if the lAB-node 570 is mobile and its trajectory is predictable (e.g. for a bus or a train), the Fl donor-CU 501 may be aware of a suitable target Fl -donor-CU controlling cells through which the lAB-node 570 will soon connect to the network. For instance, while the non-Fl terminating donor-CU of the IAB- node 570 is the donor-CU 502, the Fl donor-CU may decide the DU migration of the IAB- node 570 should be directly toward the donor-CU 503, as the lAB-node 570 may rapidly cross and not stay in the IAB topology 5002 controlled by the donor-CU 502. To not perform the DU migration toward the donor-CU 502, and instead perform DU migration toward the donor-CU 503, will avoid protocol messages for the intermediate DU migration of the IAB- node 570. When DU migration is performed, handover of the UEs served by the lAB-node 570 must also be performed. Thus, to not perform the DU migration toward the donor-CU 502 will also avoid the intermediate handover of UEs served by the lAB-node 570 to the donor-CU 502, before a new DU migration and UEs handover toward the donor-CU 503.
The procedure to perform a DU migration and the UEs handover toward a selected target Fl donor-CU is described in more detail with reference to the subsequent figures.
Figure 6 illustrates an example of lAB-node architecture 600 which enables migration of the DU of the lAB-node (DU migration) from a source IAB topology to a target IAB topology.
The lAB-node 601, which may be a mobile lAB-node like the lAB-node 570, is composed of an IAB-MT part or unit IAB-MT 610 (like the MT part or MT 571 of the IAB- node 570 of figure 5), 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 separated physical layers. At the DU migration of the lAB-node 601, both logical DUs are active: one of the logical DU terminates the Fl interface with a source Fl donor-CU (like donor-CU 501 in figure 5), while the other logical DU terminates the Fl interface with a target Fl donor-CU (like donor-CU 502 or 503 in figure 5). Otherwise (i.e. when DU migration is not to be performed), only one logical DU is sufficient for IAB operations. As an example and with reference to the IAB communication system of figure 5, the Fl terminating donor-CU of the lAB-node 601 (i.e. lAB-node 570) may be donor-CU 501 which is thus operating as the source Fl donor-CU. The source Fl -donor-CU 501 may identify lAB-donor- CU 502 as a suitable target Fl donor-CU when the source Fl -donor-CU 501 determines that the lAB-node 570 is moving towards/through the IAB topology 5002 which includes network nodes (e.g. lAB-donor-DUs 505, 506, lAB-nodes 530, 540, 550) managed by the lAB-donor- CU 502, which network nodes serve cells in IAB topology 5002 to which the lAB-node 570 will soon connect. Alternatively, for an lAB-node which is connected to parent lAB-node or parent lAB-donor-DU of the IAB topology 5001 managed by the donor-CU 501 as the Fl terminating donor-CU and which is stationary but is in proximity to or in the vicinity of one or more lAB-nodes in a neighbouring IAB topology, such as IAB topology 5002, the source Fl -donor-CU 501 may determine that lAB-donor-CU 502 is a suitable target Fl donor-CU when source Fl -donor-CU 501 determines (e.g. based on signal measurements performed at the lAB-node on radio signals received at the lAB-node from all lAB-nodes in proximity to the lAB-node and which may include lAB-nodes in the neighbouring IAB topology 5002) that the lAB-node may soon connect to an lAB-node in the neighbouring IAB topology 5002.
Before the DU migration, a UE 602 (like UE 580 of figure 5) is for instance connected to the source Fl donor-CU 501 through the logical DU IAB-DU1 611 with the access link 621 in the cell served by the logical DU IAB-DU1 611, and the logical DU IAB-DU2 612 is deactivated. At the DU migration, the logical DU IAB-DU2 612 is activated and connects to the target Fl donor-CU 502, to which the UE 602 may also connect through the logical DU IAB-DU2 612 with the link 622 in the cell served by the logical DU IAB-DU2 612. The activation of the logical DU IAB-DU2 612 may be triggered by the source Fl donor-CU and executed with the procedures described with reference to the figures 12a and 12b. Once the handover of UE 602 is completed from a cell controlled by the logical DU IAB-DU1 611 to a cell controlled by the logical DU IAB-DU2 612, the logical DU IAB-DU1 611 may be deactivated. The deactivation may be triggered by the source Fl donor-CU 501 with the procedure described with reference to figure 12c, after the detection of the completion of the handover for all UEs served by the IAB-DU1 611.
Examples of methods, in accordance with one or more embodiments of the present invention, which enable DU migration of an lAB-node to be performed, with or without (multiple) MT migration(s), and which include notifying the lAB-node about the identity of target donor-CU to enable the handover of UEs served by the lAB-node to the target donor- CU will now be described. Although the following methods/apparatus’ will be described primarily with respect to a mobile lAB-node, it will be appreciated that it is not intended that the invention is limited to mobile lAB-nodes. The methods in accordance with one or more embodiments of the present invention may apply to stationary lAB-nodes e.g. that are at the edge of one IAB topology and in the proximity of or in the vicinity of one or more lAB-nodes in a neighbouring IAB topology.
Figure 7 is a schematic and simplified diagram 700 illustrating some example message flows according to one or more embodiments of the invention, to perform the DU migration of an lAB-node, with or without (multiple) MT migration(s), and which includes the setup of data path(s) for packets routing between the target Fl donor-CU and the lAB-node through an IAB topology controlled by the non-Fl donor-CU (or RRC donor-CU) of the lAB-node.
This figure 7 shows a UE 708 like the UE 580, a source Fl donor-CU 703 like the donor-CU 501, a target Fl donor-CU 707 like the donor-CU 503, a non-Fl /RRC donor-CU 709, the core network (5GC) 702 like the core network 110 of figure 1. This figure 7 also shows an lAB-node 701 that may be a mobile lAB-node like the lAB-node 570 composed of a MT part or unit IAB-MT 704, a DU part or unit IAB-DU1 705 (e.g. source or first logical DU entity or DU), and a DU part or unit IAB-DU2 706 (e.g. target or second logical DU entity or DU). Each of the first 705 and second 706 logical DU entities serve one or more cells which are identified by identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)). The cell(s) of the IAB-DU1 705 are identified by different values for the identifiers (e.g. Physical Cell Identifier (PCI), New Radio Cell Group Identifier (NCGI)) compared to the values for the cell(s) of the 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 separated physical layers. The non-Fl donor-CU 709 for the lAB-node 701 may be the source Fl donor-CU 703 itself (e.g. donor- CU 501) if the IAB-MT 704 was not migrated. The non-Fl donor-CU for the lAB-node 701 may be the target Fl donor-CU 707 (e.g. donor-CU 703) if the IAB-MT 704 was previously migrated toward the target Fl donor-CU 707, or another donor-CU (e.g. donor-CU 502) if the IAB-MT 704 was previously migrated toward this other donor-CU (e.g. donor-CU 502).
At the beginning of the flow, the lAB-node 701 belongs to the source IAB topology controlled by the source Fl donor-CU 703. The UE 708 is served by the lAB-node 701 through a cell of IAB -DU 1 705 (e.g. the DU of the lAB-node 701 has an active IAB -DU 1 705 having a Fl connection with the source Fl lAB-donor-CU 703), while the logical IAB- DU2 706 is inactive. The user data in the downstream direction are provided by the 5GC 702 to the source Fl donor-CU 703 through the bearer 710, then the data are transmitted to the logical DU IAB-DU1 705 of the lAB-node 701 through the backhaul bearer 711, and finally to the UE 708 through the data radio bearer 712. The backhaul bearer 711 may be established in the source IAB topology controlled by the source Fl donor-CU 703, or in the IAB topology controlled by the non-Fl donor-CU 709 of the lAB-node 701 (if the IAB-MT 704 was previously migrated toward this non-Fl donor-CU). User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction.
The IAB-MT 704 may send measurement reports (not represented in the figure 7) to its non-Fl terminating donor-CU 709 as the result of the measurements regularly performed by IAB-MT 704 on signals received from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The non-Fl terminating donor-CU will be the Fl terminating donor-CU for the lAB-node (e.g. source Fl donor-CU 703) if the MT has not been migrated from its Fl terminating donor-CU. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the IAB-MT 704 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds 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 lAB-node 701. The identity of each cell is included in the measurement report to allow the non-Fl donor-CU if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, to identify the target donor-CU associated with the cell. Indeed, the identification of a donor-CU can be deduced from the Physical Cell identity (PCI) broadcasted in each cell managed by this donor-CU in a synchronization signal, and/or from the New Radio Cell Group Identifier (NCGI) also broadcasted in each cell managed by this donor-CU in a System Information Block (SIB) message. The PCI and/or the NCGI may be reported by the lAB-node 701 in the measurement report.
Based on the received measurement reports, the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, may detect that the lAB-node 701 receives radio signals in a target cell of a target parent lAB-node with a better quality than in the source serving cell. The non-Fl donor-CU 709 if the IAB-MT 704 has been migrated, or Fl terminating donor-CU 703 if the IAB-MT 704 has not been migrated, may decide to apply a procedure to perform the IAB-MT 704 migration toward a target parent lAB-node that belongs either to the same IAB topology (intra-CU topology adaptation), or to another IAB topology (inter-CU topology adaptation). In any case, the source Fl donor-CU 703 will be informed about this MT migration by the non-Fl donor-CU 709 if the IAB-MT 704 has been migrated or the source Fl donor-CU 703 will be informed since it made the decision to perform MT migration directly from the measurement reports received from the lAB-node 701 if the IAB-MT 704 has not been migrated, and this information may be used by the source Fl donor-CU 703 to trigger a DU migration of the lAB-node 701. In another example, the non-Fl donor-CU 709 may relay the information in the measurement reports received from the lAB-node 701 to the source Fl donor-CU 703. Thus, the source Fl donor-CU 703 may base its decision for DU migration of the lAB-node 701 directly from these measurement reports relayed by the non-Fl donor-CU 709.
Thus, the source Fl donor-CU 703 determines the DU of the lAB-node is to be migrated from the IAB topology (also referred to as the source IAB topology) of the source Fl donor-CU 703 to another IAB topology (also referred to as the target IAB topology) of a target lAB-donor-CU. The determination may be based on determining that a migration of a MT of the lAB-node toward a new parent lAB-node has been completed. Another example of a triggering event for determining the DU of the lAB-node is to be migrated may include the decision for DU migration may be based on the detection of a MT migration from a one IAB topology (e.g. first IAB topology) towards another IAB topology (e.g. second IAB topology), and on a known (predefined) trajectory of the lAB-node that indicates to the source Fl donor- CU that the MT will be migrated later to a yet another IAB topology (e.g. third IAB topology). In this case, to avoid signaling messages for DU migration/UEs handover toward the another IAB topology (e.g. second IAB topology), the DU is directly migrated toward the yet another IAB topology (e.g. third IAB topology). Another example of a triggering event for determining the DU of the lAB-node is to be migrated may include the processing load level being detected above a predefined threshold in the source Fl donor-CU. Then DU migration is triggered and the choice of target Fl donor-CU is based on the processing load of other donor-CUs connected to the source Fl donor-CU.
Upon the decision of or determination by the source Fl donor-CU 703 to perform the DU migration of the lAB-node 701 toward another IAB topology managed by another donor- CU which becomes the target Fl donor-CU 707, the first step 720 corresponds to sending a request to the lAB-node 701 to establish a new Fl connection between the target Fl donor- CU 707 and the mobile lAB-node 701. This may require activation of the second logical IAB-DU2 706 in the mobile lAB-node 701 and thus the first step 720 may include the activation of the second logical DU IAB-DU2 706 in the mobile lAB-node 701. This operation is performed using, for example, the procedures described with reference to the figures 12a and 12b. In particular, the message sent by the source Fl donor-CU 703 to the lAB-node 701 for the activation of the IAB-DU2 706 (e.g. 1203 in figure 12a) may include identification information for identifying the target donor-CU, such as the TNL address (i.e. IP address) of the target Fl donor-CU 707, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may 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 Fl donor-CU is not included in the request for activation, then by default and in the case where the IAB-MT 704 has been migrated to a non-Fl donor-CU 709, the non-Fl donor-CU 709 is considered as the target Fl donor-CU. In this case, the lAB-node 701 has already been informed of the identity (e.g. the TNL address/IP address) of the target Fl donor-CU when the IAB-MT 704 was migrated to the non-Fl donor-CU 709. In other words, the source Fl donor-CU 703 may send identification information for identifying the target Fl donor-CU 707 if the IAB-MT 704 has been migrated to a non-Fl donor-CU 709 different from (i.e. not the same as) the target Fl donor-CU 707. Alternatively, the source Fl donor-CU 703 may send identification information for identifying the non-Fl donor-CU 709 as the target lAB-donor-CU.
After determining the DU of the lAB-node 701 is to be migrated and once the IAB- DU2 706 has been activated, then, the IAB-DU2 706 may send a Fl setup request message (e.g. 1213 in figure 12b) to the target Fl donor-CU 707 for requesting set up of the Fl connection between the lAB-node 701 and the target Fl donor-CU 707. This message may include identification information for identifying the source lAB-donor-CU, such as the TNL address (i.e. the IP address) and/or the 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 Fl donor-CU 703 of the lAB-node 701. The destination address of the Fl setup request message is the target Fl donor-CU 707, and when this IP packet is received by the donor-DU in the Fl path for the lAB-node 701, it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 707. For instance, in an example where the lAB-node 701 is the lAB-node 570 of figure 5 which is connected to lAB-node 550 via backhaul link 5050 and where the MT (MT 571 which corresponds to IAB-MT 704 in figure 7) of the lAB-node 570 has been migrated to the nonFl donor-CU 502 and the lAB-donor-CU 501 is the source Fl donor-CU, the Fl path between the Fl donor-CU 501 to the lAB-node 570 uses the donor-DU 506. In the case where the lAB-donor-CU 503 has been identified (by Fl donor-CU 501) as the target Fl donor-CU (e.g. target Fl donor-CU 707), the Fl setup request message for the target Fl donor-CU (for instance donor-CU 503) is sent through the lAB-nodes 550, 540 and then to the donor-DU 506 from where it can be routed in the wired backhaul (508 in the figure 5) up to the target Fl donor-CU 503. In the Fl setup response (e.g. 1214 in figure 12b), the target Fl donor-CU 707 (e.g. donor-CU 503 in the example described above with reference to figure 5) may request the IAB-DU2 706 to activate new cell(s) with associated identifiers (PCI, NCGI). Usually the DU activates/deactivates 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.
After the procedure described with reference to figure 12b, and using, for example, the procedure described with reference figure 13a, the target Fl donor-CU 707 (e.g. in the configuration update message 1303) may inform the source Fl donor-CU 705 about the activation of new cell(s) from the IAB-DU2 706 of the lAB-node 701.
The next step 730 consists in the handover of UEs (e.g. UE 708 in figure 7) served by the lAB-node 701, from the cell(s) of the first logical DU IAB-DU1 705 to the cell(s) of the second logical DU IAB-DU2 706. This procedure may be the standardized procedure described in TS 38.300 section 9.2.3.2 (handover), or the standardized procedure described in TS 38.300 section 9.2.3.4 (conditional handover). In an example, to trigger the handover of the UE 708, the source Fl donor-CU 703 sends a HANDOVER REQUEST message to the target Fl donor-CU 707 including the necessary information related to the UE 708 to hand over (e.g. identification information identifying the UE, UE context information, such as the security context (e.g. security parameters such as security key, UE security capabilities), measurement configuration, radio configuration (e.g. UE radio capability), information about bearers, etc.). TS 38.423, section 9.1.1.1 provides details as to the content of a HANDOVER REQUEST message. After an admission control step in which the target Fl donor-CU 707 determines whether the donor-CU can accept the handover of the UE 708, when the target Fl donor-CU 707 accepts the request, the target Fl donor-CU 707 sends a handover acknowledgement message to the source Fl donor-CU 705, including configuration information for the UE 708 for the handover. The configuration may include radio configuration information indicating the radio configuration to be used by the UE 708 to connect to the second logical DU IAB-DU2 706 of the lAB-node 701 in an identified target cell of the second logical DU IAB-DU2 706 (e.g. the radio configuration may include frequency, radio bearer configuration, etc.). The handover acknowledgement may include an identifier for each of the one or more new cells (e.g. the target cell(s)) that have been activated at the second logical DU IAB-DU2 706. Then, the source Fl donor-CU 705 sends this configuration information to the UE 708 via the lAB-node 701 in a RRC Reconfiguration message, including the identifier of the target cell of IAB-DU2 706 to which the UE 708 is to connect. The RRC Reconfiguration message (specified in TS 38.331) is embedded in a Fl message DL RRC MESSAGE TRANSFER (specified in TS 38.473), sent to the IAB- DU1 705 and relayed by the IAB-DU1 705 to the UE 708. Upon reception of this configuration information, the UE 708 performs a random-access procedure in the indicated target cell of IAB-DU2 706 to obtain uplink resources, and then to transmit a RRC Reconfiguration Complete message to the target Fl donor-CU 707. The RRC Reconfiguration Complete message (specified in TS 38.331) is sent to the IAB-DU2 706, and then embedded in a Fl message UL RRC MESSAGE TRANSFER (specified in TS 38.473), sent to the target Fl donor-CU 707. The source Fl donor-CU 705 may be informed about the completion of the UE 708 handover through the HANDOVER SUCCESS message (specified in TS 38.423) received from the target Fl donor-CU 707.
Once the handover of all UEs served by the IAB-DU1 705 of the lAB-node 701 is completed, the source Fl donor-CU 703 may deactivate the logical DU IAB-DU1 705 of the mobile lAB-node 701 through the procedure described with reference to figure 12c. This is represented generally by the procedure 735 in figure 7.
Also, the source Fl donor-CU 705 may release the traffic (user traffic, control traffic) related to the UEs that were served by the lAB-node 701 through the I AB -DU 1 705 and the source Fl donor-CU 705. If the traffic was offloaded in an IAB topology controlled by the non-Fl donor-CU 709 (e.g. when the MT of the lAB-node 701 is migrated to the non-Fl donor-CU 709), the source Fl donor-CU 705 may apply the procedure described with reference to figure 13b to request the traffic release to the non-Fl donor-CU 709. This is represented generally by the procedure 735 in figure 7.
Finally, the target Fl donor-CU 707 has to setup the data path(s) to/from the migrated lAB-node 701, either in its own topology if there is a backhaul path to reach the lAB-node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e. the target Fl donor- CU 707 is a non-Fl terminating donor-CU for the lAB-node 701 as the IAB-MT 704 has previously been migrated to the target Fl donor-CU 707), or through the IAB topology of the non-Fl donor-CU 709 of the lAB-node 701 if there is no backhaul path to reach the IAB- node 701 in the IAB topology controlled by the target Fl donor-CU 707 (i.e. IAB-MT 704 and IAB-DU2 706 are connected to different donor-CUs). In this latter case, the target Fl donor-CU 707 may trigger the transport migration and path switch procedure 731 including the request of traffic migration to the non-Fl donor-CU 709 of the lAB-node 701, described with reference to figure 13b, and the path switch procedure toward the core network 702. As an example of this latter case with reference to figure 5, the lAB-node 701 is the lAB-node
570 of figure 5 connected to lAB-node 550 via backhaul link 5050 and where the MT (MT
571 which corresponds to IAB-MT 704 in figure 7) of the lAB-node 570 has been migrated to the non-Fl donor-CU 502 and the lAB-donor-CU 501 is the Fl donor-CU. When the DU (DU 572 which corresponds to IAB-DU2 706 in figure 7) of the lAB-node 570 has been migrated to the target donor-CU 503, and so has a Fl connection to the Fl donor-CU 503, but the MT 571 remains connected through its RRC connection to the non-Fl donor-CU 502, (its RRC connection), the data path(s) or backhaul path(s) to/from the lAB-node 570 is set up in the IAB topology 5002 controlled by the lAB-donor-CU 502 (i.e. a backhaul path to the IAB- node 570 through the lAB-donor-DU 506, lAB-nodes 540 and 550) by performing the traffic migration procedure (e.g. as described with reference to figure 13b). Also, the target donor- CU 503 may perform a path switch procedure toward the core network 702 to request the delivery of the user data related to the UE 708/580. For example, target donor-CU 503 may perform the path switch handshake procedure described in 3GPP TS 38.413 vl7.2.0 section 8.4.4.
After the handover of UE 708 and the setup of the new data paths has been performed (731), the user data in the downstream direction are transmitted by the core network 702 to the target Fl donor-CU 707 through the bearer 740, then they are transmitted to the logical DU IAB-DU2 706 of the lAB-node 701 through the backhaul bearer 741, and finally to the UE 708 through the data radio bearer 742. The backhaul bearer 741 may be established in the IAB topology controlled by the target Fl donor-CU 707, or in the IAB topology controlled by the non-Fl donor-CU 709 of the lAB-node 707 (e.g. depending on whether the IAB-MT 704 and IAB-DU2 706 of lAB-node 701 are connected to different donor-CUs). User data in the upstream direction (not represented in the figure) are transmitted through similar bearers in the opposite direction.
To request traffic migration to a donor-CU (such as the non-Fl donor-CU 709 if the MT has migrated or the Fl donor-CU 703 if the MT has not migrated) of the lAB-node 701 when the target Fl donor-CU 707 is different (i.e. is not the same donor-CU) from the Fl donor-CU of the lAB-node (e.g. non-Fl donor-CU 709), the target Fl donor-CU 707 needs to be able to identify the non-Fl donor-CU 709.
Figure 14 is a flowchart showing an example method 1400 in accordance with one or more embodiments of the invention, performed at a target lAB-donor-CU for use in managing transport migration for traffic related to an lAB-node. The transport migration is to be performed after a DU of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor-CU to a target IAB topology managed by the target IAB- donor-CU. Method 1400 may be performed as part of a DU migration process for migrating the DU of the lAB-node. For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the source lAB-donor-CU performing the method 1400 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU of the IAB- node 570 with which the lAB-node 570 retains a Fl connection). The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (e.g. source IAB topology) controlled by the lAB-donor-CU 501 (e.g. the source Fl lAB-donor-CU). The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (e.g. target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU. The method 1400 as shown in and described with respect to figure 14 may be performed by software elements and/or hardware elements. The source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 14 being performed by an apparatus for the target lAB-donor-CU including one or more processing units, such as the central processing unit 411. Briefly, at step 1402, the target lAB-donor-CU 503 receives a notification including identification information for identifying an lAB-donor-CU serving a MT of the lAB-node 570 (e.g. the MT, such as MT 571, that is co-located with the DU of the lAB-node, such as DU 572). The lAB-donor-CU serving the MT of the lAB-node is a different lAB-donor-CU to the target lAB-donor-CU. The lAB-donor-CU serving the MT of the lAB-node 570 may be the source lAB-donor-CU (e.g. the source Fl lAB-donor-CU such as lAB-donor-CU 501 is the non-Fl lAB-donor-CU) when the MT of the lAB-node 570 has not been migrated from the source lAB-donor-CU). Alternatively, the lAB-donor-CU serving the MT of the IAB- node 570 may be another or a second lAB-donor-CU (e.g. the non-Fl lAB-donor-CU or RRC I AB -donor CU such as lAB-donor-CU 502) when the MT of the lAB-node 570 has been migrated to the second lAB-donor-CU, such as lAB-donor-CU 502. Whether the non-Fl lAB-donor-CU for the migrated MT of the lAB-node 570 is the source Fl -donor-CU 501 or the non-Fl lAB-donor-CU 502, in either case, the target lAB-donor-CU is the different IAB- donor-CU 503.
As will be discussed in more detail below with reference to figures 8, 9a-9d, the target lAB-donor-CU 503 may receive the notification from the source lAB-donor-CU 501, such as in a DU migration notification which includes the identification information or in a configuration update notification which includes the identification information or from the lAB-node 570, such as in a Fl setup request which includes the identification information. The DU migration notification sent by the source lAB-donor-CU 501 may be the DU migration notification message 811 as discussed below with reference to figure 8 and figures 9a and 9d. The configuration update notification sent by the source lAB-donor-CU 501 may be the configuration update notification message 817 as discussed below with reference to figure 8 and figures 9a and 9d. The Fl setup request sent by the lAB-node 570 may be the Fl setup request message 814 as discussed below with reference to figure 8 and figures 9b, 9c and 9d. The Fl setup request is sent, by the lAB-node, after receiving, from the source IAB- donor-CU 501, a request for establishing a Fl connection (e.g. a new Fl connection) and for informing the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node. The request from the source lAB-donor-CU 501 may be sent in the DU activation request 813. The request from the source lAB-donor-CU 501 may indicate (explicitly or implicitly) to the lAB-node that the lAB-node is to inform the target IAB- donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node. For example, the request from the source lAB-donor-CU 501 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT. The information may include an Information Element, IE, for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node as discussed below with respect to figure 12a and the configuration request message 1203. The presence of the IE in the request for establishing a Fl connection may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU, or when the IE has a certain value (e.g. the IE may be one bit and the certain value may be ‘ 1’ or ‘0’), it may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB- donor-CU. In another example, the information may include identification information for identifying the lAB-donor-CU serving the MT of the lAB-node 570 and the presence of the identification information in the request may itself indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU.
As will be discussed in more detail below with reference to figures 10, 1 la-11c, when the lAB-donor-CU serving the MT of the lAB-node 570 is another lAB-donor-CU managing another IAB topology (e.g. the MT has migrated to another lAB-donor-CU, such as second lAB-donor-CU 502 managing a second IAB topology 5002), the target lAB-donor-CU 503 may receive the notification from the second lAB-donor-CU 502 (e.g. a non-Fl donor-CU or RRC donor-CU). In this case, the notification may be sent in a transport migration ready notification which includes the identification information, such as in a transport migration ready message 1013 as discussed below with reference to figure 10 and figures 1 la-11c.
The identification information for identifying an lAB-donor-CU serving the MT of the lAB-node 570 may be an identifier such as the TNL address (i.e. IP address) of the IAB- donor-CU serving the MT of the lAB-node and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3).
The notification may also include identification information for identifying the MT 571 of the lAB-node 570. For example, the identification information may be an identifier of the MT 571 of the lAB-node 570 known by the lAB-donor-CU serving the MT 571 of the IAB- node 570 (e.g. known by the Fl donor-CU 501 (when the MT has not been migrated) or by the non-Fl donor-CU 502 (when the MT has been migrated)). When the MT has been migrated, the identifier is known by the non-Fl donor-CU 502 by the information element non-F 1 -Terminating I AB -donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16, or VAIC-Ter mi noting IAB -donor UE XnAP ID information element, as a NG-RAN node UE XnAP ID that uniquely identifies a UE over the Xn interface within the NG-RAN node. Thus, each donor-CU assigns a value to each MT of an lAB-node in its IAB topology (as the IAB-MT is considered as a UE). Another identifier of the MT of an lAB-node known by the non-Fl donor-CU (or RRC donor-CU) is the BAP address that is assigned by this non-Fl donor-CU. Indeed, each lAB-donor-CU that terminates a RRC connection with an lAB-node has to assign a BAP address to this lAB-node (to use it as the destination BAP address for the BAP packets to be routed to this lAB-node in the IAB topology controlled by this IAB- donor-CU).
At step 1404, the target lAB-donor-CU 503 then, based on the identification information included in the notification (received from the source lAB-donor-CU 501 or the lAB-node 570 as discussed above) and after the DU 572 of the lAB-node 570 has been migrated to the target IAB topology 5003, performs transport migration for migrating traffic (e.g. Fl traffic which may include control and user traffic) related to or associated with the lAB-node 570 for routing over at least one path between the target lAB-donor-CU 503 and the lAB-node 570 through the IAB topology managed by the lAB-donor-CU serving the MT 571 of the lAB-node 570 (e.g. through IAB topology 5001 managed by source lAB-donor- CU 501 when the MT has not been migrated from the source Fl lAB-donor-CU 501 or through IAB topology 5002 managed by non-Fl lAB-donor-CU 502 when the MT has been migrated to the non-Fl lAB-donor-CU 502). For example, the target lAB-donor-CU 503 sends, to the lAB-donor-CU serving the MT 571 of the lAB-node 570, a traffic migration request (e.g. message 1014 in figure 10, message 1313 in figure 13b).
Figure 8 is a simplified diagram 800 illustrating example message flows, according to one or more embodiments of the invention, for providing identification information identifying a lAB-donor-CU that is serving a MT of a lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU) to a target lAB-donor-CU (e.g. the Fl terminating donor-CU) of a DU migration of the lAB-node, as part of a DU migration process of the lAB-node for use in managing or facilitating transport migration. The target lAB-donor-CU may be provided the identification information in a notification received from the source lAB-donor-CU, such as in a DU migration notification or a configuration update notification, or in a notification received from the lAB-node, such as in a Fl setup request. These examples are discussed below.
This figure 8 shows a source Fl donor-CU 803 like the donor-CU 501, a target Fl donor-CU 807 like the donor-CU 503, and an lAB-node 801 that may be a mobile lAB-node like the lAB-node 570 composed of a MT part or unit IAB-MT 804, a DU part or unit IAB- DU1 805 (e.g. source or first logical DU entity or DU), and a DU part or unit IAB-DU2 806 (e.g. target or second logical DU entity or DU). Each of the first 805 and second 806 logical DU entities 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 separated physical layers.
At the beginning of the flow, the lAB-node 801 belongs to the source IAB topology controlled by the source Fl donor-CU 803. Upon the decision of or determination by the source Fl donor-CU 803 to perform the DU migration of the lAB-node 801 toward the IAB topology managed by the target Fl donor-CU 807, the first step corresponds to sending a DU activation request message 813 to the lAB-node 801, to establish a new Fl connection between the target Fl donor-CU 807 and the mobile lAB-node 801, through the second logical DU IAB-DU2 804. The activation of the second logical IAB-DU2 806 in the mobile lAB-node 801 is performed with the operation 810. The message 813 sent by the source Fl donor-CU 803 to the lAB-node 801 for the activation of the IAB-DU2 806 is sent to the first logical DU IAB-DU1 805 as the source Fl donor-CU 803 has a Fl connection with this first logical DU of the lAB-node 801. The DU activation request message 813 may be a configuration request message 1203 as shown in figure 12a. This message 813 includes a request for establishing a Fl connection and for informing the target donor-CU 807 of the identity of the lAB-donor-CU serving the MT 804 of the lAB-node 801. The request may indicate (explicitly or implicitly) to the lAB-node 801 that the lAB-node is to inform the target donor-CU 807 of the identity of the lAB-donor-CU serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node).
After activation of the second logical DU IAB-DU2 806, the information contained in the message 813 may be transmitted from the first logical DU IAB-DU1 805 to the second logical DU IAB-DU2 806.
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 Fl donor-CU 807, so that a new Fl connection or Fl association (e.g. a F1AP interface connection) may be set up with the target donor-CU 807 (between the IAB-DU2 806 and the target donor-CU 807). This message 813 may also include a request to inform the identified target Fl donor- CU 807 of the identity of the lAB-donor-CU that is serving the MT 804 of the lAB-node 801, such as the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the lAB-donor-CU that is serving the MT 804 of the lAB-node 801. The message 813 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB- donor-CU serving the MT. The information may include an Information Element (IE) for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the IAB- donor-CU serving the MT of the lAB-node (see discussions below with respect to figure 12a and configuration request message 1203). For example, when the MT has not been migrated from the source Fl donor-CU 803, the lAB-donor-CU serving the MT 804 is the source Fl donor-CU 803 of the lAB-node 801 and when the MT has been migrated, the lAB-donor-CU serving the MT 804 is a non-Fl/RRC donor-CU of the lAB-node 801 (the non-Fl donor-CU is not shown in figure 8). The message 813 may also include identification information for identifying the lAB-donor-CU that is serving the MT 804 of the lAB-node 801, such as the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the lAB-donor-CU that is serving the MT 804 of the lAB-node 801. In an example, the information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT 804 may include the identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801 and the presence of the identification information may itself indicate to the lAB-node 801 that the lAB-node is to inform the target Fl donor- CU 807 of the identity of the lAB-donor-CU serving the MT 804. In addition, the message 813 may include the identifier of the IAB-MT 804 known by the lAB-donor-CU serving the MT 804 of the lAB-node 801. In the case the lAB-donor-CU serving the MT 804 is the nonFl donor-CU, the message 813 may include the identifier with the information element nonFl -Terminating I AB-donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16, or RRC- Terminating lAB-donor UE XnAP ID information element, as a NG-RAN node UE XnAP ID that uniquely identifies a UE over the Xn interface within the NG-RAN node. Thus, each donor-CU assigns a value to each MT of an lAB-node in its IAB topology (as the IAB-MT is considered as a UE). The Fl donor-CU 803 will have assigned an ID to the IAB-MT 804 when it was admitted in its IAB topology. At MT migration, the non-Fl donor-CU will assign another ID to IAB-MT 804. Both IDs are exchanged in handover request/acknowledge messages. Once activated, the IAB-DU2 806 may send a Fl setup request message 814 to the target Fl donor-CU 807 for requesting the setup of the Fl connection between the lAB-node 801 and the target Fl donor-CU 807. This message 814, also described with the reference 1213 at the figure 12b, may include identification information for identifying the source Fl donor-CU 803, such as the TNL address (i.e. the IP address) and/or the 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 Fl donor- CU 803 of the lAB-node 801. This message 814 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801 (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the IAB- node). If the non-Fl donor-CU is different from the target Fl donor-CU 807, this message 814 includes the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801. In addition, the message 814 may include the identifier of the IAB-MT 804 known by lAB-donor-CU serving the MT 804 of the lAB-node 801. In the case the IAB- donor-CU serving the MT 804 is the non-Fl donor-CU, the message 814 may include the identifier known by the non-Fl donor-CU with the information element non-F 1 -Terminating lAB-donor UE XnAP ID or RRC terminating I AB -donor UEXnAP ID. The message 814 may additionally or alternatively include the identifier of the IAB-MT 804 known by the non-Fl donor-CU with the information element BAP address (i.e. the BAP address assigned by the non-Fl donor-CU or RRC donor-CU when the mlAB-MT 804 has established a RRC connection and has received its BAP address in a RRC Reconfiguration message from the non-F 1/RRC donor-CU). The BAP address information element is, for instance, described in TS 38.423 V17.2.0 section 9.2.2.89. Finally, the message 814 may include the identifier gNB- DU ID of the second logical DU IAB-DU2 806 of the lAB-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 a gNB-CU. Thus, a logical DU of an lAB-node is assigned a unique ID by configuration. The unique ID may be provided to the Fl lAB-donor-CU terminating the Fl connection with the logical DU at Fl setup procedure (described in the figure 12b).
In the Fl setup response 815 (and also described with the reference 1214 in figure 12b), the target Fl donor-CU 807 may request the IAB-DU2 806 to activate new cell(s) with associated identifiers (PCI, NCGI). Usually the DU activate s/deactivates 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. After reception of the Fl setup response message 815, the IAB-DU2 806 may inform the IAB-DU1 805 about the result of the activation procedure (i.e. activation of IAB- DU2 806 and activation of new cell(s)). Then, the IAB-DU1 805 may relay this information to the source Fl donor-CU 803 through 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 lAB-node 801. The message 816 is further described with the reference 1204 in figure 12a.
As another example method to provide identification information identifying the IAB- donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source F 1 terminating donor-CU) to the target F 1 terminating donor-CU for the DU migration of an lAB-node, the source Fl donor-CU 803 may directly send a notification to the target donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node). The notification may be sent in a DU migration notification message 811 to the target Fl -donor-CU 807. The message 811 may be sent prior to launching the IAB-DU2 806 setup procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8). The message 811 may be followed by the DU migration response message 812 sent by the target Fl donor-CU 807 to the source Fl donor-CU 803 as an acknowledgment. The messages 811 and 812 may correspond to the procedure described with reference to figure 13a where message 811 corresponds to message 1303 and message 812 corresponds to message 1304. In another example, the messages 811 and 812 may correspond to the procedure described with reference to figure 13b where message 811 corresponds to message 1313 and message 812 corresponds to message 1314. This message 811 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801. If the MT 804 has been migrated to a non-Fl/RRC donor-CU and if this non-Fl donor-CU is different from the target Fl donor-CU 807, the DU migration notification message 811 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801. The message 811 may also include the identifier of lAB-node 801 as known by the source Fl donor-CU 803, either with the information element F 1 -Terminating 1 AB -donor UE XnAP ID identifying the MT 804 of the lAB-node 801, or with the information element gNB-DU ID identifying the first logical DU IAB-DU1 805 of the lAB-node 801. In addition, the message 811 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801. In the case the lAB-donor-CU serving the MT 804 is the nonFl donor-CU 803, the message 811 may include the identifier as known by the non-Fl donor- CU, with the information element non-F 1 -Terminating lAB-donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID identifying the MT 804 of the lAB-node 801. The message 811 may also or alternatively include the BAP address assigned by the non-F 1/RRC donor-CU. This involves that this BAP address was previously provided to the Fl donor-CU 803, for instance by the non-Fl donor-CU when the MT 804 was migrated (for instance using the procedure described at the figure 13a).
F 1 -Terminating lAB-donor UE XnAP ID and non-F 1 -Terminating lAB-donor UEXnAP ID (or RRC-Terminating lAB-donor UE XnAP ID) correspond to a NG-RAN node UE XnAP ID as specified in TS 38.423 section 9.2.3.16.
As another example method to provide identification information identifying the IAB- donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source F 1 terminating donor-CU) to the target F 1 terminating donor-CU for the DU migration of an lAB-node, the source Fl donor-CU 803 may directly send a notification to the target donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target Fl donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node). The notification may be sent in a configuration update message 817 to the target Fl -donor-CU 807. The message 817 may be sent at any time, before or after the launching of IAB-DU2 806 procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8). It may also be sent when the source Fl donor-CU 803 has detected a change of non-F 1/RRC donor-CU for the lAB-node 801. For instance, if a MT migration process of the lAB-node 801 is performed during the DU migration of the lAB-node 801, and if the source Fl donor-CU 803 has already provided the address and/or identifier of the old non-F 1/RRC donor-CU to the target Fl donor-CU 807, then the source Fl donor-CU can send an update through the message 817 including the address/identifier of the new non-F 1/RRC donor-CU.
Thus, the configuration update message 817 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801. For example, the message 817 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801 if this non-Fl donor-CU is different from the target Fl donor-CU 807. In addition, the message 817 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801. In the case the IAB- donor-CU serving the MT 804 is the non-Fl donor-CU 803, the message 817 may include the identifier as known by the non-Fl donor-CU, with the information element non-Fl- Terminating lAB-donor UE XnAP ID (or RRC-Terminating lAB-donor UE XnAP ED) identifying the MT 804 of the lAB-node 801. The message 817 may also or alternatively include the BAP address assigned by the non-Fl/RRC donor-CU. This involves that this BAP address was previously provided to the Fl donor-CU 803, for instance by the non-Fl donor- CU when the MT 804 was migrated (for instance using the procedure described at the figure 13a). The message 817 may also include the gNB-DU ID identifying the first logical DU IAB-DU1 805 of the lAB-node 801 and/or the gNB-DU ID identifying the second logical DU IAB-DU2 806 of the lAB-node 801.
The information identifying the lAB-donor-CU that is serving the MT of the lAB-node and the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 may also be present in the message 817 when the target Fl donor-CU 807 is the lAB-donor-CU serving the MT of the lAB-node 801. This would avoid any confusion at the target Fl donor- CU 807 to understand that the DU migration is related to the same lAB-node 801 as the MT 804.
The message 817 may be followed by the configuration acknowledgment message 818 sent by the target Fl donor-CU 807 to the source Fl donor-CU 803.
The messages 817 and 818 may correspond to the procedure described at the figure 13a with message 817 corresponding to configuration update message 1303 and message 818 corresponding to configuration acknowledge message 1304.
To communicate the identifier of the non-Fl donor-CU to the target Fl donor-CU 807, the source Fl donor-CU 803 will need to know this identifier. In case the MT 804 of the lAB-node 801 was previously migrated and the source Fl donor-CU 803 was the source non- Fl/RRC donor-CU for this MT migration, or in case the MT 804 of the lAB-node 801 is migrated during the DU migration and the source Fl donor-CU 803 is also the source non- Fl/RRC donor-CU for this MT migration, then the source Fl donor-CU 803 automatically knows the identifier of the target non-Fl/RRC donor-CU, which can be indicated to the target Fl donor-CU through the message 817. In case of consecutive MT migration, the source non- Fl donor-CU for the MT migration is not the source Fl donor-CU 803. To be informed of the identifier of the target non-Fl donor-CU (i.e. the new non-Fl donor-CU), the source Fl donor-CU 803 may receive a message (not represented in the figure) from the source non- Fl/RRC donor-CU, for instance when the MT migration is completed. To inform the target Fl donor-CU of the identifier of the non-Fl donor-CU, the source Fl donor-CU 803 may relay the message received from the source non-Fl donor-CU. The source non-Fl donor-CU for the MT migration of an lAB-node may inform the Fl donor-CU of the lAB-node about the identifier of the target non-Fl/RRC donor-CU through the procedure described with reference to the figure 13 a.
With a consecutive MT migration for a mobile lAB-node, the Fl donor-CU of an IAB- node may not be the source donor-CU of the previous MT migration. Besides, it can be noted that during the DU migration of an lAB-node, there may be two different donor-CUs serving the two logical DUs of the lAB-node. Then the question that can be raised is how does the source non-Fl donor-CU for a MT migration identify the Fl donor-CU for the lAB-node.
It can be proposed that a Fl donor-CU for an lAB-node is a donor-CU that has triggered a transport migration management (TMM) procedure for traffic related to the IAB- node. Indeed, a MT migration process includes a MT handover process similar to a UE handover, followed by a TMM procedure initiated by the Fl donor-CU to transmit/receive packets related to the lAB-node through the IAB topology controlling the non-Fl donor-CU. The TMM procedure corresponds to the procedure described in the figure 13b.
However, it has to be considered the particular case where there is no active transport migration established for a migrated lAB-node. Therefore, it is proposed that the source non- Fl donor-CU for a MT migration informs the target non-Fl donor-CU about the Fl donor- CU of the migrated lAB-node. This can be performed through the procedure described with the figure 13 a.
Besides, if a DU migration occurs while there is no active transport migration, the non- Fl donor-CU should be informed about the new Fl donor-CU. Then, it may be considered that at DU migration of an lAB-node, the source Fl donor-CU informs the non-Fl donor-CU serving the collocated MT about the target-Fl donor-CU. This can be performed through the procedure described with the figure 13a.
As another example method to provide identification information identifying the IAB- donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source F 1 terminating donor-CU) to the target F 1 terminating donor-CU for the DU migration of an lAB-node, the lAB-node 801 may directly send a notification to the target Fl donor-CU 807 including identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. when the target donor-CU 807 is a different IAB- donor-CU to the lAB-donor-CU serving the MT of the lAB-node). The notification may be sent in a configuration update message 819 from the IAB-DU2 806 to the target Fl -donor- CU 807. The information identifying the lAB-donor-CU that is serving the MT of the IAB- node may also be present in the configuration update message 819 when the target Fl donor- CU 807 is the lAB-donor-CU serving the MT of the lAB-node 801. This would avoid any confusion at the target Fl donor-CU 807 to understand that the DU migration is related to the same lAB-node 801 as the MT 804. The configuration update message 819 may be sent at any time after the completion of IAB-DU2 806 setup procedure (reference 720 in figure 7, and references 810, 813, 814, 815, 816 in figure 8). It may also be sent when the lAB-node 801 has detected a change of non-Fl/RRC donor-CU. For instance, if a MT migration process of the lAB-node 801 is performed during the DU migration of the lAB-node 801. This example method assumes that the IAB-MT 804 informs the IAB-DU2 806 of the current nonFl donor-CU through an internal communication in the lAB-node 801 between IAB-MT 804 and IAB-DU2 806.
Thus, the configuration update message 819 includes identification information for identifying the lAB-donor-CU serving the MT 804 of the lAB-node 801. For example, the configuration update message 819 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the non-Fl donor-CU of the lAB-node 801. In addition, the configuration update message 819 may include the identifier of lAB-node 801 as known by the lAB-donor-CU serving the MT 804 of the lAB-node 801 (e.g. the non-F 1 -Terminating lAB-donor UEXnAP ID or RRC-Terminating lAB-donor UE XnAP ID identifying the MT 804, and/or the BAP address identifying the MT 804). It may also include the gNB-DU ID identifying the first logical DU IAB-DU1 805 of the lAB-node 801 and/or the gNB-DU ID identifying the second logical DU IAB-DU2 806 of the lAB-node 801.
The identification information (i.e. the identifier of the lAB-donor-CU serving the MT 804 and the identifier of the MT 804 as known by this lAB-donor-CU) may be provided to the MT 804 by the lAB-donor-CU serving the MT 804. For instance, the lAB-donor-CU serving the MT 804 may use the message RRCReconfiguration, specified in TS 38.331 V17.2.0, and amended to include an information element for its TNL address (i.e. the IP address) and/or its identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3), and its identifier for the MT 804 (i.e. non-F 1 -Terminating lAB-donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16 or RRC-Terminating lAB-donor UE XnAP ID). For instance, the RRCReconfiguration message is sent when the lAB-node 801 is integrated to the network (i.e. at the first connection to an lAB-donor-CU), and following a migration of the MT 804 of the lAB-node 801. In this latter case, the RRCReconfiguration message is sent by the target non-Fl donor-CU during the IAB inter-CU topology adaptation procedure described in TS 38.401 V17.2.0 section 8.17.3. RRCReconfiguration message may also indicate the BAP address assigned to the lAB-node 801 by the non-Fl donor-CU.
The configuration update message 819 may be followed by a configuration acknowledgment message 820 sent by the target Fl donor-CU 807 to IAB-DU2 806.
The messages 819 and 820 may correspond to the procedure described with reference to the figure 12d with the configuration update message 819 corresponding to configuration update message 1233 and the configuration acknowledgment message 820 corresponding to configuration acknowledge message 1234.
Figure 9a is a flowchart of an example method 900 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor- CU) of an lAB-node, the DU migration of the lAB-node with the indication of a lAB-donor- CU that is serving the MT of the lAB-node (e.g. a non-Fl/RRC terminating donor-CU) to the target lAB-donor-CU (e.g. Fl terminating donor-CU). For example, method 900 in accordance with embodiments of the present invention is performed at the source lAB-donor- CU and is for use in managing, or as part of, a migration process/procedure for migrating a DU of an lAB-node to a target lAB-donor-CU and for providing identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor-CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the source lAB-donor-CU performing the method 900 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the lAB-node 570 with which the lAB-node 570 retains a Fl connection). The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target IAB- donor-CU. With reference to figures 7 and 8, the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 900 as shown in and described with respect to figure 9a may be performed by software elements and/or hardware elements. The source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9a being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 901, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), determines that the DU of the lAB-node, like the lAB-node 570 of figure 5 (701, 801) is to be migrated from the source Fl donor-CU 501, 703, 803 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 807). For example, the source Fl donor-CU 501, 703, 803 decides the DU migration of an lAB-node, like the lAB-node 570, toward a target Fl donor-CU, like the donor-CU 503, 707, 807. For example, the source Fl donor-CU 501, 703, 803 may determine that the DU 572 of the lAB-node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the lAB-node 570, 701, 801 toward a new parent lAB-node (which may be a new lAB-node or a new lAB-donor- DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above.
At step 902, the source Fl terminating donor-CU 501, 703, 803 may execute or perform the DU migration of the lAB-node through the procedure described with the reference 720 in figure 7. Besides, the step 902 may be executed after the step 903 or step 904.
At step 903, the source Fl terminating donor-CU 501, 703, 803 sends to the target Fl donor-CU 503, 707, 807 a notification including identification information for identifying the lAB-donor-CU serving the MT 571 of the lAB-node 570. For example, when the MT 571 has been migrated to a non-Fl/RRC terminating donor-CU, the notification includes identification information for identifying the non-Fl terminating donor-CU of the lAB-node 570, 701, 801. The non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 (the donor-CU 709 in figure 7). The indication of the non-Fl terminating donor-CU 502, 709 may be sent only if this non-Fl terminating donor-CU 502, 709 is different from the target Fl donor-CU 503, 707, 807 (in other words, when the non-Fl donor-CU 502, 709 is not the same lAB-donor-CU as the target Fl donor-CU 503, 707, 807). The message sent at step 903 may be the message 811 or the message 817 in figure 8.
At step 904, the source Fl terminating donor-CU 501, 703, 803 may receive an acknowledgment from the target Fl terminating donor-CU 503, 707, 807. The message received at step 904 may be the message 812 or the message 818 in figure 8.
Figure 9b is a flowchart of another example method 910 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor-CU) of an lAB-node, the DU migration of the lAB-node with the indication of a lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU) to the target lAB-donor-CU (e.g. Fl terminating donor-CU). For example, method 910 in accordance with embodiments of the present invention is performed at the source lAB-donor-CU and is for use in managing, or as part, of a migration process/procedure for migrating a DU of an lAB-node to a target lAB- donor-CU and for providing identification information identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor-CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
For example, with reference to the IAB communication system shown 500 in and described with respect to figure 5, the source lAB-donor-CU performing the method 910 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the lAB-node 570 with which the lAB-node 570 retains a Fl connection). The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target IAB- donor-CU. With reference to figures 7 and 8, the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 910 as shown in and described with respect to figure 9b may be performed by software elements and/or hardware elements. The source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9b being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 911, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), determines that the DU of the lAB-node, like the lAB-node 570 of figure 5 (701, 801) is to be migrated from the source Fl donor-CU 501, 703, 803 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 807). For example, the source Fl donor-CU 501, 703, 803 decides the DU migration of an lAB-node, like the lAB-node 570, 701, 801, toward a target Fl donor-CU, like the donor-CU 503, 703, 803. For example, the source Fl donor- CU 501, 703, 803 may determine that the DU of the lAB-node 570, 701, 801 is to be migrated in response to determining the migration of the MT 571, 704, 804 of the lAB-node 570, 701, 801 toward a new parent lAB-node (which may be a new lAB-node or a new IAB- donor-DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 803 determines the target Fl terminating donor-CU 503, 707, 807 is also described above.
At step 912, the source Fl terminating donor-CU 501, 703, 803 sends to the lAB-node 570, 701, 801 a request for establishing a Fl connection (i.e. a new Fl connection) between the target lAB-donor-CU 503, 707, 807 and the lAB-node 570, 701, 801 (e.g. a new Fl association with the target lAB-donor-CU) and for informing the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801. For example, the source Fl terminating donor-CU 501, 703, 803 sends to the lAB-node 570, 701, 801 to be migrated, a request for a new Fl connection. The request from the source Fl terminating donor-CU 501, 703, 803 may indicate (explicitly or implicitly) to the lAB-node 570, 701, 801 that the lAB-node is to inform the target lAB-donor-CU 503, 707, 807 of the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801. For example, the request from the source lAB-donor-CU 501 may include information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT. The information may include an Information Element, IE, for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node as discussed below with respect to figure 12a and the configuration request message 1203. The presence of the IE in the request for establishing a Fl connection may indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU or when the IE has a certain value (e.g. the IE may be one bit and the certain value may be ‘ 1’ or ‘0’) may indicate to the IAB- node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor- CU. The request may also include identification information for identifying an lAB-donor- CU serving the MT 571, 704, 804 of the lAB-node 570, 701, 801 (such as the non-Fl/RRC terminating donor-CU 502 when the MT has been migrated to the lAB-donor-CU 502 or the Fl terminating donor-CU 501 when the MT has not been migrated). In another example, the information may include identification information for identifying the lAB-donor-CU serving the MT of the lAB-node 570 and the presence of the identification information in the request may itself indicate to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU. The request may be the message 813 described with reference to figure 8. With this message, the source Fl donor-CU 501, 703, 803 may send, to the lAB-node 570, 701, 801 the request to indicate a non-Fl/RRC terminating donor-CU to the target Fl terminating donor-CU 503, 707, 807. The non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 (709 in figure 7).
At step 913, the source Fl terminating donor-CU 501, 703, 803 may receive an acknowledgment of activation from the lAB-node 570, 701, 801. The message received at step 913 may be the message 816 shown in and described with respect to figure 8.
Figure 9c is a flowchart of an example method 920 in accordance with one or more embodiments of the invention, performed at an lAB-node to perform Fl setup request to a target donor-CU while indicating the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or a RRC terminating donor-CU). For example, method 920 in accordance with embodiments of the present invention is performed at the lAB-node and is for use in, or as part of, a migration process/procedure for migrating a DU of an IAB- node to a target lAB-donor and for providing identification information identifying the IAB- donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) to the target lAB-donor-CU (e.g. the Fl terminating donor- CU) for use in managing or facilitating transport migration which is performed after DU migration of the lAB-node.
For example, with reference to the IAB communication system shown 500 in and described with respect to figure 5, the lAB-node performing the method 920 may be the mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501 (e.g. a Fl terminating donor-CU of the mobile lAB-node 570 with which the mobile lAB-node 570 retains a Fl connection) which is the source lAB-donor-CU. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU. With reference to figures 7 and 8, the lAB-node may be mobile lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 920 as shown in and described with respect to figure 9c may be performed by software elements and/or hardware elements. The lAB-node may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9c being performed by an apparatus for the lAB-node including one or more processing units, such as the central processing unit 411.
At step 921, an lAB-node, like the lAB-node 570 of figure 5 (701, 801), receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 803), a request for establishing a Fl connection or a new Fl connection (for example, a Fl connection between the lAB-node 570, 701, 801 and a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 807)) and for informing the target lAB-donor-CU of the identity of the IAB- donor-CU serving the MT 571, 704, 804 of the lAB-node. The request may be the message 813 described with reference to figure 8, and the request includes a request to indicate the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node (e.g. a non-Fl/RRC terminating donor-CU) to the target Fl donor-CU 503, 707, 807. The non-Fl/RRC terminating donor-CU may be the donor-CU 502 in figure 5 or the donor-CU 709 in figure 7. The request may include identification information for identifying the lAB-donor-CU serving the MT 571, 704, 804 of the lAB-node. Alternatively to receiving the identity from the request sent by the source Fl terminating donor-CU 501, 703, 803, the lAB-node may already know the identity of the lAB-donor-CU serving the MT 571, 704, 804 of the IAB- node. For example, the lAB-node may obtain this information at MT migration. In another example, the lAB-node may obtain the NR Cell Global Identifier (NCGI) from a System Information Block (SIB) broadcasted in a cell controlled by the parent lAB-node in the IAB topology controlled by the non-Fl terminating donor-CU. This identifier (NCGI) may be sufficient for the target Fl donor-CU to identify the non-Fl terminating donor-CU.
At step 922, in response to (or after) receiving a request for a new Fl connection, the lAB-node 570, 701, 801 then sends, to the target Fl donor-CU 503, 707, 807, a Fl setup request requesting the setup of the Fl connection. The Fl setup request message sent by the lAB-node includes identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU) (e.g. when the target donor-CU 807 is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node). The Fl setup request message may also include identification information for identifying the source Fl terminating donor-CU 501, 703, 803. The message sent at the step 922 may be the message 814 in figure 8.
Figure 9d is a flowchart of an example method 930 in accordance with embodiments of the present invention, for managing, at a target lAB-donor-CU, the transport migration after DU migration of an lAB-node. Method 930 is an example of method 1400 described above.
For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the target lAB-donor-CU performing the method 930 may be the lAB-donor-CU 503 which controls IAB topology 5003. The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003. With reference to figures 7 and 8, the lAB-node may be lAB-node 701, 801 and the migration process may involve the migration of the DU of the lAB-node 701, 801 from the source Fl donor-CU 703, 803 to the target Fl donor-CU 707, 807. The method 930 as shown in and described with respect to figure 9d may be performed by software elements and/or hardware elements. The target lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9d being performed by an apparatus for the target lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 931, the target Fl terminating donor-CU, like lAB-donor-CU 503 of figure 5 (707, 807), receives from an lAB-node, like lAB-node 570 of figure 5 (701, 801), a Fl setup request for requesting set up of a Fl connection between the target lAB-donor-CU and the lAB-node. The Fl setup request message sent by the lAB-node may include identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU when a MT of the lAB-node has been migrated to a non-Fl terminating donor-CU different from the target lAB-donor-CU or the source Fl terminating donor-CU when a MT of the lAB-node has not been migrated). The Fl setup request message may also include identification information for identifying the source Fl terminating donor- CU. The non-Fl terminating donor-CU may be the donor-CU 502 in figure 5 or the donor- CU 709 in figure 7. The message received at the step 931 may be the Fl setup request message 814 as shown in and described with respect to figure 8. The target Fl terminating donor-CU 503, 707, 807, in response to receiving the request at step 931, may send an acknowledgment to the lAB-node 570, 701, 801. The acknowledgment may be the message 815 as shown in and described with respect to figure 8.
In another example, at step 931, the target Fl terminating donor-CU, like lAB-donor- CU 503 of figure 5 (707, 807), receives a notification from the source lAB-donor-CU, such as lAB-donor-CU 501 of figure 5 (703, 803) with the notification including identification information for identifying the lAB-donor-CU that is serving the MT of the lAB-node (e.g. a non-Fl terminating donor-CU when a MT of the lAB-node has been migrated to a non-Fl terminating donor-CU different from the target lAB-donor-CU or the source Fl terminating donor-CU when a MT of the lAB-node has not been migrated). The notification may be a DU migration notification such as the DU migration notification message 811 as shown in and described with respect to figure 8. Alternatively (and not shown in figure 9d), the notification may be a configuration update notification, such as the configuration update message 817 as shown in and described with respect to figure 8.
At step 932, the target Fl terminating donor-CU 503, 707, 807, based on the identification information and after the DU of the lAB-node has been migrated to the target IAB topology, performs transport migration for migrating traffic related to or associated with the lAB-node for routing over at least one path between the target lAB-donor-CU and the lAB-node through an IAB topology managed by the lAB-donor-CU serving the MT. For example, the target Fl terminating donor-CU 503, 707, 807 sends, to the non-Fl donor-CU, a traffic migration request (e.g. message 1313 in figure 13b) for requesting traffic migration of the traffic associated with the lAB-node 570, 701, 801 that has to be routed via one or more paths in the IAB topology managed by the non-Fl terminating donor-CU 502, 709, indicated in the message received at step 931.
Figure 10 is a simplified diagram 1000 illustrating another example message flows, according to one or more embodiments of the invention, for providing identification information identifying the lAB-donor-CU that is serving a MT of a lAB-node (e.g. a non-Fl terminating donor-CU or the source Fl terminating donor-CU serving the MT) to a target lAB-donor-CU (e.g. the Fl terminating donor-CU) of a DU migration of the lAB-node, as part of a DU migration process of the lAB-node for use in managing or facilitating transport migration. The message flows shown in and described below with respect to figure 10 relate to the case where the MT of the lAB-node has been migrated to another lAB-donor-CU, e.g. a non-Fl lAB-donor-CU, which is different to the source lAB-donor-CU (source Fl donor- CU) and the target lAB-donor-CU (target Fl donor-CU).
This figure 10 shows a source Fl donor-CU 1003 like the donor-CU 501, 703, a target Fl donor-CU 1007 like the donor-CU 503, 707, and a non-Fl /RRC donor-CU 1009 like the donor-CU 502, 709.
The beginning of the flow corresponds to the end of UEs handover procedure 730 of the figure 7 after the DU migration of an lAB-node, like the lAB-node 570, 701, when the source Fl donor-CU 1003 of the lAB-node can release the traffic migration toward the non- Fl donor-CU 1009, and when the target Fl donor-CU 1007 can request traffic migration toward the non-Fl donor-CU 1007. It is assumed that the MT of the lAB-node was previously migrated toward the IAB topology managed by the non-Fl donor-CU 1009, and that the traffic related to the UEs served by the lAB-node was routed via the IAB topology managed by the non-Fl donor-CU 1009.
Following the handover of UEs served by the lAB-node toward the target Fl donor-CU 1007, the source Fl donor-CU 1003 sends a transport migration release message 1011 to the non-Fl donor-CU 1009 to request the release of traffic related to the handed over UEs, and thus to the lAB-node with migrated DU. For example, the transport migration release message 1011 may include a request for requesting release of transport migration set up by the source lAB-donor-CU for traffic related to the lAB-node. The non-Fl donor-CU 1009 responds with the transport migration response message 1012 to acknowledge the release operation.
According to an example, the message 1011 may include the indication that the traffic migration release is due to the DU migration of an lAB-node toward a target Fl donor-CU 1007. Thus, the message 1011 may include the identifiers of the migrated lAB-node known by the source Fl donor-CU 1003 and the non-Fl donor-CU 1009, with the information elements F 1 -Terminating lAB-donor UE XnAP ID and non-F I -Terminating IAB -donor UE XnAP ID (or RRC-Terminating lAB-donor UE XnAP ID). The message 1011 may also include the identifier of the target Fl donor-CU 1007 (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), and the identifier gNB-DU ID (as specified in TS 38.473 section 9.3.1.19) of the logical DU of the lAB-node served by the target Fl donor-CU 1007. Upon reception of the transport migration release message 1011, the non-Fl donor-CU 1009 may release the transport migration (e.g. set up by the source lAB-donor-CU) by deleting the configuration of lAB-nodes involved in the routing of packets to/from the migrated lAB-node within the IAB topology controlled by the non-Fl donor-CU 1009. For example, the non-Fl donor-CU 1009 may reconfigure the lAB-nodes involved in routing traffic to and/or from the lAB-node (e.g. the lAB-nodes in the routing path(s) to the IAB- node) by sending configuration update information for deleting, at each lAB-node, configuration information associated with routing traffic to and/or from the lAB-node. The non-Fl donor-CU 1009 may send updated configuration information (e.g. routing configuration tables) to the lAB-node(s) in the routing path(s) to the migrated lAB-node so that the configuration at these lAB-node(s) in the routing path(s) for routing of packets to/from the migrated lAB-node within the IAB topology is deleted. With reference to figure 5 where the MT 571 of lAB-node 570 is served by lAB-donor-CU 502, the DU 572 of IAB- node 570 has been migrated to lAB-donor-CU 503 and the lAB-node 570 is connected to lAB-node 550 via backhaul link 505, after DU migration, the lAB-donor-CU 502 as the non- Fl donor-CU may release the transport migration by reconfiguring the configuration information at lAB-donor-DU 506, and lAB-nodes 540 and 550 by deleting the configuration information associated with routing traffic to/from the lAB-node 570. As an alternative method, the non-Fl donor-CU 1009 may only suspend the traffic migration by maintaining the configuration of these lAB-nodes e.g. the lAB-nodes in the routing path are not reconfigured to delete the configuration information associated with routing traffic to/from the migrated lAB-node. Indeed, as the request for traffic migration release is due to a DU migration of the related lAB-node toward a target Fl donor-CU, a request for traffic migration from this target Fl donor-CU should be soon received by the non-Fl donor-CU 1009. And as the traffic to be migrated by the target Fl donor-CU should be equivalent to the traffic that was migrated by the source Fl donor-CU, the same configuration of lAB-nodes in the IAB topology controlled by the non-Fl donor-CU 1009 should still be applicable.
Then, the non-Fl donor-CU 1009 sends a transport migration response 1012 to the source Fl donor-CU 1003 to acknowledge the received message 1011.
The messages 1011 and 1012 may correspond to the procedure described at the figure 13b where message 1011 corresponds to message 1313 and message 1012 corresponds to message 1314. The non-Fl donor-CU 1009 further sends, to the target Fl donor-CU 1007, a notification for indicating the second lAB-donor-CU is ready to support transport migration, with the notification including identification information for identifying the non-Fl donor- CU 1009 in order to notify the target Fl donor-CU 1007 of the identity of the non-Fl donor- CU 1009 so that traffic, related to the lAB-node, can be migrated to a path (or at least one path) between the target Fl donor-CU 1007 and the migrated lAB-node 570 through the IAB topology managed by the non-Fl donor-CU 1009. The notification may be included in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 to indicate its role (i.e. the non-Fl donor-CU for the lAB-node), and to indicate the readiness to support the migration of traffic in its IAB topology. Thus, the message 1013 may include the identifier of the IAB-MT 804 known by the non-Fl donor-CU 1009 with the information element non-Fl- Terminating lAB-donor UE XnAP 7D, defined in TS 38.423 section 9.2.3.16, or RRC- Terminating IAB -donor UE XnAP ID, and the identifier gNB-DU ID of the logical DU having a Fl connection with the target Fl donor-CU 1007. The message 1013 may also or alternatively include the BAP address assigned by the non-Fl/RRC donor-CU. 1009. The transport migration ready message 1013 may include the characteristics (e.g. throughput, quality of service) of the traffic ready to be migrated, by taking the same characteristics that was previously migrated by the source Fl donor-CU 1003.
When the UEs served by the lAB-node are handed over toward the target Fl donor-CU 1007, this target Fl donor-CU 1007 sends a transport migration request message 1014 to request the migration of traffic related to the served UEs toward the IAB topology controlled by the non-Fl donor-CU 1009. Upon reception of the message 1014, the non-Fl donor-CU 1009 may accept the migration and may configure the lAB-nodes in its lAB-topology to route packets to/from the lAB-node serving the UEs, according to the traffic characteristics (e.g. throughput, quality of service) provided by the target Fl -donor-CU 1007. Then, the non- Fl donor-CU 1009 sends a transport migration response message 1015 to the target Fl donor- CU 1007 to acknowledge the transport migration. In case the non-Fl donor-CU 1009 had maintained the configuration of lAB-nodes upon reception of the message 1011, and in case the characteristics of the traffic to migrate are equivalent to the characteristics of the traffic that was previously migrated by the source Fl donor-CU 1003, the non-Fl donor-CU 1009 has just to resume the transport migration and to send the response 1015 to the target Fl donor-CU 1007. The messages 1014 and 1015 may correspond to the procedure described at the figure 13b with message 1014 corresponding to message 1313 and message 1015 corresponding to message 1314.
Figure 1 la is a flowchart of another example method 1100 in accordance with embodiments of the present invention, for managing, at the source lAB-donor-CU (e.g. Fl terminating donor-CU) of an lAB-node, the DU migration of the lAB-node with the indication of the lAB-donor-CU that is serving the MT of the lAB-node, the non-Fl terminating donor-CU or RRC terminating donor-CU, to the target lAB-donor-CU (e.g. the Fl terminating donor-CU).
For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the source lAB-donor-CU performing the method 1100 may be the lAB-donor-CU 501 (e.g a Fl terminating donor-CU or Fl donor-CU of the IAB- node 570 with which the lAB-node 570 retains a Fl connection). The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU. With reference to figures 7 and 10, the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the lAB-node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707 1007. The method 1100 as shown in and described with respect to figure I la may be performed by software elements and/or hardware elements. The source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure I la being performed by an apparatus for the source lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 1101, the source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 1003), determines that the DU of the lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7) is to be migrated from the source Fl donor-CU 501, 703, 1003 to a target Fl donor-CU, like the donor-CU 503 of figure 5 (707, 1007). For example, the source Fl donor- CU 501, 703, 1003 decides the DU migration of an lAB-node, like the lAB-node 570, toward a target Fl donor-CU, like the donor-CU 503, 707, 1007. For example, the source Fl donor- CU 501, 703, 1003 may determine that the DU of the lAB-node 570, 701 is to be migrated in response to determining the migration of the MT of the lAB-node 570, 701 toward a new parent lAB-node (which may be a new lAB-node or a new lAB-donor-DU) has been completed. Examples of other triggers for determining the DU is to be migrated are described above. Details of how the source Fl donor-CU 501, 703, 1003 determines the target Fl terminating donor-CU 503, 707, 1007 is also described above.
At step 1102, the source Fl terminating donor-CU 501, 703, 1003 executes or performs the DU migration of the lAB-node through the procedure described with the reference 720 in figure 7.
At step 1103, the source Fl terminating donor-CU 501, 703, 1003 sends to the non-Fl terminating donor-CU of the lAB-node a transport migration release for the traffic related to the lAB-node 570, 701, and indicating the target Fl donor-CU 503, 707, 1007 for the DU migration of this lAB-node (e.g. providing identification information for identifying the target Fl donor-CU). The indication of the target Fl donor-CU 503, 707, 1007 may be sent only if the non-Fl terminating donor-CU is different from the target Fl donor-CU 503, 707. The message sent at step 1103 may be the message 1011 in figure 10.
Figure 1 lb is a flowchart of an example method 1110 in accordance with embodiments of the present invention, for managing, at the non-Fl/RRC terminating donor-CU of an IAB- node, the transport migration in case of DU migration of the lAB-node. For example, method 1110 in accordance with one or more embodiments of the invention is performed at a IAB- donor-CU to which a MT of the lAB-node has been migrated (e.g. non-Fl terminating donor- CU or RRC terminating donor-CU, and also referred to as a second lAB-donor-CU) and is for use in managing transport migration for traffic related to or associated with an lAB-node. The transport migration is to be performed after a DU of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor-CU to a target IAB topology managed by the target lAB-donor-CU. The non-Fl terminating donor-CU is a different IAB- donor-CU to the target lAB-donor-CU and the source lAB-donor-CU.
For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the lAB-donor-CU performing the method 1110 may be the lAB-donor-CU 502 (e.g a non-Fl/RRC terminating donor-CU or non-Fl/RRC donor-CU of the lAB-node 570 with which the lAB-node 570 retains a RRC connection). The IAB- node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003 (also referred to as target IAB topology) managed by lAB-donor-CU 503 which is the target lAB-donor-CU. With reference to figures 7 and 10, the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the IAB- node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707, 1007. The method 1110 as shown in and described with respect to figure 1 lb may be performed by software elements and/or hardware elements. The source lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 1 lb being performed by by an apparatus for the non-Fl lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 1111, the non-Fl terminating donor-CU, like the donor-CU 502 of figure 5 (709, 1009), receives from a source Fl terminating donor-CU, like the donor-CU 501 of figure 5 (703, 1003) of an lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7), a transport migration release (e.g. the transport migration release message 1011) for requesting release of transport migration set up by the source Fl donor-CU, 501, 703, 1003 for the traffic related to or associated with the lAB-node. The transport migration release may include identification information for identifying or indicating the target Fl terminating donor-CU for the DU migration of the lAB-node. The target Fl terminating donor-CU may be the donor-CU 503 in figure 5 or the donor-CU 707 in figure 7 or the donor-CU 1007 in figure 10.
At step 1112, the non-Fl terminating donor-CU 502, 709, 1009 releases (or suspends) the transport migration previously setup upon the request of the source Fl terminating donor- CU 501, 703, 1003. As discussed above with reference to figure 10, when the non-Fl terminating donor-CU 502, 709, 1009 releases the transport migration, the terminating donor- CU 502, 709, 1009 reconfigures the lAB-nodes involved in routing traffic to and/or from the lAB-node by deleting, at each lAB-node, configuration information associated with routing traffic to and/or from the lAB-node. When the non-Fl terminating donor-CU 502, 709, 1009 suspends the transport migration, the configurations at the lAB-nodes involved in routing traffic to and/or from the lAB-node are kept.
At step 1113 (e.g. after receiving the transport migration release message 1011), the non-Fl terminating donor-CU 502, 709, 1009 sends to the target Fl donor-CU 503, 707, 1007, a notification for indicating the second lAB-donor-CU is ready for transport migration for the traffic related to the lAB-node 570, with the notification including identification information for identifying the non-Fl donor-CU 1009. The notification may be sent in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 as discussed above.
At step 1114, the non-Fl terminating donor-CU 501, 703, 1003 receives from the target Fl donor-CU 503, 707, 1007 a transport migration request for the traffic related to the IAB- node 570. The transport migration request may be sent in the transport migration request message 1014 discussed above.
At step 1115, the non-Fl terminating donor-CU 501, 703, 1003 activates (or resumes) the transport migration according to the request from the target Fl terminating donor-CU 503, 707, 1007 so that traffic related to the lAB-node is routed over at least one path between the target Fl terminating donor-CU 503, 707, 1007 and the lAB-node through the IAB topology managed by non-Fl terminating donor-CU 501, 703, 1003 serving the MT.
Figure 11c is a flowchart of another example method 1120 in accordance with embodiments of the present invention, for managing, at the target Fl terminating donor-CU of an lAB-node, the transport migration in case of DU migration of the lAB-node.
For example, with reference to the IAB communication system 500 shown in and described with respect to figure 5, the target lAB-donor-CU performing the method 1120 may be the lAB-donor-CU 503 which controls IAB topology 5003 (also referred to as target IAB topology). The lAB-node may be mobile lAB-node 570 belonging to IAB topology 5001 (also referred to as source IAB topology) controlled by the lAB-donor-CU 501. The migration process may involve the migration of the DU 572 of the lAB-node 570 from IAB topology 5001 to IAB topology 5003. With reference to figures 7 and 10, the lAB-node may be lAB-node 701 and the migration process may involve the migration of the DU of the IAB- node 701 from the source Fl donor-CU 703, 1003 to the target Fl donor-CU 707, 1007. The method 930 as shown in and described with respect to figure 11c may be performed by software elements and/or hardware elements. The target lAB-donor-CU may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 11c being performed by an apparatus for the target lAB-donor-CU including one or more processing units, such as the central processing unit 411.
At step 1121, the target Fl terminating donor-CU, like lAB-donor-CU 503 of figure 5 (707, 1007), receives from the non-Fl terminating donor-CU, like the donor-CU 502 of figure 5 (709, 1009), of an lAB-node, like the lAB-node 570 of figure 5 (701 of figure 7), a message indicating the non-Fl terminating donor-CU 502, 709, 1009 is ready for transport migration for the traffic related to the lAB-node 570. For example, the target Fl terminating donor-CU 503, 707, 1007 receives, from the non-Fl terminating donor-CU 502, 709, 1009, a notification for indicating the non-Fl terminating donor-CU 502, 709, 1009 is ready for transport migration for the traffic related to the lAB-node 570, with the notification including identification information for identifying the non-Fl donor-CU 1009. The notification may be sent in a transport migration ready message 1013 sent to the target Fl donor-CU 1007 as discussed above
At step 1122, after the DU migration of the lAB-node 570, the target Fl terminating donor-CU 503, 707, 1007, performs the transport migration for the traffic related to the IAB- node 570 toward the IAB topology controlled by the non-Fl terminating donor-CU 502, 709, 1009. For example, after DU migration of the lAB-node 570 and based on the identification information for the non-Fl terminating donor-CU 502, 709, 1009, the target Fl terminating donor-CU 503, 707, 1007 performs transport migration for migrating traffic related to or associated with the lAB-node for routing over at least one path between the target Fl terminating donor-CU 503, 707, 1007 and the lAB-node through the IAB topology managed by the non-Fl terminating donor-CU 502, 709, 1009.
Figure 12a is a schematic and simplified diagram 1200 illustrating an example message flow of a procedure to perform the activation of a logical DU according to an example.
This figure shows:
- a RAN node DU 1201, that may be DU of an lAB-node like IAB-DU 572 of IAB- node 570 of figure 5 (and IAB-DU1 805 of lAB-node 801 of figure 8),
- a RAN node CU 1202, that may be an lAB-donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8).
The message CONFIGURATION REQUEST 1203 is sent by the RAN node CU 1202 to the RAN node DU 1201 either 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 case of a logical DU activation, the message 1203 may include the TNL address (i.e. IP address) of a RAN node CU (e.g. the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated. For example, CONFIGURATION REQUEST 1203 may be sent by the source lAB-donor-CU to the lAB-node (e.g. the first logical DU entity 805 having a Fl connection with the source lAB-donor-CU) for requesting establishment of a Fl connection between a target lAB-donor- CU and the lAB-node. The message 1203 may also include an information element (IE) requesting the RAN node DU 1201 to transmit to the RAN node CU (e.g. the target Fl donor-CU 807 of figure 8) that will connect to the logical DU once activated, the TNL address (i.e. the IP address) and/or the 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 non-Fl lAB-donor-CU or RRC lAB-donor-CU) terminating the RRC connection of the RAN node embedding the RAN node DU 1201 (e.g. the address and/or identifier of the lAB-donor-CU serving the MT of the lAB-node). This IE may be limited to one bit: one value (i.e. “0” or “1”) of this one-bit IE means no specific action is requested and another value (i.e. “1” or “0”) means sending the address/identifier of the non-Fl donor-CU. This IE may be extended to include the address/identifier of the RAN node CU terminating the RRC connection. The message 1203 may include the identifier of the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201, as known by the RAN node CU terminating the RRC connection with the information element non-F 1 -Terminating I AB -donor UE XnAP ID, defined in TS 38.423 section 9.2.3.16 or RRC-Terminating 1 AB-donor UE XnAP ID.
The RAN Node DU 1201 may acknowledge the request with the message CONFIGURATION RESPONSE 1204 sent to the RAN Node CU 1202.
According to one example, the flow in figure 12a corresponds to the procedure gNB- CU Configuration Update procedure described in TS 38.473 V17.0.0 section 8.2.5, and the message 1203 corresponds to the message GNB-CU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.10, while the message 1204 corresponds to the message GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.11.
The message GNB-CU CONFIGURATION UPDATE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated at the RAN Node DU 1201. For example and with reference to figure 8, the GNB-CU CONFIGURATION UPDATE includes information to activate the new cell(s) indicated in the IE Cells to be Activated List, which new cell(s) may be served by the first logical DU entity 805 at the lAB-node 801. The cell(s) to be activated refer to cell(s) controlled by the RAN Node DU 1201 receiving the request. The associated PCI and NCGI value(s) to be used by the RAN Node DU 1201 may also be provided.
The message GNB-CU CONFIGURATION UPDATE may also include the Information Element (IE) Cells to be Deactivated List to indicate the list cell(s) to be deactivated. The cell(s) to be deactivated refer to cell(s) controlled by the RAN node DU 1201 receiving the request. For example and with reference to figure 8, the GNB-CU CONFIGURATION UPDATE may include information to deactivate the cell(s) indicated in the IE Cells to be Deactivated List which cell(s) are currently served by the first logical DU entity 805 at the lAB-node 801.
According to one example, a new IE Second DU Activation may be added in the message 1203 in the form of a Boolean (e.g. a one-bit IE) to request the activation of a second logical DU. One value (i.e. “0” or “1”) of the one-bit IE means no specific action related to the second logical DU is requested and another value (i.e. “1” or “0”) means activation of a second logical DU is requested. This IE may be completed by a new IE indicating a number of cells to be activated in the second logical DU. In the absence of this IE, the number of cells to be activated corresponds to the number of cells currently activated in the RAN Node DU 1201. The presence of this IE may indicate that the BAP address that identifies the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 shall be inserted in the request for Fl connection.
Besides, a new IE may be added (e.g. Target TNL address IE) to identify the target RAN Node CU with which a Fl connection shall be setup.
Another IE may be added to request to send the address and/or identifier of the RAN node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1201 (e.g. the address and/or identifier of the lAB-donor-CU serving the MT of the IAB- node). This IE may be the address (e.g. non-Fl TNL address IE or RRC TNL address IE) or the identifier of (e.g. non-Fl Global NG-RAN Node ID or RRC Global NG-RAN Node ID), and its presence indicates that it shall be included in the request for Fl connection.
Another IE may be added to identify the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 (e.g. non-F I -Terminating 1 AB -donor UE XnAP ID or RRC-Terminating lAB-donor UE XnAP ID), and its presence indicates that it shall be included in the request for Fl connection. The presence of this IE may indicate that the BAP address that identifies the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1201 shall be inserted in the request for Fl connection.
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. To complete the setup of the new logical DU at the lAB-node, the procedure described with reference to figure 12b may be used.
Figure 12b is a schematic and simplified diagram 1210 illustrating an example message flow of a procedure to setup a logical DU, so as to establish a Fl connection with the target lAB-donor-CU, according to an example.
This figure shows:
- a RAN node DU 1211, that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU2 806 of lAB-node 801 of figure 8),
- a RAN node CU 1212, that may be an lAB-donor-CU like lAB-donor-CU 503 of figure 5 (and target Fl donor-CU 807 of figure 8).
The message SETUP REQUEST 1213 is sent by the RAN node DU 1211 to the RAN node CU 1212 to request the Fl setup for the logical DU. For example, SETUP REQUEST 1213 may be sent by the lAB-node (e.g. by the second logical DU entity 806 which has been activated at the lAB-node 801) to the target lAB-donor-CU 807 for requesting set up of a Fl connection between a target lAB-donor-CU and the lAB-node (e.g. with the second logical DU entity 806 of the lAB-node 801)). The SETUP REQUEST message 1213 may be sent after an activation request as described with reference to figure 12a. This SETUP REQUEST message 1213 may include the number of cells to be activated along with activation of the logical DU. This SETUP REQUEST message 1213 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the Fl connection of the RAN node DU 1211 (e.g. the source lAB-donor-CU 803). This message may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the non-Fl (i.e. RRC) connection of the RAN node DU 1211 in the case where the MT (e.g. mMT 571 of lAB-node 570 or corresponding IAB-MT of 804 of lAB-node 801) has been migrated to the RAN node CU (which is now the non-Fl donor-CU).
The message 1213 may also include at least one of:
- the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the source RAN node CU that has requested the Fl setup,
TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node RD) of the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211 (e.g. the address and/or identifier of the IAB- donor-CU serving the MT of the lAB-node), the identifier for the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1211 (e.g. non-F 1 -Terminating 1 AB -donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID), known by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211, the BAP address of the MT of the RAN node embedding the RAN node DU 1211, assigned by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211, the identifier gNB-DU ID of the RAN node DU 1211.
The RAN node CU 1212 answers with the message SETUP RESPONSE 1214 sent to the RAN node DU 1211. It may include a list of cell(s) to activate with the logical DU, along with the associated PCI and NCGI value(s) to be used.
According to one example, the flow in figure 12b corresponds to the procedure Fl setup described in TS 38.473 V17.2.0 section 8.2.3, and the message 1213 corresponds to the message Fl SETUP REQUEST described in TS 38.473 V17.2.0 section 9.2.1.4, while the message 1214 corresponds to the message Fl SETUP RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.5. The message Fl SETUP RESPONSE includes the Information Element (IE) Cells to be Activated List to indicate the list of new cell(s) to be activated. The cell(s) to be activated refer to cell(s) controlled by the RAN node DU 1211 receiving the response.
Figure 12c is a schematic and simplified diagram 1220 illustrating an example message flow of a procedure to remove a logical DU.
This figure shows:
- a RAN node DU 1221, that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU1 805 of lAB-node 801 of figure 8),
- a RAN node CU 1222, that may be an lAB-donor-CU like lAB-donor-CU 501 of figure 5 (and source Fl donor-CU 803 of figure 8).
The message REMOVAL REQUEST 1223 is sent by the RAN node CU 1222 to the RAN node DU 1221 to request the removal (which is equivalent to deactivation) of the logical DU.
The RAN node DU 1221 answers with the message REMOVAL RESPONSE 1214 sent to the RAN node CU 1222. According to one example, the flow in Figure 12c corresponds to the procedure Fl removal described in TS 38.473 V17.2.0 section 8.2.8, and the message 1223 corresponds to the message Fl REMOVAL REQUEST described in TS 38.473 VI 7.2.0 section 9.2.1.16, while the message 1224 corresponds to the message Fl REMOVAL RESPONSE described in TS 38.473 V17.2.0 section 9.2.1.7.
Figure 12d is a schematic and simplified diagram 1230 illustrating an example message flow of a procedure used by a logical DU to inform an lAB-donor-CU about a change of configuration, according to an example.
This figure shows:
- a RAN node DU 1231, that may be a DU of an lAB-node DU like IAB-DU 572 of lAB-node 570 of figure 5 (and IAB-DU2 806 of lAB-node 801 of figure 8),
- a RAN node CU 1232, that may be an lAB-donor-CU like lAB-donor-CU 503 of figure 5 (and target Fl donor-CU 807 of figure 8).
The message CONFIGURATION UPDATE 1233 is sent by the RAN node DU 1231 to the RAN node CU 1232 to indicate a configuration change for the RAN node embedding the RAN node DU 1231. CONFIGURATION UPDATE message 1233 may be sent by the RAN node DU 1231 for indicating to the RAN node CU 1232 the identifier of the RAN node CU serving the MT of the RAN node embedding the RAN node DU 1231. For instance the message 1233 is sent by the second logical DU entity 806 that has been activated at the IAB- node 801 to the target lAB-donor-CU 807 to indicate the lAB-donor-CU serving the MT 804 of the lAB-node 801. This CONFIGURATION UPDATE message 1233 may include the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of the RAN node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1211 (e.g. the address and/or identifier of the lAB-donor-CU serving the MT of the lAB-node). It may also include at least one of the identifier for the Mobile Termination (MT) of the RAN node embedding the RAN node DU 1231 (e.g. non-F 1 -Terminating 1 AB -donor UE XnAP ID or RRC- Terminating lAB-donor UE XnAP ID), known by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231, the BAP address of the MT of the RAN node embedding the RAN node DU 1231, assigned by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231, the identifier gNB-DU ID of the RAN node DU 1231.
The RAN node CU 1232 answers or responds with the message CONFIGURTION ACKNOWLEDGE 1234 sent to the RAN node DU 1231.
The identifier for the Mobile Termination (MT) of the RAN node may be provided by the RAN Node CU terminating the RRC connection of the RAN node embedding the RAN node DU 1231.
According to one example, the flow in figure 12d corresponds to the procedure gNB- DU configuration update described in TS 38.473 V17.2.0 section 8.2.4, amended to include the information elements described above. The message 1233 corresponds to the message GNB-DU CONFIGURATION UPDATE described in TS 38.473 V17.2.0 section 9.2.1.7, while the message 1234 corresponds to the message GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.473 V17.2.0 section 9.2.1.8.
Figure 13a is a schematic and simplified diagram 1300 illustrating an example message flow of a procedure used by a RAN Node CU to report configuration information to another RAN Node CU according to an example.
This figure shows two RAN nodes, RAN node CUa 1301 and RAN node CUb 1302, that may be two lAB-donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5. With respect to the example shown in figure 8, RAN node CUa 1301 may be the target Fl donor-CU 807 and RAN node CUb 1302 may be the source Fl donor-CU 803 depending on the purpose of the messages.
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 about the activation of new cell(s) in a logical DU of a RAN node DU like the IAB-DU2 806 of the lAB-node 801.
For example, the source Fl donor-CU 803 receives the CONFIGURATION UPDATE message 1303 from the target Fl donor-CU 807 and the CONFIGURATION UPDATE message 1303 includes identification information (e.g. PCI, NRGI) identifying one or more new cells that have been activated at a second logical DU entity (IAB-DU2 806) of the DU of the lAB-node 801.
The message CONFIGURATION UPDATE 1303 can also be used by the RAN node CUa 1301 to the RAN node CUb 1302 to inform the RAN node CUb 1302 about the TNL address (i.e. the IP address) and/or the identifier (i.e. Global NG-RAN Node ID as specified in TS 38.423 V17.2.0 section 9.2.2.3) of a RAN node CU terminating the RRC connection of a RAN node embedding a RAN node DU (e.g. the address and/or identifier of the lAB-donor- CU serving the MT of the lAB-node) that is to be migrated toward the RAN node CUb 1302. In this case, RAN node CUa 1301 is the source Fl donor-CU 803 and RAN node CUb 1302 is the target Fl donor-CU 807.
The messages 1303 may also include at least one of:
- the identifier of the migrated RAN node as known by the RAN node CUa 1301, with the information element F 1-Terminating lAB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node, and/or with the information element gNB-DU ID identifying the logical DU of the migrated RAN node having Fl connection with the RAN node CUa 1301, the identifier of the MT of the migrated RAN node as known by the RAN node CU terminating the RRC connection with the migrated RAN node, through the information element non-F 1-Terminating lAB-donor UE XnAP ID, or RRC- Terminating lAB-donor UE XnAP ID
- the identifier of the migrated RAN node as known by the RAN node CUb 1302, with the information element target F 1-Terminating lAB-donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated RAN node, and/or the identifier gNB-DU ID of a logical DU of the migrated RAN node having a Fl connection with the RAN node CUb 1302,
- the BAP address of the MT of the migrated RAN node assigned by the RAN Node CU terminating the RRC connection of the migrated RAN node.
The RAN node CUb 1302 answers with the message CONFIGURATION ACKNOWLEDGE 1304 sent to the RAN node CUa 1301 to acknowledge the reception of the message 1303.
According to one example, the Figure 13a corresponds to the procedure NG-RAN node configuration update described in TS 38.423 V17.2.0 section 8.4.2, and the message 1303 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE described in TS 38.423 V17.2.0 section 9.1.3.4, amended with IES listed above, while the message 1304 corresponds to the message NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE described in TS 38.423 V17.2.0 section 9.1.3.5.
Figure 13b is a schematic and simplified diagram 1310 illustrating an example message flow of a procedure used by a RAN node CU to manage the transport migration (e.g. setup, modification, or release of Fl traffic such as user/control traffic) in coordination with another RAN Node CU according to an example. This figure shows two RAN nodes, RAN node CUa 1311 and RAN node CUb 1312, that may be two lAB-donor-CUs, like two of lAB-donor-CUs 501, 502, and 503 of figure 5.
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, or modification, or release in the IAB topology controlled by the RAN node CUb 1312. For example, with reference to figure 8, in the case where the DU has been migrated to the target Fl donor-CU 807 and the MT 804 of the lAB-node 801 had been migrated to a non-Fl/RRC donor-CU (not shown in figure 8), the source Fl donor-CU 803 may send a MIGRATION REQUEST 1313 to the non-Fl donor-CU to request release of the traffic (e.g. Fl traffic) migrated to the non-Fl donor-CU’ s topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 807 through the IAB topology managed by the non-Fl donor-CU). Alternatively, in the case where the DU has been migrated to the target Fl donor-CU 807 and the MT 804 of the lAB-node 801 had been migrated to a non-Fl donor-CU, the target Fl donor-CU 807 may send a MIGRATION REQUEST 1313 to the non-Fl donor-CU to request traffic (e.g. Fl traffic) migration to the non-Fl donor-CU’ s topology (i.e as the Fl traffic is now to be routed from the target Fl donor-CU 807 through the IAB topology managed by the non-Fl donor-CU).
In another example, the message MIGRATION REQUEST 1313 is sent by the RAN node CUa 1311 to the RAN node CUb 1312 to notify the DU migration of an lAB-node. When the RAN node CUb 1312 acknowledges with the message MIGRATION RESPONSE 1314, the RAN node CUb 1312 may include an identifier the RAN node CUb 1312 has assigned for the migrated lAB-node, for instance the information element target Fl- Terminating I AB -donor UE XnAP ID identifying the Mobile Termination (MT) of the migrated lAB-node.
The message 1313 may include at least one of
- the indication that the traffic migration release is due to the DU migration of the IAB- node 801 toward the target Fl donor-CU 807,
- the identifiers of the migrated lAB-node known by the source Fl donor-CU 803 and the non-Fl donor-CU, with the information elements F 1 -Terminating IAB -donor UE XnAP ID and non-F I -Terminating IAB -donor UE XnAP ID (or RRC-Terminating lAB-donor UE XnAP ID), and/or the BAP address assigned by the non-Fl donor-CU for the migrated IAB- node,
- the identifier of the target Fl 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), - the identifier gNB-DU ID (as specified in TS 38.473 section 9.3.1.19) of the logical DU of the lAB-node 801 served by the target Fl donor-CU 807.
The RAN node CUb 1312 answers with the message MIGRATION RESPONSE 1314 sent to the RAN node CUa 1311 to accept or reject the request.
Depending on the situation, the figure 13b may correspond to the IAB transport migration management procedure specified in TS 38.423 V17.2.0 section 8.5.2. The message 1313 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.2, and the message 1314 corresponds to the IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4 3. If the TRANSPORT MIGRATION MANAGEMENT procedure is the one specified in TS 38.423 V17.2.0 section 8.5.2 (which can be referred to as the legacy procedure), then the target Fl donor-CU 807 should know the UE XnAP ID assigned by the non-Fl donor-CU. If the Fl setup request message from the migrated IAB- node only provides the BAP address, then both BAP address and UE XnAP ID shall be provided to the target Fl donor-CU (through the procedure described at the figure 13a), so that the target Fl donor-CU can associate the UE XnAP ID with the BAP address. If the TRANSPORT MIGRATION MANAGEMENT procedure is amended to allow not providing a UE XnAP ID but the BAP address instead, then only the BAP address may be provided to the target Fl donor-CU (through the procedure described with reference to the figure 13a).
The figure 13b may also correspond to the IAB transport migration modification procedure specified in TS 38.423 V17.2.0 section 8.5.3. The message 1313 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION REQUEST message specified in TS 38.423 V17.2.0 section 9.1.4.4, and the message 1314 corresponds to the IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message specified in TS 38.423 V17.2.0 section 9.1.4.5.
In other words and as a summary, it can be noted that a mobile lAB-node can be partially migrated as other lAB-nodes according to Release 17. Also, this mobile IAB-MT (mlAB-MT) handover is driven by the radio conditions, and it should not be delayed to maintain backhaul connection and to avoid service interruption at the served UEs.
Thus, it can be observed that a mlAB-MT handover should not be delayed to maintain backhaul connection and to avoid service interruption at the served UEs.
Based on this first observation, it may happen that a mlAB-MT handover is triggered and executed while a migration of the co-located mobile IAB-DU (mlAB-DU) is on-going. Thus, even if the target donor-CU for the mlAB-DU migration is restricted to the mlAB- MT's donor-CU, in some situations the Fl terminating donor-CU after the mlAB-DU migration may finally be different from the non-Fl terminating donor-CU after handover of the co-located mlAB-MT.
Therefore, considering that a mlAB-MT handover should not be delayed may lead to situations where a mlAB-MT and its co-located mlAB-DU can be handed over/migrated to different donor-CUs.
Besides, the criteria for DU migration and MT handover differ: MT handover is driven by the radio conditions while DU migration decision may be based, for instance, on the available connectivity between donor-CUs and/or for load balancing purpose.
Then, it can be noted that the criteria to select a target donor-CU for a mobile lAB-node depend on the migration type, i.e., MT handover or DU migration.
Thus, according to the above observations, it should be supported, for flexible and smooth IAB network management purpose, that a mlAB-MT and its co-located mlAB-DU can be handed over/migrated to different donor-CUs.
Also, if the target Fl donor-CU is different from the non-Fl donor-CU, the target Fl donor-CU should be informed about the current non-Fl donor-CU serving the co-located mlAB-MT of the mobile lAB-node. This would allow the target Fl donor-CU to setup the IAB transport migration toward the non-Fl donor-CU’ s topology.
Then, it is proposed that the target Fl donor-CU for the migration of a mobile IAB-DU should be informed about the current non-Fl donor-CU serving the co-located mobile IAB- MT.
In case of concurrent MT handover and DU migration for a mobile lAB-node, it is the DU migration that may suffer from delay or failure due to the modification of the backhaul path to communicate with the mobile lAB-node.
To be more precise on a potential issue, it is considered the case where the mobile IAB- node has successfully performed the Fl setup procedure with a target Fl donor-CU for DU migration purpose, and that this target Fl donor-CU is different from the non-Fl donor-CU for the mobile lAB-node. If meanwhile, a MT migration of the mobile lAB-node has occurred toward a target non-Fl donor-CU (still different from the target Fl donor-CU), the target Fl donor-CU may not be aware of this new non-Fl donor-CU to perform the transport migration management (TMM) procedure. It can be noted that in case the target logical mlAB-DU’s CU is different from the mlAB-MT’s CU, the target logical mlAB-DU’s CU needs to be informed about the mlAB- MT’s CU ID and the mlAB-MT ID so that it can initiate the Xn TMM procedures towards mlAB-MT’s CU,
However, this statement may not be accurate enough to prevent any deadlock situation in case of concurrent MT and DU migrations. Indeed, it does not say when the target Fl donor-CU (i.e. the target logical mlAB-DU’s CU) is informed about the non-Fl donor-CU (i.e the mlAB-MT’s CU ID). If the target Fl donor-CU was informed before the MT migration, then the target Fl donor-CU will trigger the TMM procedures toward a donor-CU that may no longer be the non-Fl donor-CU.
Therefore, the above statement could be completed by the following: if the mlAB-MT’s CU is changed during a DU migration, the target logical mlAB-DU’s CU needs to be informed about the target mlAB-MT’s CU ID and the mlAB-MT ID, before it can initiate the TMM procedures towards the target mlAB-MT’s CU.
From the above example, it appears that some adaptations of MT and DU migration procedures may be required to avoid deadlock situations and to limit the impact of concurrent MT and DU migrations to some delay to complete the procedures.
To go forward, there are 3 options:
- option 1 : to consider independent procedures as a working assumption, to define the procedures accordingly, and then in a second step to refine (if necessary) the procedures to support concurrent DU and MT migrations,
- option 2: to consider concurrent DU and MT migrations as a working assumption, then to define the procedures accordingly,
- option 3 : to not support concurrent DU and MT migrations, to define the procedures independently, and in a second step to add the necessary mechanisms to avoid this concurrence.
It can be observed that a mobile IAB-MT migration is driven by the radio conditions, and it should not be delayed to maintain backhaul connectivity and to avoid service interruption at the served UEs. It means that a mobile IAB-MT handover may be triggered and executed while a migration of the co-located mobile IAB-DU is on-going.
Besides, option 2 seems more efficient than option 1 when considering the support of concurrent DU and MT migrations. Therefore, if concurrent DU and MT migrations have to be supported, then the procedures for MT and DU migrations are defined taking into account the possible concurrence of DU and MT migrations (option 2).
Providing identification information to a target Fl donor-CU, one question to address is which node informs the target Fl donor-CU for the DU migration of a mobile lAB-node about the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID).
The 3 following options may be considered for the providing node:
- Option 1 : the source Fl donor-CU. In this case, the source Fl donor-CU may relay to the target Fl donor-CU the identification information previously received from the source non-Fl donor-CU at the MT migration of the mobile lAB-node.
- Option 2: the non-Fl donor-CU. In this case the source Fl donor-CU should have provided to the non-Fl donor-CU the identification information related to the target Fl donor-CU.
- Option 3: the migrating lAB-node. In this case, the non-Fl donor-CU should have provided the identification information to the lAB-node.
Therefore, the 3 following options may be considered to provide the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID) to the target Fl donor-CU for the DU migration of a mobile lAB-node:
- Option 1 : the source Fl donor-CU,
- Option 2: the source non-Fl donor-CU,
- Option 3 : the migrating lAB-node.
Option 2 may be a suitable option as it is in line with the following statement:
The source donor CU for the mlAB-MT HO provides to the donor CU serving the mlAB-DU at least the: gNB ID of the target donor CU for the ml AB -MT HO.
- ID(s) of the mlAB-MT.
As mentioned above, in case of concurrent MT handover and DU migration for a mobile lAB-node, it is the DU migration that may suffer from delay or failure due to the modification of the backhaul path to communicate with the mobile lAB-node.
To be more precise on a potential issue, it is considered the case where the mobile IAB- node has successfully performed the Fl setup procedure with a target Fl donor-CU for DU migration purpose, and that this target Fl donor-CU is different from the non-Fl donor-CU for the mobile lAB-node. If meanwhile, a MT migration of the mobile lAB-node has occurred toward a target non-Fl donor-CU (still different from the target Fl donor-CU), the target Fl donor-CU may not be aware of this new non-Fl donor-CU to perform the transport migration management (TMM) procedure.
It can be noted that in case the target logical mlAB-DU’s CU is different from the mlAB- MT’s CU, the target logical mlAB-DU’s CU needs to be informed about the mlAB-MT’s CU ID and the mlAB-MT ID so that it can initiate the Xn TMM procedures towards mlAB-MT’s CU.
However, this statement may not be accurate enough to prevent any deadlock situation in case of concurrent MT and DU migrations. Indeed, it does not say when the target Fl donor- CU (i.e. the target logical mlAB-DU’s CU) is informed about the non-Fl donor-CU (i.e the mlAB-MT’s CU ID). If the target Fl donor-CU was informed before the MT migration, then the target Fl donor-CU will trigger the TMM procedures toward a donor-CU that may no longer be the non-Fl donor-CU.
Therefore, the above statement could be completed by the following: if the mlAB-MT’s CU is changed during a DU migration, the target logical mlAB-DU’s CU needs to be informed about the target mlAB-MT’s CU ID and the mlAB-MT ID, before it can initiate the TMM procedures towards the target mlAB-MT’s CU.
From the above example, it appears that some adaptations of MT and DU migration procedures may be required to avoid deadlock situations and to limit the impact of concurrent MT and DU migrations to some delay to complete the procedures.
Assuming that the mlAB-MT handover (or migration) and mlAB-DU migration are separate procedures, does not preclude that both migrations may overlap in time. To go forward, there are 3 options:
- option 1 : to consider concurrent DU and MT migrations as a working assumption, to define the procedures without taking into account the potential concurrence in a first step, and then in a second step to refine (if necessary) the procedures to support concurrent DU and MT migrations,
- option 2: to consider concurrent DU and MT migrations as a working assumption, then to define the procedures accordingly,
- option 3 : to not support concurrent DU and MT migrations, to define the procedures, and in a second step to add the necessary mechanisms to avoid this concurrence. It can be observed that a mobile IAB-MT migration is driven by the radio conditions, and it should not be delayed to maintain backhaul connectivity and to avoid service interruption at the served UEs. It means that a mobile IAB-MT handover may be triggered and executed while a migration of the co-located mobile IAB-DU is on-going.
Besides, option 2 seems more efficient than option 1 when considering the support of concurrent DU and MT migrations.
Therefore, if concurrent DU and MT migrations have to be supported, then the procedures for MT and DU migrations are defined taking into account the possible concurrence of DU and MT migrations (option 2).
Providing identification information to a target Fl donor-CU, one question to address is which node informs the target Fl donor-CU for the DU migration of a mobile lAB-node about the identification information related to the non-Fl donor-CU (i.e. the mlAB-MT’s CU ID and the mlAB-MT ID).
There are the following two options for providing the gNB-ID of the mlAB-MT’s CU and the XnAP UE ID of the mlAB-MT at this CU to mlAB-DU’s target CU:
• Option A: XnAP signalling from the mlAB-DU’s source CU.
• Option B: F1AP signalling from the target logical mlAB-DU.
It can be noted that both options can support concurrent MT and DU migrations according to the way it is performed.
With option A, the source Fl donor-CU may relay to the target Fl donor-CU the identification information previously received from the source non-Fl donor-CU at the MT migration of the mobile lAB-node. In this case the XnAP procedure NG-RAN node Configuration Update procedure may be appropriate.
With option B, providing the identification information through the Fl setup procedure may not be sufficient: in case the non-Fl donor CU changes after the completion of the Fl setup procedure, the target F 1 donor-CU will not know the new non-F 1 donor-CU to perform the TMM procedure. Thus, the F1AP procedure gNB-DU Configuration Update may be appropriate as it can be triggered at any time, for instance when the non-Fl donor-CU has changed.
For the down selection (i.e. for the selection of one option between option A and option B), option A seems more straight forward than option B as it does not involve the migrating lAB-node as intermediate node. Thus, it can be proposed that XnAP signalling from the mlAB-DU’s source CU is used for providing the gNB-ID of the mlAB-MT’s CU and the XnAP UE ID of the mlAB-MT at this CU to the mlAB-DU’s target CU.
Taking into account that the identifier of the MT of the mobile lAB-node (mlAB-MT) may be the BAP address assigned by the lAB-donor-CU controlling the mlAB-MT (and sent to the mlAB-MT via RRC protocol message when the mlAB-MT connects to this lAB-donor- CU), and that the lAB-donor-CU controlling the mlAB-MT may be referred to as the non-Fl terminating donor-CU or RRC terminating donor-CU, it can be further questioned which ID assigned by the MT’s CU for the IAB MT should be used for the TMM procedure and how this ID can be mapped to a corresponding IAB node.
Actually, this ID assigned by the RRC terminating donor-CU (i.e. the mlAB-MT’s CU) may be a BAP address or a UE XnAP ID.
The BAP address selected by the RRC terminating donor-CU can be provided by the target logical mobile IAB-DU to the target Fl terminating donor-CU (i.e. the mlAB-DU’s CU) in the legacy Rel-16/17 Fl setup request message. In case only the BAP address is provided (and not the UE XnAP ID allocated at the RRC terminating donor-CU), the TMM request message shall be amended to allow the use of the BAP address IE instead of the non-Fl terminating lAB-donor UE XnAP ID IE. Moreover, the behavior of the RRC terminating donor-CU receiving this TMM request message shall be adapted accordingly. Indeed, according to the Release 17 specifications (TS 38.423), the presence of UE XnAP IDs allocated by the Fl terminating donor-CU and by the RRC terminating donor-CU is mandatory for the TMM procedure.
To avoid the modifications of the TMM procedure and of the IAB-donor-CUs’ behavior, the UE XnAP ID allocated at the RRC terminating donor-CU should be provided to the target Fl terminating donor-CU. For this purpose, there are two options:
- F1AP signalling from the target logical mobile IAB-DU, e.g. with the Fl setup request message or the gNB-DU Configuration Update message. This option involves that the UE XnAP ID is provided to the mobile lAB-node beforehand, e.g. through RRC by the RRC terminating donor-CU. With this option, it is not needed to provide a BAP address in the Fl setup request message.
- XnAP signalling from the source Fl terminating donor-CU. This option may involve the introduction of a new XnAP procedure. Besides, to avoid any confusion in case of DU migration of several mobile lAB-nodes at the same time, an additional piece of information known by the target Fl terminating donor-CU shall 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 lAB-node, assuming this BAP address was present in the Fl setup request message from the target logical mobile IAB-DU to the target Fl terminating donor-CU, and assuming this BAP address is also available at the source Fl terminating donor-CU.
Based on the above considerations, we can conclude that there is less specifications impact when F1AP signalling from the target mobile IAB-DU is selected for transferring an ID of the mobile IAB MT to the target Fl terminating donor-CU, and that it is preferable to use the UE XnAP ID for the identification of the mobile IAB-MT.
Thus, it is proposed that for the case of DU migration of a mobile lAB-node, F1AP signalling from the target mobile IAB-DU is selected for transferring the UE XnAP ID of the mobile IAB MT (at the RRC terminating donor-CU) to the target Fl terminating donor-CU.
Considering the network integration case, there are two options to pass the identification information to the Fl terminating donor-CU (i.e. the mlAB-DU’s CU):
- Option 1 : through F1AP signalling, the mobile lAB-node provides the identification information based on information received from the RRC terminating donor-CU (i.e. the mlAB-MT’s CU),
- Option 2: through XnAP signalling, the RRC terminating donor-CU provides the identification information once the RRC terminating donor-CU knows the identifier of the Fl terminating donor-CU from the mobile lAB-node.
With the option 2, the RRC terminating donor-CU shall provide an identifier of the mobile lAB-node known by the Fl terminating donor-CU. This identifier may be the BAP address of the mobile IAB-MT selected by the RRC terminating donor-CU, assuming this BAP address was present in the Fl setup request message from the mobile IAB-DU to the Fl terminating donor-CU.
With the option 1, the F1AP signalling can be the same as for the case of DU migration. Moreover, it seems there is less specifications impact with option 1 than with option 2.
Thus, it is proposed that for the case of network integration of a mobile lAB-node, F1AP signalling from the mobile IAB-DU is selected for transferring the gNB-ID of the RRC terminating donor-CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor-CU) to the F 1 terminating donor-CU.
Assuming the same Fl AP signalling is adopted to pass identification information at DU migration and at network integration of a mobile lAB-node, then, for the sake of consistency, the mobile lAB-node should also provide identification information related to the target RRC terminating donor-CU at MT migration.
Thus, it is proposed that for the case of MT integration of a mobile lAB-node, F1AP signalling from the mobile IAB-DU is selected for transferring the gNB-ID of the target RRC terminating donor-CU and the UE XnAP ID of the mobile IAB MT (at this RRC terminating donor-CU) to the F 1 terminating donor-CU.
The F1AP procedure gNB-DU Configuration Update is appropriate to inform the Fl terminating donor-CU in the case of MT migration.
Then, the gNB-DU Configuration Update procedure can be used by a mobile lAB-node to inform the Fl terminating donor-CU about the gNB-ID of the RRC terminating donor-CU and the UE XnAP ID of the mobile IAB-MT at this CU.
It can be observed that the mlAB-MT’s source donor CU can send the info on the mlAB- MT’s target donor CU to the mlAB-DU’s donor CU after the completion of IAB-MT HO (handover). Actually, the proposal is compatible with this statement as the source RRC terminating donor-CU (i.e. the mlAB-MT’s source donor CU) would pass the information to the Fl terminating donor-CU (i.e. the mlAB-DU’s donor CU), not directly, but through the mobile lAB-node.
While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
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 advantageously used. In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.
Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer- readable medium.
By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer- readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

Claims
1. A method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node, the transport migration to be performed after a Distributed Unit, DU, of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target IAB- donor-CU, the method at the target lAB-donor-CU comprising: receiving a notification including identification information for identifying an IAB- donor-CU serving a Mobile Termination, MT, of the lAB-node, the lAB-donor-CU serving the MT of the lAB-node being a different lAB-donor-CU to the target lAB-donor-CU; based on the identification information and after the DU of the lAB-node has been migrated to the target IAB topology, performing transport migration for migrating traffic related to the lAB-node for routing over at least one path between the target lAB-donor-CU and the lAB-node through an IAB topology managed by the lAB-donor-CU serving the MT.
2. The method of claim 1, wherein the lAB-donor-CU serving the MT is the source IAB- donor-CU.
3. The method of claim 1, wherein the lAB-donor-CU serving the MT is a second IAB- donor-CU managing a second IAB topology, wherein the path between the target lAB-donor- CU and the MT of the lAB-node is through the second IAB topology.
4. The method of any one of the preceding claims, wherein receiving a notification comprises receiving a notification from the source lAB-donor-CU.
5. The method of claim 4, wherein the notification is included in a DU migration notification message.
6. The method of claim 4, wherein the notification is included in a configuration update message.
7. The method of any one of the claims 1 to 3, wherein receiving a notification comprises receiving a notification from the lAB-node.
8. The method of claim 7, wherein the notification is included in a Fl setup request message or a configuration update message.
9. The method of claim 3, wherein receiving a notification comprises receiving a notification from the second lAB-donor-CU.
10. The method of claim 9, wherein the notification is a notification for indicating the second lAB-donor-CU is ready for transport migration of the traffic for the lAB-node, the notification including identification information for identifying the second lAB-donor-CU.
11. The method of claim 10, wherein the notification is included in a transport migration ready message.
12. The method of any one of the preceding claims, wherein the notification further includes identification information for identifying the MT of the lAB-node.
13. A method for use in managing a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target IAB- donor-CU, the method at the source lAB-donor-CU comprising: determining the DU of the lAB-node is to be migrated to the target lAB-donor-CU; sending, to the lAB-node, a request for establishing a Fl connection between the target lAB-donor-CU and the lAB-node.
14. The method of claim 13, wherein sending comprises sending a request for establishing a Fl connection between the target lAB-donor-CU and the lAB-node and for informing the target lAB-donor-CU of the identity of an lAB-donor-CU serving the Mobile Termination, MT, of the IAB.
15. The method of claim 13 or claim 14, wherein the request is included in a DU activation request message.
16. The method of claim 13 or claim 14 or claim 15, wherein the request includes an Information Element, IE, for indicating the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node.
17. The method of any one of claims 13 to 16, wherein the request includes identification information for identifying the lAB-donor-CU serving the MT.
18. The method of any one of claims 13 to 17, wherein the request includes information for indicating to the lAB-node the lAB-node is to inform the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT.
19. The method of claim 18, wherein the request includes the information when the target lAB-donor-CU is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node.
20. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, the method at the source lAB-donor-CU comprising: determining the DU of the lAB-node is to be migrated to the target lAB-donor-CU; sending, to the target lAB-donor-CU, a notification including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT of the IAB- node; performing DU migration of the DU of the lAB-node to the target IAB topology.
21. The method of claim 20, wherein the notification is included in a DU migration notification message.
22. The method of claim 20, wherein the notification is included in a configuration update message.
23. The method of any one of claims 20 to 22, wherein the notification further includes identification information for identifying the MT of the lAB-node.
24. The method of any one of claims 20 to 22, wherein sending comprises sending, to the target lAB-donor-CU, a notification including identification information for identifying the lAB-donor-CU serving the MT of the lAB-node when the target lAB-donor-CU is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node.
25. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, the method at the lAB-node comprising: sending, to the target lAB-donor-CU, a Fl setup request for requesting the setup of a Fl connection, the Fl setup request including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node.
26. The method of claim 25, further comprising receiving, from the source lAB-donor-CU, a request for establishing a Fl connection between the target lAB-donor-CU and the IAB- node.
27. The method of claim 25, further comprising receiving, from the source lAB-donor-CU, a request for establishing a Fl connection between the target lAB-donor-CU and the IAB- node and for informing the target lAB-donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node.
28. The method of claim 26 or claim 27, wherein the request for establishing a Fl connection includes information for indicating the lAB-node is to inform the target IAB- donor-CU of the identity of the lAB-donor-CU serving the MT of the lAB-node.
29. The method of any one of claims 26 to 28, wherein the request includes identification information for identifying the lAB-donor-CU serving the MT.
30. The method of any one of claims 25 to 29, wherein the Fl setup request includes identification information for identifying the MT of the lAB-node.
31. The method of any one of claims 25 to 30, wherein sending comprises sending, to the target lAB-donor-CU, the Fl setup request including identification information for identifying the lAB-donor-CU serving the MT when the target lAB-donor-CU is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node.
32. A method for use in managing transport migration for traffic related to an Integrated Access Backhaul, IAB, node, the transport migration is to be performed after a Distributed Unit, DU, of the lAB-node has been migrated from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target IAB- donor-CU, a Mobile Termination, MT, of the lAB-node having been migrated to a second lAB-donor-CU , the second lAB-donor-CU being a different lAB-donor-CU to the target lAB-donor-CU and the source lAB-donor-CU, the method at the second lAB-donor-CU comprising: after the DU of the lAB-node has been migrated to the target IAB topology, receiving a transport migration release message for requesting release of transport migration set up by the source lAB-donor-CU for traffic related to the lAB-node, sending, to the target lAB-donor-CU, a notification for indicating the second IAB- donor-CU is ready for transport migration of the traffic related to the lAB-node over at least one path between the target lAB-donor-CU and the lAB-node through an IAB topology managed by the second lAB-donor-CU, the notification including identification information for identifying the second lAB-donor-CU.
33. The method of claim 32, wherein the notification is included in a transport migration ready notification message.
34. The method of claim 32 or claim 33, wherein after receiving the transport migration release message, releasing the transport migration previously set up by the source lAB-donor- CU.
35. The method of claim 34, wherein releasing comprises reconfiguring the lAB-nodes involved in routing traffic to and/or from the lAB-node by deleting, at each lAB-node, configuration information associated with routing traffic to and/or from the lAB-node.
36. The method of claim 32 or claim 33, wherein after receiving the transport migration release message, suspending the transport migration previously set up by the source IAB- donor-CU.
37. The method of claim 36, wherein suspending comprises suspending traffic migration and maintaining configurations of one or more lAB-nodes in the one or more routing paths set up by the source lAB-donor-CU for traffic related to the lAB-node.
38. The method of any one of claims 32 to 37, wherein the notification includes identification information for identifying the MT of the lAB-node.
39. The method of any one of claims 32 to 38, wherein the transport migration release message includes information indicating that the traffic migration release is due to a DU migration of the lAB-node toward the target lAB-donor-CU.
40. A method for use in a migration process for migrating a Distributed Unit, DU, of an Integrated Access Backhaul, IAB, node from a source IAB topology managed by a source lAB-donor Central Unit, CU, to a target IAB topology managed by a target lAB-donor-CU, the method at the lAB-node comprising: sending, to the target lAB-donor-CU, a notification including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node.
41. The method of claim 40, wherein the notification further includes identification information for identifying the MT of the lAB-node.
42. The method of claim 40 or claim 41, wherein the notification is included in a configuration update message.
43. The method of any one of claims 40 to 42, wherein the sending comprises sending, to the target lAB-donor-CU, a notification including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node, after completion of a setup of a Fl connection between the DU of the IAB node and the target lAB-donor-CU.
44. The method of any one of the preceding claims when dependent on a respective one of the claims 12, 23, 30, 38, or 41, wherein the identification information for identifying the MT of the lAB-node includes at least one of: UE XnAP ID; and a BAP address.
45. An apparatus for an Integrated Access Backhaul, IAB, donor Central Unit, CU, node of an IAB communication system, the apparatus comprising: one or more processing units configured to: receive a notification including identification information for identifying an IAB- donor-CU serving a Mobile Termination, MT, of an lAB-node of the IAB communication system, the lAB-donor-CU serving the MT of the lAB-node being a different lAB-donor-CU to the IAB donor CU; based on the identification information and after a DU of the lAB-node has been migrated to a IAB topology managed by the IAB donor CU, perform transport migration for migrating traffic related to the lAB-node for routing over at least one path between the IAB donor CU and the lAB-node through an IAB topology managed by the lAB-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 lAB-node.
47. The apparatus of claim 46, wherein the notification is included in a Fl setup request message or a configuration update message.
48. The apparatus of any one of claims 45 to 47, wherein the notification further includes identification information for identifying the MT of the lAB-node.
49. The apparatus of claim 48, wherein the identification information for identifying the MT of the lAB-node includes at least one of: UE XnAP ID; and a BAP address.
50. An apparatus for an Integrated Access Backhaul, IAB, donor Central Unit, CU, node of an IAB communication system, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims 1 to 24 and claims 32 to 39 or claim 44.
51. An apparatus for an Integrated Access Backhaul, IAB, node of an IAB communication system, the apparatus comprising: one or more processing units configured to send, to a target lAB-donor-CU, a Fl setup request for requesting the setup of a F 1 connection, the F 1 setup request including identification information for identifying an lAB-donor-CU serving a Mobile Termination, MT, of the lAB-node.
52. The apparatus of claim 51, wherein the one or more processing units are further configured to receive, from a source lAB-donor-CU, a request for establishing a Fl connection between the target lAB-donor-CU and the lAB-node.
53. The apparatus of claim 51 or 52, wherein the Fl setup request includes identification information for identifying the MT of the lAB-node.
54. The apparatus of claim 53, wherein the identification information for identifying the MT of the lAB-node includes at least one of UE XnAP ID; and a BAP address.
55. The apparatus of any one of claims 51 to 54, wherein the one or more processing units are configured to send, to the target lAB-donor-CU, the Fl setup request including identification information for identifying the lAB-donor-CU serving the MT when the target lAB-donor-CU is a different lAB-donor-CU to the lAB-donor-CU serving the MT of the lAB-node.
56. An apparatus for an Integrated Access Backhaul, IAB, node of an IAB communication system, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims 25 to 31 and claims 40 to 44.
57. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 44.
58. A computer-readable medium carrying a computer program according to claim 57.
PCT/EP2024/051544 2023-02-15 2024-01-23 Migration of nodes in an iab communication system WO2024170232A1 (en)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
GB2302171.0A GB2627227A (en) 2023-02-15 2023-02-15 Migration of nodes in an IAB communication system
GB2302171.0 2023-02-15
GB2305082.6A GB2627311A (en) 2023-02-15 2023-04-05 Migration of nodes in an IAB communication system
GB2305082.6 2023-04-05
GB2307011.3A GB2627313A (en) 2023-02-15 2023-05-11 Migration of nodes in an IAB communication system
GB2307011.3 2023-05-11
GB2314756.4A GB2627330A (en) 2023-02-15 2023-09-26 Migration of nodes in an IAB communication system
GB2314756.4 2023-09-26

Publications (1)

Publication Number Publication Date
WO2024170232A1 true WO2024170232A1 (en) 2024-08-22

Family

ID=89768436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/051544 WO2024170232A1 (en) 2023-02-15 2024-01-23 Migration of nodes in an iab communication system

Country Status (1)

Country Link
WO (1) WO2024170232A1 (en)

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description (Release 18)", vol. RAN WG3, no. V18.0.0, 12 January 2024 (2024-01-12), pages 1 - 152, XP052576773, Retrieved from the Internet <URL:https://ftp.3gpp.org/Specs/archive/38_series/38.401/38401-i00.zip 38401-i00.docx> [retrieved on 20240112] *
"5G; NG-RAN; Architecture description (3GPP TS 38.401 version 17.3.0 Release 17)", vol. 3GPP RAN, no. V17.3.0, 17 January 2023 (2023-01-17), pages 1 - 128, XP014446609, Retrieved from the Internet <URL:http://www.etsi.org/deliver/etsi_ts/138400_138499/138401/17.03.00_60/ts_138401v170300p.pdf> [retrieved on 20230117] *
INTEL CORPORATION: "Discussion on Full Migration of mobile IAB-node", vol. RAN WG3, no. Electronic Meeting; 20220815 - 20220824, 9 August 2022 (2022-08-09), XP052264944, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_117-e/Docs/R3-224777.zip R3-224777-Discussion on full migration of mobile IAB-node_vS.docx> [retrieved on 20220809] *
QUALCOMM (MODERATOR): "CB#34 IAB_MigrationProcedureDetails", vol. RAN WG3, no. Online; 20210125 - 20210204, 5 February 2021 (2021-02-05), XP051978484, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_111-e/Docs/R3-211199.zip R3-211199 CB34 - IAB_MigrationProcedureDetails PH2 - summary - Copy.docx> [retrieved on 20210205] *
SU YI ET AL: "(TP for Mobile IAB BL CR TS38.401) Discussion on IAB-node mobility and integration", vol. 3GPP RAN 3, no. Toulouse, FR; 20230821 - 20230825, 11 August 2023 (2023-08-11), XP052437611, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG3_Iu/TSGR3_121/Docs/R3-233881.zip R3-233881_iab_mobility_tp_38401.doc> [retrieved on 20230811] *
YUANPING ZHU ET AL: "(TP for NR_mobile_IAB BL CR for TS 38.401):Partial migration for mobile IAB", vol. 3GPP RAN 3, no. Toulouse, FR; 20221114 - 20221118, 4 November 2022 (2022-11-04), XP052223834, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG3_Iu/TSGR3_118/Docs/R3-226350.zip R3-226350 Partial migration for mobile IAB.docx> [retrieved on 20221104] *

Similar Documents

Publication Publication Date Title
EP4449770A1 (en) Methods for use in a process for migrating resources between integrated access and backhaul topologies
WO2024170232A1 (en) Migration of nodes in an iab communication system
GB2627313A (en) Migration of nodes in an IAB communication system
GB2606033A (en) Routing data in an integrated access and backhaul network
WO2024094547A1 (en) Migration of nodes in an iab communication system
GB2628873A (en) Migration management in an IAB communication system
GB2624000A (en) Migration of nodes in an IAB communication system
WO2024208856A2 (en) Migration management in an iab communication system
WO2024094687A2 (en) Migration of nodes in an iab communication system
GB2624001A (en) Migration of nodes in an IAB communication system
TW202435635A (en) Migration of nodes in an iab communication system
WO2024017909A1 (en) Managing migration involving a mobile integrated access and backhaul node
GB2620777A (en) PCI collision avoidance in 5G mobile IAB
GB2627318A (en) PCI collision detection in 5G mobile IAB
WO2024170503A2 (en) Pci collision detection in 5g mobile iab
US20240048486A1 (en) Routing data in an integrated access and backhaul network
WO2024017590A1 (en) Pci collision avoidance in 5g mobile iab
WO2024013071A1 (en) Managing network connectivity in a wireless communication system
GB2620605A (en) Managing network connectivity in a wireless communication system
GB2628842A (en) Managing or facilitating network connectivity in a wireless communication system
GB2623993A (en) Managing network connectivity in a wireless communication system
TW202423155A (en) Managing network connectivity in a wireless communication system
WO2024208858A1 (en) Managing or facilitating network connectivity in a wireless communication system
GB2611068A (en) Routing data in an integrated access and backhaul network
GB2625930A (en) Routing data in an integrated access and backhaul network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24702486

Country of ref document: EP

Kind code of ref document: A1