WO2023240523A1

WO2023240523A1 - Mobility management in mobile integrated access and backhaul network

Info

Publication number: WO2023240523A1
Application number: PCT/CN2022/099109
Authority: WO
Inventors: Ilkka Antero Keskitalo; Matti Einari Laitila; Esa Mikael Malkamaki; Henri Markus Koskinen; Xiang Xu
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2022-06-16
Filing date: 2022-06-16
Publication date: 2023-12-21
Anticipated expiration: 2024-12-16
Also published as: CN119366221A

Abstract

Various example embodiments relate to apparatuses and methods for mobility management in integrated access and backhaul networks. A first radio access network node may send to a second radio access network node a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node and receive an acknowledge message responsive to the handover request from the second radio access network node. The handover request may comprise configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node.

Description

MOBILITY MANAGEMENT IN MOBILE INTEGRATED ACCESS AND BACKHAUL NETWORK

TECHNICAL FIELD

Various example embodiments described herein generally relate to communication technologies, and more particularly, to apparatuses and methods for mobility management in mobile integrated access and backhaul (IAB) networks.

BACKGROUND

Certain abbreviations that may be found in the description and/or in the figures are herewith defined as follows:

BAP Backhaul Adaptation Protocol

CN Core Network

CP Control Plane

CU Central Unit

DRB Data Radio Bearer

DU Distributed Unit

F1 Interface between CU and DU

F1-C F1 Control plane

F1-U F1 User plane

gNB next generation Node-B

HO Handover

IAB Integrated Access and Backhaul

MT Mobile Termination

NGC Next Generation Core

NR New Radio

PDU Protocol Data Unit

QoS Quality of Service

RAN Radio Access Network

RLC Radio Link Control

RRC Radio Resource Control

SRB Signaling Radio Bearer

TNL Transport Network Layer

UE User Equipment

UP User Plane

UPF User Plane Function

Vehicle mounted relays (VMRs) can provide high-quality communication services to onboard and surrounding user equipments (UEs) . 5G New Radio (NR) provides support for VMR scenarios in Integrated Access and Backhaul (IAB) networks where the VMR may be implemented as a mobile IAB node which uses wireless links for backhauling (instead of fiber) to enable wireless relaying of NR access to the network. On the network side the wireless backhauling terminates at a base station known as IAB donor which provides network access for one or more IAB nodes and UEs connected to the IAB nodes. As the vehicle moves, the mobile IAB nodes mounted on the vehicle may migrate between cells supported by the IAB donor or between different IAB donors.

SUMMARY

A brief summary of example embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for a more detailed description provided below.

In a first aspect, an example embodiment of a first radio access network node is provided. The first radio access network node may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the first radio access network node at least to send to a second radio access network node a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node and receive an acknowledge message responsive to the handover request from the second radio access network node. The handover request may comprise configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node.

In a second aspect, an example embodiment of a second radio access network node is provided. The second radio access network node may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the second radio access network node at least to receive from a first radio access network node a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node. The handover request may comprise configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node. The second radio access network node may send to the first radio access network node an acknowledge message responsive to the handover request.

In a third aspect, an example embodiment of a central node is provided. The central node may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the central node at least to receive from a first radio access network node and/or a second radio access network node an indication indicative of handover of an integrated access and backhaul node from the first radio access network node to the second radio access network node. One or more user equipments connected to the integrated access and backhaul node are serviced by the central node. The centralize node may suspend transmission between the central node and the integrated access and backhaul node via the first radio access network node in response to the indication.

In a fourth aspect, an example embodiment of a radio access network node is provided. The radio access network node may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the radio access network node at least to send a handover command to an integrated access and backhaul node, and send an indication indicative of the handover of the integrated access and backhaul node to a central node serving one or more user equipments connected to the integrated access and backhaul node. The handover command may comprise one or more parameters to be used to hand over the integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node.

In a fifth aspect, an example embodiment of a central node is provided. The central node may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the central node at least to receive from a radio access network node an indication indicative of handover of an integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node, and suspend transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node in response to the received indication. The central node serves one or more user equipments connected to the integrated access and backhaul node.

Example embodiments of methods, apparatus and computer program products are also provided. Such example embodiments generally correspond to the above example embodiments, and a repetitive description thereof is omitted here for convenience.

Other features and advantages of the example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

Figs. 1A, 1B and 1C are schematic diagrams illustrating IAB network architectures in which example embodiments of the present disclosure can be implemented.

Fig. 2 is a schematic diagram illustrating inter-donor migration of an IAB node.

Fig. 3 is a schematic diagram illustrating intra-donor CU inter-donor DU migration of an IAB node.

Fig. 4 is a schematic message sequence chart illustrating a procedure for inter-donor mobility of an IAB node according to an example embodiment of the present disclosure.

Fig. 5 is a schematic message sequence chart illustrating a procedure for F1 TNL configuration according to an example embodiment of the present disclosure.

Fig. 6 is a schematic flowchart illustrating an inter-donor handover method according to an example embodiment of the present disclosure.

Fig. 7 is a schematic flowchart illustrating an inter-donor handover method according to an example embodiment of the present disclosure.

Fig. 8 is a schematic flowchart illustrating an inter-donor handover method according to an example embodiment of the present disclosure.

Fig. 9 is a schematic message sequence chart illustrating a procedure for intra-donor CU inter-donor DU mobility of an IAB node according to an example embodiment of the present disclosure.

Fig. 10 is a schematic flowchart illustrating an intra-donor CU inter-donor DU handover method according to an example embodiment of the present disclosure.

Fig. 11 is a schematic flowchart illustrating an intra-donor CU inter-donor DU handover method according to an example embodiment of the present disclosure.

Fig. 12 is a schematic block diagram illustrating devices in a communication system in which example embodiments of the present disclosure can be implemented.

Throughout the drawings, same or similar reference numerals indicate same or similar elements. A repetitive description on the same elements would be omitted.

DETAILED DESCRIPTION

Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.

As used herein, the term “network device” refers to any suitable devices or entities that can provide cells or coverage, through which terminal devices can access the network or receive services. The network device may be commonly referred to as a base transceiver station (BTS) , a base station (BS) , or some other suitable terminology. The term “base station” or “base transceiver station” used herein can represent a node B (NodeB or NB) , an evolved node B (eNodeB or eNB) , a next generation Node B (gNB) , or a next generation enhanced Node B (ng-eNB) . The base station may be embodied as a macro base station, a relay node, or a low power node such as a pico base station or a femto base station. The base station may also include or may be referred to as a RAN (radio access network) node, and may consist of several distributed network units, such as a central unit (CU) , one or more distributed units (DUs) , one or more remote radio heads (RRHs) or remote radio units (RRUs) . The number and functions of these distributed units depend on the selected split RAN architecture.

As used herein, the term “terminal device” or “user equipment” (UE) refers to any devices or entities that can wirelessly communicate with the network devices or with each other. Examples of the terminal device can include a mobile phone, a mobile terminal, a mobile station (MS) , a subscriber station, a portable subscriber station, an access terminal, a personal digital assistant (PDA) , a computer, a wearable device, an on-vehicle communication device, a machine type communication (MTC) device, a D2D communication device, a V2X communication device, a sensor and the like. The term “terminal device” can be used interchangeably with UE, a user terminal, a mobile terminal, a mobile station, or a wireless device.

In a 5G communication network, New Radio (NR) cells may be deployed in a wide range of frequency spectrum, which comprises a frequency range 1 (FR1) occupying frequencies less than 6 GHz and a frequency range 2 (FR2) occupying frequencies greater than 6 GHz. At higher frequencies, the coverage of the NR cells is relatively small. As a result, densification via the deployment of more and more base stations is one of the mechanisms that can be employed to satisfy the increasing demand of capacity while providing a full coverage area in wireless networks. In such a deployment, various forms of wireless connectivity that uses integrated access and backhaul (IAB) nodes between base stations and user equipments (UEs) are supported in 5G NR systems. The IAB nodes can support wireless access and backhaul in both FR1 and FR2 spectrum. NR UEs can transparently connect to an IAB-node via NR. Further, legacy Long Term Evolution (LTE) UEs can transparently connect to an IAB node via LTE in case the IAB node supports backhauling of LTE access.

IAB nodes can be used in a diverse range of deployment scenarios, including support for outdoor small cell deployments, indoor deployments, and vehicle mounted relays (VMRs) . The VMRs may utilize mobile IAB nodes mounted on a vehicle (e.g., train, bus, tram, subway, etc. ) to increase data rate and reliability for UEs either within the vehicle or in the surrounding. Unlike a stationary IAB node which may be connected to a fixed IAB donor (base station) , the mobile IAB node may migrate between different IAB donors as the vehicle moves. For example, when the mobile IAB nodes are mounted on a train that travels a long distance, the mobile IAB nodes and the UEs connected to the IAB nodes would migrate between a large number of IAB donors. Therefore, it has been proposed that a dedicated central unit (CU) may be used to service the UEs connected to the mobile IAB nodes.

Figs. 1A, 1B and 1C illustrate some example architectures of IAB networks in which a CU (hereinafter referred to as mobile CU or m-CU) is provided to service UEs connected to mobile IAB nodes. Example embodiments of the present disclosure discussed below may be implemented in but not limited to such example IAB network architectures. Referring to Fig. 1A first, there is shown an example mobile IAB network architecture with a single hop backhaul to a mobile IAB node. As shown in Fig. 1A, a mobile IAB node 110 is RRC connected to an IAB donor 130 via NR Uu interface, the IAB donor 130 is connected to a core network 160 via NG interface, and a central unit 150 (i.e., m-CU, also referred to as central node) is provided to service UEs (e.g. the UE 101a) connected to the mobile IAB node 110. The m-CU 150 may connect to a mobile IAB specific user plane function (UPF) 162, which may be referred to as mobile UPF (m-UPF) hereinafter. The IAB network 100A shown in Fig. 1A may be a part of a larger cellular communication system such as a 5G system (5GS) .

