Communication method and communication apparatus

Abstract

This application provides a communication method and a communication apparatus. The method includes: receiving a first message from a second node, the first message indicating the reconfiguration of resources in a first topology used to serve first traffic, the first topology being a topology controlled by a first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node; and reconfiguring resources in the first topology used to serve the first traffic according to the first message. Specifically, the third node has RRC connections with both the first and second nodes, and an F1 connection exists between the third node and the second node. The first node is a CU in a first IAB host node, and the second node is a CU in a second IAB host node. In this application, by exchanging the first message between the first and second nodes, the first message can be used to instruct the first node to reconfigure resources in its topology used to serve the first traffic, thereby enabling cross-CU traffic control.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and communication device. Background Technology

[0002] The fifth-generation (5G) mobile communication system introduces integrated access and backhaul (IAB) network technology. Both the access link and backhaul link in an IAB network utilize wireless transmission schemes, reducing fiber optic deployment and thus lowering deployment costs and increasing deployment flexibility. An IAB network includes IAB nodes and IAB donors. Typically, an IAB node consists of a mobile termination (MT) component and a distributed unit (DU) component, while an IAB donor consists of a centralized unit (CU) component and distributed units (DUs).

[0003] The interface between the CU and DU is called the F1 interface. In a dual connectivity (DC) scenario, an IAB node allows dual connectivity to different IAB donors. The IAB node in a dual connectivity scenario is called a boundary node. The IAB donor to which the CU with a partial F1 interface to the boundary node DU belongs is called the primary node, and the IAB donor to which the CU without a partial F1 interface to the boundary node DU belongs is called the secondary node. Information is exchanged between the primary node CU and the secondary node CU via the Xn interface. For an example, please refer to [link to example]. Figure 1 , Figure 1 This is a schematic diagram of a network structure with IABnodes having dual connections across CUs. (See diagram below.) Figure 1 As shown, CU1 and donorDU1 are the CU and DU portions of the primary node (IAB donor1), respectively, and CU2 and donorDU2 are the CU and DU portions of the secondary node (IAB donor2), respectively. IABMT and IABDU are the MT and DU portions of the IAB node, respectively. For example, IABMT1 and IABDU1 are the MT and DU portions of IAB node1, respectively. The set of primary nodes and IAB nodes that have F1 interfaces with the CUs in the primary node is called the primary topology, and the set of secondary nodes and IAB nodes that have F1 interfaces with the CUs in the secondary nodes is called the secondary topology. Figure 1As shown, CU1, donorDU1, IAB node1, IAB node2, and IAB node4 constitute the main topology, while CU2, donorDU2, and IAB node3 constitute the secondary topology. It should be noted that, in... Figure 1 In the system architecture shown, flow control in the primary topology is controlled by CU1, and flow control in the secondary topology is controlled by CU2. When an IAB node detects congestion or poor serving cell signal quality in a topology (e.g., primary or secondary), it only reports a status indication message to its associated node (CU1 or CU2). This status indication message triggers flow control in the receiving node. For example, when IAB node2 or IAB node4 detects congestion or poor serving cell signal quality, they only send a status indication message to CU1. Similarly, when IAB node3 detects congestion or poor serving cell signal quality, it only sends a status indication message to CU2. Therefore, flow control across CU dual-connectivity network architectures cannot be implemented. Summary of the Invention

[0004] This application provides a communication method and communication device that enables cross-CU resource reconfiguration in scenarios where IAB node is dual-connected to different IABdonor CUs, thereby achieving cross-CU flow control.

[0005] In a first aspect, this application provides a communication method applicable to a first node, the method comprising:

[0006] Receive a first message from a second node, the first message being used to instruct the reconfiguration of resources in a first topology for serving the first traffic, the first topology being a topology controlled by the first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node.

[0007] Based on the first message, reconfigure the resources in the first topology used to serve the first traffic;

[0008] The third node (i.e., the MT of the third node) has RRC connections with both the first node and the second node, and the third node (i.e., the DU of the third node) has an F1 connection with the second node. The first node is a centralized unit CU in the first integrated access backhaul IAB host node, and the second node is a centralized unit CU in the second IAB host node.

[0009] In this application, the first node can be a CU of the primary IAB host node, and the second node can be a CU of the secondary IAB host node; alternatively, the first node can be a CU of the secondary IAB host node, and the second node can be a CU of the primary IAB host node. Specifically, by exchanging a first message with the second node, this first message can be used to instruct the first node to reconfigure the resources in its topology used to serve the first traffic, thereby enabling cross-CU traffic control.

[0010] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0011] In this application, different granularities of resource reconfiguration can be achieved by instructing resource reconfiguration through a first message, such as reconfiguring all resources, reconfiguring resources at the QoS index level, or reconfiguring resources at the F1-U Tunnel level.

[0012] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0013] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0014] In one possible implementation, the method further includes:

[0015] Send a first feedback to the second node of the first message. The first feedback is used to trigger the second node to reconfigure the resources in the second topology used to serve the first traffic. The second topology is a topology controlled by the second node.

[0016] In this application, the second node receives first feedback from the first node. On the one hand, the second node can reconfigure the resources in the second topology used to serve the first traffic based on the first feedback, thereby achieving cross-CU traffic control. On the other hand, it can be used to determine that the first node has successfully received the first message.

[0017] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0018] In one possible implementation, the first topology includes the DU of the first node.

[0019] In one possible implementation, reconfiguring the resources in the first topology used to serve the first traffic according to the first message includes:

[0020] Delete the resources in the first topology used to serve the first traffic based on the first message.

[0021] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0022] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0023] In one possible implementation, the first message is an Xn message.

[0024] Secondly, this application provides a communication method applicable to a second node, the method comprising:

[0025] A first message is determined, which is used to instruct the reconfiguration of resources in a first topology for serving the first traffic, wherein the first topology is a topology controlled by a first node, and the first traffic is the traffic of a third node or the traffic of a downstream node of the third node.

[0026] Send the first message to the first node;

[0027] The third node has RRC connections with both the first and second nodes, and an F1 connection with the second node. The first node is a centralized unit (CU) in the first integrated access backhaul IAB host node, and the second node is a centralized unit (CU) in the second IAB host node.

[0028] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0029] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0030] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0031] In one possible implementation, the method further includes:

[0032] Receive first feedback from the first message from the first node;

[0033] In response to the first feedback, the resources in the second topology used to serve the first traffic are reconfigured, wherein the second topology is the topology controlled by the second node.

[0034] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0035] In one possible implementation, the first topology includes the DU of the first node.

[0036] In one possible implementation, the reconfiguration of resources in the second topology used to serve the first traffic includes:

[0037] Delete the resources in the second topology used to serve the first traffic.

[0038] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0039] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0040] In one possible implementation, the first message is an Xn message.

[0041] In one possible implementation, the method further includes:

[0042] A status indication message is received, which is used to determine the first message.

[0043] Thirdly, this application provides a communication method applicable to a first node, the method comprising:

[0044] Receive at least one target Internet Protocol (IP) address corresponding to the data packet of the first service from the second node;

[0045] Determine the first parameter corresponding to each of the target IP addresses;

[0046] Send the first parameter corresponding to each of the target IP addresses to the second node;

[0047] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0048] This application presents a cross-CU routing method for scenarios where an IAB node has dual connections to different IAB donor CUs. Specifically, the second node obtains the mapping relationship between DSCP, IPv6 flow label, and target IP address from the first node, so that the second node can write it into the packet header, ensuring the correct transmission of packets across the topology and improving communication reliability.

[0049] In one possible implementation, a target IP address corresponds to a first parameter;

[0050] Sending the first parameter corresponding to each target IP address to the second node includes:

[0051] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0052] Send the first parameter to the second node, along with a 1:1 mapping relationship between each target IP address.

[0053] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0054] Sending the first parameter corresponding to each target IP address to the second node includes:

[0055] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0056] Send the first parameter and the 1:N mapping relationship between multiple target IP addresses to the second node.

[0057] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0058] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0059] Fourthly, this application provides a communication method applicable to a second node, the method comprising:

[0060] Send at least one target Internet Protocol (IP) address corresponding to the data packet of the first service to the first node;

[0061] Receive a first parameter corresponding to each of the target IP addresses from the first node;

[0062] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0063] In one possible implementation, a target IP address corresponds to a first parameter;

[0064] The step of receiving the first parameter corresponding to each of the target IP addresses from the first node includes:

[0065] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0066] Receive the 1:1 mapping relationship between the first parameter from the first node and each target IP address.

[0067] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0068] The step of receiving the first parameter corresponding to each of the target IP addresses from the first node includes:

[0069] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0070] Receive the first parameter from the first node and the 1:N mapping relationship between multiple target IP addresses.

[0071] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0072] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0073] Fifthly, this application provides a communication method applicable to a second node, the method comprising:

[0074] Send the first Internet Protocol IP address corresponding to the data packet of the first service to the first node;

[0075] Receive the first mapping relationship between the first IP address from the first node and the first backhaul adaptation protocol routing identifier (BAProuting ID);

[0076] Send a second mapping relationship between the first BAP routing ID and the second BAP routing ID to the third node. The second mapping relationship is used for the rerouting of data packets of the first service.

[0077] Wherein, the first node is the centralized unit CU in the target IAB host node of the third node, and the second node is the centralized unit CU in the source IAB host node of the third node.

[0078] This application presents a cross-CU rerouting method for handover scenarios. Specifically, the second node interacts with the first node, using the IP address as an intermediate variable to generate a mapping relationship between the old and new BAP routing IDs, and informs the third node (i.e., the boundary node). This enables packet rerouting, improves transmission success rate, and reduces service interruptions.

[0079] In one possible implementation, the first IP address includes the source IP address.

[0080] In one possible implementation, the method further includes:

[0081] Obtain the third mapping relationship between the first IP address and the second BAP routing ID;

[0082] The second mapping relationship is determined based on the first mapping relationship and the third mapping relationship.

[0083] Sixthly, this application provides a communication method applicable to a first node, the method comprising:

[0084] Receive the first Internet Protocol IP address corresponding to the data packet from the first service of the second node;

[0085] Send the first mapping relationship between the first IP address and the first backhaul adaptation protocol routing identifier (BAP routingID) to the second node.

[0086] In one possible implementation, the first IP address includes the source IP address.

[0087] In a seventh aspect, this application provides a communication device, which can be a first node, the device comprising:

[0088] The transceiver unit is configured to receive a first message from a second node, the first message being configured to instruct the reconfiguration of resources in a first topology for serving the first traffic, the first topology being a topology controlled by the first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node.

[0089] A processing unit is configured to reconfigure the resources in the first topology used to serve the first traffic based on the first message;

[0090] The third node has RRC connections with both the first and second nodes, and an F1 connection with the second node. The first node is a centralized unit (CU) in the first integrated access backhaul IAB host node, and the second node is a centralized unit (CU) in the second IAB host node.

[0091] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0092] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0093] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0094] In one possible implementation, the transceiver unit is further configured to:

[0095] Send a first feedback to the second node of the first message. The first feedback is used to trigger the second node to reconfigure the resources in the second topology used to serve the first traffic. The second topology is a topology controlled by the second node.

[0096] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0097] In one possible implementation, the first topology includes the DU of the first node.

[0098] In one possible implementation, the processing unit is specifically used for:

[0099] Delete the resources in the first topology used to serve the first traffic based on the first message.

[0100] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0101] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0102] In one possible implementation, the first message is an Xn message.

[0103] Eighthly, this application provides a communication device, which can be a second node, the device comprising:

[0104] A processing unit is configured to determine a first message, the first message being configured to instruct the reconfiguration of resources in a first topology for serving the first traffic, the first topology being a topology controlled by a first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node.

[0105] The transceiver unit is used to send the first message to the first node;

[0106] The third node has RRC connections with both the first and second nodes, and an F1 connection with the second node. The first node is a centralized unit (CU) in the first integrated access backhaul IAB host node, and the second node is a centralized unit (CU) in the second IAB host node.

[0107] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0108] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0109] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0110] In one possible implementation, the transceiver unit is further configured to receive first feedback from the first message of the first node;

[0111] The processing unit is further configured to, in response to the first feedback, reconfigure the resources in the second topology used to serve the first traffic, wherein the second topology is the topology controlled by the second node.

