RU2803196C1 - Data package transmission method and device - Google Patents

Abstract

FIELD: transmission of data packages.

SUBSTANCE: IAB donor defines the first configuration information, where the first configuration information is used to indicate the first radio link control channel (RLC) of the backhaul (BH), and the first RLC BH is used to transmit a control protocol data unit (PDU) at the backhaul network adaptation protocol layer (BAP). The IAB donor sends the first configuration information to the IAB node. According to the above procedure, the IAB donor indicates, using the first configuration information, the IAB node to send the BAP layer control PDU on the first BH RLC to implement bearer mapping when the IAB node is to send the BAP layer control PDU.

EFFECT: matching of unidirectional channels for data payload in transit communication line.

17 cl, 16 dwg

Description

Field of technology to which the invention relates

This application relates generally to the field of wireless communication technologies and, in particular, to a method and apparatus for transmitting data packets.

State of the art

Integrated access and backhaul (IAB) is being implemented into the 5th generation (5G) mobile communications system. The wireless transmission solution in the IAB network is used for both the access link and the backhaul link, avoiding the deployment of optical fiber to reduce deployment costs and increase deployment flexibility. The IAB network includes an IAB node and an IAB donor. The terminal side device can access the IAB node, and the traffic data of the terminal side device can be transferred from the IAB node to the IAB donor via a wireless backhaul link.

However, existing bearer mapping is mainly performed on the F1 user plane (F1-U) data payload and the F1 control plane (F1-C) data payload that are transferred between the IAB node and the donor node in the F1 interface. In fact, there are other types of payloads that need to be transferred between the IAB node and the donor node, that is, payloads other than the F1 user plane payload and the F1 control plane payload. This payload may be collectively referred to as a non-F1 traffic data payload. How to perform bearer mapping for a non-F1 traffic data packet over a wireless backhaul is not used in traditional technology, and this is a problem that needs to be solved as soon as possible.

The essence of the invention

Implementations of the present application provide a method and apparatus for transmitting data packets to solve the related problem of how to perform bearer mapping for a data payload on a backhaul link.

According to a first aspect, an embodiment of the present application provides a method for transmitting a data packet, including the following steps: an IAB donor determines first configuration information, where the first configuration information is used to indicate a first RLC BH channel, and the first RLC BH channel is used to transmit a layer control PDU. BAP. The IAB donor sends the first configuration information to the IAB node.

According to the above procedure, the IAB donor instructs, using the first configuration information, the IAB node to send a control PDU at the BAP layer through the first RLC channel of the BH to realize bearer mapping when the IAB node needs to send a control PDU at the BAP layer.

In an exemplary implementation, the first configuration information includes a channel identifier of the first RLC channel BH; or

the first configuration information includes a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH.

According to a second aspect, there is provided a method for transmitting a data packet, which includes the following step: the IAB node determines a first RLC channel BH used to transmit a control PDU at the BAP layer. The IAB node sends a BAP-level control PDU to the neighboring IAB node on the first RLC channel of the BH.

According to the above procedure, the IAB donor instructs, using the first configuration information, the IAB node to send a BAP-level control PDU on the first BH RLC channel to realize bearer mapping when the IAB node needs to send a BAP-level control PDU.

In an exemplary implementation, the IAB node determining a first backhaul BH RLC used to transmit a control PDU at the BAP involves the following step: the IAB node receiving first configuration information from the IAB donor, where the first configuration information is used to indicate the first RLC BH channel used to transmit control PDUs at the BAP layer. The IAB node determines the first RLC channel of the BH based on the first configuration information.

In an exemplary implementation, the first configuration information includes a channel identifier of the first RLC channel BH; or the first configuration information includes a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH.

According to a third aspect, there is provided a method for transmitting a data packet, which includes the following step: the IAB donor determines second configuration information, where the second configuration information is used to indicate a second radio link control (RLC) channel of the backhaul link (BH), the second RLC channel of the BH is used for transmitting a first type data payload, and the first type data payload is a data payload different from the F1 user plane data payload (F1-U) and the F1 control plane data payload (F1-C). The IAB donor sends the second configuration information to the IAB node.

According to the above procedure, the IAB donor, using the second configuration information, instructs the IAB node to send a data payload of the first type on the second RLC channel of the BH to realize bearer mapping on the data payload of the first type.

In an exemplary implementation, the first type data payload includes any of the following:

Operation, Administration and Maintenance (OAM) traffic package; packet used to request an Internet Protocol (IP) address; a packet used to establish an Internet Protocol Security (IPsec) data link; Stream Control Transport Protocol (SCTP) association installation package; SCTP Association Disable Packet; and an SCTP association heartbeat packet.

In an exemplary implementation, the second configuration information includes any one or more of the following:

a first type, where the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH; first differentiated service information, where the first differentiated service information corresponds to a first type and/or a second RLC BH channel; and a first stream label, where the first stream label corresponds to a first type and/or second channel of the RLC BH.

In an exemplary implementation, the method further includes the following step: the IAB donor generates a first data payload, where the first data payload is a first type of data payload. If the packet header information corresponding to the first data payload carries the first differentiated service information, the IAB donor sends the first data packet to the IAB node on the second RLC BH channel corresponding to the first differentiated service information; or if the packet header information corresponding to the first data payload includes a first flow label, the IAB donor sends the first data packet to the IAB node on a second RLC BH channel corresponding to the first flow label, where the first data packet includes the first data payload.

In an exemplary implementation, the second configuration information includes identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier corresponding to the second RLC BH channel.

According to a fourth aspect, there is provided a method for transmitting a data packet, which includes the following step: an IAB node receives second configuration information from an IAB donor, where the second configuration information is used to indicate a second radio link control (RLC) channel of a backhaul link (BH), the second channel The RLC BH is used to transmit a first type data payload, and the first type data payload is a data payload different from the F1 user plane data payload (F1-U) and the F1 control plane data payload (F1-C). The IAB node transmits a first type of data payload based on the second configuration information.

According to the above procedure, the IAB node determines, using the second configuration information sent by the IAB donor, that a data payload of the first type is sent on the second RLC channel of the BH in order to implement bearer mapping on the data payload of the first type.

In an exemplary implementation, the first type data payload includes any of the following:

Operation, Administration and Maintenance (OAM) traffic package; packet used to request an Internet Protocol (IP) address; a packet used to establish an Internet Protocol Security (IPsec) data link; Stream Control Transport Protocol (SCTP) association installation package; SCTP Association Disable Packet; and an SCTP association heartbeat packet.

In an exemplary implementation, the second configuration information includes any one or more of the following:

a first type, where the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH; first differentiated service information, where the first differentiated service information corresponds to a first type and/or a second RLC BH channel; and a first stream label, where the first stream label corresponds to a first type and/or second channel of the RLC BH.

In an exemplary implementation, the second configuration information includes identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier corresponding to the second RLC BH channel.

According to a fifth aspect, there is provided a method for transmitting a data packet, which includes the following step: the IAB donor determines a first label based on packet header information corresponding to a third data payload, where the first label is used to determine an output radio link control (RLC) channel of the third payload. data. The IAB donor sends a third data packet to the IAB node, where the third data packet includes a third data payload and a first backhaul adaptation protocol BAP layer header, and the first BAP layer header includes a first label.

According to the above procedure, the IAB donor uses the first label to indicate the output radio link control (RLC) channel of the third data payload, and no longer determines the output RLC channel of the third data payload based only on the input RLC channel of the third data payload, so as to realize flexible transmission of the third payload. data loads.

In a possible implementation, the IAB donor determines the first label based on the packet header information corresponding to the third data payload includes:

The IAB donor receives the third configuration information. The IAB donor determines the first label based on the packet header information corresponding to the third data payload and the third configuration information, where the third configuration information is used to configure a mapping between the first information in the packet header information and the first label, and the first information includes any one or several of the following:

first differentiated service information, a first flow label, and a first Internet Protocol address (IP address).

According to a sixth aspect, there is provided a method for transmitting a data packet that includes the following step: a second IAB node receives a fourth data payload. The second IAB node determines a second label based on packet header information corresponding to the fourth data payload or a message type corresponding to the fourth data payload, where the second label is used to determine an output radio link control (RLC) channel of the fourth data payload. The second IAB node sends a fourth data packet to the first IAB node, where the fourth data packet includes a fourth data payload and a second backhaul adaptation protocol BAP layer header, and the second BAP layer header includes a second label.

In an exemplary implementation, the second IAB node determines a second label based on packet header information corresponding to the fourth data payload includes:

The second IAB node receives the fourth configuration information from the IAB donor.

The second IAB node determines the second label based on the packet header information corresponding to the fourth data payload and the fourth configuration information.

The fourth configuration information is used to configure a mapping between the second information in the packet header information and the second label, and the second information includes any one or more of the following:

second differentiated service information in the packet header information, a second flow label in the packet header information, a second IP address in the packet header information, radio bearer information which is in the packet header information and which corresponds to the fourth data payload, a second type of fourth payload data payloads and the flow identifier at the SCTP layer that carries the F1AP message when the fourth data payload is an F1AP message.

In an exemplary implementation, the second IAB node determines a second label based on the message type corresponding to the fourth data payload includes:

The second IAB node receives the fourth configuration information from the IAB donor.

The second IAB node determines a second label from the fourth configuration information based on the message type corresponding to the fourth data payload.

The fourth data payload is a control plane F1 application protocol message F1AP, and the fourth configuration information includes one or more of the following:

a second type of a fourth data payload and a second label corresponding to the second type, where the second type is any one or more F1AP message types:

an SCTP layer identifier for the flow that carries the F1AP message when the fourth data payload is an F1AP message, and a second label corresponding to the flow identifier.

According to a seventh aspect, there is provided a method for transmitting a data packet, which includes:

The first Integrated Access and Backhaul Node (IAB) receives a data packet, where the data packet is a data packet received from a second IAB node or a data packet received from an IAB donor, the backhaul adaptation protocol BAP layer header of the data packet includes a third label , and the third label is used to determine the output radio link control (RLC) channel of the data packet.

The first IAB node determines the third RLC channel identifier based on the third label, where the third RLC channel identifier is the output RLC channel identifier of the data packet.

The first IAB node sends a data packet on an output RLC channel corresponding to the third RLC channel identifier.

In an exemplary implementation, the determination, by the first IAB node, of the third RLC channel identifier based on the third label includes:

The first IAB node receives fifth configuration information from the IAB donor, where the fifth configuration information is used to configure a mapping between the third label and the third RLC channel identifier.

The first IAB node determines, as the third RLC channel identifier, the RLC channel identifier which is in the fifth configuration information and which corresponds to the third label.