The IAB donor 130 may be a Radio Access Network (RAN) node e.g. a base station that has backhaul connectivity to the core network 160. The IAB donor 130 may be treated as a single logical node that comprises a set of functions such as a central unit (CU) 134, one or more distributed units (DUs) 132, and potentially other functions (not shown) . In some deployments, the IAB donor 130 may be split according to these functions, which can all be either collocated or non-collocated as allowed by 3GPP NG-RAN architecture. Also, some of the functions presently associated with the IAB donor 130 may be moved outside of the donor in case those functions do not perform IAB-specific tasks. In an example deployment, the CU 134 may be deployed at a central office, and the DUs 132 may be deployed at respective cell sites. In another example where the RAN has a cloud-based architecture, the CU 134 may be deployed in the cloud.

The donor DU 132 and the donor CU 134 are connected via F1 interface, including F1-C interface between the donor DU 132 and a control plane (CP, not shown) of the donor CU 134 and F1-U interface between the donor DU 132 and a user plane (UP, not shown) of the donor CU 134. The donor CU 134 may include one donor CU-CP and multiple donor CU-UPs, the donor DU 132 can have F1-C connection with only one donor CU-CP and F1-U connections with multiple donor CU-UPs. The donor DU 132 may host one or more transmit/receive points (TRPs) and support one or more cells to service UEs and child IAB nodes. In the example, one or more UEs 101b may be connected to the donor DU 132 via NR Uu interface and serviced by the control and user planes of the donor CU 134.

The IAB node 110 may hold a distributed unit (DU) 112 and a mobile termination (MT) part 114. The IAB MT 114 is a component that offers a function residing on the IAB node 110 which terminates the radio interface layers of the backhaul Uu interface toward the IAB donor 130 or other intermediate IAB nodes. The IAB MT 114 enables the IAB node 110 to act much like a normal UE towards the IAB donor 130. In the example shown, the MT 114 is RRC connected to the IAB donor 130.

Similar to the donor DU 132, the IAB DU 112 may host one or more transmit/receive points (TRPs) and support one or more cells. In an example, the mobile IAB node 110 may not have descendant IAB nodes, and only one or more UEs 101a are connected to the IAB DU 112 via the NR Uu interface. From the UE point of view, the IAB DU cell may be seen as a normal cell like a donor DU cell. The IAB DU 112 of the mobile IAB node 110 may have an F1 connection to the m-CU 150, and the UEs 101a connected to the IAB DU 112 can get control plane and user plane services from the m-CU 150. The F1 connection and other backhaul connections may be carried via a PDU session established between the IAB MT 114 and a mobile IAB specific UPF (m-UPF) 162 through the access RAN (i.e. the IAB donor 130) . The core network 160 can select the m-UPF 162 appropriate for the m-CU 150 during the PDU session establishment. For example, the core network 160 may select the m-UPF 162 in the same local edge cloud as the donor CU 134. The PDU session serves as a point-to-point link between the IAB MT 114 and the m-UPF 162, and radio bearers may be configured at the IAB MT 114 and the donor CU 134 for the PDU session. From the core network point of view, the IAB DU 112 and the m-CU 150 may be seen as a base station, and the donor DU 132 and the donor CU 134 may be seen as another base station.

In the 5G NR context, the core network 160 may be Next Generation Core (NGC) . The NGC 160 may include various entities and network functions (not shown) such as an Access and Mobility Management function (AMF) , a Session Management Function (SMF) , a User Plane Function (UPF) , a non-3GPP Interworking Function (N3IWF) and so on. The m-CU 150 and the donor CU 134 may connect to the NGC 160 via NG interface.

In the network architecture shown in Fig. 1A, the physical location of the m-CU 150 and the m-UPF 162 may be flexibly determined depending on the physical deployment of the network implementations. In an example, the m-CU 150 and the m-UPF 162 may reside in the IAB donor 130 as a part of functions of the IAB donor 130. In another example where the access RAN has a cloud-based architecture, the m-CU 150 and the m-UPF 162 may be placed in a cloud infrastructure. Depending on the use cases and moving range of the mobile IAB node 110, the m-CU 150 and the m-UPF 162 may be placed within a RAN local cloud, e.g. hosted by the IAB donor 130 or another IAB donor node. An advantage of the cloud-based architecture is that it can provide flexibility to serve relatively large areas with dedicated mobile functions serving the mobile IAB node 110. In some example embodiments, the m-CU 150 and the m-UPF 162 may be a part of a specific network slice serving mobile IAB nodes.

The example IAB network architecture illustrated in Fig. 1A can reuse existing functions and interfaces defined in 5G NR. In particular, the mobile IAB node 110 can reuse the MT plus DU structure of current stationary IAB nodes, which can minimize changes to IAB node hardware and software. IAB MT, IAB DU, donor DU, donor CU, UPF, AMF and SMF as well as the corresponding interfaces such as NR Uu between UE and IAB/donor DU and between MT and parent-node DU, F1 (including F1-C and F1-U) between DU and CU, Xn between CUs and NG between RAN and NGC may be used as baseline for the IAB architectures. Therefore, the mobile IAB architecture can serve legacy UEs with minimum or no impact to the access network. Enhancements to the IAB network may be implemented in the dedicated functions or entities, i.e. the m-CU 150, the m-UPF 162 and the mobile IAB node 110. The mobile IAB node 110 is almost transparent to the access RAN, which provides flexibility to apply the architecture for a variety of use cases and network deployment scenarios.

A further advantage according to the IAB network architecture shown in Fig. 1A is that the RAN node which provides network access for the mobile IAB node 110 may be an IAB-capable RAN node such as the IAB donor 130 or a non-IAB capable RAN node such as a legacy base station. It enables the mobile IAB node 110 to connect to any NR RAN base station with or without IAB capabilities, and the operator does not need to upgrade a large number of legacy base stations which normally do not need wireless backhaul for IAB support. This is especially useful in scenarios where the mobile vehicle carrying the IAB node 110 travels a long distance and the IAB node 110 migrates between different base stations deployed along the distance.

Different from the single hop architecture illustrated in Fig. 1A, Fig. 1B illustrates a multi-hop architecture of a mobile IAB network 100B where the mobile IAB node 110 is connected to the IAB donor 130 via one or more intermediate IAB nodes 120. The intermediate IAB nodes 120 may be stationary/fixed nodes, and the mobile IAB node 110 may be the last (the most downstream) IAB node in the multi-hop chain serving access UEs. The intermediate IAB nodes 120 may also include an IAB DU 122 which sustains Uu interface with the IAB MT 114 in the mobile IAB node 110 and an IAB MT 124 which sustains Uu interface with the IAB donor DU 132. The IAB DU 122 may have an F1 connection to the IAB donor CU 134, and the F1 connection may be carried via a PDU session or a backhaul adaption protocol (BAP) layer (not shown) . Similar to IAB DU 112 and the donor DU 132, the IAB DU 122 can also support one or more cells to service UEs. For example, one or more UEs 101c may be connected to the IAB DU 122 via the NR Uu interface.

Similar to the architecture shown in Fig. 1A, the wireless backhaul of the mobile IAB node 110 may be carried via the PDU session, and the radio bearers for the PDU session go transparently through the stationary IAB node 120. Therefore, the mobile IAB node 110 is regarded as a normal UE connected to the stationary IAB node 120. It would be appreciated that the UEs 101a connected to the mobile IAB node 110 are serviced in control and user planes by the m-CU 150, while the UEs 101c connected to the intermediate IAB nodes 120 and the UEs 101b connected to the IAB donor 130 are serviced in control and user planes by the donor CU 134. Other aspects of the example shown in Fig. 1B are similar to the example shown in Fig. 1A and a repetitive description is omitted here for convenience.

Fig. 1C shows another example architecture of a mobile IAB network 100C. Compared with the architectures shown in Figs. 1A and 1B, the mobile IAB network 100C does not use the PDU session for backhaul links. Instead, a L2 routing protocol called Backhaul Adaptation Protocol (BAP) is included on top of backhaul RLC bearer for routing packets to a downstream or upstream destination node and mapping UE bearer data to proper backhaul RLC channels (also for mapping between ingress and egress backhaul RLC channels in the intermediate IAB nodes 120) . The BAP layer can deliver control and data PDUs via multiple hops, though the intermediate IAB nodes 120 are omitted in Fig. 1C. In some examples where no intermediate IAB node 120 is connected between the mobile IAB node 110 and the IAB donor 130, the BAP layer may be omitted and the backhaul links may be carried via a radio bearer layer. Between the donor DU 132 and the m-CU 150, the backhaul links may be carried over Internet Protocol (IP) interface. The mobile IAB network 100C has an advantage that the core network interfaces are terminated at the donor CU 134 and the m-CU 150, and therefore the L2 relaying is only a RAN functionality without the m-UPF function shown in Figs. 1A and 1B. Other aspects of the example shown in Fig. 1C are similar to the examples shown in Figs. 1A-1B and a repetitive description is omitted here for convenience.