[0112] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0113] In one possible implementation, the first topology includes the DU of the first node.

[0114] In one possible implementation, the processing unit is specifically used for:

[0115] Delete the resources in the second topology used to serve the first traffic.

[0116] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0117] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0118] In one possible implementation, the first message is an Xn message.

[0119] In one possible implementation, the transceiver unit is further configured to:

[0120] A status indication message is received, which is used to determine the first message.

[0121] Ninthly, this application provides a communication device, which is a first node, the device comprising:

[0122] The transceiver unit is used to receive at least one target Internet Protocol (IP) address corresponding to the data packet of the first service from the second node;

[0123] The processing unit is used to determine the first parameter corresponding to each of the target IP addresses;

[0124] The transceiver unit is used to send the first parameter corresponding to each of the target IP addresses to the second node;

[0125] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0126] In one possible implementation, a target IP address corresponds to a first parameter;

[0127] The transceiver unit is specifically used for:

[0128] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0129] Send the first parameter to the second node, along with a 1:1 mapping relationship between each target IP address.

[0130] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0131] The transceiver unit is specifically used for:

[0132] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0133] Send the first parameter and the 1:N mapping relationship between multiple target IP addresses to the second node.

[0134] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0135] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0136] In a tenth aspect, this application provides a communication device, which is a second node, comprising:

[0137] The transceiver unit is used to send at least one target Internet Protocol (IP) address corresponding to the data packet of the first service to the first node;

[0138] The transceiver unit is configured to receive a first parameter corresponding to each target IP address from the first node;

[0139] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0140] In one possible implementation, a target IP address corresponds to a first parameter;

[0141] The transceiver unit is specifically used for:

[0142] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0143] Receive the 1:1 mapping relationship between the first parameter from the first node and each target IP address.

[0144] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0145] The transceiver unit is specifically used for:

[0146] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0147] Receive the first parameter from the first node and the 1:N mapping relationship between multiple target IP addresses.

[0148] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0149] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0150] In one aspect, this application provides a communication device suitable for a second node, the device comprising:

[0151] The transceiver unit is used to send the first Internet Protocol IP address corresponding to the data packet of the first service to the first node;

[0152] The transceiver unit is used to receive a first mapping relationship between the first IP address and the first backhaul adaptation protocol routing ID from the first node;

[0153] The transceiver unit is used to send a second mapping relationship between the first BAP routing ID and the second BAProuting ID to the third node. The second mapping relationship is used for the rerouting of data packets of the first service.

[0154] Wherein, the first node is the centralized unit CU in the target IAB host node of the third node, and the second node is the centralized unit CU in the source IAB host node of the third node.

[0155] In one possible implementation, the first IP address includes the source IP address.

[0156] In one possible implementation, the apparatus further includes a processing unit, the processing unit being configured to:

[0157] Obtain the third mapping relationship between the first IP address and the second BAP routing ID;

[0158] The second mapping relationship is determined based on the first mapping relationship and the third mapping relationship.

[0159] In a twelfth aspect, this application provides a communication device, which is a first node, the device comprising:

[0160] The transceiver unit is used to receive the first Internet Protocol IP address corresponding to the data packet from the first service of the second node;

[0161] The transceiver unit is used to send the first mapping relationship between the first IP address and the first backhaul adaptation protocol routing ID (BAP routing ID) to the second node.

[0162] In one possible implementation, the first IP address includes the source IP address.

[0163] In a thirteenth aspect, this application provides a communication device, which may be a first node, a device within the first node, or a device compatible with the first node. The communication device may also be a chip system. The communication device can execute the methods described in the first aspect and / or the third aspect and / or the sixth aspect. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions. The unit or module may be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the methods described in the first aspect and / or the third aspect and / or the sixth aspect, and their beneficial effects are not repeated here.

[0164] In a fourteenth aspect, this application provides a communication device, which may be a second node, a device within a second node, or a device capable of being used in conjunction with a second node. The communication device may also be a chip system. The communication device can execute the methods described in the second and / or fourth and / or fifth aspects. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions. These units or modules can be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the methods described in the second and / or fourth and / or fifth aspects above, and their beneficial effects are not repeated here.

[0165] In a fifteenth aspect, this application provides a communication device, which may be a first node, the communication device including a processor and a transceiver, the processor and the transceiver being configured to execute a computer program or instructions stored in at least one memory to cause the device to implement the method of any one of the first aspect and / or the third aspect and / or the sixth aspect.

[0166] In a sixteenth aspect, this application provides a communication device, which may be a first node, comprising a processor, a transceiver, and a memory. The processor, transceiver, and memory are coupled; the processor and transceiver are used to implement the methods of any one of the first and / or third and / or sixth aspects.

[0167] In a seventeenth aspect, this application provides a communication device, which may be a second node, the communication device including a processor and a transceiver, the processor and the transceiver being configured to execute a computer program or instructions stored in at least one memory to cause the device to implement the method as described in any one of the second and / or fourth and / or fifth aspects.

[0168] In an eighteenth aspect, this application provides a communication device, which may be a second node, comprising a processor, a transceiver, and a memory. The processor, transceiver, and memory are coupled; the processor and transceiver are used to implement the methods of any one of the second and / or fourth and / or fifth aspects.

[0169] In a nineteenth aspect, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a computer, implement the method of any one of the first to fourth aspects.

[0170] In a twentieth aspect, this application provides a computer program product including instructions, wherein the computer program product includes computer program code, which, when run on a computer, implements the method of any one of the first to fourth aspects. Attached Figure Description

[0171] Figure 1 This is a schematic diagram of the network architecture of IAB node with dual connections across CU;

[0172] Figure 2 This is a schematic diagram of the network architecture of an IAB network.

[0173] Figure 3 This is a schematic diagram of a protocol stack provided in an embodiment of this application;

[0174] Figure 4 This is a schematic diagram of a mapping relationship provided in an embodiment of this application;

[0175] Figure 5 This is another schematic diagram of the mapping relationship provided in the embodiments of this application;

[0176] Figure 6 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0177] Figure 7 This is another schematic flowchart of the communication method provided in the embodiments of this application;

[0178] Figure 8 This is a switching diagram provided in an embodiment of this application;

[0179] Figure 9 This is another schematic flowchart of the communication method provided in the embodiments of this application;

[0180] Figure 10 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0181] Figure 11 This is a schematic diagram of another communication device provided in an embodiment of this application;

[0182] Figure 12 This is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0183] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0184] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0185] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0186] Fifth-generation (5G) mobile communication imposes more stringent requirements on various network performance indicators. These include a 1000-fold increase in capacity, wider coverage, and ultra-high reliability and ultra-low latency. On the one hand, given the abundance of high-frequency carrier resources, the use of high-frequency small cell networks is becoming increasingly popular in hotspot areas to meet the ultra-high capacity demands of 5G. However, high-frequency carriers have poor propagation characteristics, suffer severe attenuation due to obstruction, and have limited coverage, thus requiring a large-scale, dense deployment of small cells. Consequently, providing fiber optic backhaul for these densely deployed small cells is costly and difficult to implement, necessitating an economical and convenient backhaul solution. On the other hand, from the perspective of wide coverage requirements, providing network coverage in remote areas presents significant challenges and costs associated with fiber optic deployment, necessitating the design of flexible and convenient access and backhaul solutions. Integrated access and backhaul (IAB) technology offers a solution to these two problems: both its access link and backhaul link utilize wireless transmission schemes, reducing fiber optic deployment.

[0187] To address the reliability requirements of service transmission, IAB nodes can support dual connectivity (DC) or multi-connectivity to handle potential anomalies in the backhaul link, such as link failures, blockages, or load fluctuations, thereby improving transmission reliability. Considering the limited coverage of high-frequency bands, multi-hop networking can be employed in the IAB network to ensure network coverage performance.

[0188] Because IAB networks support multi-hop and multi-connection networking, multiple transmission paths may exist between terminal devices (e.g., user equipment (UE)) and IAB donor nodes. Each transmission path contains multiple nodes, which may include the UE, one or more IAB nodes, and the IAB donor. If the IAB donor is in a form where centralized units (CU) and distributed units (DU) are separate, then the IAB donor may include an IAB donor-DU portion and an IAB donor-CU portion, etc. In an IAB network, IAB nodes can provide radio access services to terminal devices, and the service data of the terminal devices is transmitted from the IAB nodes to the IAB donor via a radio backhaul link. IAB nodes can have different names in different communication systems. For example, an IAB node can be called a relay node (RN), a wireless backhaul node, or a wireless backhaul device. In 5G systems, a relay node can be called an integrated access and backhaul node (IAB node). Of course, relay nodes may have different names in future communication systems, and this is not limited here. All IAB nodes mentioned in the embodiments of this application can be replaced with relay nodes.

[0189] In this architecture, each IAB node considers the adjacent nodes providing backhaul services as its parent nodes (or superior nodes), and correspondingly, each IAB node can be considered a child node (or subordinate node) of its parent node. The wireless link used by an IAB node to communicate with its child nodes is called an access link, which includes both uplink and downlink transmission links. Uplink transmission on the access link is also called access link uplink transmission, and downlink transmission is also called access link downlink transmission. Similarly, the wireless link used by an IAB node to communicate with its parent node can be called a backhaul link, which also includes both uplink and downlink transmission links. Uplink transmission on the backhaul link is also called backhaul link uplink transmission, and downlink transmission is also called backhaul link downlink transmission.

[0190] For example, please see Figure 2 , Figure 2 This is a schematic diagram of an IAB network architecture. (Example) Figure 2In the wireless relay scenario shown, the parent node of node 1 is the host node (i.e., the IAB donor). Node 1 is also the parent node of nodes 2 and 3. Nodes 2 and 3 are both the parent nodes of node 4, and node 5's parent node is node 2. There are two available data transmission paths between UE1 and the IAB donor: Path 1: UE1-Node 4-Node 3-Node 1-IAB donor, Path 2: UE1-Node 4-Node 2-Node 1-IAB donor. There are three available data transmission paths between UE2 and the IAB donor: Path 3: UE2-Node 4-Node 3-Node 1-IAB donor, Path 4: UE2-Node 4-Node 2-Node 1-IAB donor, Path 5: UE2-Node 5-Node 2-Node 1-IAB donor. Each UE's uplink data packets can be transmitted to the IAB donor by one or more IAB nodes, and then sent to the mobile gateway device (such as the user plane function (UPF) network element in the 5G core network) by the IAB donor. Downlink data packets can be received from the mobile gateway device by the IAB donor and then sent to the UE through the IAB nodes.

[0191] An IAB node can include a mobile termination (MT) component and a distributed unit (DU) component. When an IAB node faces its parent node (which can be another IAB node or an IAB donor), it can be regarded as a user equipment, i.e., the role of an MT. When an IAB node faces its child node (which can be another IAB node or a termination device), it can be regarded as a network device, i.e., the role of a DU, which provides backhaul services to the child node.

[0192] In this application, the IAB donor can be an access network element with full access functionality, or it can be an access network element with separate CU and DU configurations. The IAB donor can connect to the core network (e.g., 5G core network (5Gcore, 5GC)) serving the terminal equipment and provide wireless backhaul services to the IAB node. For ease of description, the centralized unit of the IAB donor is simply referred to as the donor CU (or directly as CU), and the distributed unit of the IAB donor is simply referred to as the donor DU. The donor CU may also have a configuration where the control plane (CP) and user plane (UP) are separate; for example, the CU may consist of one CU-CP and one (or more) CU-UP. In the embodiments of this application, the IAB donor may also be referred to as the IAB host, IAB host node, host node (donor node), or host base station (donor gNodeB, DgNB), and this application does not impose any limitations on this.

[0193] Figure 2 The IAB networking scenario shown is merely an example. In IAB networking scenarios that combine multi-hop and multi-connection, there are many other possibilities, such as a DgNB and an IAB node under another DgNB forming a dual connection to serve the UE. These are not listed here.

