Communication methods and apparatus, storage medium and program product

Abstract

Provided in the embodiments of the present disclosure are communication methods and apparatus, a storage medium, and a program product. A method is applied to a first node, and comprises: generating an HARQ receiving buffer status report, the HARQ receiving buffer status report being used for indicating HARQ receiving buffer status after the first node has received at least one data packet; and sending the HARQ receiving buffer status report to a second node.

Description

Communication methods, devices, storage media and software products

[0001] This disclosure claims priority to Chinese patent application No. 202410983241.6, filed on July 19, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of communication technology, and in particular to a communication method, apparatus, storage medium, and program product. Background Technology

[0003] In the field of communication technology, such as in wireless communication systems, to improve the reliability of data transmission, a hybrid automatic repeat request (HARQ) mechanism is often used. This allows the terminal to promptly inform the base station whether it has successfully received the data sent by the base station by providing either an acknowledgment (ACK) or a negative acknowledgment (NACK). In the HARQ mechanism, the base station sends a new packet to the terminal when it receives an ACK. If the base station receives a NACK and the number of retransmissions for the data packet has not reached the maximum number of transmissions, it sends a retransmission packet to the terminal. If the base station receives a NACK and the number of retransmissions for the data packet has reached the maximum number of transmissions, it will not retransmit the data packet but will instead send a new packet to the terminal. In 5G, the feedback in the above HARQ mechanism is also called HARQ ACK feedback or HARQ ACK / NACK feedback. Here, HARQ ACK feedback refers to the feedback mechanism where the receiving end sends an ACK or NACK for each data packet, not that an ACK must always be sent. Summary of the Invention

[0004] On one hand, this disclosure provides a communication method. The method is applied to a first node and includes:

[0005] Generate a HARQ receive buffer status report, which is used to indicate the HARQ receive buffer status after the first node receives at least one data packet;

[0006] Send the HARQ receive buffer status report to the second node.

[0007] On the other hand, embodiments of this disclosure provide a communication method. This method is applied to a second node and includes:

[0008] Send at least one data packet to the first node;

[0009] The system receives a HARQ receive buffer status report sent by the first node, the HARQ receive buffer status report being used to indicate the HARQ receive buffer status after the first node receives the at least one data packet.

[0010] In another aspect, embodiments of this disclosure provide a communication device. The communication device includes: a processor and a memory for storing instructions executable by the processor; the processor is configured to execute the instructions, such that the communication device implements any of the communication methods provided in embodiments of this disclosure.

[0011] In another aspect, embodiments of this disclosure provide a computer-readable storage medium storing computer program instructions that, when executed on a computer, cause the computer to implement any of the communication methods provided in embodiments of this disclosure.

[0012] In another aspect, embodiments of this disclosure provide a computer program product including computer program instructions that, when executed on a computer, cause the computer to implement any of the communication methods provided in embodiments of this disclosure. Attached Figure Description

[0013] Figure 1 is a schematic diagram of the structure of a communication system according to some embodiments.

[0014] Figure 2 is a flowchart illustrating a communication method according to some embodiments.

[0015] Figure 3 is a flowchart illustrating another communication method according to some embodiments.

[0016] Figure 4 is a flowchart illustrating another communication method according to some embodiments.

[0017] Figure 5 is a flowchart illustrating another communication method according to some embodiments.

[0018] Figure 6 is a flowchart illustrating another communication method according to some embodiments.

[0019] Figure 7 is a flowchart illustrating another communication method according to some embodiments.

[0020] Figure 8 is a flowchart illustrating another communication method according to some embodiments.

[0021] Figure 9 is a flowchart illustrating another communication method according to some embodiments.

[0022] Figure 10 is a flowchart illustrating another communication method according to some embodiments.

[0023] Figure 11 is a flowchart illustrating another communication method according to some embodiments.

[0024] Figure 12 is a schematic diagram of the structure of a communication device according to some embodiments. Detailed Implementation

[0025] The technical solutions in the embodiments of this disclosure will now be clearly and completely described with reference to the accompanying drawings.

[0026] In the description of this disclosure, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: only A, A and B, and only B.

[0027] Furthermore, "at least one" refers to one or more, and "more than one" refers to two or more. To facilitate a clear description of the technical solutions of the embodiments of this disclosure, the terms "first," "second," etc., are used in the embodiments of this disclosure to distinguish identical or similar items with substantially the same function and effect. It should be understood that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., are not necessarily different.

[0028] Furthermore, in this disclosure, expressions such as "exemplarily" or "for example" are used to indicate that they are examples, illustrations, or illustrations. Any embodiment or design described as "exemplarily" or "for example" in this disclosure should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of expressions such as "exemplarily" or "for example" is intended to present the relevant concepts in a detailed manner.

[0029] In the field of communication technology, such as in wireless communication systems, retransmission mechanisms are typically employed to improve the reliability of data transmission. The base station uses ACK or NACK responses from the terminal to determine whether the terminal has successfully received data and to retransmit failed data. When a data packet reception fails, the terminal sends a NACK to the base station; upon receiving a NACK, the base station considers the data packet transmission failed and retransmits it. When the terminal successfully receives a data packet, it sends an ACK to the base station; upon receiving the ACK, the base station sends a new data packet to the terminal.

[0030] However, in some scenarios, base stations may send data packets to terminals that do not meet their requirements. For example, due to changes in the wireless environment, there is a possibility that the base station may misinterpret an ACK as a NACK, or vice versa. When an ACK is misinterpreted as a NACK, the base station should send a new packet but instead sends a retransmission packet. When a NACK is misinterpreted as an ACK, the base station should send a retransmission packet but instead sends a new packet. For example, due to network congestion, the terminal does not want the base station to retransmit data packets, but it will still send a NACK feedback for failed data packets. The base station will then retransmit the data packets upon receiving the NACK. All of these will result in a waste of transmission resources and a reduction in data transmission efficiency.

[0031] To address this, this disclosure provides a communication method applied to a first node, comprising: generating a HARQ receive buffer status report, the HARQ receive buffer status report indicating the HARQ receive buffer status of the first node after receiving at least one data packet; and sending the HARQ receive buffer status report to a second node. Based on this, data transmission resource waste can be reduced and data transmission efficiency improved.

[0032] For ease of understanding, the inventive concept involved in this disclosure will be described in detail below.

[0033] In 5G communication, HARQ resides at the medium access control (MAC) layer. A single HARQ entity contains multiple HARQ processes, each with its own independent receiver HARQ buffer. This receiver HARQ buffer is also known as the HARQ receive buffer. Each HARQ process's receive buffer corresponds to the reception of a Transport Block (TB). Typically, the HARQ receive buffer stores the soft information data of the TB before decoding. When TB decoding is successful, the soft information data in the HARQ receive buffer is cleared to prepare for receiving new packets. When TB decoding fails, the soft information data in the HARQ receive buffer is retained, awaiting the arrival of retransmitted packets for soft information merging before being sent to the decoder. Furthermore, when TB transmission encounters issues such as reaching the maximum retransmission count, timer timeout, or network congestion, a packet loss operation is triggered. In this case, the soft information data in the HARQ receive buffer is also cleared, awaiting the arrival of new packets.

[0034] It should be understood that after the terminal receives a data packet, the state of the receive buffer in the terminal will change according to the reception status of the data packet (e.g., whether the data packet was successfully received, whether it was lost, etc.). It should be noted that the receive buffer described in this disclosure and the HARQ receive buffer, receiver HARQ buffer, receive HARQ buffer, and HARQ receive buffer mentioned below are the same concept, and will not be elaborated further below.

[0035] Typically, the HARQ receive buffer state of a terminal reflects whether the terminal expects the base station to transmit new packets or retransmit packets. This disclosure provides examples of the following scenarios one through four. In these scenarios, the terminal's HARQ receive buffer state changes according to the data packet reception status (e.g., whether the data packet was successfully received, whether it was lost, etc.), thereby reflecting whether the terminal expects the base station to transmit new packets or retransmit packets.

[0036] Scenario 1: After the terminal successfully receives the data packet sent by the base station, in addition to sending an ACK to the base station, it also clears the data in the HARQ receive buffer (clearing can also be equivalent to clearing, which will not be elaborated on below) to make room for the new packet data. It can be understood that at this time, the HARQ receive buffer state of the HARQ process is that the terminal is waiting for the base station to send a new packet.

