Mobility management in mobile integrated access and backhaul networks

Abstract

Various example embodiments relate to apparatuses and methods for mobility management in an integrated access and backhaul network. The first radio access network node may send a handover request to the second radio access network node to handover the integrated access and backhaul node from the first radio access network node to the second radio access network node, and receive an acknowledgement message from the second radio access network node in response to the handover request. The handover request may include configuration information indicating a 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

Technical Field

[0001] Various example embodiments described herein relate generally to communication technology, and more particularly, to apparatus and methods for mobility management in a mobile Integrated Access and Backhaul (IAB) network. Background Art

[0002] Certain abbreviations that may be found in the specification and / or drawings are defined herein 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 gNBNext Generation Node B HO Switchover IAB Integrated Access and Backhaul MT Mobile Terminal 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 Signalling Radio Bearer TNL Transport Network Layer UE User Equipment UP User Plane UPF User Plane Function

[0003] Vehicle-mounted relay (VMR) can provide high-quality communication services to vehicle-mounted and surrounding user equipment (UE). 5G New Radio (NR) provides support for VMR scenarios in integrated access and backhaul (IAB) networks, where VMR can be implemented as a mobile IAB node that uses a radio link (instead of optical fiber) for backhaul to enable wireless relay of NR access to the network. On the network side, the wireless backhaul terminates at a base station called an IAB donor, which provides network access to one or more IAB nodes and UEs connected to the IAB nodes. As the vehicle moves, the mobile IAB node installed on the vehicle can migrate between cells supported by the IAB donor or between different IAB donors. Summary of the invention

[0004] The following provides a brief summary of example embodiments to provide a 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 to limit the scope of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a prelude to the more detailed description provided below.

[0005] In a first aspect, an exemplary embodiment of a first radio access network node is provided. The first radio access network node may include 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, together with the at least one processor, cause the first radio access network node to at least: send a handover request to a second radio access network node to handover an integrated access and backhaul node from the first radio access network node to the second radio access network node; and receive a confirmation message in response to the handover request from the second radio access network node. The handover request may include configuration information indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node.

[0006] In a second aspect, an exemplary embodiment of a second radio access network node is provided. The second radio access network node may include 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, together with the at least one processor, cause the second radio access network node to at least: receive a handover request from the first radio access network node to handover an integrated access and backhaul node from the first radio access network node to the second radio access network node. The handover request may include configuration information indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node. The second radio access network node may send a confirmation message in response to the handover request to the first radio access network node.

[0007] In a third aspect, an example embodiment of a central node is provided. The central node may include 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, together with the at least one processor, cause the central node to at least: receive an indication from a first radio access network node and / or a second radio access network node, the indication indicating a 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 equipment connected to the integrated access and backhaul node are served by the central node. The central node may, in response to the indication, suspend transmission between the central node and the integrated access and backhaul node via the first radio access network node.

[0008] In a fourth aspect, an exemplary embodiment of a radio access network node is provided. The radio access network node may include 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, together with the at least one processor, cause the radio access network node to at least: send a handover command to an integrated access and backhaul node, and send an indication to a central node serving one or more user equipment connected to the integrated access and backhaul node, the indication indicating a handover of the integrated access and backhaul node. The handover command may include one or more parameters to be used to handover 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.

[0009] In a fifth aspect, an exemplary embodiment of a central node is provided. The central node may include 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, together with the at least one processor, enable the central node to at least: receive an indication from a radio access network node indicating a 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 in response to the received indication, suspend transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node. The central node serves one or more user equipment connected to the integrated access and backhaul node.

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

[0011] Other features and advantages of example embodiments of the present disclosure will become 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

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

[0013] Figure 1A , 1B 1C are schematic diagrams illustrating an IAB network architecture in which example embodiments of the present disclosure may be implemented.

[0014] Figure 2 Schematic diagram of the migration of IAB nodes between donors.

[0015] Figure 3Schematic diagram of migration between donor DUs within a donor CU of an IAB node.

[0016] Figure 4 is a schematic message sequence chart illustrating a procedure for inter-donor mobility of an IAB node according to an exemplary embodiment of the present disclosure.

[0017] Figure 5 FIG. 1 is a schematic message sequence chart illustrating a process for F1 TNL configuration according to an exemplary embodiment of the present disclosure.

[0018] Figure 6 is a schematic flow chart illustrating a donor-to-donor switching method according to an exemplary embodiment of the present disclosure.

[0019] Figure 7 is a schematic flow chart illustrating a donor-to-donor switching method according to an exemplary embodiment of the present disclosure.

[0020] Figure 8 is a schematic flow chart illustrating a donor-to-donor switching method according to an exemplary embodiment of the present disclosure.

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

[0022] Fig.10 is a schematic flowchart illustrating a donor DU switching method within a donor CU according to an exemplary embodiment of the present disclosure.

[0023] Fig.11 is a schematic flowchart illustrating a donor DU switching method within a donor CU according to an exemplary embodiment of the present disclosure.

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

[0025] Throughout the drawings, the same or similar reference numerals indicate the same or similar elements, and repeated description of the same elements will be omitted. DETAILED DESCRIPTION

[0026] Hereinafter, 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 the various concepts. However, it is apparent to those skilled in the art that these concepts can be practiced without these specific details. In some cases, known circuits, techniques, and components are shown in block diagram form to avoid obscuring the concepts and features described.

[0027] As used herein, the term "network equipment" refers to any suitable equipment or entity that can provide a cell or coverage, through which a terminal device can access a network or receive a service. Network equipment may generally be referred to as a base transceiver station (BTS), a base station (BS), or some other suitable term. The term "base station" or "base transceiver station" used herein may represent a node B (Node B or NB), an evolved node B (e Node B or eNB), a next generation node B (gNB), or a next generation enhanced node B (ng-e NB). A base station may be embodied as a macro base station, a relay node, or a low power node, such as a micro base station or a femto base station. A base station may also include or may be referred to as a RAN (radio access network) node, and may be composed of several distributed network units, such as a central unit (CU), one or more distributed units (DU), one or more remote radio heads (RRHs), or remote radio units (RRUs). The number and functionality of these distributed units depends on the selected split RAN architecture.

[0028] As used herein, the term "terminal device" or "user equipment" (UE) refers to any device or entity that can communicate wirelessly with network devices or each other. Examples of terminal devices may include mobile phones, mobile terminals, mobile stations (MS), subscriber stations, portable subscriber stations, access terminals, personal digital assistants (PDAs), computers, wearable devices, vehicle-mounted communication devices, machine type communication (MTC) devices, D2D communication devices, V2X communication devices, sensors, etc. The term "terminal device" may be used interchangeably with UE, user terminal, mobile terminal, mobile station, or wireless device.

[0029] In a 5G communication network, a new radio (NR) cell can be deployed in a wide spectrum range, including a frequency range 1 (FR1) occupying a frequency less than 6 GHz and a frequency range 2 (FR2) occupying a frequency greater than 6 GHz. At higher frequencies, the coverage of the NR cell is relatively small. As a result, densification by deploying more and more base stations is one of the mechanisms that can be used to meet the increased capacity requirements while providing a full coverage area in a wireless network. In such deployments, various forms of wireless connections using an integrated access and backhaul (IAB) node between a base station and a user equipment (UE) are supported in a 5G NR system. The IAB node can support radio access and backhaul in FR1 and FR2 spectrums. The NR UE can be transparently connected to the IAB node via NR. In addition, in the case where the IAB node supports the backhaul of LTE access, the traditional long term evolution (LTE) UE can be transparently connected to the IAB node via LTE.