[0194] In this application, the host base station may include, but is not limited to: a next-generation node B (gNB), an evolved node B (eNB), a radio network controller (RNC), a node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home evolved node B (or home node B), a transmission and reception point (or transmission point), a roadside unit (RSU) with base station functionality, a baseband unit (BBU), a remote radio unit (RRU), an active antenna unit (AAU), one or a group of antenna panels, or a node with base station functionality in a subsequent evolution system. The host base station may be a single entity, or it may include a centralized unit (CU) entity plus at least one distributed unit (DU) entity. The interface between the CU and the DU may be referred to as the F1 interface. The two ends of the F1 interface are CU and DU, respectively. The opposite end of the F1 interface of the CU is DU, and the opposite end of the F1 interface of the DU is CU. The F1 interface can further include the control plane F1 interface (F1-C) and the user plane F1 interface (F1-U). In this application, the CU of the host base station can be abbreviated as Donor CU, and the DU of the host base station can be abbreviated as Donor DU.

[0195] In this application, the terminal is sometimes also referred to as user equipment (UE), mobile station, terminal device, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, etc. Terminals may include, but are not limited to: user equipment (UE), mobile station, mobile device, terminal equipment, user agent, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication capabilities, computing device, other processing device connected to a wireless modem, in-vehicle equipment, wearable device (such as smartwatch, smart bracelet, smart glasses, etc.), smart furniture or home appliances, vehicle equipment in vehicle-to-everything (V2X) networks, terminal equipment with relay capabilities, customer premises equipment (CPE), IAB nodes (specifically, the MT of an IAB node or an IAB node acting as a terminal), etc. This application does not limit the specific name and implementation form of the terminal.

[0196] like Figure 3As shown, in the current discussion of IAB networks, it is determined that a backhaul adaptation protocol (BAP) layer will be introduced into the radio backhaul link. This protocol layer can be located above the radio link control (RLC) layer and can be used to implement functions such as packet routing and bearer mapping on the radio backhaul link. The IAB donor-CU assigns a unique BAP address to each IAB node it controls, thus uniquely identifying each IAB node in the network. In the case of multiple paths, each BAP address can be associated with multiple path IDs. The source nodes (IAB donor-DU in the downlink DL direction and access IABnode in the uplink UL direction) will add a BAP header to the packets they are transmitting in their BAP layer. The BAP header includes the BAP address and BAP path ID. Each IAB node will have a routing table configured with uplink UL and downlink DL (configured by the IAB donor-CU), which contains the next-hop identifier for each BAP path ID. Separate routing tables are maintained for the DL and UL directions, with IAB node-DU using the DL table and IAB node-MT using the UL table. The routing table indicates which child node (if it's a DL) or parent node (if it's a UL) a data packet should be forwarded to. When an access IABnode receives a data packet, it is forwarded to a higher layer and processed as an incoming F1-U or F1-C data packet, similar to how a normal DU processes such packets. In addition to routing, the BAP protocol performs mapping between ingress and egress BH RLC channels, with mapping rules configured by the IAB donor-CU. For intermediate IABnodes, the mapping is configured as {ingress link ID, ingress BH RLC CH ID, outgress link ID, outgress BH RLC CH ID}. For uplink mapping when an access IABnode sends an F1-U data packet, the mapping is configured as {destination IP Address, TEID, outgress link ID, outgress BH RLC CH ID}. For downlink mapping of the donor-DU, the mapping is configured as {destination IP Address, DSCP (optional), IPv6 flow label (optional), outgress link ID, outgress BH RLC CH ID}.

[0197] In this application, an F1 interface (or F1* interface; in this embodiment, it can be uniformly referred to as the F1 interface, but the name is not limited) needs to be established between the IAB node (the DU portion of the IAB) and the IAB donor (or donor CU). This F1 interface supports user plane protocols (F1-U / F1*-U) and control plane protocols (F1-C / F1*-C). The user plane protocols include one or more of the following protocol layers: General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U), User Datagram Protocol (UDP), and Internet Protocol (IP). The control plane protocols include one or more of the following: F1 Application Protocol (F1AP), Stream Control Transport Protocol (SCTP), and IP. Through the control plane of the F1 interface, the IAB node and the IAB donor can perform interface management, manage the donor DU, and perform UE context-related configurations. Through the user plane of the F1 interface, IAB nodes and IAB donors can perform functions such as transmitting user plane data and providing downlink transmission status feedback.

[0198] In an IAB network, the physical layer (PHY), MAC layer, and radio link control (RLC) layer, which are peers of the terminal, are located on the access IAB node. The packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), and radio resource control (RRC) layers, which are peers of the terminal, are located on the IAB donor CU. If the IAB donor-CU consists of a CP and an UP, then the RRC layer, which is peers of the terminal, is located on the CP of the IAB donor CU (i.e., donor-CU-CP), and the PDCP and SDAP layers, which are peers of the terminal, are located on the UP of the IAB donor CU (i.e., donor-CU-UP).

[0199] Figure 3 (a) and Figure 3(b) in the figure are schematic diagrams of the user plane protocol stack and the control plane protocol stack in the IAB network provided in the embodiments of this application, respectively. The following is in conjunction with Figure 3 (a) and Figure 3 Explain in (b) of the text.

[0200] From the user's perspective, such as Figure 3 As shown in (a), a Uu interface is established between the UE and IAB node 2-DU (hereinafter referred to as IAB2-DU), with corresponding protocol layers including RLC, MAC, and PHY layers. An F1-U interface is established between IAB2-DU and IAB donor CU 1, with corresponding protocol layers including GTP-U, UDP, and IP layers. An F1 interface within the IAB host is established between IAB donor DU and IAB donor CU, with corresponding protocol layers including IP, L2, and L1. Additionally, corresponding SDAP and PDCP layers are established between the UE and IAB donor CU, and a corresponding IP layer is established between IAB2-DU and IAB donor DU.

[0201] It can be seen that, compared with the user plane protocol stack of a single air interface, the user plane protocol stack of the IAB access node implements some of the functions of the gNB-DU of the single air interface (i.e., the functions of establishing peering RLC, MAC, and PHY layers with the terminal, and the functions of establishing peering GTP-U, UDP, and IP layers with the IAB donor CU). It can be understood that the DU of the IAB access node implements the functions of the gNB-DU of the single air interface; and the IAB donor CU implements the functions of the gNB-CU of the single air interface.

[0202] For control surfaces, such as Figure 3 As shown in (b), a Uu interface is established between the UE and the IAB2-DU, with corresponding protocol layers including RLC, MAC, and PHY layers. An F1-C interface is established between the IAB2-DU and the IAB donor CU, with corresponding protocol layers including F1AP, SCTP, and IP layers. An F1 interface within the IAB host is established between the IAB donor DU and the IAB donor CU, with corresponding protocol layers including IP, L2, and L1. Additionally, corresponding RRC and PDCP layers are established between the UE and the IAB donor CU, and a corresponding IP layer is established between the IAB donor DU and the IAB donor DU.

[0203] It can be seen that, compared with the control plane protocol stack of a single air interface, the DU accessing the IAB node in the IAB network implements the functions of a gNB-DU (i.e., establishing peer-to-peer RLC, MAC, and PHY layers with the terminal, and establishing peer-to-peer F1AP, SCTP, and IP layers with the CU). It can be understood that the DU accessing the IAB node in the IAB network implements the functions of a gNB-DU (single air interface); the IAB donor CU implements the functions of a gNB-CU (single air interface).

[0204] On the control plane, RRC messages are encapsulated within F1AP messages transmitted between the access IAB node and the IAB donor CU. For example, as... Figure 3 As shown, taking the routing path "UE-IAB node 2-IAB node 1-IAB donor" as an example, in the uplink direction, the UE can encapsulate the RRC message in a PDCP protocol data unit (PDU), and send it to IAB2-DU after processing through the RLC layer, MAC layer, and PHY layer in sequence. IAB2-DU then processes the data through the PHY layer, MAC layer, and RLC layer to obtain a PDCP PDU. This PDCP PDU is encapsulated in an F1AP message and processed through the SCTP layer and IP layer in sequence to obtain a data packet. IAB node2-MT (hereinafter referred to as IAB2-MT) ​​then processes the data packet through the BAP layer, RLC layer, MAC layer, and PHY layer in sequence before sending it to IAB node1-DU (hereinafter referred to as IAB1-DU). IAB1-DU then processes the data packet through the PHY layer, MAC layer, RLC layer, and BAP layer in sequence. Finally, IAB node1-MT (hereinafter referred to as IAB1-MT) uses a similar operation to IAB2-MT to send this data packet to the IAB donor DU. After the IAB donor DU parses the data packet, it sends the packet to the IAB donor CU. The IAB donor CU processes the packet sequentially through the SCTP layer, F1AP layer, and PDCP layer to obtain the RRC message. The downlink direction is similar and will not be described further here.

[0205] On the control plane, PDCP packets are encapsulated in a GTP-U tunnel between the access IAB node and the IAB donor CU for transmission. The GTP-U tunnel is established on the F1-U interface.

[0206] To make the embodiments of this application clearer, the relevant technical features involved in the embodiments of this application are explained below. It should be noted that these explanations are for the purpose of making the embodiments of this application easier to understand, and should not be regarded as a limitation on the scope of protection claimed by this application.

[0207] 1. Connecting to IAB nodes and intermediate IAB nodes

[0208] In this application embodiment, the access IAB node refers to the IAB node accessed by the terminal, and the intermediate IAB node refers to the IAB node between the access IAB node and the host node.

[0209] For example, see Figure 2 In the path “UE1→IAB node 4→IAB node 3→IAB node 1→host node”, IAB node 4 is the access IAB node, and IAB node 3 and IAB node 1 are intermediate IAB nodes. IAB node 3 provides backhaul services to IAB node 4, and IAB node 1 provides backhaul services to IAB node 3.

[0210] It's important to note that, from the perspective of the terminal connected to that IAB node, it is an access IAB node. From the perspective of terminals connecting to other IAB nodes, it is an intermediate IAB node. Therefore, whether an IAB node is a access IAB node or an intermediate IAB node is not fixed and needs to be determined based on the specific application scenario.

[0211] 2. Links, access links, and backhaul links

[0212] Link: refers to the path between two adjacent nodes in a path.

[0213] An access link refers to the link through which a terminal accesses the network. This can be the link between the terminal and access network equipment, between the terminal and an IAB node, between the terminal and a host node, or between the terminal and a host DU. Alternatively, an access link can include the wireless link used by an IAB node when it acts as a regular terminal device and communicates with its parent node. When an IAB node acts as a regular terminal device, it does not provide backhaul services to any child nodes. Access links include uplink access links and downlink access links. In this application, the terminal's access link is a wireless link; therefore, the access link can be referred to as a wireless access link.

[0214] A backhaul link refers to the link between an IAB node and its parent node when the IAB node acts as a wireless backhaul node. When an IAB node acts as a wireless backhaul node, it provides wireless backhaul services to its child nodes. Backhaul links include uplink backhaul links and downlink backhaul links. In this application, the backhaul link between the IAB node and its parent node is a wireless link; therefore, the backhaul link can also be referred to as a wireless backhaul link.

[0215] 3. The node's previous hop node, the node's next hop node, the node's ingress link, and the node's egress link.

[0216] The previous hop node of a node: refers to the last node in the path that contains the node that received the data packet before the current node.

[0217] The next-hop node of a node is the first node in the path that contains the node to receive the data packet after that node.

[0218] Node ingress link: For uplink transmission, it refers to the link between the node and its previous hop node (for example, the previous hop node of the node can be a child node of the node), also known as the node's previous hop link.