As mentioned above, when the mobile IAB node 110 moves along with the vehicle on which it is mounted, the mobile IAB node may need to change its access serving node (the IAB donor 130 or the intermediate IAB node 120) . Fig. 2 and Fig. 3 illustrate two examples of mobile IAB node migration cases. Referring to Fig. 2 first, there is shown an inter-donor CU migration case where the mobile IAB node 110 migrates from domain of the source donor 130 (with or without one or more intermediate IAB nodes between the mobile IAB node 110 and the source donor 130) to domain of a target donor 140 (with or without one or more intermediate IAB nodes between the mobile IAB node 110 and the target donor 140) . Similar to the source donor 130, the target donor 140 may include a central unit (CU) 144 and one or more distributed units (DUs) 142. To migrate from the domain of the source donor 130 to the domain of the target donor 140, the mobile IAB node 110 may perform a handover procedure to establish a new RRC connection with the target donor 140 (or a descendant IAB node of the target donor 140) and migrate the backhaul links from the source donor 130 to the target donor 140. A transport network layer (TNL) connection may be set up between the m-CU 150 and the target donor DU 142 to route F1 traffic between the IAB DU 112 and the m-CU 150 via the target donor DU 142. The m-CU 150 may include a control plane (CP) 152 that has an F1-C connection with the IAB DU 112 and a user plane (UP) 154 that has an F1-U connection with the IAB DU 112. After the inter-donor CU migration, the UEs 101a connected to the mobile IAB node 110 are still serviced by the m-CU 150.

Fig. 3 illustrates an intra-donor CU inter-donor DU migration case where the mobile IAB node 110 migrates from domain of a first donor DU 132 (with or without one or more intermediate IAB nodes between the mobile IAB node 110 and the first donor DU 132) to domain of a second donor DU 136 (with or without one or more intermediate IAB nodes between the mobile IAB node 110 and the second donor DU 136) , and the first and

second donor DUs

132, 136 are under the control of the same donor CU 134. Other aspects of the intra-donor CU inter-donor DU migration are similar to the inter-donor CU migration discussed above with respect to Fig. 2, and a repetitive description thereof is omitted here for convenience.

In order to achieve service continuity for the UEs 101a connected to the mobile IAB nodes 110, it is desirable that efficient mobility of the mobile IAB node 110 can be supported in various migration cases. However, existing signaling does not support backhaul link mobility between the source and target donors or donor DUs when the m-CU 150 is used e.g. in the IAB networks shown in Figs. 1A-1C. For example, there is no signaling to indicate the m-CU 150 about the handover procedure and its phase during the IAB node mobility, and the m-CU 150 may not stop transmission to the mobile IAB node even during the handover procedure. The handover signaling between the source donor CU 134 and the target donor CU 144 does not support backhaul link DRB change, and the target donor CU 144 cannot know which DRB is used for backhaul connectivity. Moreover, in the existing handover procedure, no RLC bearer configuration information is informed by the target donor CU 144 to the m-CU-CP 152, and no indication of the m-CU-UP 154 is sent to the target donor CU 144 for UP routing. Therefore, the existing signaling and handover procedure do not support efficient mobility of the mobile IAB node 110 in the mobile IAB network where the m-CU 150 is used.

Hereinafter, various example embodiments of apparatuses, methods and computer program products supporting mobile IAB node mobility will be described in detail with reference to the accompanying drawings. The example embodiments can support efficient mobility of the mobile IAB node in diverse migration scenarios with minimized impact on the legacy base stations. The example embodiments are applicable to but not limited to example architectures shown in Figs. 1A-1C. In general, the example embodiments are applicable to mobile IAB network architectures where IAB donors provide wireless backhaul connections while a m-CU provides control plane and user plane services to UEs connected to the mobile IAB nodes. In the example embodiments, mobility of the IAB node is limited to the backhaul link and it would not affect the access UEs as long as the m-CU serving the UEs remains unchanged.

Fig. 4 is a schematic message sequence chart illustrating a procedure 200 for inter-donor mobility of a mobile IAB node according to an example embodiment of the present disclosure. The operations shown in Fig. 4 may be performed by a mobile IAB node, a source IAB donor and a target IAB donor providing RRC and backhaul connections for the mobile IAB node, and an m-CU serving the mobile IAB node and UEs connected to the mobile IAB node. The above mentioned network and terminal nodes may include a plurality of means, modules, components or elements for performing the operations discussed below, and the means, modules, components or elements may be implemented in various manners, including but not limited to software, hardware, firmware, or any combination thereof. Although not shown in Fig. 4, it would be appreciated that one or more intermediate IAB nodes may be connected between the mobile IAB node and the source donor and/or between the mobile IAB node and the target donor.

At the beginning of the inter-donor mobility procedure 200, it is assumed that the IAB MT 114 of the mobile IAB node 110 is RRC connected to the source donor CU 134 of the source donor 130 and has been configured with backhaul bearers, backhaul RLC bearers/channels, PDU sessions or QoS flows to carry F1 traffic between the m-CU 150 and the IAB DU 112, as mentioned above with respect to Figs. 1A-1C. The F1 (including F1-C and F1-U) traffic may be routed via the source donor DU 132. For example, the source donor DU 132 may map the downlink F1 traffic to a related backhaul RLC channel and relay the downlink F1 traffic to the IAB DU 112 over the wireless backhaul. The IAB DU 112 then transmits the downlink data to a destined UE (not shown) which is connected to the IAB DU 112 via an access link. The uplink F1 traffic is transmitted in a reverse direction from the IAB DU 112 to the m-CU 150. The source donor CU 134 may have an Xn interface with the m-CU 150.

The IAB MT 114 may measure neighboring cells according to measurement configuration configured by the source donor 130. The source donor 130 may configure measurement-reporting events for the IAB MT 114 to trigger measurement reporting. Referring to Fig. 4, at 210, the IAB MT 114 may send a measurement report to the source donor CU 134 when one of the configured measurement-reporting events is detected at the IAB MT 114. For example, when the IAB MT 114 detects that signal strength represented by e.g. reference signal received power (RSRP) , reference signal received quality (RSRQ) or signal to interference and noise ratio (SINR) of one or more neighboring cells is better than signal strength of the serving cell served by the source donor DU 132 by more than a threshold (measurement-reporting Event A3) , the IAB MT 114 may send the measurement report to the source donor CU 134 indicating the signal strength of the serving cell and the one or more neighboring cells. In an example, the source donor DU 132 may forward the measurement report received from the IAB MT 114 to the source donor CU 134.

In response to the measurement report received from the IAB MT 114, the source donor CU 134 may decide at 212 to hand over the IAB node 110 from the source donor 130 to the target donor 140. When the measurement report includes indication of more than one neighboring cell as handover candidate, the source donor CU 134 may select for example the best/strongest neighboring cell for the handover of the IAB node 110. Although the measurement report is described here as an example event to trigger the handover decision, it would be appreciated that the handover decision may also be triggered by other events and the present disclosure is not limited to any particular trigger for the handover decision. At 214, the source donor CU 134 may send a handover request to the target donor CU 144 via an Xn application protocol (XnAP) message. If there is no Xn connection between the source donor CU 134 and the target donor CU 144, the source donor CU 134 may perform an Xn setup procedure to establish the Xn connection with the target donor CU 144 before the source donor CU 134 sends the handover request to the target donor CU 144.

The handover request may include information associated with wireless backhaul of the IAB node 110, in addition to legacy information such as target cell ID, UE (IAB MT) XnAP ID, handover cause, UE context and the like for the handover of the IAB node 110. In some example embodiments, the handover request may include configuration information indicative of backhaul configuration for the IAB node 110. For example, the backhaul configuration for the IAB node 110 may include configuration of one or more of a radio bearer (s) , a RLC bearer (s) , a PDU session (s) and a QoS flow (s) for backhaul connections of the IAB node 110. The handover request may explicitly or implicitly indicate which radio bearer (s) , RLC bearer (s) , PDU session (s) and/or QoS flow (s) are used for backhaul connections of the IAB node 110. In some example embodiments, the handover request may include an indication of the m-CU 150 which controls the IAB node 110 and the UEs 101a connected to the IAB node 110. For example, the indication of the m-CU 150 may include an identifier (ID) or address (e.g. IP address) of the control plane 152 of the m-CU 150 and/or an identifier or address (e.g. IP address) of the user plane 154 of the m-CU 150. Alternatively or additionally, the indication of the m-CU 150 may also include other information for example an index, a series number and the like pre-configured at the source donor 130 and the target donor 140 to identify the control plane 152 and the user plane 154 of the m-CU 150.

When the handover procedure for the IAB node 110 is initiated at 214, optionally the source donor CU 134 may send at 216 an early/first handover indication to the m-CU-CP 152 to inform the m-CU 150 that the IAB node 110 would be handed over to the target donor 140. The early handover indication may include an indicator indicative of the current phase of the handover. The early handover indication may further include information associated with the IAB node 110 and the target donor 140 so that the m-CU-CP 152 can be aware of which target donor the IAB node 110 would be handed over to. For example, the early handover indication may include an identifier of the IAB node 110 and an identifier of the target cell or the target donor DU 142 supporting the target cell. In an example, the early handover indication may further include an identifier of the target donor CU 144 associated with the target donor DU 142. In some example embodiments, the m-CU 150 may check if an Xn connection exists between the m-CU-CP 152 and the target donor CU 144. If no Xn connection exists, the m-CU 150 may initiate an Xn setup procedure to establish the Xn connection between the m-CU-CP 152 and the target donor CU 144.

It would be appreciated that the early handover indication may also be sent to the m-CU 150 at other times or occasions. For example, the source donor CU 134 may send the early handover indication to the m-CU-CP 152 when the source donor CU 134 receives the measurement report that triggers the handover procedure from the IAB node 110. With the early handover indication, the m-CU 150 can know which target donor the IAB node 110 is going to be handed over to and establish a connection with the target donor in a timely manner.

In response to the handover request received at 214, the target donor 140 may perform admission control at 218 to determine whether it can accommodate the IAB node 110. The target donor 140 may allocate resources for the IAB node 110 while taking into account the information received in the handover request. When the resources are available at the target donor 140 for the IAB node 110, the target donor 140 may admit the handover request. Otherwise, the target donor 140 may reject the handover request.