[0030] IAB nodes can be used in various deployment scenarios, including support for outdoor small cell deployment, indoor deployment, and vehicle-mounted relay (VMR). VMR can utilize mobile IAB nodes installed on vehicles (e.g., trains, buses, trams, subways, etc.) to increase the data rate and reliability of UEs in or around the vehicle. Unlike fixed IAB nodes that can be connected to fixed IAB donors (base stations), mobile IAB nodes can migrate between different IAB donors when the vehicle moves. For example, when the mobile IAB node is installed on a train traveling long distances, the mobile IAB node and the UE connected to the IAB node will migrate between a large number of IAB donors. Therefore, it has been proposed that a dedicated central unit (CU) can be used to serve UEs connected to the mobile IAB node.

[0031] Figure 1A , 1B 1C and 1C show some example architectures of an IAB network, in which a CU (hereinafter referred to as a mobile CU or m-CU) is provided to a serving UE connected to a mobile IAB node. The example embodiments of the present disclosure discussed below may be implemented in, but are not limited to, such an example IAB network architecture. First, refer to Figure 1A , shows an example mobile IAB network architecture with a single-hop backhaul to a mobile IAB node. Figure 1A As shown, the mobile IAB node 110 is connected to the IAB donor 130 via the NR Uu interface RRC, the IAB donor 130 is connected to the core network 160 via the NG interface, and a central unit 150 (i.e., m-CU, also referred to as a central node) is provided to serve the UE (e.g., UE 101a) connected to the mobile IAB node 110. The m-CU 150 may be connected to a mobile IAB specific user plane function (UPF) 162, which may be referred to as a mobile UPF (m-UPF) hereinafter. Figure 1A The illustrated IAB network 100A may be part of a larger cellular communication system such as a 5G system (5GS).

[0032] The IAB donor 130 may be a radio access network (RAN) node, such as a base station with a backhaul connection to the core network 160. The IAB donor 130 may be viewed as a single logical node that includes a set of functions, such as a central unit (CU) 134, one or more distributed units (DU) 132, and potentially other functions (not shown). In some deployments, the IAB donor 130 may be split according to these functions, which may all be collocated or non-collocated as allowed by the 3GPP NG-RAN architecture. In addition, some functions currently associated with the IAB donor 130 may be moved outside the donor in the case where these functions do not perform IAB-specific tasks. In an example deployment, the CU 134 may be deployed at a central office, and the DU 132 may be deployed at a corresponding cell site. In another example where the RAN has a cloud-based architecture, the CU 134 may be deployed in the cloud.

[0033] The donor DU 132 and the donor CU 134 are connected via an F1 interface, which includes an F1-C interface between the donor DU 132 and the control plane (CP, not shown) of the donor CU 134 and an F1-U interface between the donor DU 132 and the 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, and the donor DU 132 may have an F1-C connection with only one donor CU-CP and an F1-U connection 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 serve UEs and sub-IAB nodes. In this example, one or more UEs 101b may be connected to the donor DU 132 via an NR Uu interface and served by the control plane and user plane of the donor CU 134.

[0034] The IAB node 110 may include a distributed unit (DU) 112 and a mobile terminal (MT) portion 114. The IAB MT 114 is a component that provides functionality resident on the IAB node 110 that terminates the radio interface layer of the backhaul Uu interface to the IAB donor 130 or other intermediate IAB nodes. The IAB MT 114 enables the IAB node 110 to act like a normal UE toward the IAB donor 130. In the example shown, the MT 114 is RRC connected to the IAB donor 130.

[0035] 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 the example, the mobile IAB node 110 may not have a descendant IAB node, and only one or more UEs 101a are connected to the IAB DU 112 via the NR Uu interface. From the perspective of the UE, the IAB DU cell can be regarded as a normal cell like the 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 UE 101a connected to the IAB DU 112 may obtain 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 the mobile IAB specific UPF (m-UPF) 162 through the access RAN (ie, the IAB donor 130). The core network 160 may select the m-UPF 162 corresponding to the m-CU 150 during the PDU session establishment. For example, the core network 160 may select an 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 a radio bearer may be configured for the PDU session at the IAB MT 114 and the donor CU 134. From the core network's perspective, the IAB DU 112 and the m-CU 150 may be considered as a base station, and the donor DU 132 and the donor CU 134 may be considered as another base station.

[0036] In the context of 5G NR, the core network 160 may be a 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), etc. The m-CU 150 and the donor CU 134 may be connected to the NGC 160 via an NG interface.

[0037] exist Figure 1AIn the network architecture shown, the physical location of m-CU 150 and m-UPF 162 can be flexibly determined according to the physical deployment of the network implementation. In the example, m-CU 150 and m-UPF 162 can reside in IAB donor 130 as part of the function of IAB donor 130. In another example where the access RAN has a cloud-based architecture, m-CU 150 and m-UPF 162 can be placed in a cloud infrastructure. Depending on the use case and mobile range of the mobile IAB node 110, m-CU 150 and m-UPF 162 can be placed in a RAN local cloud hosted by IAB donor 130 or another IAB donor node. The advantage of a cloud-based architecture is that it can provide flexibility to utilize dedicated mobile functions serving mobile IAB nodes 110 to serve relatively large areas. In some example embodiments, m-CU 150 and m-UPF 162 can be part of a specific network slice serving a mobile IAB node.

[0038] Figure 1A The example IAB network architecture shown can reuse existing functions and interfaces defined in 5G NR. Specifically, the mobile IAB node 110 can reuse the MT+DU structure of the current fixed IAB node, which can minimize changes to the IAB node hardware and software. IAB MT, IAB DU, donor DU, donor CU, UPF, AMF and SMF and 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 CU and NG between RAN and NGC can be used as the baseline of the IAB architecture. Therefore, the mobile IAB architecture can serve traditional UEs with minimal or no impact on the access network. Enhancements to the IAB network can be implemented in dedicated functions or entities, namely m-CU 150, m-UPF 162 and mobile IAB node 110. The mobile IAB node 110 is almost transparent to the access RAN, which provides flexibility to apply the architecture for various use cases and network deployment scenarios.

[0039] according to Figure 1AAnother advantage of the IAB network architecture shown in is that the RAN node providing network access to the mobile IAB node 110 can 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 NRRAN base station with or without IAB capability, and operators do not need to upgrade a large number of legacy base stations, which generally do not require wireless backhaul for IAB support. This is particularly useful in scenarios where a 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.

[0040] and Figure 1A Unlike the single-hop architecture shown in Figure 1B A multi-hop architecture of a mobile IAB network 100B is shown, wherein a mobile IAB node 110 is connected to an IAB donor 130 via one or more intermediate IAB nodes 120. The intermediate IAB node 120 may be a fixed / fixed node, and the mobile IAB node 110 may be the last (most downstream) IAB node in a multi-hop chain serving an access UE. The intermediate IAB node 120 may also include an IAB DU 122 and an IAB MT 124, the IAB DU 122 maintaining a Uu interface with the IAB MT 114 in the mobile IAB node 110, and the IAB MT 124 maintaining a 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 adaptation protocol (BAP) layer (not shown). Similar to the IAB DU 112 and the donor DU 132, the IAB DU 122 may also support one or more cells to serve the UE. For example, one or more UEs 101c may be connected to the IAB DU 122 via the NR Uu interface.