[0219] Node outbound link: For uplink transmission, it refers to the link between the node and its next-hop node (for example, the next-hop node of the node can be the node's parent node), also known as the node's next-hop link.

[0220] Parent and Child Nodes: Each IAB node considers the node that provides wireless access and / or wireless backhaul services to it as its parent node. Correspondingly, each IAB node can be considered a child node of its parent node. Alternatively, a child node can also be called a subordinate node, and a parent node can also be called a superior node.

[0221] 4. Data packets

[0222] The data packet can be a data packet in a radio bearer (RB), which can be a data radio bearer (DRB), meaning the data packet is a user plane data packet; or it can be a signaling radio bearer (SRB), meaning the data packet is a control plane data packet; or it can be an operation administration and maintenance (OAM) data packet, meaning the data packet is a management plane data packet.

[0223] 5. Mapping relationships between RLC channels, LCH, and protocol entities

[0224] See Figure 4 and Figure 5 , Figure 4 and Figure 5 This is a schematic diagram illustrating the mapping relationship between RLC channels, LCH, and protocol entities. For example... Figure 4 or Figure 5As shown, the RLC CH is the channel between an RLC entity and its upper-layer protocol entity. For example, if the upper layer of the RLC entity is a PDCP entity, then the RLC CH on the backhaul link is the channel between the RLC entity and the PDCP entity. As another example, if the upper layer of the RLC entity is a BAP layer entity, then the RLC CH on the backhaul link is the channel between the RLC entity and the BAP entity. Therefore, the definition of the RLC CH depends specifically on the upper-layer protocol entity of the RLC entity.

[0225] A logical channel is a channel between an RLC entity and its underlying protocol entity. For example, if the underlying layer of an RLC entity is the MAC layer, the logical channel is a channel between the RLC entity and the MAC entity.

[0226] Each RLC CH of an IAB node corresponds to one RLC entity and one RLC bearer.

[0227] In this context, a BAP entity can correspond to multiple RLC entities, such as... Figure 4 As shown, a BAP entity can also correspond to an RLC entity, such as... Figure 5 As shown, this application does not limit this.

[0228] In addition, the BAP layer possesses one or more of the following capabilities: adding routing information recognizable by the IAB node to data packets; performing routing selection based on the routing information recognizable by the IAB node; adding identification information related to quality of service (QoS) requirements recognizable by the IAB node to data packets; performing QoS mapping on multi-segment links containing the IAB node for data packets; adding data packet type indication information to data packets; and sending flow control feedback information to nodes with flow control capabilities. It should be noted that the name of the protocol layer possessing these capabilities is not necessarily BAP layer; it can be other names. Those skilled in the art will understand that any protocol layer possessing these capabilities can be understood as the BAP layer in the embodiments of this application. The RLC CH on the BH link can be understood as a service differentiation channel on the BH link between two nodes, which can provide specific QoS guarantees for data packet transmission. The RLC CH on the BH link can be understood as a logical concept, rather than a physical channel concept.

[0229] Specifically, the RLC CH on the BH link can be understood as the peer RLC CH of the two IAB nodes on the BH link. For example, in Figure 2In this context, the host node has RLC CH1 and RLC CH2; node 1 has RLC CH1 and RLC CH2. The RLC entities of the host node's RLC CH1 and node 1's RLC CH1 are peers, and the RLC entities of the host node's RLC CH2 and node 1's RLC CH1 are peers. Further, it can be understood that the host node's RLC CH1 is peer to node 1's RLC CH1, and the host node's RLC CH2 is peer to node 1's RLC CH2. The RLC CH1 of the BH link between host node DU and node 1 can refer to both the host node's RLC CH1 and node 1's RLC CH1, and the RLC CH2 of the BH link between host node DU and node 1 can refer to both the host node's RLC CH2 and node 1's RLC CH2.

[0230] Since RLC CH, RLC bearer, and logical channel have a one-to-one correspondence, these three terms can be substituted for each other in the embodiments of this application. For example, RLC CH can be replaced with RLC bearer or logical channel in the embodiments of this application. Similarly, the RLC bearer in the BH link can also be called BH bearer or BH link bearer. Therefore, the RLC CH of the BH link can be replaced with the RLC actual bearer of the BH link, the logical channel of the BH link, or the BH bearer or the bearer of the BH link.

[0231] 6. Export RLC CH and Import RLC CH

[0232] Export RLC CH: refers to the RLC CH between an IAB node and its parent node.

[0233] Entry RLC CH: refers to the RLC CH between an IAB node and its child nodes.

[0234] The outgoing RLC CH and the incoming RLC CH can have a mapping relationship. Uplink data received by an IAB node from the incoming RLC CH can be sent to the next IAB node (i.e., the parent node of the IAB node) by the outgoing RLC CH mapped by that incoming RLC CH.

[0235] 7. Quality of Service (QoS) and Tunnel Endpoint Identification (TEID)

[0236] Generally, QoS can be implemented by one or a group of F1-U Tunnels, where a TEID is used to uniquely identify an F1-U Tunnel.

[0237] 8. Boundary node, descendant node, and ancestor node.

[0238] In this embodiment, a boundary node refers to an IAB node operating in a dual-connectivity state, a child node refers to a downstream node of the boundary node, and a parent node refers to an upstream node of the boundary node. The parent node can also be called an ancestor node, etc., and is not limited thereto. For example, in... Figure 1 In the diagram (where IAB nodes are represented as MT and DU portions, and IAB donors as CU and donor-DU portions), IAB node2 is the boundary node, IAB node4 is the descendant node, IAB node1 is the MN-related ancestor node, and IAB node3 is the SN-related ancestor node. In the following description, IAB DU refers to the DU portion of the IAB node, and donor-DU refers to the DU portion of the IAB donor.

[0239] 9. Master node (MN) and secondary node (SN)

[0240] The IAB donor to which the CU with an F1 interface to the DU part of the boundary node belongs is called the master node (MN), and the IAB donor to which the CU with no F1 interface to the DU part of the boundary node belongs is called the secondary node (SN). The master node and the secondary node exchange information through the Xn interface.

[0241] It should be noted that, in Figure 1 In the architecture of the communication system to which this application embodiment applies, the IABnode allows dual connections to different IABnode CUs, such as... Figure 1As shown, CU1 is the MN CU and CU2 is the SN CU. When CU1 establishes traffic passing through the secondary topology, CU1 needs to send a QoS list to CU2 through the Xn interface, informing it of the QoS information of the traffic passing through the secondary topology. CU2 then configures resources in the secondary topology nodes to meet these QoS requirements. For non-UP traffic, each index in the QoS list represents a service type (UE-associated F1AP / non-UE-associated F1AP / non-F1); for UP traffic, each index in the QoS list represents one or more F1-U Tunnels that fulfill the QoS requirement. CU2 may know the TEID of each F1-U Tunnel (CU1 informs CU2) or it may not know it (CU1 does not inform CU2).

[0242] The set of primary nodes and IAB nodes that have F1 interfaces with the CUs in the primary nodes is called the primary topology, and the set of secondary nodes and IAB nodes that have F1 interfaces with the CUs in the secondary nodes is called the secondary topology. For example... Figure 1 As shown, CU1, donor-DU1, IAB node1, IAB node2, and IAB node4 constitute the main topology, while CU2, donor-DU2, and IAB node3 constitute the secondary topology. It should be noted that, in... Figure 1 In the system architecture shown, flow control in the primary topology is controlled by CU1, and flow control in the secondary topology is controlled by CU2. When an IAB node detects congestion or poor serving cell signal quality in a topology (e.g., primary or secondary), it only reports a status indication message to its associated node (CU1 or CU2). This status indication message triggers flow control in the receiving node. For example, when IAB node2 or IAB node4 detects congestion or poor serving cell signal quality, they only send a status indication message to CU1. Similarly, when IAB node3 detects congestion or poor serving cell signal quality, it only sends a status indication message to CU2. Therefore, flow control across CU dual-connectivity network architectures cannot be implemented.

[0243] Based on this, this application proposes a communication method that supports cross-CU resource reconfiguration for scenarios where IAB node is dual-connected to different IABdonor CUs, thereby enabling cross-CU traffic control.

[0244] It should be noted that reconfiguration in this application embodiment can also be described as deletion, release, configuration, or modification, etc., and this application embodiment does not limit it here. In this application embodiment, flow control can also be described as flow release, flow withdrawal, etc., and is not limited here.

[0245] The communication method and communication device provided in this application are described in detail below:

[0246] Please see Figure 6 , Figure 6 This is a flowchart illustrating a communication method provided in an embodiment of this application. For example... Figure 6 As shown, the communication method includes the following steps S601 to S602:

[0247] S601, The first node receives the first message from the second node.

[0248] In some feasible implementations, the second node sends a first message to the first node, and correspondingly the first node receives a first message from the second node. This first message instructs the reconfiguration of resources in a first topology used to serve the first traffic. The first topology is a topology controlled by the first node, and the first traffic is the traffic of a third node or the traffic of a downstream node of the third node. The third node is a boundary node, such as... Figure 1 In the system architecture shown, the third node is IABnode2.

[0249] Generally, when a fourth node detects congestion based on its own implementation (e.g., when the fourth node's DU portion determines that its buffer load is greater than or equal to a preset threshold) or when the serving cell signal quality is poor (e.g., when the fourth node's MT portion detects through radio resource management (RRM) that the serving cell signal quality is less than or equal to a preset signal quality threshold), the fourth node can send a second message to the second node. This second message can also be called a status indication message, which may include a Base Station-Distributed Unit Status Indication (GNB-DU) message or an RRC message, etc., without limitation. This second message is used to report the location of congestion or poor signal quality. For example, the second message may include the identifier of the backhaul link (BH link) or the backhaul radio link control channel identification (BH RLC CH ID), etc. Therefore, the second node receiving this second message can generate a first message based on it. Specifically, when the DU part of the fourth node discovers congestion based on its own implementation, it can send a GNB-DU Status Indication message carrying the BH link or RLCCH ID to the second node through its DU part; that is, the second message is a GNB-DU Status Indication message. When the MT part of the fourth node discovers poor signal quality of the serving cell through RRM measurements, it can send an RRC message carrying the BH link or RLCCH ID to the second node through its MT part; that is, the second message is an RRC message. Upon receiving the second message from the fourth node, the second node can then generate a first message based on the second message and send the first message to the first node. Generally, the second node can send the first message to the first node through the Xn interface; that is, the first message is an Xn message.

[0250] The fourth node can be an IAB node in the network architecture. For example, the fourth node and the third node can be the same node, meaning the fourth node is a boundary node. Figure 1 In the system architecture diagram shown, IAB node2; or, the fourth node is a child node of the boundary node (or a downstream node of the boundary node), for example... Figure 1 In the system architecture diagram shown, IAB node4; or, the fourth node is a secondary ancestor node of the boundary node, for example... Figure 1 The IAB node3 in the system architecture diagram shown is not limited here. The solutions provided in this application will be described in detail later for different possibilities of the fourth node.

[0251] In this implementation, the third node (or described as the MT portion of the third node) has RRC connections with both the first and second nodes, and an F1 connection with the second node (or described as the DU portion of the third node). The first node is a centralized unit (CU) within the first IAB host node, and the second node is a centralized unit (CU) within the second IAB host node. That is, the third node is doubly connected to both the first and second nodes. Alternatively, it can be described as the first node being a centralized unit (CU) within the first IAB host node in a doubly connected mode, and the second node being a centralized unit (CU) within the second IAB host node in a doubly connected mode. The first IAB host node can be a secondary IAB host node in a doubly connected mode, and the second IAB host node can be the primary IAB host node in a doubly connected mode. Alternatively, the first IAB host node can be the primary IAB host node in a doubly connected mode, and the second IAB host node can be a secondary IAB host node in a doubly connected mode. In other words, in one possible implementation, the first node is a CU of the secondary IAB host node in a doubly connected mode, and the second node is a CU of the primary IAB host node in a doubly connected mode. In another implementation, the first node is the CU of the primary IAB host node in dual-connection mode, and the second node is the CU of the secondary IAB host node in dual-connection mode.

[0252] In this scenario, when the first node is the CU of the secondary IAB host node in dual-connection mode and the second node is the CU of the primary IAB host node in dual-connection mode, the first topology is the secondary topology. That is, the first message is used to instruct the reconfiguration of resources in the secondary topology used to serve the first traffic. When the first node is the CU of the primary IAB host node in dual-connection mode and the second node is the CU of the secondary IAB host node in dual-connection mode, the first topology is the primary topology. That is, the first message is used to instruct the withdrawal of resources in the primary topology used to serve the first traffic. The following sections will provide detailed explanations for these two scenarios.

[0253] In one implementation, when the first node is the CU of the secondary IAB host node in dual-connection mode, and the second node is the CU of the primary IAB host node in dual-connection mode, the first node can determine the resources in the first topology that need to be reconfigured to serve the first traffic based on the second message received from the fourth node. Here, the fourth node can be a boundary node, a child node of a boundary node, or an ancestor node related to the primary node. For example, with... Figure 1 Taking the system architecture shown as an example, the first node can be as follows: Figure 1 As shown in CU2, the second node can be as follows: Figure 1 As shown in CU1, the fourth node can be as follows: Figure 1The boundary node shown is IAB node2 (i.e., IAB MT2 and IABDU2), or the fourth node can be as follows: Figure 1 The child nodes of the boundary node shown are IAB node4 (i.e., IAB MT4 and IABDU4), or the fourth node can be as follows: Figure 1 The ancestor nodes IAB node1 (i.e., IAB MT1 and IAB DU1) associated with the master node are shown.

[0254] In another implementation, when the first node is the CU of the primary IAB host node in dual-connection mode, and the second node is the CU of the secondary IAB host node in dual-connection mode, the first node can determine the service traffic carried in the first topology to be withdrawn based on the second message received from the third IAB node. Specifically, the fourth node can be an ancestor node related to the secondary node. For example, similarly... Figure 1 Taking the system architecture shown as an example, the first node can be as follows: Figure 1 As shown in CU2, the second node can be as follows: Figure 1 As shown in CU1, the fourth node can be as follows: Figure 1 The ancestor nodes IAB node3 (i.e., IAB MT3 and IAB DU3) associated with the auxiliary nodes are shown.

[0255] S602, The first node reconfigures the resources in the first topology used to serve the first traffic based on the first message.

[0256] In some feasible implementations, the first node can reconfigure the resources in the first topology used to serve the first traffic based on the first message. Here, reconfiguring the resources in the first topology used to serve the first traffic based on the first message can be understood as deleting the resources in the first topology used to serve the first traffic based on the first message. Optionally, the first node can also send a first feedback of the first message to the second node. The first feedback is used to trigger the second node to reconfigure the resources in the second topology used to serve the first traffic, where the second topology is a topology controlled by the second node.

[0257] Generally, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to QoS indexes in the resources of the first traffic, and resources corresponding to the tunnel endpoint identifier (TEID) in the resources of the first traffic. That is, the first node performs resource deletion, resource reconfiguration, or resource release at different granularities based on the different contents included in the first message, thereby realizing traffic release, traffic control, or traffic withdrawal at different granularities.

[0258] Optionally, the first message may also include first indication information, which indicates the reason for triggering flow control. Specifically, the reason for triggering flow control includes congestion or signal quality not meeting quality requirements. For example, the length of the first indication information can be 1 bit, where a value of 1 indicates that the reason for triggering flow control is congestion, and a value of 0 indicates that the reason for triggering flow control is signal quality not meeting quality requirements; or vice versa, without restriction. As another example, the length of the first indication information can be 2 bits, where a value of 10 indicates that the reason for triggering flow control is congestion, and a value of 01 indicates that the reason for triggering flow control is signal quality not meeting quality requirements; or vice versa, without restriction.

[0259] In one possible implementation, when the first message includes an indication to reconfigure all resources for the first traffic, the first node can delete all resources in the first topology used to serve the first traffic. Correspondingly, the second node can delete all resources in the second topology used to serve the first traffic, thereby releasing all resources used to serve the first traffic. Specifically, ① when the first node is the CU of the secondary IAB host node in dual-connection mode, and the second node is the CU of the primary IAB host node in dual-connection mode, the second node can use FIAP to inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node associated with the primary node) to release all traffic in the QoS list passing through the secondary topology. The first node can also use FIAP to inform the secondary topology node (e.g., ancestor node associated with the secondary node) to release all traffic in the QoS list passing through the secondary topology. ② When the first node is the CU of the primary IAB host node in dual-connection mode and the second node is the CU of the secondary IAB host node in dual-connection mode, the first node can use F1AP to inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node related to the primary node) to release all traffic in the QoS list passing through the primary topology. The second node can use F1AP to inform the secondary topology node (e.g., ancestor node related to the secondary node) to release all traffic in the QoS list passing through the primary topology.