[0037] Scenario 2: If the terminal fails to receive a data packet from the base station, in addition to sending a NACK to the base station, it will also check whether the maximum number of retransmissions has been reached. If the maximum number of retransmissions has not been reached, the data in the HARQ receive buffer is retained for soft information merging after the retransmission packet arrives. It can be understood that at this time, the HARQ receive buffer state of the HARQ process is that the terminal expects the base station to send a retransmission packet.

[0038] Scenario 3: When the terminal fails to receive a data packet from the base station, in addition to sending a NACK to the base station, it also checks whether the maximum retransmission count has been reached. If the maximum retransmission count has been reached, the terminal considers the data packet lost and clears the data in the HARQ receive buffer, waiting for the base station to send a new packet. It can be understood that at this point, the HARQ receive buffer state of the HARQ process indicates that the terminal is expecting the base station to send a new packet.

[0039] Scenario 4: In cases of time-sensitive data packet timeout, buffer congestion, or hardware failure, the terminal deems it necessary to actively drop packets. Since retransmitted packets after packet loss are meaningless for the terminal to receive, it can be understood that the HARQ receive buffer state of the HARQ process at this time indicates that the terminal expects the base station to send new packets.

[0040] As can be seen from scenarios one through four, after the terminal receives a data packet, the state of the HARQ receive buffer in the receive buffer will change according to the reception status of the data packet.

[0041] This disclosure provides two HARQ receive buffer states (e.g., the first buffer state and the second buffer state described below). One HARQ receive buffer state indicates that the base station is expected to send a new packet, and the other HARQ receive buffer state indicates that the base station is expected to send a retransmission packet. This allows the terminal to feed back the HARQ receive buffer state to the base station, enabling the base station to clearly determine whether to send a new packet or a retransmission packet, thereby reducing invalid data packet transmission and improving data transmission efficiency.

[0042] It should be understood that, although under normal circumstances, the data packets sent by the base station based on the ACK / NACK feedback from the terminal are of the type that corresponds to the data packet type expected by the terminal's HARQ receive buffer state, there are also situations in which the type of data packets sent by the base station does not conform to the terminal's HARQ receive buffer state expectation.

[0043] For example, if the base station misinterprets a NACK sent by the terminal as an ACK, even though the terminal expects the base station to send a retransmission packet, the base station will send a new packet to the terminal based on the ACK. In this case, the base station will no longer send a retransmission packet to the terminal. Since the terminal cannot successfully receive the original data packet, it can only discard the original data packet and clear the data in the corresponding receive buffer of the HARQ process. This causes unwanted packet loss. For example, if the terminal still fails to decode transport block TB1 after two retransmissions, but a second retransmission would normally succeed, the base station will send a new transport block TB2 to the terminal because the terminal's NACK is misinterpreted as an ACK. TB1 will no longer be HARQ retransmitted, so TB1 will be lost, and the transmission resources of the previous TB1 retransmissions will be wasted. If the lost TB1 is retransmitted using upper-layer reliability guarantee mechanisms, it will consume transmission resources and reduce data transmission efficiency.

[0044] For example, if the base station misinterprets an ACK sent by the terminal as a NACK, even though the terminal has successfully decoded the packet and expects the base station to send a new packet, the base station will still send a retransmission packet to the terminal based on the NACK. In this case, the terminal no longer needs the retransmission packet, and the transmission of the retransmission packet wastes resources and reduces data transmission efficiency.

[0045] For example, if the terminal detects that the received time-sensitive data packet has expired, the terminal no longer needs to wait for the retransmission of the data packet. If the base station sends the retransmission packet at this time, it will waste transmission resources and reduce data transmission efficiency.

[0046] For example, due to receive window congestion or other hardware failures, the terminal needs to drop packets to ensure the normal reception of subsequent data. In this case, the terminal no longer needs to wait for the retransmission of the dropped data packets. If the base station then sends retransmission packets, it wastes transmission resources and reduces data transmission efficiency.

[0047] Based on the analysis, it can be seen that in the feedback mechanism of related technologies, there are cases where the base station sends data packets to the terminal that do not meet the terminal's requirements, which leads to a waste of data transmission resources and a reduction in data transmission efficiency.

[0048] The communication method provided in this disclosure can inform the base station of the terminal's HARQ receive buffer status, so that the base station can more accurately determine the type of data packet to be sent, ensure that the type of data packet sent by the base station meets the terminal's expectations, avoid sending invalid data packets, reduce unnecessary packet loss, reduce the waste of data transmission resources, and improve data transmission efficiency.

[0049] The communication method provided in this disclosure can be applied to systems with various communication standards. For example, it includes, but is not limited to, long-term evolution (LTE) systems, various versions based on LTE evolution, 5G systems, new radio (NR) systems, 5G NR systems, 5th generation new radio-advanced (5G-advanced) systems, and next-generation communication systems such as 6th generation (6G) systems. Furthermore, the communication method provided in this disclosure can also be applied to future-oriented communication technologies.

[0050] It should be understood that the receive buffer in this embodiment is a Hybrid Automatic Repeat Request (HARQ) receive buffer, the HARQ receive buffer corresponds to the receive buffer of the HARQ process, and the HARQ receive buffer status report corresponds to the receive buffer status report of the HARQ process. For ease of description, the HARQ receive buffer status can be simply referred to as the receive buffer status. Furthermore, the HARQ receive buffer status report can also be called a receive buffer status report, HARQ receive buffer status indication, receive end buffer status report, receive buffer report, receive end buffer status indication, receive end buffer status information, or receive end buffer status indication information, etc., and this embodiment does not limit the terminology used.

[0051] Figure 1 illustrates a communication system according to some embodiments of the present disclosure. The communication system includes a first node 110 and a second node 120, and a communication connection exists between the first node 110 and the second node 120.

[0052] The first node 110 can be a terminal, user equipment (UE), a handheld device with various communication functions, an in-vehicle device, a wearable device, a computer, a smart home device, or a smart office device, etc., and this disclosure does not limit this. The first node 110 is at least used to perform one or more steps in the communication method provided in this disclosure. For ease of understanding, the first node is described by way of example as a terminal.

[0053] The second node 120 can be a next-generation node (gNB), a transceiver point (TRP), an evolved node (eNB), a radio access point (AP), or an evolved node base station (eNB), a base station in a 5G network, or a base station in a 6G network, etc., and this disclosure does not limit it in this way. The second node 120 is at least used to perform one or more steps in the communication method provided in the embodiments of this disclosure. For ease of understanding, the second node is illustrated by example as a base station.

[0054] It should be understood that the examples of the communication systems described are merely for illustrating the technical solutions of the embodiments of this disclosure more clearly, and do not constitute a limitation of this disclosure. Those skilled in the art will recognize that, with the evolution of network architecture and the emergence of new service scenarios, the technical solutions provided in the embodiments of this disclosure are also applicable to similar technical problems.

[0055] The communication method provided by the embodiments of this disclosure will be described below with reference to the accompanying drawings. It should be noted that the various embodiments of this disclosure can be mutually referenced or understood. For example, the same or similar steps, method embodiments, and device embodiments can be mutually referenced, and the embodiments of this disclosure do not limit this.

[0056] As shown in Figure 2, this embodiment of the present disclosure provides a communication method applied to a first node, which includes steps S101 and S102.

[0057] S101. Generate a HARQ receive buffer status report, which is used to indicate the HARQ receive buffer status after the first node receives at least one data packet.

[0058] The HARQ receive buffer status is used to indicate whether the data packet the first node expects the second node to send is a new packet or a retransmission packet.

[0059] The HARQ receive buffer state includes at least one of the following: the HARQ receive buffer state of a single packet from a single HARQ process; the HARQ receive buffer state of multiple packets from a single HARQ process; or the HARQ receive buffer state of multiple HARQ processes. The HARQ receive buffer state of multiple HARQ processes can be the HARQ receive buffer state of multiple HARQ processes under a single HARQ entity, or the HARQ receive buffer state of multiple HARQ processes under multiple HARQ entities.

[0060] The at least one data packet includes: a data packet determined by the second node based on the HARQ receive buffer status report last sent by the first node; and / or, a data packet not determined by the second node based on the HARQ receive buffer status report last sent by the first node.

