WO2022198400A1

WO2022198400A1 - Methods, devices, and computer readable medium for communication

Info

Publication number: WO2022198400A1
Application number: PCT/CN2021/082140
Authority: WO
Inventors: Zhe Chen; Gang Wang
Original assignee: Nec Corporation
Priority date: 2021-03-22
Filing date: 2021-03-22
Publication date: 2022-09-29

Abstract

According to embodiments of the present disclosure, solutions on dual transmission handover have been proposed. According to embodiments of the present disclosure, a first integrated access backhaul (IAB) node receives a downlink (DL) transfer status request from a donor centralized unit (CU). The DL transfer status request at least indicates routing information related to a second IAB node. The donor CU determines that the second IAB node is to be handed over from the first IAB node to a third IAB node. The first IAB node transmits a DL transfer status response to the donor CU or an anchor IAB node of the first IAB node. In this way, it can reduce handover loss.

Description

METHODS, DEVICES, AND COMPUTER READABLE MEDIUM FOR COMMUNICATION

TECHNICAL FIELD

Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices, and computer readable medium for communication.

BACKGROUND

In recent communication networks, network speed has been improved. The communication networks are expected to provide low latency and reliability for consumers and industries. In order to achieve super-fast data rates and ultra-low latency, higher frequency electromagnetic waves (for example, millimeter waves) are introduced into the communication networks. However, signals transmitted with higher frequency electromagnetic waves are easily blocked by objects. In this situation, a technology of Integrated Access and Backhaul (IAB) has been introduced. Further, handover procedures are very important to ensure communication qualities. In cellular telecommunication, the term “handover (HO) ” refers to a process of transferring an ongoing cell or data session from one channel to another channel. The handover procedures may be different in different scenarios. Therefore, applying the handover to the IAB scenario is worth studying.

SUMMARY

In general, example embodiments of the present disclosure provide a solution for communication.

In a first aspect, there is provided a method for communication. The method comprises receiving, at a first integrated access backhaul (IAB) node, a downlink (DL) transfer status request from a donor centralized unit (CU) , the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and transmitting, to a communication device, a DL transfer status response.

In a second aspect, there is provided a method for communication. The method comprises transmitting, at a donor centralized unit (CU) , a downlink (DL) transfer status request to a first integrated access backhaul (IAB) node, the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

In a third aspect, there is provided a method for communication. The method comprises receiving, at an anchor integrated access backhaul (IAB) node which is a parent IAB node of both a first IAB node and a third IAB node, a downlink (DL) transfer information from a first communication device, the DL transfer information at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to the third IAB node by a donor centralized unit (CU) .

In a fourth aspect, there is provided a method for communication. The method comprises transmitting, at a donor centralized unit (CU) and to an ancestor integrated access backhaul (IAB) node of a first IAB node, a first data transmission confirm request to confirm whether the parent IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and receiving, from the parent IAB node, a first response to the first data transmission confirm request.

In a fifth aspect, there is provided a method for communication. The method comprises receiving, at a parent integrated access backhaul (IAB) node of a first IAB node and from a donor centralized unit (CU) , a first data transmission confirm request to confirm whether the parent IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and transmitting, to the donor CU, a first response to the first data transmission confirm request.

In a sixth aspect, there is provided a method for communication. The method comprises receiving, at a first integrated access backhaul (IAB) node and from a first communication, a data transmission confirm request to confirm whether the first IAB node has transmitted a predetermined number of data packets to a second IAB node, the data transmission confirm request indicating routing information related to the second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by a donor centralized unit (CU) ; and transmitting, to the first communication device, a response to the data transmission confirm request.

In a seventh aspect, there is provided an IAB node. The IAB node comprises a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the IAB node device to perform method according to the first aspect or the sixth aspect.

In an eighth aspect, there is provided a donor DU. The donor DU comprises a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the donor DU to perform method according the second aspect or the fourth aspect.

In a ninth aspect, there is provided an IAB node. The IAB node comprises a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the IAB node device to perform method according the third aspect or the fifth aspect.

In an tenth aspect, there is provided a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to carry out the method according to any one of the first, second, third, fourth, fifth, or sixth aspect.

Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Through the more detailed description of some example embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

Fig. 1 is a schematic diagram of a communication environment in which embodiments of the present disclosure can be implemented;

Fig. 2 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 3 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 4 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 5 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 6 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 7 illustrates a signaling flow for lossless handover according to some embodiments of the present disclosure;

Fig. 8 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure;

Fig. 9 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure;

Fig. 10 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure;

Fig. 11 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure;

Fig. 12 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure;

Fig. 13 is a flowchart of an example method for lossless handover according to some embodiments of the present disclosure; and

Fig. 14 is a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

As used herein, the term “network device” refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB) , an Evolved NodeB (eNodeB or eNB) , a NodeB in new radio access (gNB) a Remote Radio Unit (RRU) , a radio head (RH) , a remote radio head (RRH) , a low power node such as a femto node, a pico node, a satellite network device, an aircraft network device, and the like. For the purpose of discussion, in the following, some example embodiments will be described with reference to eNB as examples of the network device.

As used herein, the term “terminal device” refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs) , portable computers, tablets, wearable devices, internet of things (IoT) devices, Internet of Everything (IoE) devices, machine type communication (MTC) devices, device on vehicle for V2X communication where X means pedestrian, vehicle, or infrastructure/network, or image capture devices such as digital cameras, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

In one embodiment, the terminal device may be connected with a first network device and a second network device. One of the first network device and the second network device may be a master node and the other one may be a secondary node. The first network device and the second network device may use different radio access technologies (RATs) . In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is eNB and the second RAT device is gNB. Information related with different RATs may be transmitted to the terminal device from at least one of the first network device and the second network device. In one embodiment, a first information may be transmitted to the terminal device from the first network device and a second information may be transmitted to the terminal device from the second network device directly or via the first network device. In one embodiment, information related with configuration for the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related with reconfiguration for the terminal device configured by the second network device may be transmitted to the terminal device from the second network device directly or via the first network device.

Communications discussed herein may use conform to any suitable standards including, but not limited to, New Radio Access (NR) , Long Term Evolution (LTE) , LTE-Evolution, LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , Code Division Multiple Access (CDMA) , cdma2000, and Global System for Mobile Communications (GSM) and the like. Furthermore, the communications may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.85G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , and the sixth (6G) communication protocols. The techniques described herein may be used for the wireless networks and radio technologies mentioned above as well as other wireless networks and radio technologies.

The term “circuitry” used herein may refer to hardware circuits and/or combinations of hardware circuits and software. For example, the circuitry may be a combination of analog and/or digital hardware circuits with software/firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor (s) , software, and memory (ies) that work together to cause an apparatus, such as a terminal device or a network device, to perform various functions. In a still further example, the circuitry may be hardware circuits and or processors, such as a microprocessor or a portion of a microprocessor, that requires software/firmware for operation, but the software may not be present when it is not needed for operation. As used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (s) or a portion of a hardware circuit or processor (s) and its (or their) accompanying software and/or firmware.

As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “includes” and its variants are to be read as open terms that mean “includes, but is not limited to. ” The term “based on” is to be read as “based at least in part on. ” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” The terms “first, ” “second, ” and the like may refer to different or same objects. Other definitions, explicit and implicit, may be included below.

In some examples, values, procedures, or apparatus are referred to as “best, ” “lowest, ” “highest, ” “minimum, ” “maximum, ” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

As mentioned above, IAB is an important feature in 5G New Radio (NR) that enables rapid and cost-effective millimeter wave deployments through self-backhauling in the same spectrum. The term “wireless self-backhauling” used herein refers to a technology that uses the same wireless channel for coverage and backhaul connectivity to other base stations. It can achieve greater performance, more efficient use of spectrum resources and lowers equipment costs, while also reduce the reliance on the availability of wired backhaul at each access node location. In an IAB system, there are two types of network devices, IAB node and IAB donor. In other words, IAB is a multi-hop approach to network deployment and allows deployment of millimeter wave base stations with or without fiber backhaul transport. It works by having a fraction of the deployed network device act as donor nodes, using a fiber/wired connection. The remainder without a wired connection is called IAB nodes. Both types of BSs generate an equivalent cellular coverage area and appear identical to user equipment (UE) in its coverage area. The Donor distributed unit (DU) is a conventional fiber-fed BS connected to the centralized unit (CU) using an F1 interface. The IAB node may serve as a first hop or second hop node. Both donor and IAB nodes also directly support UEs multiplexed with the backhaul Ur interface. The Uu interface is directly between a UE and an IAB or donor node. The channel between two IAB nodes can be called radio link control (RLC) channel.

