CN118283852A

CN118283852A - Communication method and communication device

Info

Publication number: CN118283852A
Application number: CN202310153140.1A
Authority: CN
Inventors: 朱世超; 孙飞; 朱元萍; 史玉龙
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-12-30
Filing date: 2023-02-16
Publication date: 2024-07-02

Abstract

The application provides a communication method and a communication device, relates to the technical field of communication, and can be applied to DU and/or MT migration in an IAB network. The method comprises the following steps: the third CU or the fourth CU receives first information from the first CU, wherein the first information is used for indicating whether the fourth CU and a host DU managed by the third CU can communicate in an IP routing mode or not, F1 connection exists between the first CU and the DU of the IAB node, RRC connection exists between the third CU and the MT of the IAB node, and the fourth CU is a candidate target CU of the DU of the IAB node; determining whether the host DUs managed by the fourth CU and the third CU can communicate in an IP routing mode according to the first information; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

Description

Communication method and communication device

The present application claims priority from the chinese patent office, application number 202211731643.4, chinese patent application entitled "communication method and communication device," filed on 12 months and 30 days 2022, the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates to the field of communications, and in particular, to a communication method and a communication device.

Background

Compared with the fourth generation mobile communication system, the fifth generation mobile communication (5G) has set more stringent requirements for various performance indexes of the network. For example, capacity is increased by 1000 times, coverage requirements are wider, ultra-high reliability and ultra-low latency are achieved, etc. On the one hand, considering that the high-frequency carrier frequency resources are abundant, in order to meet the 5G ultra-high capacity requirement in the hot spot area, the networking by using the high-frequency small station is becoming popular. The high-frequency carrier has poor propagation characteristics, serious shielding attenuation and poor coverage range, so that a large number of small stations are required to be densely deployed. Accordingly, the cost of providing optical fiber backhaul for these large numbers of densely deployed small stations is high, and the construction difficulty is high, so that an economic and convenient backhaul scheme is required. On the other hand, from the aspect of wide coverage requirement, network coverage is provided in some remote areas, the deployment difficulty of optical fibers is high, the cost is high, and flexible and convenient access and return schemes are also required to be designed. The access backhaul Integrated (IAB) technology provides an idea for solving the two problems: the access link (ACCESS LINK) and the backhaul link (backhaul link) both adopt a wireless transmission scheme, so that the optical fiber deployment is reduced.

In an IAB network, a relay node, or an IAB-node (IAB-node), may provide a radio access service for a User Equipment (UE). Traffic data for the UE is transmitted by an IAB-node over a wireless backhaul link to an IAB host (IAB-donor). The IAB-node includes a mobile terminal (mobile termination, MT) portion and a Distributed Unit (DU) portion. When the IAB-node faces to the father node, the IAB-node can be used as a role of terminal equipment, namely MT; an IAB-node is considered a network device when it is towards its child node (which may be another IAB-node, or UE), i.e. takes on the role of a DU. The IAB-donor is an access network element with the function of a complete base station (e.g. gNB) and comprises a centralized unit (centralized unit, CU) and a Distributed Unit (DU), and is connected to a core network serving the UE (e.g. to a 5G core network).

IAB node migration across CUs can be divided into two implementations, full migration (full migration) and partial migration (partial migration). In partial migration, the MT of the migrating IAB node, i.e., boundary node (boundary node), has a cross-CU handover, but the DU of the boundary node remains F1 connected to the source CU. Whereas in full migration, the DU of the boundary node needs to establish an F1 connection with the target CU. The essential difference between full and partial migration is whether or not a DU migration is required (in fact, a new logical DU is generated and then an F1 interface is established with the candidate target CU, but from the IAB node macroscopic point of view, it may be generally expressed as "DU migration"). In the existing full migration, candidate target CUs of MT and DU (i.e. CU to which to switch) are identical, so it is necessary to study CU migration schemes when target CUs of MT and DU are different.

Disclosure of Invention

The embodiment of the application discloses a communication method and a communication device, which can avoid or reduce the occurrence of data transmission failure between a target CU of MT of an IAB node and a target CU of DU of the IAB node.

In a first aspect, an embodiment of the present application provides a communication method, including: receiving first information from a first CU, the first information including an internet protocol (internet protocol, IP) address of the third CU or an IP address of the fourth CU, the first CU having an F1 connection with a DU of an IAB node, the third CU having a radio resource control (radio resource control, RRC) connection with an MT of the IAB node, the fourth CU being a candidate target CU for the DU of the IAB node; and determining whether the host DUs managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU or whether an Xn interface exists between the third CU and the fourth CU according to the first information. The first information is used to indicate whether the host DUs managed by the fourth CU and the third CU are capable of communication by way of internet protocol (internet protocol, IP) routing. Or the first information is used for indicating whether the Xn interface can be established between the third CU and the fourth CU. Or the first information is used for indicating whether an Xn interface exists between the third CU and the fourth CU. The IP address of the third CU may be replaced with identification information of the third CU, such as a gNB ID of the third CU; but also the IP address of the DU managed by the third CU. Or the first information includes at least one of an IP address of the third CU, identification information of the third CU, and an IP address of a DU managed by the third CU. The IP address of the fourth CU may be replaced with identification information of the fourth CU, such as the gNB ID of the fourth CU. Or the first information includes at least one of an IP address of the fourth CU, a gNB ID of the fourth CU. Optionally, the first information further includes a gNB ID of the first CU.

The fourth CU is a candidate target CU for the DU of the IAB node. Alternatively, the fourth CU is a candidate target CU currently selected for the DU of the IAB node. When the DU of the IAB node is directly migrated to the fourth CU, there may be a case where the DU managed by the third CU and the fourth CU cannot communicate by way of IP routing, which may cause data transmission failure. In the embodiment of the application, according to the first information, whether the host DU managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU is determined; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

In one possible implementation, the method further includes: and sending second information to the first CU, wherein the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing.

In this implementation, the second information is sent to the first CU, so that the first CU selects one candidate target CU for the DU of the IAB node again or migrates the DU of the IAB node to the fourth CU according to the second information.

In one possible implementation, the method further includes: and sending second information to the first CU, wherein the second information is used for indicating that an Xn interface can be or can not be established between the third CU and the fourth CU.

In one possible implementation, the method further includes: and sending second information to the first CU, wherein the second information is used for indicating the existence or non-existence of an Xn interface between the third CU and the fourth CU.

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the second information includes an IP address of the fourth CU and identification information identifying the MT in the fourth CU.

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of: in case it is determined that the fourth CU and the host DU managed by the third CU are capable of communicating by means of IP routing, sending third information to the third CU, the third information being used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology. In the present application, the third CU establishes, within its topology, an F1 interface transmission between the DU of the IAB node and the fourth CU comprising at least one of: the third CU configures resources for an F1 interface between the DU of the IAB node and the fourth CU in the topology, the third CU allocates IP addresses and/or BAP configuration of MTs for the F1 interface between the DU of the IAB node and the fourth CU, and the third CU determines DSCP/flow labels for the F1 interface between the DU of the IAB node and the fourth CU.

In the case that it is determined that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, transmitting third information to the third CU; it can be ensured that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing, thereby avoiding or reducing the occurrence of data transmission failure between the target CU of the DUs of the IAB node and the target CU of the MT (i.e. the third CU).

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of: and sending third information to the third CU under the condition that the Xn interface can be established between the third CU and the fourth CU, wherein the third information is used for requesting the third CU to establish F1 interface transmission between the DU of the IAB node and the fourth CU in the topology.

Transmitting third information to the third CU under the condition that the Xn interface can be established between the third CU and the fourth CU; it can be ensured that the host DUs managed by the fourth CU and the third CU can communicate via the Xn interface, thereby avoiding or reducing the occurrence of data transmission failure between the target CU of the DUs of the IAB node and the target CU of the MT (i.e. the third CU).

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of: and sending third information to the third CU in the condition that the Xn interface exists between the third CU and the fourth CU, wherein the third information is used for requesting the third CU to establish F1 interface transmission between the DU of the IAB node and the fourth CU in the topology.

Transmitting third information to the third CU if it is determined that the Xn interface exists between the third CU and the fourth CU; it can be ensured that the host DUs managed by the fourth CU and the third CU can communicate via the Xn interface, thereby avoiding or reducing the occurrence of data transmission failure between the target CU of the DUs of the IAB node and the target CU of the MT (i.e. the third CU).

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: in the event that it is determined that the fourth CU and the third CU manage host DUs capable of communicating by way of IP routing, an F1 interface transmission between the IAB node's DUs and the fourth CU is established within its topology.

In this implementation, the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) is avoided or reduced.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: in case it is determined that an Xn interface can be established between the third CU and the fourth CU, an F1 interface transmission between the DU of the IAB node and the fourth CU is established within its topology.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: in case there is an Xn interface between the third CU and the fourth CU, an F1 interface transmission between the DU and the fourth CU within its topology for establishing the IAB node is established.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: in the event that it is determined that an Xn interface can be established between the third CU and the fourth CU, sending thirteenth information (e.g., carried in IAB Transport Migration management procedure Request messages) to the fourth CU, the thirteenth information being used to request the fourth CU to initiate an IAB transport migration (IAB Transport Migration) procedure; receiving third information (e.g., carried in IAB Transport Migration management Request messages) from the fourth CU requesting that the third CU establish, within its topology, an F1 interface transmission between DUs of the IAB node and the fourth CU; in response to the third information, an F1 interface transmission between the DUs of the IAB node and the fourth CU is established within its topology. Optionally, the third information carries an IP address of the fourth CU. In the case where it is determined that an Xn interface can be established between the third CU and the fourth CU, sending thirteenth information to the fourth CU may be replaced with: transmitting thirteenth information to the fourth CU in case it is determined that an Xn interface exists between the third CU and the fourth CU; alternatively, it may be: in the case where it is determined that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, thirteenth information is transmitted to the fourth CU.

In this implementation, after the third CU initiates a request to establish a transmission across topology F1, the third CU establishes an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology; can be consistent with the existing protocol as much as possible.

In a possible implementation manner, the thirteenth information carries a gNB-ID of the third CU and identification information for identifying the MT in the third CU. Optionally, the thirteenth information further carries identification information for identifying the MT in the fourth CU.

The thirteenth information carries identification information for identifying the MT in the fourth CU and identification information for identifying the MT in the third CU, and is used for informing the fourth CU as to which MT the traffic is migrated.

In one possible implementation, the first information includes an ID of the fourth CU and identification information identifying the MT in the fourth CU.

In this implementation manner, the first information includes an ID of the fourth CU and identification information identifying the MT in the fourth CU, so that when the third CU determines that the fourth CU and the host DU managed by the third CU can communicate by IP routing, the third CU may directly establish an F1 interface between the DU of the IAB node and the fourth CU and transmit the Differentiated Services Code Point (DSCP) or a flow label (flow label) to the fourth CU, thereby saving signaling overhead.

In one possible implementation, the first information includes an ID of the third CU and identification information identifying the MT in the third CU.

In this implementation, the first information includes an ID of the third CU and identification information identifying the MT in the third CU, so that when the fourth CU determines that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing, the fourth CU may directly request to the third CU for transmission of the F1 interface between the DU establishing the IAB node in the third CU topology and the fourth CU, thereby saving signaling overhead.

In one possible implementation, the method further includes: in a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sixth information is transmitted to the first CU, the sixth information indicating that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

In this implementation, the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) may be avoided or reduced.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: and sending seventh information to the MT, wherein the seventh information comprises an IP address of the MT under the third CU topology and a backhaul link adaptation layer protocol (backhaul adaptation protocol, BAP) configuration of the MT under the third CU topology.

In this implementation, seventh information is sent to the MT so that the IAB node initiates an F1 interface setup request to the fourth CU based on the seventh information.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: and sending fifth information to the first CU, wherein the fifth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology. Optionally, the fifth information further includes an IP address of the fourth CU.

In a second aspect, an embodiment of the present application provides another communication method, including: generating first information, where the first information is used for indicating whether a host DU managed by a fourth CU and a third CU can communicate through an IP routing manner, or whether the first information is used for indicating whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an F1 connection exists between the first CU and a DU of an IAB node, an RRC connection exists between the third CU and an MT of the IAB node, and the fourth CU is a candidate target CU of a DU of the IAB node; and sending the first information. The IP address of the third CU may be replaced with identification information of the third CU, such as a gNB ID of the third CU; but also the IP address of the DU managed by the third CU. Or the first information includes at least one of an IP address of the third CU, identification information of the third CU, and an IP address of a DU managed by the third CU. The IP address of the fourth CU may be replaced with identification information of the fourth CU, such as the gNB ID of the fourth CU. Or the first information includes at least one of an IP address of the fourth CU, a gNB ID of the fourth CU.

In the embodiment of the application, the first information is sent, so that the third CU or the fourth CU can determine whether the fourth CU and the host DU managed by the third CU can communicate in an IP routing mode according to the first information; thereby avoiding or reducing the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT, i.e. the third CU.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and sending third information to the third CU, where the second information is used to indicate that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and sending third information to the third CU under the condition that the second information is used for indicating that an Xn interface can be established between the third CU and the fourth CU, wherein the third information is used for requesting the third CU to establish F1 interface transmission between the DU of the IAB node and the fourth CU in the topology.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and sending third information to the third CU, wherein the third information is used for requesting the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in the topology of the third CU, if the second information is used for indicating that an Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the third information includes identification information of the fourth CU and identification information identifying the MT in the fourth CU. Optionally, the third information further includes an IP address of the fourth CU.

The reason why the third information carries the identification information of the fourth CU and the identification information of the MT in the fourth CU is that the F1 connection that the third CU needs to establish is between the DU to be used for the IAB node and the fourth CU4, and the third CU needs to issue a Differentiated Services Code Point (DSCP) or a flow label (flow label) to the fourth CU in the subsequent process.

In one possible implementation, the method further includes: and selecting a fifth CU as a candidate target CU of the DU of the IAB node in the case that the second information is used for indicating that the host DUs managed by the fourth CU and the third CU cannot communicate through the IP routing.

In one possible implementation, the method further includes: and selecting a fifth CU as a candidate target CU of the DU of the IAB node in the condition that the second information is used for indicating that an Xn interface can not be established between the third CU and the fourth CU.

In one possible implementation, the method further includes: and selecting a fifth CU as a candidate target CU of the DU of the IAB node in the condition that the second information is used for indicating that an Xn interface does not exist between the third CU and the fourth CU.

In one possible implementation, the second information includes an IP address of the fourth CU and identification information identifying the MT in the fourth CU.

The purpose of carrying the IP address of the fourth CU is to send this IP address to the IAB node by the first CU in a subsequent step for establishing an F1 interface between the DU of the IAB node and the fourth CU. In addition, the second information also carries identification information identifying the MT in the fourth CU, for example XNAP ID of the MT under the fourth CU, for the first CU to inform the third CU later, so that the third CU can send DSCP or stream label to the third CU.

In one possible implementation, before sending the first information, the method further includes: receiving fourth information from the fourth CU, the fourth information including an IP address of the fourth CU, optionally, the fourth information further including identification information identifying an MT at the fourth CU; the transmitting the first information includes: and sending the first information to the third CU, wherein the first information comprises the IP address of the fourth CU. Optionally, the first information further includes an IP address of the fourth CU and identification information of identifying MT at the fourth CU, so that when the third CU determines that the fourth CU and a host DU managed by the third CU can communicate by IP routing, the third CU may directly establish F1 interface transmission between the DU of the IAB node and the fourth CU, thereby saving signaling overhead.

In this implementation, the first information includes an IP address of the fourth CU, so that the third CU determines whether the fourth CU and the host DUs managed by the third CU can communicate by way of IP routing.

In one possible implementation, the method further includes: receiving a transmitted fifth information from the third CU, the fifth information including an IP address of the MT under the third CU topology and a BAP configuration of the MT under the third CU topology; and sending F1 Application Protocol (AP) information to the DU of the IAB node, wherein the F1AP information comprises the IP address of the fourth CU. Optionally, the fifth information further includes an IP address of the fourth CU.

In this implementation, the F1 application protocol AP information is sent to the DU of the IAB node in order for the IAB node to establish a new F1 interface or migrate the F1 interface.

In one possible implementation, the method further includes: and selecting the fourth CU from CUs with Xn interfaces with the first CU as a candidate target CU of the DU of the IAB node. For example, the first CU selects the fourth CU as a candidate target CU for the DU of the IAB node from a target list, where the target list includes identification information of one or more CUs having an XN interface with the first CU. Optionally, the fourth CU is any one of the target lists. The first CU may randomly select one of the CUs in the target list as a candidate target CU for the DU of the IAB node. Optionally, the fourth CU is a CU with a largest service range in the target list.

In one possible implementation, the method further includes: transmitting fourteenth information to the core network (e.g., access and mobility management function (ACCESS AND mobility management, AMF) network element), the fourteenth information being used to request the core network to select a candidate target CU for DU migration; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; and according to the fifteenth information, the fourth CU is taken as a candidate target CU of the DU of the IAB node.

In one possible implementation, the method further includes: transmitting fourteenth information to a network manager (e.g., an operation administration and maintenance (operation administration AND MAINTENANCE, OAM) network element), the fourteenth information being used to request the network manager to select a candidate target CU for DU migration; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; and according to the fifteenth information, the fourth CU is taken as a candidate target CU of the DU of the IAB node.