[0260] It should be noted that the QoS lists involved in the embodiments of this application can all be understood as MN CU (e.g., Figure 1 When establishing traffic through the secondary topology, MN CU (e.g., CU1) sends information to SN CU (e.g., CU1) via the Xn interface. Figure 1The QoS list sent by CU2 in the secondary topology is used to inform the QoS information of traffic passing through the secondary topology. Based on this, the SN CU can configure resources in the secondary topology node to meet the QoS requirements in the QoS list.

[0261] In one possible implementation, when the first message includes QoS indexes, the first node can delete the resources corresponding to the QoS indexes in the first topology, and correspondingly, the second node can delete the resources corresponding to the QoS indexes in the second topology, thereby releasing some resources used to serve the first traffic. Specifically, ① when the first node is the CU of the secondary IAB host node in dual-connection mode, and the second node is the CU of the primary IAB host node in dual-connection mode, the second node can inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node associated with the primary node) via FIAP to release the QoS indexes that need to be released in the QoS list passing through the secondary topology, and the first node can inform the secondary topology node (e.g., ancestor node associated with the secondary node) via FIAP to release the QoS indexes that need to be released in the QoS list passing through the secondary topology. ② When the first node is the CU of the primary IAB host node in dual-connection mode and the second node is the CU of the secondary IAB host node in dual-connection mode, the first node can use F1AP to inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node related to the primary node) to release the QoS indexes that need to be released in the QoS list passing through the primary topology. The second node can use F1AP to inform the secondary topology node (e.g., ancestor node related to the secondary node) to release the QoS indexes that need to be released in the QoS list passing through the primary topology.

[0262] When the granularity of traffic release is all traffic or release with QoS as the smallest granularity, releasing traffic can be understood as deleting the RLC CH newly created in the node (main topology node or auxiliary topology node) to meet the QoS requirements in the QoS list, or deleting the mapping relationship between QoS requirements and RLC CH.

[0263] For example, such as Figure 1Taking the system architecture shown as an example, assume the first node is CU2 and the second node is CU1. Assume that when CU1 establishes traffic through the secondary topology, the QoS list sent by CU1 to CU2 via the Xn interface includes QoS index1 for service type 1, QoS index2 for service type 2, and QoS index3 for service type 3. During traffic transmission, CU2 receives first information from CU1, which includes QoS index1. Therefore, CU2 can notify Donor-du2 and IAB node3 (i.e., IAB MT3 and IAB DU3) to release the traffic corresponding to QoS index1. CU1 can notify Donor-du1, IAB node1 (i.e., IAB MT1 and IAB DU1), IAB node2 (i.e., IAB MT2 and IAB DU2), and IAB node4 (i.e., IAB MT4 and IAB DU4) to release the traffic corresponding to QoS index1.

[0264] In one possible implementation, when the first message includes a TEID, the first node can delete the resource corresponding to the TEID in the first topology (i.e., the F1-U Tunnel). Correspondingly, the second node can delete the resource corresponding to the TEID in the second topology (i.e., the F1-U Tunnel), thereby releasing some resources used to serve the first traffic. Specifically, ① when the first node is the CU of the secondary IAB host node in dual-connection mode, and the second node is the CU of the primary IAB host node in dual-connection mode, the second node can inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node associated with the primary node) to release resources in the selected F1-U Tunnel via F1AP. The first node can also inform the secondary topology node (e.g., ancestor node associated with the secondary node) to release resources in the selected F1-U Tunnel via F1AP. ② When the first node is the CU of the primary IAB host node in dual-connection mode and the second node is the CU of the secondary IAB host node in dual-connection mode, the first node can use F1AP to inform the primary topology node (e.g., boundary node, and / or descendant node, and / or ancestor node related to the primary node) to release resources in the selected F1-U Tunnel. The second node can use F1AP to inform the secondary topology node (e.g., ancestor node related to the secondary node) to release resources in the selected F1-U Tunnel.

[0265] When the granularity of traffic release is based on the F1-U Tunnel, releasing traffic can be understood as deleting the RLC CH in the F1-U Tunnel corresponding to the TEID in the node (primary or secondary topology node). It should be noted that when the first message includes a TEID, the CU of the primary node needs to inform the CU of the secondary node of all TEIDs passing through the secondary topology when establishing traffic through the secondary topology.

[0266] For example, such as Figure 1 Taking the system architecture shown as an example, assume the first node is CU2 and the second node is CU1. Assume that when CU1 establishes traffic through the secondary topology, CU1 sends all TEIDs (TEIDs) for the secondary topology to CU2 via the Xn interface, namely TEID1, TEID2, TEID3, TEID4, and TEID5. During traffic transmission, CU2 receives the first information from CU1, which includes TEID2 and TEID3. Therefore, CU2 can notify Donor-du2 and IAB node3 (i.e., IAB MT3 and IAB DU3) to release the traffic corresponding to TEID2 and TEID3. CU1 can notify Donor-du1, IAB node1 (i.e., IAB MT1 and IAB DU1), IAB node2 (i.e., IAB MT2 and IAB DU2), and IAB node4 (i.e., IAB MT4 and IAB DU4) to release the traffic corresponding to TEID2 and TEID3.

[0267] Optionally, in some feasible implementations, releases triggered by secondary topology nodes can all be rebuilt in the primary topology. Whether rebuilding is allowed for releases triggered by primary topology nodes depends on the network element that triggered the traffic release. For example, [the following is a possible implementation details:] Figure 1 Taking the system architecture shown as an example, for releases triggered by poor serving cell signal quality reported by IAB MT2 (which can be determined through the first indication information), this part of the traffic can be re-established in the main topology (for example, establishing an RLC CH according to QoS requirements, or re-establishing the F1-U Tunnel). For congestion or poor signal quality detected by IAB DU2 or IAB node4, it can only be alleviated by traffic release, and reconstruction in the main topology is not supported.

[0268] In this embodiment, a cross-CU traffic control method supporting various resource granularities is provided for scenarios where an IAB node is dual-connected to different IAB donor CUs. Specifically, when a second node determines that the first topology where the second node resides is congested or has poor signal quality, the second node can send a first message to the first node. This first message instructs the reconfiguration of resources in the first topology used to serve the first traffic. Therefore, the first node and the second node can respectively delete the resources carried in their corresponding topologies used to serve the first traffic based on the instruction of the first message. The resource reconfiguration granularity involved in this embodiment includes reconfiguring all resources, cross-CU resource reconfiguration at the QoS index granularity, and cross-CU resource reconfiguration at the F1-U Tunnel granularity. Alternatively, the traffic control granularity involved in this embodiment can be described as including releasing all traffic, cross-CU traffic release at the QoS index granularity, and cross-CU traffic release at the F1-U Tunnel granularity.

[0269] It should be noted that, regarding such Figure 1 The network architecture shown depicts two IAB nodes connected to different IAB donor CUs. Donor-DU2 needs to perform downlink RLC CH mapping based on the target IP address, IPv6 flow label, and Differentiated Services Code Point (DSCP). The target IP address, IPv6 flow label, and DSCP all need to be included in the IP header, which CU1 writes into the IP header. The DSCP and IPv6 flow label reflect the QoS requirements of the service and have a mapping relationship with the target IP address. In donor-DU2, this mapping relationship is configured by IAB donor-CU2. Therefore, this application also proposes a communication method that can solve the following problems: Figure 1 The following section discusses the mapping configuration issue of RLC CH under the network architecture shown. A detailed explanation follows. Figure 6 This section describes how to feed this mapping relationship back to CU1 so that CU1 can write this information into the IP header.

[0270] Please see Figure 7 , Figure 7 This is another flowchart illustrating the communication method provided in this application embodiment. It should be noted that in this application embodiment, the first node is the centralized unit (CU) in the secondary IAB host node under dual-connection mode, and the second node is the centralized unit (CU) in the primary IAB host node under dual-connection mode. For example... Figure 7 As shown, the communication method includes the following steps S701 to S703:

[0271] S701, The first node receives at least one target Internet Protocol (IP) address corresponding to the data packet of the first service from the second node.

[0272] In some feasible implementations, the second node sends at least one target Internet Protocol (IP) address corresponding to the data packet of the first service to the first node, and correspondingly, the first node receives at least one target IP address corresponding to the data packet of the first service from the second node. The first and second nodes can communicate via the Xn interface; that is, the second node can send the target IP address of the downlink data packet to the first node via the Xn interface.

[0273] S702, The first node determines the first parameter corresponding to each target IP address.

[0274] In some feasible implementations, the first node determines a first parameter corresponding to each target IP address. That is, the first node can configure the first parameter corresponding to each target IP address. The target IP address can be an IPv4 address or an IPv6 address.