[0041] Similar to Figure 1A In the architecture shown in , the wireless backhaul of the mobile IAB node 110 can be carried via a PDU session, and the radio bearer for the PDU session transparently passes through the fixed IAB node 120. Therefore, the mobile IAB node 110 is regarded as a normal UE connected to the fixed IAB node 120. It should be understood that the UE 101a connected to the mobile IAB node 110 is served by the m-CU 150 in the control plane and the user plane, while the UE 101c connected to the intermediate IAB node 120 and the UE 101b connected to the IAB donor 130 are served by the donor CU 134 in the control plane and the user plane. Figure 1B Other aspects of the examples shown are similar to Figure 1A The examples shown are similar and repeated descriptions are omitted here for convenience.

[0042] Figure 1C Another example architecture of a mobile IAB network 100C is shown. Figure 1A and 1B Compared to the architecture shown in FIG. 1 , the mobile IAB network 100C does not use PDU sessions for the backhaul link. Instead, a L2 routing protocol called the Backhaul Adaptation Protocol (BAP) is included on top of the backhaul RLC bearer to route packets to downstream or upstream destination nodes and map UE bearer data to the appropriate backhaul RLC channel (also used for mapping between ingress and egress backhaul RLC channels in the intermediate IAB node 120). The BAP layer can deliver control and data PDUs via multiple hops, although in Figure 1C The intermediate IAB node 120 is omitted. 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 can be omitted and the backhaul link can be carried via the radio bearer layer. Between the donor DU 132 and the m-CU 150, the backhaul link can be carried over an Internet Protocol (IP) interface. The mobile IAB network 100C has the following advantages: the core network interface terminates at the donor CU 134 and the m-CU 150, and therefore the L2 relay is only a RAN function without Figure 1A and 1B The m-UPF function shown in . Figure 1C Other aspects of the examples shown in Figure 1A-1B The examples shown in are similar, and for convenience, repeated description is omitted here.

[0043] As described above, when the mobile IAB node 110 moves together with the vehicle in which it is installed, the mobile IAB node may need to change its access service node (IAB donor 130 or intermediate IAB node 120). Figure 2 and Figure 3 Two examples of mobile IAB node migration scenarios are shown. Figure 2, shows a donor inter-CU migration scenario, in which the mobile IAB node 110 migrates from the 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 the domain of the 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. In order 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 link from the source donor 130 to the target donor 140. A transport network layer (TNL) connection may be established 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 having an F1-C connection with the IAB DU 112 and a user plane (UP) 154 having an F1-U connection with the IAB DU 112. After the donor CU migration, the UE 101a connected to the mobile IAB node 110 is still served by the m-CU 150.

[0044] Figure 3 The scenario of intra-donor CU inter-donor DU migration is shown, where the mobile IAB node 110 migrates from the 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 the 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 donor DU 132 and the second donor DU 136 are under the control of the same donor CU 134. Other aspects of intra-donor CU inter-donor DU migration are similar to those described above with respect to Figure 2 The donor-CU inter-migration is discussed, and for convenience, its repeated description is omitted here.

[0045] In order to achieve service continuity for the UE 101a connected to the mobile IAB node 110, it is desirable to support efficient mobility of the mobile IAB node 110 in various migration situations. Figures 1A to 1CWhen used in the IAB network shown in , the existing signaling does not support backhaul link mobility between the source donor and the target donor or donor DU. For example, there is no signaling to instruct the m-CU150 about the switching process and its stages during the IAB node mobility, and the m-CU 150 may not stop transmission to the mobile IAB node, even during the switching process. The switching signaling between the source donor CU 134 and the target donor CU 144 does not support the backhaul link DRB change, and the target donor CU144 cannot know which DRB is used for the backhaul connection. In addition, in the existing switching process, the target donor CU 144 does not notify the m-CU-CP 152 of the RLC bearer configuration information, and does not send an indication of the m-CU-UP 154 to the target donor CU 144 for UP routing. Therefore, in the mobile IAB network using the m-CU150, the existing signaling and switching process do not support efficient mobility of the mobile IAB node 110.

[0046] Hereinafter, various exemplary embodiments of apparatuses, methods, and computer program products for supporting mobility of mobile IAB nodes will be described in detail with reference to the accompanying drawings. The exemplary embodiments may support efficient mobility of mobile IAB nodes in different migration scenarios with minimized impact on traditional base stations. The exemplary embodiments are applicable to, but not limited to, Figures 1A-1C In general, the example embodiments are applicable to a mobile IAB network architecture where an IAB donor provides a wireless backhaul connection and an m-CU provides control plane and user plane services to UEs connected to the mobile IAB node. In the example embodiment, the mobility of the IAB node is limited to the backhaul link and it does not affect the access UE as long as the m-CU serving the UE remains unchanged.

[0047] Figure 4 is a schematic message sequence chart illustrating a process 200 for inter-donor mobility of a mobile IAB node according to an example embodiment of the present disclosure. Figure 4 The operations shown may be performed by a mobile IAB node, a source IAB donor and a target IAB donor that provide an RRC connection and a backhaul connection for the mobile IAB node, and an m-CU serving the mobile IAB node and a UE connected to the mobile IAB node. The above-mentioned network and terminal node may include a plurality of parts, modules, components or elements for performing the operations discussed below, and these parts, modules, components or elements may be implemented in various ways, including but not limited to software, hardware, firmware or any combination thereof. Although Figure 4 Not shown, but it should be understood, 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.

[0048] At the beginning of the inter-donor mobility process 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 a backhaul bearer, backhaul RLC bearer / channel, PDU session or QoS flow to carry F1 traffic between the m-CU 150 and the IAB DU 112, as described above with respect to Figures 1A-1C Mentioned. F1 (including F1-C and F1-U) traffic can be routed via the source donor DU 132. For example, the source donor DU 132 can map the downlink F1 traffic to the relevant backhaul RLC channel and relay the downlink F1 traffic to the IAB DU 112 through the wireless backhaul. The IAB DU 112 then transmits the downlink data to a destination UE (not shown), which is connected to the IAB DU 112 via an access link. The uplink F1 traffic is sent from the IAB DU 112 to the m-CU 150 in the reverse direction. The source donor CU 134 may have an Xn interface with the m-CU 150.

[0049] The IAB MT 114 may measure neighboring cells according to the measurement configuration configured by the source donor 130. The source donor 130 may configure a measurement report event for the IAB MT 114 to trigger a measurement report. Figure 4 At 210, when one of the configured measurement report events is detected at the IAB MT 114, the IAB MT 114 may send a measurement report to the source donor CU 134. For example, when the IAB MT 114 detects that the signal strength of one or more neighboring cells is better than the signal strength of the serving cell served by the source donor DU 132 to exceed a threshold (measurement report event A3), the IAB MT 114 may send a measurement report indicating the signal strength of the serving cell and the one or more neighboring cells to the source donor CU 134, the signal strength being represented by, for example, reference signal received power (RSRP), reference signal received quality (RSRQ), or signal to interference and noise ratio (SINR). 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.

[0050] In response to the measurement report received from the IAB MT 114, the source donor CU 134 may decide at 212 to switch the IAB node 110 from the source donor 130 to the target donor 140. When the measurement report includes more than one neighbor cell indication as a handover candidate, the source donor CU 134 may select, for example, the best / strongest neighbor cell for handover of the IAB node 110. Although the measurement report is described herein as an example event that triggers a handover decision, it should be understood 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 establishment process to establish an Xn connection with the target donor CU 144 before the source donor CU 134 sends the handover request to the target donor CU 144.