In a third aspect, an embodiment of the present application provides another communication method, including: receiving first information from a second CU, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can communicate through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided between the fourth CU and a DU of the IAB node or an F1 connection is to be established; and determining whether the host DUs managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU or whether an Xn interface exists between the third CU and the fourth CU according to the first information.

In the embodiment of the application, according to the first information, whether the host DU managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU or whether an Xn interface exists between the third CU and the fourth CU is determined; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

In one possible implementation, the method further includes: and sending second information to the second CU, wherein the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing.

In this implementation, the second information is sent to the second CU, so that the second CU selects one candidate target CU for the DU of the IAB node again or migrates the DU of the IAB node to the fourth CU according to the second information.

In one possible implementation, the method is applied to the third CU or a module in the third CU; the method further comprises the steps of: in case there is an Xn interface between the third CU and the fourth CU, an F1 interface transmission between the DU of the IAB node and the fourth CU is established within its topology.

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of: in case it is determined that the fourth CU and the host DU managed by the third CU are capable of communicating by means of IP routing, sending third information to the third CU, the third information being used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology. Optionally, the third information includes an IP address of the fourth CU.

In one possible implementation, the method further includes: in a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sixth information is transmitted to the second CU, the sixth information indicating that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

In one possible implementation, the method further includes: and sending ninth information to the second CU, wherein the ninth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology.

By sending the ninth information to the second CU, the second CU sends information to the MT carrying the IP address of the MT in the third CU topology, the BAP configuration of the MT in the third CU topology, and the IP address of the fourth CU.

In one possible implementation, the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of: an eleventh message is received from the third CU, the eleventh message including a DSCP/flow label of traffic of the IAB node. Optionally, the eleventh information further includes an IP address of the MT under the third CU topology, a BAP configuration of the MT under the third CU topology; and transmitting twelfth information to the DU of the IAB node, wherein the twelfth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology.

In this implementation, twelfth information is sent to the DUs of the IAB node so that the IAB node switches the MT from the topology of the second CU to the topology of the third CU based on the twelfth information.

In a possible implementation manner, the method is applied to the third CU or a module in the third CU, and the first information is carried in a handover request for requesting that the MT be handed over to the third CU; the method further comprises the steps of: and in the case that it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sending a handover preparation failure message to the second CU, wherein the handover preparation failure message indicates rejection of the handover request. The handover request includes identification information identifying the MT in the second CU, e.g. MT XNAP ID. In the case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sending a handover preparation failure message to the second CU may be replaced with: in case it is determined that an Xn interface cannot be established (or is not present) between the fourth CU and a host DU managed by the third CU, a handover preparation failure message is sent to the second CU.

In this implementation, the first information is carried in the handover request for requesting to handover the MT to the third CU, which can save signaling overhead.

In one possible implementation, the handover preparation failure message includes a first field indicating that the reason why the third CU refuses the handover request is that the topology under the third CU cannot serve the F1 interface traffic of the fourth CU.

In this implementation, the handover preparation failure message includes a first field (which may be referred to as a cause field) that may inform the second CU of the reason for its refusal of the handover request.

In one possible implementation, the method further includes: and sending a switching request response message to the second CU, wherein the switching request response message indicates that the switching request is accepted, under the condition that the fourth CU and the host DU managed by the third CU can communicate through an IP route. In the case where it is determined that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, sending a handover request response message to the second CU may be replaced with: in case it is determined that an Xn interface (or an Xn interface exists) can be established between the fourth CU and the host DU managed by the third CU, a handover request response message is sent to the second CU.

In one possible implementation manner, the method is applied to the third CU or a module in the third CU, the first information is carried in a handover request for requesting that the MT be handed over to the third CU, the handover request carrying a migration type in which the MT migrates the DU without migration or a migration type in which the MT migrates and the DU may migrate; the determining whether the host DUs managed by the fourth CU and the third CU can communicate by IP routing or whether an Xn interface can be established between the third CU and the fourth CU according to the first information includes: when the switching request carries a migration type that the MT migration DU does not migrate, determining whether the host DU managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU according to the first information.

In the implementation manner, when the switching request carries a migration type that the MT migration DU does not migrate, determining whether a host DU managed by the fourth CU and the third CU can communicate in an IP routing manner or whether an Xn interface can be established between the third CU and the fourth CU according to the first information; unnecessary determination operations can be reduced.

In a fourth aspect, an embodiment of the present application provides another communication method, including: generating first information, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can communicate through an IP routing manner, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided between the fourth CU and the DU of the IAB node or an F1 connection is to be established; and sending the first information.

In a possible implementation manner, the first information further includes an ID of the fourth CU and identification information identifying the MT in the fourth CU; so that the third CU can directly establish the F1 interface transmission between the DU of the IAB node and the fourth CU when determining that the fourth CU and the host DU managed by the third CU can communicate by means of IP routing, thereby saving signaling overhead.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and in the case that the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, sending eighth information to the fourth CU, where the eighth information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and under the condition that the second information is used for indicating that an Xn interface can be established between the third CU and the fourth CU, sending eighth information to the fourth CU, wherein the eighth information is used for indicating that the fourth CU and the host DU managed by the third CU can communicate in an IP routing mode.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and sending eighth information to the fourth CU when the second information is used for indicating that an Xn interface exists between the third CU and the fourth CU, wherein the eighth information is used for indicating that the fourth CU and a host DU managed by the third CU can communicate in an IP routing mode.

In one possible implementation, the method further includes: in the case where the second information is used to indicate that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, the sixth CU is selected as a candidate target CU for the MT.

In one possible implementation, the method further includes: and selecting a sixth CU as a candidate target CU of the MT in the condition that the second information is used for indicating that an Xn interface cannot be established between the third CU and the fourth CU.

In one possible implementation, the method further includes: and selecting a sixth CU as a candidate target CU of the MT in the condition that the second information is used for indicating that an Xn interface does not exist between the third CU and the fourth CU.

In one possible implementation, the method further includes: receiving ninth information from the third CU, the ninth information including an IP address of the MT under the third CU topology and a BAP configuration of the MT under the third CU topology; and transmitting tenth information to the MT, wherein the tenth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology.

In this implementation, tenth information is sent to the MT for the MT to migrate to the third CU.

In one possible implementation, the method further includes: and selecting the third CU as a candidate target CU of the MT according to the measurement report of the MT.

In one possible implementation, the first information is carried in a handover request for requesting handover of the MT to the third CU.

In one possible implementation, the handover request carries a migration type that the MT migrates that the DU does not migrate or a migration type that the MT migrates and that the DU may migrate.

In this implementation, the handover request carries a migration type that the MT migrates the DU does not migrate or a migration type that the MT migrates and the DU may migrate, so that the third CU determines, according to the migration type carried by the handover request, whether the fourth CU and the host DU managed by the third CU can perform a determination of communications by means of internet protocol IP routing.

In one possible implementation, the method further includes: and receiving a handover preparation failure message from the third CU, wherein the handover preparation failure message indicates that the third CU refuses the handover request, and the handover preparation failure message comprises a first field, and the first field indicates that the reason that the third CU refuses the handover request is that a topology under the third CU cannot provide service for the F1 interface traffic of the fourth CU.

In a fifth aspect, an embodiment of the present application provides another communication method, including: receiving first information from a second CU, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can communicate through an IP routing manner, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, the fourth CU is a target CU of a DU of the IAB node, and an F1 connection is provided between the first CU and a DU of the IAB node; and determining whether the host DUs managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU or whether an Xn interface exists between the third CU and the fourth CU according to the first information.

Possible implementations of the communication method of the fifth aspect may be found in the various possible implementations of the third aspect.

Regarding the technical effects brought about by the various possible implementations of the fifth aspect, reference may be made to the description of the technical effects of the third aspect or the various possible implementations of the third aspect.

In a sixth aspect, an embodiment of the present application provides another communication method, including: generating first information, where the first information is used for indicating whether a host DU managed by a fourth CU and a third CU can communicate through an IP routing manner, or the first information is used for indicating whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, the fourth CU is a target CU of the DU of the IAB node, and F1 connection is provided between the first CU and the DU of the IAB node; and sending the first information.

In one possible implementation, after sending the first information, the method further includes: receiving second information; and in the case that the second information is used for indicating whether the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, sending eighth information to the first CU, wherein the eighth information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

Possible implementations of the communication method of the sixth aspect may be seen in the various possible implementations of the fourth aspect.

Regarding the technical effects brought about by the various possible implementations of the sixth aspect, reference may be made to the description of the technical effects of the fourth aspect or the various possible implementations of the fourth aspect.

In a seventh aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the method embodiment of the first aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive first information from a first CU, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an internet protocol (internet protocol, IP) routing, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an F1 connection is between the first CU and a DU of an IAB node, and a radio resource control (radio resource control, RRC) connection is between the third CU and an MT of the IAB node, and the fourth CU is a candidate target CU of the DU of the IAB node; the processing unit is configured to determine, according to the first information, whether a host DU managed by the fourth CU and the third CU can communicate through IP routing, or whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to send second information to the first CU, where the second information is used to indicate that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing. Or the second information is used to indicate that an Xn interface can be or cannot be established between the third CU and the fourth CU. Or the second information is used to indicate the presence or absence of an Xn interface between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to, in a case where the processing unit determines that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing, send third information to the third CU, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

In a possible implementation manner, the transceiver unit is further configured to send third information to the third CU, where the processing unit determines that an Xn interface can be established between the third CU and the fourth CU, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

In a possible implementation manner, the transceiver unit is further configured to send third information to the third CU, where the processing unit determines that an Xn interface exists between the third CU and the fourth CU, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

In a possible implementation manner, the processing unit is further configured to establish, in a topology thereof, an F1 interface transmission between the DU of the IAB node and the fourth CU, in a case where it is determined that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing.

In a possible implementation manner, the processing unit is further configured to establish, in a topology thereof, an F1 interface transmission between the DU of the IAB node and the fourth CU, in case it is determined that an Xn interface can be established between the third CU and the fourth CU.

In a possible implementation, the processing unit is further configured to establish, in the case where an Xn interface exists between the third CU and the fourth CU, an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

In a possible implementation manner, the transceiver unit is further configured to send thirteenth information to the fourth CU, where the processing unit determines that an Xn interface can be established between the third CU and the fourth CU, where the thirteenth information is used to request the fourth CU to initiate an IAB transfer migration (IAB Transport Migration) procedure; receiving third information from the fourth CU, the third information for requesting the third CU to establish an F1 interface transmission between DUs of the IAB node and the fourth CU within its topology; the processing unit is further configured to establish, in response to the third information, an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

In a possible implementation manner, the transceiver unit is further configured to, when the processing unit determines that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing, send sixth information to the first CU, where the sixth information is used to indicate that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

In a possible implementation manner, the transceiver unit is further configured to send seventh information to the MT, where the seventh information includes an IP address of the MT under the third CU topology, and a BAP configuration of the MT under the third CU topology.

In a possible implementation manner, the transceiver unit is further configured to send fifth information to the first CU, where the fifth information includes an IP address of the MT in the third CU topology and a BAP configuration of the MT in the third CU topology.

Possible implementations of the communication device of the seventh aspect may be seen in the various possible implementations of the first aspect.

With respect to the technical effects brought about by the various possible implementations of the seventh aspect, reference may be made to the description of the technical effects of the first aspect or of the various possible implementations of the first aspect.

In an eighth aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the method embodiment of the second aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the processing unit is configured to generate first information, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an F1 connection exists between the first CU and a DU of an IAB node, an RRC connection exists between the third CU and an MT of the IAB node, and the fourth CU is a candidate target CU of a DU of the IAB node; the receiving and transmitting unit is configured to transmit the first information.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and sending third information to the third CU, where the second information is used to indicate that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and sending third information to the third CU under the condition that the second information is used for indicating that an Xn interface can be established between the third CU and the fourth CU, wherein the third information is used for requesting the third CU to establish F1 interface transmission between the DU of the IAB node and the fourth CU in the topology.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and sending third information to the third CU, wherein the third information is used for requesting the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in the topology of the third CU, if the second information is used for indicating that an Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the processing unit is further configured to select a fifth CU as a candidate target CU for the DU of the IAB node, where the second information is used to indicate that the fourth CU and the host DU managed by the third CU cannot communicate by IP routing.

In a possible implementation manner, the processing unit is further configured to select a fifth CU as a candidate target CU for the DU of the IAB node, where the second information is used to indicate that an Xn interface cannot be established between the third CU and the fourth CU.

In a possible implementation manner, the processing unit is further configured to select a fifth CU as a candidate target CU for the DU of the IAB node if the second information indicates that no Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to receive fourth information from the fourth CU, where the fourth information includes an IP address of the fourth CU; the transceiver unit is specifically configured to send the first information to the third CU, where the first information includes an IP address of the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to receive, from the third CU, sending fifth information, where the fifth information includes an IP address of the MT in the third CU topology and a BAP configuration of the MT in the third CU topology; and sending F1 Application Protocol (AP) information to the DU of the IAB node, wherein the F1AP information comprises the IP address of the fourth CU.

In a possible implementation manner, the processing unit is further configured to select the fourth CU as a candidate target CU for the DU of the IAB node from CUs having an Xn interface with the first CU.

In a possible implementation manner, the transceiver unit is further configured to send fourteenth information to the core network, where the fourteenth information is used to request the core network to select a candidate target CU for DU migration; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; the processing unit is further configured to use the fourth CU as a candidate target CU for a DU of an IAB node according to the fifteenth information.

In a possible implementation manner, the transceiver unit is further configured to send fourteenth information to the network manager, where the fourteenth information is used to request the network manager to select a candidate target CU for DU migration; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; the processing unit is further configured to use the fourth CU as a candidate target CU for a DU of an IAB node according to the fifteenth information.

Possible implementations of the communication device of the eighth aspect may be seen in the various possible implementations of the second aspect.

With respect to the technical effects brought about by the various possible implementations of the eighth aspect, reference may be made to the description of the technical effects of the second aspect or of the various possible implementations of the second aspect.

In a ninth aspect, an embodiment of the present application provides another communication apparatus having a function of implementing the behavior in the method embodiment of the third aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive first information from a second CU, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided between the fourth CU and a DU of the IAB node or an F1 connection is to be established; the processing unit is configured to determine, according to the first information, whether a host DU managed by the fourth CU and the third CU can communicate through IP routing, or whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to send second information to the second CU, where the second information is used to indicate that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing. Or the second information is used to indicate that an Xn interface can be or cannot be established between the third CU and the fourth CU. Or the second information is used to indicate the presence or absence of an Xn interface between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to send thirteenth information to the fourth CU, where the processing unit determines that an Xn interface can be established between the third CU and the fourth CU, where the thirteenth information is used to request the fourth CU to initiate an IAB transmission migration procedure; receiving third information (e.g., carried in IAB Transport Migration management Request messages) from the fourth CU requesting that the third CU establish, within its topology, an F1 interface transmission between DUs of the IAB node and the fourth CU; the processing unit is further configured to establish, in response to the third information, an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

In a possible implementation manner, the transceiver unit is further configured to, when the processing unit determines that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing, send sixth information to the second CU, where the sixth information is used to indicate that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

In a possible implementation manner, the transceiver unit is further configured to send ninth information to the second CU, where the ninth information includes an IP address of the MT in the third CU topology and a BAP configuration of the MT in the third CU topology.

In a possible implementation manner, the transceiver unit is further configured to receive eleventh information from the third CU, where the eleventh information includes a DSCP/flow label of the traffic of the IAB node. Optionally, the eleventh information further includes an IP address of the MT under the third CU topology, a BAP configuration of the MT under the third CU topology; and transmitting twelfth information to the DU of the IAB node, wherein the twelfth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology.

In one possible implementation, the first information is carried in a handover request for requesting handover of the MT to the third CU; the processing unit is further configured to send a handover preparation failure message to the second CU, where the handover preparation failure message indicates rejection of the handover request, in a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

In a possible implementation manner, the processing unit is further configured to send a handover request response message to the second CU, where the handover request response message indicates that the handover request is accepted, where it is determined that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

In one possible implementation manner, the first information is carried in a handover request for requesting that the MT be handed over to the third CU, where the handover request carries a migration type that the MT migrates the DU without migration or a migration type that the MT migrates and the DU may migrate; the processing unit is specifically configured to determine, according to the first information, whether a host DU managed by the fourth CU and the third CU can communicate by IP routing or whether an Xn interface can be established between the third CU and the fourth CU when the handover request carries a migration type that the MT migration DU does not migrate.

Possible implementations of the communication device of the ninth aspect may be seen in the various possible implementations of the third aspect.

Regarding the technical effects brought about by the various possible implementations of the ninth aspect, reference may be made to the description of the technical effects of the third aspect or the various possible implementations of the third aspect.

In a tenth aspect, an embodiment of the present application provides another communication apparatus having a function of realizing the behavior in the method embodiment of the fourth aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the processing unit is configured to generate first information, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided between the fourth CU and a DU of the IAB node or an F1 connection is to be established; the receiving and transmitting unit is configured to transmit the first information.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and in the case that the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, sending eighth information to the fourth CU, where the eighth information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and under the condition that the second information is used for indicating that an Xn interface can be established between the third CU and the fourth CU, sending eighth information to the fourth CU, wherein the eighth information is used for indicating that the fourth CU and the host DU managed by the third CU can communicate in an IP routing mode.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and sending eighth information to the fourth CU when the second information is used for indicating that an Xn interface exists between the third CU and the fourth CU, wherein the eighth information is used for indicating that the fourth CU and a host DU managed by the third CU can communicate in an IP routing mode.