When IAB node is serving a UE, it works as a distributed unit (DU) to the UE, and a mobile terminal (MT) to its parent IAB node. Backhaul RLC channel (s) are setup between the MT part and the parent nodes DU part and adaptation layer called Backhaul Adaptation Protocol (BAP) is agreed to be on top of the radio link control (RLC) layer. The IAB-node DU part connects to the IAB-donor CU with F1 interface which is enhanced to support IAB functions. F1 packets (GTP-U/UDP/IP for user plane (UP) and F1AP/SCTP/IP for control plane (CP) ) are transported on top of the adaptation layer. IAB thus implements L2 relaying. An IAB node represents a co-located resource providing NR access coverage and backhauling over the air interface. As such, an IAB node may take on both the personality of UE (MT part) for transferring backhaul traffic or that of gNB (or gNB-DU) serving connected UEs and forwarding backhaul traffic to the next hop.

In multi-link IAB architecture, since the RLC automatic repeat request (ARQ) is hop by hop, when Donor CU sends a RLC protocol data unit (PDU) to a next hop IAB, the next hop IAB feedbacks an acknowledgement (ACK) to Donor CU and the Donor CU assumes that the RLC PDU is successfully transmitted. However, it is possible that this RLC PDU is not transmitted to the migrating IAB node yet, which will cause data loss during handover.

In conventional NR handover, packet data convergence protocol (PDCP) re-establishment and PDCP recovery can be used to trigger PDCP status report, thus the gNB can issue PDCP re-transmission. However, during a procedure of intra-Donor IAB handover, the PDCP anchor is not changed, so it is not possible for UE to trigger PDCP re-establishment. Furthermore, the UE is attached to the access IAB node, it is the access IAB node which is going to perform handover, the UE keeps RLC connection to the access IAB node. So it is not possible for the UE to trigger PDCP recovery.

In order to solve at least part of the above problems and other potential problems, new solutions on lossless handover on IAB nodes are needed. According to embodiments of the present disclosure, a first integrated access backhaul (IAB) node receives a downlink (DL) transfer status request from a donor centralized unit (CU) . The DL transfer status request at least indicates routing information related to a second IAB node. The donor CU determines that the second IAB node is to be handed over from the first IAB node to a third IAB node. The first IAB node transmits a DL transfer status response to the donor CU or an anchor IAB node of the first IAB node. In this way, it can reduce handover loss.

Fig. 1 illustrates a schematic diagram of a communication system in which embodiments of the present disclosure can be implemented. The communication system 100, which is a part of a communication network, comprises a terminal device 110-1, a terminal device 110-2, ..., a terminal device 110-N, which can be collectively referred to as “terminal device (s) 110. ” The number N can be any suitable integer number.

The communication system 100 further comprises an IAB node 120-1, an IAB node 120-2, an IAB node 120-3, an IAB node 120-4, ..., a network device 120-M (not shown) which can be collectively referred to as “IAB node (s) 120. ” In some embodiments, the IAB node can be any suitable device. The number M can be any suitable integer number. As shown in Fig. 1, the communication system 100 may also a donor CU 130. It should be noted that the number of donor CUs shown in Fig. 1 is only an example. In the communication system 100, the IAB nodes 120 and the terminal devices 110 can communicate data and control information to each other. The IAB nodes 120 can communicate with each other. The donor CUs can also communicate with the IAB nodes 120. Only as an example, the IAB node 120-2 can be handed over from the IAB node 120-3 (i.e., a source IAB node) to the IAB node 120-4 (i.e., a target IAB node) . According to the topology shown in Fig. 1, the IAB node 120-5 can be regarded an ancestor/parent node of the IAB nodes 120-3 and 120-4. In this case, the IAB node 120-5 can be an anchor IAB node. The term “ancestor node” used herein can refer to an IAB node which is between the current IAB node and the donor. The term “descendant/child node” used herein can refer to an IAB node which is between the current IAB node and a terminal device. The numbers of devices shown in Fig. 1 are given for the purpose of illustration without suggesting any limitations.