When the handover request is admitted at 218, the target donor CU 144 may send at 220 a UE (IAB MT) context setup request message to the target donor DU 142 to create UE context and configure backhaul link for the IAB MT 114. The UE context setup request may contain configuration of radio bearers (e.g. SRB and DRB) or backhaul RLC bearers for the backhaul connection between the IAB node 110 and the target donor 140, which may be determined based on the backhaul configuration received in the handover request from the source donor CU 134. In some example embodiments, the target donor CU 144 may also cooperate with the core network (not shown) to configure PDU sessions and QoS flows for the backhaul links of the IAB node 110. At 222, the target donor DU 142 may respond with a UE context setup response message.

At 224, the target donor CU 144 may send a handover acknowledgement to the source donor CU 134 in response to the handover request received at 214. The handover acknowledgement message may include a transparent container comprising RRC configuration information required for the IAB MT 114 to access the target cell as a part of a handover command. In some example embodiments, the RRC configuration information may include backhaul configuration for the IAB node 110, e.g. configuration of radio bearers (e.g. SRB and DRB) , backhaul RLC bearers, PDU sessions and/or QoS flows for the backhaul link of the IAB node 110. In some example embodiments, the RRC configuration information may include one or more new transport network layer (TNL) addresses (e.g. IP addresses) assigned by the target donor CU 144 to the IAB DU 112.

In some example embodiments, the target donor 140 may check if an Xn connection is available between the target donor 140 and the m-CU 150. As discussed above, the target donor 140 may receive the indication of the m-CU 150 via the handover request message. If there is no Xn connection between the target donor 140 and the m-CU 150, the target donor 140 may initiate an Xn setup procedure to set up the Xn connection with the m-CU 150 at 226. In some example embodiments, the m-CU 150 may initiate the Xn setup procedure when it receives the identifier of the target donor CU 144 in the early handover indication received from the source donor 130, as discussed above.

At 228, the target donor CU 144 may send a second handover indication to the m-CU 150 to indicate the current phase of the handover procedure for the IAB node 110. The second handover indication may be transmitted via the Xn connection between the target donor CU 144 and the m-CU 150. Similar to the early/first handover indication sent from the source donor 130 to the m-CU 150, the second handover indication may include, in addition to the indicator indicative of the current phase of the handover procedure, information associated with the IAB node 110 and the target donor 140 so that the m-CU-CP 152 can be aware of which target donor the IAB node 110 would be handed over to. For example, the second handover indication may include an identifier of the IAB node 110, an identifier of the target cell or the target donor DU 142 supporting the target cell, and an identifier of the target donor CU 144 associated with the target donor DU 142. In some example embodiments, the second handover indication may further include transport configuration associated with the target donor DU 142. For example, the transport configuration may include TNL parameters such as a TNL address (i.e. IP address) , a tunnel endpoint identifier (TEID) , and usage (for F1-C, F1-U or both) of the TNL address and TEID, which may be used for UP and/or CP data transmissions between the m-CU 150 and the IAB DU 112.

Although Fig. 4 shows the second handover indication is sent at 228 when the target donor CU 144 transmits the handover acknowledgement to the source donor CU 134 at 224, the second handover indication may also be sent at other times/occasions. For example, the target donor CU 144 may send the second handover indication to the m-CU 150 when it receives the handover request from the source donor CU 134 at 214.

When the source donor CU 134 receives the handover acknowledgement from the target donor CU 144, the source donor CU 134 may send at 230 an RRC reconfiguration message comprising a handover command to the IAB MT 114. As discussed above, the handover command may include RRC configuration information required for the IAB MT 114 to access the target cell, backhaul configuration for the IAB node 110, and the new TNL addresses assigned to the IAB DU 112.

At 232, the source donor CU 134 may send to the m-CU 150 a third handover indication indicative of current phase in the handover procedure. The third handover indication may be sent when the source donor CU 134 receives the handover acknowledgement from the target donor CU 144 at 224 and/or when the source donor CU 134 sends the handover command to the IAB MT 114 at 230, and the third handover indication may include an indicator to indicate the current handover phase. In some example embodiments, the third handover indication may further include an identifier of the IAB node 110, an identifier of the target cell or the target donor DU 142 supporting the target cell, and an identifier of the target donor CU 144 associated with the target donor DU 142.

Responsive to the third handover indication indicating that the source donor CU 134 has received the handover acknowledgement from the target donor CU 144 or sent the handover command to the IAB node 110, the m-CU 150 may suspend at 234 downlink transmission to the IAB node 110 via the source donor 130. For example, the m-CU-CP 152 may pause F1-C signaling to the IAB node 110 via the source donor 130 because the RRC connection between the IAB node 110 and the source donor 130 may have poor quality or not be available any longer, and instruct the m-CU-UP 154 to suspend F1-U data transmission. Upon receiving the instruction, the m-CU-UP 154 may start buffering UP data for the IAB node 110.

Although Fig. 4 shows that the m-CU 150 suspends the transmission to the IAB node 110 in response to the third handover indication, the present disclosure is not limited to the embodiment. For example, the m-CU 150 may suspend the transmission to the IAB node 110 when it receives the early/first handover indication from the source donor 130 or when it receives the second handover indication from the target donor 140. In another example, the m-CU 150 may suspend the transmission to the IAB node 110 when it receives the earliest handover indication associated with the IAB node 110 from the source donor 130 or the target donor 140.

When the IAB MT 114 receives the handover command from the source donor 130, the IAB MT 114 may initiate a random access (RA) procedure to the target donor DU 142 at 236. With the RRC configuration received in the handover command message, a legacy RA procedure may be performed for the IAB MT 114 to connect to the target donor DU 142. The IAB MT 114 may further set up radio bearers, backhaul RLC bearers, PDU sessions and/or QoS flows for the backhaul links. When the IAB MT 114 is connected to the target donor DU 142, the IAB MT 114 may send an RRC message indicating handover completion to the target donor CU 144 at 238. Although not shown, the target donor CU 144 may instruct the source donor CU 134 to release UE (IAB MT) context of the IAB MT 114 when the handover procedure is completed.

At 240, the target donor CU 144 may indicate the m-CU-CP 152 about completion of the handover procedure for the IAB node 110. From the indication, the m-CU-CP 152 knows that the IAB node 110 has connected to the target donor 140, and a new path between the IAB node 110 and the m-CU 150 via the target donor 140 may be configured for transmissions between the IAB node 110 and the m-CU 150. In some example embodiments, the target donor CU 144 may also send transport configuration comprising TNL parameters associated with the target donor DU 142 to the m-CU-CP 152 at 240.

Then at 242, the m-CU 150, the target donor 140 and the IAB node 110 may reconfigure the transport connection between the m-CU 150 and the IAB node 110 and resume the F1-C traffic between the m-CU 150 and the IAB node 110 via the target donor DU 142.

Fig. 5 illustrates an example procedure 300 for reconfiguring the transport connection according to an example embodiment of the present disclosure, which may be performed at the step 242 in the procedure 200 shown in Fig. 4. Referring to Fig. 5, the IAB DU 112 may send at 310 a gNB DU configuration update message to the m-CU-CP 152 to set up a new SCTP association with the m-CU-CP 152. This message may include the new TNL addresses assigned to the IAB DU 112 for F1-C and F1-U tunnels. The m-CU-CP 152 may respond to the IAB DU 112 with a gNB DU configuration update acknowledge message at 312 to acknowledge receipt of the configuration update.

At 314, the m-CU-CP 152 may send an IAB transport migration management request message to request the target donor CU 144 to support the F1 traffic to be transferred via the target donor 140. This message may include F1 traffic related configuration e.g. backhaul information for the target donor DU 142. The target donor CU 144 may respond to the m-CU-CP 152 with an IAB transport migration management response message at 316, which may include the new TNL address (es) anchored in the target donor DU 142 for the requested F1 traffic. Then, the F1-C traffic may be resumed at 318 between the IAB node 110 and the m-CU-CP 152 via the target donor 140 (i.e., the target donor DU 142) .

Referring back to Fig. 4, as discussed above, the target donor 140 configures the backhaul link for the IAB node 110 based on the backhaul configuration received in the handover request. Optionally, if the target donor 140 wants to change the backhaul link (e.g., to support the requested F1 traffic) , the target donor CU 144 may send at 244 an RRC reconfiguration message to the IAB MT 114 to, for example, add, remove or modify a radio bearer, a backhaul RLC bearer, a backhaul RLC channel, a PDU session or a QoS flow used for the backhaul link. At 246, the IAB MT 114 may respond to the target donor CU 144 with an RRC reconfiguration complete message to acknowledge that it has successfully updated the backhaul configuration.

At 248, the m-CU-CP 152 may reconfigure the m-CU-UP 154 with the new TNL parameters associated with the target donor DU 142 for the F1-U transmission between the IAB node 110 and the m-CU-UP 154. Then the F1-U traffic may be resumed between the m-CU-UP 154 and the IAB DU 112 via the target donor 140 (i.e., the target donor DU 142) at 250. At this point, the IAB node 110 successfully migrates to the target donor 140 and it can transmit/receive data to/from the m-CU 150 on F1 interface via the target donor 140. For example, downlink data is routed from the m-CU-UP 154 to the target donor DU 142. The target donor DU 142 may perform the traffic mapping to a related backhaul RLC channel and relays the downlink data to the IAB DU 112 over wireless backhaul. The uplink data is transmitted in a reverse direction from the IAB DU 112 to the m-CU-UP 154.

In the procedure 200 discussed above, the backhaul configuration associated with the IAB node 110 is transferred from the source donor 130 to the target donor 140 so that the target donor 140 can configure backhaul links for the IAB node 110 in an efficient manner during the handover procedure. The source donor 130 also informs the target donor 140 of information of the m-CU 150 controlling the IAB node 110, and the target donor 140 may establish an Xn connection with the m-CU 150 and send TNL parameters to the m-CU 150. It would help to switch the F1 traffic between the IAB node 110 and the m-CU 150 to the new path via the target donor 140. The m-CU 150 can further receive handover indications from the source donor 130 and/or the target donor 140. From the handover indications the m-CU 150 can be aware of current phase of the handover procedure and it can suspend and resume transmissions between the m-CU 150 and the IAB node 110 in a timely manner. It helps to hand over the IAB node 110 efficiently and maintain service continuity for UEs connected to the IAB node 110. In addition, mobility of the IAB node 110 is limited to the backhaul link, and it would not affect the UEs connected to the IAB node 110 because the m-CU 150 for controlling the IAB node 110 and the connected UEs is not changed before and after the handover procedure.