[0061] In some embodiments, the HARQ receive buffer state includes a first buffer state and a second buffer state. The first buffer state is used to indicate that the first node expects the second node to send a new packet, and the second buffer state is used to indicate that the first node expects the second node to send a retransmission packet.

[0062] As an example, the HARQ receive buffer state of the first node is set to the first buffer state if any of the following conditions are met: the first node successfully receives a data packet; the first node decides to discard the data packet; the first node clears the data in the receive buffer; or the first node transfers the data in the receive buffer (e.g., transferring the data in the receive buffer to an external buffer). For example, if the first node successfully receives a data packet from a certain HARQ process and expects the second node to send a new packet, then the HARQ receive buffer state of that HARQ process is set to the first buffer state.

[0063] As another example, the HARQ receive buffer state of the first node is set to the second buffer state if any of the following conditions are met: the first node fails to receive data; the first node stores the soft information of the received data packet in the receive buffer; the first node merges the soft information of the received data packet with the existing soft information in the receive buffer and stores the merged soft information data in the receive buffer. For example, if the first node fails to receive a data packet from a certain HARQ process and expects a retransmission, then the HARQ receive buffer state of that HARQ process is set to the second buffer state.

[0064] In some embodiments, the HARQ receive buffer status is indicated by binary bits. For example, a first buffer status of bit 0 indicates that the first node expects the second node to send a new packet; a second buffer status of bit 1 indicates that the first node expects the second node to send a retransmission packet.

[0065] In some embodiments, generating a HARQ receive buffer status report includes: directly generating a HARQ receive buffer status report based on the HARQ receive buffer status of each data packet. For example, the HARQ receive buffer status indication of a single data packet from a single HARQ process (1 bit) can be directly used as the HARQ receive buffer status report.

[0066] In some embodiments, the HARQ receive buffer status report includes a New Data Indicator (NDI), which is used to indicate the HARQ receive buffer status of a single data packet.

[0067] For example, the first node uses a new data indictor (NDI) to indicate the HARQ receive buffer state of a single data packet. The second node determines whether the first node's HARQ receive buffer state has changed by detecting NDI flips (e.g., flipping the NDI from bit 0 to bit 1, or from bit 1 to bit 0). For example, in the k-th HARQ process, the first node sends a HARQ receive buffer state report containing the NDI to the second node, which then saves the NDI. When the first node expects the second node to send a retransmission packet, the NDI remains unchanged. When the first node expects the second node to send a new packet, the NDI is flipped. When the NDI received by the second node is the same as the previously stored NDI, it considers the HARQ receive buffer state to indicate that the first node expects a retransmission packet, and thus sends a retransmission packet to the first node. When the NDI received by the second node is different from the previously stored NDI, it considers the HARQ receive buffer state to indicate that the first node expects a new packet, and thus sends a new packet to the first node. Therefore, a HARQ receive buffer status report can be generated directly using the new data indicator (NDI) to indicate the HARQ receive buffer status of a single data packet.

[0068] In some embodiments, the HARQ receive buffer status report includes a HARQ receive buffer status bitmap, which includes the HARQ receive buffer status of each data packet, and the HARQ receive buffer status of each data packet corresponds to one bit in the HARQ receive buffer status bitmap.

[0069] For example, the first node uses a HARQ receive buffer status bitmap as its HARQ receive buffer status report. The HARQ receive buffer status bitmap includes HARQ receive buffer status indicators for multiple data packets, with each data packet's HARQ receive buffer status corresponding to a single bit in the bitmap. Therefore, a HARQ receive buffer status report can be generated using a bitmap. For example, the first node uses a bitmap in its HARQ receive buffer status report to represent the HARQ receive buffer status of four HARQ processes (k to k+3), such as "0100," where 0 indicates anticipation of new packets and 1 indicates anticipation of retransmission packets. That is, HARQ processes k, k+2, and k+3 anticipate new packets from the second node, and HARQ process k+1 anticipates retransmission packets from the second node.

[0070] In some embodiments, generating a HARQ receive buffer status report includes: the first node generating an updated HARQ receive buffer status report after updating the HARQ receive buffer status of the receive buffer.

[0071] S102, Send a HARQ receive buffer status report to the second node.

[0072] The first node and the second node have a communication connection. It should be understood that when the first node sends a HARQ receive buffer status report to the second node, it is essentially reporting the HARQ receive buffer status of the first node after receiving at least one data packet.

[0073] In some embodiments, the HARQ receive buffer status report includes the HARQ receive buffer status of each data packet. The first node directly sends the HARQ receive buffer status report, which includes the HARQ receive buffer status of each data packet in the at least one data packet, such as by directly sending an NDI or by directly sending a HARQ receive buffer status bitmap.

[0074] In other embodiments, the HARQ receive buffer status report includes the HARQ receive buffer status of each data packet. The first node transmits the HARQ receive buffer status of each data packet in the at least one data packet mentioned in the HARQ receive buffer status report after joint encoding. For example, the first node adds a Cyclic Redundancy Check (CRC) check after jointly encoding the HARQ receive buffer status of each data packet. The joint encoding method of HARQ receive buffer status can provide encoding gain, and adding CRC check can ensure that all information passing the CRC check is correct. Compared with the method of only feeding back 1 bit ACK / NACK in HARQ, the joint encoding of HARQ receive buffer status can improve the accuracy of the terminal's feedback to the base station, thereby reducing the possibility of ACK / NACK misjudgment on the base station side.

[0075] In some embodiments, the transmission of HARQ receive buffer status reports is based on periodic triggering. For example, when the total number of HARQ processes in the first node is m, the transmission period of the HARQ receive buffer status report is configured to be once every n HARQ processes; where m and n are positive integers, and m is divisible by n. It should be noted that this can also be described as follows: the first node uses the transmission of every n HARQ processes as a transmission period, where n is divisible by the total number of HARQ processes m in the first node, and n is a positive integer; or, the total number of processes under a HARQ entity is an integer multiple of the transmission period value. For example, if the total number of HARQ processes is 32, corresponding to 32 parallel HARQ processes in a HARQ entity, the transmission period of the HARQ receive buffer status report is configured to be once every 4 HARQ processes. Through 8 transmissions, the first node reports the HARQ receive buffer status of all HARQ processes to the second node.

[0076] In some embodiments, the transmission of the buffer status report is event-triggered. For example, when the first node experiences receive window congestion and actively drops packets, it sends a HARQ receive buffer status report.

[0077] In some embodiments, in response to receiving a transmit enable instruction for a HARQ receive buffer status report sent by a second node, a first node sends a HARQ receive buffer status report to a second node, wherein the transmit enable instruction is used to trigger the first node to send the HARQ receive buffer status report.

[0078] In some embodiments, sending a HARQ receive buffer status report to a second node includes at least one of the following methods: sending the HARQ receive buffer status report using a physical uplink control channel (PUCCH); sending the HARQ receive buffer status report using a physical uplink shared channel (PUSCH); sending the HARQ receive buffer status report using uplink control information (UCI); and sending the HARQ receive buffer status report using a medium access control element (MAC CE). For example, the HARQ receive buffer status report can be placed on the MAC CE and transmitted using the PUSCH; for example, the HARQ receive buffer status report can be sent together with ACK / NACK via the PUCCH; for example, the HARQ receive buffer status report can be sent together with a scheduling request (SR), for example, by sending the HARQ receive buffer status report using newly defined dedicated control signaling in the UCI.

[0079] In some embodiments, the HARQ receive buffer status report is sent based on the configuration of the second node. For example, the first node can configure the triggering method, transmission method, encoding method, and data format of the HARQ receive buffer status report based on the configuration information of the HARQ receive buffer status report sent by the second node.

[0080] The communication method provided in this disclosure allows a first node to send a HARQ receive buffer status report to a second node, informing the second node of the HARQ receive buffer status after the first node has received at least one data packet. This enables the second node to monitor the current status of the first node's HARQ receive buffer. Furthermore, it facilitates the second node in sending data packets that meet the first node's requirements based on the HARQ receive buffer status. Therefore, invalid data packet transmissions and packet loss can be reduced, thereby avoiding waste of communication resources and improving data transmission efficiency.