[0275] S703, The first node sends the first parameter corresponding to each target IP address to the second node.

[0276] In some feasible implementations, the first node sends a first parameter corresponding to each target IP address to the second node. When the target IP address is an IPv4 address, the first parameter includes a DSCP. When the target IP address is an IPv6 address, the first parameter includes both a DSCP and an IPv6 flow label. For ease of understanding, the following illustrations will use an IPv6 target IP address and a first parameter including both a DSCP and an IPv6 flow label.

[0277] In one possible implementation, when one target IP address corresponds to one first parameter, sending the first parameter corresponding to each target IP address to the second node can be understood as: sending the first parameter corresponding to each target IP address to the second node based on the receiving order of at least one target IP address; or, sending the first parameter to the second node a 1:1 mapping relationship between each target IP address and the first parameter. That is, for a 1:1 mapping, the first node can arrange {DSCP, IPv6 flowlabel} sequentially according to the order of the target IP addresses sent to it by the second node and send it to the second node through the Xn interface. For ease of understanding, the cell structure of the 1:1 mapping under this sending method can be represented as shown in Table 1 below. Alternatively, for a 1:1 mapping, the first node can use the arrangement {DSCP, IPv6 flow label, IP} and send this mapping relationship to the second node through the Xn interface. For ease of understanding, the cell structure of the 1:1 mapping under this sending method can be represented as shown in Table 2 below.

[0278] Table 1

[0279] IE Name for 1:1 mapping(option1) DSCP IPv6 flowlabel

[0280] Table 2

[0281]

[0282] For example, such as Figure 1Taking the system architecture shown as an example, for a 1:1 mapping, assume that the target IP addresses sent by CU1 to CU2 include IP address1, IP address2, and IP address3, and that CU1 sends these IP addresses to CU2 in the order of IP address1→IP address2→IP address3. When CU2 receives these IP addresses, it can configure IP address1 to correspond to DSCP1 and IPv6 flow label1; IP address2 to correspond to DSCP2 and IPv6 flow label2; and IP address3 to correspond to DSCP3 and IPv6 flow label3. In one possible implementation, CU2 can arrange the {DSCP, IPv6 flow label} corresponding to IP address1, IP address2, and IP address3 in the order of the IP addresses sent to it by CU1, and send them to CU1 through the Xn interface. That is, CU2 sends the {DSCP, IPv6 flow label} corresponding to IP address1, IP address2, and IP address3 to CU1 in the order of {DSCP1, IPv6 flow label1} → {DSCP2, IPv6 flow label2} → {DSCP3, IPv6 flow label3}.In another possible implementation, CU2 can use the arrangement {DSCP, IPv6 flow label, IP address} to send the {DSCP, IPv6 flow label, IP address} corresponding to IP address1, IP address2, and IP address3 to CU1 via the Xn interface. That is, CU2 sends {DSCP1, IPv6 flow label1, IP address1}, {DSCP2, IPv6 flow label2, IP address2}, and {DSCP3, IPv6 flow label3, IP address3} to CU1. Understandably, the sending order is not limited in this implementation. For example, CU2 can send them in the order {DSCP1, IPv6 flow label1, IP address1} → {DSCP2, IPv6 flow label2, IP address2} → {DSCP3, IPv6 flow label3, IP address3}. Or, for another example, CU2 can send them in the order {DSCP2, IPv6 flow label2, IP address2} → {DSCP1, IPv6 flow label1, IP address2}. The sequence {address1}→{DSCP3,IPv6 flow label3,IP address3} can be used. For example, CU2 can be sent in the order {DSCP2,IPv6 flow label2,IP address2}→{DSCP3,IPv6flow label3,IP address3}→{DSCP1,IPv6 flow label1,IP address1}, etc. No restrictions are imposed here.

[0283] In another possible implementation, when a target IP address corresponds to multiple first parameters, sending the first parameter corresponding to each target IP address to the second node can be understood as: sending the first parameter corresponding to each target IP address to the second node based on the receiving order of at least one target IP address; or, sending the first parameter to the second node a 1:N mapping relationship between multiple target IP addresses. That is, for 1:N mapping, the first node can arrange {DSCP, IPv6 flowlabel} sequentially according to the order of the target IP addresses sent to it by the second node, and send it to the second node through the Xn interface (the cell structure can be seen in Table 1 above); or, the mapping relationship can be expressed by arranging {{DSCP, IPv6 flow label}, {IP1, ..., IPN}}, pairing {DSCP, IPv6 flow label} with the corresponding multiple IP addresses, and then sending the mapping relationship to the second node through the Xn interface. For ease of understanding, the cell structure of the 1:1 mapping under this sending method can be represented as shown in Table 3 below.

[0284] Table 3

[0285]

[0286] For example, such as Figure 1Taking the system architecture shown as an example, for a 1:N mapping, assume that the target IP addresses sent by CU1 to CU2 include IP address1, IP address2, IP address3, and IP address4, and that CU1 sends these IP addresses to CU2 in the order of IP address1→IP address2→IP address3→IP address4. When CU2 receives these IP addresses, it can configure IP address1 to correspond to DSCP1 and IPv6 flow label1; IP address2 to correspond to DSCP1 and IPv6 flow label1; IP address3 to correspond to DSCP2 and IPv6 flow label2; and IP address4 to correspond to DSCP2 and IPv6 flow label2. In one possible implementation, CU2 can arrange the {DSCP, IPv6 flow label} corresponding to IP address1, IP address2, IP address3, and IP address4 in the order of the IP addresses sent to it by CU1, and send them to CU1 through the Xn interface. That is, CU2 sends the {DSCP, IPv6 flow label} corresponding to IP address1, IP address2, IP address3, and IP address4 to CU1 in the order of {DSCP1, IPv6 flow label1}→{DSCP1, IPv6flow label1}→{DSCP2, IPv6 flow label2}→{DSCP2, IPv6 flow label2}.In another possible implementation, CU2 can use the arrangement {{DSCP,IPv6 flow label},{IP1,…,IPN}} to send the {DSCP,IPv6 flow label,IP address} corresponding to IP address1, IP address2, and IP address3 to CU1 via the Xn interface. That is, CU2 sends {{DSCP1,IPv6 flow label1},{IP address1,IP address2}} and {{DSCP2,IPv6 flow label2},{IP address3,IP address4}} to CU1. Understandably, the sending order is not limited in this implementation. For example, CU2 can send them in the order {{DSCP1,IPv6 flow label1},{IP address1,IP address2}} → {{DSCP2,IPv6 flow label2},{IP address3,IP address4}}, or in the order {{DSCP2,IPv6flow label2},{IP address3,IP address4}} → {{DSCP1,IPv6 flow label2},{IP address3,IP address4}}. The order of {label1}, {IPaddress1, IP address2}} is not restricted here.

[0287] It should be noted that for each data packet, the second node can write the target IP address, DSCP and IPv6 flow label into the IP header based on the mapping relationship, and finally send the data packet to the donor-DU2 for routing.

[0288] In this embodiment, a cross-CU routing method is provided for scenarios where an IAB node has dual connections to different IAB donor CUs. Specifically, the second node obtains the mapping relationship between DSCP, IPv6 flow label, and target IP address from the first node, so that the second node can write it into the packet header, ensuring the correct transmission of data packets across topologies and improving communication reliability.

[0289] It should be noted that in the discussions of the 3GPP Rel-17 standard, it was determined that the handover of IAB nodes between different hosts will adopt partial migration. That is, the MT portion of the IAB node to be switched will be switched to the DU of the target host (either the target host's donor-DU or the IAB node DU controlled by the target host's donor-CU), disconnecting from the source host and establishing an RRC connection with the target host's CU; while its DU portion remains under the control of the source CU, retaining its F1 interface with the source host CU, and will not establish a new F1 interface with the target host CU. For an example, please refer to [link to example]. Figure 8 , Figure 8 This is a switching diagram provided in an embodiment of this application. For example... Figure 8 As shown, IAB MT2 maintains dual connectivity with CU1 and CU2 through IAB DU1 and IAB DU3. Sometimes, IAB MT2 will directly switch to IAB DU3, disconnecting from IAB DU1. However, in this case, IAB DU2 and IAB DU4 will not establish an F1AP with CU2, but will maintain their F1AP with CU1 to reduce the overhead of F1AP reconstruction. This architecture is called partial migration. Understandably, when IAB MT2 switches to IAB DU3, which is controlled by CU2, it establishes an RRC connection with CU2; while IAB DU2 remains controlled by CU1, retaining its F1 interface with CU1. This F1 interface is implemented through the path "IAB node2→IAB node3→donor-DU2→CU1".

[0290] It should be noted that after a partial migration, the boundary / descendant node and CU1 can only be connected via the first topology. However, considering that data may be being transmitted through the second topology when a partial migration occurs, and IAB MT2 disconnects from the second topology, this transmitted data needs to be rerouted across topologies. Cross-topology rerouting involves rewriting the BAP header, requiring the old BAP routing ID in the input topology to be changed to a new BAP routing ID that can be recognized in the output topology. Figure 8 For example, for IAB node2, data transmission between it and IAB node3 and IAB node4 all need to go through BAP routing. IAB node2 needs to know how to modify the BAP routing ID so that it can change the BAP routing ID from being recognizable by the second topology to being recognizable by the first topology during uplink transmission.

[0291] Based on this, this application proposes a communication method that can solve the problem of rewriting the BAP header during rerouting in partial migration scenarios.

[0292] Please see Figure 9 , Figure 9 This is another flowchart illustrating the communication method provided in this application embodiment. It should be noted that in this application embodiment, the first node is the centralized unit (CU) in the target IAB host node of the third node, and the second node is the centralized unit (CU) in the source IAB host node of the third node. The third node can be a DU of a boundary node. Figure 9 As shown, the communication method includes the following steps S901 to S903:

[0293] S901, The second node sends the first IP address corresponding to the data packet of the first service to the first node.

[0294] In some feasible implementations, the second node obtains the first IP address and sends it to the first node via the Xn interface. Correspondingly, the first node receives the first IP address from the second node via the Xn interface. The first IP address includes the source IP address. Specifically, the second node can obtain the source IP address of the uplink data packet based on the traffic context of the border node or its child nodes, and inform the first node of this information via the Xn interface.

[0295] S902, the second node receives the first mapping relationship between the first IP address from the first node and the first backhaul adaptation protocol routing ID (BAP routing ID).

[0296] In some feasible implementations, for each uplink data packet, the first node can assign a first Backhaul Adaptor Protocol routing ID (BAP routing ID) in the first topology to each data packet, and inform the second node of the first mapping relationship between the first BAP routing ID and the first IP address (i.e., the source IP address of the uplink data packet) through F1AP. Accordingly, the second node receives the first mapping relationship between the first IP address and the first BAP routing ID from the first node.

[0297] S903, the second node sends the second mapping relationship between the first BAP routing ID and the second BAP routing ID to the third node.

[0298] In some feasible implementations, the second node sends a second mapping relationship between the first BAP routing ID and the second BAP routing ID to the third node. This second mapping relationship is used for rerouting data packets of the first service. Specifically, the second node obtains a third mapping relationship between the first IP address and the second BAP routing ID, and determines the second mapping relationship based on the first and third mapping relationships. Further, the second node sends the second mapping relationship between the first BAProuting ID and the second BAP routing ID to the third node. This second mapping relationship is used for rerouting data packets of the first service. In other words, based on the received mapping relationship between the IP address and the first BAP routing ID of the first topology, and the mapping relationship between the IP address and the second BAP routing ID of the second topology already known in the second node, the second node can use the first IP address as an intermediate variable to generate a mapping relationship between the second BAP routing ID of the second topology and the first BAP routing ID of the first topology. Further, the second node can send the second mapping relationship between the second BAProuting ID in the second topology and the first BAP routing ID in the first topology to the DU of the third node via F1AP. Therefore, the DU of the third node can rewrite the BAP routing ID based on this second mapping relationship.