Alternatively, the first IAB node determines, as the third RLC channel identifier, the RLC channel identifier which is in the fifth configuration information and which corresponds to the third label, and the fourth RLC channel identifier, where the fourth RLC channel identifier is the identifier of the input RLC channel for receiving the data packet. .

Alternatively, the first IAB node determines, from the fifth configuration information, a first quality of service (QoS) identifier corresponding to the third label, and determines, as a third RLC channel identifier, an RLC channel identifier which is in the fifth configuration information and which corresponds to the first QoS ID.

Alternatively, the first IAB node determines, from the fifth configuration information, a first QoS parameter corresponding to the third label, and determines, as a third RLC channel identifier, an RLC channel identifier contained in the fifth configuration information and which corresponds to the first QoS parameter.

In an exemplary implementation, the fifth configuration information includes any one or more of the following:

correspondence between the third label and the third RLC channel identifier;

a correspondence between the third label, the fourth RLC channel identifier and the third RLC channel identifier;

correspondence between the third label and the quality of service (QoS) identifier;

correspondence between the QoS identifier and the RLC third channel identifier;

correspondence between the third label and the QoS parameter; And

correspondence between the QoS parameter and the third RLC channel identifier.

According to an eighth aspect, the present application further provides a communication device. The communication device has the function of implementing any method provided in any of the previous aspects. The communication device may be implemented in hardware or may be implemented in hardware executing corresponding software. The hardware or software includes one or more blocks corresponding to the above function.

In an exemplary implementation, the communication device includes a processor, and the processor is configured to support the communication device in performing the respective functions of a first IAB node, a second IAB node, an IAB donor, or an IAB node in the above method. The communication device may further include a memory, and the memory may be coupled to the processor and may store program instructions and data that are needed by the communication device. Optionally, the communication device further includes a communication interface, and the communication interface is configured to support communication between the communication device and a device such as a first IAB node, a second IAB node, an IAB donor, or an IAB node.

In a possible implementation, the communication device includes corresponding functional blocks configured to implement the steps of the above method. The function may be implemented in hardware or may be implemented in hardware executing associated software. The hardware or software includes one or more blocks corresponding to the above function.

In a possible implementation, the structure of the communication device includes a processing unit and a communication unit. These blocks can perform corresponding functions in the above example methods. For more detailed information, please refer to the description of the method according to any of the previous aspects. The details are not repeated in this document.

According to a ninth aspect, the present application provides a communication device including a processor and a memory. The memory is configured to store computer-executable instructions, and when the device is operated, the processor executes the computer-executable instructions stored in the memory, such that the device performs the methods described in the previous aspects.

According to a tenth aspect, the present application provides a communication device including a unit or means configured to perform the steps described in the previous aspects.

According to an eleventh aspect, the present application provides a communication device including a processor and a communication interface. The processor is configured to: maintain communication with another device through a communication interface and perform the methods described in the previous aspects. There are one or more processors.

According to a twelfth aspect, the present application provides a communication device including a processor configured to: connect to at least one memory and call a program stored in the at least one memory to perform the methods described in the previous aspects. The at least one memory may be located inside the device or may be located outside the device. In addition, there are one or more processors.

According to a thirteenth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores instructions, and when the instructions are executed on a computer, the computer can perform the methods described in the previous aspects.

According to a fourteenth aspect, the present application further provides a computer program product including instructions, and when the computer program product is run on a computer, the computer can perform the methods described in the previous aspects.

According to a fifteenth aspect, the present application further provides a system on a chip including a processor configured to perform the methods described in the previous aspects.

According to a sixteenth aspect, the present application further provides a system-on-chip including a first IAB node, a second IAB node, and an IAB donor as presented above.

Brief description of drawings

FIG. 1 is a schematic representation of a communication system to which an embodiment of the present application is applicable; FIG.

FIG. 2 is a schematic representation of the structure of an IAB donor according to an embodiment of the present application; FIG.

FIG. 3(a) and FIG. 3(b) are schematic representations of the correspondence between an RLC channel, a logical channel and a protocol entity according to an embodiment of the present application;

FIG. 4 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application;

FIG. 5 is a flowchart of a method for transmitting data packets according to an embodiment of the present application;

FIG. 6 is a schematic diagram of the structure of a data packet according to an embodiment of the present application;

FIG. 7 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a data packet structure according to an embodiment of the present application; FIG.

FIG. 9 is a schematic diagram of a data packet structure according to an embodiment of the present application; FIG.

FIG. 10 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application;

FIG. 11 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application; FIG.

FIG. 12 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application;

FIG. 13 is a schematic diagram of a network architecture in online mode according to an embodiment of the present application; FIG.

FIG. 14 is a schematic diagram of the structure of a communication device according to an embodiment of the present application; FIG. And

FIG. 15 is a schematic diagram of the structure of a communication device according to an embodiment of the present application.

Detailed Description of the Invention

Embodiments of the present application will now be described in detail with reference to the accompanying drawings.

Embodiments of the present application can be applied to various mobile communication systems, for example, new radio (NR), long term evolution (LTE), long term evolution-advanced (LTE). A), evolved long term evolution (eLTE), future communication system and other communication system. In particular, these examples are not intended to be limiting herein.

In embodiments of the present application, the terminal-side device is a device having a wireless transceiver function, or a chip that may be located in the device. A device having a wireless transceiver function may also be referred to as a user equipment (UE), access terminal, subscriber unit, subscriber station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent, or user device. In embodiments of the present application, in a real application, the device on the terminal side may be a mobile phone (mobile phone), a tablet computer (Pad), a computer having a wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (augmented reality) terminal , AR), wireless terminal in industrial control system, wireless terminal in self-drive system, wireless terminal in remote medical system, wireless terminal in smart grid, wireless terminal in the transport safety system, wireless terminal in the smart city system, wireless terminal in the smart home system, etc. The application scenario is not limited to embodiments of the present application. In this application, a device having a wireless transceiver function and a chip that may be housed in the device are collectively referred to as a terminal device.

In embodiments of the present application, the network device may be a radio access device operating using various standards, for example, an evolved NodeB (eNB), a radio network controller (RNC), a NodeB (NB), a basic base station controller (BSC), base transceiver station (BTS), home base station (for example, home evolved NodeB or home NodeB (HNB)), baseband unit ( baseband unit, BBU), access point (AP) in a Wi-Fi wireless communication system (Wireless Fidelity, Wi-Fi), wireless relay node, wireless transit node, transmission point (TP) or transceiver transmission reception point (TRP). The network device can alternatively be a gNB or transmission point (TRP or TP) in a 5G (NR) system, one or a group of antenna panels (including multiple antenna panels) of a base station in a 5G system, a network node , which forms a gNB or transmission point, such as a baseband unit (BBU), DU or CU in a central unit-distributed unit (CU-DU) system or the like.

In embodiments of the present application, an IAB scenario in a wireless communication network is used as an example to describe some scenarios. It should be noted that the solutions presented in the embodiments of the present application may be further applied to another wireless communication network, and the corresponding name may also be replaced by the name of the corresponding function in another wireless communication network.

For ease of understanding the embodiments of the present application, the communication system shown in FIG. 1 is first used as an example to describe in detail the communication system to which the embodiments of the present application are applicable. FIG. 1 is a schematic diagram of a communication system to which an embodiment of the present application is applicable. As shown in FIG. 1, the communication system includes a base station, an IAB donor, an IAB node 1, an IAB node 2, and a terminal-side device.

In this embodiment of the present application, a node that supports integrated access and backhaul is referred to as an IAB node, and the IAB node may also be referred to as a relay node (RN). For ease of description, both the node and the relay node are referred to as the IAB node in the following. The IAB node may provide a wireless access service to a terminal-side device, and traffic data or control information of the terminal-side device is transmitted from the IAB node to an IAB donor or other network device via a wireless backhaul link. The IAB node may include at least one mobile terminal (MT) and at least one distributed unit (DU). In this embodiment of the present application, only an example in which the IAB includes one MT and one DU is used for description. The MT block in the IAB node implements that the IAB node serves as a terminal for communication with the parent node of the IAB node and the donor IAB. The DU in the IAB node provides access service to a terminal device or other IAB node connected to the DU, and can also communicate with the IAB donor via the F1 interface. The MT in the IAB node may also be referred to as the MT functional entity in the IAB node, and the DU in the IAB node may also be referred to as the DU functional entity in the IAB node. For ease of description, both the MT at an IAB node and the MT functional object at an IAB node are briefly referred to as "IAB Node MT", and both the DU at an IAB node and the DU functional object at an IAB node are briefly referred to as "IAB Node DU".

In this embodiment of the present application, the donor IAB may be an access network element having the full function of a base station, or may be an access network element in the form in which a centralized unit (CU) and a distributed unit (DU) are separated. For details, see figure 2. In FIG. 2, the IAB donor CU may alternatively be in a form in which the control plane (CP) and the user plane (UP) are separated. For example, one IAB donor CU includes one CU-CP and multiple CU-UPs. This is not limited to this embodiment of the present application.

The CU in the IAB donor may also be referred to as the CU functional entity in the IAB donor, and the DU in the IAB donor may also be referred to as the DU functional entity in the IAB donor. For ease of description, in this embodiment of the present application, the CU in the IAB donor and the functional entity CU in the IAB donor are briefly referred to as the IAB donor CU, and the DU in the IAB donor and the functional entity DU in the IAB donor are briefly referred to as the IAB donor DU.

In addition to this, FIG. 1 further shows the names of the interfaces between the devices. For example, the Uu NR interface is between the terminal side device and IAB Node 1, and the Un NR interface is between IAB Node 2 and the IAB donor. The interface names are merely examples and do not represent restrictions on the interface. When the communication system version changes, the corresponding name may also be replaced by the corresponding function name in another wireless network. In addition to this, when the base station is a base station in 5G, the interface between the IAB donor and the base station may be an Xn interface. When the base station is a base station in LTE, the interface between the IAB donor and the base station may be the X2 interface.

The IAB network shown in FIG. 1 supports multi-hop networking. For example, an intermediate IAB node (ie, IAB node 2) is located between IAB node 1 and the IAB donor shown in FIG. 1. In another possible network scenario, IAB Node 1 could also be directly connected to the IAB donor with no other intermediate IAB nodes, or there could be more than one intermediate IAB node between IAB Node 1 and the IAB donor.

The IAB network shown in FIG. 1 supports both multi-hop networking and multi-connection networking. At least one transmission path including multiple communication links may exist between the terminal-side device served by the IAB node and the donor IAB. One or more transmission paths may also be between an IAB node and an IAB donor, and each transmission path may include one or more IAB nodes. In the transmission path, each IAB node considers the neighboring node that provides transport service to the IAB node as a parent node, and accordingly, each IAB node can be considered as a child node of the parent node of the IAB node. For example, in the scenario shown in FIG. 1, the parent node of IAB node 2 is the IAB donor, and the IAB donor considers IAB node 2 as a child node.