[0051] In addition to traditional information such as the target cell ID for the handover of the IAB node 110, the UE (IAB MT) XnAPID, the handover cause, the UE context, etc., the handover request may also include information associated with the wireless backhaul of the IAB node 110. In some example embodiments, the handover request may include configuration information indicating the backhaul configuration for the IAB node 110. For example, the backhaul configuration for the IAB node 110 may include one or more of the following configurations: radio bearers, RLC bearers, PDU sessions, and / or QoS flows for the backhaul connection of the IAB node 110. The handover request may explicitly or implicitly indicate which radio bearers, RLC bearers, PDU sessions, and / or QoS flows are used for the backhaul connection of the IAB node 110. In some example embodiments, the handover request may include an indication of the m-CU 150 that controls the IAB node 110 and the UE 101a connected to the IAB node 110. For example, the indication of the m-CU 150 may include an identifier (ID) or an address (e.g., an IP address) of the control plane 152 of the m-CU 150 and / or an identifier or an address (e.g., an 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 such as an index, a sequence number, etc. 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.

[0052] When the handover process for the IAB node 110 is initiated at 214, the source donor CU 134 may optionally send an early / first handover indication to the m-CU-CP 152 at 216 to inform the m-CU150 that the IAB node 110 will be switched to the target donor 140. The early handover indication may include an indicator indicating the current stage of the handover. The early handover indication may also include information associated with the IAB node 110 and the target donor 140 so that the m-CU-CP 152 may know which target donor the IAB node 110 will be switched 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 the example, the early handover indication may also 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 whether there is an Xn connection between the m-CU-CP 152 and the target donor CU 144. If an Xn connection does not exist, the m-CU 150 may initiate an Xn establishment procedure to establish an Xn connection between the m-CU-CP 152 and the target donor CU 144 .

[0053] It should be understood that the early switching indication may also be sent to the m-CU 150 at other times or opportunities. For example, when the source donor CU 134 receives a measurement report triggering the switching process from the IAB node 110, the source donor CU 134 may send the early switching indication to the m-CU-CP 152. With the early switching indication, the m-CU 150 may know which target donor the IAB node 110 is going to switch to, and establish a connection with the target donor in a timely manner.

[0054] 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 assign resources to the IAB node 110 while taking into account the information received in the handover request. When resources at the target donor 140 are available for the IAB node 110, the target donor 140 may grant the handover request. Otherwise, the target donor 140 may deny the handover request.

[0055] When the handover request is granted at 218, the target donor CU 144 may send a UE (IAB MT) context setup request message to the target donor DU 142 at 220 to create a UE context and configure the backhaul link of the IAB MT 114. The UE context setup request may include a configuration of radio bearers (e.g., SRBs and DRBs) 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 a core network (not shown) to configure a PDU session and QoS flow for the backhaul link of the IAB node 110. At 222, the target donor DU 142 may respond with a UE context setup response message.

[0056] At 224, the target donor CU 144 may send a handover confirmation to the source donor CU 134 in response to the handover request received at 214. The handover confirmation message may include a transparent container including RRC configuration information required for the IAB MT 114 to access the target cell as part of the handover command. In some example embodiments, the RRC configuration information may include a backhaul configuration for the IAB node 110, such as a configuration of radio bearers (e.g., SRBs and DRBs), 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 to the IAB DU 112 by the target donor CU 144.

[0057] In some example embodiments, the target donor 140 may check whether an Xn connection is available between the target donor 140 and the m-CU 150. As described above, the target donor 140 may receive an indication of the m-CU 150 via a 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 establishment procedure at 226 to establish an Xn connection with the m-CU 150. In some example embodiments, when the m-CU 150 receives an identifier of the target donor CU 144 in an early handover indication received from the source donor 130, the m-CU 150 may initiate the Xn establishment procedure, as described above.

[0058] At 228, the target donor CU 144 may send a second handover indication to the m-CU 150 to indicate the current stage of the handover process for the IAB node 110. The second handover indication may be sent via an 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, in addition to the indicator indicating the current stage of the handover process, the second handover indication may also include information associated with the IAB node 110 and the target donor 140, so that the m-CU-CP 152 may know which target donor the IAB node 110 will be handed over to. For example, the second handover indication may include an identifier of the IAB node 110, an identifier of a target cell or a target donor DU 142 supporting the target cell, and an identifier of a target donor CU 144 associated with the target donor DU 142. In some example embodiments, the second handover indication may also include a transmission 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 of the TNL address and TEID (for F1-C, F1-U, or both), which may be used for UP and / or CP data transmission between the m-CU 150 and the IAB DU 112.

[0059] although Figure 4 The second switching indication is shown to be sent at 228 when the target donor CU 144 sends the switching confirmation to the source donor CU 134 at 224, but the second switching indication may also be sent at other times / opportunities. For example, when the target donor CU 144 receives the switching request from the source donor CU 134 at 214, the target donor CU 144 may send the second switching indication to the m-CU 150.

[0060] When the source donor CU 134 receives the handover confirmation from the target donor CU 144, the source donor CU 134 may send an RRC reconfiguration message including a handover command to the IAB MT 114 at 230. As described above, the handover command may include the RRC configuration information required for the IAB MT 114 to access the target cell, the backhaul configuration of the IAB node 110, and the new TNL address assigned to the IAB DU 112.

[0061] At 232, the source donor CU 134 may send a third handover indication indicating the current stage in the handover process to the m-CU 150. The third handover indication may be sent when the source donor CU 134 receives a handover confirmation from the target donor CU 144 at 224 and / or when the source donor CU 134 sends a handover command to the IAB MT 114 at 230, and the third handover indication may include an indicator for indicating the current handover stage. In some exemplary embodiments, the third handover indication may also 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.

[0062] In response to the third handover indication indicating that the source donor CU 134 has received a handover confirmation from the target donor CU 144 or has sent a handover command to the IAB node 110, the m-CU 150 may suspend downlink transmissions to the IAB node 110 via the source donor 130 at 234. For example, the m-CU-CP 152 may suspend 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 is no longer available, 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.

[0063] Although Figure 4 It is shown that the m-CU 150 suspends transmission to the IAB node 110 in response to the third switching indication, but the present disclosure is not limited to this embodiment. For example, when the m-CU 150 receives an early / first switching indication from the source donor 130 or when it receives a second switching indication from the target donor 140, the m-CU 150 may suspend transmission to the IAB node 110. In another example, when the m-CU 150 receives the earliest switching indication associated with the IAB node 110 from the source donor 130 or the target donor 140, the m-CU 150 may suspend transmission to the IAB node 110.

[0064] 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. Using the RRC configuration received in the handover command message, a conventional RA procedure may be performed for the IAB MT 114 to connect to the target donor DU 142. The IAB MT 114 may also establish a radio bearer, a backhaul RLC bearer, a PDU session, and / or a QoS flow for a backhaul link. 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, when the handover procedure is completed, the target donor CU 144 may instruct the source donor CU 134 to release the UE (IABMT) context of the IAB MT 114.

[0065] At 240, the target donor CU 144 may indicate to the m-CU-CP 152 the completion of the handover process regarding the IAB node 110. Based on the indication, the m-CU-CP 152 knows that the IAB node 110 has been 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 transmission between the IAB node 110 and the m-CU 150. In some example embodiments, at 240, the target donor CU 144 may also send a transmission configuration including TNL parameters associated with the target donor DU 142 to the m-CU-CP 152.

[0066] 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 F1-C traffic between the m-CU 150 and the IAB node 110 via the target donor DU 142 .

[0067] Figure 5 An example process 300 for reconfiguring a transport connection according to an example embodiment of the present disclosure is shown, which may be performed in Figure 4 The process 200 is shown as being performed at step 242. Figure 5 , the IAB DU 112 may send a gNB DU Configuration Update message to the m-CU-CP 152 at 310 to establish a new SCTP association with the m-CU-CP 152. The message may include new TNL addresses assigned to the IAB DU 112 for the 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.

[0068] 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 service to be transmitted via the target donor 140. The message may include F1 service related configurations, such as 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 a new TNL address anchored in the target donor DU 142 for the requested F1 service. The F1-C service may then be resumed between the IAB node 110 and the m-CU-CP 152 via the target donor 140 (i.e., the target donor DU 142) at 318.

[0069] Return to reference Figure 4 As described 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 service), the target donor CU 144 can send an RRC reconfiguration message to the IAB MT 114 at 244 to, for example, add, remove, or modify a radio bearer, backhaul RLC bearer, backhaul RLC channel, PDU session, or QoS flow for the backhaul link. At 246, the IAB MT 114 can respond to the target donor CU 144 with an RRC reconfiguration complete message to confirm that it has successfully updated the backhaul configuration.