In a possible implementation manner, the processing unit is further configured to select a sixth CU as the candidate target CU for the MT, where the second information is used to indicate that the fourth CU and the host DU managed by the third CU cannot communicate by IP routing.

In a possible implementation manner, the processing unit is further configured to select a sixth CU as the candidate target CU for the MT, where the second information is used to indicate that an Xn interface cannot be established between the third CU and the fourth CU.

In a possible implementation manner, the processing unit is further configured to select a sixth CU as the candidate target CU for the MT, where the second information is used to indicate that no Xn interface exists between the third CU and the fourth CU.

In a possible implementation manner, the transceiver unit is further configured to receive ninth information from the third CU, where the ninth information includes an IP address of the MT in the third CU topology and a BAP configuration of the MT in the third CU topology; and transmitting tenth information to the MT, wherein the tenth information comprises an IP address of the MT under the third CU topology and BAP configuration of the MT under the third CU topology.

In a possible implementation manner, the processing unit is further configured to select, according to the measurement report of the MT, the third CU as a candidate target CU for the MT.

In a possible implementation manner, the transceiver unit is further configured to receive a handover preparation failure message from the third CU, where the handover preparation failure message indicates that the third CU refuses the handover request, and the handover preparation failure message includes a first field, where the first field indicates that the reason why the third CU refuses the handover request is that the topology under the third CU cannot provide services for the F1 interface traffic of the fourth CU.

Possible implementations of the communication device of the tenth aspect may be seen in the various possible implementations of the fourth aspect.

Regarding the technical effects brought about by the various possible implementations of the tenth aspect, reference may be made to the description of the technical effects of the fourth aspect or the various possible implementations of the fourth aspect.

In an eleventh aspect, an embodiment of the present application provides another communication apparatus having a function of implementing the behavior in the method embodiment of the fifth aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive first information from a second CU, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, the fourth CU is a target CU of the DU of the IAB node, and an F1 connection is provided between the first CU and the DU of the IAB node; the processing unit is configured to determine, according to the first information, whether a host DU managed by the fourth CU and the third CU can communicate through IP routing, or whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU.

Regarding the technical effects brought about by the various possible implementations of the eleventh aspect, reference may be made to the description of the technical effects of the fifth aspect or the various possible implementations of the fifth aspect.

In a twelfth aspect, an embodiment of the present application provides another communication apparatus having a function of implementing the actions in the method embodiment of the sixth aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the processing unit is configured to generate first information, where the first information is used to indicate whether a host DU managed by a fourth CU and a third CU can perform communication through an IP route, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, or whether an Xn interface exists between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an RRC connection is provided between the second CU and an MT of an IAB node, the third CU is a candidate target CU of the MT, the fourth CU is a target CU of a DU of the IAB node, and an F1 connection is provided between the first CU and the DU of the IAB node; the receiving and transmitting unit is configured to transmit the first information.

In a possible implementation manner, the transceiver unit is further configured to receive second information; and under the condition that the second information is used for indicating that an Xn interface can be established between the third CU and the fourth CU, sending eighth information to the first CU, wherein the eighth information is used for indicating that the fourth CU and a host DU managed by the third CU can communicate in an IP routing mode.

With respect to the technical effects brought about by the various possible implementations of the twelfth aspect, reference may be made to the description of the technical effects of the sixth aspect or the various possible implementations of the sixth aspect.

In a thirteenth aspect, an embodiment of the present application provides another communications device, the communications device including a processor coupled to a memory for storing a program or instructions which, when executed by the processor, cause the communications device to perform the method of any one of the first to sixth aspects described above.

In the embodiment of the present application, in the process of executing the above method, the process of sending information (or signals) in the above method may be understood as a process of outputting information based on instructions of a processor. In outputting the information, the processor outputs the information to the transceiver for transmission by the transceiver. This information, after being output by the processor, may also need to be subjected to other processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver receives the information and inputs it to the processor. Further, after the transceiver receives the information, the information may need to be further processed before being input to the processor.

With respect to operations such as sending and/or receiving, etc., as referred to by a processor, if not explicitly stated or if not contradicted by actual or inherent logic in the relevant description, may be generally understood as processor-based instruction output.

In implementation, the processor may be a processor dedicated to performing the methods, or may be a processor that executes computer instructions in a memory to perform the methods, such as a general-purpose processor. For example, the processor may also be configured to execute a program stored in the memory, which when executed, causes the communication device to perform the method as described above in the first aspect or any possible implementation of the first aspect.

In one possible implementation, the memory is located outside the communication device. In one possible implementation, the memory is located within the communication device.

In one possible implementation, the processor and the memory may also be integrated in one device, i.e. the processor and the memory may also be integrated together.

In one possible implementation, the communication device further comprises a transceiver for receiving signals or transmitting signals, etc.

In a fourteenth aspect, the present application provides another communication apparatus comprising processing circuitry and interface circuitry for acquiring data or outputting data; the processing circuitry is configured to perform the method of any one of the first to sixth aspects described above.

In a fifteenth aspect, the present application provides a computer readable storage medium having stored therein a computer program comprising program instructions which when executed cause a computer to perform the method of the first aspect as described above to any of the sixth aspects described above.

In a sixteenth aspect, the present application provides a computer program product comprising a computer program comprising program instructions which when executed cause a computer to perform the method of any of the first to sixth aspects as described above.

A seventeenth aspect of the present application provides a communication system comprising a communication device according to any possible implementation of the seventh or seventh aspect, a communication device according to any possible implementation of the eighth or eighth aspect, and a communication device according to any possible implementation of the eighth or eighth aspect.

In an eighteenth aspect, the present application provides a communication system comprising a communication device according to any possible implementation of the ninth or ninth aspect and a communication device according to any possible implementation of the tenth or tenth aspect.

In a nineteenth aspect, the present application provides a communication system comprising a communication device according to any possible implementation of the eleventh or eleventh aspect and a communication device according to any possible implementation of the twelfth or twelfth aspect.

In a twentieth aspect, the present application provides a chip comprising a processor and a communication interface, the processor reading instructions stored on a memory through the communication interface, performing the method as set forth in any one of the first to sixth aspects above.

In a twenty-first aspect, an embodiment of the present application provides another communication method, including: receiving sixteenth information, wherein the sixteenth information is used for triggering an IAB node to initiate an F1 interface establishment request to a fourth CU; and based on the sixteenth information, transmitting seventeenth information to a third CU, where the seventeenth information is used to request uplink configuration information for transmission of a target F1 interface to the third CU, the third CU has RRC connection with an MT of an IAB node, and the fourth CU is a target host CU of a DU of the IAB node. The target F1 interface refers to an F1 interface between a fourth CU to be established and a DU of the relay node. In the application, the uplink configuration information for the transmission of the target F1 interface comprises an IP address and/or BAP configuration for the transmission of the target F1 interface. It will be appreciated that the sixteenth information has the effect of triggering the IAB node to initiate an F1 interface setup request to the fourth CU, and also has the effect of triggering the transmission of seventeenth information to the third CU.

In the embodiment of the application, seventeenth information is sent to a third CU based on sixteenth information; uplink configuration information required for initiating an F1 interface establishment request to a fourth CU can be timely obtained.

In one possible implementation, the sixteenth information includes identification information of the fourth CU. For example, the sixteenth information is carried in an F1 setup indication (F1 setup indication) message. The identification information of the fourth CU includes a gNB ID and/or IP address of the fourth CU.

In one possible implementation manner, the seventeenth information includes at least one of identification information of a DU of the relay node and identification information of the fourth CU. For example, the identification information of the DU of the relay node is a gNB-DU ID of the DU of the relay node, and the identification information of the fourth CU is a gNB ID or an IP address of the fourth CU.

In a twenty-second aspect, an embodiment of the present application provides another communication method, including: generating eighteenth information, and sending the eighteenth information to a third CU, where the eighteenth information is used to instruct the third CU to send uplink configuration information for transmission of a target F1 interface to an MT of an IAB node, and RRC connection is provided between the third CU and the MT of the IAB node. The target F1 interface refers to an F1 interface between the fourth CU to be established and the DU of the relay node. The fourth CU is the target hosting CU for the DU of the IAB node. The eighteenth information may include identification information that identifies the MT in the third CU.

In the embodiment of the present application, the eighteenth information is sent to the third CU, so that the third CU sends uplink configuration information for transmission of the target F1 interface to the MT of the IAB node.

In one possible implementation manner, the eighteenth information includes at least one of identification information of a DU of the relay node and identification information of the fourth CU.

In a twenty-third aspect, an embodiment of the present application provides another communication method, including: receiving eighteenth information, where the eighteenth information is used to instruct the third CU to send uplink configuration information for transmission of a target F1 interface to an MT of an IAB node, and the third CU and the MT of the IAB node have RRC connection; and transmitting nineteenth information to the MT, wherein the nineteenth information comprises uplink configuration information for transmission of the target F1 interface.

In one possible implementation, the eighteenth information includes identification information of a DU of the relay node and identification information of the fourth CU.

In a possible implementation manner, the nineteenth information further includes at least one of identification information of a DU of the relay node and identification information of the third CU.

In a twenty-fourth aspect, an embodiment of the present application provides another communication method, including: determining that a target F1 interface needs to be established based on pre-configuration information of operation administration and maintenance (operation administration AND MAINTENANCE, OAM); and when the target F1 interface is determined to be required to be established, transmitting twentieth information to a third CU, wherein the twentieth information is used for requesting the third CU to transmit uplink configuration information for transmission of the target F1 interface to an MT of an IAB node, and the third CU and the MT are connected through RRC (radio resource control). The target F1 interface refers to an F1 interface between the fourth CU to be established and the DU of the relay node. The fourth CU is the target hosting CU for the DU of the IAB node.

In the embodiment of the application, when the need of establishing the target F1 interface is determined, twentieth information is sent to the third CU; uplink configuration information for transmission of the target F1 interface can be obtained.

In one possible implementation, the twentieth information includes at least one of identification information of a DU of the relay node and identification information of the fourth CU.

In one possible implementation, the twentieth information is an RRC message.

In a twenty-fifth aspect, an embodiment of the present application provides another communication method, including: receiving twenty-first information from a third CU, the twenty-first information including an IP address and/or BAP configuration of an IAB node when an MT is under the third CU, and identification information of a fourth CU (e.g., CU-CP IP of the fourth CU), the third CU being a target CU of the MT, i.e., the MT is to migrate to the third CU, the fourth CU being a target host CU of a DU of the IAB node; and transmitting twenty-second information to the MT, wherein the twenty-second information comprises an IP address and/or BAP configuration of an IAB node when the MT is under the third CU and identification information of the fourth CU. The twenty-fifth aspect is performed by a second CU, having an RRC connection with the MT.

In the embodiment of the application, the twenty-second information is sent to the MT, so that the MT can obtain the IP address and/or BAP configuration of the IAB node when the MT is under the third CU, and the identification information of the fourth CU.

In a twenty-sixth aspect, an embodiment of the present application provides another communication method, including: receiving twenty-third information from a third CU, the twenty-third information including an IP address and/or BAP configuration of an IAB node when an MT under the third CU, the third CU being a target CU of the MT, i.e., the MT is to migrate to the third CU, or the third CU and the MT have an RRC connection therebetween; and sending twenty-fourth information to the DU of the IAB node, wherein the twenty-fourth information includes an IP address and/or BAP configuration of the IAB node when the MT is under the third CU, and identification information of the fourth CU. The twenty-fifth aspect of the execution body is a first CU, and an F1 connection is provided between the first CU and a DU of an IAB node.

In the embodiment of the application, the twenty-fourth information is sent to the DU of the IAB node, so that the DU of the IAB node can obtain the IP address and/or BAP configuration of the IAB node and the identification information of the fourth CU when the MT is under the third CU.

In a possible implementation manner, the twenty-third information further includes identification information of the fourth CU.

In a twenty-seventh aspect, an embodiment of the present application provides another communication method, including: receiving twenty-fifth information from a third CU, the twenty-fifth information including an IP address and/or BAP configuration of an IAB node when an MT is under the third CU, the third CU being a target CU of the MT, i.e., the MT is to migrate to the third CU, or the third CU and the MT have an RRC connection therebetween; and sending twenty-sixth information to the DU of the IAB node, wherein the twenty-sixth information comprises the IP address and/or BAP configuration of the IAB node when the MT is under the third CU.

In the embodiment of the application, the twenty-sixth information is sent to the DU of the IAB node, so that the DU of the IAB node can obtain the IP address and/or BAP configuration of the IAB node when the MT is under the third CU.

In a twenty-eighth aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the method embodiment of the twenty-first aspect described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the receiving and transmitting unit is configured to receive sixteenth information, where the sixteenth information is used to trigger the IAB node to initiate an F1 interface establishment request to the fourth CU; the processing unit is used for generating seventeenth information based on the sixteenth information; the transceiver unit is further configured to send the seventeenth information, where the seventeenth information is used to request uplink configuration information for transmission of a target F1 interface to the third CU, the third CU has RRC connection with an MT of an IAB node, and the fourth CU is a target host CU of a DU of the IAB node.

In a twenty-ninth aspect, an embodiment of the present application provides another communication apparatus having a function of implementing the behavior in the above-described twenty-second aspect method embodiment. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the processing unit is used for generating eighteenth information; the transceiver unit is configured to send the eighteenth information to a third CU, where the eighteenth information is configured to instruct the third CU to send uplink configuration information for transmission of the target F1 interface to the MT of the IAB node, and the third CU and the MT of the IAB node have an RRC connection

In a thirty-third aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the twenty-third aspect method embodiment described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive eighteenth information, where the eighteenth information is configured to instruct the third CU to send uplink configuration information for transmission of the target F1 interface to the MT of the IAB node, and the third CU and the MT of the IAB node have RRC connection; the processing unit is configured to generate nineteenth information, and the transceiver unit is further configured to send nineteenth information to the MT, where the nineteenth information includes uplink configuration information for transmission by the target F1 interface.

In a thirty-first aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the twenty-fourth aspect method embodiment described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the processing unit is used for determining that a target F1 interface needs to be established based on the pre-configuration information of the OAM; the transceiver unit is configured to send twentieth information to a third CU, where the twentieth information is used to request the third CU to send uplink configuration information for transmission of the target F1 interface to an MT of an IAB node, and RRC connection is provided between the third CU and the MT.

In a thirty-second aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the twenty-fifth aspect method embodiment described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive twenty-first information from a third CU, where the twenty-first information includes an IP address and/or BAP configuration of an IAB node when an MT is under the third CU, and identification information of a fourth CU (e.g., a CU-CP IP of the fourth CU), where the third CU is a target CU of the MT, i.e., the MT is to be migrated to the third CU, and the fourth CU is a target host CU of a DU of the IAB node; the processing unit is used for generating twenty-second information; the transceiver unit is further configured to send, to the MT, twenty-second information, where the twenty-second information includes an IP address and/or BAP configuration of an IAB node when the MT is under the third CU, and identification information of the fourth CU.

In a thirty-third aspect, an embodiment of the present application provides another communication device having a function of implementing the behavior in the twenty-sixth aspect method embodiment described above. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive twenty-third information from a third CU, where the twenty-third information includes an IP address and/or a BAP configuration of an IAB node when an MT under the third CU, and the third CU is a target CU of the MT, that is, the MT is to migrate to the third CU, or an RRC connection is provided between the third CU and the MT; the processing unit is further used for generating twenty-fourth information; the transceiver unit is further configured to send the twenty-fourth information to a DU of the IAB node, where the twenty-fourth information includes an IP address and/or BAP configuration of the IAB node when the MT is under the third CU, and identification information of the fourth CU.

In a thirty-fourth aspect, an embodiment of the present application provides another communication apparatus having a function of realizing the behavior in the above twenty-seventh aspect method embodiment. The communication device may be a communication apparatus, a component of a communication apparatus (e.g., a processor, a chip, or a system-on-a-chip), or a logic module or software that can implement all or part of the functions of the communication apparatus. The functions of the communication device may be implemented by hardware, or may be implemented by executing corresponding software by hardware, where the hardware or software includes one or more modules or units corresponding to the functions described above. In one possible implementation, the communication device includes: the receiving and transmitting unit and the processing unit, wherein: the transceiver unit is configured to receive twenty-fifth information from a third CU, where the twenty-fifth information includes an IP address and/or a BAP configuration of an IAB node when an MT under the third CU, and the third CU is a target CU of the MT, that is, the MT is to migrate to the third CU, or an RRC connection is provided between the third CU and the MT; the processing unit is used for generating twenty-sixth information; the transceiver unit is further configured to send the twenty-sixth information to a DU of the IAB node, where the twenty-sixth information includes an IP address and/or a BAP configuration of the IAB node when the MT is under the third CU.

In a thirty-fifth aspect, the present application provides another communication device comprising processing circuitry and interface circuitry for acquiring data or outputting data; the processing circuitry is configured to perform the method as set forth in any of the twenty-first to twenty-seventh aspects above.