[0081] In some embodiments, as shown in FIG3, after step S102, the method further includes step S103.

[0082] S103. Receive at least one data packet sent by the second node based on the HARQ receive buffer status report.

[0083] It should be understood that when the HARQ receive buffer status report indicates that the HARQ receive buffer status is in the first buffer state, it means that the HARQ process expects the second node to send a new packet to the HARQ process. When the HARQ receive buffer status report indicates that the HARQ receive buffer status is in the second buffer state, it means that the HARQ process expects the second node to send a retransmission packet to the HARQ process.

[0084] Furthermore, the second node sends the data packets of the HARQ process to the first node based on the received HARQ receive buffer status report (e.g., sending a new packet based on the first buffer status and a retransmission packet based on the second buffer status), so that the data packets received by the first node are consistent with expectations.

[0085] For example, the first buffer state is represented by bit 0, and the second buffer state is represented by bit 1. The first node successfully receives data in the k, k+2, and k+3 HARQ processes, but fails to receive data in the k+1 HARQ process. The first node sends a HARQ receive buffer state report with a state of "0100" for the four HARQ processes from k to k+3 to the second node. Even if the second node misinterprets an ACK as a NACK or vice versa, based on the HARQ receive buffer state report, it can still send new packets in the k, k+2, and k+3 HARQ processes and retransmit packets in the k+1 HARQ process. In subsequent HARQ process transmissions, the first node can then receive new packets in the k, k+2, and k+3 HARQ processes and retransmit packets in the k+1 HARQ process as expected. In other words, there will be no situation where the first node expects a new packet but receives a useless retransmission packet, or the first node expects a retransmission packet but can only discard the previous data packets because it receives a new packet.

[0086] The communication method provided in this embodiment enables a second node to send data packets to a first node based on the HARQ receive buffer state fed back by the first node. This makes the data packets sent by the second node more consistent with the HARQ receive buffer state of the first node, avoiding invalid data packet transmission and packet loss, and improving the efficiency of data transmission.

[0087] It should be noted that step S103 is optional. That is, although the second node can determine the type of data packet to send to the first node based on the HARQ receive buffer status report, the second node may also choose not to send data packets to the first node based on the HARQ receive buffer status report. For example, the second node only sends data packets to the first node based on the HARQ receive buffer status report if the HARQ receive buffer status decision function is enabled. Conversely, the second node does not send data packets to the first node based on the HARQ receive buffer status report if the HARQ receive buffer status decision function is not enabled. Furthermore, the second node does not send data packets to the first node based on the HARQ receive buffer status report until it receives it. Alternatively, the second node can decide for itself whether to send data packets to the first node based on the HARQ receive buffer status report. The second node may send data packets based solely on HARQ ACK / NACK feedback, solely on the HARQ receive buffer status report, or a combination of HARQ ACK / NACK feedback and the HARQ receive buffer status report.

[0088] In some embodiments, as shown in FIG4, the method further includes the following step S104 before step S101.

[0089] S104. The first node receives at least one data packet sent by the second node and determines the HARQ receive buffer state after the first node receives at least one data packet.

[0090] The HARQ receive buffer state includes the HARQ receive buffer state of at least one data packet. The HARQ receive buffer state of each data packet corresponds to the HARQ receive buffer state of each HARQ process, reflecting the first node's expectation that the second node will send data packets to that HARQ process. After receiving a data packet, the first node updates the HARQ receive buffer state and determines the updated HARQ receive buffer state as the HARQ receive buffer state after the first node has received at least one data packet.

[0091] In some embodiments, as shown in FIG5, the method further includes the step S105.

[0092] S105. Receive the HARQ receive buffer status report configuration information sent by the second node; configure the HARQ receive buffer status report based on the HARQ receive buffer status report configuration information.

[0093] In some embodiments, the HARQ receive cache status report configuration information includes at least one of the following.

[0094] (1) Triggering methods for HARQ receive cache status reports. Triggering methods include: periodic triggering or event triggering.

[0095] (2) HARQ receive buffer status report sending period. When triggered by a period, the HARQ receive buffer status report sending period is also configured so that the first node sends the HARQ receive buffer status report periodically as agreed.

[0096] (3) Indication of HARQ receive buffer status report triggering event. When triggered by an event, an indication of the HARQ receive buffer status report triggering event is also configured, enabling the first node to send non-periodic HARQ receive buffer status reports when a sudden event occurs. For example, due to hardware failure or receive window congestion, the first node experiences a large number of packet losses and triggers the HARQ receive buffer status report. For example, the first node detects that a data packet sent by the second node is not the data packet the first node expected, triggering the HARQ receive buffer status report.

[0097] (4) Enable indication for sending HARQ receive buffer status report. For example, if the second node needs to know the current HARQ receive buffer status of the first node, the configuration information for sending enable indication will trigger the first node to report the HARQ receive buffer status report.

[0098] (5) The time-frequency resources corresponding to the HARQ receive buffer status report, that is, the time-frequency resources used when sending the HARQ receive buffer status report. The first node uses the time-frequency resources to send the HARQ receive buffer status report, and the second node receives the HARQ receive buffer status report on the time-frequency resources.

[0099] (6) The space reuse method used when sending HARQ receive buffer status reports.

[0100] (7) The transmission method used when sending the HARQ receive buffer status report. For example, the HARQ receive buffer status report may be sent using PUCCH, PUSCH, UCI, or MAC CE.

[0101] (8) Cache indication corresponding to the HARQ receive buffer status report. For example, the cache indication may be at least one of the following: HARQ process identifier, number of HARQ processes, data packet identifier, number of data packets, cache address index, etc. For example, a receive buffer corresponds to a HARQ process identifier, and the receive buffer of the corresponding HARQ process can be indicated through the HARQ process identifier. For example, the data packet identifier may be a TB identifier, TB index, etc., and the receive buffer corresponding to the data packet can be indicated through the data packet identifier. For example, the cache indication may be the starting data packet index, the ending data packet index, the number of data packets, the starting HARQ process ID, the ending HARQ process ID, and the number of HARQ processes. For example, through the starting HARQ process ID and the number of HARQ processes, the first node knows from which HARQ process to start and the HARQ receive buffer status of several consecutive HARQ processes as the content reported in the HARQ receive buffer status report. It should be understood that when the first node receives at least one data packet that is multiple data packets, the HARQ receive buffer status report may include the HARQ receive buffer status of multiple data packets. The second node can use cache indicators to inform the first node which HARQ process and / or which data packets' HARQ receive cache status to send.

[0102] (9) The modulation and coding scheme (MCS) used when sending the HARQ receive buffer status report. The first node uses the MCS to jointly encode the HARQ receive buffer status of multiple data packets (or multiple HARQ processes). Since the encoding has coding gain and includes a parity bit, the reliability of the HARQ receive buffer status report being correctly received by the second node is improved, thereby correcting the ACK / NACK misjudgment problem.

[0103] It should be noted that the naming of the HARQ receive cache status report configuration information is only an example, and it can also be directly named configuration information, cache status configuration information, report configuration information, etc. This disclosure embodiment does not limit this.

[0104] In some embodiments, the HARQ receive buffer status report configuration information is sent by the second node based on control signaling. Exemplarily, step S105 includes at least one of the following: receiving a radio resource control (RRC) message sent by the second node, the RRC message carrying the HARQ receive buffer status report configuration information; receiving downlink control information (DCI) sent by the second node, the DCI carrying the HARQ receive buffer status report configuration information; and receiving an unsolicited-link grant (UL grant) sent by the second node, the UL grant carrying the HARQ receive buffer status report configuration information.

[0105] In one example, the RRC message includes HARQ receive cache status report configuration information, for instance, by including a field for HARQ receive cache status report configuration information in the RRC reconfiguration message.

[0106] In some embodiments, as shown in FIG6, the method further includes step S106.

[0107] S106. The first node sends a configuration request message to the second node. The configuration request message is used to request the second node to send HARQ receive cache status report configuration information.

[0108] In some embodiments, step S105 can be implemented as: receiving a configuration request response sent by the second node, wherein the configuration request response includes HARQ receive cache status report configuration information.

[0109] In some embodiments, the configuration request information includes the resources required to send the HARQ receive cache status report, and the HARQ receive cache status report configuration information is generated by the second node based on the configuration request.