[0070] At 248, the m-CU-CP 152 may reconfigure the m-CU-UP 154 with new TNL parameters associated with the target donor DU 142 for F1-U transmission between the IAB node 110 and the m-CU-UP 154. Then, the F1-U service may be restored 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 has successfully migrated to the target donor 140, and it may send / receive data to / from the m-CU 150 on the 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 service mapping to the relevant backhaul RLC channel and relay the downlink data to the IAB DU 112 via the wireless backhaul. Uplink data is sent from the IAB DU 112 to the m-CU-UP 154 in the reverse direction.

[0071] In the process 200 discussed above, the backhaul configuration associated with the IAB node 110 is transmitted from the source donor 130 to the target donor 140, so that the target donor 140 can configure the backhaul link for the IAB node 110 in an efficient manner during the switching process. The source donor 130 also notifies the target donor 140 of the information of the m-CU 150 that controls the IAB node 110, and the target donor 140 can establish an Xn connection with the m-CU 150 and send TNL parameters to the m-CU 150. It will help to switch the F1 service between the IAB node 110 and the m-CU 150 via the target donor 140 to a new path. The m-CU 150 can also receive a switching indication from the source donor 130 and / or the target donor 140. According to the switching indication, the m-CU 150 can know the current stage of the switching process, and it can suspend and resume the transmission between the m-CU 150 and the IAB node 110 in a timely manner. It helps to efficiently switch the IAB node 110 and maintain service continuity of the UE connected to the IAB node 110. In addition, the mobility of the IAB node 110 is limited to the backhaul link, and it will not affect the UE connected to the IAB node 110 because the m-CU 150 for controlling the IAB node 110 and the connected UE does not change before and after the switching process.

[0072] Figure 6 Flowchart of an example method 400 for inter-donor mobility of IAB nodes according to an example embodiment of the present disclosure is shown. Method 400 may be implemented at a source IAB donor (e.g., source IAB donor 130 discussed above). It should be understood that the steps shown in dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, method 400 may also include one or more steps performed at source IAB donor 130, as described above with respect to Figure 4 It should also be understood that the above Figure 4 Details of some of the steps in process 400 are discussed, and process 400 will be described here in a simplified manner.

[0073] At block 410 , the source donor 130 may decide to switch the IAB node 110 from the source donor 130 to the target donor 140 , for example, based on the measurement report received from the IAB node 110 .

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

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

[0076] At block 430 , source donor 130 may receive a confirmation message from target donor 140 in response to the handover request.

[0077] At block 440, the source donor 130 may send a first handover indication to the m-CU 150. The first handover indication may indicate a current stage of a handover process for the IAB node 110. In some example embodiments, the first handover indication may be sent when the source donor 130 receives a measurement report from the IAB node 110, when the source donor 130 sends a handover request to the target donor 140, when the source donor 130 receives a handover confirmation 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 include information associated with the target donor 140. For example, the first handover indication may include an identifier of a target cell or a target donor DU 142 supporting the target cell, and an identifier of a target donor CU 144 associated with the target donor DU 142. The first handover indication may also include an identifier of the IAB node 110 to be switched.

[0078] Figure 7 Flowchart of an example method 500 for inter-donor mobility of IAB nodes according to an example embodiment of the present disclosure is shown. The method 500 may be implemented at a target IAB donor (e.g., the target IAB donor 140 discussed above). It should be understood that the steps shown in dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, the method 500 may also include one or more steps performed at the target IAB donor 140, as described above with respect to Figure 4 It should also be understood that the above Figure 4 Details of some of the steps in process 500 are discussed, and process 500 will be described here in a simplified manner.

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

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

[0081] At block 520 , the target donor 140 may send an acknowledgment to the source donor 130 for the switch request.

[0082] At block 530 , the target donor 140 may establish a connection, such as an Xn connection, with the m-CU 150 .

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

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

[0085] At block 550, the target donor 140 may send a transport configuration including 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 to the m-CU 150 in the second handover indication. In some other example embodiments, the target donor 140 may send the transport configuration to the m-CU 150 in a separate message, for example, in an IAB Transport Migration Management Response message or in an IAB Transport Migration Modification Request message.

[0086] Figure 8 Flowchart of an example method 600 for inter-donor mobility of IAB nodes according to an example embodiment of the present disclosure is shown. The method 600 may be implemented at a central node (e.g., the m-CU 150 described above). It should be understood that the steps shown in dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, the method 600 may also include one or more steps performed at the m-CU 150, as described above with respect to Figure 4 It should also be understood that the above Figure 4 Details of some of the steps in process 600 are discussed, and process 600 will be described here in a simplified manner.

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

[0088] In some example embodiments, the handover indication includes a first indication received from source donor 130 and / or a second indication received from target donor 140. The first indication may indicate that a measurement report triggering handover of IAB node 110 is received at source donor 130, a handover request is sent from source donor 130 to target donor 140, a confirmation message in response to the handover request is received at source donor 130 from target donor 140, or a handover command is sent from source donor 130 to IAB node 110. The second indication may indicate that a handover request is received at target donor 140, a confirmation message in response to the handover request is sent from target donor 140 to source donor 130, or a handover completion message from IAB node 110 is received at target donor 140.

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

[0090] At block 630, the m-CU 150 may receive a transport configuration including TNL parameters from the target donor 140. In some example embodiments, the transport configuration may be received in a second handover indication from the target donor 140. In some other example embodiments, the transport configuration may be received in a separate message, such as an IAB Transport Migration Management Response message or an IAB Transport Migration Modification Request message from the target donor 140.

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

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

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

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

[0095] It should be understood that the intra-donor CU inter-donor DU mobility process 700 includes a subset of the signaling / messages in the inter-donor mobility process 200, because the signaling / messages between the source donor CU and the target donor CU are not required in the intra-donor CU inter-donor DU mobility process 700. In other words, the signaling / messages of the intra-donor CU inter-donor DU mobility process 700 are similar to the signaling / messages included in the inter-donor mobility process 200. Therefore, the intra-donor CU inter-donor DU mobility process 700 will be described in a simplified manner here, and some details of the steps in the process 700 can be referred to the above description of the steps in the process 700. Figure 4 Description of process 200.