[0299] For example, with Figure 7Taking the uplink data packets in the system architecture shown as an example: First, CU1, based on the context of descendanttraffic, learns that five IP addresses (IP Address1, IP Address2, IP Address3, IP Address4, and IP Address5) previously sent data to it through the second topology. Now, the data from these IP addresses needs to be rerouted to the first topology. Therefore, CU1 informs CU2 of IP Address1, IP Address2, IP Address3, IP Address4, and IP Address5. Next, CU2 learns that the data packets from these IP addresses will be rerouted to the first topology and assigns a first BAP routing ID to these IP address data packets. For example: {IP Address1, IP Address2, IP Address3} -> First BAP routing ID1; {IP Address4, IP Address5} -> First BAP routing ID2, and informs CU1 of these mapping relationships (i.e., the first mapping relationships). Then, CU1 already knows the mapping relationship between IP addresses and the second BAP routing ID (i.e., the third mapping relationship), for example: {IP Address1}->Second BAP routing ID1; {IP Address2, IP Address3}->Second BAP routing ID2; {IP Address4, IP Address5}->Second BAP routing ID3. Therefore, CU1 can further know the mapping relationship between the second BAP routing ID and the first BAP routing ID (i.e., the second mapping relationship), as follows: {Second BAP routing ID1, Second BAP routing ID2}->First BAP routing ID1; {Second BAP routing ID3}->First BAP routing ID2. Finally, CU1 sends the mapping relationship between the second BAP routing ID and the first BAP routing ID to IAB DU2. IAB DU2 rewrites the BAP routing ID according to this mapping relationship. For example, for an uplink data packet with the second BAP routing ID3 in the BAP header, IAB DU2 rewrites the BAP routing ID to the first BAP routing ID2 and sends it to IAB DU3 through IAB MT2. IAB DU3 can correctly identify the information in the first BAP routing ID2.

[0300] To give another example, with Figure 7 Taking the uplink data packets in the system architecture shown as an example: First, CU1, based on the boundary traffic context, learns that three IP addresses—IP Address1, IP Address2, and IP Address3—previously sent data to it through the second topology. Now, data from these IP addresses needs to be rerouted to the first topology. Therefore, CU1 informs CU2 of IP Address1, IP Address2, and IP Address3. Next, CU2 learns that the data packets from these IP addresses will be rerouted to the first topology and assigns a first BAP routing ID to these IP address data packets. For example: {IPAddress1} -> First BAP routing ID1; {IP Address2} -> First BAP routing ID2; {IPAddress3} -> First BAP routing ID3. CU2 then informs CU1 of these mapping relationships (i.e., the first mapping relationships). Then, CU1 already knows the mapping relationship between IP addresses and the second BAP routing ID (i.e., the third mapping relationship), for example: {IPAddress1}->second BAP routing ID3; {IP Address2}->second BAP routing ID2; {IPAddress3}->second BAP routing ID1. Therefore, CU1 can further know the mapping relationship between the second BAP routing ID and the first BAP routing ID (i.e., the second mapping relationship), as follows: {second BAP routing ID1}->first BAP routing ID3; {second BAP routing ID2}->first BAP routing ID2; {second BAP routing ID3}->first BAP routing ID1. Finally, CU1 sends the mapping relationship between the second BAP routing ID and the first BAP routing ID to IAB DU2. IAB DU2 rewrites the BAP routing ID according to this mapping relationship. For example, for an uplink data packet with the second BAP routing ID 3 in the BAP header, IAB DU2 rewrites the BAP routing ID to the first BAP routing ID 1 and sends it to IAB DU3 through IAB MT2. IAB DU3 can correctly identify the information in the first BAP routing ID 2.

[0301] In this embodiment of the application, a cross-CU rerouting method is provided for handover scenarios. Specifically, the second node interacts with the first node, using the IP address as an intermediate variable to generate a mapping relationship between the old and new BAP routing IDs, and informs the third node (i.e., the boundary node). This enables packet rerouting, improves transmission success rate, and reduces service interruption.

[0302] The following will combine Figures 10-12 The communication device provided in this application will be described in detail.

[0303] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Figure 10 The communication device shown can be used to perform the above. Figures 6-9 The described method embodiments include some or all of the functions of the first node. The device can be the first node, a device within the first node, or a device compatible with the first node. The communication device can also be a chip system. Figure 10 The communication device shown may include a transceiver unit 1001 and a processing unit 1002. The processing unit 1002 is used for data processing. The transceiver unit 1001 integrates a receiving unit and a transmitting unit. The transceiver unit 1001 may also be referred to as a communication unit. Alternatively, the transceiver unit 1001 may be split into a receiving unit and a transmitting unit. The processing unit 1002 and the transceiver unit 1001 described below are similar and will not be repeated here. Wherein:

[0304] In one implementation:

[0305] The transceiver unit 1001 is used to receive a first message from a second node, the first message being used to instruct the reconfiguration of resources in a first topology for serving the first traffic, the first topology being a topology controlled by the first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node.

[0306] Processing unit 1002 is configured to reconfigure the resources in the first topology used to serve the first traffic according to the first message;

[0307] The third node has RRC connections with both the first and second nodes, and an F1 connection with the second node. The first node is a centralized unit (CU) in the first integrated access backhaul IAB host node, and the second node is a centralized unit (CU) in the second IAB host node.

[0308] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0309] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0310] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0311] In one possible implementation, the transceiver unit 1001 is further configured to:

[0312] Send a first feedback to the second node of the first message. The first feedback is used to trigger the second node to reconfigure the resources in the second topology used to serve the first traffic. The second topology is a topology controlled by the second node.

[0313] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0314] In one possible implementation, the first topology includes the DU of the first node.

[0315] In one possible implementation, the processing unit 1002 is specifically used for:

[0316] Delete the resources in the first topology used to serve the first traffic based on the first message.

[0317] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0318] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0319] In one possible implementation, the first message is an Xn message.

[0320] In another implementation:

[0321] The transceiver unit 1001 is used to receive at least one target Internet Protocol IP address corresponding to the data packet of the first service from the second node;

[0322] Processing unit 1002 is used to determine a first parameter corresponding to each of the target IP addresses;

[0323] The transceiver unit 1001 is used to send the first parameter corresponding to each of the target IP addresses to the second node;

[0324] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0325] In one possible implementation, a target IP address corresponds to a first parameter;

[0326] The transceiver unit 1001 is specifically used for:

[0327] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0328] Send the first parameter to the second node, along with a 1:1 mapping relationship between each target IP address.

[0329] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0330] The transceiver unit 1001 is specifically used for:

[0331] Based on the receiving order of the at least one target IP address, send the first parameter corresponding to each target IP address to the second node; or,

[0332] Send the first parameter and the 1:N mapping relationship between multiple target IP addresses to the second node.

[0333] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0334] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0335] In another implementation:

[0336] The transceiver unit 1001 is used to receive the first Internet Protocol IP address corresponding to the data packet of the first service from the second node;

[0337] The transceiver unit 1001 is used to send the first mapping relationship between the first IP address and the first backhaul adaptation protocol routing ID (BAP routing ID) to the second node.

[0338] In one possible implementation, the first IP address includes the source IP address.

[0339] Other possible implementations of this communication device can be found in the above. Figures 6-9 The relevant descriptions of the access network device functions in the corresponding method embodiments are not repeated here.

[0340] Please see Figure 11 , Figure 11 This is a schematic diagram of another communication device provided in an embodiment of this application. Figure 11 The communication device shown can be used to perform the above. Figures 6-9 The described method embodiments include some or all of the functions of the second node. The device can be the second node itself, a component within the second node, or a device capable of being used in conjunction with the second node. The communication device can also be a chip system. Figure 11 The communication device shown may include a transceiver unit 1101 and a processing unit 1102. Wherein:

[0341] In one implementation:

[0342] Processing unit 1102 is configured to determine a first message, the first message being configured to instruct the reconfiguration of resources in a first topology for serving the first traffic, the first topology being a topology controlled by a first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node.

[0343] Transceiver unit 1101 is used to send the first message to the first node;

[0344] The third node has RRC connections with both the first and second nodes, and an F1 connection with the second node. The first node is a centralized unit (CU) in the first integrated access backhaul IAB host node, and the second node is a centralized unit (CU) in the second IAB host node.

[0345] In one possible implementation, the first message includes at least one of the following: an indication to reconfigure all resources of the first traffic, resources corresponding to the Quality of Service Index in the resources of the first traffic, and resources corresponding to the Tunnel Endpoint Identifier (TEID) in the resources of the first traffic.

[0346] In one possible implementation, the first message is also used to indicate the reason for triggering flow control.

[0347] In one possible implementation, the reasons for triggering flow control include congestion or signal quality not meeting quality requirements.

[0348] In one possible implementation, the transceiver unit 1101 is further configured to receive first feedback from the first message from the first node;

[0349] The processing unit 1102 is further configured to, in response to the first feedback, reconfigure the resources in the second topology used to serve the first traffic, wherein the second topology is the topology controlled by the second node.

[0350] In one possible implementation, the second topology includes the distributed unit DU of the second node.

[0351] In one possible implementation, the first topology includes the DU of the first node.

[0352] In one possible implementation, the processing unit 1102 is specifically used for:

[0353] Delete the resources in the second topology used to serve the first traffic.

[0354] In one possible implementation, the first IAB host node is a secondary IAB host node, and the second IAB host node is a primary IAB host node; or...

[0355] The first IAB host node is the primary IAB host node, and the second IAB host node is the secondary IAB host node.

[0356] In one possible implementation, the first message is an Xn message.

[0357] In one possible implementation, the transceiver unit 1101 is further configured to:

[0358] A status indication message is received, which is used to determine the first message.

[0359] In another implementation:

[0360] The transceiver unit 1101 is used to send at least one target Internet Protocol IP address corresponding to the data packet of the first service to the first node;

[0361] The transceiver unit 1101 is used to receive a first parameter corresponding to each target IP address from the first node;

[0362] The first parameter reflects the QoS requirement of the first service. The target IP address and the first parameter corresponding to the target IP address are used to determine the Radio Link Control Channel (RLC CH) corresponding to the first service. The first node is the centralized unit (CU) in the secondary IAB host node in the dual-connectivity mode, and the second node is the centralized unit (CU) in the primary IAB host node in the dual-connectivity mode.

[0363] In one possible implementation, a target IP address corresponds to a first parameter;

[0364] The transceiver unit 1101 is specifically used for:

[0365] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0366] Receive the 1:1 mapping relationship between the first parameter from the first node and each target IP address.

[0367] In one possible implementation, multiple target IP addresses correspond to a single first parameter;

[0368] The transceiver unit 1101 is specifically used for:

[0369] Based on the transmission order of the at least one target IP address, receive the first parameter corresponding to each target IP address from the first node; or,

[0370] Receive the first parameter from the first node and the 1:N mapping relationship between multiple target IP addresses.

[0371] In one possible implementation, the target IP address includes an IPv4 address, and the first parameter includes a Differentiated Services Code Point (DSCP).

[0372] In one possible implementation, the target IP address includes an IPv6 address, and the first parameter includes a DSCP and an IPv6 flow label.

[0373] In another implementation:

[0374] The transceiver unit 1101 is used to send the first Internet Protocol IP address corresponding to the data packet of the first service to the first node;

[0375] The transceiver unit 1101 is used to receive the first mapping relationship between the first IP address and the first backhaul adaptation protocol routing ID from the first node;

[0376] The transceiver unit 1101 is used to send a second mapping relationship between the first BAP routing ID and the second BAProuting ID to the third node. The second mapping relationship is used for the rerouting of data packets of the first service.

[0377] Wherein, the first node is the centralized unit CU in the target IAB host node of the third node, and the second node is the centralized unit CU in the source IAB host node of the third node.

[0378] In one possible implementation, the first IP address includes the source IP address.

[0379] In one possible implementation, the device further includes a processing unit 1102, the processing unit 1102 being configured to:

[0380] Obtain the third mapping relationship between the first IP address and the second BAP routing ID;

[0381] The second mapping relationship is determined based on the first mapping relationship and the third mapping relationship.

[0382] Other possible implementations of this communication device can be found in the above. Figures 6-9 The relevant descriptions of the access network device functions in the corresponding method embodiments are not repeated here.

[0383] Please see Figure 12 , Figure 12 This is a schematic diagram of another communication device provided in an embodiment of this application. This communication device can be the first node or the second node described in this application, used to implement the above... Figures 6-9 The function of the first or second node. For ease of explanation, Figure 12 Only the main components of the communication device 1200 are shown.