[0110] It should be noted that the steps in the communication method can be combined with each other. For example, the first node may only execute steps S101 and S102. Alternatively, the first node may execute steps S105, S101, and S102. Another example is that the first node may execute steps S106, S105, S101, and S102. Yet another example is that the first node may execute steps S101, S102, and S103. Yet another example is that the first node may execute steps S104, S101, S102, and S103. This disclosure does not limit the scope of the embodiments.

[0111] As can be seen, the above description mainly focuses on the communication method provided by the embodiments of this disclosure from the perspective of the first node. Embodiments of this disclosure also provide a communication method applied to a second node.

[0112] As shown in Figure 7, this embodiment of the present disclosure provides a communication method applied to a second node, the method including steps S201 and S202.

[0113] S201, Send at least one data packet to the first node.

[0114] The at least one data packet includes: a data packet determined by the second node based on the HARQ receive buffer status report last sent by the first node; and / or, a data packet not determined by the second node based on the HARQ receive buffer status report last sent by the first node.

[0115] For example, before the second node receives the HARQ receive buffer status report, it sends at least one data packet to the first node.

[0116] For example, the second node sends at least one data packet based only on HARQ ACK / NACK feedback.

[0117] For example, the second node sends at least one data packet based on the obtained HARQ receive buffer status report.

[0118] For example, the second node sends at least one data packet after comprehensively considering the HARQ ACK / NACK feedback and the obtained HARQ receive buffer status report.

[0119] S202. Receive the HARQ receive buffer status report sent by the first node. The HARQ receive buffer status report is used to indicate the HARQ receive buffer status after the first node has received at least one data packet.

[0120] The HARQ receive buffer state is used to indicate whether the data packet the first node expects the second node to send is a new packet or a retransmission packet. The HARQ receive buffer state includes at least one of the following: the HARQ receive buffer state of a single data packet from a single HARQ process; the HARQ receive buffer state of multiple data packets from a single HARQ process; or the HARQ receive buffer state of multiple HARQ processes. The HARQ receive buffer state of multiple HARQ processes can be the HARQ receive buffer state of multiple HARQ processes under a single HARQ entity, or the HARQ receive buffer state of multiple HARQ processes under multiple HARQ entities.

[0121] For details regarding HARQ receive buffer status reports (such as sending cycle, buffer type, and transmission method), please refer to the description above, which will not be repeated here.

[0122] HARQ receive buffer status includes a first buffer status and a second buffer status. The first buffer status indicates that the first node expects the second node to send a new packet, and the second buffer status indicates that the first node expects the second node to send a retransmission packet.

[0123] It should be understood that when the HARQ receive buffer status report indicates that the HARQ receive buffer status is in the first buffer state, it means that the HARQ process expects the second node to send a new packet to the HARQ process. When the HARQ receive buffer status report indicates that the HARQ receive buffer status is in the second buffer state, it means that the HARQ process expects the second node to send a retransmission packet to the HARQ process.

[0124] Furthermore, the second node sends data packets for that HARQ process to the first node based on the received HARQ receive buffer status report (e.g., sending new packets based on the first buffer status and retransmission packets based on the second buffer status), ensuring that the data packets received by the first node are consistent with expectations. For example, the first buffer status is represented by bit 0, and the second buffer status is represented by bit 1. The first node successfully receives data in the k, k+2, and k+3 HARQ processes, but fails to receive data in the k+1 HARQ process. The first node sends a HARQ receive buffer status report with a HARQ receive buffer status of "0100" for the four HARQ processes from k to k+3 to the second node. Even if the second node misinterprets an ACK as a NACK or a NACK as an ACK, it can still send new packets in the k, k+2, and k+3 HARQ processes and retransmission packets in the k+1 HARQ process based on the aforementioned HARQ receive buffer status report. In subsequent HARQ processes, the first node can expect to receive new packets in the k, k+2, and k+3 HARQ processes, and retransmitted packets in the k+1 HARQ process. That is, there will be no situation where the first node expects new packets but receives useless retransmitted packets, or the first node expects retransmitted packets but, because it receives new packets, has to discard previous data packets, resulting in packet loss.

[0125] In some embodiments, step S202 includes at least one of the following: receiving the HARQ receive buffer status report on the PUCCH; receiving the HARQ receive buffer status report on the PUSCH; receiving uplink control information UCI sent by the first node, the UCI including the HARQ receive buffer status report; receiving a media access control unit MAC CE sent by the first node, the MAC CE including the HARQ receive buffer status report.

[0126] In some embodiments, after step S202, the method further includes: directly obtaining the HARQ receive buffer status of each data packet based on the HARQ receive buffer status report; or, jointly decoding the HARQ receive buffer status report to obtain the HARQ receive buffer status of each data packet.

[0127] The communication method provided in this disclosure can obtain the HARQ receive buffer status of the first node after receiving at least one data packet by receiving a HARQ receive buffer status report sent by the first node. On the one hand, this enables the second node to monitor the current status of the first node's HARQ receive buffer. On the other hand, it facilitates the second node in sending data packets that meet the first node's requirements based on the HARQ receive buffer status. Therefore, invalid data packet transmissions and packet loss can be reduced, thereby avoiding waste of communication resources and improving data transmission efficiency.

[0128] In some embodiments, as shown in FIG8, the method further includes step S203.

[0129] S203, Send at least one data packet determined based on the HARQ receive buffer status report to the first node.

[0130] In some embodiments, when the HARQ receive buffer is in a first buffer state, the second node sends a new packet to the first node; or, when the HARQ receive buffer is in a second buffer state, the second node sends a retransmission packet to the first node.

[0131] In some cases, the ACK / NACK feedback received by the second node conflicts with the HARQ receive buffer state of the first node.

[0132] It should be understood that after the second node receives the HARQ feedback and HARQ receive buffer status report sent by the first node, if it finds that the first node has responded with a NACK for a certain HARQ, but the HARQ receive buffer status report of the corresponding HARQ process indicates a first buffer status, it means that the first node expects the second node to send a new packet, not a retransmitted packet. Similarly, if the second node receives the HARQ feedback and HARQ receive buffer status report sent by the first node, and finds that the first node has responded with an ACK for a certain HARQ, but the HARQ receive buffer status report of the corresponding HARQ process indicates a second buffer status, it means that the first node expects the second node to send a retransmitted packet, not a new packet.

[0133] For example, in any of the following situations, although the second node receives a NACK feedback, the first node actually expects the second node to send a new packet: the second node misinterprets an ACK as a NACK; the data packet received by the first node expires; the first node has successfully received a data packet through another link; the first node waits for a data packet for too long and actively drops the packet, abandoning retransmission. By sending an indication of the first buffer state, the second node understands that the first node expects it to send a new packet. Based on the method provided in this disclosure embodiment, the HARQ receive buffer state report can be used to inform the second node of the first node's HARQ receive buffer state, thereby avoiding the base station sending useless retransmission packets, reducing the waste of data transmission resources, and improving data transmission efficiency.

[0134] For example, if the second node misinterprets a NACK as an ACK, although the second node receives the ACK, the first node actually expects the second node to send a retransmission packet. By sending an indication of the second buffer state, the second node understands that the first node expects it to send a retransmission packet. Based on the method provided in this disclosure, the HARQ receive buffer state report can be used to inform the second node of the first node's HARQ receive buffer state, thereby avoiding the base station directly sending new packets, which could lead to the loss of original data packets and improve the reliability of data transmission.

[0135] In some embodiments, as shown in FIG9, the method further includes step S204 before the second node receives the HARQ receive buffer status report.

[0136] S204. Send HARQ receive buffer status report configuration information to the first node. The HARQ receive buffer status report configuration information is used by the first node to configure the HARQ receive buffer status report.

[0137] The configuration information for HARQ receive buffer status reports can be found in the description above, and will not be repeated here.

[0138] In some embodiments, step S204 includes at least one of the following: sending a Radio Resource Control (RRC) message to the first node, the RRC message carrying HARQ receive buffer status report configuration information; sending downlink control information (DCI) to the first node, the DCI carrying HARQ receive buffer status report configuration information; and sending an uplink grant (UL grant) to the first node, the UL grant carrying HARQ receive buffer status report configuration information.

[0139] In some embodiments, as shown in FIG10, the method further includes step S205.