Fig. 6 shows a flowchart of an example method 400 for inter-donor mobility of an IAB node in accordance with an example embodiment of the present disclosure. The method 400 can be implemented at a source IAB donor e.g. the source IAB donor 130 discussed above. It would be understood that steps illustrated in dashed-line blocks represent optional steps and they can be omitted in some example embodiments. In some example embodiments, the method 400 may further include one or more steps that are performed at the source IAB donor 130 as described above with respect to Fig. 4. It would also be understood that details of some steps in the procedure 400 have been discussed above with respect to Fig. 4 and the procedure 400 will be described here in a simple manner.

At block 410, the source donor 130 may decide to hand over an IAB node 110 from the source donor 130 to a target donor 140, for example based on a measurement report received from the IAB node 110.

At block 420, the source donor 130 may send to the target donor 140 a handover request to hand over the IAB node 110 to the target donor 140. The handover request may comprise configuration information indicative of backhaul configuration of the IAB node and/or an indication of a m-CU 150 serving one or more UEs connected to the IAB node 110.

In some example embodiments, the backhaul configuration may comprise configuration of at least one of a radio bearer, a RLC bearer, a PDU session, and QoS flow (s) for a backhaul connection of the IAB node 110. The indication of the m-CU 150 may comprise an identifier or address of a control plane 152 of the m-CU 150 and/or an identifier or address of a user plane 154 of the m-CU 150.

At block 430, the source donor 130 may receive an acknowledge message responsive to the handover request from the target donor 140.

At block 440, the source donor 130 may send a first handover indication to the m-CU 150. The first handover indication may indicate current phase of a handover procedure for the IAB node 110. In some example embodiments, the first handover indication may be sent when the source donor 130 receives the measurement report from the IAB node 110, when the source donor 130 sends the handover request to the target donor 140, when the source donor 130 receives the handover acknowledgement from the target donor 140, or when the source donor 130 sends a handover command to the IAB node 110. In some example embodiments, the first handover indication may comprise information associated with the target donor 140. For example, the first handover indication may comprise an identifier of the target cell or the target donor DU 142 supporting the target cell, and an identifier of the target donor CU 144 associated with the target donor DU 142. The first handover indication may further comprise an identifier of the IAB node 110 to be handed over.

Fig. 7 shows a flowchart of an example method 500 for inter-donor mobility of an IAB node in accordance with an example embodiment of the present disclosure. The method 500 can be implemented at a target IAB donor e.g. the target IAB donor 140 discussed above. It would be understood that steps illustrated in dashed-line blocks represent optional steps and they can be omitted in some example embodiments. In some example embodiments, the method 500 may further include one or more steps that are performed at the target IAB donor 140 as described above with respect to Fig. 4. It would also be understood that details of some steps in the procedure 500 have been discussed above with respect to Fig. 4 and the procedure 500 will be described here in a simple manner.

At block 510, the target donor 140 may receive from a source donor 130 a handover request to hand over an IAB node 110 from the source donor 130 to the target donor 140. The handover request may comprise configuration information indicative of backhaul configuration of the IAB node and/or an indication of a m-CU 150 serving one or more UEs connected to the IAB node 110.

In some example embodiments, the backhaul configuration may comprise configuration of at least one of a radio bearer, a RLC bearer, a PDU session, and a QoS flow for backhaul connection of the IAB node 110. The indication of the m-CU 150 may comprise an identifier or address of a control plane 152 of the m-CU 150 and/or an identifier or address of a user plane 154 of the m-CU 150.

At block 520, the target donor 140 may send an acknowledgement for the handover request to the source donor 130.

At block 530, the target donor 140 may establish a connection e.g. Xn connection with the m-CU 150.

At block 540, the target donor 140 may send a second handover indication to the m-CU 150. The second handover indication may indicate current phase of the handover procedure for the IAB node 110.

In some example embodiments, the second handover indication may be sent when the target donor 140 receives the handover request from the source donor 130, when the target donor 140 sends the acknowledgement for the handover request to the source donor 130, or when the target donor 140 receives a handover complete message from the IAB node 110.

At block 550, the target donor 140 may send transport configuration comprising TNL parameters associated with the target donor 140 to the m-CU 150. In some example embodiments, the target donor 140 may send the transport configuration in the second handover indication to the m-CU 150. In some other example embodiments, the target donor 140 may send the transport configuration in a separate message e.g. an IAB transport migration management response message or an IAB transport migration modification request message to the m-CU 150.

Fig. 8 shows a flowchart of an example method 600 for inter-donor mobility of an IAB node in accordance with an example embodiment of the present disclosure. The method 600 can be implemented at a central node e.g. the m-CU 150 discussed above. It would be understood that steps illustrated in dashed-line blocks represent optional steps and they can be omitted in some example embodiments. In some example embodiments, the method 600 may further include one or more steps that are performed at the m-CU 150 as described above with respect to Fig. 4. It would also be understood that details of some steps in the procedure 600 have been discussed above with respect to Fig. 4 and the procedure 600 will be described here in a simple manner.

At block 610, the m-CU 150 may receive from a source donor 130 and/or a target donor 140 an indication indicative of handover of an IAB node 110 from the source donor 130 to the target donor 140.

In some example embodiments, the handover indication comprises a first indication received from the source donor 130 and/or a second indication received from the target donor 140. The first indication may indicate that a measurement report triggering the handover of the IAB node 110 is received at the source donor 130, a handover request is sent from the source donor 130 to the target donor 140, an acknowledge message responsive to the handover request is received at the source donor 130 from the target donor 140, or a handover command is sent from the source donor 130 to the IAB node 110. The second indication may indicate that the handover request is received at the target donor 140, the acknowledge message responsive to the handover request is sent from the target donor 140 to the source donor 130, or a handover complete message is received at the target donor 140 from the IAB node 110.

At block 620, the m-CU 150 may suspend transmission between the m-CU 150 and the IAB node 110 via the source donor 130 in response to the handover indication received from the source donor 130 or the target donor 140. In an example, the m-CU 150 may suspend transmission between the m-CU 150 and the IAB node 110 via the source donor 130 in response to the handover indication that the handover command is sent from the source donor 130 to the IAB node 110. In another example, the m-CU 150 may suspend transmission between the m-CU 150 and the IAB node 110 via the source donor 130 in response to the earliest handover indication received from the source donor 130 or the target donor 140.

At block 630, the m-CU 150 may receive transport configuration comprising TNL parameters from the target donor 140. In some example embodiments, the transport configuration may be received in the second handover indication from the target donor 140. In some other example embodiments, the transport configuration may be received in a separate message e.g. an IAB transport migration management response message or an IAB transport migration modification request message from the target donor 140.

At block 640, the m-CU 150 may resume transmission between a control plane 152 of the m-CU 150 and the IAB node 110 via the target donor 140 at least partially based on the received transport configuration.

At block 650, the m-CU 150 may reconfigure a user plane 154 of the m-CU 150 for transmission between the m-CU-UP 154 and the IAB node 110 based on the received transport configuration.

At block 660, the m-CU 150 may resume transmission between the m-CU-UP 154 and IAB node 110 via the target donor 140.

Fig. 9 is a schematic message sequence chart illustrating a procedure 700 for intra-donor CU inter-donor DU mobility of a mobile IAB node according to an example embodiment of the present disclosure. The operations shown in Fig. 9 may be performed by a mobile IAB node, an IAB donor providing RRC and backhaul connections for the mobile IAB node, and an m-CU serving the mobile IAB node and UEs connected to the mobile IAB node. The above mentioned network and terminal nodes may include a plurality of means, modules, components or elements for performing the operations discussed below, and the means, modules, components or elements may be implemented in various manners, including but not limited to software, hardware, firmware, or any combination thereof. Although not shown in Fig. 9, it would be appreciated that one or more intermediate IAB nodes may be connected between the mobile IAB node and the IAB donor.

It would be appreciated that the intra-donor CU inter-donor DU mobility procedure 700 comprises a subset of signalings/messages in the inter-donor mobility procedure 200 because signalings/messages between source and target donor CUs are not required in the intra-donor CU inter-donor DU mobility procedure 700. In other words, signalings/messages of the intra-donor CU inter-donor DU mobility procedure 700 are similar to those included in the inter-donor mobility procedure 200. Therefore, the intra-donor CU inter-donor DU mobility procedure 700 will be described here in a simple manner, and some details of steps in the procedure 700 may refer to the above description of the procedure 200 with respect to Fig. 4.

At the beginning of the intra-donor CU inter-donor DU mobility procedure 700, it is assumed that the IAB MT 114 of the mobile IAB node 110 is RRC connected to a source cell served by a source/first donor DU 132 associated with a source donor CU 134 of the IAB donor 130 and has been configured with backhaul bearers, backhaul RLC bearers/channels, PDU sessions or QoS flows to carry F1 traffic between the m-CU 150 and the IAB DU 112, as mentioned above with respect to Figs. 1A-1C. The F1 (including F1-C and F1-U) traffic may be routed via the first donor DU 132. For example, the first donor DU 132 may map the downlink F1 traffic to a related backhaul RLC channel and relay the downlink F1 traffic to the IAB DU 112 over the wireless backhaul. The IAB DU 112 then transmits the downlink data to a destined UE (not shown) which is connected to the IAB DU 112 via an access link. The uplink F1 traffic is transmitted in a reverse direction from the IAB DU 112 to the m-CU 150 via the first donor DU 132. The IAB donor CU 134 may have an Xn interface with the m-CU 150.