[0384] like Figure 12As shown, the communication device 1200 includes one or more processors 1201, and optionally, an interface 1202. When the relevant program instructions are executed in the at least one processor 1201, the device 1200 can implement the communication methods and any possible designs provided in any of the foregoing embodiments. Alternatively, the processor 1201 can implement the communication methods and any possible designs provided in any of the foregoing embodiments through logic circuits or executable code instructions. The interface 1202 can be used to receive program instructions and transmit them to the processor, or the interface 1202 can be used for the device 1200 to communicate and interact with other communication devices, such as interacting with control signaling and / or service data. For example, the interface 1202 can be used to receive signals from other devices besides the device 1200 and transmit them to the processor 1201, or send signals from the processor 1201 to other communication devices besides the device 1200. The interface 1202 can be a code and / or data read / write interface circuit, or the interface 1202 can be a signal transmission interface circuit between a communication processor and a transceiver, or a chip pin. Optionally, the communication device 1200 may further include at least one memory 1203, which can be used to store required program instructions and / or data. Optionally, the device 1200 may further include a power supply circuit 1204, which can be used to power the processor 1201. The power supply circuit 1204 may be located within the same chip as the processor 1201, or within a separate chip. Optionally, the device 1200 may further include a bus 1205, through which the various parts of the device 1200 can be interconnected.

[0385] It should be understood that the processor in the embodiments of this application can be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, etc. A general-purpose processor can be a microprocessor, or it can be any conventional processor, etc.

[0386] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), or direct rambus RAM (DR RAM).

[0387] The power supply circuit described in this application includes, but is not limited to, at least one of the following: a power supply line, power supply to an electronic system, a power management chip, a power management processor, or a power management control circuit.

[0388] The transceiver device, interface, or transceiver described in the embodiments of this application may include a separate transmitter and / or a separate receiver, or the transmitter and receiver may be integrated into one unit. The transceiver device, interface, or transceiver can operate under the instruction of a corresponding processor. Optionally, the transmitter may correspond to a transmitter in a physical device, and the receiver may correspond to a receiver in a physical device.

[0389] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0390] In the embodiments of this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0391] Those skilled in the art will recognize that the unit or algorithm operations of the various examples described in conjunction with the embodiments disclosed herein can be implemented in hardware, or in software, or in a combination of both. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0392] In this application, "implemented through software" can refer to a processor reading and executing program instructions stored in memory to implement the functions corresponding to the aforementioned modules or units. Here, a processor refers to a processing circuit capable of executing program instructions, including but not limited to at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., all processing circuits capable of running program instructions. In other embodiments, the processor may also include circuits with other processing functions (such as hardware circuits for hardware acceleration, buses, and interfaces). The processor can be presented as an integrated chip, for example, as an integrated chip whose processing function only includes executing software instructions, or it can be presented as a system-on-a-chip (SoC), that is, on a single chip, in addition to the processing circuit capable of running program instructions (often referred to as a "core"), it also includes other hardware circuits for implementing specific functions (of course, these hardware circuits can also be implemented separately based on ASICs or FPGAs). Correspondingly, the processing functions, in addition to executing software instructions, may also include various hardware acceleration functions (such as AI calculations, encoding / decoding, compression / decompression, etc.).

[0393] In this application, "implemented in hardware" means that the functions of the above-mentioned modules or units are implemented through hardware processing circuits that do not have program instruction processing capabilities. These hardware processing circuits can be composed of discrete hardware components or integrated circuits. To reduce power consumption and size, integrated circuits are typically used. The hardware processing circuits can include ASICs or programmable logic devices (PLDs); PLDs can include FPGAs, complex programmable logic devices (CPLDs), etc. These hardware processing circuits can be a single packaged semiconductor chip (e.g., packaged as an ASIC); or they can be integrated with other circuits (e.g., CPUs, DSPs) and packaged into a single semiconductor chip. For example, multiple hardware circuits and a CPU can be formed on a silicon substrate and packaged into a single chip, also known as a System-on-a-Chip (SoC). Alternatively, circuits for implementing FPGA functions and a CPU can be formed on a silicon substrate and packaged into a single chip, also known as a System-on-a-Chip (SoPC).

[0394] It should be noted that when this application is implemented through software, hardware, or a combination of both, different software or hardware can be used, and it is not limited to using only one type of software or hardware. For example, one module or unit can be implemented using a CPU, while another module or unit can be implemented using a DSP. Similarly, when implemented using hardware, one module or unit can be implemented using an ASIC, while another module or unit can be implemented using an FPGA. Of course, it is not limited to using the same software (e.g., all through a CPU) or the same hardware (e.g., all through an ASIC) to implement some or all modules or units. Furthermore, those skilled in the art will understand that software is generally more flexible but less performant than hardware, while hardware is the opposite. Therefore, those skilled in the art can choose software, hardware, or a combination of both based on actual needs.

[0395] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. The embodiments of this application can be combined, and some technical features in the embodiments can be decoupled from specific embodiments. Combining with existing technology can solve the technical problems involved in the embodiments of this application.

[0396] In this embodiment, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments in this application, depending on actual needs.

[0397] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0398] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and may include several instructions to cause a computer device, such as a personal computer, server, or network device, or a processor, to execute all or part of the operations of the methods described in the various embodiments of this application. The aforementioned storage medium may include various media capable of storing program code or computer-readable storage media, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0399] In the description of this application, terms such as "first", "second", "S601" or "S602" are used only for the purpose of distinguishing descriptions and for the convenience of context. The different order numbers themselves do not have specific technical meanings and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying the order of execution of operations.

[0400] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural. Additionally, the character " / " in this document indicates that the preceding and following related objects have an "or" relationship.

[0401] In this application, "transmission" can include the following three situations: sending data, receiving data, or both sending and receiving data. In this application, "data" can include business data and / or signaling data.

[0402] The terms “comprising” or “having” and any variations thereof in this application are intended to cover a non-exclusive inclusion, such as a process / method that includes a series of steps, or a system / product / equipment that includes a series of units, not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes / methods / products / equipment.

[0403] In the description of this application, unless otherwise specified, the number of nouns refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more. "Including at least one of the following: A, B, C" means that it may include A, or B, or C, or A and B, or A and C, or B and C, or A, B, and C. A, B, and C may be single or multiple.

[0404] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A communication method characterized by comprising: The method is applied to a first node, and includes: receiving a first message from a second node, the first message being used to indicate reconfiguration of resources in a first topology for serving first traffic, the first topology being a topology controlled by the first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node; reconfiguring the resources in the first topology for serving the first traffic according to the first message; wherein the third node has a radio resource control (RRC) connection with the first node and the second node, and has an F1 connection with the second node, and the first node is a centralized unit (CU) in a first integrated access and backhaul (IAB) donor node, and the second node is a CU in a second IAB donor node.

2. The method of claim 1, wherein, The first message includes at least one of the following information: indication information of reconfiguring all resources of the first traffic, resources corresponding to a quality of service (QoS) index in the resources of the first traffic, and resources corresponding to a tunnel endpoint identifier (TEID) in the resources of the first traffic.

3. The method of claim 1, wherein, The first message is also used to indicate a reason for triggering traffic control.

4. The method of claim 3, wherein, The reason for triggering traffic control includes occurrence of congestion or failure of signal quality to meet quality requirements.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: sending first feedback of the first message to the second node, the first feedback being used to trigger the second node to reconfigure resources in a second topology for serving the first traffic, the second topology being a topology controlled by the second node.

6. The method of claim 5, wherein, The second topology includes a distributed unit (DU) of the second node.

7. The method according to any one of claims 1 to 4, characterized in that, The first topology includes a DU of the first node.

8. The method according to any one of claims 1 to 4, characterized in that, The reconfiguring of the resources in the first topology for serving the first traffic according to the first message includes: deleting the resources in the first topology for serving the first traffic according to the first message.

9. The method of any of claims 1-4, wherein the first IAB donor node is a secondary IAB donor node, and the second IAB donor node is a primary IAB donor node; or the first IAB donor node is a primary IAB donor node, and the second IAB donor node is a secondary IAB donor node.

10. The method according to any one of claims 1 to 4, characterized in that, The first message is an Xn message.

11. A communication method, comprising: The method is applied to a second node, and includes: determining a first message, the first message being used to indicate reconfiguration of resources in a first topology for serving first traffic, the first topology being a topology controlled by a first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node; sending the first message to the first node; wherein the third node has a radio resource control (RRC) connection with the first node and the second node, and has an F1 connection with the second node, and the first node is a centralized unit (CU) in a first integrated access and backhaul (IAB) donor node, and the second node is a CU in a second IAB donor node.

12. The method of claim 11, wherein, The first message comprises at least one of the following information: indication information of reconfiguring resources of all the first traffic, resources corresponding to a quality of service index in the resources of the first traffic, and resources corresponding to a tunnel endpoint identifier TEID in the resources of the first traffic.

13. The method of claim 11, wherein, The first message is further used to indicate a reason for triggering traffic control.

14. The method of claim 13, wherein, The reason for triggering traffic control comprises occurrence of congestion or signal quality not meeting quality requirements.

15. The method according to any one of claims 11-14, characterized in that, The method further comprises: receiving first feedback of the first message from the first node; in response to the first feedback, reconfiguring resources in a second topology for serving the first traffic, the second topology being a topology controlled by the second node.

16. The method of claim 15, wherein, The second topology comprises a distributed unit DU of the second node.

17. The method according to any one of claims 11-14, characterized in that, The first topology comprises a DU of the first node.

18. The method according to any one of claims 11-14, characterized in that, The reconfiguring resources in the second topology for serving the first traffic comprises: deleting resources in the second topology for serving the first traffic.

19. The method of any of claims 11-14, wherein: the first IAB-donor node is a secondary IAB-donor node, and the second IAB-donor node is a primary IAB-donor node; or the first IAB-donor node is a primary IAB-donor node, and the second IAB-donor node is a secondary IAB-donor node.

20. The method of any one of claims 11-14, wherein, The first message is an Xn message.

21. The method according to any one of claims 11-14, characterized in that, The method further comprises: receiving a status indication message, the status indication message being used to determine the first message.

22. A communications device, characterized by The apparatus is a first node, comprising: a transceiver, configured to receive a first message from a second node, the first message being used to indicate reconfiguring resources in a first topology for serving first traffic, the first topology being a topology controlled by the first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node; a processing unit, configured to reconfigure the resources in the first topology for serving the first traffic according to the first message; wherein the third node has an RRC connection with the first node and the second node, and the third node has an Fl connection with the second node, and the first node is a centralized unit CU in a first integrated access backhaul IAB-donor node, and the second node is a centralized unit CU in a second IAB-donor node.

23. A communications device, characterized by The apparatus is a second node, comprising: a processing unit, configured to determine a first message, the first message being used to indicate reconfiguring resources in a first topology for serving first traffic, the first topology being a topology controlled by a first node, and the first traffic being traffic of a third node or traffic of a downstream node of the third node; a transceiver, configured to send the first message to the first node; wherein the third node has an RRC connection with the first node and the second node, and the third node has an Fl connection with the second node, and the first node is a centralized unit CU in a first integrated access backhaul IAB-donor node, and the second node is a centralized unit CU in a second IAB-donor node.

24. A communications device, characterized by The apparatus is a first node comprising a processor and a transceiver configured to execute computer programs or instructions stored in at least one memory to enable the apparatus to implement the method of any one of claims 1-10.

25. A communications device, characterized by The apparatus is a second node comprising a processor and a transceiver configured to execute computer programs or instructions stored in at least one memory to enable the apparatus to implement the method of any one of claims 11-21.

26. A computer-readable storage medium, characterized in that, The storage medium stores computer programs or instructions which, when executed by a computer, implement the method of any one of claims 1-10.

27. A computer-readable storage medium, characterized in that, The storage medium stores computer programs or instructions which, when executed by a computer, implement the method of any one of claims 11-21.

28. A computer program product, characterised in that, The computer program product comprises computer program code which, when run on a computer, implements the method of any one of claims 1-10.

29. A computer program product, characterised in that, The computer program product comprises computer program code which, when run on a computer, implements the method of any one of claims 11-21.

Images