In another possible Non-standalone multi-connectivity networking scenario, a terminal-side device served by an IAB node may establish a connection to the IAB node, and may also be directly connected to a base station (evolved Node B (eNB) in the LTE network ) via the Uu interface in LTE. Similarly, an IAB node can be connected to a base station via the Uu interface in LTE, and can also be connected to an IAB donor via a single-hop or multi-hop NR wireless backhaul. The IAB donor and the base station are connected via the X2 interface.

In this embodiment of the present application, certain technical terms may be used, for example, previous hop node, next hop node, ingress link of a node, and egress link of a node. In the following, these technical terms will be explained first.

Previous node hop node: The node's previous hop node is the last node that is on the path that includes the node and that receives a data packet before the node.

Next node hop node: The next node hop node is the 1st a node that is on a path that includes the node and that receives the data packet after the node.

Input node link: The input link of a node is the link between a node and the node of the previous hop of the node and can also be referred to as the previous hop link of the node.

Node output link: A node output link is a communication link between a node and a node's next-hop node, and may also be referred to as a node's next-hop link.

Parent Node and Child Node: Each IAB node considers the node that provides wireless access service and/or wireless backhaul service to the IAB node as a parent node. Accordingly, each IAB node can be considered a child node of the parent node of the IAB node. Alternatively, a child node can also be called a lower-level node, and a parent node can also be called a top-level node.

F1 Interface: The F1 interface in this embodiment of the present application is the interface between the IAB node DU and the IAB donor or the IAB donor CU. The F1 interface may also be referred to as the F1* interface. For ease of description, in this embodiment of the present application, the interfaces may be collectively referred to as the F1 interface, but this name is not limiting.

It should be noted that the F1 interface can also be an interface between functional objects in a device. For example, for a base station including a DU and a CU, interface F1 may be an interface between the DU in the base station and the CU in the base station.

In this embodiment of the present application, the F1 interface supports the user plane protocol and the control plane protocol. For example, the user plane protocol layer of the F1 interface includes the General Packet Radio Service (GPRS), the GPRS Tunneling Protocol User Plane (GTP-U), the user datagram protocol layer ( protocol, UDP) and the Internet protocol (IP) layer. If necessary, the user plane protocol layer of the F1 interface additionally includes a PDCP layer and/or an IP security layer (IP Security, IPsec).

For example, the control plane protocol layer of the F1 interface includes the F1 application protocol (F1AP) layer, the stream control transport protocol (SCTP) layer, and the IP layer. Optionally, the control plane protocol layer of the F1 interface additionally includes one or more PDCP layers, an IPsec layer, and a datagram transport layer security (DTLS).

In addition, it should be understood that in this embodiment of the present application, although the terms “first”, “second”, “third”, etc. may be added before terms to describe various messages and information, for example, first configuration information, second configuration information and third configuration information, the terms “first”, “second”, “third”, and the like. are used only to distinguish messages, information, etc., and do not imply that messages, information, etc. limited by this.

FIG. 1, FIG. 3(a), and FIG. 3(b) show schematic representations of the correspondence between an RLC channel, a logical channel (LCH), and a protocol entity. As shown in FIG. 3(a) and FIG. 3(b), a radio link control (RLC) channel is a channel between an RLC entity and an upper layer protocol entity of the RLC entity. For example, if the top layer of the RLC entity is a PDCP entity, the RLC channel on the backhaul link is the channel between the RLC entity and the PDCP entity. As another example, if the top layer of the RLC entity is a Backhaul Adaptation Protocol (BAP) entity, the RLC channel on the backhaul link is the channel between the RLC entity and the BAP entity. Thus, the RLC channel is specifically defined by the RLC entity's upper layer protocol entity.

A logical channel is a channel between an RLC entity and a lower layer protocol entity of the RLC entity. For example, if the lower layer of the RLC entity is the MAC layer, the logical channel is the channel between the RLC entity and the MAC entity.

The RLC channel of the IAB node uniquely corresponds to the RLC object, and also uniquely corresponds to the RLC bearer.

For the relationship between a BAP entity and an RLC entity, as shown in FIG. 3(a), one BAP entity may correspond to multiple RLC entities, or, as shown in FIG. 3(b), one BAP entity may correspond to one RLC entity. In the present application, this case is not a limitation.

In addition, the BAP layer has one or more of the following capabilities: adding routing information to the data packet, which can be identified by the IAB node; performing routing selection based on routing information that can be identified by the wireless transit node; adding to the data packet identification information that can be identified by the wireless transit node and that is associated with a quality of service (QoS) requirement; performing QoS mapping on a data packet over multiple links, including a wireless backhaul; adding data packet type indicator information to the data packet; and sending the flow control feedback information to the node having the flow control capability. It should be noted that the name of the protocol layer that has these capabilities is not necessarily the BAP layer or may have a different name. One skilled in the art will appreciate that any protocol layer having these capabilities can be considered a BAP layer in embodiments of the present application. The RLC channel on the BH link can be considered as a traffic differentiation channel on the BH link between two nodes, and the service differentiation channel can provide a certain Quality of Service (QoS) guarantee for the transmission of data packets. The RLC channel on the BH link can be considered as a logical channel rather than a physical channel.

In this embodiment of the present application, the BH RLC channel, that is, the BH link RLC channel, can be considered as a traffic differentiation channel on the BH link between two nodes. A traffic differentiation channel can provide some quality of service (QoS) guarantee for the transmission of data packets. The RLC channel on the BH link can be considered as a logical channel rather than a physical channel.

In particular, the RLC channel on the BH link can be considered as the peer RLC channels of two neighboring nodes that are connected via the BH link. For example, in FIG. 1, the IAB donor DU has an RLC channel 1 and an RLC channel 2, and the IAB node 1 has an RLC channel 1 and an RLC channel 2. The IAB donor RLC DU channel 1 is the IAB node 1 RLC peer 1, and the IAB donor DU RLC channel 2 is the IAB node 1 RLC peer 2. RLC channel 1 on the BH link between IAB donor DU and IAB node 1 may be IAB donor DU RLC channel 1 and IAB node 1 RLC channel 1, and RLC channel 2 on the BH link between IAB donor DU and IAB node 1 may be IAB donor DU RLC channel 2 and IAB node 1 RLC channel 2.

Since RLC channels, RLC bearers and logical channels are in a one-to-one correspondence, in this embodiment of the present application, the three descriptions can replace each other. For example, in this embodiment of the present application, the RLC channel may be replaced by an RLC bearer or a logical channel. Likewise, the RLC channel on the BH link may be replaced by a unidirectional RLC channel on the BH link or a logical channel on the BH link. An RLC bearer on a BH link may also be called a BH bearer or a BH link bearer.

It should be noted that the RLC channel used when a node receives a data packet may also be referred to as an ingress RLC channel, and the RLC channel used when sending a data packet is referred to as an egress RLC channel.

Referring to the previous description, in an IAB network, the payload transmitted between the IAB node and the donor node may include an F1 traffic payload and a non-F1 traffic payload. The F1 traffic data payload includes an F1 user plane data payload (F1-U) or an F1 control plane data payload (F1-C). The non-F1 traffic data payload may include payloads other than F1 user plane payload and F1 control plane payload. In embodiments of the present application, this payload is collectively referred to as a Type 1 payload.