In a thirty-sixth aspect, the present application provides a computer-readable storage medium having stored therein a computer program comprising program instructions which, when executed, cause a computer to perform the method as set forth in any one of the twenty-first to twenty-seventh aspects above.

In a thirty-seventh aspect, the present application provides a computer program product comprising a computer program comprising program instructions which, when executed, cause a computer to perform the method as set out in any of the twenty-first to twenty-seventh aspects above.

In a thirty-eighth aspect, the present application provides a chip comprising a processor and a communication interface, the processor reading instructions stored on a memory through the communication interface, and performing the method as in any one of the twenty-first to twenty-seventh aspects.

Drawings

In order to more clearly describe the embodiments of the present application or the technical solutions in the background art, the following description will describe the drawings that are required to be used in the embodiments of the present application or the background art.

Fig. 1 is a schematic diagram of a communication system according to an embodiment of the present application;

fig. 2 shows an example of an IAB network comprising a plurality of UEs and a plurality of IAB nodes;

FIG. 3 is a schematic diagram of an IAB network architecture;

FIG. 4 is a schematic diagram of partial migration;

FIG. 5 is a schematic illustration of a full scale;

fig. 6 is an example of a scenario of a contiguous partial migration (no migration DU);

fig. 7 is an example of a scenario for migrating DUs in a sequence partial migration according to an embodiment of the present application;

FIG. 8 is a diagram illustrating a different scenario among mIAB-MT and mIAB-DU target CUs provided by an embodiment of the present application;

FIG. 9 is an interaction flow chart of a communication method according to an embodiment of the present application;

FIG. 10 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 11 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 12 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 13 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 14 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 15 is an interaction flow chart of another communication method according to an embodiment of the present application;

FIG. 16 illustrates a possible exemplary block diagram of a communication device involved in an embodiment of the present application;

fig. 17 is a schematic structural diagram of a network device 1700 according to an embodiment of the present application.

Detailed Description

The terms first and second and the like in the description, the claims and the drawings of the present application are used for distinguishing between different objects and not for describing a particular sequential order. It will be appreciated that the various numerical numbers referred to in the embodiments of the present application are merely for ease of description and are not intended to limit the scope of the embodiments of the present application. The sequence number of each process does not mean the sequence of the execution sequence, and the execution sequence of each process should be determined according to the function and the internal logic. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion. Such as a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to the list of steps or elements but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments.

The terminology used in the following embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the present application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates to the contrary. It should also be understood that the term "and/or" as used in this disclosure refers to and encompasses any or all possible combinations of one or more of the listed items. For example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The term "plurality" as used in the present application means two or more. In the text description of the present application, the character "/", generally indicates that the front-rear associated object is an or relationship. The term "at least one" as used in the present application means one or more.

It will be appreciated that in the embodiments of the present application, "B corresponding to a" means that there is a correspondence between a and B, and B may be determined according to a. It should also be understood that determining (or generating) B from (or based on) a does not mean determining (or generating) B from (or based on) a alone, but may also determine (or generate) B from (or based on) a and/or other information.

Fig. 1 is a schematic architecture diagram of a communication system to which an embodiment of the present application is applied. As shown in fig. 1, the communication system includes a core network device 110, a radio access network device 120, a wireless backhaul device 130, and at least one terminal device (illustratively depicted in fig. 1 as terminal device 140 and terminal device 150). The terminal equipment is connected with the wireless backhaul equipment in a wireless manner and is connected with the wireless access network equipment through one or more wireless backhaul equipment. In addition, part of the terminal devices may also be directly connected to the radio access network device by wireless means). The wireless access network device is connected with the core network device in a wireless or wired mode. The core network device and the radio access network device may be separate physical devices, or may integrate the functions of the core network device and the logic functions of the radio access network device into the same physical device, or may integrate the functions of a part of the core network device and the functions of a part of the radio access network device into one physical device, which is not limited in this application. The terminal device may be fixed in position or may be movable. It should be understood that the mobile communication system shown in fig. 1 is only schematic, and other network devices may be included in the communication system, for example, a wireless relay device or a wireless backhaul device, which are not shown in fig. 1. The embodiment of the application does not limit the number of the core network equipment, the wireless access network equipment, the wireless backhaul equipment and the terminal equipment included in the mobile communication system.

The wireless access network device is an access device that a terminal device accesses to the mobile communication system in a wireless manner, and may be a base station NodeB, an evolved base station eNodeB, a base station in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system, etc., and the specific technology and the specific device configuration adopted by the wireless access network device are not limited in the embodiments of the present application. The terminal device may also be referred to as a terminal (terminal), UE, mobile Station (MS), MT, etc.

The terminal device may be a mobile phone (mobile phone), a tablet (Pad), a computer with wireless transceiving function, a Virtual Reality (VR) terminal device, an augmented reality (augmented reality, AR) terminal device, a cellular phone (cellular phone), a smart phone (smart phone), a wireless data card, a Personal Digital Assistant (PDA), a wireless terminal in industrial control (industrial control), a wireless terminal in unmanned aerial vehicle (SELF DRIVING), a wireless terminal in teleoperation (remote medical surgery), a wireless terminal in smart grid (SMART GRID), a wireless terminal in transportation security (transportation safety), a wireless terminal in smart city (SMART CITY), a wireless terminal in smart home (smart home), a machine type communication (MACHINE TYPE) terminal, a wearable device, an in-vehicle terminal device, an unmanned aerial vehicle, or the like.

The wireless backhaul device may provide backhaul services to its child nodes. In particular, it may be a relay node in a long term evolution (long term evolution, LTE) system, an IAB node in a 5G system, or other device capable of providing a wireless relay function. The radio access network device and the terminal device may be deployed on land, including indoor or outdoor, hand-held or vehicle-mounted; the device can be deployed on the water surface; but also on aerial planes, balloons and satellites. The embodiment of the application does not limit the application scenes of the wireless access network equipment and the terminal equipment.

Communication between the radio access network device and the terminal device and between the terminal device and the terminal device can be performed through a licensed spectrum (licensed spectrum), communication can be performed through an unlicensed spectrum (unlicensed spectrum), and communication can be performed through both the licensed spectrum and the unlicensed spectrum. Communication between the radio access network device and the terminal device and between the terminal device and the terminal device can be performed through a frequency spectrum of 6 gigahertz (GHz) or less, communication can be performed through a frequency spectrum of 6GHz or more, and communication can be performed by using a frequency spectrum of 6GHz or less and a frequency spectrum of 6GHz or more simultaneously. The embodiment of the application does not limit the spectrum resources used between the wireless access network equipment and the terminal equipment.

The network elements described above may be network elements implemented on dedicated hardware, software instances running on dedicated hardware, or instances of virtualized functionality on a suitable platform. In addition, the embodiment of the application can be applied to other communication technologies facing the future. The network architecture and the service scenario described in the present application are for more clearly describing the technical solution of the present application, and do not constitute a limitation to the technical solution provided by the present application, and those skilled in the art can know that the technical solution provided by the present application is equally applicable to similar technical problems with evolution of the network architecture and occurrence of new service scenarios.

In order to facilitate understanding of the embodiments of the present application, terms and technical features related to the embodiments of the present application will be briefly described below.

1) IAB network: considering that the coverage area of the high frequency band is small, in order to ensure the coverage performance of the network, the network coverage is provided in some remote areas, the deployment difficulty of the optical fiber is high, the cost is high, and flexible and convenient access and return schemes are also required to be designed. The IAB technology has been developed, and the access link (ACCESS LINK) and the backhaul link (backhaul link) of the IAB technology all adopt a wireless transmission scheme, so that optical fiber deployment is avoided or reduced, and equipment cost is reduced.

In an IAB network, a relay node, or an IAB-node (IAB-node), may provide radio access services for a UE, and traffic data of the UE is transmitted by the IAB-node via a radio backhaul link to an IAB-donor node (IAB-node). The IAB node may be referred to as mIAB (mobile IAB) node. Hereinafter, mIAB refers to mIAB node, mIAB-MT refers to MT of IAB node, mIAB-DU refers to DU of IAB node, MT is abbreviation of MT of IAB node, DU is abbreviation of DU of IAB node. The IAB node may establish a wireless backhaul link with one or more upper nodes and access the core network through the upper nodes. The upper node may perform certain control (e.g., data scheduling, timing modulation, power control, etc.) on the relay node through various signaling. In addition, the relay node may establish an access link with one or more subordinate nodes and provide access services for the one or more subordinate nodes. The upper node of the relay node may be a base station or another relay node. The lower node of the relay node may be a terminal, or may be another relay node. In some cases, an upstream node of an IAB node may also be referred to as an upstream node or parent node, and a downstream node of the IAB node may also be referred to as a downstream node or child node.

Multi-hop networking may be employed in an IAB network. Considering the requirement of service transmission reliability, the IAB node may support dual connection (dual connectivity, DC) or multiple connection (multi-connectivity) to cope with the abnormal situations (such as interruption or blocking (blockage) of the wireless link and load fluctuation) possibly occurring in the backhaul link, so as to improve the reliability guarantee of the transmission. Thus, the IAB network may support multi-hop and multi-connection networking, where multiple routing paths may exist between the terminal device and the home base station. Wherein, on a path, there is a certain hierarchical relationship between the IAB nodes, and between the IAB nodes and the host base station serving the IAB nodes, each IAB node regards the node serving it for backhaul as a parent node, and accordingly, each IAB node may be regarded as a child node of its parent node.

It should be appreciated that either a break (outage) or a blockage (blockage) of the radio link may result in a radio link failure or congestion. For example, when there is a building shelter between the UE and the IAB host node, a radio link between the UE and the IAB host node may be blocked. In the prior art, the reason for the radio link failure is mainly when the physical layer indicates that the radio link has a problem and a certain period of time is exceeded or the random access has failed or the radio link layer control (radio link control, RLC) has failed. It should be understood that there may be other reasons for the failure of the radio link, and the embodiments of the present application are not limited in this regard. Radio link congestion may refer to an amount of uplink or downlink buffered data to be transmitted by an IAB node on a link exceeding a certain threshold.

The IAB node may include an MT part (i.e., IAB-node-MT) and a DU part (i.e., IAB-node-DU., where when the IAB node faces its parent node, it may be regarded as a terminal device accessing the parent node, i.e., as an MT role, and when the IAB node faces its child node, it may be regarded as a network device providing backhaul service for the child node, i.e., as a DU role, where the child node may be another IAB node or a terminal device.

The IAB hosting node (IAB-node) may be an access network element with a complete base station function, such as the hosting base station DgNB, or an access network element in a form of a centralized unit (centralized unit, CU) and a DU split, where the IAB hosting node is connected to a core network (e.g. to a 5G core network) element serving the terminal device and provides a radio backhaul function for the IAB node. For ease of description, the centralized unit of the IAB host node may be referred to simply as a donor CU or an IAB-donor CU, and the distributed unit of the IAB host node may be referred to simply as a donor DU or an IAB-donor DU, where the donor CU may also be in a form in which a Control Plane (CP) and a User Plane (UP) are separated, e.g. a CU may consist of one CU-CP and one (or more) CU-UP.

In an IAB network, one or more IAB-nodes may be included on one transmission path between a UE and an IAB-node. Each IAB-node needs to maintain a wireless backhaul link towards the parent node and also needs to maintain a wireless link with the child node. If the sub-node of the IAB-node is a terminal device, a radio access link is between the IAB-node and the sub-node (i.e. the terminal device). If the child node of the IAB-node is another IAB-node, a wireless backhaul link is between the IAB-node and the child node (i.e., the other IAB-node). Fig. 2 shows an example of an IAB network comprising a plurality of UEs and a plurality of IAB nodes. Fig. 2 is an example of an UE including 2 UEs and 5 IAB nodes. Wherein the 2 UEs are UE1 and UE2 respectively, and the 5 IAB nodes are IAB nodes 1 to IAB node 5 respectively. It should be appreciated that fig. 2 is a bold line illustrating the access link and a thin line illustrating the backhaul link. Referring to fig. 2, in the path "UE1→iab-node4→iab-node3→iab-node1→iab-node" UE1 accesses IAB-node4 through a wireless access link, IAB-node4 is connected to IAB-node3 through a wireless backhaul link, IAB-node3 is connected to IAB-node1 through a wireless backhaul link, and IAB-node1 is connected to IAB-node through a wireless backhaul link. It should be appreciated that the IAB networking scenario shown in fig. 2 is merely exemplary, and that many other possibilities are supported in multi-hop and multi-connection networking IAB networks, which are not listed here.

The IAB-node-DU (hereinafter abbreviated as IAB-DU) is logically connected to an IAB-donor CU (hereinafter abbreviated as CU) through an F1 interface. Fig. 3 is a schematic diagram of an IAB network architecture. The F1 connection in fig. 3 is not a physical direct connection but a logical connection. In practice, the connection of the IAB-DU to the CU F1 is physically achieved through the NR Uu interface between the IAB-node MT and the parent node DU per hop, but since the final IAB-DU can communicate with the CU, it can be considered that there is a logical F1 interface. The F1 interface may also be referred to as an F1 interface, and the name of the interface is not limited in the embodiments of the present application. And this interface is referred to herein as the F1 interface as an example. The IAB-donor CU is connected to the 5G core network (5G core network,5GC/5 GCN) through the NG interface. An Xn-C interface is arranged between the IAB-donor CUs and gNodeB.

2) Partial migration (partial migration) and full migration (full migration)

In the discussion of 3GPP Release-17, IAB node migration across CUs is divided into two implementations, full migration and partial migration. The full scale includes three implementations of gradual top-down (step-down), gradual bottom-up (step-up), and full nest (full nest). In partial migration, the MT of the IAB node has a cross-CU handover, but the DU of the IAB node remains F1 connected to the source CU; in full migration, however, the IAB node DU needs to establish an F1 connection with the candidate target CU. Rel-17 mainly faces to the migration of IAB nodes taking load balancing as a starting point, so partial migration can be adopted, and the F1 interface is changed for path transmission only by switching MT, but the anchor point of the F1 interface is not changed. While Rel-18 is mainly directed to migration caused by the movement of the IAB node, when the movement range of the IAB node is large, it is not suitable to maintain the F1 connection with the source CU, and the anchor point of the F1 connection needs to be changed to the candidate target CU. Thus, full scale is an essential feature of Rel-18 mobile IAB. The status quo of partial migration and full scale discussion will be briefly described.

The IAB node where migration occurs is called a boundary node (boundary node). Fig. 4 is a schematic diagram of partial migration. Referring to fig. 4, IAB-node2 is a border node, where before the IAB-node2 performs partial migration, an RRC connection exists between IAB-MT2 and CU1, an F1 interface exists between IAB-DU2 and CU1, and the IAB-node2 and the IAB-node communicate through a source path (via the IAB-node1 formed by IAB-MT1 and IAB-DU 1), see the solid line with arrows. IAB-node2 at partial migration, IAB-MT2 has cell switch across CU and set up RRC connection with CU2, but IAB-DU2 still maintains F1 interface with CU1 and does not set up F1 interface with CU2 in order to avoid or reduce reestablishment procedure introducing F1 interface. Thus, the communication path between CU1 and IAB-DU2 becomes cross-topology: See dashed lines with arrows. In FIG. 4, CU1 and CU2 are referred to as F1-TERMINATING CU and non-F1-TERMINATING CU, respectively. It should be noted that the data is not transmitted via CU2 during this path, and CU1 and Donor-DU2 are in direct communication via the IP network. In partial migration, the interactive signaling of the core is an XN message between CU1 and CU 2: IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE message, see standard TS 38.423V17.2.0Section 9.4.2,Section 9.4.3.CU1 requests CU2 via IAB TRANSPORT MANAGEMENT REQUEST message to help it establish traffic transport across the topology, with IP address and quality of service (quality of service, qoS) information for the traffic; after the CU2 establishes the traffic transmission across the topology, return backhaul link (backhaul) information (topology in a dashed box under the CU 2) of the MT of the boundary node to the CU1 through IAB TRANSPORT MANAGEMENT RESPONSE messages, and the CU1 configures the BAP rule across the topology for the boundary node through the F1AP based on the backhaul information of the MT of the boundary node. IAB TRANSPORT MANAGEMENT REQUEST/RESPONSE is an XN message for the UE association (associated) to the MT of the (associated to) border node, so both messages are required to carry the MT of the border node XNAP ID under CU1 and XNAP ID under CU2 for identifying this MT.

FIG. 5 is a schematic diagram of a full scale. Referring to fig. 5, IAB-node3 is a border node, and in full migration, it is necessary to migrate the F1 interface between IAB-DU3 and CU1 to CU2. Since the protocol does not support the existence of an F1 interface between one DU and two CUs, in the existing implementation scheme, by expanding the IAB-DU3 into two logical DUs, i.e., IAB-DU3a (may be simply referred to as DU3 a) and IAB-DU3b (i.e., new logical DU), the IAB-DU3a always maintains the F1 interface with CU1, while the IAB-DU3b (may be simply referred to as DU3 b) is used to establish a new F1 interface with CU2, where DU3a and DU3b may be regarded as two DUs, each with an F1 interface, the UE needs to make a handover, and the cell under the IAB-DU3a is handed over to the cell under the IAB-DU3 b. In three implementations of full scale:

the first few steps of the gradual top-down are similar to partial migration, first, following the procedure of partial migration, IAB-MT3 (which may be abbreviated as MT 3) is switched, the cross-topologies F1-C and F1-U between DU3a and CU1 are established, CU2, while helping to establish the cross-topologies F1-C and F1-U between DU3a and CU1, also establishes F1-C and F1-U between DU3b and CU2, and then the UE is switched to DU3b, where the UE can communicate directly with CU2 on the target path (TARGET PATH).

The target path refers to

In the generic bottom-up, firstly, by establishing cross-topologies F1-C and F1-U between DU3b and CU2, UE can be switched under DU3b, control plane and user plane data transmission between DU3b and CU2 through topology 1 is established, after all UEs are successfully switched, a switching command is sent to MT3 or the switching command of MT3 is validated, then F1-C/U is established on TARGET PATH, and the flow of the UE can be migrated to TARGET PATH. Topology 1 refers toThe establishment of control plane and user plane data transmission between the DU3b and the CU2 through the topology 1 requires the establishment of backhaul link resources (BH RLC CH) on the DU3b and the donor-DU1 and on intermediate hop nodes (if any) therebetween, and the configuration of the BAP layer, so that the related nodes can have corresponding resources for transmitting the control plane and user plane data, and the BAP layer of each related node knows how to perform the mapping of the data packet to the resources.

The full close case is similar to the full bottom-up, by first establishing a cross-topology F1-C between DU3b and CU2 (only establishing a cross-topology F1-C, allowing UE to be switched under DU3b when making a handover decision for CU2, but not establishing a cross-topology F1-U, and not making a cross-topology data transfer), so that UE can allow handover under DU3b, immediately after sending a handover command to all UEs, sending a handover command to MT3 or validating the handover command of MT3, and then directly establishing F1-C/U on TARGET PATH, so that the traffic of UE can migrate to TARGET PATH.

3) DU migration in succession partial migration

The essence of full migration differs from partial migration in that it is whether or not a migration of DUs is required (in fact, a new logical DU is generated and then an F1 interface is established with the target CU, but from the macro point of view of the IAB node, this may be generally expressed as "migration of DUs"). In the Rel-18mobile IAB's position document, full scale is taken as an optional feature. However, this does not mean that the IAB node needs to make full migration every time it migrates. In the discussion of the first few conferences of Rel-18, the main stream view is to take the continuous partial migration as the baseline and to perform the migration of DUs when it is required. Fig. 6 is an example of a scenario of a contiguous partial migration (no migration DU). As shown in fig. 6. mIAB (mobile IAB) -MT is switched from CU1 topology to CU2 topology, and from CU2 to CU3 topology, mIAB-DU maintains F1 connection with CU1 all the time. According to the conclusion of RAN3#117b e-meeting, the CU (i.e., CU 1) at the F1 anchor point of mIAB-DU decides whether migration of DU is required. Fig. 7 is an example of a scenario for migrating DUs in a sequence partial migration according to an embodiment of the present application. FIG. 7 shows how CU1 decides to perform DU migration when mIAB-MT migrates from the topology under CU2 to the topology under CU3, and similar to full migration, mIAB-node needs to generate a new logical DU (mIAB-DU 2), establish the F1 interface with CU3, and then hand over the UE from the cell under mIAB-DU1 to the cell under mIAB-DU 2. In fig. 6 and 7, mIAB-MT is directly connected to a donor-DU, but it is only illustrative that mIAB-MT may also be connected to other fixed IAB-DUs, arriving at the donor-DU by multi-hop, and embodiments of the application are not limited.

In light of the evolution of RAN3 118 conferences held at 10 of 2022, many companies consider mIAB-MT and mIAB-DU to be different not only for source CUs but even for their target CUs. The target CU for mIAB-MT refers to the CU to which mIAB-MT is migrated, and the target CU for mIAB-DU refers to the CU to which mIAB-DU is migrated. Fig. 8 is a different scenario example of a target CU for mIAB-MT and mIAB-DU provided by an embodiment of the present application. Referring to fig. 8, the miab-MT switches from CU2 to CU3, while mIAB-DU migrates from CU1 to CU4. Reasons given by supporters of this view include:

Due to mobility, mIAB-MTs may frequently replace CUs (e.g., pico-cell CUs), while mIAB-DU anchor CUs are not prone to frequent replacement, rather than a CU with a larger control range to be accessed instead of a CU with a small station following mIAB-MT. For example, CU1 and CU4 are both CU of the macro base station, CU2 and CU3 are CU of the small base stations associated with CU1 and CU4, respectively, and when the MT switches from CU2 to CU3, CU1 determines that it is necessary to migrate the DU under CU 4.

Even for the case that mIAB-MT is the same as the target CU of mIAB-DU, mIAB-MT may be re-handed over to another CU after the first handover failure, where mIAB-DU is different from the target CU of mIAB-MT.

The aim of different companies supporting mIAB-MT and mIAB-DU is to decouple the migration of mIAB-MT and mIAB-DU entirely. That is, not only is mIAB-MT migration in Rel-17 required to be supported, mIAB-DU is not migrated (partial migration); in Rel-18, mIAB-DU migration is also allowed, mIAB-MT is not migrated. In this way, not only the target CUs for mIAB-MT and mIAB-DU may be different, but also the time to select the target CUs may be different (only one network element is migrated at a time).

The target CU of the MT determines the path of the F1 connection and the target CU of the DU determines the anchor CU of the F1 connection. When the DU is different from the target CU of the MT, there is a new problem that: how to ensure that nodes on the path of the F1 connection are communicable (IP reachable) with the anchor CU of the F1 connection. Referring to FIG. 8, when migrating DUs, if CU4 is the target CU for which CU1 selects for DU, then mIAB-the connection of the F1 interface between CU4 and CU 2 is routed through the donor-DU3, and until then, CU3 and CU4 have not interacted with whether or not communication between CU4 and donor-DU3 is possible. Whether communication between the CU4 and the donor-DU3 is possible may be whether communication between the CU4 and the donor-DU3 is possible through IP routing, whether an Xn interface can be established between the CU4 and the CU3, or whether an Xn interface exists between the CU4 and the CU 3. Therefore, if the prior art is directly migrated to a scenario where the DU is different from the target CU of the MT, communication between the two target CUs may be disabled, resulting in failure of data transmission. It will be appreciated that in the scenario shown in fig. 8, CU4 is the target CU selected by CU1 for the DU, CU3 is the target CU for the MT, and it is necessary to ensure that communication is possible between CU4 (the anchor CU to which F1 is connected) and CU3 (the node on the path to which F1 is connected).

The embodiment of the application provides a communication scheme capable of ensuring that the nodes on the path of the F1 connection and the anchor point CU of the F1 connection can communicate (IP reachable). In other words, the communication scheme provided by the embodiment of the application can avoid or reduce the occurrence of data transmission failure between the target CU of the MT of the IAB node and the target CU of the DU of the IAB node. In addition, the embodiment of the application also provides a mIAB-node obtaining communication scheme of the configuration (such as the IP address of MT, BAP configuration and CU-CP IP address of target CU) required for establishing a new F1 interface or migrating the F1 interface. The migration scenario suitable for the communication scheme provided by the embodiment of the application is described first.

Different migration scenarios are presented for the target CUs of mIAB-DU and mIAB-MT in mIAB, as shown in FIG. 8. Further, the target CUs for mIAB-DU and mIAB-MT can be subdivided differently into four scenarios:

scene 1: MT migration results in DU migration, and the target CUs for both migration are different. The MT switches based on signal quality due to the movement of the IAB node, while the anchor CU of the DU also determines that the DU needs to be switched due to the MT's switch. In this scenario, both MT and DU are migrated, and the entire flow is triggered by MT migration. As shown in fig. 8, the MT is switched from CU2 to CU3, and at this time, CU1 determines that the DU needs to be switched from CU1 to CU4.

Scene 2: when the MT does not migrate, the DU migrates, and the target CU for DU migration is different from the CU of the MT. Although in this scenario the MT does not migrate and there is no so-called "target CU" for the MT, it is also within the scope of the application that the nature is that the CU controlling the MT is not the same as the DU. The scene covers the situation that after MT migration for a period of time, DU is migrated again, and belongs to the popularization of scene 1. As in fig. 8, MT is already connected to CU3, or always connected to CU3, at which point CU1 determines that the DU needs to be switched from CU1 to CU4 (topology part of CU2 does not exist).

Scene 3: DU migration results in MT migration, and the target CU for both migration is different. In this scenario, the source CU of the DU needs to migrate, and after selecting the target CU for the DU, the source CU of the MT is notified, and then the source CU of the MT controls the migration of the MT. In this scenario, both MT and DU are migrated, and the whole procedure is triggered by DU migration, as in fig. 8, where DU is switched from CU1 to CU4, and CU2 determines that MT needs to be switched from CU2 to CU3.

Scene 4: when DU is not migrated, MT migrates, and the target CU migrated by MT is different from the CU of DU. This scenario is similar to partial migration, the only difference being that we consider that the DU is not migrated in the MT migration of this time. Therefore, if the target CU of the MT cannot communicate with the current CU of the DU, it cannot be expected that the DU will also migrate, and it needs to be ensured that the target CU of the MT and the current CU of the DU are communicable, otherwise, the source CU of the MT needs to reselect the target CU for the MT. As shown in fig. 8, the MT switches from CU2 to CU3, at this time mIAB-always maintains the F1 connection between DU1 and CU1, and no migration of DUs is performed (topology part of CU4 does not exist).

The following describes a communication scheme provided by an embodiment of the present application with reference to the accompanying drawings.

Fig. 9 is an interaction flow chart of a communication method according to an embodiment of the present application. The method in fig. 9 is applicable to scenario 1 and scenario 2 described above. In fig. 9, CU1 represents a first CU, CU2 represents a second CU, CU3 represents a third CU, CU4 represents a fourth CU, and the meaning of each network element in the other subsequent figures can be referred to as meaning in fig. 9. The first CU has an F1 connection with the DU of the IAB node, the MT of the IAB node has an RRC connection with the third CU or the second CU, and the fourth CU is a candidate target CU for the DU of the IAB node. As shown in fig. 9, the method includes:

901. the third CU sends a message 1 to the second CU.

In one possible implementation, message 1 is a handover request response (HANDOVER REQUEST ACK) for mIAB-MT. The second CU may send a HANDOVER REQUEST (HANDOVER REQUEST) for mIAB-MT to the third CU before the third CU sends message 1 to the second CU. When message 1 is a handover request response for mIAB-MT, step 901 belongs to the handover preparation flow of MT (MT has not performed handover yet, is also connected under the second CU).

In one possible implementation, message 1 is a message releasing the context for mIAB-MT, e.g., UE CONTEXT RELEASE. For example, after mIAB-MT has switched under the third CU, the third CU sends a message to the second CU to release the context for mIAB-MT at the source station. When message 1 is a message to release the context for mIAB-MT, step 901 is the context release procedure after MT handover execution is completed.

902. The second CU sends a message 2 to the first CU.

Message 2 may carry the gNB-ID of the third CU, XNAP ID of the mIAB-MT under the first, second, third CU, the IP address of the donor-DU3 or the third CU. Step 902 may be replaced by: the third CU sends a message 2 to the first CU.

Step 901 and step 902 are optional. When the method flow in fig. 9 is applicable to scenario 1 described above, the MT of the IAB node has an RRC connection with the second CU, and the method flow in fig. 9 includes step 901 and step 902. That is, when steps 901 and 902 exist, the method flow in fig. 9 represents the MT handover procedure, and is applicable to scenario 1 described above. When the method flow in fig. 9 is applicable to scenario 2 above, the MT of the IAB node has an RRC connection with the third CU, and the MT has always been switched under the third CU or under the third CU before performing the method flow in fig. 9, the method flow in fig. 9 does not include step 901 and step 902. That is, when step 901 and step 902 do not exist, the MT is always under the third CU, or has already been switched to under the third CU, and the method flow in fig. 9 is applicable to the above scenario 2. Whereas for steps subsequent to step 902, scenario 1 and scenario 2 are the same.

903. The first CU selects the fourth CU as a candidate target CU for the DU of the IAB node.

One possible implementation of step 903 is as follows: and selecting the fourth CU from CUs with Xn interfaces with the first CU as a candidate target CU of the DU of the IAB node. For example, the first CU selects the fourth CU as a candidate target CU for the DU of the IAB node from a target list, where the target list includes identification information of one or more CUs having an XN interface with the first CU. Optionally, the fourth CU is any one of the object lists. The first CU may randomly select one of the CUs in the target list as a candidate target CU for the DU of the IAB node. Optionally, the fourth CU is a CU with a largest service range in the target list.

Another possible implementation of step 903 is as follows: the first CU sends fourteenth information to the core network (e.g., AMF network element), the fourteenth information being used to request the core network to select a candidate target CU for DU migration for the first CU; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; according to the fifteenth information, the fourth CU is set as a candidate target CU for the DU of the IAB node. The fourteenth information may include identification information of the first CU.

Another possible implementation of step 903 is as follows: transmitting fourteenth information to a network manager (e.g., an OAM network element), the fourteenth information being used to request the network manager to select a candidate target CU for DU migration for the first CU; receiving fifteenth information, wherein the fifteenth information comprises identification information of the fourth CU; according to the fifteenth information, the fourth CU is set as a candidate target CU for the DU of the IAB node.

904. The first CU sends first information to the fourth CU.

The first information is used to indicate whether or not the host DUs managed by the fourth CU and the third CU can communicate by IP routing. Or the first information is used for indicating whether the Xn interface can be established between the third CU and the fourth CU. Or the first information is used for indicating whether an Xn interface exists between the third CU and the fourth CU. The following describes an example of a determination that the first information indicates whether or not the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing. The first information may carry one or more of a gNB-ID of the first CU, a gNB-ID of the third CU, an IP address of the third CU, or an IP address of the donor-DU 3. Optionally, the first information carries mIAB-MT identification information under the third CU, e.g., XNAP ID. mIAB-identification information of the MT under the third CU may be referred to as identification information identifying the MT in the third CU.

905. The fourth CU determines, based on the first information, whether the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

The embodiment of the present application does not limit the manner in which the host DUs managed by the fourth CU and the third CU can communicate by IP routing according to the first information. For example, the fourth CU queries the IP routing table, if there is an entry for the third CU or the donor-DU managed by the third CU (e.g., the next hop IP address can be queried according to the IP address of the third CU or the donor-DU managed by the third CU), the fourth CU and the host DU managed by the third CU are considered to be capable of communicating by way of IP routing, i.e., IP reachable; otherwise, the host DUs managed by the fourth CU and the third CU are considered not capable of communicating by way of IP routing, i.e. IP is not reachable.

When the first information is used to indicate whether the Xn interface can be established between the third CU and the fourth CU, step 905 may be replaced with: the fourth CU determines (or judges) whether an Xn interface can be established between the third CU and the fourth CU according to the first information. When the first information is used to indicate whether an Xn interface exists between the third CU and the fourth CU, step 905 may be replaced with: the fourth CU determines whether an Xn interface exists between the third CU and the fourth CU.

906. The fourth CU sends second information to the first CU.

The second information is used to indicate that the host DU managed by the third CU and the fourth CU can or cannot communicate through IP routing. The second information may be carried in an existing message or may be carried in a new message, for example, a message named IP routable result notification, which is not limited by the present application. The second information may carry the IP address of the fourth CU. The IP address of the fourth CU may be the IP address of the CU-CP of the fourth CU described above. Such lower level is defined in view of the fact that the IP address on the CU for servicing F1 Control Plane (CP) messages may be different from the IP addresses for other purposes. The IP address here is the CU's IP address for transmission between DUs with the IAB node, CU-CP. The purpose of carrying the IP address of the fourth CU is to send this IP address to the IAB node by the first CU in a subsequent step for establishing an F1 interface between the DU of the IAB node and the fourth CU. In addition, the second information also carries identification information identifying the MT in the fourth CU, for example XNAP ID of the MT under the fourth CU, for the first CU to inform the third CU later, so that the third CU can send DSCP or stream label to the third CU.

907. The first CU selects the fifth CU as a candidate target CU for the DU of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

If the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate through IP routing, the first CU returns to step 903, i.e. a candidate target CU is selected again for the DU of the IAB node. The first CU selects the fifth CU as the candidate CU for the DU of the IAB node in a similar manner as the fourth CU is selected as the candidate CU for the DU of the IAB node, and will not be described again.

908. The first CU transmits third information to the third CU in a case where the second information is used to instruct the fourth CU and the third CU to manage the host DUs that can communicate by way of IP routing.

The third information is used to request the third CU to establish in its topology an F1 interface transmission configuration resource between the DU of the IAB node and the fourth CU. For example, the third information is carried in Transport Migration Management Request messages. The third information may include the gNB-ID of the fourth CU and identification information of the MT under the fourth CU, such as XNAP ID in fourth CU of mIAB-MT. Optionally, the third information includes an IP address of the fourth CU, for example an IP address of a CU-CP of the fourth CU. The reason that the third information carries the gNB-ID of the fourth CU and mIAB-MT XNAP ID in the fourth CU is that this F1 connection is to be used between mIAB-DU2 and the fourth CU, which in the following process needs to issue a DSCP/stream tag to the fourth CU. The third CU needs to be able to find the fourth CU and this message may be UE Associated. The purpose of the third information including the IP address of the fourth CU is to issue this IP address to mIAB-node in a subsequent step for establishing the F1 interface between mIAB-DU2 and the fourth CU. This is optional because the IP address of the fourth CU may not inform the third CU, but the first CU may inform mIAB-node directly through the F1 interface with mIAB-DU 1.