[0096] At the beginning of the intra-donor CU inter-donor DU mobility process 700, it is assumed that the IAB MT 114 of the mobile IAB node 110 is RRC connected to the source cell served by the source / first donor DU 132, which is associated with the source donor CU 134 of the IAB donor 130 and has been configured with a backhaul bearer, backhaul RLC bearer / channel, PDU session or QoS flow to carry F1 traffic between the m-CU 150 and the IAB DU 112, as described above with respect to Figures 1A-1CMentioned. F1 (including F1-C and F1-U) traffic can be routed via the first donor DU 132. For example, the first donor DU 132 can map the downlink F1 traffic to the relevant backhaul RLC channel and relay the downlink F1 traffic to the IAB DU 112 through the wireless backhaul. The IABDU 112 then transmits the downlink data to a destination UE (not shown), which is connected to the IAB DU 112 via an access link. The uplink F1 traffic is sent from the IAB DU 112 to the m-CU 150 in the reverse direction via the first donor DU 132. The IAB donor CU 134 may have an Xn interface with the m-CU 150.

[0097] 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 the signal strength of the cell supported by the second donor DU 136.

[0098] In response to the measurement report, the donor CU 134 may decide to switch the IAB node 110 from the first donor DU 132 to the second donor DU 136 at 712. Although the measurement report is described here as an example event that triggers the switching decision, it should be understood that the switching decision may also be triggered by other events, and the present disclosure is not limited to any specific trigger for the switching decision. The donor CU 134 may send a UE (IAB MT) context establishment request message to the second donor DU 136 at 714 to create a UE context and configure the backhaul link of the IAB MT 114. The UE context establishment request may contain a configuration of a radio bearer (e.g., SRB and DRB) or a backhaul RLC bearer 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 a PDU session and QoS flow for the backhaul link of the IAB node 110. At 716, the second donor DU 136 may respond to the donor CU 134 with a UE context establishment response message.

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

[0100] At 720, the donor CU 134 may send a switching indication to the m-CU-CP 152 to notify the m-CU 150 of the ongoing mobility procedure. The switching indication may include an indicator indicating the current stage of the switching procedure and information associated with the second donor DU 136 and the IAB node 110, so that the m-CU-CP 152 may know to which donor DU the IAB node 110 will be switched. In some example embodiments, the switching indication may also include a transmission configuration associated with the second donor DU 136. For example, the transmission configuration may include TNL parameters, such as a TNL address (i.e., an IP address), a tunnel endpoint identifier (TEID), and the use of the TNL address and TEID (for F1-C, F1-U, or both), which may be used for UP and / or CP data transmission between the m-CU 150 and the IAB DU 112 via the second donor DU 136. Although Fig. 9 Donor CU 134 is shown sending a handover indication when a handover command is sent to IAB node 110, but it should be understood that donor CU 134 may also send a handover indication when it receives a measurement report triggering a handover of IAB node 110 and / or at other times / opportunities, as described below.

[0101] In response to the switching indication, the m-CU 150 may suspend downlink transmissions to the IAB node 110 via the first donor DU 132 at 722. For example, the m-CU-CP 152 may suspend 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 may no longer be available. In addition, the m-CU-CP 152 may instruct the m-CU-UP 154 to suspend F1-U transmissions to the IAB node 110. Upon receiving the instruction, the m-CU-UP 154 may begin buffering UP data for the IAB node 110.

[0102] 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. Using the RRC configuration received in the handover command message, a conventional RA procedure may be performed for the IAB MT 114 to connect to the second donor DU 136. The IAB MT 114 may also establish a radio bearer, a backhaul RLC bearer, a PDU session, and / or a QoS flow for a backhaul link. 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.

[0103] 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. Based on the indication, the m-CU-CP 152 knows that the IAB node 110 has been 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 transmission between the IAB node 110 and the m-CU 150. In some example embodiments, the IAB donor CU 134 may also send a transmission configuration including TNL parameters associated with the second donor DU 136 to the m-CU-CP 152 at step 728.

[0104] At 730, the transport connection between the m-CU 150 and the IAB node 110 may be reconfigured so that the F1 service between the m-CU 150 and the IAB node 110 via the second donor DU 136 may be restored. Step 730 may be similar to the above-described process with reference to FIG. 1 , except that the operations performed by the target donor CU 144 in process 300 are performed here at the IAB donor CU 134. Figure 5 Process 300 discussed. For example, the IAB DU 112 may establish a new SCTP association with the m-CU-CP 152 using the new TNL address (e.g., received at 718). 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 service to be transported via the second donor DU 136. The message may include F1 service related configurations, such as backhaul information of 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 anchored in the second donor DU 136 for the requested F1 service. Then, the F1-C traffic between the IAB node 110 and the m-CU-CP 152 via the second donor DU 136 may be resumed.

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

[0106] 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 F1-U transmission between the IAB node 110 and the m-CU-UP 154. Then, 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 has successfully migrated to the second donor DU 136, and it may send / receive data to / from the m-CU 150 via the second donor DU 136 on the F1 interface.

[0107] Fig.10 Flowchart of an example method 800 for intra-donor CU inter-donor DU mobility of an IAB node according to an example embodiment of the present disclosure is shown. The method 800 may be implemented at an IAB donor (e.g., the IAB donor 130 discussed above). It should be understood that the steps shown in dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, the method 800 may also include one or more steps performed at the IAB donor 130, as described above with respect to Fig. 9 It should also be understood that the above Fig. 9 Details of some of the steps in process 800 are discussed, and process 800 will be described here in a simplified manner.

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

[0109] At block 820, the IAB donor 130 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 of the IAB node 110, and a new TNL address assigned to the IAB node 110.

[0110] At block 830, the IAB donor 130 may send an indication to the m-CU 150 indicating the switching of the IAB node 110. The switching indication may include an indicator indicating the current stage of the switching process and information associated with the second donor DU 136 and the IAB node 110, so that the m-CU 150 may know to which donor DU the IAB node 110 will be switched. In some example embodiments, the switching indication may also include a transmission configuration associated with the second donor DU 136. For example, the transmission configuration may include TNL parameters such as a TNL address (i.e., an IP address), a tunnel endpoint identifier (TEID), and the use of the TNL address and TEID (for F1-C, F1-U, or both), which may be used for UP and / or CP data transmission between the m-CU 150 and the IAB node 110 via the second donor DU 136.

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

[0112] At block 840, the IAB donor 130 may send a transport configuration including 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 a handover indication to the m-CU 150. In some other example embodiments, the IAB donor 130 may send the transport configuration to the m-CU 150 in a separate message, such as an IAB Transport Migration Management Response message or an IAB Transport Migration Modification Request message.

[0113] Fig.11 Flowchart of an example method 900 for intra-donor CU inter-donor DU mobility for an IAB node according to an example embodiment of the present disclosure is shown. The method 900 may be implemented at a central node (e.g., the m-CU 150 described above). It should be understood that the steps shown in dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, the method 900 may also include one or more steps performed at the m-CU 150, as described above with respect to Fig. 9 It should also be understood that the above Fig. 9 Details of some of the steps in process 900 are discussed, and process 900 will be described here in a simplified manner.

[0114] At block 910, the m-CU 150 may receive an indication from the IAB donor 130 indicating a switch of the IAB node 110 from the first donor DU 132 to the 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.

[0115] The handover indication may include an indicator indicating a current stage of a handover procedure associated with IAB node 110. In some example embodiments, the handover indication may indicate that a measurement report triggering a handover of IAB node 110 is received at IAB donor 130, a handover command is sent from IAB donor 130 to IAB node 110, or a handover complete message from IAB node 110 is received at IAB donor 130.

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