Currently, non-F1 traffic payloads can come in many forms. For example, a non-F1 traffic data payload may include a BAP layer control Protocol Data Unit (PDU), an Operation, Administration, and Maintenance (OAM) traffic data packet. IAB node (which in a particular implementation may be an IAB node DU) sent when a stream control transport protocol (SCTP) association is established between an IAB node (which in a particular implementation may be an IAB node DU) and the IAB donor or when maintaining a stream control transport protocol (SCTP) association, and a data packet involved in establishing an Internet Protocol Security (IPsec) data link between the IAB node (which in a particular implementation may be the node's DU IAB) and donor IAB. How to perform bearer mapping for non-F1 traffic data payload on a wireless backhaul is not considered in the traditional technology. An embodiment of the present application provides a method for performing bearer matching of non-F1 traffic data payloads over a wireless backhaul link. A description of this embodiment is presented below.

Embodiment 1

The BAP layer control PDU is transmitted between the IAB node and the IAB donor. The control PDU at the BAP layer can be considered as a non-F1 traffic data packet, and the data payload carried in the control PDU is a data payload different from the F1 user plane data payload and the F1 control plane data payload.

In this embodiment of the present application, a control PDU at the BAP layer exchanges data between two neighboring nodes. For example, a child node sends a control PDU to a parent node, or a parent node sends a control PDU to a child node. A child node may be an IAB node, and a parent node may be another IAB node, or a parent node may be an IAB donor (which in a particular implementation may be an IAB donor DU). The BAP level control PDU may include incremental control information, such as including feedback information used for flow control, or including a notification that the wireless backhaul link is faulty, which is sent by the parent node to the child node . A wireless backhaul failure may be a radio link failure (RLF), a blockage or congestion of the wireless backhaul, or there may be a connection associated with the wireless backhaul that cannot be restored and etc. This BAP level control PDU does not need to be encapsulated in an IP packet.

With reference to the previous description, FIG. 4 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. See figure 4. The method includes the following steps.

Step 401: The IAB donor determines first configuration information.

The first configuration information is used to indicate the first RLC channel of the BH, and the first RLC channel of the BH is used to transmit a control PDU at the BAP layer.

Step 402: The IAB donor sends the first configuration information to the IAB node.

In this embodiment of the present application, the IAB donor may send the first configuration information using a control plane message such as an F1AP message or an RRC message. Alternatively, the IAB donor (which in a particular implementation may be an IAB donor DU or an IAB donor CU) may obtain the first configuration information from the IAB node OAM, and then send the first configuration information to the IAB node.

It should be noted that if the IAB node has a parent node, the IAB donor can also send the first configuration information to the parent IAB node. The specific process may be the same as the process of sending the first configuration information to the IAB node. The details are not repeated in this document.

For example, if the IAB donor includes a CU and a DU, steps 401 and 402 may be performed by the IAB donor CU. If the IAB donor includes a CU and a DU, the IAB donor CU may further configure first configuration information for the IAB donor DU.

For example, if the IAB donor CU includes a CP and a UP, steps 401 and 402 may be performed by the IAB donor CU-CP.

Step 403: The IAB node receives first configuration information from the IAB donor.

Step 404: The IAB node determines, based on the first configuration information, a first RLC BH channel used to transmit a control PDU at the BAP layer.

Step 405: The IAB node sends a BAP level control PDU to the neighboring IAB node on the first RLC channel of the BH.

An adjacent node of an IAB node may be, for example, a parent node (the parent node may be another IAB node or an IAB donor (which in a particular implementation may be an IAB donor DU in which the IAB donor is in an architecture in which the CU and DU are separate)) of the node IAB or a child node of the IAB node.

It should be noted that steps 401-403 and steps 404 and 405 may be two independent procedures. Steps 401-403 may be performed before step 404. After executing step 403, the IAB node may perform step 404 and step 405 based on the actual situation in determining whether to send a control PDU at the BAP layer.

According to the above procedure, the IAB donor instructs, using the first configuration information, the IAB node to send a control PDU at the BAP layer on the first RLC channel of the BH to realize bearer mapping when the IAB node needs to send a control PDU at the BAP layer.

In this embodiment of the present application, there may be multiple implementations of the first configuration information. In an exemplary implementation, the first configuration information may include a channel identifier of the first RLC BH channel. In this case, when sending the BAP-layer control PDU, the IAB node may send the BAP-layer control PDU on the first RLC BH channel corresponding to the channel identifier that belongs to the first RLC BH channel and which is in the first configuration information.

In another possible implementation, the first configuration information may include a logical channel identifier (LCID), and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH. In this case, when sending the BAP-level control PDU, the IAB node determines the first BH RLC channel using the logical channel identifier in the first configuration information, and sends the BAP-level control PDU on the first BH RLC channel.

For example, the IAB donor (which in a particular implementation may be the IAB donor DU) may also send a BAP-level control PDU to the IAB node. In this case, the IAB donor DU may also send a control PDU at the BAP layer based on the first RLC channel of the BH specified in the first configuration information. For more information, refer to the description of sending control PDUs at the BAP level by the IAB. The details are not repeated in this document.

In this embodiment of the present application, in another possible embodiment, the IAB donor may not send the first configuration information. In this case, the first RLC BH channel may be negotiated in advance, for example, the channel identifier of the first RLC BH channel or the first logical channel identifier is specified in the protocol. The first RLC BH channel corresponding to a given channel identifier of the first RLC BH channel or a given first logical channel identifier is used to send a control PDU at the BAP layer. In this case, the IAB node may determine the first RLC BH based on the channel ID of the first RLC BH negotiated in advance or the first logical channel ID and send a BAP control PDU on the first RLC BH. Accordingly, the IAB donor (which in a particular implementation may be the IAB donor DU) can also determine the first RLC BH channel based on the channel identifier of the first RLC BH channel that is agreed upon in advance, or the first logical channel identifier, and send a BAP control PDU on the first channel RLC BH.

In yet another possible implementation, the IAB donor does not send the first configuration information. When the first node needs to send a BAP-level control PDU to a second node, the first node determines, based on the information carried in the BAP-level control PDU, an RLC channel BH used to transmit the BAP-level control PDU. The first node and the second node are directly connected through one backhaul link. For example, the first node is an IAB node, the second node is the parent node of the first node, the BAP layer control PDU generated by the first node carries buffer state information corresponding to the first RLC BH channel, and the first RLC BH channel is the RLC BH channel corresponding to the line connection between the first node and the second node. In this case, the first node sends a BAP-level control PDU to the second node over the first RLC BH channel. In another example, the first node is an IAB node, the second node is the parent node of the first node, and the BAP layer control PDU generated by the first node carries buffer state information corresponding to the first RLC BH channel and buffer state information corresponding to the other RLC BH channel. However, the first RLC BH channel has a higher priority than the other RLC BH channel, and each of the first RLC BH channel and the other RLC BH channel is an RLC BH channel corresponding to a communication link between the first node and the second node. In this case, the first node sends a BAP-level control PDU to the second node over the first RLC BH channel.

The above is a description of how to transmit control PDUs at the BAP layer. Next, how to transmit another non-F1 traffic data payload will be described.

Option 2

FIG. 5 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. See figure 5. The method includes the following steps.

Step 501: The IAB donor determines second configuration information.

The second configuration information is used to indicate a second RLC BH channel, the second RLC BH channel is used to transmit a first type data payload, and the first type data payload is a data payload different from the F1-U data payload and the F1 control plane data payload (F1-C).

Step 502: The IAB donor sends the second configuration information to the IAB node.

In this embodiment of the present application, the IAB donor may send the second configuration information using a control plane message such as an F1AP message or an RRC message. Alternatively, the IAB donor may receive the second configuration information from the IAB node OAM, and then send the second configuration information to the IAB node.

Optionally, if the IAB node has a parent node, the IAB donor can also send second configuration information to the parent IAB node. The specific process may be the same as the process of sending the second configuration information to the IAB node. The details are not repeated in this document.

For example, if the IAB donor includes a CU and a DU, steps 501 and 502 may be performed by the IAB donor CU. If the IAB donor includes a CU and a DU, the IAB donor CU may further configure second configuration information for the IAB donor DU. Alternatively, the IAB donor DU may obtain the second configuration information using OAM.

For example, if the IAB donor CU includes a CP and a UP, steps 501 and 502 may be performed by the IAB donor CU-CP.

Step 503: The IAB node receives second configuration information from the IAB donor.

Step 504: The IAB node transmits a first type of data payload based on the second configuration information.

According to the above procedure, the IAB donor instructs, using the second configuration information, the IAB node to send on the second RLC channel BH a data payload other than the F1 user plane data payload (F1-U) and the F1 control plane data payload (F1-C) to perform bearer mapping to non-F1 traffic data payload.

In this embodiment of the present application, the second configuration information includes identification information used to identify the second RLC BH channel, and the identification information may be a channel identifier of the second RLC BH channel or a logical channel identifier corresponding to the second RLC BH channel. The second configuration information may further include any one or more of the following:

a first type, where the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH;

first differentiated service information, where the first differentiated service information corresponds to a first type and/or a second RLC BH channel; And

a first flow label, where the first flow label corresponds to the first type and/or second channel of the RLC BH.

It should be noted that the differentiated service information may be a differentiated services code point (DSCP), a type of service (ToS) in the Internet Protocol Version 4 (IPv4) packet header, a field traffic class in the Internet Protocol Version 6 (IPv6) packet header, the first six bits of the traffic class field in the IPv6 packet header, etc. Flow label also refers to the flow label field found in the IPv6 packet header.

In this implementation, the first type data payload includes any one or more of the following:

IAB node OAM traffic packet;

packet used to request an IP address, such as a Dynamic Host Configuration Protocol (DHCP) packet such as a DHCP discover packet or a DHCP offer packet, a Dynamic Host Configuration Protocol (DHCP) packet for an IPv6 packet Host Configuration Protocol for IPv6, DHCPv6), such as a DHCPv6 Solicit packet or a DHCPv6 Advertise packet, an IPv6-based Router Solicitation packet, or an IPv6-based Router Advertisement packet;

packet used to establish an IPsec transmission channel; And

SCTP Association Service Packet. An SCTP Association Service Packet is an SCTP layer message that does not include a data chunk, and the data chunk refers to a data packet in the SCTP layer upper protocol layer. For example, an SCTP Association Service Packet includes, but is not limited to, packets such as an SCTP Association Setup Data Packet, an SCTP Association Disable Data Packet, and an SCTP Association Healthy Data Packet.

In this implementation, in the downlink direction, when the IAB donor sends the first data payload to the IAB node, the first data payload is a first type data payload. In this case, the IAB donor (which in a particular implementation may be an IAB donor DU, an IAB donor CU, an IAB donor CU-CP, or an IAB donor CU-UP) may use the packet header information corresponding to the first data payload to carry the first differentiated service information, or first stream label. The packet header information may be an IP packet header.

The IAB donor (which in a particular implementation may be the IAB donor DU) may send the first data packet to the IAB node on the second RLC BH channel corresponding to the first differentiated service information, send the first data packet to the IAB node on the second RLC BH channel corresponding to the first flow label , or send the first data packet to the IAB node on a second RLC BH channel corresponding to the first type, where the first data packet includes a first data payload.

For example, with reference to the previous description, as shown in FIG. 6, the first data packet includes a first data payload and packet header information, and the first data packet may further include other information. The details are not described in this document. As described above, the first data payload may be an OAM traffic packet, a packet used to request an IP address, or the like. The packet header information may be an IP packet header. After receiving the first data payload, the IAB donor adds the corresponding packet header information to the first data payload to obtain the first data packet.

In this implementation, in the uplink direction, when the IAB node sends the first data payload, the first data payload is a first type data payload. In this case, the IAB node may use the packet header information corresponding to the first data payload to carry the first differentiated service information or the first flow label. The IAB node may send the first data packet to the next hop node of the IAB node on the second RLC BH channel corresponding to the first differentiated service information, or send the first data packet to the next hop node of the IAB node on the second RLC BH channel corresponding to the first flow label, where the first packet data includes a first data payload and packet header information corresponding to the first data payload. Alternatively, in the uplink direction, when the IAB node sends the first data payload, the first data payload is a first data payload type. In this case, the IAB node may send the first data packet to the next hop node of the IAB node on a second RLC BH channel corresponding to the first type, where the first data packet includes a first data payload. The next hop node of an IAB node is the parent node of the IAB node and can be specifically an IAB donor (eg, an IAB donor DU) or another IAB node.

In this embodiment of the present application, in another possible implementation, the IAB donor may not send the second configuration information. In this case, in a possible implementation, the second RLC BH channel may be negotiated in advance, for example, the channel identifier of the second RLC BH channel or the second logical channel identifier is specified in the protocol. A second RLC BH channel corresponding to the specified channel identifier of the second RLC BH channel or the specified second logical channel identifier is used to send a data payload of the first type. In this case, the IAB node may determine the second RLC BH based on the channel identifier of the second RLC BH that is agreed upon in advance, or the second logical channel identifier, and send a data packet whose data payload type is the first type on the second RLC BH. Accordingly, the IAB donor (which in a particular implementation may be, for example, the IAB donor DU) can also determine the second RLC BH based on the channel identifier of the second RLC BH that is agreed upon in advance, or the second logical channel identifier, and send a data packet whose type The data payload is the first type, on the second RLC BH channel. For example, the default channel identifier of the second RLC BH channel is specified in the protocol, and the RLC BH channel specified by the channel identifier is the default RLC BH channel and can be used to transmit a data payload of the first type.

In another possible implementation, in addition to the channel identifier of the second RLC BH channel or the second logical channel identifier, one or more of the following may be specified (eg, specified in a protocol): a first type, a first differentiated service information, a mapping between the first type and the first differentiated service information, a correspondence between the first differentiated service information, a second RLC BH channel and a first flow label, a correspondence between the first type and a first flow label, and a correspondence between the first flow label and a second RLC BH channel.