It should be noted that the first CU performs step 907 or step 908 according to the second information, and does not perform both step 907 and step 908.

906', The fourth CU transmits third information to the third CU in case it is determined that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing.

The third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology. After determining that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing (i.e., IP reachable), the fourth CU does not need to inform the first CU, and the fourth CU directly sends third information to the third CU. The third information may be carried in a topology traffic transfer request IAB Transport Migration Management Request message. For example, after determining that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, the fourth CU does not need to inform the first CU, and directly initiates a cross-topology traffic transmission request to the third CU, where the request carries an IP address of the fourth CU, e.g., an IP address of a CU-CP of the fourth CU. The role of the IP address of the CU-CP carrying the fourth CU here is the same as in step 908, and here it must be carried, since the first CU is not yet aware of the fourth CU's IP address at this time. If the host DUs managed by the fourth and third CUs cannot communicate by way of IP routing (i.e., IP is not reachable), the fourth CU informs the first CU, lets it go back to step 903, reselects the destination CU for the DU. In contrast to step 908, there is no need for an additional gNB-ID indicating the fourth CU, since this message is sent from the fourth CU to the third CU, which is able to know the gNB-ID of the fourth CU.

907', The fourth CU transmitting sixth information to the first CU in case it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by means of IP routing.

The sixth information is used to indicate that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing. The sixth information may be carried in an existing message or may be carried in a new message, for example, a message named IP non-routable result notification, which is not limited by the present application.

908', The first CU selects the fifth CU as a candidate target CU for the DU of the IAB node in response to the sixth information.

If the first CU receives information, for example, sixth information, indicating that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing, the first CU returns to step 903, i.e., selects a candidate target CU again for the DU of the IAB node.

It should be noted that the fourth CU performs step 906 'or step 907' without performing both step 906 'and step 907'.

Steps 906 through 908 are optional. Steps 906 through 908 may be replaced with steps 906 'through 908'. One possible implementation of the method flow in fig. 9 includes: step 901 to step 903 (optional), step 904, step 905, step 906, step 907. Another possible implementation of the method flow in fig. 9 includes: step 901 to step 903 (optional), step 904, step 905, step 906, step 908. Another possible implementation of the method flow in fig. 9 includes: step 901 to step 903 (optional), step 904, step 905, step 906'. Another possible implementation of the method flow in fig. 9 includes: step 901 to step 903 (optional), step 904, step 905, step 907', step 908'.

When selecting the target CU (fourth CU) of the DU, the first CU negotiates with the MT CU (third CU), and the fourth CU determines whether the selected fourth CU is available. If the first CU is feasible, performing cross-topology traffic migration, and if the first CU is not feasible, notifying the first CU to reselect the target CU of the DU; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

Fig. 10 is an interaction flow chart of another communication method according to an embodiment of the present application. The method in fig. 10 is applicable to scenario 1 and scenario 2 described above. The meaning of each network element in fig. 10 can be referred to as meaning in fig. 9. The first CU has an F1 connection with the DU of the IAB node, the MT of the IAB node has an RRC connection with the third CU or the second CU, and the fourth CU is a candidate target CU for the DU of the IAB node. As shown in fig. 10, the method includes:

1001. the third CU sends a message 1 to the second CU.

1002. The second CU sends a message 2 to the first CU.

1003. The first CU selects the fourth CU as a candidate target CU for the DU of the IAB node.

Steps 1001 to 1003 may be the same as steps 901 to 903 in fig. 9, and are not described here.

1004. The first CU sends a message 3 to the fourth CU.

Message 3 is used to request the CU-CP IP address of the fourth CU. If the XN interface is not arranged between the first CU and the fourth CU, the message between the first CU and the fourth CU is forwarded through the AMF.

1005. The fourth CU sends a message 4 to the first CU.

Message 4 may carry the IP address of the CU-CP of the fourth CU and XNAP ID of mIAB-MT under the fourth CU. Wherein the purpose of message 4 carrying mIAB-MT XNAP ID under the fourth CU is for the first CU to subsequently inform the third CU so that the third CU can send DSCP/stream labels to the fourth CU.

1006. The first CU sends first information to the third CU.

For a description of the first information, reference may be made to the description of the first information in the flow of the method of fig. 9. The first information includes an IP address of the fourth CU, e.g., a CU-CP IP address of the fourth CU. Optionally, the first information further includes a gNB-ID of the fourth CU and XNAP ID of mIAB-MT under the fourth CU. The uses of gNB-ID and mIAB-MT of the fourth CU under XNAP ID of the fourth CU are: if the third CU judges that the IP is reachable, the resource serving the F1 interface between mIAB-DU and the fourth CU can be directly configured, and then DSCP/flow label is sent to the fourth CU.

1007. The third CU determines whether the host DU managed by the fourth CU and the third CU can communicate by way of IP routing according to the first information.

Step 1007 may refer to step 905 in fig. 9. The implementation of the third CU to determine whether the fourth CU and the third CU managed host DU can communicate through IP routing may be the same as the implementation of the fourth CU to determine whether the fourth CU and the third CU managed host DU can communicate through IP routing.

1008. The third CU sends second information to the first CU.

Step 1008 may refer to step 906 in fig. 9.

1009. The first CU selects the fifth CU as a candidate target CU for the MT of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

Step 1009 may refer to step 907 in fig. 9.

1010. The first CU transmits third information to the third CU in a case where the second information is used to instruct the fourth CU and the third CU to manage the host DUs that can communicate by way of IP routing.

Step 1010 may refer to step 908 in fig. 9. Step 1010 differs from step 908 in fig. 9 in that the third information does not need to carry the CU-CP IP address of the fourth CU. It should be noted that the first information in step 1006 or the third information in step 1010 includes the gNB-ID of the fourth CU and XNAP ID in of mIAB-MT. It is noted that the first CU performs step 1009 or step 1010 according to the second information, and does not perform both step 1009 and step 1010.

1008', The third CU sends thirteenth information to the fourth CU in case it is determined that the fourth CU and the host DU managed by the third CU can communicate by means of IP routing.

For example, thirteenth information is carried in IAB Transport Migration management procedure Request messages, where the thirteenth information is used to request the fourth CU to initiate an IAB transfer migration (IAB Transport Migration) procedure. The thirteenth information carries identification information for identifying the MT in the fourth CU and identification information for identifying the MT in the third CU. For example, XNAP ID of the MT under the third CU and the fourth CU is carried in the thirteenth information, to inform the fourth CU about which MT the traffic is migrated.

1009', The fourth CU sends third information to the third CU.

The third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology. The third information may include a CU-CP IP address of the fourth CU.

1010', The third CU establishes an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

Step 1008 'and step 1009' are optional. After performing step 907, the third CU may directly perform step 1010' in case it is determined that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing.

1008", The third CU sends sixth information to the first CU in case it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by means of IP routing.

Step 1008 "may refer to step 907' in fig. 9.

1009", The first CU selects the fifth CU as a candidate target CU for the DU of the IAB node in response to the sixth information.

Step 1009 "may refer to step 908' in fig. 9. Steps 1008 to 1010 may be replaced with steps 1008 'to 1010', 1008 "and 1009". One possible implementation of the method flow in fig. 10 includes: steps 1001 to 1003 (optional), steps 1004 to 1007, step 1008, step 1009. Another possible implementation of the method flow in fig. 10 includes: steps 1001 to 1003 (optional), steps 1004 to 1007, step 1008, step 1010. Another possible implementation of the method flow in fig. 10 includes: steps 1001 to 1003 (optional), steps 1004 to 1007, and steps 1008 'to 1010'. Another possible implementation of the method flow in fig. 10 includes: steps 1001 to 1003 (optional), steps 1004 to 1007, and steps 1008 "to 1009".

In the embodiment of the present application, the first CU negotiates with the CU of the MT (third CU) when selecting the target CU of the DU (fourth CU). It is determined by the third CU whether the selected fourth CU is viable. If feasible, then cross topology traffic migration is performed, and if not feasible, then the first CU is notified to reselect the target CU for DUs.

In contrast to the prior art, the embodiments shown in fig. 9 and 10 enable the following two scenarios: mt migration results in DU migration, and the target CUs for both migration are different; when the MT does not migrate, the DU migrates, and the target CU for DU migration is different from the CU of the MT. The problem that the cross-topology F1 connection is not feasible due to the fact that the prior art is directly applied to the two scenes is solved, so that the cross-topology traffic transmission can be successfully established in the two scenes, and the flexibility of the IAB migration scene is improved.

Fig. 11 is an interaction flow chart of another communication method according to an embodiment of the present application. The method in fig. 11 is applicable to scenario 3 (DU has completed migration) or scenario 4 described above. The meaning of each network element in fig. 11 can be referred to as meaning in fig. 9. The second CU has RRC connection with the MT of the IAB node, the third CU is a candidate target CU of the MT, and the fourth CU has F1 connection with the DU of the IAB node. As shown in fig. 11, the method includes:

1101. The second CU selects the third CU as a candidate target CU for the MT.

One possible implementation of step 1101 is as follows: and selecting the third CU as a candidate target CU of the MT according to the measurement report of the MT. Another possible implementation of step 1101 is as follows: the second CU selects a third CU adjacent to the MT and having the lightest load as a candidate target CU for the MT. The second CU may also select candidate target CUs for the MT by other means, not limited herein. There is an F1 connection between the fourth CU and the IAB node's DU, indicating that the IAB node's DU has been migrated to the fourth CU before migrating the MT (scenario 3), or that the IAB node's DU remains F1 connected to the fourth CU all the time (scenario 4).

1102. And performing a switching preparation flow of the MT between the second CU and the third CU.

One possible implementation of step 1102 is as follows: the second CU sends a handover request, i.e., a Handover (HO) request, to the third CU requesting migration of the MT to the third CU, the handover request including mIAB-MT XNAP ID under the second CU; the third CU performs admission control (determines whether to accept MT handover), and if so, returns a handover request response to the second CU, carrying mIAB-MT XNAP ID under the third CU. Embodiments of the present application are not limited to the implementation of step 1102.

1103. The second CU sends first information to the third CU.

For a description of the first information, reference may be made to the description of the first information in the flow of the method of fig. 9. The first information includes an IP address of the fourth CU, e.g., a CU-CP IP address of the fourth CU. Optionally, the first information includes a gNB-ID of the fourth CU and XNAP ID of mIAB-MT under the fourth CU. Optionally, the first information may be carried in the handover request of step 1102.

1104. The third CU determines whether the host DU managed by the fourth CU and the third CU can communicate by way of IP routing according to the first information.

Step 1104 may refer to step 905 in fig. 9.

1105. The third CU sends second information to the second CU.

For a description of the second information, reference may be made to the description of the second information in the flow of the method of fig. 9. Optionally, the second information may be carried in the handover request response of step 1102.

1106. The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

Step 1106 may refer to step 907 in fig. 9.

1107. The second CU transmits eighth information to the fourth CU in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

The eighth information indicates that the host DU managed by the third CU and the fourth CU can communicate by IP routing. It should be noted that the second CU performs step 1106 or step 1107 according to the second information, and does not perform both step 1106 and step 1107.

1108. The fourth CU sends third information to the third CU.

The third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

1105', The third CU sends thirteenth information to the fourth CU in case it is determined that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing.

Step 1105 'may refer to step 1008' in fig. 10.

1106', The fourth CU sends third information to the third CU.

Step 1106 'may refer to step 1009' in fig. 10.

1107', The third CU establishes within its topology an F1 interface transmission between the DUs of the IAB node and the fourth CU.

Step 1105 'and step 1106' are optional. After performing step 904, the third CU may directly perform step 1010' in case it is determined that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing.

1105", The third CU sends sixth information to the second CU in case it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

For a description of the sixth information, reference may be made to the description of the sixth information in the flow of the method of fig. 9.

1106", The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in response to the sixth information.

Step 1106 "may refer to step 908' in FIG. 9. Steps 1105 to 1108 may be replaced with steps 1105 'to 1107', 1105″ and 1106". One possible implementation of the method flow in fig. 11 includes: steps 1101 through 1106. Another possible implementation of the method flow in fig. 11 includes: steps 1101 to 1105, 1107 to 1108. Another possible implementation of the method flow in fig. 11 includes: steps 1101 to 1104, 1105 'to 1107'. Another possible implementation of the method flow in fig. 11 includes: steps 1101 to 1104 and 1105 "to 1106".

In the embodiment of the present application, the second CU negotiates with the CU (scenario 4, fourth CU) that always controls the DU when selecting the target CU (third CU) of the MT. It is determined by the third CU whether the selected third CU is viable. If the topology-spanning traffic migration is feasible, notifying the second CU to reselect the target CU of the MT if the topology-spanning traffic migration is not feasible; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

Fig. 12 is an interaction flow chart of another communication method according to an embodiment of the present application. The method in fig. 12 is applicable to scenario 3 (DU has completed migration) or scenario 4 described above. The meaning of each network element in fig. 12 can be referred to as meaning in fig. 9. The second CU has RRC connection with the MT of the IAB node, the third CU is a candidate target CU of the MT, and the fourth CU has F1 connection with the DU of the IAB node. As shown in fig. 12, the method includes:

1201. The second CU selects the third CU as a candidate target CU for the MT.

Step 1201 may refer to step 1101.

1202. And performing a switching preparation flow of the MT between the second CU and the third CU.

Step 1202 may refer to step 1102.

1203. The second CU sends the first information to the fourth CU.

For a description of the first information, reference may be made to the description of the first information in the flow of the method of fig. 9. The first information includes the gNB-ID of the third CU and/or the IP address of the third CU, and XNAP ID of mIAB-MT under the third CU. The first information may be used by the fourth CU to determine IP reachability with the donor-DU3 and initiate a cross-topology traffic setup request to the third CU if IP is reachable.

1204. The fourth CU determines, based on the first information, whether the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

Step 1204 may refer to step 905.

1205. The fourth CU sends second information to the second CU.

1206. The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

1207. The second CU transmits eighth information to the fourth CU in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

Step 1207 may refer to step 1107.

1208. The fourth CU sends third information to the third CU.

Step 1208 may refer to step 1108.

1205', The fourth CU sends third information to the third CU in case it is determined that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing.

1206', The fourth CU sends sixth information to the second CU in case it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by means of IP routing.

1207', The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in response to the sixth information.

In the embodiment of the present application, the second CU negotiates with the CU (scenario 4, fourth CU) that always controls the DU when selecting the target CU (third CU) of the MT. It is determined by the fourth CU whether the selected third CU is viable. If the topology-spanning traffic migration is feasible, notifying the second CU to reselect the target CU of the MT if the topology-spanning traffic migration is not feasible; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

Fig. 13 is an interaction flow chart of another communication method according to an embodiment of the present application. The method in fig. 13 is applicable to scenario 3 (DU incomplete migration) described above. The meaning of each network element in fig. 13 can be referred to the meaning in fig. 9. The first CU is connected with the DU of the IAB node through F1, the second CU is connected with the MT of the IAB node through RRC, the third CU is a candidate target CU of the MT, and the fourth CU is a candidate target CU of the DU. As shown in fig. 13, the method includes:

1301. the first CU selects the fourth CU as a candidate target CU for the DU of the IAB node.

Step 1301 can refer to step 903.

1302. The first CU sends a DU migration request message to the fourth CU.

The DU migration request message carries the gNB-ID of the first CU. Optionally, the DU migration request message carries mIAB-MT XNAP ID under CU 1. And, optionally, the DU migration request message carries mIAB-DU2 gNB-DU ID. The DU migration request message is used to request migration of DUs to the fourth CU.

1303. The fourth CU sends a DU migration request response message to the first CU.

The DU migration request response message carries the gNB-ID of the fourth CU. Optionally, the DU migration request response message carries mIAB-MT XNAP ID under the fourth CU, and the IP address of the fourth CU CP plane.

1304. The first CU sends a message 5 to the second CU.

Message 5 carries identification information of the candidate target CU selected for the DU by the first CU, e.g. the gNB-ID of the fourth CU. Optionally, message 5 also carries XNAP ID under the fourth CU of mIAB-MT received in step 1303, and the IP address of the CP plane of the fourth CU.

1305. The second CU selects the third CU as a candidate target CU for the MT.

Step 1305 may refer to step 1101.

1306. And performing a switching preparation flow of the MT between the second CU and the third CU.

Step 1306 may refer to step 1102. One possible implementation of step 1306 is as follows: the second CU sends a handover request, i.e., a Handover (HO) request, to the third CU requesting to handover (or migrate) the MT to the third CU, which may include mIAB-MT XNAP ID under the second CU; the third CU performs admission control (judging whether MT switching is accepted or not); if the handover request is denied, returning a handover preparation failure (handover preparation failure) message to the second CU indicating that the handover request is denied, the handover preparation failure message may carry XNAP ID of mIAB-MT under the third CU; if the handover request is accepted, a handover request response (HO request ACK) is returned to the second CU, indicating that the handover request is accepted.

1307. The second CU sends first information to the third CU.

Step 1307 can refer to step 1103. Alternatively, the first information may be carried in the handover request of step 1306.

1308. The third CU determines whether the host DU managed by the fourth CU and the third CU can communicate by way of IP routing according to the first information.