Communications in the communication system 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) and the sixth generation (6G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Divided Multiple Address (CDMA) , Frequency Divided Multiple Address (FDMA) , Time Divided Multiple Address (TDMA) , Frequency Divided Duplexer (FDD) , Time Divided Duplexer (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Divided Multiple Access (OFDMA) and/or any other technologies currently known or to be developed in the future.

Embodiments of the present disclosure can be applied to any suitable scenarios. For example, embodiments of the present disclosure can be implemented at reduced capability NR devices. Alternatively, embodiments of the present disclosure can be implemented in one of the followings: NR multiple-input and multiple-output (MIMO) , NR sidelink enhancements, NR systems with frequency above 52.6GHz, an extending NR operation up to 71GHz, narrow band-Internet of Thing (NB-IOT) /enhanced Machine Type Communication (eMTC) over non-terrestrial networks (NTN) , NTN, UE power saving enhancements, NR coverage enhancement, NB-IoT and LTE-MTC, Integrated Access and Backhaul (IAB) , NR Multicast and Broadcast Services, or enhancements on Multi-Radio Dual-Connectivity.

Embodiments of the present disclosure will be described in detail below. Reference is first made to Fig. 2, which shows a signaling chart illustrating process 200 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 200 may involve the donor CU 130, the IAB nodes 120-5, 120-3 and 120-4. It should be noted that the process can involve any proper devices. In some embodiments, as shown in Fig. 1, the donor CU 130 can determine the IAB node 120-5 to be the anchor IAB node, since the IAB node 120-5 is the parent IAB node of the IAB nodes 120-3 and 120-4. In some embodiments, if both the IAB nodes 120-3 and 120-4 have a same redundant parent IAB node (for example, the IAB node 120-7 as shown in Fig. 1) , the donor CU 130 can select a parent IAB node with less load. For example, if the IAB node 120-5 has less load than the IAB node 120-7, the donor CU 130 can select the IAB node 120-5 to be the anchor IAB node.

The donor CU 130 can transmit 2005 a set of BAP PDUs to the IAB node 120-5. Only as an example, the donor CU 130 can send the BAP PDUs 1 2, and 3 to the IAB node 120-5. The IAB node 120-5 may transmit 2010 a subset of the BAP PDUs. For example, the IAB node 120-2 may only transmit the BAP PDU 1 to the IAB node 120-3.

The donor CU 130 may receive measurement results from the IAB node 120-2. For example, the donor CU 130 may receive a measurement of reference signal received power (RSRP) from the IAB node 120-2. Alternatively or in addition, the measurement may be reference signal received quality (RSRQ) . It should be noted that the measurement can be any proper type of measurements.

The donor CU 130 can make handover decision for the IAB node 120-2. The donor CU 130 can determine that the IAB node 120-2 to migrate/handover from the IAB node 120-3 to the IAB node 120-4. As discussed above, since the donor CU 130 can manage the IAB architecture link of the communication system 100, the donor CU 130 can configure the IAB node 120-5 to be the anchor IAB node which can retransmit/re-route one or more BAP PDUs which is/are not successfully delivered to the IAB node 120-3. In this situation, the donor CU 130 can transmit 2015 a downlink (DL) radio resource control (RRC) message to the IAB node 120-3. The DL RRC message may indicate the handover for the IAB node 120-2. The IAB node 120-3 can transmit an indication for the handover to the IAB node 120-2. It should be noted that the IAB node 120-2 can apply any proper handover procedure to migrate from the IAB node 120-3 to the IAB node 120-4.

The donor CU 130 can transmit 2020 a DL transfer status request to the IAB node 120-3. The DL transfer status request can comprise a first routing identity for the IAB node 120-2. For example, the first routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-3 (i.e., the source IAB node) . In addition, the DL transfer status request can comprise a second routing identity for the IAB node 120-2. For example, the second routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-4 (i.e., the target IAB node) . Alternatively or additionally, the DL transfer status request can comprise an address of the anchor IAB node. For example, as stated above, the IAB node 120-5 can be configured as the anchor IAB node by the donor CU 130. In this case, the DL transfer status request can comprise the address of the IAB node 120-5.

The IAB node 120-3 can transmit 2025 a DL transfer status response to the IAB node 120-5. The DL transfer status response can comprise a BAP sequence number (SN) of a BAP PDU which is the last BAP PDU successfully transmitted to the IAB node 120-2. Similarly, the DL transfer status response can comprise a first routing identity for the IAB node 120-2. For example, the first routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-3. In addition, the DL transfer status response can comprise a second routing identity for the IAB node 120-2. For example, the second routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-4. Alternatively or additionally, the DL transfer status response can comprise an address of the anchor IAB node. For example, the DL transfer status response can comprise the address of the IAB node 120-5.

After receiving the DL transfer status response from the IAB node 120-3, the IAB node 120-5 can determine whether the address of the anchor IAB node matches to its address. For example, since the donor CU 130 configures the IAB node 120-5 as the anchor IAB node, the address of the anchor IAB node in the DL transfer status response matches with the address of the IAB node 120-5. In this case, the IAB node 120-5 can understand that it is configured as the anchor IAB node.

The IAB node 120-5 can retransmit 2030 the one or more BAP PDUs which is/are not successfully delivered to the IAB node 120-3. For example, if the set of BAP PDUs comprises the BAP PDUs 1 2, and 3 and the BAP SN in the DL transfer status response is 1, the IAB node 120-5 can retransmit the BAP PDUs 2 and 3 to the IAB node 120-4. In this way, the unsuccessfully transmitted PDUs can be retransmitted as quickly as possible, thereby reducing handover loss.

In some embodiments, if the IAB node 120-3 has not transmitted BAP PDU1 to IAB2, the IAB node 120-3 can forward 2035 this BAP PDU1 to the IAB node 120-5. If the IAB node 120-5 has buffered the BAP PDU1, the IAB node 120-5 can discard 2040 the BAP PDU1. Alternatively, if the BAP PDU1 is not buffered, the IAB node 120-5 can retransmit the BAP PDU1 to the IAB node 120-4.

Embodiments of the present disclosure will be described in detail below. Reference is made to Fig. 3, which shows a signaling chart illustrating process 300 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 300 may involve the donor CU 130, the IAB nodes 120-5, 120-3, 120-2 and 120-4. It should be noted that the process can involve any proper devices.

In some embodiments, before the donor CU 130 makes handover decision for the IAB node 120-2, the donor CU 130 can select an ancestor IAB node of both IAB3 and IAB4 as the anchor node. If there are multiple anchor IAB nodes available in selection, the donor CU 130 can select the less loaded one as the anchor IAB node.

The donor CU 130 can transmit 3005 a set of BAP PDUs to the IAB node 120-5. Only as an example, the donor CU 130 can send the BAP PDUs 1 2, and 3 to the IAB node 120-5. The IAB node 120-5 may transmit 3010 a subset of the BAP PDUs. For example, the IAB node 120-2 may only transmit the BAP PDU 1 to the IAB node 120-3.

The donor CU 130 can transmit 3015 a re-routing configuration message to the IAB node 120-5. The re-routing configuration message can comprise a first routing identity for the IAB node 120-2. For example, the first routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-3. In addition, the re-routing configuration message can comprise a second routing identity for the IAB node 120-2. For example, the second routing identity can relate to the routing to the IAB node 120-2 through the IAB node 120-4.

After receiving the re-routing configuration from the donor CU 130, the IAB node 120-5 can re-route 3020 the set of BAP PDUs with first routing identity to the second routing identity. For example, the IAB node 120-5 can retransmit the BAP PDUs 1, 2 and 3 to the IAB node 120-4.

The donor CU 130 can transmit 3025 a DL RRC message to the IAB node 120-3. The DL RRC message may indicate the handover for the IAB node 120-2. The IAB node 120-3 can transmit an indication for the handover to the IAB node 120-2. It should be noted that the IAB node 120-2 can apply any proper handover procedure to migrate from the IAB node 120-3 to the IAB node 120-4 The IAB node 120-3 can transmit 3030 a RRC reconfiguration to the IAB node 120-2. The RRC reconfiguration can be used to migrate from the IAB node 120-3 to the IAB node 120-4.

The donor CU 130 can transmit 3035 a UE context release message to the IAB node 120-3. After receiving the UE context release message, the IAB node 120-3 can release the context of the IAB node 120-2. The IAB node 120-3 can forward 3040 one or more undelivered BAP PDUs in the IAB node 120-3 to the IAB node 120-5. In some embodiments, if the one or more undelivered BAP PDUs has buffered at the IAB node 120-5, the IAB node 120-5 can discard 3045 the forwarded BAP PDUs. The IAB node 120-5 can retransmit 3050 the one or more undelivered BAP PDUs to the IAB node 120-4. The one or more undelivered BAP PDUs can be re-routed to the IAB node 120-2 via the IAB node 120-4. The BAP PDU routing identity (i.e., the first routing identity) can be replicated with the new routing identity (i.e., the second routing identity) in the re-routing configuration.

Reference is made to Fig. 4, which shows a signaling chart illustrating process 400 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 400 may involve the donor CU 130, the IAB nodes 120-2, 120-3 and 120-4. It should be noted that the process can involve any proper devices.

The donor CU 130 can transmit a set of BAP PDUs to the IAB node 120-3. Only as an example, the donor CU 130 can send the BAP PDUs 1 2, and 3 to the IAB node 120-3. The donor CU 130 may receive measurement results from the IAB node 120-2. For example, the donor CU 130 may receive a measurement of reference signal received power (RSRP) from the IAB node 120-2. Alternatively or in addition, the measurement may be reference signal received quality (RSRQ) . It should be noted that the measurement can be any proper type of measurements. The donor CU 130 can make handover decision for the IAB node 120-2. The donor CU 130 can determine that the IAB node 120-2 to migrate/handover from the IAB node 120-3 to the IAB node 120-4.

The donor CU 130 can transmit 4005 a DL transfer status request to the IAB node 120-3. The DL transfer status request can comprise a routing identity for the IAB node 120-2 through the IAB node 120-3 (i.e., the source IAB node) . After receiving the DL transfer status request, the IAB node 120-3 will not continue transferring the BAP PDUs to the IAB node 120-2. For example, if the IAB node 120-3 has only transmitted the BAP PDU 1 to the IAB node 120-2, the IAB node 120-3 will not transfer the BAP PDUs 2 and 3 which have not been transferred to the IAB node 120-2.

The IAB node 120-3 can transmit 4010 a DL transfer status response to the donor CU 130. The DL transfer status response can comprise a BAP sequence number (SN) of a BAP PDU which is the last BAP PDU successfully transmitted to the IAB node 120-2. For example, the DL transfer status response can comprise the SN of the BAP PDU 1. In this case, the donor CU 130 can understand the BAP PDUs 2 and 3 are not delivered to the IAB node 120-2.

The donor CU 130 can transmit 4015 a RRC reconfiguration message to the IAB node 120-2 for handover. The donor CU 130 can retransmit 4020 the undelivered BAP PDUs to the IAB node 120-4. For example, the BAP PDUs 2 and 3 can be retransmitted to the IAB node 120-4. The IAB node 120-4 can transmit 4025 the undelivered BAP PDUs to the IAB node 120-2.

According to the above example embodiments, the handover can be performed as soon as possible and it does not need to wait the DL data transmission is completed. Further, the signaling can be reduced as well.

Reference is made to Fig. 5, which shows a signaling chart illustrating process 500 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 500 may involve the donor CU 130, the IAB nodes 120-5, 120-3, 120-2 and 120-4. It should be noted that the process can involve any proper devices.

Since RLC is hop by hop, so the RLC SN is only valid in one hop. Only as an example, if the donor CU 130 sends RLC PDUs with the RLC SNs 1, 2 and 3 to the IAB node 120-5, the IAB node 120-5 will reconfigure the RLC SNs to be 4, 5 and 6 and sends the RLC PDUs with the RLC SNs 4, 5 and 6 to the IAB node 120-3. The IAB node 120-3 can reconfigure the RLC SNs to be 7, 8, and 9 but only RLC PDU with the RLC SN 7 was sent to IAB2.

The donor CU 130 can transmit 5005 a DL transfer status request to the IAB node 120-3. The DL transfer status request can comprise an uplink routing identity for the IAB node 120-2. In addition, the DL transfer status request can comprise a DL routing identity for the IAB node 120-2. In this situation, the IAB node 120-3 can obtain the BAP address of the IAB node 120-2 based on the DL routing identity. The IAB node 120-3 can obtain the BAP address of the IAB node 120-5 based on the UL routing identity.

The IAB node 120-3 can transmit 5010 a DL transfer status response to the IAB node 120-5. The DL transfer status response can comprise a first RLC SN of a RLC PDU which is the last RLC PDU successfully transmitted to the IAB node 120-2. The first RLC SN of the RLC PDU can correspond to a second RLC SN of the RLC PDU received from the IAB node 120-5. For example, the IAB node 120-5 can receive the RLC PDU with the RLC SN 1which is configured by the donor CU, the IAB node 120-5 can transmit the RLC PDU with a reconfigured RLC SN 4 to the IAB node 120-3. The IAB node 120-3 can then transmit the RLC PDU with a reconfigured RLC SN 7 to the IAB node 120-2. In this situation, after the RLC PDU is successfully transmitted to the IAB node 120-2, the IAB node 120-3 can transmit the DL transfer status response comprising the RLC SN 4 to indicate the last RLC SN that successfully transmitted to the IAB node 120-2.

The IAB node 120-5 can transmit 5015 another DL transfer status response to the donor CU 130. The other DL transfer status response can comprise a third RLC SN of the RLC PDU, to indicate the last RLC SN received from the donor CU 130 that is successfully transmitted to the IAB node 120-3. The third RLC SN can be determined based on the first RLC SN. For example, since the RLC SN 1 corresponds to the RLC SN 4, the other DL transfer status response can comprise the RLC SN 1. In this situation, the donor CU 130 can understand the RLC PDU with the RLC SN 1 is successfully transmitted and the RLC PDUs with the RLC SN 2 and 3 are not delivered.

The donor CU 130 can transmit 5020 a RRC reconfiguration message to the IAB node 120-2 for handover. The donor CU 130 can retransmit 5025 one or more RLC PDUs to the IAB node 120-4. The one or more RLC PDUs was not transmitted to the IAB node 120-2 previously. For example, the donor CU 130 can retransmit the RLC PDUs with the RLC SN 2 and 3. The IAB node 120-4 can transmit 5030 the one or more RLC PDUs to the IAB node 120-2.

Reference is made to Fig. 6, which shows a signaling chart illustrating process 600 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 600 may involve the donor CU 130, the IAB nodes 120-5 and 120-3. It should be noted that the process can involve any proper devices. It should be noted that there may be one or more IAB nodes between the donor CU 130 and the IAB node 120-5.

The donor CU 130 can transmit 6005 a first data transmission confirm request to an ancestor IAB node of the IAB node 120-3 to confirm whether a first predetermined number of data packets is transmitted to the IAB node 120-3. For example, the first predetermined number of data packets can be all of the data packets which have been transmitted by the donor CU 130. The first data transmission confirm request comprising a routing identity of the IAB node 120-2 through the IAB node 120-3. Only for the purpose of illustrations, the donor CU 130 can transmit the first data transmission confirm request the IAB node 120-5. If there is another IAB node between the donor CU 130 and the IAB node 120-5, the first data transmission confirm request can be transmitted to the other IAB node and the other IAB node can transmit the first data transmission confirm response to the donor CU 130. After receiving the first data transmission confirm response from the other IAB node, the donor CU 130 can transmit a further data transmission confirm request to the IAB node 120-5. The donor CU 130 can confirm with all ancestor nodes of the IAB node 120-2 whether the DL transfer has been completed. The confirmation procedure can be performed node by node. In other words, the donor CU can first transmit a data transmission confirm request to the closest IAB node to the donor CU 130. After receiving a data transmission confirm response from the closest IAB node, the donor CU 130 can then transmit a further data transmission confirm request to the second closest IAB node.

The IAB node 120-5 can transmit 6010 a first data transmission confirm response to the donor CU 130. In some embodiments, if the IAB node 120-5 cannot transmit the first predetermined number of data packets to the IAB node 120-3 within a predetermined time period, the IAB node 120-5 can send the first data transmission confirm response indicating a false value to the donor CU 130. In some embodiments, the first data transmission confirm response can comprise a BAP SN or RLC SN of the data packet which has been successfully transmitted to the next IAB node (for example, the IAB node 120-3) . Alternatively, if the IAB node 120-5 transmits the first predetermined number of data packets to the IAB node 120-3 within the predetermined time period, the IAB node 120-5 can send the first data transmission confirm response indicating a true value to the donor CU 130. In some embodiments, the predetermined time period can be configured by the donor CU 130. For example, as shown in Fig. 6, the donor CU 130 can transmit 6002 information indicating the predetermined time period to the IAB node 120-5. It should be noted that the step 6002 can take place before/after the step 6005. Alternatively, the predetermined time period can be included in the first data transmission confirm request. Alternatively, the predetermined time period can be fixed.

After receiving the first data transmission confirm response from the IAB node 120-5, the donor CU 130 can transmit 6015 a second data transmission confirm request to the IAB node 120-3 to confirm whether a second predetermined number of data packets is transmitted to the IAB node 120-2. For example, the second predetermined number of data packets can be all of the data packets which have been transmitted by the IAB node 120-5. The second data transmission confirm request comprising a routing identity of the IAB node 120-2 through the IAB node 120-3.

The IAB node 120-3 can transmit 6020 a second data transmission confirm response to the donor CU 130. In some embodiments, if the IAB node 120-3 cannot transmit the second predetermined number of data packets to the IAB node 120-2 within a predetermined time period, the IAB node 120-3 can send the second data transmission confirm response indicating a false value to the donor CU 130. In some embodiments, the second data transmission confirm response can comprise a BAP SN or RLC SN of the data packet which has been successfully transmitted to the next IAB node (for example, the IAB node 120-2) . Alternatively, if the IAB node 120-3 transmits the second predetermined number of data packets to the IAB node 120-2 within the predetermined time period, the IAB node 120-3 can send the second data transmission confirm response indicating a true value to the donor CU 130. For example, as shown in Fig. 6, the donor CU 130 can transmit 6012 information indicating the predetermined time period to the IAB node 120-3. It should be noted that the step 6012 can take place before/after the step 6015. Alternatively, the predetermined time period can be included in the second data transmission confirm request.

In this way, the donor CU can make sure that all data packets have been transmitted to the migrating IAB node before the donor CU makes the handover decision.

Reference is made to Fig. 7, which shows a signaling chart illustrating process 700 among devices according to some example embodiments of the present disclosure. Only for the purpose of discussion, the process 700 may involve the donor CU 130, the IAB nodes 120-5 and 120-3. It should be noted that the process can involve any proper devices.

The donor CU 130 can transmit 7005 a first DL transfer confirm request to the IAB node 120-5. In some embodiments, the first DL transfer confirm request can comprise a routing identity for the IAB node 120-2 through the IAB node 120-3. The IAB node 120-5 can understand that this request is related to the data packets transmitted to the IAB node 120-3. In addition, the first DL transfer confirm request can comprise a BAP address of the IAB node 120-2 which is to be handed over from the IAB node 120-3 to the IAB node 120-4. Alternatively or additionally, the first DL transfer confirm request can comprise a first RLC SN of a RLC PDU.

In some embodiments, if a first predetermined number of data packets with the same routing identity and a RLC PDU with lower RLC SN in the first DL transfer status request message were transmitted to the IAB node 120-3, the IAB node 120-5 can transmit 7010 a second DL transfer confirm request. The second DL transfer confirm request can comprise the routing identity for the IAB node 120-2 through the IAB node 120-3. In addition, the second DL transfer confirm request can comprise a BAP address of the IAB node 120-2 which is to be handed over from the IAB node 120-3 to the IAB node 120-4. Alternatively or additionally, the second DL transfer confirm request can comprise a second RLC SN of the RLC PDU. The second RLC SN corresponds to the RLC SN sent to the IAB node 120-3.

The IAB node 120-3 can transmit 7015 second DL transfer confirm response to the IAB node 120-5. a second In some embodiments, if a second predetermined number of data packets with the same routing ID, and a RLC PDU with lower RLC SN in the second DL transfer confirm request message were transmitted to the IAB node 120-2 within a predetermined time period, the IAB node 120-3 can transmit the second DL transfer confirm response indicating a true value to the IAB node 120-5. Alternatively, if the second predetermined number of data packets were not transmitted to the IAB node 120-2 within the predetermined time period, the IAB node 120-3 can transmit a second DL transfer confirm response indicating a false value to the IAB node 120-5. In some embodiments, the second data transmission confirm response can comprise the last RLC sequence number of the packet that has been transmitted to the next IAB node (for example, the IAB node 120-2) .

The IAB node 120-5 can transmit 7020 a first data transmission confirm response to the donor CU 130. In some embodiments, if the IAB node 120-5 cannot send all data to the IAB node 120-3 within a predetermined time period, the IAB node 120-5 can send the first data transmission confirm response indicating a false value to the donor CU 130. Alternatively, if the IAB node 120-5 sends all data to the IAB node 120-3 within a predetermined time period, the IAB node 120-5 can send the first data transmission confirm response indicating a true value to the donor CU 130. In some embodiments, the first data transmission confirm response can comprise the last RLC sequence number of the packet that has been transmitted to the next IAB node (for example, the IAB node 120-3) . In some embodiments, the predetermined time period can be configured by the donor CU 130. Alternatively, the predetermined time period can be fixed.

In this way, the donor CU makes sure all data have been transmitted to the migrating IAB node before it makes handover decision. Only some of the RLC channels require lossless handover.

Fig. 8 shows a flowchart of an example method 800 in accordance with an embodiment of the present disclosure. The method 800 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 800 is described to be implemented at the IAB node 120-3.

At block 810, the IAB node 120-3 receives a downlink (DL) transfer status request from the donor CU 130. The DL transfer status request at least indicates routing information related to a second IAB node. The second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

At block 820, the IAB node 120-3 transmits, to a communication device, a DL transfer status response.

In some embodiments, the communication device can be the IAB node 120-5. In this case, the DL transfer status request can comprise: a first routing identity for the IAB node 120-2 through the IAB node 120-3, a second routing identity for the IAB node 120-2 through the IAB node 120-4, and an address of the anchor IAB node.

In some embodiments, the DL transfer status response can comprise: a sequence number of a BAP PDU which is last sent to the IAB node 120-2, the first routing identity, the second routing identity, and the address of the anchor IAB node.

In some embodiments, if a BAP PDU is not transmitted to the IAB node 120-2, the IAB node 120-3 can forward the BAP PDU to the IAB node 120-5.

In some embodiments, the communication device can be the donor CU. In this case, the DL transfer status request can comprise: a routing identity for the IAB node 120-2 through the IAB node 120-3. In some embodiments, the DL transfer status response can comprise: a sequence number of a BAP PDU which is last sent to the IAB node 120-2.

In some embodiments, the communication device is the IAB node 120-5. In this case, the DL transfer status request comprises: an UL routing identity for the IAB node 120-2, and a DL routing identity for the IAB node 120-2.

In some embodiments, the DL transfer status response comprises: a SN of a RLC PDU which indicates a last RLC PDU received from the IAB node 120-5 and successfully transmitted to the IAB node 120-2.

Fig. 9 shows a flowchart of an example method 900 in accordance with an embodiment of the present disclosure. The method 900 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 900 is described to be implemented at the donor CU 130.

At block 910, the donor CU 130 transmits a DL transfer status request to the IAB node 120-3. The DL transfer status request at least indicates routing information related to the IAB node 120-2. The donor CU determines that the IAB node 120-2 is to be handed over from the IAB node 120-3 to the IAB node 120-4.

In some embodiments, the donor CU 130 determines an anchor node (for example, the IAB node 120-5) which is a parent IAB node of both the IAB node 120-3 and the IAB node 120-4. In this case, the DL transfer status request can comprise: a first routing identity for the IAB node 120-2 through the IAB node 120-3, a second routing identity for the IAB node 120-2 through the IAB node 120-4, and an address of the anchor IAB node.

In some embodiments, the DL transfer status request comprises: a routing identity for the IAB node 120-2 through the IAB node 120-3.

In some embodiments, at block 920, the donor CU 130 can receive, from the IAB node 120-3, a DL transfer status response comprising a sequence number of a BAP PDU which is last sent to the IAB node 120-2.

In some embodiments, the donor CU 130 can determine, based on the sequence number, a set of BAP PDUs which need to be retransmitted to the IAB node 120-2. The donor CU 130 can transmit the set of BAP PDUs to the IAB node 120-2 via the IAB node 120-4.

In some embodiments, the DL transfer status request comprises: an UL routing identity for the IAB node 120-2, and a DL routing identity for the IAB node 120-2.

In some embodiments, the donor CU 130 can receive, from an anchor IAB node (for example, the IAB node 120-5) , a DL transfer status response. The DL transfer status response can comprise a first SN of a RLC PDU which is last successfully transmitted to the IAB node 120-3. The first SN corresponds to a second SN of the PDU configured by the IAB node 110-5.

In some embodiments, the donor CU 130 can determine, based on the first sequence number, a set of RLC PDUs which need to be retransmitted to the IAB node 120-2. The donor CU 130 can transmit the set of RLC PDUs to the second IAB node via the IAB node 120-4.

Fig. 10 shows a flowchart of an example method 1000 in accordance with an embodiment of the present disclosure. The method 1000 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 1000 is described to be implemented at the IAB node 120-5.

At block 1010, the IAB node 120-5 receives a DL transfer information from a first communication device. The DL transfer information at least indicates routing information related to the IAB node 120-2. The donor CU determines that the IAB node 120-2 is to be handed over from the IAB node 120-3 to the IAB node 120-4.

In some embodiments, the first communication device is the IAB node 120-3. In this case, the IAB node 120-5 receives, from the IAB node 120-3, a DL transfer status response. The DL transfer status response can comprises a sequence number of a BAP PDU which is last sent to the IAB node 120-2, the first routing identity, the second routing identity, and the address of the anchor IAB node.

In some embodiments, the IAB node 120-5 can determine a set of BAP PDUs based on the sequence number. The IAB node 120-5 can retransmit a set of BAP PDUs to the third IAB node based on the second routing identity.

In some embodiments, the IAB node 120-5 can receive, from the IAB node 120-3, a BAP PDU which is not transmitted to the IAB node 120-2 by the IAB node 120-3.

In some embodiments, if the BAP PDU is buffered at the IAB node 120-5, the IAB node 120-5 can discard the BAP PDU. Alternatively, if the BAP PDU is not buffered at the IAB node 120-5, the IAB node 120-5 can retransmit the BAP PDU to the IAB node 120-4 based on the second routing identity.

In some embodiments, the first communication device is the donor CU 130. In this case, the IAB node 120-5 can receive, from the donor CU 130, a re-routing configuration. The re-routing configuration can comprise a first routing identity for the IAB node 120-2 through the IAB node 120-3, and a second routing identity for the IAB node 120-2 through the IAB node 120-4.

In some embodiments, the IAB node 120-5 can re-route a set of BAP PDUs with the first routing identity to the IAB node 120-2 via the IAB node 120-4 based on the second routing identity.

In some embodiments, the first communication device is the first IAB node. In this case, the IAB node 120-5 can receive, from the IAB node 120-3, a first DL transfer response comprising a first sequence number (SN) of radio link control (RLC) protocol data unit (PDU) which indicates a last RLC PDU received from the anchor IAB node and successfully transmitted to the second IAB node. The IAB node 120-5 can determine a second SN of RLC PDU corresponding to the first SN of RLC PDU. In this embodiment, at block 1020, the IAB node 120-5 can transmit, to the donor CU 130, a second DL transfer response comprising the second SN of RLC PDU to indicate a last RLC PDU received from the donor CU 130 and successfully transmitted to the IAB node 120-3.

Fig. 11 shows a flowchart of an example method 1100 in accordance with an embodiment of the present disclosure. The method 1100 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 1100 is described to be implemented at the donor CU 130.

At block 1110, the donor CU 130 transmits, to an ancestor IAB node (for example, the IAB node 120-5) of the IAB node 120-3, a first data transmission confirm request to confirm whether the ancestor IAB node has transmitted a first predetermined number of data packets to the IAB node 120-3. The first data transmission confirm request indicates routing information related to the IAB node 120-2. The second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

At block 1120, the donor CU 130 receives, from the ancestor IAB node, a first response to the first data transmission confirm request.

In some embodiments, if the first response indicates a true value, the donor CU 130 can determine that the first predetermined number of data packets have been transmitted to the IAB node 120-3. Alternatively, if the first response indicates a false value, the donor CU 130 can determine that the first predetermined number of data packets have not been transmitted to the IAB node 120-3.

In some embodiments, the donor CU 130 can transmit, to the IAB node 120-3, a second data transmission confirm request to confirm whether the IAB node 120-3 has transmitted a second predetermined number of data packets to the IAB node 120-2. The first data transmission confirm request can indicate the routing information. In some embodiments, the donor CU 130 can receive, from the IAB node 120-3, a second response to the second data transmission confirm request.

In some embodiments, if the second response indicates a true value, the donor CU 130 can determine that the second predetermined number of data packets have been transmitted to the IAB node 120-2. Alternatively, if the second response indicates a false value, the donor CU 130 can determine that the second predetermined number of data packets have not been transmitted to the IAB node 120-2 within a predetermined time period.

In some embodiments, the first data transmission confirm request further comprises a BAP address of the IAB node 120-2.

Fig. 12 shows a flowchart of an example method 1200 in accordance with an embodiment of the present disclosure. The method 1200 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 1200 is described to be implemented at the IAB node 120-5.

At block 1210, the IAB node 120-5 receives, from a donor CU 130, a first data transmission confirm request to confirm whether the IAB node 120-5 has transmitted a first predetermined number of data packets to the IAB node 120-3. The first data transmission confirm request can indicate routing information related to the IAB node 120-2. The second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

At block 1220, the IAB node 120-5 transmits, to the donor CU 130, a first response to the first data transmission confirm request. In some embodiments, if the first predetermined number of data packets have been transmitted to the IAB node 120-3, the IAB node 120-5 can transmit the first response indicating a true value. Alternatively, if the first predetermined number of data packets have not been transmitted to the IAB node 120-3, the IAB node 120-5 can transmit the first response indicating a false value.

In some embodiments, the first data transmission confirm request comprises a BAP address of the IAB node 120-2 and a first RLC SN. In this embodiment, if the first predetermined of data packets and a RLC PDU with the first RLC SN are transmitted to the IAB node 120-3, the IAB node 120-5 can transmit a second data transmission confirm request to the IAB node 120-3. The second data transmission confirm request can comprise the routing information, the BAP address of the IAB node 120-2, and a second RLC SN associated with the IAB node 120-3 which corresponds to the first RLC SN.

In some embodiments, the IAB node 120-5 can receive, from the IAB node 120-3, a second response to the second data transmission confirm request.

In some embodiments, the first data transmission confirm request comprises a BAP address of the IAB node 120-2 and a RLC SN. In an example embodiment, if the first predetermined of data packets and a RLC PDU with the first RLC SN are not transmitted to the IAB node 120-3, the IAB node 120-5 can transmit the first response indicating a false value.

Fig. 13 shows a flowchart of an example method 1300 in accordance with an embodiment of the present disclosure. The method 1300 can be implemented at any suitable devices. Only for the purpose of illustrations, the method 1300 is described to be implemented at the IAB node 120-3.

At block 1310, the IAB node 120-3 receives, from a first communication, a data transmission confirm request to confirm whether the IAB node 120-3 has transmitted a predetermined number of data packets to the IAB node 120-2. The data transmission confirm request indicates routing information related to the IAB node 120-2. The second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

In some embodiments, the first communication device can be a parent IAB node of the IAB node 120-3. In this situation, the IAB node 120-3 can receive, from the IAB node 120-5, the data transmission confirm request. The data transmission confirm request can comprise a BAP address of the IAB node 120-2, and a RLC SN for the IAB node 120-3.

At block 1320, the IAB node 120-3 transmits, to the first communication device, a response to the data transmission confirm request. In some embodiment, the first communication device can be the donor CU 130. In some embodiments, if the predetermined number of data packets are transmitted to the IAB node 120-2, the IAB node 120-3 can transmit the response indicating a true value. Alternatively, if the predetermined number of data packets are not transmitted to the IAB node 120-2, the IAB node 120-3 can transmit the response indicating a false value.

In some embodiments, if the predetermined of data packets and a RLC protocol data unit (PDU) with the RLC SN are transmitted to the second IAB node, the IAB node 120-3 can transmit the response indicating a true value.

Fig. 14 is a simplified block diagram of a device 1400 that is suitable for implementing embodiments of the present disclosure. The device 1400 can be considered as a further example implementation of the terminal device, the IAB node 120 or the donor CU 130 as shown in Fig. 1. Accordingly, the device 1400 can be implemented at or as at least a part of the terminal device, the IAB node 120 or the donor CU 130.

As shown, the device 1400 includes a processor 1410, a memory 1420 coupled to the processor 1410, a suitable transmitter (TX) and receiver (RX) 1440 coupled to the processor 1410, and a communication interface coupled to the TX/RX 1440. The memory 1420 stores at least a part of a program 1440. The TX/RX 1440 is for bidirectional communications. The TX/RX 1440 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 interface for bidirectional communications between eNBs, S1 interface for communication between a Mobility Management Entity (MME) /Serving Gateway (S-GW) and the eNB, Un interface for communication between the eNB and a relay node (RN) , or Uu interface for communication between the eNB and a terminal device.

The program 1440 is assumed to include program instructions that, when executed by the associated processor 1410, enable the device 1400 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to Fig. 5 to 13. The embodiments herein may be implemented by computer software executable by the processor 1410of the device 1000, or by hardware, or by a combination of software and hardware. The processor 1410may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 1410and memory 1420 may form processing means 1450 adapted to implement various embodiments of the present disclosure.

The memory 1420 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 1420 is shown in the device 1400, there may be several physically distinct memory modules in the device 1400. The processor 1410may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1400 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

In some embodiments, an IAB node comprises circuitry configured to: receive a downlink (DL) transfer status request from a donor centralized unit (CU) , the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and transmit, to a communication device, a DL transfer status response.

In some embodiments, the communication device is an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, and wherein the DL transfer status request comprises: a first routing identity for the second IAB node through the first IAB node, a second routing identity for the second IAB node through the third IAB node, and an address of the anchor IAB node.

In some embodiments, the DL transfer status response comprises a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node, the first routing identity, the second routing identity, and the address of the anchor IAB node.

In some embodiments, the IAB node comprises circuitry configured to: in accordance with a determination that a backhaul adaptation protocol (BAP) protocol data unit (PDU) is not transmitted to the second IAB node, forward the BAP PDU to the anchor IAB node.

In some embodiments, the communication device is the donor CU, and the DL transfer status request comprises: a routing identity for the second IAB node through the first IAB node.

In some embodiments, wherein the DL transfer status response comprises: a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node.

In some embodiments, the communication device is an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, and wherein the DL transfer status request comprises: an uplink (UL) routing identity for the second IAB node, and a DL routing identity for the second IAB node.

In some embodiments, the DL transfer status response comprises: a sequence number (SN) of radio link control (RLC) protocol data unit (PDU) which indicates a last RLC PDU received from the anchor IAB node and successfully transmitted to the second IAB node.

In some embodiments, a donor CU comprises circuitry configured to: transmit a downlink (DL) transfer status request to a first integrated access backhaul (IAB) node, the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.

In some embodiments, the donor CU comprises circuitry configured to: determine an anchor node which is a parent IAB node of both the first IAB node and the third IAB node, and the DL transfer status request comprises: a first routing identity for the second IAB node through the first IAB node, a second routing identity for the second IAB node through the third IAB node, and an address of the anchor IAB node.

In some embodiments, the DL transfer status request comprises: a routing identity for the second IAB node through the first IAB node.

In some embodiments, the donor CU comprises circuitry configured to: receive, from the first IAB node, a DL transfer status response comprising a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node.

In some embodiments, the donor CU comprises circuitry configured to: determine, based on the sequence number, a set of BAP PDUs which need to be retransmitted to the second IAB node; transmit the set of BAP PDUs to the second IAB node via the third IAB node.

In some embodiments, the DL transfer status request comprises: an uplink (UL) routing identity for the second IAB node, and a DL routing identity for the second IAB node.

In some embodiments, the donor CU comprises circuitry configured to: receive, from an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, a DL transfer status response comprising a first sequence number (SN) of a radio link control (RLC) protocol data unit (PDU) which is last successfully transmitted to the first IAB node, the firs SN corresponding to a second SN of the PDU configured by the anchor IAB node.

In some embodiments, the donor CU comprises circuitry configured to: determine, based on the sequence number, a set of RLC PDUs which need to be retransmitted to the second IAB node; transmit the set of RLC PDUs to the second IAB node via the third IAB node.

In some embodiments, an IAB node comprises circuitry configured to: receive, at an anchor integrated access backhaul (IAB) node which is a parent IAB node of both a first IAB node and a third IAB node, a downlink (DL) transfer information from a first communication device, the DL transfer information at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to the third IAB node by a donor centralized unit (CU) .

In some embodiments the first communication device is the first IAB node, and the IAB node comprises circuitry configured to receive, from the first IAB node, a DL transfer status response comprising a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node, a first routing identity for the second IAB node through the first IAB node, a second routing identity for the second IAB node through the third IAB node, and an address of the anchor IAB node.

In some embodiments, the IAB node comprises circuitry configured to determine a set of BAP PDUs based on the sequence number; and retransmit a set of BAP PDUs to the third IAB node based on the second routing identity.

In some embodiments, the IAB node comprises circuitry configured to receive, from the first IAB node, a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is not transmitted to the second IAB node by the first IAB node.

In some embodiments, the IAB node comprises circuitry configured to in accordance with a determination that the BAP PDU is buffered at the anchor IAB node, discard the BAP PDU; or in accordance with a determination that the BAP PDU is not buffered at the anchor IAB node, retransmit the BAP PDU to the third IAB node based on the second routing identity.

In some embodiments, the first communication device is the donor CU, and he IAB node comprises circuitry configured to receive the DL transfer information by receiving, from the donor CU, a re-routing configuration comprising: a first routing identity for the second IAB node through the first IAB node, and a second routing identity for the second IAB node through the third IAB node.

In some embodiments, the IAB node comprises circuitry configured to re-route a set of BAP PDUs with the first routing identity to the second IAB node via the third IAB node based on the second routing identity.

In some embodiments, the first communication device is the first IAB node, and the IAB node comprises circuitry configured to receive the DL transfer information by receiving, from the first IAB node, a first DL transfer response comprising a first sequence number (SN) of radio link control (RLC) protocol data unit (PDU) which indicates a last RLC PDU received from the anchor IAB node and successfully transmitted to the second IAB node. In some embodiments, the IAB node comprises circuitry configured to determine a second SN of RLC PDU corresponding to the first SN of RLC PDU; and transmit, to the donor CU, a second DL transfer response comprising the second SN of RLC PDU to indicate a last RLC PDU received from the donor CU and successfully transmitted to the first IAB node.

In some embodiments, a donor CU comprises circuitry configured to transmit, to an ancestor integrated access backhaul (IAB) node of a first IAB node, a first data transmission confirm request to confirm whether the parent IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and receive, from the parent IAB node, a first response to the first data transmission confirm request.

In some embodiments, the donor CU comprises circuitry configured to in accordance with a determination that the first response indicates a true value, determine that the first predetermined number of data packets have been transmitted to the first IAB node; or in accordance with a determination that the first response indicates a false value, determine that the first predetermined number of data packets have not been transmitted to the first IAB node.

In some embodiments, the donor CU comprises circuitry configured to transmit, to the first IAB node, a second data transmission confirm request to confirm whether the first IAB node has transmitted a second predetermined number of data packets to the second IAB node, the first data transmission confirm request indicating the routing information; and receive, from the first IAB node, a second response to the second data transmission confirm request.

In some embodiments, the donor CU comprises circuitry configured to in accordance with a determination that the second response indicates a true value, determine that the second predetermined number of data packets have been transmitted to the second IAB node; or in accordance with a determination that the second response indicates a false value, determine that the second predetermined number of data packets have not been transmitted to the second IAB node within a predetermined time period.

In some embodiments, the first data transmission confirm request further comprises a backhaul adaptation protocol (BAP) address of the second IAB node.

In some embodiments, an IAB node comprises circuitry configured to receive, at a parent integrated access backhaul (IAB) node of a first IAB node and from a donor centralized unit (CU) , a first data transmission confirm request to confirm whether the parent IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and transmit, to the donor CU, a first response to the first data transmission confirm request.

In some embodiments, the IAB node comprises circuitry configured to transmit the first response by in accordance with a determination that the first predetermined number of data packets have been transmitted to the first IAB node, transmitting the first response indicating a true value; or in accordance with a determination that the first predetermined number of data packets have not been transmitted to the first IAB node, transmitting the first response indicating a false value.

In some embodiments, the first data transmission confirm request comprises a backhaul adaptation protocol (BAP) address of the second IAB node and a first radio link control (RLC) sequence number (SN) . In some embodiments, the IAB node comprises circuitry configured to in accordance with a determination that the first predetermined of data packets and a RLC protocol data unit (PDU) with the first RLC SN are transmitted to the first IAB node, transmit a second data transmission confirm request to the first IAB node, the second data transmission confirm request comprising: the routing information, the BAP address of the second IAB node, and a second RLC SN associated with the first IAB node which corresponds to the first RLC SN.

In some embodiments, the IAB node comprises circuitry configured to receive, from the first IAB node, a second response to the second data transmission confirm request.

In some embodiments, the first data transmission confirm request comprises a backhaul adaptation protocol (BAP) address of the second IAB node and a first radio link control (RLC) sequence number (SN) and the IAB node comprises circuitry configured to transmit the first response by in accordance with a determination that the first predetermined of data packets and a RLC protocol data unit (PDU) with the first RLC SN are not transmitted to the first IAB node, transmitting the first response indicating a false value.

In some embodiments, an IAB node comprises circuitry configured to receive, from a first communication, a data transmission confirm request to confirm whether the first IAB node has transmitted a predetermined number of data packets to a second IAB node, the data transmission confirm request indicating routing information related to the second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by a donor centralized unit (CU) ; and transmit, to the first communication device, a response to the data transmission confirm request.

In some embodiments, the first communication device is the donor CU, and the IAB node comprises circuitry configured to transmit the response by in accordance with a determination that the predetermined number of data packets are transmitted to the second IAB node, transmitting the response indicating a true value; or in accordance with a determination that the predetermined number of data packets are not transmitted to the second IAB node, transmitting the response indicating a false value.

In some embodiments, the first communication device is a parent IAB node of the first IAB node, and the IAB node comprises circuitry configured to receive the data transmission confirm request by receiving, from the parent IAB node, the data transmission confirm request further comprising: a backhaul adaptation protocol (BAP) address of the second IAB node, and a radio link control (RLC) sequence number (SN) for the first IAB node.

In some embodiments, the IAB node comprises circuitry configured to transmit the response by in accordance with a determination that the predetermined of data packets and a RLC protocol data unit (PDU) with the RLC SN are transmitted to the second IAB node, transmitting the response indicating a true value.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to any of Figs. 4-10. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

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

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

Although the present disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A communication method, comprising:

receiving, at a first integrated access backhaul (IAB) node, a downlink (DL) transfer status request from a donor centralized unit (CU) , the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and

transmitting, to a communication device, a DL transfer status response.
The method of claim 1, wherein the communication device is an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, and wherein the DL transfer status request comprises:

a first routing identity for the second IAB node through the first IAB node,

a second routing identity for the second IAB node through the third IAB node, and

an address of the anchor IAB node.
The method of claim 2, wherein the DL transfer status response comprises:

a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node,

the first routing identity,

the second routing identity, and

the address of the anchor IAB node.
The method of claim 2, further comprising:

in accordance with a determination that a backhaul adaptation protocol (BAP) protocol data unit (PDU) is not transmitted to the second IAB node, forwarding the BAP PDU to the anchor IAB node.
The method of claim 1, wherein the communication device is the donor CU, and wherein the DL transfer status request comprises:

a routing identity for the second IAB node through the first IAB node.
The method of claim 5, wherein the DL transfer status response comprises:

a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node.
The method of claim 1, wherein the communication device is an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, and wherein the DL transfer status request comprises:

an uplink (UL) routing identity for the second IAB node, and

a DL routing identity for the second IAB node.
The method of claim 7, wherein the DL transfer status response comprises:

a sequence number (SN) of radio link control (RLC) protocol data unit (PDU) which indicates a last RLC PDU received from the anchor IAB node and successfully transmitted to the second IAB node.
A communication method, comprising:

transmitting, at a donor centralized unit (CU) , a downlink (DL) transfer status request to a first integrated access backhaul (IAB) node, the DL transfer status request at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU.
The method of claim 9, further comprising:

determining an anchor node which is a parent IAB node of both the first IAB node and the third IAB node, and wherein the DL transfer status request comprises:

a first routing identity for the second IAB node through the first IAB node,

a second routing identity for the second IAB node through the third IAB node, and

an address of the anchor IAB node.
The method of claim 9, wherein the DL transfer status request comprises:

a routing identity for the second IAB node through the first IAB node.
The method of claim 11, further comprising:

receiving, from the first IAB node, a DL transfer status response comprising a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node.
The method of claim 12, further comprising:

determining, based on the sequence number, a set of BAP PDUs which need to be retransmitted to the second IAB node;

transmitting the set of BAP PDUs to the second IAB node via the third IAB node.
The method of claim 9, wherein the DL transfer status request comprises:

an uplink (UL) routing identity for the second IAB node, and

a DL routing identity for the second IAB node.
The method of claim 14, further comprising:

receiving, from an anchor IAB node which is a parent IAB node of both the first IAB node and the third IAB node, a DL transfer status response comprising a first sequence number (SN) of a radio link control (RLC) protocol data unit (PDU) which is last successfully transmitted to the first IAB node, the first SN corresponding to a second SN of the PDU configured by the anchor IAB node.
The method of claim 15, further comprising:

determining, based on the first sequence number, a set of RLC PDUs which need to be retransmitted to the second IAB node; and

transmitting the set of RLC PDUs to the second IAB node via the third IAB node.
A communication method, comprising:

receiving, at an anchor integrated access backhaul (IAB) node which is a parent IAB node of both a first IAB node and a third IAB node, a downlink (DL) transfer information from a first communication device, the DL transfer information at least indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to the third IAB node by a donor centralized unit (CU) .
The method of claim 17, wherein the first communication device is the first IAB node, and wherein receiving the DL transfer information comprises:

receiving, from the first IAB node, a DL transfer status response comprising:

a sequence number of a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is last sent to the second IAB node,

a first routing identity for the second IAB node through the first IAB node,

a second routing identity for the second IAB node through the third IAB node, and

an address of the anchor IAB node.
The method of claim 18, further comprising:

determining a set of BAP PDUs based on the sequence number; and

retransmitting the set of BAP PDUs to the third IAB node based on the second routing identity.
The method of claim 18, further comprising:

receiving, from the first IAB node, a backhaul adaptation protocol (BAP) protocol data unit (PDU) which is not transmitted to the second IAB node by the first IAB node.
The method of claim 20, further comprising:

in accordance with a determination that the BAP PDU is buffered at the anchor IAB node, discarding the BAP PDU; or

in accordance with a determination that the BAP PDU is not buffered at the anchor IAB node, retransmitting the BAP PDU to the third IAB node based on the second routing identity.
The method of claim 17, wherein the first communication device is the donor CU, and wherein receiving the DL transfer information comprises:

receiving, from the donor CU, a re-routing configuration comprising:

a first routing identity for the second IAB node through the first IAB node, and

a second routing identity for the second IAB node through the third IAB node.
The method of claim 22, further comprising:

re-routing a set of BAP PDUs with the first routing identity to the second IAB node via the third IAB node based on the second routing identity.
The method of claim 17, wherein the first communication device is the first IAB node, and wherein receiving the DL transfer information comprises:

receiving, from the first IAB node, a first DL transfer response comprising a first sequence number (SN) of radio link control (RLC) protocol data unit (PDU) which indicates a last RLC PDU received from the anchor IAB node and successfully transmitted to the second IAB node; and the method further comprises:

determining a second SN of RLC PDU corresponding to the first SN of RLC PDU; and

transmitting, to the donor CU, a second DL transfer response comprising the second SN of RLC PDU to indicate a last RLC PDU received from the donor CU and successfully transmitted to the first IAB node.
A communication method, comprising:

transmitting, at a donor centralized unit (CU) and to an ancestor integrated access backhaul (IAB) node of a first IAB node, a first data transmission confirm request to confirm whether the ancestor IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and

receiving, from the ancestor IAB node, a first response to the first data transmission confirm request.
The method of claim 25, further comprising:

in accordance with a determination that the first response indicates a true value, determining that the first predetermined number of data packets have been transmitted to the first IAB node; or

in accordance with a determination that the first response indicates a false value, determining that the first predetermined number of data packets have not been transmitted to the first IAB node.
The method of claim 25, further comprising:

transmitting, to the first IAB node, a second data transmission confirm request to confirm whether the first IAB node has transmitted a second predetermined number of data packets to the second IAB node, the first data transmission confirm request indicating the routing information; and

receiving, from the first IAB node, a second response to the second data transmission confirm request.
The method of claim 27, further comprising:

in accordance with a determination that the second response indicates a true value, determining that the second predetermined number of data packets have been transmitted to the second IAB node; or

in accordance with a determination that the second response indicates a false value, determining that the second predetermined number of data packets have not been transmitted to the second IAB node within a predetermined time period.
The method of claim 27, wherein the first data transmission confirm request further comprises a backhaul adaptation protocol (BAP) address of the second IAB node.
A communication method, comprising:

receiving, at a parent integrated access backhaul (IAB) node of a first IAB node and from a donor centralized unit (CU) , a first data transmission confirm request to confirm whether the parent IAB node has transmitted a first predetermined number of data packets to the first IAB node, the first data transmission confirm request indicating routing information related to a second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by the donor CU; and

transmitting, to the donor CU, a first response to the first data transmission confirm request.
The method of claim 30, wherein transmitting the first response comprises:

in accordance with a determination that the first predetermined number of data packets have been transmitted to the first IAB node, transmitting the first response indicating a true value; or

in accordance with a determination that the first predetermined number of data packets have not been transmitted to the first IAB node, transmitting the first response indicating a false value.
The method of claim 30, wherein the first data transmission confirm request comprises a backhaul adaptation protocol (BAP) address of the second IAB node and a first radio link control (RLC) sequence number (SN) , the method further comprising:

in accordance with a determination that the first predetermined of data packets and a RLC protocol data unit (PDU) with the first RLC SN are transmitted to the first IAB node, transmitting a second data transmission confirm request to the first IAB node, the second data transmission confirm request comprising:

the routing information,

the BAP address of the second IAB node, and

a second RLC SN associated with the first IAB node which corresponds to the first RLC SN.
The method of claim 32, further comprising:

receiving, from the first IAB node, a second response to the second data transmission confirm request.
The method of claim 30, wherein the first data transmission confirm request comprises a backhaul adaptation protocol (BAP) address of the second IAB node and a first radio link control (RLC) sequence number (SN) and wherein transmitting the first response comprising:

in accordance with a determination that the first predetermined of data packets and a RLC protocol data unit (PDU) with the first RLC SN are not transmitted to the first IAB node, transmitting the first response indicating a false value.
A communication method, comprising:

receiving, at a first integrated access backhaul (IAB) node and from a first communication, a data transmission confirm request to confirm whether the first IAB node has transmitted a predetermined number of data packets to a second IAB node, the data transmission confirm request indicating routing information related to the second IAB node, wherein the second IAB node is determined to be handed over from the first IAB node to a third IAB node by a donor centralized unit (CU) ; and

transmitting, to the first communication device, a response to the data transmission confirm request.
The method of claim 35, wherein the first communication device is the donor CU, and wherein transmitting the response comprises:

in accordance with a determination that the predetermined number of data packets are transmitted to the second IAB node, transmitting the response indicating a true value; or

in accordance with a determination that the predetermined number of data packets are not transmitted to the second IAB node, transmitting the response indicating a false value.
The method of claim 35, wherein the first communication device is a parent IAB node of the first IAB node, and wherein receiving the data transmission confirm request comprises:

receiving, from the parent IAB node, the data transmission confirm request further comprising:

a backhaul adaptation protocol (BAP) address of the second IAB node, and

a radio link control (RLC) sequence number (SN) for the first IAB node.
The method of claim 35, wherein transmitting the response comprises:

in accordance with a determination that the predetermined of data packets and a RLC protocol data unit (PDU) with the RLC SN are transmitted to the second IAB node, transmitting the response indicating a true value.
A donor centralized unit comprising:

a processor configured to perform the method according to any of claims 9-16 or any of claims 25-29.
A device integrated access backhaul (IAB) node comprising:

a processor configured to perform the method according to any of claims 1-8, or any of claims 17-24, or any of claims 30-34 or any of claims 35-38.
A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 1-8, or any of claims 9-16, or any of claims 17-24, or any of claims 25-29, or any of claims 30-34 or any of claims 35-38.
A donor centralized unit comprising:

a processor configured to perform the method according to any of claims 9-16 or any of claims 25-29.
A device integrated access backhaul (IAB) node comprising:

a processor configured to perform the method according to any of claims 1-8, or any of claims 17-24, or any of claims 30-34 or any of claims 35-38.
A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 1-8, or any of claims 9-16, or any of claims 17-24, or any of claims 25-29, or any of claims 30-34 or any of claims 35-38.