[0117] At block 930, the m-CU 150 may receive a transport configuration including TNL parameters for the second donor DU 136 from the IAB donor 130. In some example embodiments, the transport configuration may be received in a 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).

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

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

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

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

[0122] refer to Fig.12 , the first network device 1100 may include one or more processors 1111, one or more memories 1112, and one or more transceivers 1113 interconnected by 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 a series of lines on a motherboard or integrated circuit, optical fiber, optical device, or other optical communication device, etc. Each of the one or more transceivers 1113 may include a receiver and a transmitter 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) via 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 cause the first network device 1100 to perform operations and processes related to the mobile IAB node 110 as described above when executed by the one or more processors 1111.

[0123] The second network device 1200 may include one or more processors 1211, one or more memories 1212, one or more transceivers 1213, and one or more network interfaces 1217 interconnected by one or more buses 1214. 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, optical fiber, optical device, or other optical communication device. Each of the one or more transceivers 1213 may include a receiver and a transmitter 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 one or more antennas 1216. One or more network interfaces 1217 may provide a wired or wireless communication link, and the second network device 1200 may communicate with other network devices, entities, elements, or functions through a wired or wireless communication link. The second network device 1200 may communicate with the third network device 1300 via a connection 1218. 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 processes related to the IAB source donor 130 and / or the IAB target donor 140 .

[0124] The third network device 1300 may include one or more processors 1311, one or more memories 1312, and one or more network interfaces 1317 interconnected by 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, optical fiber, optical device, or other optical communication device. The third network device 1300 may operate as a RAN node (e.g., a central node) and communicate with the second network device 1200 by wired or wireless communication through one or more links. One or more network interfaces 1317 may provide a wired or wireless communication link, and the third network device 1300 may communicate with other network devices, entities, elements, or functions through a wired or wireless communication link. One or more memories 1312 may include computer program code 1315. One or more memories 1312 and computer program code 1315 may be configured to cause the third network device 1300 to perform operations and processes related to the m-CU 150 as described above when executed by one or more processors 1311.

[0125] The one or more processors 1111, 1211, and 1311 discussed above may be any suitable type suitable for the local technology network, and may include a general purpose processor, a special purpose processor, a microprocessor, a digital signal processor (DSP), one or more processors in a processor-based multi-core processor architecture, and one or more of those special purpose processors such as those developed based on a field programmable gate array (FPGA) and an application specific integrated circuit (ASIC). The one or more processors 1111, 1211, and 1311 may be configured to control other elements of the network device and operate in cooperation with them to implement the above-mentioned processes.

[0126] One or more memories 1112, 1212, and 1312 may include at least one storage medium in various forms, such as volatile memory and / or non-volatile memory. Volatile memory may include, but is not limited to, for example, random access memory (RAM) or cache. Non-volatile memory may include, but is not limited to, read-only memory (ROM), hard disk, flash memory, etc. In addition, one or more memories 1112, 1212, and 1312 may include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or equipment, or any combination thereof.

[0127] It should be understood that the blocks in the drawings can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks can be implemented using software and / or firmware (e.g., machine executable instructions stored in a storage medium). In addition to or in place of machine executable instructions, some or all of the blocks in the drawings can be implemented at least in part by one or more hardware logic components. For example, but not limited to, 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), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0128] Some exemplary embodiments also provide computer program codes or instructions that can cause a device or apparatus to perform the above-mentioned processes when executed by one or more processors. The computer program code for executing the processes of the exemplary embodiments can be written in any combination of one or more programming languages. The computer program code can be provided to one or more processors or controllers of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a separate software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0129] Some exemplary embodiments also provide a computer program product or computer readable medium in which computer program code or instructions are stored. A computer readable medium may be any tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or apparatus. A 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, device, or device, or any suitable combination of the foregoing. More specific examples of machine readable storage media would include an electrical connection with one or more wires, a portable computer disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0130] In addition, although the operations are depicted in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown or in a sequential order, or performing all the operations shown to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but should be interpreted as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0131] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims.

Claims

1. A first radio access network node, comprising: at least one processor; as well as 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 to at least: sending a handover request to a second radio access network node to handover 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 indicating a 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; as well as An acknowledgement message is received from the second radio access network node in response to the handover request.

2. The first radio access network node according to 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 an integrated access and backhaul node, and / or The indication of the central node comprises an identifier or an address of a control plane of the central node and / or an identifier or an address of a user plane of the central node.

3. 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 to at least: A first indication is sent to the central node, the first indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.

4. The first radio access network node according to claim 3, wherein the first indication is sent when: When the first radio access network node receives a measurement report from the integrated access and backhaul node triggering the handover of the integrated access and backhaul node, When the first radio access network node sends the handover request to the second radio access network node, When the first radio access network node receives the confirmation message from the second radio access network node, or When the first radio access network node sends a handover command to the integrated access and backhaul node.

5. 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.

6. A second radio access network node, comprising: at least one processor; as well as 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 to at least: receiving, from a first radio access network node, a handover request to handover 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 indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node; as well as An acknowledgement message in response to the handover request is sent to the first radio access network node.

7. The second radio access network node according to 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 an address of a control plane of the central node and / or an identifier or an address of a user plane of the central node.

8. 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 to at least: A second indication is sent to the central node, the second indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.

9. The second radio access network node according to claim 8, wherein the second indication is sent when: When the second radio access network node receives the handover request from the first radio access network node, When the second radio access network node sends the confirmation message to the first radio access network node, or When the second radio access network node receives a handover complete message from the integrated access and backhaul node.

10. 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 to at least: A connection is established between the second radio access network node and the central node for transmission of the second indication.

11. 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 to at least: A transmission configuration including transmission network layer parameters associated with the second radio access network node is sent to the central node.

12. A central node, comprising: at least one processor; as well as at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the central node to at least: receiving an indication from a first radio access network node and / or a second radio access network node, the indication indicating a 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 equipment connected to the integrated access and backhaul node; as well as In response to the indication, transmission between the central node and the integrated access and backhaul node via the first radio access network node is suspended.

13. The central node according to 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 instruction indicates: 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, a confirmation message from the second radio access network node in response to the handover request is received at the first radio access node, or a handover command is sent from the first radio access network node to the integrated access and backhaul node; The second instruction indicates: the handover request from the first radio access network node is received at the second radio access network node, the confirmation message in response 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 from the integrated access and backhaul node is received at a second radio access network node.

14. The central node of claim 12, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the central node to at least: receiving a transmission configuration including transmission network layer parameters from the second radio access network node; and Based at least in part on the received transmission configuration, transmission between a control plane of the central node and the integrated access and backhaul node via the second radio access network node is resumed.

15. The central node of claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the central node to at least: reconfiguring the 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 transmission configuration; and Transmission between the user plane of the central node and the integrated access and backhaul node via the second radio access network node is resumed.

16. A radio access network node, comprising: at least one processor; as well as 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 to at least: sending a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to handover 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; as well as An indication is sent to a central node serving one or more user equipment connected to the integrated access and backhaul node, the indication indicating the switching of the integrated access and backhaul node.

17. The radio access network node according to claim 16, wherein the indication is sent when: When the radio access network node receives a measurement report from the integrated access and backhaul node triggering the handover of the integrated access and backhaul node, When the radio access network node sends the handover command to the integrated access backhaul node, or When the radio access network node receives a handover complete message from the integrated access and backhaul node.

18. 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.

19. 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 to at least: A transmission configuration including transmission network layer parameters associated with the second distributed unit of the radio access network node is sent to the central node.