Step 1308 may refer to step 905 in fig. 9. Step 1308 is optional.

In one possible implementation, the handover request in the first information multiplexing step 1306, the handover request response or the handover preparation failure message in the second information multiplexing step 1306. In other words, the first information is the handover request in step 1306, and the second information is the handover request response or the handover preparation failure message in step 1306. The handover request (i.e., the first information) carries the current migration type. The migration type carried by the handover request includes MT migration DU not migrating (partial migration), or MT migration and DU possible migration (full migration). In other words, the handover request carries a migration type that the MT migrates the DU does not migrate or a migration type that the MT migrates and the DU may migrate. When the migration type carried in the handover request is MT migration DU is not migrated, the third CU performs step 1308, namely, determines IP reachability between the douor-DU 3 and the mIAB-DU CUs; when the IP is reachable (i.e., the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing), the third CU accepts the handover request; when the IP is not reachable, the handover request is denied. When the migration type carried in the handover request is MT migration and the DU may be migrated, the third CU does not perform step 1308, i.e. the third CU does not determine IP reachability, and does not reject the handover request because the IP reachability is not satisfied. Rejecting the handoff request refers to rejecting the handoff of the MT.

1309. The third CU sends second information to the second CU.

For a description of the second information, reference may be made to the description of the second information in the flow of the method of fig. 9. Step 1309 can refer to step 1105. Optionally, the second information may be carried in the handover request response of step 1306.

In one possible implementation, the first information is carried in the handover request in step 1306, and the second information is carried in the handover request response or handover preparation failure message in step 1306. Alternatively, the first information may multiplex the handover request in step 1306, and the second information may multiplex the handover request response or handover preparation failure message in step 1306. In other words, the first information is the handover request in step 1306, and the second information is the handover request response or the handover preparation failure message in step 1306. For example, when the third CU determines that the fourth CU and the host DU managed by the third CU can communicate by IP routing according to the first information (i.e., the handover request), the third CU sends a handover response message, i.e., the second information, to the second CU, indicating that the handover request is accepted; when the third CU determines, according to the first information, that the fourth CU and the host DU managed by the third CU cannot communicate by means of IP routing, the third CU sends a handover preparation failure message, i.e., second information, to the second CU, indicating rejection of the handover request. Optionally, the first field (which may be referred to as the Cause field) in the handover preparation failure message indicates that the third CU refuses the handover request because the topology under the third CU is unable to service the F1 interface traffic of the fourth CU (e.g., because there is no IP reachable between the donor-DU3 and the fourth CU, or there is no XN interface between the third CU and the fourth CU).

1310. The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

Step 1310 may refer to step 907 in fig. 9.

1311. The second CU sends a message 6 to the first CU in case the second information indicates that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing.

Message 6 is used to inform the first CU that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing. It should be noted that the second CU performs step 1310 or step 1311 according to the second information, and does not perform both step 1310 and step 1311.

1312. The first CU sends third information to the third CU.

In one possible implementation, step 1311 is replaced by: the second CU sends a message 6 to the fourth CU in case the second information is used to instruct the host DUs managed by the fourth CU and the third CU to be able to communicate by means of IP routing; step 1312 is replaced with: the fourth CU sends third information to the third CU.

1309', The third CU transmits thirteenth information to the fourth CU in a case where it is determined that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing.

1310', The fourth CU sends third information to the third CU.

1311', The third CU establishes an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

Steps 1309 'through 1311' can be referred to as steps 1105 'through 1107' in fig. 11.

1309", The third CU transmits sixth information to the second CU in a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

1310", The second CU selecting the fifth CU as a candidate target CU for the DU of the IAB node in response to the sixth information.

Steps 1309 "through 1310" may refer to steps 1105 "through 1106" in fig. 11.

In the embodiment of the present application, when selecting the target CU (third CU) of the MT, the second CU negotiates with the CU (scenario 3, fourth CU) to which the DU is to be migrated. It is determined by the third CU whether the selected third CU is viable. If the topology-spanning traffic migration is feasible, notifying the second CU to reselect the target CU of the MT if the topology-spanning traffic migration is not feasible; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

Fig. 14 is an interaction flow chart of another communication method according to an embodiment of the present application. The method in fig. 14 is applicable to scenario 3 (DU incomplete migration) described above. The meaning of each network element in fig. 14 can be referred to as meaning in fig. 9. The first CU is connected with the DU of the IAB node through F1, the second CU is connected with the MT of the IAB node through RRC, the third CU is a candidate target CU of the MT, and the fourth CU is a candidate target CU of the DU. As shown in fig. 14, the method includes:

1401. The first CU selects the fourth CU as a candidate target CU for the DU of the IAB node.

1402. The first CU sends a DU migration request message to the fourth CU.

1403. The fourth CU sends a DU migration request response message to the first CU.

1404. The first CU sends a message 5 to the second CU.

1405. The second CU selects the third CU as a candidate target CU for the MT.

1406. And performing a switching preparation flow of the MT between the second CU and the third CU.

Steps 1401 to 1406 are the same as steps 1301 to 1306 in fig. 13.

1407. The second CU sends the first information to the fourth CU.

Step 1407 may refer to step 1203.

1408. The fourth CU determines, based on the first information, whether the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

Step 1408 may refer to step 905.

1409. The fourth CU sends second information to the second CU.

1410. The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in a case where the second information indicates that the host DUs managed by the fourth CU and the third CU cannot communicate by IP routing.

1411. The second CU sends a message 6 to the first CU in case the second information indicates that the host DUs managed by the fourth CU and the third CU can communicate by means of IP routing.

Step 1411 may refer to step 1311.

1412. The first CU sends third information to the third CU.

Step 1412 may refer to step 1312. In one possible implementation, step 1411 is replaced with: the second CU sends a message 6 to the fourth CU in case the second information is used to instruct the host DUs managed by the fourth CU and the third CU to be able to communicate by means of IP routing; step 1412 is replaced with: the fourth CU sends third information to the third CU.

1409', The fourth CU transmits third information to the third CU in a case where it is determined that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

1410', The fourth CU sends sixth information to the second CU in case it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by means of IP routing.

1411', The second CU selects the fifth CU as a candidate target CU for the MT of the IAB node in response to the sixth information.

Steps 1409 'to 1411' are the same as steps 1205 'to 1207' in fig. 12.

In the embodiment of the present application, when selecting the target CU (third CU) of the MT, the second CU negotiates with the CU (scenario 3, fourth CU) to which the DU is to be migrated. It is determined by the fourth CU whether the selected third CU is viable. If the topology-spanning traffic migration is feasible, notifying the second CU to reselect the target CU of the MT if the topology-spanning traffic migration is not feasible; the occurrence of data transmission failure between the target CU of the DU of the IAB node and the target CU of the MT (i.e., the third CU) can be avoided or reduced.

In contrast to the prior art, any of the embodiments shown in fig. 11-14 enable the following two scenarios: mt migration results in DU migration, and the target CUs for both migration are different; when the MT does not migrate, the DU migrates, and the target CU for DU migration is different from the CU of the MT. The problem that the cross-topology F1 connection is not feasible due to the fact that the prior art is directly applied to the two scenes is solved, so that the cross-topology traffic transmission can be successfully established in the two scenes, and the flexibility of the IAB migration scene is improved.

The foregoing embodiments are communication schemes (IP reachable) provided by the embodiments of the present application, where the anchor CU that can ensure that a node on a path connected to F1 and connected to F1 are communicable. The following describes, with reference to the accompanying drawings, a mIAB-node obtaining communication scheme for setting up a new F1 interface or migrating a configuration (for example, an IP address of an MT, a BAP configuration, and a CU-CP IP address of a target CU) required for the F1 interface according to an embodiment of the present application.

Fig. 15 is an interaction flow chart of another communication method according to an embodiment of the present application. In fig. 15, CU1 represents a first CU, CU2 represents a second CU, CU3 represents a third CU, and CU4 represents a fourth CU. As shown in fig. 15, the method includes:

1501. The third CU receives a request for cross-topology traffic establishment (IAB transport migration request).

The request for cross-topology traffic establishment may be the third information in step 908 of fig. 9, the third information in step 906 'of fig. 9, the third information in step 1010 of fig. 10, the third information in step 1108 of fig. 11, the third information in step 1106' of fig. 11, the third information in step 1208 of fig. 12, the third information in step 1205 'of fig. 12, the third information in step 1312 of fig. 13, the third information in step 1310' of fig. 13, the third information in step 1412 'of fig. 14, and the third information in step 1409' of fig. 14. Step 1501 is optional.

1502. The third CU configures resources for F1 interface transmission within its topology.

For example, the resources for F1 interface transmission include the configuration of BH RLC CH, BAP rules (BAP configuration for short), and allocation mIAB-MT of IP addresses under the third CU topology on the donor-DU3 (i.e., DU managed by the third CU), and on intermediate nodes between the donor-DU3 and mIAB-node (if any). Step 1501 does not exist, and when step 1502 is directly performed, step 1010' in fig. 10 (excluding step 1008' and step 1009 ') corresponds to step 1107' in fig. 11 (excluding step 1105' and step 1106 ') and step 1311' in fig. 13 (excluding step 1309' and step 1310 ').

1503. The third CU sends a message 7 to the fourth CU.

Message 7 may carry DSCP/flow label (scenarios 1-4 all need to carry). If the fourth CU is already the mIAB-DU current F1 anchor CU (i.e., scenario 4, where DU does not migrate, always under the fourth CU), then optionally the IP address of the MT under the third CU and BAP configuration are also sent to the fourth CU. Of course, conventionally, if XN interactions are present, messages between the third and fourth CUs also carry mIAB-MT XNAP ID under the third and fourth CUs. Message 7 may multiplex the existing IAB Transport Migration Response messages because these cells may be carried in IAB Transport Migration Response messages. Message 7 may also use a new message, especially for the case that the third CU receives IAB Transport Migration Request from the first CU. In the existing scheme, the third CU will only reply IAB Transport Migration Response to the first CU, so enhancement of IAB Transport Migration Response messages is needed if it is desired to multiplex it. For example: introducing XNAP ID under the fourth CU in IAB Transport Migration Request messages about the gNB-ID or MT of the other CU (e.g., the fourth CU) may provide that when the third CU sees this field, then only IAB Transport Migration Response messages will be sent to the fourth CU, and not directly replies to the CU sending IAB Transport Migration Request. Or instead of IAB Transport Migration Response messages, a new message may be introduced to carry the cells.

1504. The third CU sends a message 8 to the MT.

Message 8 carries mIAB-MT at least one of the IP address under the third CU topology, BAP configuration, and CU-CP IP address of the fourth CU. Optionally, the message 8 further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU 2. Message 8 may be an RRC message. mIAB-node, having taken the configuration in message 8, may initiate an F1 interface setup request to the fourth CU. The method flows of steps 1501 to 1504 in fig. 15 are applicable to a scenario in which the MT has been switched to or is always connected under the third CU. It is noted that even for scenario 2 (MT not migrated, always under the third CU), resources need to be reconfigured for this new F1 interface, since a new F1 interface between mIAB-DU2 (newly generated logical DU) and the fourth CU via the third CU topology needs to be established at this time. Taking fig. 8 as an example, the F1 interface between mIAB-DU1 and the first CU and the F1 interface between mIAB-DU2 and the fourth CU all pass through the donor-DU3, but they use two resources, and the third CU needs to configure the resources for the newly generated F1 interface on the right.

In one possible implementation, the third CU receives seventeenth information from the MT, before sending message 8 to the MT, the seventeenth information being used to request uplink configuration information for the target F1 interface transmission from the third CU. The third CU may be sending message 8 to the MT: the third CU sends a message 8 to the MT according to the seventeenth information. The MT may receive sixteenth information for triggering the IAB node to initiate an F1 interface setup request to the fourth CU before sending seventeenth information to the third CU. That is, the MT transmits seventeenth information to the third CU after receiving sixteenth information; after the seventeenth information is received by the third CI, a message 8 is sent to the MT. It will be appreciated that the sixteenth information has the effect of triggering the IAB node to initiate an F1 interface setup request to the fourth CU, and also has the effect of triggering the transmission of seventeenth information to the third CU.

In one possible implementation, the third CU receives, before sending message 8 to the MT, eighteenth information from the first CU, where the eighteenth information is used to instruct the third CU to send uplink configuration information for the target F1 interface transmission to the MT of the IAB node. The third CU sends a message 8 to the MT may be: the third CU sends a message 8 to the MT based on the eighteenth information. For example, the first CU sends the eighteenth information to the third CU after selecting the fourth U as the target hosting CU for the DU of the IAB node; the third CU sends a message 8 (nineteenth information) to the MT based on the eighteenth information.

In one possible implementation, the third CU receives, before sending message 8 to the MT, twentieth information from the MT, the twentieth information being used to request that the third CU send, to the MT of the IAB node, uplink configuration information for the target F1 interface transmission. The third CU sends a message 8 to the MT may be: the third CU sends a message 8 to the MT based on the twentieth information. For example, when the IAB node determines that the target F1 interface needs to be established based on the pre-configuration information of the OAM, the twenty-first information is sent to the third CU by the MT; the third CU sends a message 8 to the MT based on the twentieth information.

1504', The third CU sends a message 9 to the second CU.

Message 9 carries mIAB-MT at least one of the IP address under the third CU, BAP configuration, and CU-CP IP address of the fourth CU. Message 9 is IAB Transport Migration Response message or a new XN message. Optionally, the message 9 further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU 2. Message 9 includes twenty-first information including at least one of an IP address of the IAB node, a BAP configuration, and a CU-CP IP address of the fourth CU when mIAB-MT is under the third CU.

1505', The second CU sends a message 10 to the MT.

Message 10 may be at least one of a CU-CP IP address carrying mIAB-MT under the third CU, a BAP configuration, and a fourth CU. Message 10 may be an RRC message. The method flows from step 1501 to step 1503 and from step 1504 'to step 1505' in fig. 15 are applicable to the scenario where the MT is to be switched to the third CU and is currently connected to the second CU. Optionally, the message 10 further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU 2. The message 10 includes twenty-second information including at least one of an IP address of the IAB node, a BAP configuration, and a CU-CP IP address of the fourth CU when the mIAB-MT is under the third CU.

1504", The third CU sends a message 11 to the first CU.

Message 11 carries mIAB-MT at least one of the IP address under the third CU, BAP configuration, and CU-CP IP address of the fourth CU. Message 11 is IAB Transport Migration Response message or a new XN message. Optionally, the message 11 further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU 2. Message 11 includes twenty-third information including at least one of an IP address of the IAB node, a BAP configuration, and a CU-CP IP address of the fourth CU when mIAB-MT is under the third CU.

1505", The first CU sends an F1AP message to mIAB-DU 1.

The F1AP message may carry mIAB-MT at least one of an IP address under the third CU, a BAP configuration, and a CU-CP IP address of the fourth CU. The CP-plane IP address of the fourth CU is optional here because the first CU may have obtained this information in some previous step (e.g., step 906 in fig. 9). The method flows from step 1501 to step 1503 and from step 1504 to step 1505 in fig. 15 are applicable to the scenario where the DU is to be switched to the fourth CU, and is currently connected to the first CU. Optionally, the F1AP message further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU 2. The F1AP message includes twenty-fourth information including at least one of an IP address of the IAB node, a BAP configuration, and a CU-CP IP address of the fourth CU when the mIAB-MT is under the third CU.

1504' ", The fourth CU sends a message 12 to mIAB-DU 2.

Message 12 is an F1AP message carrying mIAB-MT IP address and/or BAP configuration under the third CU. The method flows of steps 1501 to 1503, 1504 '"to 1505'" in fig. 15 are applicable to the scenario where the DU has been switched under the fourth CU, or always under the fourth CU. In this scenario, since DU migration is not considered, or has been completed, mIAB-node has only one DU, mIAB-DU2 at this time. The F1 interface between mIAB-DU2 and the fourth CU is replaced by a transmission path (MT is switched from the second CU to the third CU), configuration only needs to be updated, the F1 interface does not need to be newly built, and the IP address of the CU side does not need to be updated, so that the CP plane IP address of the fourth CU does not need to be carried in the step. Optionally, the message 12 further carries third indication information, where the third indication information is used to indicate that the IP address and/or BAP configuration is used for the F1 interface traffic of mIAB-DU2. Message 12 includes twenty-sixth information including the IP address and/or BAP configuration of the IAB node when mIAB-MT is under the third CU.

1505' ", MT switches from the second CU topology to the third CU topology.

1506. MIAB-DU2 initiates an F1 interface setup request message to the fourth CU.

Step 1506 may be replaced by: 1506', mIAB-DU2 initiate gNB-DU configuration update messages to the fourth CU.

It should be noted that the method flows from step 1501 to step 1504 and step 1506 in fig. 15 are applicable to the scenario in which the MT has been switched to or is always connected to the third CU. The method flows of steps 1501 to 1503, 1504 'to 1505', and 1506 in fig. 15 are applicable to the scenario in which the MT is to be switched to the third CU, and is currently connected to the second CU. The method flows of steps 1501 to 1503, 1504 "to 1505" and 1506 in fig. 15 are applicable to the scenario where the DU is to be switched to the fourth CU, and is currently connected to the first CU. The method flows of steps 1501 to 1503, 1504' "to 1505'" and 1506' in fig. 15 are applicable to a scenario where the DU has been switched to or is always under the fourth CU.