In this implementation, for uplink transmission, when the IAB node determines to send a first type data payload, the IAB node uses the packet header information corresponding to the first type data payload to carry the specified first differentiated service information or the specified first flow label and sends a first type data payload on a second RLC BH channel corresponding to a given first differentiated service information or a given first flow label. Alternatively, when determining to send a data payload of the first type, the IAB node sends the data payload of the first type on a second RLC BH channel corresponding to the first type. For downlink transmission, when the IAB donor determines to send a data payload of the first type, the IAB donor (which in a particular implementation may be an IAB donor CU, an IAB donor CU-UP, or an IAB donor CU-CP) uses packet header information corresponding to the payload. a first type data payload to carry a given first differentiated service information or a given first flow label, and an IAB donor (which in a particular implementation may be an IAB donor DU) sends a first type data payload on a second RLC channel BH corresponding to the specified first differentiated service information or given first stream label. Alternatively, when determining to send a data payload of the first type, the IAB donor sends the data payload of the first type on a second RLC BH channel corresponding to the first type.

In another possible implementation, the 5-tuple IP information, the correspondence between the 5-tuple IP information and the first differentiated service information, and the correspondence between the first differentiated service information and the second RLC BH channel may be specified, or the 5-tuple IP information may be specified. , the correspondence between the 5-tuple IP information and the first flow label and the correspondence between the first flow label and the second RLC BH channel. The IP 5-tuple information includes at least one of the following: source IP address, destination IP address, source port number, destination port number, and transport layer protocol type.

In this implementation, for uplink transmission, after determining that the IP 5-tuple information corresponding to the sent data payload is the specified IP 5-tuple information, the IAB node uses the packet header information corresponding to the data payload. for carrying a given first differentiated service information or a given first flow label, and sends a data payload on a second RLC channel BH corresponding to the given first differentiated service information or a given first flow label. For downlink transmission, the IAB donor also sends a data payload in the same way. The details are not repeated in this document.

What has been described above is how to transmit non-F1 traffic payloads such as the BAP layer control PDU and the packet used to establish an SCTP association. The following is a description of how to transmit the F1 traffic data payload. It should be noted that each data payload in embodiments 3 to 6 is an F1 user plane data payload (F1-U) or an F1 control plane data payload (F1-C), unless otherwise specified.

In the IAB network shown in FIG. 1, IAB node 1 is an IAB node that provides access service for a terminal-side device, and IAB node 2 is an intermediate IAB node. It should be noted that the IAB node can be used either as an intermediate IAB node or as an access IAB node. For example, IAB Node 2 may be used as an intermediate node between IAB Node 1 and the donor IAB, but for a terminal-side device that accesses a cell served by IAB Node 1, IAB Node 2 is used as the access IAB node.

On the wireless backhaul link between IAB Node 2 and IAB Node 1, and on the wireless backhaul link between IAB Node 2 and the IAB donor (which in a particular implementation may be an IAB donor DU), one or more backhaul RLC links BH) are set based on the IAB donor configuration. When sending a data packet over the backhaul, the IAB node or IAB donor (which in a particular implementation may be the IAB donor DU) must perform bearer mapping. For example, bearer mapping must first be performed by the IAB donor (in a particular implementation, the IAB donor DU may be performed) for a data packet that is transmitted on the downlink. More specifically, the correct RLC BH channel is selected from the RLC BH channels on the link between the IAB node 2 and the donor IAB to send the data packet. After receiving, from the IAB donor, a data packet to be sent to IAB Node 1, IAB Node 2 must also select the correct RLC BH channel from the RLC BH channels on the link between IAB Node 1 and IAB Node 2 to send the data packet.

Likewise, for a data packet that is sent on the uplink, for example, bearer mapping must also be performed by IAB Node 1 for the uplink data packet sent by IAB Node 1. More specifically, the RLC BH channel is selected from the RLC BH channels on the link between IAB Node 1 and IAB Node 2 to send a data packet to IAB Node 2.

In the conventional technology, when IAB node 2 used as an intermediate IAB node performs bearer mapping, IAB node 2 relies on the RLC input channel BH used to receive the data packet. Specifically, the output channel RLC BH corresponding to the input RLC channel BH of the data packet may be used as the output channel RLC BH used to send the data packet. However, this implementation is not flexible enough. When data packets received from the same RLC BH input channel are sent to the next hop node, the data packets can only be mapped to the same BH output RLC channel for transmission. Therefore, flexibility is poor, differentiated quality of service (QoS) cannot be ensured for data packets with different traffic, and QoS requirements for data packets cannot be satisfied.

In this embodiment of the present application, a data packet transmitted over a wireless backhaul may be allowed to carry additional information used by the intermediate IAB node to perform bearer mapping, so that the intermediate IAB node can more flexibly perform bearer mapping. The additional information may be a label, and the label may be carried in the BAP layer header information of the data packet backhaul adaptation protocol. It should be noted that the label may later have a different name. In this embodiment of the present application, the mark is merely used as an example for description. When the communication standard is changed, the corresponding name may also be replaced by the name of the corresponding function in the changed communication standard.

The following is a description of how to add and use a label to perform bearer mapping in a wireless backhaul, respectively, from the perspective of the IAB donor, the intermediate IAB node, and the access IAB node.

Option 3

FIG. 7 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. The method includes the following step:

Step 700: The IAB donor receives third configuration information.

The third configuration information is used to configure a mapping between the first label and the first information in the packet header information corresponding to the third data payload received by the IAB donor. The first information may include any one or more of the following: first differentiated service information, a first flow label, and a first IP address.

For example, in this embodiment of the present application, the third configuration information may include any of the following:

(1) first differentiated service information and a first label corresponding to the first differentiated service information, where

in this embodiment of the present application, the differentiated service information may be DSCP, or, when the packet header information corresponding to the third data payload is an IPv4 packet header, the differentiated service information may be a type of service (ToS) in the IPv4 packet header, or, when the packet header information corresponding to the third data payload is an IPv6 packet header, the differentiated service information may be a class type field in an IPv6 packet header, the first six bits of a class type field in an IPv6 packet header, etc.;

(2) the first flow label and the first label corresponding to the first flow label, where

when the packet header information corresponding to the third data payload is an IPv6 packet header, the flow label is also information carried in the IPv6 packet header;

(3) first differentiated service information, a first flow label, and corresponding first labels;

(4) a first IP address and a first label corresponding to the first IP address;

(5) the first flow label, the first IP address and the corresponding first labels;

(6) first differentiated service information, a first IP address and corresponding first tags; And

(7) first differentiated service information, a first flow label, a first IP address, and corresponding first labels.

It should be noted that the first IP address in the third configuration information may be a destination IP address in the data packet. For (4), in the third configuration information, the first IP address may alternatively be a source IP address in the data packet.

Based on the third configuration information, after receiving the third data payload, the IAB donor may determine a first label based on one or more of: differentiated service information, a flow label, and an IP address in the packet header information corresponding to the third data payload, and then send the first label and the third data payload to the next hop node. For more information, refer to the description of step 701 and step 702.

Optionally, this embodiment of the present application further includes the following steps.

Step 701: The IAB donor determines the first label based on the packet header information corresponding to the third data payload.

Specifically, the IAB donor determines the first label based on the packet header information corresponding to the third data payload and the third configuration information.

The first label is used to determine the output RLC channel of the third data payload.

It should be noted that the IAB donor may receive a downlink data packet including a third data payload, where the structure of the downlink data packet may be shown in FIG. 8. The downlink data packet shown in FIG. 8 includes a third data payload and packet header information, and the packet header information may be an IP packet header.

Step 702: The IAB donor sends a third data packet to the IAB node.

The third data packet includes a third data payload and a first layer BAP header, and the first layer BAP header includes a first label.

It should be noted that after the IAB node receives the third data packet, reference may be made to the following descriptions to obtain details of how to determine the RLC output channel of the third data payload based on the first label.

Referring to FIG. 8, after receiving the downlink data packet shown in FIG. 8, the IAB donor may add a first layer BAP header to the downlink data packet to obtain a third data packet. The structure of the third data packet can be shown in FIG. 9. The third data packet includes a first layer BAP header, a third data payload, and the like.

For example, if the IAB donor includes a CU and a DU, the IAB donor in steps 700-702 may be, in particular, an IAB donor DU, that is, the IAB donor DU may add a first label to the first BAP layer header in the third data packet. Accordingly, the IAB donor CU (which in a particular implementation may be the IAB donor CU-CP) sends third configuration information to the IAB donor DU.

For example, the third configuration information may be included in the F1AP message sent by the IAB donor CU to the IAB donor DU.

For example, if the IAB donor is not in a form in which the CU and DU are separated, the IAB donor does not need to obtain the third configuration information, and the IAB donor may generate the third configuration information, or may obtain the third configuration information from the OAM.

Embodiment 4

FIG. 10 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. The method includes the following step:

Step 1000: The second IAB node receives fourth configuration information from the IAB donor.

The second IAB node may be an access IAB node.

For example, if the IAB donor includes a CU and a DU, the IAB donor CU may configure fourth configuration information for the second IAB node.

For example, if the IAB donor CU includes a CP and a UP, the IAB donor CU-CP may configure the fourth configuration information for the second IAB node.

In an exemplary implementation, the fourth configuration information is used to configure a mapping between the second label and the second information in the packet header information corresponding to the fourth data payload received by the second IAB node, and the second label is used to determine the output RLC channel of the fourth data payload. The second information may include any one or more of the following:

second differentiated service information in the packet header information, a second flow label in the packet header information, a second IP address in the packet header information, and radio bearer information that is in the packet header information and that corresponds to the fourth data payload.

For example, the fourth configuration information may include any one or more of the following:

(1) a second stream label and a second label corresponding to the second stream label;

(2) a second flow label, a second IP address, and second labels corresponding to the second flow label and the second IP address;

(3) a second IP address and a second label corresponding to the second IP address;

(4) second differentiated service information and a second label corresponding to the second differentiated service information;

(5) second differentiated service information, a second IP address, and second labels corresponding to the second differentiated service information and the second IP address;

(6) second differentiated service information, a second flow label, and second labels corresponding to the second differentiated service information and the second flow label; And

(7) second differentiated service information, a second flow label, a second IP address, and corresponding second labels.

It should be noted that the second IP address in the fourth configuration information may be a destination IP address. For differentiated service information and flow mark in the fourth configuration information, see the description of the third configuration information. The details are not repeated in this document.

In another possible implementation, the fourth configuration information is used to configure a mapping between the fourth data payload and the second label. For example, the fourth configuration information may include any one or more of the following:

(8) Radio bearer information corresponding to the fourth data payload, and a second label corresponding to the radio bearer information.

In this case, the fourth data payload is a user plane data packet.

The radio bearer information may be any of the following: General Packet Radio Service (GPRS), GPRS Tunneling Protocol User Plane (GTP-U), Tunnel endpoint identifier identifier, TEID) carried in the user plane data packet, the GTP TEID and IP address that are carried in the user plane data packet, the UE DRB identifier (which can be determined jointly based on the UE identifier and the DRB identifier) of the user plane data packet, and the identifier user plane data packet logical channel. The GTP TEID is a tunnel endpoint identifier carried in the GTP user plane protocol layer header information, and the tunnel endpoint identifier may be an uplink tunnel endpoint identifier allocated by an IAB donor or an IAB donor CU, and corresponds to one radio data bearer ( data radio bearer, DRB) UE.

(9) A second type of a fourth data payload and a second label corresponding to the second type.

In this case, the fourth data payload is an F1 control plane packet, that is, an F1AP message. The second type is any one or more F1AP message types.

In a possible implementation, the following two types of F1AP messages may occur: a UE associated F1AP message and a non-UE associated F1AP message. Alternatively, in another possible implementation, the following plurality of specific F1AP message types may occur: an F1 setup request, a gNB-DU configuration update, a UE context setup response, and the like. In particular, the types of messages that are sent by the IAB Donor DU to the IAB Donor CU in a variety of F1AP messages described in sections 9.2/8.1 in TS 38.874 may be included. Alternatively, in another possible implementation, the following F1AP message type may occur: a UE signaling radio bearer (SRB) type corresponding to the content (eg, UE RRC message) included in the F1AP message.

The above descriptions are just examples. Another case of the F1AP message type is also possible. The details are not repeated in this document.

(10) The stream ID at the SCTP layer that carries the F1AP message when the fourth data payload is an F1AP message, and a second label corresponding to the stream ID.

Based on the fourth configuration information, after the second IAB node receives the uplink data packet including the fourth data payload, the second IAB node determines a second label based on the second information in the uplink data packet, radio bearer information, corresponding to the fourth data payload, an F1AP message type corresponding to the fourth data payload, or an SCTP layer flow identifier that carries the fourth data payload, and then sends, to the next hop node, an uplink data packet to which a second label is appended . For more detailed information, please refer to the description of steps 1001-1003.

Optionally, this embodiment of the present application further includes the following steps.

Step 1001: The second IAB node receives the fourth data payload. In particular, the second IAB node may generate a fourth data payload or receive a fourth data payload from a terminal device or a child node served by the second IAB node.

Step 1002: The second IAB node determines the second label.

In particular, the second IAB node may determine the second label based on packet header information corresponding to the fourth data payload, radio bearer information corresponding to the fourth data payload, an F1AP message type corresponding to the fourth data payload, or a flow identifier at the SCTP layer. , which carries the fourth data payload.

Step 1003: The second IAB node sends a fourth data packet to the parent node.

The fourth data packet includes a fourth data payload and a second layer BAP header, and the second layer BAP header includes a second label.

Embodiment 5

FIG. 11 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. The method includes the following step:

Step 1100: The first IAB node receives fifth configuration information from the IAB donor.

The fifth configuration information is used to configure the mapping between the third label and the third RLC channel identifier. The third label is carried in the BAP layer header of the data packet and is used by the first IAB to determine the output RLC channel of the data packet. The third RLC channel identifier is used to identify the output RLC channel of the BH (ie, the third RLC BH channel) through which the first IAB sends the data packet, and may be the identifier of the third RLC BH channel or the logical channel identifier corresponding to the third RLC BH channel.

For example, the fifth configuration information may include any one or more of the following:

(1) The third label and the corresponding third RLC channel identifier.

(2) A third label, the output link identifier and corresponding third RLC channel identifiers, where the output link identifier is used to indicate the output link over which the first IAB node sends the data packet. In particular, for uplink transmission, the egress link identifier may be the parent node identifier of the first IAB node (eg, the parent node's BAP layer identifier, the parent node's DU identifier, the parent node's IP address, the parent node's cell identifier, or a group identifier cell of the parent node for the first IAB node). For downlink transmission, the output link ID may be the ID of a child node of the first IAB node (eg, the F1 control plane UE ID F1AP DU allocated by the first IAB node to the child node, the cell ID of the first IAB node accessed by the child node + Cell Radio Network Temporary Identifier (C-RNTI) allocated by the first IAB node to the child node, IP address of the child node, or BAP layer identifier of the child node).

(3) A third label, a fourth RLC channel identifier, and corresponding third RLC channel identifiers, where the fourth RLC channel identifier is used to identify the input RLC BH channel (i.e., the fourth RLC BH channel) through which the first IAB node receives the data packet and may be an identifier the fourth RLC BH channel or a logical channel identifier corresponding to the fourth RLC BH channel.

(4) The third label, the input link identifier, the fourth RLC channel identifier, the output link identifier and the corresponding third RLC channel identifiers, where for the fourth RLC channel identifier, refer to the description (3), and for the output link identifier, refer to description (2). The details are not repeated in this document. The ingress link identifier is used to indicate the ingress link over which the first IAB node receives the data packet. In particular, for uplink transmission, the incoming link identifier may be a child node identifier of the first IAB node. For a specific example of a child node ID, refer to description (2). For downlink transmission, the input link identifier may be the parent node identifier of the first IAB node. For a specific example of a parent node ID, refer to description (2). The details are not repeated in this document.

(5) Correspondence between the third label and the QoS ID. If necessary, a mapping between the QoS identifier and the third RLC channel identifier is additionally included. In this correspondence, the third label does not have a direct correspondence to the output RLC channel, and an intermediate matching process takes place, that is, there is a correspondence between the third label and the QoS ID, and there is a correspondence between the QoS ID and the output RLC channel. Both the mapping between the third label and the QoS ID, and the mapping between the QoS ID and the third RLC bearer ID (for example, the fifth configuration information includes the third label, the QoS ID corresponding to the third label, and the third RLC bearer ID) can be configured, or the mapping between the third label and the QoS identifier and the mapping between the QoS identifier and the third RLC channel identifier may be configured separately (for example, the fifth configuration information includes the third label and the QoS identifier to configure the mapping between the third label and the QoS identifier, and other configuration information includes a third RLC channel identifier and a QoS identifier to configure a mapping between the QoS identifier and the third RLC channel identifier). This is not limited to this embodiment of the present application.

It should be noted that a single QoS identifier can be used to represent one or a group of QoS parameters. The QoS identifier may be, but is not limited to, a QoS Class Identifier (QCI), a 5G QoS Indicator (5QI), a QoS flow identifier (QFI), and the like. For example, one or a group of QoS parameters include delay, packet loss ratio, throughput, etc.).

(6) The correspondence between the third label and the QoS parameter and the correspondence between the QoS parameter and the third RLC channel identifier. Both the mapping between the third label and the QoS parameter, and the mapping between the QoS parameter and the third RLC bearer identifier (for example, the fifth configuration information includes the third label, the QoS parameter corresponding to the third label, and the third RLC bearer identifier) can be configured, or the mapping between the third label and the QoS parameter and the mapping between the QoS parameter and the third RLC channel identifier can be configured separately (for example, the fifth configuration information includes the third label and the QoS parameter to configure the mapping between the third label and the QoS parameter, and the other configuration information includes includes a third RLC channel identifier and a QoS parameter to configure the mapping between the QoS parameter and the third RLC channel identifier). This is not limited to this embodiment of the present application.

It should be noted that the third label can be used as an additional field. If the data packet does not carry the third label, the configuration information configured by the IAB donor for the IAB node may only include a mapping between an input RLC channel and an output RLC channel, that is, a mapping between a fourth RLC channel identifier and a third RLC channel identifier.

For example, if the IAB donor includes a CU and a DU, the IAB donor CU may configure fifth configuration information for the first IAB node.

For example, if the IAB donor CU includes a CP and a UP, the IAB donor CU-CP may configure fifth configuration information for the first IAB node.

In this embodiment, the first IAB node may be an intermediate IAB node. A data packet (the data packet may be an uplink data packet or a downlink data packet) received by an intermediate IAB node on a wireless backhaul carries a label. Therefore, the intermediate IAB node must perform bearer matching based on the label carried in the data packet, that is, select the RLC output channel for the data packet to send the data packet to the next hop node. In this embodiment of the present application, the intermediate IAB node may perform bearer matching for the received data packet based on the fifth configuration information. A detailed description is provided below.

Optionally, this embodiment of the present application further includes the following steps.

Step 1101: The first IAB node receives the data packet.

The data packet is a data packet received from a second IAB node, or the data packet is a data packet received from an IAB donor.

The Data Packet Backhaul Adaptation Protocol BAP layer header includes a third label.

Step 1102: The first IAB node determines the third RLC channel identifier based on the third label.

For example, when the fifth configuration information includes a third label, an incoming link identifier, a fourth RLC channel identifier, an egress link identifier, and a third RLC channel identifier, the first IAB node performs routing selection for the data packet to determine the egress link identifier, and then determines a third RLC channel identifier based on the third label in the data packet, an input link on which the data packet was received, and a fourth RLC channel on the input link on which the data packet was received. Another case has not been described.

Step 1103: The first IAB node sends a data packet on an output RLC channel corresponding to the third RLC channel identifier.

In the above process, the first IAB node performs bearer mapping for a data packet based on the fifth configuration information. This solution may allow the first IAB node to more flexibly perform bearer mapping to provide more accurate QoS guarantee in the IAB network.

Embodiment 6

FIG. 12 is a flowchart of a method for transmitting a data packet according to an embodiment of the present application. The method includes the following step:

Step 1200: The second IAB node receives sixth configuration information from the IAB donor.

The second IAB node may be an access IAB node.

For example, if the IAB donor includes a CU and a DU, the IAB donor CU may configure sixth configuration information for the second IAB node.

For example, if the IAB donor CU includes a CP and a UP, the IAB donor CU-CP may configure sixth configuration information for the second IAB node.

The sixth configuration information is used to configure packet header information respectively added to the sixth data payload to be transmitted by the second IAB node. The sixth data payload may be an F1 control layer (F1-C) message, that is, an F1AP message, between the second IAB node and the IAB donor (which may be, in particular, an IAB donor CU or an IAB donor CU-CP). Packet header information is a field in the header of an IP packet and, in particular, includes differentiated service information and/or a flow label.

In an exemplary implementation, the sixth configuration information specifically includes any one or more of the following:

the first differentiated service information and/or the first flow label indicated for the F1AP message associated with the UE (UE associated F1AP message), and the second differentiated service information and/or the second flow label indicated for the F1AP message not associated with the UE (non- UE associated F1AP message).

In another possible implementation, the sixth configuration information specifically includes any one or more of the following:

the identifier of the first terminal device, the first differentiated service information and/or the first flow label indicated for the F1AP message associated with the UE of the first terminal device, and the second differentiated service information and/or the second flow label indicated for the F1AP message not associated with the UE .

Based on the sixth configuration information, after receiving an uplink data packet including the sixth payload data, the second IAB node determines, based on the F1AP message type corresponding to the sixth payload data, differentiated service information and/or flow label to be added to the IP packet header, and then sends to the next hop node an uplink data packet to which the differentiated service information and/or flow label is/are added. For details, see the descriptions of steps 1201-1203.

Optionally, this embodiment of the present application further includes the following steps.

Step 1201: The second IAB node receives the sixth data payload. In particular, the second IAB node may generate a sixth data payload.

Step 1202: The second IAB node determines differentiated service information and/or flow label corresponding to the sixth data payload.

The second IAB may determine, based on the type of F1AP message (eg, an F1AP message not associated with a UE or an F1AP message associated with a UE) corresponding to the sixth data payload, differentiated service information and/or a flow label corresponding to the sixth payload data, or when the sixth data payload is an F1AP message associated with the UE, the second IAB may determine, based on an identifier that is associated with the first terminal device and that corresponds to the sixth data payload, differentiated service information and/or flow label , corresponding to the sixth data payload. Specifically, when the sixth data payload is an F1AP message not associated with the UE, the sixth data payload corresponds to the second differentiated service information and/or the second flow label, or when the sixth data payload is an F1AP message associated with the UE, the data payload corresponds to the first differentiated service information and/or the first flow label. Alternatively, when the sixth data payload is an F1AP message associated with the UE of the first terminal device, the sixth data payload corresponds to the first differentiated service information and/or the first flow label.

Step 1203: The second IAB node sends the sixth data packet to the parent node.

The sixth data packet includes a sixth data payload and an IP packet header, and the IP packet header includes differentiated service information and/or a flow label that corresponds to the sixth data payload and that is/are defined at step 1202. If necessary, the second IAB node may determine, based on the differentiated service information and/or flow label included in the sixth data packet, an RLC output channel BH used to send the sixth data packet.

In the above process, the second IAB node adds various differentiated service information and/or flow label values to various types of F1AP messages based on the sixth configuration information so that the second IAB node can determine, based on the RLC BH channels, corresponding to the differentiated service information and/or flow label values, RLC BH channels used to send F1AP messages to ensure differentiated QoS for different types of F1-C messages.

Embodiment 7

In the current Dual Connectivity scenario, the UE is connected to both a Master Node (MN) and a Secondary Node (SN). The MN and SN may use the same access standard (for example, both the MN and SN use the LTE standard or the NR standard), or they may use different access standards (for example, the MN uses the LTE standard and the SN uses the NR standard, or MN uses the NR standard, and SN uses the LTE standard). A Master Cell Group (MCG) includes a serving cell associated with an MN and includes at least one primary PCell and optionally includes one or more secondary SCells. Likewise, a Secondary Cell Group (SCG) includes a serving cell associated with an SN, and includes at least one primary cell (eg, a primary secondary cell (PSCell)), and optionally includes one or more secondary SCells. The MCG link is a single-hop access link between the UE and the MN, and the SCG link is a single-hop access link between the UE and the SN.

When the UE detects that a Radio Link Failure (RLF) occurs on the MCG link between the UE and the MN, the UE initiates an RRC connection re-establishment process to restore the MCG link. When the UE detects that an RLF occurs on the SCG link between the UE and the SN, the UE does not initiate the RRC connection re-establishment process, and sends an SCG failure report to the MN using the MCG for the MN to initiate the process SCG failure recovery to restore the SCG channel, for example, initiates the SCG change process. 3GPP Release 16 improves the existing DC and introduces a fast MCG recovery mechanism. To be specific, when the UE detects that an RLF occurs on the MCG link between the UE and the MN, the UE uses a mechanism similar to the SCG failure mechanism and no longer initiates the RRC connection re-establishment process, but sends an MCG failure report ) using SCG.

In the IAB scenario, the IAB node can operate in standalone (SA) mode or non-standalone (NSA) mode based on EN-DC (E-UTRAN NR Dual Connectivity).

In this embodiment, the IAB node is considered to operate primarily in NSA mode. As shown in FIG. 13, the MN that provides a service to the IAB node is an eNB, and the SN that provides a service to the IAB node is an IAB donor. MN uses the LTE standard and SN uses the NR standard. Similarly, the link MCG is the link between the IAB node (ie the IAB MT node) and the MN, and the link SCG is the link between the IAB node (ie the IAB MT node) and the SN.

When the IAB node detects that an RLF occurs on the SCG link between the IAB node and the donor IAB, the IAB node sends an SCG failure report over the MCG link to the eNB, which provides the service to the IAB node, so that the eNB initiates the failure recovery process. SCG to restore the SCG channel.

When the SCG link fails or cannot be restored (for example, an SCG change failure occurs or an SCG release is in progress), the IAB node must send one piece of RLF pointer information to the child node from the IAB node so that the child node from the IAB node performs appropriate processing. In an exemplary implementation, when a child node from an IAB node receives RLF pointer information sent by an IAB node, the child node from an IAB node sends, using MCG, an SCG failure report to the eNB that provides a service to the child node. A child node of an IAB node may be a UE or another IAB node. The eNB that provides a service to an IAB node may be the same or different from the eNB that provides a service to a child node of the IAB node. In this embodiment, this case is not a limitation.

It should be noted that this embodiment is also applicable to the multi-hop IAB scenario. More specifically, it is possible for another IAB node on the link between the IAB node and the donor node, that is, a scenario in which the IAB node is connected to the donor node using another IAB node. The details are not described in this document.

The embodiments described herein may be independent solutions or may be combined based on internal logic. All these decisions fall within the scope of protection of the present application.

It can be understood that in the above method embodiments, methods and operations implemented by a terminal device may alternatively be implemented by a component (e.g., a chip or circuit) that may be used in the terminal device, and methods and operations implemented by a network device may alternatively be implemented a component (such as a chip or circuit) that can be used in a network device.

The above mainly describes, from the point of view of interaction between network elements, the solutions provided in this application. It is understood that in order to implement the above functions, each network element includes a corresponding hardware structure and/or software module for implementing each function. One skilled in the art will appreciate that the blocks, algorithms, and steps presented in the examples, which are described with reference to the embodiments disclosed herein, may be implemented in the present invention using hardware or a combination of hardware and computer software. provision. Whether a function is performed in hardware or in firmware controlled by computer software depends on the specific applications and design constraints imposed on the technical solutions. One skilled in the art may use different methods for each particular application to implement the described functions, but implementation should not be considered beyond the scope of the present invention.

FIG. 14 shows a possible block diagram of a communication device according to the present application. The device 1400 may exist in the form of software or hardware. The device 1400 may include a processing unit 1401 and a communication unit 1402. In an implementation, communication unit 1402 may include a receive unit and a send unit. The processing unit 1401 is configured to: monitor and control the actions of the device 1400. The communication unit 1402 is configured to maintain communication between the device 1400 and another network entity.

When device 1400 is configured to implement IAB donor functions in the method embodiment shown in FIG. 4, the following operations are performed:

The processing unit is configured to determine the first configuration information, where the first configuration information is used to indicate a first radio link control (RLC) channel of a backhaul link (BH), and the first RLC channel BH is used to transmit a control protocol data unit (PDU) at the BAP layer Transit Connection Adaptation Protocol.

The communication unit is configured to send the first configuration information to the IAB node.

In an exemplary implementation, the first configuration information includes a channel identifier of the first RLC channel BH; or

the first configuration information includes a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH.

When the device 1400 is configured to implement the functions of the IAB node in the method embodiment shown in FIG. 4, the following operations are performed:

The processing unit is configured to determine a first radio link control channel (RLC) of a backhaul link (BH) used to transmit a control protocol data unit (PDU) at the BAP layer.

The communication unit is configured to send a control PDU at the BAP level to the neighboring IAB node over the first RLC channel of the BH.

In a possible implementation, the processing unit is specifically configured to:

receiving first configuration information from the donor IAB, where the first configuration information is used to indicate a first RLC BH channel used to transmit a control PDU at the BAP layer; And

determining a first RLC channel BH based on the first configuration information.

In an exemplary implementation, the first configuration information includes a channel identifier of the first RLC channel BH; or

the first configuration information includes a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH.

When device 1400 is configured to implement IAB donor functions in the method embodiment shown in FIG. 5, the following operations are performed:

The processing unit is configured to determine second configuration information, where the second configuration information is used to indicate a second radio link control (RLC) channel of a backhaul link (BH), a second RLC channel BH is used to transmit a data payload of a first type, and a data payload of a first type type is a data payload different from the F1 user plane data payload (F1-U) and the F1 control plane data payload (F1-C).

The communication unit is configured to send the second configuration information to the IAB node.

In an exemplary implementation, the first type data payload includes any of the following:

Operation, Administration and Maintenance (OAM) traffic package;

packet used to request an Internet Protocol (IP) address;

a packet used to establish an Internet Protocol Security (IPsec) data link;

Stream Control Transport Protocol (SCTP) association installation package;

SCTP Association Disable Packet; And

SCTP association heartbeat packet.

In an exemplary implementation, the second configuration information includes any one or more of the following:

a first type, where the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH;

first differentiated service information, where the first differentiated service information corresponds to a first type and/or a second RLC BH channel; And

a first stream label, where the first stream label corresponds to a first type and/or second channel of the RLC BH.

In a possible implementation, the processing unit is additionally configured to:

generating a first data payload, where the first data payload is a first type data payload; And

if the packet header information corresponding to the first data payload carries the first differentiated service information, the communication unit is further configured to send the first data packet to the IAB node on the second RLC BH channel corresponding to the first differentiated service information; or if the packet header information corresponding to the first data payload carries the first flow label, the communication unit is further configured to send the first data packet to the IAB node on a second RLC BH channel corresponding to the first flow label, where the first data packet includes the first payload data.

In an exemplary implementation, the second configuration information includes identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier corresponding to the second RLC BH channel.

When the device 1400 is configured to implement the functions of the IAB node in the method embodiment shown in FIG. 5, the following operations are performed:

The communication unit is configured to receive second configuration information from the donor IAB, where the second configuration information is used to indicate a second radio link control (RLC) channel of the backhaul link (BH), the second RLC channel BH is used to transmit a data payload of the first type, and the payload the first type data payload is a data payload different from the F1 user plane data payload (F1-U) and the F1 control plane data payload (F1-C).