[0140] S205. Receive configuration request information sent by the first node. The configuration request information is used to request the second node to send HARQ receive cache status report configuration information.

[0141] In some embodiments, step S205 can be implemented as: sending a configuration request response to the first node, the configuration request response including HARQ receive cache status report configuration information. It should be noted that the steps in the communication method can be combined with each other. For example, the second node can execute only steps S201 and S202. Alternatively, the second node can execute only steps S201, S202, and S203. Another example is that the second node can execute steps S204, S201, and S202. Yet another example is that the second node can execute steps S204, S201, S202, and S203. Yet another example is that the second node can execute steps S205, S204, S201, S202, and S203. This disclosure does not limit the scope of the embodiments.

[0142] To more clearly illustrate the methods provided in the embodiments of this disclosure, several example embodiments are provided below to describe the methods provided in the embodiments of this disclosure.

[0143] (I) Example 1

[0144] In wireless communication, due to the limited transmit power of terminals, and under poor channel conditions or interference, the HARQ ACK feedback received by the base station has a certain probability of error. The base station may misinterpret an ACK from the terminal as a NACK, and vice versa. When such misinterpretations occur, if the base station only uses the HARQ ACK feedback mechanism for ACK / NACK feedback when transmitting data, the data packets sent by the base station to the terminal will not meet the terminal's expectations.

[0145] Taking the example of a terminal successfully receiving TB1 and sending an ACK feedback, when the base station misinterprets the ACK as a NACK, it assumes that the current data packet TB1 has not been successfully received by the terminal and sends a retransmission packet of TB1. However, in reality, the terminal has already successfully received the current data packet and expects the base station to send a new data packet (such as TB2). If the terminal expects a new packet but the base station sends a retransmission packet, then this retransmission packet is a useless packet that can be discarded by the terminal. Transmitting this useless retransmission packet is a waste of resources and also reduces the data transmission rate.

[0146] Taking the example of a terminal failing to receive TB1 and sending a NACK feedback, when the base station misinterprets NACK as ACK, it assumes that the current data packet TB1 has been successfully received by the terminal and sends a new data packet (such as TB2). However, in reality, the terminal did not successfully receive TB1 and expects the base station to send a retransmission packet of TB1. Since the base station sends a new packet TB2, the terminal cannot receive the TB1 retransmission packet, resulting in TB1 packet loss on the terminal side. This is especially problematic when TB1 has already undergone several retransmissions and is about to be successfully decoded via soft information merging. The loss of TB1 due to this misinterpretation severely wastes transmission resources and reduces the data transmission rate.

[0147] When the terminal sends a HARQ receive buffer status report to the base station, the HARQ receive buffer status report may include at least one of the following: the HARQ receive buffer status of a single data packet of a HARQ process; the HARQ receive buffer status of multiple data packets of a HARQ process; or the HARQ receive buffer status of multiple HARQ processes.

[0148] Whether it's a new transmission or a retransmission, as long as the terminal successfully receives data, it will clear the receive buffer of the data packet corresponding to the HARQ process to prepare for the upcoming new packet. Whether it's a new transmission or a retransmission, as long as the data packet transmission has not reached the maximum retransmission count and the terminal fails to receive data, it will store the soft information of the data packet corresponding to the HARQ process in the receive buffer. If the data packet transmission has reached the maximum retransmission count, the base station will not retransmit the data packet again, and the terminal will also clear the corresponding receive buffer to prepare for the upcoming new packet. Therefore, as long as the receive buffer is cleared, it means the buffer state is expecting the base station to send a new packet. As long as the receive buffer stores the soft information of the received data, it means the buffer state is expecting the base station to send a retransmission packet. Therefore, it can be considered that the HARQ receive buffer state of each data packet has two types (such as the first buffer state and the second buffer state mentioned above): one is expecting the base station to send a new packet, and the other is expecting the base station to send a retransmission packet.

[0149] Terminals use HARQ receive buffer status reports to provide feedback on their HARQ receive buffer status. This allows the base station to have a more accurate understanding of the data packets received by the terminal, reducing the possibility of misinterpretations of ACK / NACK feedback. In particular, the use of joint coding in the transmission of HARQ receive buffer status reports, with its coding gain and parity bits, makes the base station's reception of these reports more accurate. For example, if an ACK is misinterpreted as a NACK, and the base station learns from the HARQ receive buffer status report that the corresponding HARQ process's HARQ receive buffer status is awaiting a new packet, then the base station knows that the ACK was misinterpreted as a NACK and needs to send a new packet instead of retransmitting a packet based on the NACK. Similarly, if a NACK is misinterpreted as an ACK, and the base station learns from the HARQ receive buffer status report that the corresponding HARQ process's HARQ receive buffer status is awaiting a retransmission, then the base station knows that the NACK was misinterpreted as an ACK and needs to send a retransmission packet instead of sending a new packet based on the ACK.

[0150] As can be seen, the base station can send data packets that meet the needs of the terminal based on the HARQ receive buffer status report, thus improving data transmission efficiency.

[0151] (II) Example 2

[0152] In communication scenarios, there are situations where a terminal fails to receive a data packet and sends a NACK, but expects the base station to transmit a new packet. For example, in any of the following situations, the terminal will actively drop packets and clear its receive buffer: the terminal's data packet receive timer times out; the terminal's data receive window is congested; the terminal experiences a hardware failure; the data packet received by the terminal is time-sensitive data, and the time-sensitive data has expired, etc.

[0153] In such cases, the base station will typically send unnecessary retransmission packets based on NACK, resulting in a waste of transmission resources.

[0154] However, the communication method provided in this embodiment involves the terminal sending a HARQ receive buffer status report back to the base station after receiving the data packet, so that the base station can determine whether the data the terminal expects the base station to send is a new packet or a retransmission packet based on the HARQ receive buffer status report, thereby avoiding the base station from sending unnecessary retransmission packets to the terminal and reducing the waste of data transmission resources.

[0155] (III) Example 3

[0156] The communication method provided in this disclosure embodiment will be briefly described below from the perspective of terminal and base station interaction. Referring to FIG11, this disclosure also provides a communication method, including the following steps S301 to S306.

[0157] S301. The terminal sends a configuration request message to the base station; correspondingly, the base station receives the configuration request message sent by the terminal.

[0158] The configuration request information is used to request the base station to send the HARQ receive buffer status report configuration information.

[0159] S302, The base station sends HARQ receive buffer status report configuration information to the terminal; correspondingly, the terminal receives the HARQ receive buffer status report configuration information.

[0160] The relevant information regarding the HARQ receive cache status report configuration can be found in the description above.

[0161] It should be noted that step S301 is not mandatory. For example, the base station may send HARQ receive buffer status report configuration information to the terminal by default, or it may send HARQ receive buffer status report configuration information to the terminal in response to a configuration request.

[0162] Furthermore, the terminal configures the HARQ receive buffer status report based on the HARQ receive buffer status report configuration information.

[0163] S303, The base station sends at least one data packet to the terminal; correspondingly, the terminal receives at least one data packet sent by the base station.

[0164] Furthermore, based on the reception status of at least one data packet, the terminal performs a receive buffer processing operation and determines the HARQ receive buffer state after the terminal has received at least one data packet.

[0165] S304. The terminal generates a HARQ receive buffer status report. The HARQ receive buffer status report is used to indicate the HARQ receive buffer status after the terminal has received at least one data packet.

[0166] S305. The terminal sends the HARQ receive buffer status report to the base station; correspondingly, the base station receives the HARQ receive buffer status report.

[0167] S306. The base station sends at least one data packet to the terminal based on the HARQ receive buffer status report.

[0168] When the HARQ receive buffer is in the first buffer state, the base station sends a new packet to the terminal; or, when the HARQ receive buffer is in the second buffer state, the base station sends a retransmission packet to the terminal.

[0169] Based on this, the base station can send data packets to the terminal based on the HARQ receive buffer state fed back by the terminal. This ensures that the data packets sent by the base station are more consistent with the terminal's HARQ receive buffer state, avoiding the transmission of invalid data packets and improving data transmission efficiency. On one hand, it allows the base station to monitor the HARQ receive buffer state. On the other hand, it helps the base station send data packets that meet the terminal's requirements based on the HARQ receive buffer state, avoiding the transmission of invalid data packets and reducing duplicate data transmissions. Therefore, it can reduce the waste of communication resources and improve data transmission efficiency.