20. A central node, comprising: at least one processor; as well as at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the central node to at least: receiving an indication from a radio access network node, the indication indicating a 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; as well as In response to the received indication, transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node is suspended, the central node serving one or more user equipment connected to the integrated access and backhaul node.

21. The central node according to 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 from the integrated access and backhaul node is received at the radio access network node.

22. The central node of claim 20, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the central node to at least: receiving, from the radio access network node, a transmission configuration comprising transmission network layer parameters for the second distributed unit of the radio access network node; and Based at least in part on the received transmission configuration, 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 is resumed.

23. The central node of claim 22, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the central node to at least: reconfiguring the 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 transmission configuration; and The 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 is resumed.

24. A method implemented at a first radio access network node, comprising: sending a handover request to a second radio access network node to handover 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 indicating a 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; as well as An acknowledgement message is received from the second radio access network node in response to the handover request.

25. 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 integrating the access and backhaul nodes, and / or The indication of the central node comprises an identifier or an address of a control plane of the central node and / or an identifier or an address of a user plane of the central node.

26. The method of claim 24, further comprising: A first indication is sent to the central node, the first indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.

27. The method of claim 26, wherein the first indication is sent when When the first radio access network node receives a measurement report from the integrated access and backhaul node triggering the handover of the integrated access and backhaul node, When the first radio access network node sends the handover request to the second radio access network node, When the first radio access network node receives the confirmation message from the second radio access network node, or When the first radio access network node sends a handover command to the integrated access and backhaul node.

28. 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.

29. A method implemented at a second radio access network node, comprising: receiving, from a first radio access network node, a handover request to handover 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 indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node; as well as An acknowledgement message in response to the handover request is sent to the first radio access network node.

30. 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 an address of a control plane of the central node and / or an identifier or an address of a user plane of the central node.

31. The method of claim 29, further comprising: A second indication is sent to the central node, the second indication indicating the handover of the integrated access and backhaul node from the first radio access node to the second radio access node.

32. The method of claim 31 , wherein the second indication is sent when: when the second radio access network node receives the handover request from the first radio access network node; When the second radio access network node sends the confirmation message to the first radio access network node, or When the second radio access network node receives a handover complete message from the integrated access and backhaul node.

33. The method of claim 32, further comprising: A connection is established between the second radio access network node and the central node for transmission of the second indication.

34. The method of claim 29, further comprising: A transmission configuration including transmission network layer parameters associated with the second radio access network node is sent to the central node.

35. A method implemented at a central node, comprising: receiving an indication from a first radio access network node and / or a second radio access network node, the indication indicating a 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 equipment connected to the integrated access and backhaul node; as well as In response to the indication, transmission between the central node and the integrated access and backhaul node via the first radio access network node is suspended.

36. 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 instruction indicates: 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, a confirmation message from the second radio access network node in response to the handover request is received at the first radio access node, or a handover command is sent from the first radio access network node to the integrated access and backhaul node; The second instruction indicates: the handover request from the first radio access network node is received at the second radio access network node, the confirmation message in response 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 from the integrated access and backhaul node is received at the second radio access network node.

37. The method of claim 35, further comprising: receiving a transmission configuration including transmission network layer parameters from the second radio access network node; as well as Based at least in part on the received transmission configuration, transmission between a control plane of the central node and the integrated access and backhaul node via the second radio access network node is resumed.

38. The method of claim 37, further comprising: reconfiguring the 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 transmission configuration; as well as Transmission between the user plane of the central node and the integrated access and backhaul node via the second radio access network node is resumed.

39. 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 handover 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; as well as An indication is sent to a central node serving one or more user equipment connected to the integrated access and backhaul node, the indication indicating the switching of the integrated access and backhaul node.

40. The method of claim 39, wherein the indication is sent when: When the radio access network node receives a measurement report from the integrated access and backhaul node triggering the handover of the integrated access and backhaul node, When the radio access network node sends the handover command to the integrated access backhaul node, or When the radio access network node receives a handover complete message from the integrated access and backhaul node.

41. 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.

42. The method of claim 39, further comprising: A transmission configuration including transmission network layer parameters associated with the second distributed unit of the radio access network node is sent to the central node.

43. A method implemented at a central node, comprising: receiving an indication from a radio access network node, the indication indicating a 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; as well as In response to the received indication, transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node is suspended, the central node serving one or more user equipment connected to the integrated access and backhaul node.

44. 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 from the integrated access and backhaul node is received at the radio access network node.

45. The method of claim 43, further comprising: receiving, from the radio access network node, a transmission configuration comprising transmission network layer parameters for the second distributed unit of the radio access network node; as well as Based at least in part on the received transmission configuration, 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 is resumed.

46. ​​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 transmission configuration; as well as The 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 is resumed.

47. An apparatus comprising: means for sending a handover request to a second radio access network node to handover 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 indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node; as well as Means for receiving, from the second radio access network node, an acknowledgement message in response to the handover request.

48. An apparatus comprising: means for receiving, from a first radio access network node, a handover request to handover 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 indicating a backhaul configuration of the integrated access and backhaul node and / or an indication of a central node serving one or more user equipment connected to the integrated access and backhaul node; as well as Means for sending a confirmation message in response to the handover request to the first radio access network node.

49. An apparatus comprising: means for receiving, at a central node, an indication from a first radio access network node and / or a second radio access network node, the indication indicating a 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 equipment connected to the integrated access and backhaul node; as well as 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.

50. 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 handover 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; as well as Means for sending an indication to a central node serving one or more user equipment connected to the integrated access and backhaul node, the indication indicating the switching of the integrated access and backhaul node.

51. An apparatus comprising: means for receiving, at a central node, an indication from a radio access network node, the indication indicating a 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; as well as Means for suspending transmissions 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 equipment connected to the integrated access and backhaul node.

52. A computer program product embodied in at least one computer readable medium and comprising instructions which, when executed by at least one processor of a first radio access network node, cause the first radio access network node to at least: sending a handover request to a second radio access network node to handover an integrated access and backhaul node to the second radio access network node, the handover request comprising configuration information indicating a 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 An acknowledgement message is received from the second radio access network node in response to the handover request.

53. A computer program product embodied in at least one computer readable medium and comprising instructions which, when executed by at least one processor of a second radio access network node, cause the second radio access network node to at least: receiving, from a first radio access network node, a handover request to handover 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 indicating a 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 An acknowledgement message in response to the handover request is sent to the first radio access network node.

54. A computer program product, embodied in at least one computer-readable medium and comprising instructions, which when executed by at least one processor of a central node, cause the central node to at least: receiving an indication from a first radio access network node and / or a second radio access network node, the indication indicating a 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 In response to the indication, transmission between the central node and the integrated access and backhaul node via the first radio access network node is suspended.

55. A computer program product embodied in at least one computer readable medium and comprising instructions which, when executed by at least one processor of a radio access network node, cause the radio access network node to at least: sending a handover command to an integrated access and backhaul node, the handover command comprising one or more parameters to be used to handover 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 An indication is sent to a central node serving one or more user equipment connected to the integrated access and backhaul node, the indication indicating the switching of the integrated access and backhaul node.

56. A computer program product, embodied in at least one computer-readable medium and comprising instructions, which when executed by at least one processor of a central node, cause the central node to at least: receiving an indication from a radio access network node, the indication indicating a 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 In response to the received indication, transmission between the central node and the integrated access and backhaul node via the first distributed unit of the radio access network node is suspended, the central node serving one or more user equipment connected to the integrated access and backhaul node.

Images