The processing unit is configured to transmit a first type of data payload based on the second configuration information.

In an exemplary implementation, the first type data payload includes any of the following:

Operation, Administration and Maintenance (OAM) traffic package;

packet used to request an Internet Protocol (IP) address;

a packet used to establish an Internet Protocol Security (IPsec) data link;

Stream Control Transport Protocol (SCTP) association installation package;

SCTP Association Disable Packet; And

SCTP association heartbeat packet.

In an exemplary implementation, the second configuration information includes any one or more of the following:

a first type, where the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH;

first differentiated service information, where the first differentiated service information corresponds to a first type and/or a second RLC BH channel; And

a first stream label, where the first stream label corresponds to a first type and/or second channel of the RLC BH.

In an exemplary implementation, the second configuration information includes identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier corresponding to the second RLC BH channel.

In the method embodiment shown in FIG. 7, device 1400 may further implement the functions of an IAB donor; in the method embodiment shown in FIG. 10, device 1400 may further implement the functions of a second IAB node; in the method embodiment shown in FIG. 11, device 1400 may further implement the functions of a first IAB node, and in the method embodiment shown in FIG. 12, device 1400 may further implement functions of a second IAB node. For more detailed information please refer to the previous descriptions. The details are not repeated in this document.

FIG. 15 shows a hardware device 1500 according to an embodiment of the present application. The device shown in FIG. 15 may be a hardware circuit implementation of the device shown in FIG. 14. The communication device may be used in the block diagram shown above and functions as an IAB node or IAB donor in the above method embodiments. For ease of description, FIG. 15 shows only the main components of the communication device.

The hardware device 1500 shown in FIG. 15 includes at least one processor 1501. For example, the processor 1501 may be a general-purpose central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP) ), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, transistor logic device, hardware component, or any combination thereof. The processor may implement or execute various exemplary logical blocks, modules, and circuits described with reference to the content disclosed herein. Alternatively, the processor may be a combination of processors that implement a computing function, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

The hardware device 1500 may further include at least one memory 1502 configured to store program instructions and/or data. Memory 1502 is coupled to processor 1501. Communication in this embodiment of the present application is an indirect communication or communication connection between devices, blocks or modules for exchanging information between devices, blocks or modules and may take electrical, mechanical or other forms. Processor 1501 may operate in conjunction with memory 1502. Processor 1501 may execute program instructions stored in memory 1502. At least one of at least one memory may be included in the processor.

The hardware device 1500 may further include a communication interface 1503 configured to communicate with another device via a transmission medium such that a hardware device in the hardware device 1500 can communicate with the other device. In this embodiment of the present application, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface. In this embodiment of the present application, the transceiver may be an independent receiver, an independent transmitter, a transceiver integrated with a transceiver function, or an interface circuit.

The hardware device 1500 may further include a communication line 1504. Communication interface 1503, processor 1501, and memory 1502 may be coupled to each other via communication line 1504. Communication line 1504 may be a peripheral component interconnect (PCI), extended industry standard architecture (EISA), or the like. Communication line 1504 may be divided into an address bus, a data bus, a control bus, and the like. For ease of presentation, only one bold line is used to represent the communication line in FIG. 15, but this does not mean that there is only one bus or only one type of bus.

In the method embodiment shown in FIG. 4, device 1500 may implement the functions of an IAB node or IAB donor, in the method embodiment shown in FIG. 5, device 1500 may further implement the functions of an IAB node or IAB donor, in the method embodiment, shown in FIG. 7, device 1500 may further implement the functions of an IAB donor; in the method embodiment shown in FIG. 10, device 1500 may further implement the functions of a second IAB node; in the method embodiment shown in FIG. 11, device 1500 may further implement the functions of the first IAB node, and in the method embodiment shown in FIG. 1, the device 1500 may further implement the functions of the second IAB node 2. For more detailed information, please refer to the previous descriptions. The details are not repeated in this document.

One skilled in the art will appreciate that embodiments of the present application may be provided as a method, system, or computer program product. Therefore, the present application may take the form of hardware-only embodiments, software-only embodiments, or embodiments with a combination of software or hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer storage media (including, but not limited to, disk memory, optical memory, and the like) that includes program code used by the computer.

This application is described with reference to flowcharts and/or flowcharts of a method, apparatus (system), and computer program product according to this application. It should be understood that computer program instructions may be used to implement each procedure and/or each block in the flowcharts and/or flowcharts and combinations of procedures and/or blocks in the flowcharts and/or flowcharts. These computer program instructions may be provided to a general purpose computer, a special purpose computer, an embedded processor, or a processor of another programmable processing device to create a machine such that the instructions executed by the computer or the processor of another programmable processing device create a device for implementing a specific function in one or multiple procedures in flowcharts and/or in one or more blocks in flowcharts.

Alternatively, these computer program instructions may be stored in computer readable memory, which may direct the computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an artifact that includes the instruction device. The command device implements a particular function in one or more procedures in flowcharts and/or in one or more blocks in flowcharts.

It is understood that one skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. This application is intended to cover these modifications and variations of this application, provided that they fall within the scope of protection defined by the claims of this application and equivalent technologies.

Claims (48)

1. A method for transmitting data packets containing: determining, by the Integrated Access and Backhaul (IAB) donor, first configuration information, wherein the first configuration information indicates that a first radio link control (RLC) channel of the backhaul link (BH) is for transmitting a control protocol data unit PDU at the backhaul adaptation protocol layer connections (BAP); And sending, by the IAB donor, the first configuration information to the IAB node. 2. The method according to claim 1, wherein the first configuration information comprises a channel identifier of the first RLC BH channel; or the first configuration information contains a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH. 3. A method for transmitting data packets, containing: reception, by an Integrated Access and Backhaul node (IAB) from an IAB donor, of first configuration information indicating that a first radio link control (RLC) channel of the backhaul link (BH) is intended to transmit a protocol data unit (PDU) at the backhaul adaptation protocol layer connections (BAP); determining, by the IAB node based on the first configuration information, a first RLC BH channel used for transmitting a control PDU at the BAP layer; And sending, by the IAB node, a BAP level control PDU to the neighboring IAB node on the first RLC channel of the BH. 4. The method according to claim 3, wherein the first configuration information comprises a channel identifier of the first RLC BH channel; or the first configuration information contains a logical channel identifier, and the logical channel indicated by the logical channel identifier corresponds to the first RLC channel of the BH. 5. A method for mapping bearers for a data packet, comprising: determining, by the integrated access and backhaul (IAB) donor, second configuration information, wherein the second configuration information indicates that a second radio link control (RLC) channel of the backhaul (BH) is for transmitting a first type of data payload, and the data payload the first type is a data payload other than a protocol data unit (PDU) at the backhaul adaptation protocol (BAP) layer, an F1 user plane data payload (F1-U), and an F1 control plane data payload (F1-C); And sending, by the IAB donor, the second configuration information to the IAB node. 6. The method of claim 5, wherein the first type data payload comprises any of the following: Operation, Administration and Maintenance (OAM) traffic package; packet used to request an Internet Protocol (IP) address; a packet used to establish an Internet Protocol Security (IPsec) data link; Stream Control Transport Protocol (SCTP) association installation package; SCTP Association Disable Packet; And SCTP association heartbeat packet. 7. The method of claim 5 or 6, wherein the second configuration information comprises any one or more of the following: a first type, wherein the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH; first differentiated service information, wherein the first differentiated service information corresponds to a first type and/or a second RLC channel BH; And a first stream label, wherein the first stream label corresponds to a first type and/or second RLC BH channel. 8. The method according to any one of claims 5-7, in which the method additionally contains: generating, by the IAB donor, a first data payload, the first data payload being a first type data payload; And if the packet header information corresponding to the first data payload carries the first differentiated service information, sending, by the IAB donor, the first data packet to the IAB node on the second RLC BH channel corresponding to the first differentiated service information; or if the packet header information corresponding to the first data payload carries the first flow label, sending, by the IAB donor, the first data packet to the IAB node on a second RLC BH channel corresponding to the first flow label, the first data packet containing the first data payload. 9. The method according to any one of claims 5 to 8, wherein the second configuration information comprises identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier, corresponding to the second RLC BH channel. 10. A method for mapping bearers for a data packet, comprising: receiving, by the Integrated Access and Backhaul Node (IAB), second configuration information from the IAB donor, wherein the second configuration information indicates that a second radio link control (RLC) channel of the backhaul (BH) is for transmitting a first type of data payload, and The first type data payload is a data payload other than the protocol data unit (PDU) at the backhaul adaptation protocol (BAP) layer, the F1 user plane data payload (F1-U), and the F1 control plane data payload (F1-C). ); And transmitting, by the IAB node, a first type of data payload based on the second configuration information. 11. The method of claim 10, wherein the first type data payload comprises any of the following: Operation, Administration and Maintenance (OAM) traffic package; packet used to request an Internet Protocol (IP) address; a packet used to establish an Internet Protocol Security (IPsec) data link; Stream Control Transport Protocol (SCTP) association installation package; SCTP Association Disable Packet; And SCTP association heartbeat packet. 12. The method of claim 10 or 11, wherein the second configuration information comprises one or more of the following: a first type, wherein the first type is a data payload type, and the first type corresponds to the second RLC channel of the BH; first differentiated service information, wherein the first differentiated service information corresponds to a first type and/or a second RLC channel BH; And a first stream label, wherein the first stream label corresponds to a first type and/or second RLC BH channel. 13. The method according to any one of claims 10 to 12, wherein the second configuration information contains identification information used to identify the second RLC BH channel, and the identification information is a channel identifier of the second RLC BH channel, or the identification information is a logical channel identifier, corresponding to the second RLC BH channel. 14. A communication device comprising a memory and a processor, wherein the memory is configured to store instructions, the processor is configured to execute instructions stored in the memory, wherein the instructions stored in the memory, when executed by the processor, cause the device to perform the method of claim 1 or 2 or the method according to claim 3 or 4. 15. A computer-readable storage medium containing machine-readable instructions, the instructions being executed by a communication device to perform the method of claim 1 or 2 or the method of claim 3 or 4. 16. A communication device comprising a memory and a processor, wherein the memory is configured to store instructions, the processor is configured to execute instructions stored in the memory, wherein the instructions stored in the memory, when executed by the processor, cause the device to perform the method of any one of claims 5 -9 or the method according to any of paragraphs 10-13. 17. A computer-readable storage medium containing machine-readable instructions, the instructions being executed by a communication device to perform the method of any one of claims 5 to 9 or the method of any of claims 10 to 13.

Images