[0170] As can be seen, the description primarily focuses on the methodological aspects of the solutions provided in this disclosure. To achieve the described functions, this disclosure provides corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0171] The related apparatus provided in the embodiments of this disclosure will be described below. It should be understood that the communication apparatus described below can be referred to in correspondence with the communication method described above.

[0172] This disclosure also provides a first node, which includes a report generation module and a first communication module. In some embodiments, the first node further includes a report configuration module and / or a cache operation module.

[0173] The report generation module is used to generate a HARQ receive buffer status report, which is used to indicate the HARQ receive buffer status after the first node receives at least one data packet.

[0174] The first communication module is used to send the HARQ receive buffer status report to the second node.

[0175] In some embodiments, the first communication module is further configured to receive HARQ receive buffer status report configuration information sent by the second node.

[0176] In some embodiments, the report configuration module is used to configure the HARQ receive cache status report based on HARQ receive cache status report configuration information.

[0177] In some embodiments, the first communication module is further configured to send a configuration request to the second node, the configuration request being used to request the second node to send the HARQ receive cache status report configuration information; the first communication module is configured to receive a configuration request response sent by the second node, the configuration request response including the HARQ receive cache status report configuration information.

[0178] In some embodiments, the first communication module is configured to: receive a Radio Resource Control (RRC) message sent by the second node, the RRC message carrying the HARQ Receive Buffer Status Report configuration information; receive Downlink Control Information (DCI) sent by the second node, the DCI carrying the HARQ Receive Buffer Status Report configuration information; and receive an Uplink Grant (UL grant) sent by the second node, the UL grant carrying the HARQ Receive Buffer Status Report configuration information.

[0179] In some embodiments, the first communication module is configured to directly send a HARQ receive buffer status report including the HARQ receive buffer status of each data packet in the at least one data packet; or, to send the HARQ receive buffer status of each data packet in the at least one data packet in the HARQ receive buffer status report after joint encoding.

[0180] In some embodiments, the caching operation module is configured to update the HARQ receive buffer state when any of the following conditions are met: the first node successfully receives any one of the at least one data packets; the first node fails to receive any one of the at least one data packets; the first node actively discards any one of the at least one data packets; the first node's data packet receive timer times out; the first node's data packet receive window is congested; or the first node experiences a hardware failure.

[0181] In some embodiments, the first communication module is configured to: transmit the HARQ receive buffer status report using the Physical Uplink Control Channel (PUCCH); transmit the HARQ receive buffer status report using the Physical Uplink Shared Channel (PUSCH); transmit the HARQ receive buffer status report using Uplink Control Information (UCI); or transmit the HARQ receive buffer status report using the Media Access Control Unit (MAC CE).

[0182] This disclosure also provides a second node, which includes a second communication module. In some embodiments, the second node further includes a report processing module.

[0183] The second communication module is used to send at least one data packet to the first node; and to receive a HARQ receive buffer status report sent by the first node, wherein the HARQ receive buffer status report is used to indicate the HARQ receive buffer status of the first node after receiving the at least one data packet.

[0184] In some embodiments, the second communication module is further configured to send HARQ receive buffer status report configuration information to the first node, wherein the HARQ receive buffer status report configuration information is used by the first node to configure the HARQ receive buffer status report.

[0185] In some embodiments, the second communication module is further configured to receive a configuration request sent by the first node, the configuration request being used to request the second node to send the HARQ receive cache status report configuration information; the second communication module is configured to send a configuration request response to the second node, the configuration request response including the HARQ receive cache status report configuration information.

[0186] In some embodiments, the second communication module is configured to: send a Radio Resource Control (RRC) message to the first node, the RRC message carrying the HARQ Receive Buffer Status Report configuration information; send Downlink Control Information (DCI) to the first node, the DCI carrying the HARQ Receive Buffer Status Report configuration information; and send an Uplink Grant (UL grant) to the first node, the UL grant carrying the HARQ Receive Buffer Status Report configuration information.

[0187] In some embodiments, the report processing module is configured to, after receiving the HARQ receive buffer status report sent by the first node, directly obtain the HARQ receive buffer status of each data packet in the at least one data packet based on the HARQ receive buffer status report; or, jointly decode the HARQ receive buffer status report to obtain the HARQ receive buffer status of each data packet in the at least one data packet.

[0188] In some embodiments, the second communication module is configured to: receive a Physical Uplink Control Channel (PUCCH) sent by the first node, wherein the HARQ receive buffer status report is carried on the PUCCH; receive a Physical Uplink Shared Channel (PUSCH) sent by the first node, wherein the HARQ receive buffer status report is carried on the PUSCH; receive Uplink Control Information (UCI) sent by the first node, wherein the UCI includes the HARQ receive buffer status report; and receive a Media Access Control Unit (MAC CE) sent by the first node, wherein the MAC CE includes the HARQ receive buffer status report.

[0189] It should be noted that the module division described is illustrative and represents only one logical functional division; in actual implementation, other division methods are possible. For example, two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module.

[0190] In the case where the integrated module's functionality is implemented in hardware, this disclosure also provides a structure for a communication device used to execute the communication method provided in this disclosure. Similarly, the communication device and the communication method described above can be referred to in correspondence with each other.

[0191] As shown in Figure 12, the communication device includes a processor 1202 and a communication interface 1203. In some examples, the communication device may also include at least one of a bus 1204 and a memory 1201.

[0192] Processor 1202 can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 1202 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof, all of which can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 1202 can also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0193] The communication interface 1203 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0194] The memory 1201 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0195] In one implementation, the memory 1201 can exist independently of the processor 1202. The memory 1201 can be connected to the processor 1202 via a bus 1204 to store instructions or program code executable by the processor 1202, such as computer program instructions. When the processor 1202 calls and executes the instructions or program code stored in the memory 1201, it can implement the communication method provided in this embodiment.

[0196] In another implementation, the memory 1201 can also be integrated with the processor 1202.

[0197] Bus 1204 can be an extended industry standard architecture (EISA) bus, etc. Bus 1204 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in Figure 12, but this does not mean that there is only one bus or one type of bus.

[0198] Some embodiments of this disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a computer, cause the computer to perform the communication method as described in any of the embodiments. It should be understood that this disclosure does not limit the form of the computer.

[0199] In some examples, the computer-readable storage medium may include, but is not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0200] This disclosure provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the communication method described in any of the embodiments described herein.

[0201] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions within the technical scope disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A communication method, wherein, The method is applied to a first node, and the method comprises: generating a hybrid automatic repeat request (HARQ) reception buffer status report (BSR) for indicating a HARQ reception buffer status after the first node receives at least one data packet; sending the HARQ reception BSR to a second node.

2. The method of claim 1, wherein, The HARQ reception BSR comprises a first buffer status and a second buffer status, the first buffer status is used to indicate that the first node expects the second node to send a new packet, and the second buffer status is used to indicate that the first node expects the second node to send a retransmission packet.

3. The method of claim 1, wherein, The HARQ reception BSR comprises at least one of the following: a HARQ reception buffer status of a single data packet in a HARQ process; a HARQ reception buffer status of multiple data packets in a HARQ process; a HARQ reception buffer status of multiple HARQ processes.

4. The method of claim 1, wherein, Before sending the HARQ reception BSR to the second node, the method further comprises: receiving HARQ reception BSR configuration information sent by the second node; configuring the HARQ reception BSR based on the HARQ reception BSR configuration information.

5. The method of claim 4, wherein, The method further comprises: sending a configuration request to the second node, the configuration request being used to request the second node to send the HARQ reception BSR configuration information; receiving the HARQ reception BSR configuration information sent by the second node, comprising: receiving a configuration request response sent by the second node, the configuration request response comprising the HARQ reception BSR configuration information.