The IP address of the fourth CU in the embodiment of the present application may be replaced by the gNB-ID of the fourth CU, because there may be two cases: 1) The OAM may configure the mapping relation between the gNB-ID and the IP address to mIAB-node in advance, so that mIAB-node only needs to obtain the gNB-ID of the fourth CU, and can also query the mapping relation by itself to obtain the IP address of the fourth CU; 2) And mIAB-node takes the gNB-ID of the fourth CU, then sends a request message about the IP address of the fourth CU to the OAM, carries the gNB-ID of the fourth CU, and acquires the IP address of the fourth CU from the OAM.

Regarding the IP address of the MT under the third CU, BAP configuration (including BAP address and default BAP configuration): for the scenario of DU migration, there may be a case of configuration multiplexing. Taking fig. 8 as an example, the F1 connection between mIAB-DU1 and the first CU and the F1 connection between mIAB-DU2 and the fourth CU are all through mIAB-MT. A relatively easy way to distinguish is to assign different IP addresses and BAP configurations to the data traffic in the two F1 connections. That is, when a DU migration is required, a third CU allocates a set of IP addresses and BAP configuration to the MT. But the multiplexing configuration is also operative, including the following three cases: 1) The BAP configuration of the two F1 interfaces is multiplexed, the IP addresses are different, and as the IP layer is arranged on the upper layer of the BAP layer, the traffic of mIAB-DU1 and mIAB-DU2 can be distinguished through the IP addresses; 2) The BAP configuration of the two F1 interfaces is different, IP addresses are multiplexed, in this case, since the lower layer header is processed first when the protocol stack is processed in the receiving process, the traffic of the two F1 interfaces can be distinguished as long as the BAP addresses are different, and the IP address multiplexing is not influenced; 3) The BAP configuration and the IP address of the two F1 interfaces are multiplexed, and the F1AP application layer identifiers of mIAB-DU1 and mIAB-DU2 are set to be different only by distinguishing the F1AP application layer identifiers of the upper layers. Thus, in the present application, in the relevant step of carrying the IP address and BAP configuration of the MT under the third CU, it is possible not to carry the IP address and BAP configuration of the MT under the third CU at the same time, but to carry one of the BAP configuration of the MT under the third CU and the first indication information (for indicating that the BAP configuration of the MT under the third CU is mIAB-DU1 multiplexed with mIAB-DU 2), and/or to carry one of the IP address and the second indication information (for indicating that the IP address of the MT under the third CU is mIAB-DU1 multiplexed with mIAB-DU 2), where "and/or" means that if there is a case where the IP or BAP relevant configuration is not carried, it is multiplexed by default.

In the embodiment of the application, after the third CU receives the request for establishing the cross-topology traffic, or the third CU determines that the IP is reachable, after configuring the resources in its own topology, how to inform mIAB-node of the IP address under the third CU topology, BAP configuration, and CU-CP IP address of the fourth CU, which are used for mIAB-node to establish a new F1 interface (scenarios 1,2, 3) or migrate the F1 interface (scenario 4).

The embodiment of the present application may also be used in a case where the third CU and the fourth CU are the same CU, which means that the MT and the DU are migrated to the same target CU, or the MT is migrated to the CU under the DU, or the DU is migrated to the CU under the MT, where step 1503 is not required to be executed.

Fig. 16 shows a possible exemplary block diagram of a communication device involved in an embodiment of the application. As shown in fig. 16, the communication device 1600 may include: a processing unit 1601 and a transceiver unit 1602. The processing unit 1601 is configured to control and manage operations of the communication device 1600. The transceiver unit 1602 is configured to support communication between the communication apparatus 1600 and other devices. Alternatively, the transceiver unit 1602 may include a receiving unit and/or a transmitting unit for performing receiving and transmitting operations, respectively. Optionally, the communication device 1600 may further comprise a storage unit for storing program code and/or data of the communication device 1600. The transceiver unit may be referred to as an input/output unit, a communication unit, or the like, and the transceiver unit may be a transceiver; the processing unit may be a processor. When the communication device is a module (e.g., a chip) in the communication apparatus, the transceiver unit may be an input/output interface, an input/output circuit, an input/output pin, or the like, and may also be referred to as an interface, a communication interface, or an interface circuit; the processing unit may be a processor, a processing circuit, a logic circuit, or the like. Specifically, the device may be the first CU, the second CU, the third CU, the fourth CU, the IAB node, mIAB-DU, the mbib-MT, or the like.

The application also provides a network device. As shown in fig. 17, a schematic structural diagram of a network device 1700 according to an embodiment of the present application is provided, for example, the network device 1700 may be a first CU, a second CU, a third CU, a fourth CU, and an IAB-DU, so as to perform the functions of the network device in the foregoing method embodiment. It should be understood that the following is only an example, and that other forms and configurations of network devices are possible in future communication systems.

For example, in a 5G communication system, network device 1700 may include CUs, DUs, and AAUs, in contrast to network devices in an LTE communication system, comprised of one or more radio units, such as a remote radio unit (remote radio unit, RRU) and one or more indoor baseband processing units (building base band unit, BBU):

The non-real-time part of the original BBU is divided and redefined as CU, and is responsible for processing non-real-time protocol and service, partial physical layer processing function of BBU is combined with the original RRU and passive antenna to be AAU, and the rest functions of BBU are redefined as DU, and is responsible for processing physical layer protocol and real-time service. In short, CUs and DUs differentiate in real-time of the processing content, AAU is a combination of RRU and antenna.

CU, DU, AAU may be implemented separately or together, so that multiple network deployment configurations may occur, one possible deployment configuration is shown in fig. 17 as consistent with a conventional 4G network device, where a CU and DU are co-hardware deployed. It should be understood that fig. 17 is only an example, and the scope of the present application is not limited, and for example, the deployment mode may be that the DUs are deployed in a BBU room, a CU centralized deployment or a DU centralized deployment, a CU higher hierarchy set, or the like.

The AAU1800 may implement a transceiving function corresponding to the transceiving unit 1602 in fig. 16. Alternatively, the AAU1800 may also be referred to as a transceiver, transceiver circuitry, or transceiver, etc., which may include at least one antenna 1801 and a radio frequency unit 1802. Alternatively, the AAU1800 may include a receiving unit, which may correspond to a receiver (or receiver, receiving circuit), and a transmitting unit, which may correspond to a transmitter (or transmitter, transmitting circuit). The internal processing functions that the CU and DU1900 can implement correspond to the functions of the processing unit 1601 in fig. 16. Alternatively, the CU and DU1900 may control the network device, and so on, and may be referred to as a controller. The AAU, CU and DU may be physically located together or may be physically separated.

The network device is not limited to the configuration shown in fig. 17, and may be other configurations: for example: comprises a BBU and an adaptive radio unit (adaptive radio unit, ARU), or comprises a BBU and an AAU; the present application is not limited by the configuration of the customer premise equipment (customer premises equipment, CPE) or other configurations.

In one example, CU and DU1900 may be formed by one or more single boards, where the multiple single boards may support a single access radio access network (such as an LTE network) together, or may support different access radio access networks (such as an LTE network, a 5G network, a future network, or other networks) respectively. The CU and DU1900 also include a memory 1901 and a processor 1902. The memory 1901 stores necessary instructions and data. The processor 1902 is configured to control the network device to perform necessary actions, for example, to control the network device to perform the operation procedure related to the network device in the method embodiment. The memory 1901 and processor 1902 may serve one or more boards. That is, the memory and the processor may be separately provided on each board. It is also possible that multiple boards share the same memory and processor. In addition, each single board can be provided with necessary circuits.

It should be appreciated that the network device 1700 shown in fig. 17 is capable of implementing the network device functions involved in the method embodiments of fig. 9-15. The operations and/or functions of the various elements in network device 1700 are each for purposes of implementing a corresponding flow performed by the network device in an embodiment of the method of the present application. To avoid or reduce repetition, detailed descriptions are omitted here as appropriate. The architecture of the network device illustrated in fig. 17 is only one possible configuration and should not be construed as limiting the embodiments of the present application in any way. The application does not exclude the possibility of other forms of network device architecture that may occur in the future.

The CU and DU1900 described above may be used to perform actions described in the previous method embodiments as being implemented internally by the network device, and the AAU1800 may be used to perform actions described in the previous method embodiments as being transmitted to or received from the terminal device by the network device. Please refer to the description of the foregoing method embodiments, and details are not repeated herein.

The embodiment of the application also provides a communication system which comprises the first CU, the second CU, the third CU, the fourth CU and the IAB node.

The embodiment of the application also provides a communication system which comprises the second CU, the third CU, the fourth CU and the IAB node.

The application also provides a chip comprising: a communication interface and a processor; the communication interface is used for receiving and transmitting signals of the chip; the processor is configured to execute the computer program instructions to cause a communication device comprising the chip as described above to perform the method as in the above embodiments.

Based on the above embodiments, the present embodiments also provide a readable storage medium storing instructions that, when executed, cause the method of any of the above embodiments to be implemented. The readable storage medium may include: various media capable of storing program codes, such as a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, compact disc-read only memory (CD-ROM), optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Claims

1. A method of communication, comprising:

receiving first information from a first Centralized Unit (CU), wherein the first information comprises an Internet Protocol (IP) address of the third CU or an IP address of the fourth CU, F1 connection is arranged between the first CU and a Distributed Unit (DU) of an access backhaul Integrated (IAB) node, radio Resource Control (RRC) connection is arranged between the third CU and a Mobile Terminal (MT) of the IAB node, and the fourth CU is a candidate target CU of the DU of the IAB node;

And determining whether the host DUs managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU according to the first information.

2. The method according to claim 1, wherein the method further comprises:

and sending second information to the first CU, wherein the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing.

3. The method according to claim 2, wherein the method is applied to the fourth CU or a module in the fourth CU; the second information includes an IP address of the fourth CU and identification information identifying the MT in the fourth CU.

4. The method according to claim 1, wherein the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of:

In case it is determined that the fourth CU and the host DU managed by the third CU are capable of communicating by means of IP routing, sending third information to the third CU, the third information being used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU within its topology.

5. The method of claim 1, wherein the method is applied to the third CU or a module in the third CU; the method further comprises the steps of:

in the event that it is determined that the fourth CU and the third CU manage host DUs capable of communicating by way of IP routing, an F1 interface transmission between the IAB node's DUs and the fourth CU is established within its topology.

6. The method according to claim 5, wherein the first information includes an ID of the fourth CU and identification information identifying the MT in the fourth CU.

7. The method of claims 1, 4, 5,6, further comprising:

In a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sixth information is transmitted to the first CU, the sixth information indicating that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

8. A method of communication, comprising:

Generating first information, where the first information is used to indicate whether a fourth centralized unit CU and a host distributed unit DU managed by a third CU can perform communication through an internet protocol IP routing manner, or whether the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, an F1 connection is between the first CU and a DU accessing to a backhaul integrated IAB node, a radio resource control RRC connection is between the third CU and a mobile terminal MT of the IAB node, and the fourth CU is a candidate target CU of the DU of the IAB node;

And sending the first information.

9. The method of claim 8, wherein after transmitting the first information, the method further comprises:

Receiving second information;

And sending third information to the third CU, where the second information is used to indicate that the fourth CU and the host DU managed by the third CU can communicate by way of IP routing, where the third information is used to request the third CU to establish an F1 interface transmission between the DU of the IAB node and the fourth CU in its topology.

10. The method according to claim 9, wherein the third information includes identification information of the fourth CU and identification information identifying the MT in the fourth CU.

11. The method according to claim 9 or 10, characterized in that the method further comprises:

And selecting a fifth CU as a candidate target CU of the DU of the IAB node in the case that the second information is used for indicating that the host DUs managed by the fourth CU and the third CU cannot communicate through the IP routing.

12. The method according to claim 8 or 9, wherein the second information comprises an IP address of the fourth CU and identification information identifying the MT in the fourth CU.

13. The method according to any one of claims 8 to 12, wherein prior to transmitting the first information, the method further comprises:

receiving fourth information from the fourth CU, the fourth information including an IP address of the fourth CU;

the transmitting the first information includes:

and sending the first information to the third CU, wherein the first information comprises the IP address of the fourth CU.

14. A method of communication, comprising:

Receiving first information from a second centralized unit CU, where the first information is used to indicate whether a fourth CU and a host distributed unit DU managed by a third CU can communicate by means of an IP routing of an internet protocol, or whether an Xn interface can be established between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, a radio resource control RRC connection is provided between the second CU and a mobile terminal MT accessing a backhaul integrated IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided or an F1 connection is to be established between the fourth CU and a DU of the IAB node;

15. The method of claim 14, wherein the method further comprises:

and sending second information to the second CU, wherein the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can or cannot communicate through IP routing.

16. The method according to claim 14 or 15, wherein the method is applied to the third CU or a module in the third CU; the method further comprises the steps of:

17. The method according to claim 14 or 15, wherein the method is applied to the fourth CU or a module in the fourth CU; the method further comprises the steps of:

18. The method according to claim 16 or 17, characterized in that the method further comprises:

In a case where it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sixth information is transmitted to the second CU, the sixth information indicating that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing.

19. The method according to claim 14, 16, 17, characterized in that the method is applied to the third CU or a module in the third CU, the first information being carried in a handover request for requesting a handover of the MT to the third CU; the method further comprises the steps of:

And in the case that it is determined that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, sending a handover preparation failure message to the second CU, wherein the handover preparation failure message indicates rejection of the handover request.

20. The method of claim 19, wherein the handover preparation failure message includes a first field indicating that the reason for the third CU to reject the handover request is that a topology under the third CU is unable to service F1 interface traffic of the fourth CU.

21. The method according to claim 19 or 20, characterized in that the method further comprises:

And sending a switching request response message to the second CU, wherein the switching request response message indicates that the switching request is accepted, under the condition that the fourth CU and the host DU managed by the third CU can communicate through an IP route.

22. The method according to claim 14 or 19 or 20 or 21, wherein the method is applied to the third CU or a module in the third CU, the first information being carried in a handover request for requesting handover of the MT to the third CU, the handover request carrying a migration type in which an MT migrates DU does not migrate or a migration type in which an MT migrates and a DU may migrate;

The determining whether the host DUs managed by the fourth CU and the third CU can communicate by IP routing or whether an Xn interface can be established between the third CU and the fourth CU according to the first information includes:

When the switching request carries a migration type that the MT migration DU does not migrate, determining whether the host DU managed by the fourth CU and the third CU can communicate in an IP routing mode or whether an Xn interface can be established between the third CU and the fourth CU according to the first information.

23. A method of communication, comprising:

Generating first information, where the first information is used to indicate whether a fourth centralized unit CU and a host distributed unit DU managed by a third CU can perform communication through an internet protocol IP routing manner, or the first information is used to indicate whether an Xn interface can be established between the third CU and the fourth CU, the first information includes an IP address of the third CU or an IP address of the fourth CU, a radio resource control RRC connection is provided between the second CU and a mobile terminal MT accessing the backhaul integrated IAB node, the third CU is a candidate target CU of the MT, and an F1 connection is provided or an F1 connection is to be established between the fourth CU and the DU of the IAB node;

And sending the first information.

24. The method according to claim 23, wherein the first information further comprises an ID of the fourth CU and identification information identifying the MT in the fourth CU.

25. The method according to claim 23 or 24, wherein after transmitting the first information, the method further comprises:

Receiving second information;

And in the case that the second information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing, sending eighth information to the fourth CU, where the eighth information is used for indicating that the host DUs managed by the fourth CU and the third CU can communicate by way of IP routing.

26. The method of claim 25, wherein the method further comprises:

in the case where the second information is used to indicate that the host DUs managed by the fourth CU and the third CU cannot communicate by way of IP routing, the sixth CU is selected as a candidate target CU for the MT.

27. The method according to any of claims 23 to 26, wherein the first information is carried in a handover request for requesting handover of the MT to the third CU.

28. The method of claim 27, wherein the handoff request carries a migration type in which the MT migrates a DU without migration or a migration type in which the MT migrates and the DU may migrate.

29. The method according to claim 27 or 28, characterized in that the method further comprises:

And receiving a handover preparation failure message from the third CU, wherein the handover preparation failure message indicates that the third CU refuses the handover request, and the handover preparation failure message comprises a first field, and the first field indicates that the reason that the third CU refuses the handover request is that a topology under the third CU cannot provide service for the F1 interface traffic of the fourth CU.

30. A communication device comprising means or units for implementing the method of any one of claims 1 to 7.

31. A communication device comprising means or units for implementing the method of any one of claims 8 to 13.

32. A communication device comprising means or units for implementing the method of any one of claims 14 to 22.

33. A communication device comprising means or units for implementing the method of any one of claims 23 to 29.

34. A communication system comprising the communication device of claim 30 and the communication device of claim 31, or the communication system comprising the communication device of claim 32 and the communication device of claim 33.

35. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program comprising program instructions which, when executed, cause a computer to perform the method of any of claims 1 to 29.

36. A communications device comprising a processor coupled to a memory, the memory storing computer program instructions, the processor configured to execute the computer program instructions to cause the communications device to perform the method of any one of claims 1 to 29.

37. A computer program product, characterized in that the computer program product comprises a computer program comprising program instructions which, when executed, cause a computer to perform the method of any of claims 1 to 29.