At 710, the IAB MT 114 may send a measurement report to the donor CU 134 via the first donor DU 132. The measurement report may indicate signal strength of a cell supported by the second donor DU 136.

In response to the measurement report, the donor CU 134 may decide at 712 to hand over the IAB node 110 from the first donor DU 132 to the second donor DU 136. Although the measurement report is described here as an example event to trigger the handover decision, it would be appreciated that the handover decision may also be triggered by other events and the present disclosure is not limited to any particular trigger for the handover decision. The donor CU 134 may send at 714 a UE (IAB MT) context setup request message to the second donor DU 136 to create UE context and configure backhaul link for the IAB MT 114. The UE context setup request may contain configuration of radio bearers (e.g. SRB and DRB) or backhaul RLC bearers for the backhaul connection of the IAB node 110. In some example embodiments, the donor CU 134 may also cooperate with the core network (now shown) to configure PDU sessions and QoS flows for the backhaul links of the IAB node 110. At 716, the second donor DU 136 may respond to the donor CU 134 with a UE context setup response message.

At 718, the donor CU 134 may send an RRC reconfiguration message comprising a handover command to the IAB MT 114. The handover command may include RRC configuration information required for the IAB MT 114 to connect to the second donor DU 136, backhaul configuration for the IAB node 110, and the new TNL addresses assigned to the IAB DU 112.

At 720, the donor CU 134 may send a handover indication to the m-CU-CP 152 to inform the m-CU 150 of the ongoing mobility procedure. The handover indication may comprise an indicator indicative of current phase of the handover procedure and information associated with the second donor DU 136 and the IAB node 110 so that the m-CU-CP 152 can be aware of which donor DU the IAB node 110 would be handed over to. In some example embodiments, the handover indication may further include transport configuration associated with the second donor DU 136. For example, the transport configuration may include TNL parameters such as a TNL address (i.e. IP address) , a tunnel endpoint identifier (TEID) , and usage (for F1-C, F1-U or both) of the TNL address and TEID, which may be used for UP and/or CP data transmissions between the m-CU 150 and the IAB DU 112 via the second donor DU 136. Although Fig. 9 shows the donor CU 134 sends the handover indication when the handover command is sent to the IAB node 110, it would be appreciated that the donor CU 134 may also send the handover indication when it receives the measurement report that triggers the handover of the IAB node 110 and/or at other times/occasions as discussed below.

Responsive to the handover indication, the m-CU 150 may suspend at 722 downlink transmission to the IAB node 110 via the first donor DU 132. For example, the m-CU-CP 152 may pause F1-C signaling to the IAB node 110 because the RRC connection between the IAB node 110 and the first donor DU 132 may have poor quality or not be available any longer. In addition, the m-CU-CP 152 may instruct the m-CU-UP 154 to suspend F1-U transmission to the IAB node 110. Upon receiving the instruction, the m-CU-UP 154 may start buffering UP data for the IAB node 110.

When the IAB MT 114 receives the handover command from the IAB donor CU 134, the IAB MT 114 may initiate a random access (RA) procedure to the second donor DU 136 at 724. With the RRC configuration received in the handover command message, a legacy RA procedure may be performed for the IAB MT 114 to connect to the second donor DU 136. The IAB MT 114 may further set up radio bearers, backhaul RLC bearers, PDU sessions and/or QoS flows for the backhaul links. When the IAB MT 114 is connected to the second donor DU 136, the IAB MT 114 may send a handover complete message to the IAB donor CU 134 at 726.

At 728, the IAB donor CU 134 may send a handover indication to the m-CU-CP 152 indicating that the handover of the IAB node 110 is successfully completed. From the indication, the m-CU-CP 152 knows that the IAB node 110 has connected to the second donor DU 136, and a new path between the IAB node 110 and the m-CU 150 via the second donor DU 136 may be configured for transmissions between the IAB node 110 and the m-CU 150. In some example embodiments, the IAB donor CU 134 may also send transport configuration comprising TNL parameters associated with the second donor DU 136 to the m-CU-CP 152 at the step 728.

At 730, the transport connection between the m-CU 150 and the IAB node 110 may be reconfigured so that the F1 traffic between the m-CU 150 and the IAB node 110 can be resumed via the second donor DU 136. The step 730 may be similar to the procedure 300 discussed above with respect to Fig. 5 except that operations performed by the target donor CU 144 in the procedure 300 are performed at the IAB donor CU 134 here. For example, the IAB DU 112 may use the new TNL address (e.g. received at 718) to set up a new SCTP association with the m-CU-CP 152. The IAB DU 112 may also report its new TNL address for F1-U to the m-CU-CP 152. The m-CU-CP 152 may send an IAB transport migration management request message to the IAB donor CU 134 and request the IAB donor CU 134 to support the F1 traffic to be transferred via the second donor DU 136. This message may include F1 traffic related configuration e.g. backhaul information for the second donor DU 136. The IAB donor CU 134 may respond to the m-CU-CP 152 with an IAB transport migration management response message which may include the new TNL address (es) anchored in the second donor DU 136 for the requested F1 traffic. Then, the F1-C traffic may be resumed between the IAB node 110 and the m-CU-CP 152 via the second donor DU 136.

Optionally, if the IAB donor CU 134 wants to change the backhaul link (e.g., to support the requested F1 traffic) , the IAB donor CU 134 may send at 732 an RRC reconfiguration message to the IAB MT 114 to, for example, add, remove or modify a radio bearer, a backhaul RLC bearer, a backhaul RLC channel, a PDU session or a QoS flow used for the backhaul link. At 734, the IAB MT 114 may respond to the IAB donor CU 134 with an RRC reconfiguration complete message to acknowledge that it has successfully updated the backhaul configuration.

At 736, the m-CU-CP 152 may reconfigure the m-CU-UP 154 with the new TNL parameters associated with the second donor DU 136 for the F1-U transmission between the IAB node 110 and the m-CU-UP 154. Then the F1-U traffic may be resumed between the m-CU-UP 154 and the IAB DU 112 via the second donor DU 136 at 738. At this point, the IAB node 110 successfully migrates to the second donor DU 136 and it can transmit/receive data to/from the m-CU 150 on F1 interface via the second donor DU 136.

Fig. 10 shows a flowchart of an example method 800 for intra-donor CU inter-donor DU mobility of an IAB node in accordance with an example embodiment of the present disclosure. The method 800 may be implemented at an IAB donor e.g. the IAB donor 130 discussed above. It would be understood that steps illustrated in dashed-line blocks represent optional steps and they can be omitted in some example embodiments. In some example embodiments, the method 800 may further include one or more steps that are performed at the IAB donor 130 as described above with respect to Fig. 9. It would also be understood that details of some steps in the procedure 800 have been discussed above with respect to Fig. 9 and the procedure 800 will be described here in a simple manner.

At block 810, the IAB donor 130 may decide to hand over the IAB node 110 from a first donor DU 132 to a second donor DU 136, for example based on a measurement report received from the IAB node 110. The first donor DU 132 and the second donor DU 136 are associated to a donor CU 134 of the IAB donor 130.

At block 820, the IAB donor130 may send a handover command to the IAB node 110. The handover command may include RRC configuration information required for the IAB node 110 to connect to the second donor DU 136, backhaul configuration for the IAB node 110, and new TNL addresses assigned to the IAB node 110.

At block 830, the IAB donor 130 may send an indication indicative of the handover of the IAB node 110 to the m-CU 150. The handover indication may comprise an indicator indicative of current phase of the handover procedure and information associated with the second donor DU 136 and the IAB node 110 so that the m-CU 150 can be aware of which donor DU the IAB node 110 would be handed over to. In some example embodiments, the handover indication may further include transport configuration associated with the second donor DU 136. For example, the transport configuration may include TNL parameters such as a TNL address (i.e. IP address) , a tunnel endpoint identifier (TEID) , and usage (for F1-C, F1-U or both) of the TNL address and TEID, which may be used for UP and/or CP data transmissions between the m-CU 150 and the IAB node 110 via the second donor DU 136.

In some example embodiments, the handover indication may be sent when the IAB donor 130 receives the measurement report from the IAB node 110, when the IAB donor 130 sends the handover command to the IAB node 110, or when the IAB donor 130 receives a handover complete message from the IAB node 110.

At block 840, the IAB donor 130 may send transport configuration comprising TNL parameters associated with the second donor DU 136 to the m-CU 150. In some example embodiments, the IAB donor 130 may send the transport configuration in the handover indication to the m-CU 150. In some other example embodiments, the IAB donor 130 may send the transport configuration in a separate message e.g. an IAB transport migration management response message or an IAB transport migration modification request message to the m-CU 150.

Fig. 11 shows a flowchart of an example method 900 for intra-donor CU inter-donor DU mobility of an IAB node in accordance with an example embodiment of the present disclosure. The method 900 can be implemented at a central node e.g. the m-CU 150 discussed above. It would be understood that steps illustrated in dashed-line blocks represent optional steps and they can be omitted in some example embodiments. In some example embodiments, the method 900 may further include one or more steps that are performed at the m-CU 150 as described above with respect to Fig. 9. It would also be understood that details of some steps in the procedure 900 have been discussed above with respect to Fig. 9 and the procedure 900 will be described here in a simple manner.

At block 910, the m-CU 150 may receive from an IAB donor 130 an indication indicative of handover of an IAB node 110 from a first donor DU 132 to a second donor DU 136. The first donor DU 132 and the second donor DU 136 are associated with a donor CU 134 of the IAB donor 130.