6. The method of claim 4 or 5, wherein, The HARQ reception BSR configuration information comprises at least one of the following: a triggering mode of the HARQ reception BSR, the triggering mode comprising a periodic triggering or an event-based triggering; a sending period of the HARQ reception BSR; a sending enabling indication of the HARQ reception BSR, the sending enabling indication being used to trigger the first node to send the HARQ reception BSR; an indication of a triggering event of the HARQ reception BSR; a time-frequency resource used when the HARQ reception BSR is sent; a spatial multiplexing mode used when the HARQ reception BSR is sent; a transmission mode used when the HARQ reception BSR is sent; a buffer indication corresponding to the HARQ reception BSR; a modulation and coding mode used when the HARQ reception BSR is sent.

7. The method of claim 6, wherein, In a case where a total number of HARQ processes configured in the first node is m, a sending period of the HARQ reception BSR is configured to be sent once every n HARQ processes; wherein m and n are positive integers, and m is divisible by n.

8. The method of claim 6, wherein, The buffer indication corresponding to the HARQ reception BSR comprises at least one of the following: a HARQ process identifier, a number of HARQ processes, a data packet identifier, a number of data packets, and a buffer address index.

9. The method of claim 4, wherein, receiving the HARQ reception buffer status report configuration information sent by the second node, including at least one of the following: receiving a radio resource control (RRC) message sent by the second node, wherein the RRC message carries the HARQ reception buffer status report configuration information; receiving a downlink control information (DCI) sent by the second node, wherein the DCI carries the HARQ reception buffer status report configuration information; receiving an uplink grant (UL grant) sent by the second node, wherein the UL grant carries the HARQ reception buffer status report configuration information.

10. The method of claim 1, wherein, the HARQ reception buffer status report includes the HARQ reception buffer status of each data packet in the at least one data packet; sending the HARQ reception buffer status report to the second node, including: directly sending the HARQ reception buffer status report including the HARQ reception buffer status of each data packet in the at least one data packet; or jointly encoding the HARQ reception buffer status of each data packet in the at least one data packet in the HARQ reception buffer status report and then sending the HARQ reception buffer status report.

11. The method of claim 1, wherein: the HARQ reception buffer status report includes a new data indicator (NDI) used to indicate the HARQ reception buffer status of a single data packet; and / or the HARQ reception buffer status report includes a HARQ reception buffer status bitmap including the HARQ reception buffer status of each data packet in the at least one data packet, and the HARQ reception buffer status of each data packet in the at least one data packet corresponds to one bit in the HARQ reception buffer status bitmap. The method further includes:

12. The method of claim 1, wherein, updating, by the first node, the HARQ reception buffer status when any of the following conditions is met: the first node successfully receives any data packet in the at least one data packet; the first node fails to receive any data packet in the at least one data packet; the first node actively discards any data packet in the at least one data packet; a data packet reception timer of the first node expires; a data packet reception window of the first node is congested; the first node experiences a hardware failure. sending the HARQ reception buffer status report to the second node, including at least one of the following:

13. The method of claim 1, wherein, sending the HARQ reception buffer status report using a physical uplink control channel (PUCCH); sending the HARQ reception buffer status report using a physical uplink shared channel (PUSCH); sending the HARQ reception buffer status report using uplink control information (UCI); sending the HARQ reception buffer status report using a medium access control control element (MAC CE). The method is applied to a second node, and the method includes:

14. A communication method, wherein, sending at least one data packet to a first node; ​ receiving a HARQ reception buffer status report sent by the first node, the HARQ reception buffer status report being used to indicate a HARQ reception buffer status of the first node after receiving the at least one data packet.

15. The method of claim 14, wherein, After receiving the HARQ reception buffer status report sent by the first node, the method further comprises: sending at least one data packet determined based on the HARQ reception buffer status report to the first node.

16. The method of claim 14, wherein, The HARQ reception buffer status comprises a first buffer status and a second buffer status, the first buffer status being used to indicate that the first node expects the second node to send a new packet, and the second buffer status being used to indicate that the first node expects the second node to send a retransmission packet.

17. The method of claim 14, wherein, The HARQ reception buffer status comprises at least one of: a HARQ reception buffer status of a single data packet of a HARQ process; a HARQ reception buffer status of multiple data packets of a HARQ process; a HARQ reception buffer status of multiple HARQ processes.

18. The method of claim 14, wherein, Before receiving the HARQ reception buffer status report sent by the first node, the method further comprises: sending HARQ reception buffer status report configuration information to the first node, the HARQ reception buffer status report configuration information being used to configure the HARQ reception buffer status report by the first node.

19. The method of claim 18, wherein, The method further comprises: receiving a configuration request sent by the first node, the configuration request being used to request the second node to send the HARQ reception buffer status report configuration information; sending the HARQ reception buffer status report configuration information to the first node, comprising: sending a configuration request response to the second node, the configuration request response comprising the HARQ reception buffer status report configuration information.

20. The method of claim 18 or 19, wherein, The HARQ reception buffer status report configuration information comprises at least one of: a triggering mode of the HARQ reception buffer status report, the triggering mode comprising a periodic triggering or an event-based triggering; a sending period of the HARQ reception buffer status report; a sending enabling indication of the HARQ reception buffer status report, the sending enabling indication being used to trigger the first node to send the HARQ reception buffer status report; an indication of a HARQ reception buffer status report triggering event, the indication of the HARQ reception buffer status report triggering event being used to configure a triggering event triggering the sending of the HARQ reception buffer status report; a time-frequency resource used when sending the HARQ reception buffer status report; a spatial multiplexing mode used when sending the HARQ reception buffer status report; a transmission mode used when sending the HARQ reception buffer status report; a buffer indication corresponding to the HARQ reception buffer status report; a modulation and coding mode used when sending the HARQ reception buffer status report.

21. The method of claim 20, wherein, In a case where a total number of HARQ processes configured in the first node is m, a sending period of the HARQ reception buffer status report is configured to be sent once every n HARQ processes; where m and n are positive integers, and m is divisible by n.

22. The method of claim 20, wherein, The buffer indication corresponding to the HARQ receiving buffer status report comprises at least one of the following: HARQ process identification, HARQ process number, data packet identification, data packet number, buffer address index.

23. The method of claim 18, wherein, The method further comprises the following steps of: sending the HARQ receiving buffer status report configuration information to the first node, comprising at least one of the following: sending a radio resource control (RRC) message to the first node, wherein the RRC message carries the HARQ receiving buffer status report configuration information; sending a downlink control information (DCI) to the first node, wherein the DCI carries the HARQ receiving buffer status report configuration information; 24. The method of claim 14, wherein, sending an uplink grant (UL grant) to the first node, wherein the UL grant carries the HARQ receiving buffer status report configuration information. After receiving the HARQ receiving buffer status report sent by the first node, the method further comprises the following steps of: directly obtaining the HARQ receiving buffer status of each data packet in the at least one data packet based on the HARQ receiving buffer status report; or jointly decoding the HARQ receiving buffer status report to obtain the HARQ receiving buffer status of each data packet in the at least one data packet.

25. The method of claim 14, wherein, the HARQ receiving buffer status report comprises a new data indicator (NDI) used to indicate the HARQ receiving buffer status of a single data packet; and / or 26. The method of claim 14, wherein, the HARQ receiving buffer status report comprises a HARQ receiving buffer status bitmap comprising the HARQ receiving buffer status of each data packet in the at least one data packet, and the HARQ receiving buffer status of each data packet in the at least one data packet corresponds to one bit in the HARQ receiving buffer status bitmap. The method further comprises the following steps of: receiving a physical uplink control channel (PUCCH) sent by the first node, wherein the HARQ receiving buffer status report is carried on the PUCCH; receiving a physical uplink shared channel (PUSCH) sent by the first node, wherein the HARQ receiving buffer status report is carried on the PUSCH; receiving uplink control information (UCI) sent by the first node, wherein the UCI comprises the HARQ receiving buffer status report; 27. A communications device, wherein, receiving a medium access control control element (MAC CE) sent by the first node, wherein the MAC CE comprises the HARQ receiving buffer status report. The communication device comprises a processor and a memory for storing instructions executable by the processor; 28. A computer readable storage medium, wherein, wherein the processor is configured to execute the instructions to cause the communication device to perform the communication method according to any one of claims 1-26. The computer readable storage medium stores computer instructions, which, when executed on a computer, cause the computer to perform the communication method according to any one of claims 1-26.

29. A computer program product, wherein, The computer program product comprises computer instructions which, when run on a computer, cause the computer to perform the communication method according to any one of claims 1-26.

Images