The handover indication may comprise an indicator indicative of current phase of the handover procedure associated with the IAB node 110. In some example embodiments, the handover indication may indicate a measurement report triggering the handover of the IAB node 110 is received at the IAB donor 130, a handover command is sent from the IAB donor 130 to the IAB node 110, or a handover complete message is received at the IAB donor 130 from the IAB node 110.

At block 920, the m-CU 150 may suspend transmission between the m-CU 150 and the IAB node 110 via the first donor DU 132 in response to the handover indication. In an example embodiment, the m-CU 150 may suspend the transmission between the m-CU 150 and the IAB node 110 in response to the handover indication that the handover command is sent from the IAB donor 130 to the IAB node 110. In another example embodiment, the m-CU 150 may suspend the transmission between the m-CU 150 and the IAB node 110 in response to the earliest handover indication received from the IAB donor 130.

At block 930, the m-CU 150 may receive from the IAB donor 130 transport configuration comprising TNL parameters for the second donor DU 136. In some example embodiments, the transport configuration may be received in the handover indication from the IAB donor 130. In some other example embodiments, the transport configuration may be received in a separate message e.g. an IAB transport migration management response message or an IAB transport migration modification request message from the IAB donor 130.

At block 940, the m-CU 150 may resume transmission between a control plane 152 of the m-CU 150 and the IAB node 110 via the second donor DU 136 at least partially based on the received transport configuration.

At block 950, the m-CU 150 may reconfigure a user plane 154 of the m-CU 150 for transmission between the m-CU-UP 154 and the IAB node 110 based on the received transport configuration.

At block 960, the m-CU 150 may resume transmission between the m-CU-UP 154 and IAB node 110 via the second donor DU 136.

Fig. 12 is a schematic block diagram illustrating devices in a communication system 1000 in which example embodiments of the present disclosure can be implemented. As shown in Fig. 12, the communication system 1000 may comprise a first network device 1100 which may be implemented as the mobile IAB node 110 discussed above, a second network device 1200 which may be implemented as the IAB source donor 130 and/or the IAB target donor 140 discussed above, and a third network device 1300 which may be implemented as the m-CU 150 discussed above.

Referring to Fig. 12, the first network device 1100 may comprise one or more processors 1111, one or more memories 1112 and one or more transceivers 1113 interconnected through one or more buses 1114. The one or more buses 1114 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 1113 may comprise a receiver and a transmitter, which are connected to one or more antennas 1116. The first network device 1100 may wirelessly communicate with the second network device 1200 and one or more UEs (not shown) through the one or more antennas 1116. The one or more memories 1112 may include computer program code 1115. The one or more memories 1112 and the computer program code 1115 may be configured to, when executed by the one or more processors 1111, cause the first network device 1100 to perform operations and procedures relating to the mobile IAB node 110 as described above.

The second network device 1200 may comprise one or more processors 1211, one or more memories 1212, one or more transceivers 1213 and one or more network interfaces 1217 interconnected through one or more buses 1214. The one or more buses 1214 may be address, data, or control buses, and may include any interconnection mechanism such as a series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 1213 may comprise a receiver and a transmitter, which are connected to one or more antennas 1216. The second network device 1200 may operate as a base station and wirelessly communicate with the first network device 1100 and one or more UEs (not shown) through the one or more antennas 1216. The one or more network interfaces 1217 may provide wired or wireless communication links through which the second network device 1200 may communicate with other network devices, entities, elements or functions. The second network device 1200 may communicate with the third network device 1300 via a connection 1218. The one or more memories 1212 may include computer program code 1215. The one or more memories 1212 and the computer program code 1215 may be configured to, when executed by the one or more processors 1211, cause the second network device 1200 to perform operations and procedures relating to the IAB source donor 130 and/or the IAB target donor 140.

The third network device 1300 may comprise one or more processors1311, one or more memories 1312, and one or more network interfaces 1317 interconnected through one or more buses 1314. The one or more buses 1314 may be address, data, or control buses, and may include any interconnection mechanism such as a series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The third network device 1300 may operate as a RAN node e.g. a central node and wired or wirelessly communicate with the second network device 1200 through one or more links. The one or more network interfaces 1317 may provide wired or wireless communication links through which the third network device 1300 may communicate with other network devices, entities, elements or functions. The one or more memories 1312 may include computer program code 1315. The one or more memories 1312 and the computer program code 1315 may be configured to, when executed by the one or more processors 1311, cause the third network device 1300 to perform operations and procedures relating to the m-CU 150 as described above.

The one or

more processors

1111, 1211 and 1311 discussed above may be of any appropriate type that is suitable for the local technical network, and may include one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP) , one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . The one or

more processors

1111, 1211 and 1311 may be configured to control other elements of the network devices and operate in cooperation with them to implement the procedures discussed above.

The one or

more memories

1112, 1212 and 1312 may include at least one storage medium in various forms, such as a volatile memory and/or a non-volatile memory. The volatile memory may include but not limited to for example a random access memory (RAM) or a cache. The non-volatile memory may include but not limited to for example a read only memory (ROM) , a hard disk, a flash memory, and the like. Further, the one or

more memories

1112, 1212 and 1312 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.

It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and/or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-Specific Integrated Circuits (ASICs) , Application-Specific Standard Products (ASSPs) , System-on-Chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , etc.

Some exemplary embodiments further provide computer program code or instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The computer program code for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The computer program code may be provided to one or more processors or controllers of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

Some exemplary embodiments further provide a computer program product or a computer readable medium having the computer program code or instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the subject matter has been described in a language that is specific to structural features and/or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims.

Claims

A first radio access network node comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the first radio access network node at least to:

send, to a second radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

receive, from the second radio access network node, an acknowledge message responsive to the handover request.
The first radio access network node of claim 1 wherein the backhaul configuration comprises configuration of at least one of a radio bearer, a radio link control (RLC) bearer, a protocol data unit (PDU) session and a quality of service (QoS) flow for a backhaul connection of the integrated access and backhaul node, and/or

the indication of the central node comprises an identifier or address of a control plane of the central node and/or an identifier or address of a user plane of the central node.
The first radio access network node of claim 1 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the first radio access network node at least to:

send, to the central node, a first indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.
The first radio access network node of claim 3 wherein the first indication is sent when

the first radio access network node receives from the integrated access and backhaul node a measurement report triggering the handover of the integrated access and backhaul node,

the first radio access network node sends the handover request to the second radio access network node,

the first radio access network node receives the acknowledge message from the second radio access network node, or

the first radio access network node sends a handover command to the integrated access and backhaul node.
The first radio access network node of claim 3 wherein the first indication comprises information associated with the second radio access network node to which the integrated access and backhaul node is handed over.
A second radio access network node comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the second radio access network node at least to:

receive from a first radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

send to the first radio access network node, an acknowledge message responsive to the handover request.
The second radio access network node of claim 6 wherein the backhaul configuration comprises configuration of at least one of a radio bearer, a radio link control (RLC) bearer, a protocol data unit (PDU) session and a quality of service (QoS) flow for a backhaul connection of the integrated access and backhaul node, and/or

the indication of the central node comprises an identifier or address of a control plane of the central node and/or an identifier or address of a user plane of the central node.
The second radio access network node of claim 6 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the second radio access network node at least to:

send, to the central node, a second indication indicative of the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.
The second radio access network node of claim 8 wherein the second indication is sent when

the second radio access network node receives the handover request from the first radio access network node,

the second radio access network node sends the acknowledge message to the first radio access network node, or

the second radio access network node receives a handover complete message from the integrated access and backhaul node.
The second radio access network node of claim 9 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the second radio access network node at least to:

establish a connection between the second radio access network node and the central node for transmission of the second indication.
The second radio access network node of claim 6 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the second radio access network node at least to:

send transport configuration comprising transport network layer parameters associated with the second radio access network node to the central node.
A central node comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the central node at least to:

receive, from a first radio access network node and/or a second radio access network node, an indication indicative of handover of an integrated access and backhaul node from the first radio access network node to the second radio access network node, the central node serving one or more user equipments connected to the integrated access and backhaul node; and

suspend transmission between the central node and the integrated access and backhaul node via the first radio access network node in response to the indication.
The central node of claim 12 wherein the indication comprises a first indication received from the first radio access network node and/or a second indication received from the second radio access network node,

the first indication indicates that

a measurement report triggering the handover of the integrated access and backhaul node is received at the first radio access network node,

a handover request is sent from the first radio access network node to the second radio access network node,

an acknowledge message responsive to the handover request is received at the first radio access node from the second radio access network node, or

a handover command is sent from the first radio access network node to the integrated access and backhaul node,

the second indication indicates that

the handover request is received at the second radio access network node from the first radio access network node,

the acknowledge message responsive to the handover request is sent from the second radio access network node to the first radio access network node, or

a handover complete message is received at the second radio access network node from the integrated access and backhaul node.
The central node of claim 12 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the central node at least to:

receive transport configuration comprising transport network layer parameters from the second radio access network node; and

resume transmission between a control plane of the central node and the integrated access and backhaul node via the second radio access network node at least partially based on the received transport configuration.
The central node of claim 14 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the central node at least to:

reconfigure a user plane of the central node for transmission between the user plane of the central node and the integrated access and backhaul node, based on the transport configuration; and

resume transmission between the user plane of the central node and the integrated access and backhaul node via the second radio access network node.
A radio access network node comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the radio access network node at least to:

send a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to hand over the integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

send an indication indicative of the handover of the integrated access and backhaul node to a central node serving one or more user equipments connected to the integrated access and backhaul node.
The radio access network node of claim 16 wherein the indication is sent when

the radio access network node receives from the integrated access and backhaul node a measurement report triggering the handover of the integrated access and backhaul node,

the radio access network node sends the handover command to the integrated access and backhaul node, or

the radio access network node receives a handover complete message from the integrated access and backhaul node.
The radio access network node of claim 16 wherein the indication comprises information associated with the second distributed unit of the radio access network node to which the integrated access and backhaul node is handed over.
The radio access network node of claim 16 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the radio access network node at least to:

send transport configuration comprising transport network layer parameters associated with the second distributed unit of the radio access network node to the central node.
A central node comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the central node at least to:

receive from a radio access network node an indication indicative of handover of an integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

suspend transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node in response to the received indication, the central node serving one or more user equipments connected to the integrated access and backhaul node.
The central node of claim 20 wherein the indication indicates

a measurement report triggering the handover of the integrated access and backhaul node is received at the radio access network node,

a handover command is sent from the radio access network node to the integrated access and backhaul node, or

a handover complete message is received at the radio access network node from the integrated access and backhaul node.
The central node of claim 20 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the central node at least to:

receive, from the radio access network node, transport configuration comprising transport network layer parameters for the second distributed unit of the radio access network node; and

resume transmission between a control plane of the central node and the integrated access and backhaul node via the second distributed unit of the radio access network node at least partially based on the received transport configuration.
The central node of claim 22 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the central node at least to:

reconfigure a user plane of the central node for transmission between the user plane of the central node and the integrated access and backhaul node, based on the transport configuration; and

resume transmission between the user plane of the central node and the integrated access and backhaul node via the second distributed unit of the radio access network node.
A method implemented at a first radio access network node comprising:

sending, to a second radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

receiving, from the second radio access network node, an acknowledge message responsive to the handover request.
The method of claim 24 wherein the backhaul configuration comprises configuration of at least one of a radio bearer, a radio link control (RLC) bearer, a protocol data unit (PDU) session and a quality of service (QoS) flow for a backhaul connection of the integrated access and backhaul node, and/or

the indication of the central node comprises an identifier or address of a control plane of the central node and/or an identifier or address of a user plane of the central node.
The method of claim 24 further comprising:

sending, to the central node, a first indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.
The method of claim 26 wherein the first indication is sent when

the first radio access network node receives from the integrated access and backhaul node a measurement report triggering the handover of the integrated access and backhaul node,

the first radio access network node sends the handover request to the second radio access network node,

the first radio access network node receives the acknowledge message from the second radio access network node, or

the first radio access network node sends a handover command to the integrated access and backhaul node.
The method of claim 26 wherein the first indication comprises information associated with the second radio access network node to which the integrated access and backhaul node is handed over.
A method implemented at a second radio access network node, comprising:

receiving, from a first radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

sending to the first radio access network node, an acknowledge message responsive to the handover request.
The method of claim 29 wherein the backhaul configuration comprises configuration of at least one of a radio bearer, a radio link control (RLC) bearer, a protocol data unit (PDU) session and a quality of service (QoS) flow for a backhaul connection of the integrated access and backhaul node, and/or

the indication of the central node comprises an identifier or address of a control plane of the central node and/or an identifier or address of a user plane of the central node.
The method of claim 29 further comprising:

sending, to the central node, a second indication indicative of the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.
The method of claim 31 wherein the second indication is sent when

the second radio access network node receives the handover request from the first radio access network node,

the second radio access network node sends the acknowledge message to the first radio access network node, or

the second radio access network node receives a handover complete message from the integrated access and backhaul node.
The method of claim 32 further comprising:

establishing a connection between the second radio access network node and the central node for transmission of the second indication.
The method of claim 29 further comprising:

sending transport configuration comprising transport network layer parameters associated with the second radio access network node to the central node.
A method implemented at a central node, comprising:

receiving, from a first radio access network node and/or a second radio access network node, an indication indicative of handover of an integrated access and backhaul node from the first radio access network node to the second radio access network node, the central node serving one or more user equipments connected to the integrated access and backhaul node; and

suspending transmission between the central node and the integrated access and backhaul node via the first radio access network node in response to the indication.
The method of claim 35 wherein the indication comprises a first indication received from the first radio access network node and/or a second indication received from the second radio access network node,

the first indication indicates that

a measurement report triggering the handover of the integrated access and backhaul node is received at the first radio access network node,

a handover request is sent from the first radio access network node to the second radio access network node,

an acknowledge message responsive to the handover request is received at the first radio access node from the second radio access network node, or

a handover command is sent from the first radio access network node to the integrated access and backhaul node,

the second indication indicates that

the handover request is received at the second radio access network node from the first radio access network node,

the acknowledge message responsive to the handover request is sent from the second radio access network node to the first radio access network node, or

a handover complete message is received at the second radio access network node from the integrated access and backhaul node.
The method of claim 35 further comprising:

receiving transport configuration comprising transport network layer parameters from the second radio access network node; and

resuming transmission between a control plane of the central node and the integrated access and backhaul node via the second radio access network node at least partially based on the received transport configuration.
The method of claim 37 further comprising:

reconfiguring a user plane of the central node for transmission between the user plane of the central node and the integrated access and backhaul node, based on the transport configuration; and

resuming transmission between the user plane of the central node and the integrated access and backhaul node via the second radio access network node.
A method implemented at a radio access network node, comprising:

sending a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to hand over the integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

sending an indication indicative of the handover of the integrated access and backhaul node to a central node serving one or more user equipments connected to the integrated access and backhaul node.
The method of claim 39 wherein the indication is sent when

the radio access network node receives from the integrated access and backhaul node a measurement report triggering the handover of the integrated access and backhaul node,

the radio access network node sends the handover command to the integrated access and backhaul node, or

the radio access network node receives a handover complete message from the integrated access and backhaul node.
The method of claim 39 wherein the indication comprises information associated with the second distributed unit of the radio access network node to which the integrated access and backhaul node is handed over.
The method of claim 39 further comprising:

sending transport configuration comprising transport network layer parameters associated with the second distributed unit of the radio access network node to the central node.
A method implemented at a central node comprising:

receiving from a radio access network node an indication indicative of handover of an integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

suspending transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node in response to the received indication, the central node serving one or more user equipments connected to the integrated access and backhaul node.
The method of claim 43 wherein the indication indicates

a measurement report triggering the handover of the integrated access and backhaul node is received at the radio access network node,

a handover command is sent from the radio access network node to the integrated access and backhaul node, or

a handover complete message is received at the radio access network node from the integrated access and backhaul node.
The method of claim 43 further comprising:

receiving, from the radio access network node, transport configuration comprising transport network layer parameters for the second distributed unit of the radio access network node; and

resuming transmission between a control plane of the central node and the integrated access and backhaul node via the second distributed unit of the radio access network node at least partially based on the received transport configuration.
The method of claim 45 further comprising:

reconfiguring a user plane of the central node for transmission between the user plane of the central node and the integrated access and backhaul node, based on the transport configuration; and

resuming transmission between the user plane of the central node and the integrated access and backhaul node via the second distributed unit of the radio access network node.
An apparatus comprising:

means for sending, to a second radio access network node, a handover request to hand over an integrated access and backhaul node from a first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

means for receiving, from the second radio access network node, an acknowledge message responsive to the handover request.
An apparatus comprising:

means for receiving from a first radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to a second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

means for sending to the first radio access network node, an acknowledge message responsive to the handover request.
An apparatus comprising:

means for receiving at a central node, from a first radio access network node and/or a second radio access network node, an indication indicative of handover of an integrated access and backhaul node from the first radio access network node to the second radio access network node, the central node serving one or more user equipments connected to the integrated access and backhaul node; and

means for suspending transmission between the central node and the integrated access and backhaul node via the first radio access network node in response to the indication.
An apparatus comprising:

means for sending a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to hand over the integrated access and backhaul node from a first distributed unit of a radio access network node to a second distributed unit of the radio access network node; and

means for sending an indication indicative of the handover of the integrated access and backhaul node to a central node serving one or more user equipments connected to the integrated access and backhaul node.
An apparatus comprising:

means for receiving, at a central node from a radio access network node, an indication indicative of handover of an integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

means for suspending transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node in response to the received indication, the central node serving one or more user equipments connected to the integrated access and backhaul node.
A computer program product embodied in at least one computer readable medium and comprising instructions, when executed by at least one processor of a first radio access network node, causing the first radio access network node at least to:

send to a second radio access network node, a handover request to hand over an integrated access and backhaul node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

receive, from the second radio access network node, an acknowledge message responsive to the handover request.
A computer program product embodied in at least one computer readable medium and comprising instructions, when executed by at least one processor of a second radio access network node, causing the second radio access network node at least to:

receive from a first radio access network node, a handover request to hand over an integrated access and backhaul node from the first radio access network node to the second radio access network node, the handover request comprising configuration information indicative of backhaul configuration of the integrated access and backhaul node and/or an indication of a central node serving one or more user equipments connected to the integrated access and backhaul node; and

send to the first radio access network node, an acknowledge message responsive to the handover request.
A computer program product embodied in at least one computer readable medium and comprising instructions, when executed by at least one processor of a central node, causing the central node at least to:

receive from a first radio access network node and/or a second radio access network node, an indication indicative of handover of an integrated access and backhaul node from the first radio access network node to the second radio access network node, the central node serving one or more user equipments connected to the integrated access and backhaul node; and

suspend transmission between the central node and the integrated access and backhaul node via the first radio access network node in response to the indication.
A computer program product embodied in at least one computer readable medium and comprising instructions, when executed by at least one processor of a radio access network node, causing the radio access network node at least to:

send a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to hand over the integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

send an indication indicative of the handover of the integrated access and backhaul node to a central node serving one or more user equipments connected to the integrated access and backhaul node.
A computer program product embodied in at least one computer readable medium and comprising instructions, when executed by at least one processor of a central node, causing the central node at least to:

receive from a radio access network node an indication indicative of handover of an integrated access and backhaul node from a first distributed unit of the radio access network node to a second distributed unit of the radio access network node; and

suspend transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node in response to the received indication, the central node serving one or more user equipments connected to the integrated access and backhaul node.