Data sending method, data receiving method, apparatus, related devices, and storage medium

By introducing a threshold mechanism in 6G communication, the problem of sliding window stagnation is solved, the data transmission rate is improved and the low latency requirement is met.

WO2025119025A1PCT designated stage expired Publication Date: 2025-06-12CHINA MOBILE COMM LTD RES INST +1
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/134269
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-12-06
Filing Date
2024-11-25
Publication Date
2025-06-12

AI Technical Summary

Technical Problem

In the sixth generation mobile communication technology (6G), the existing sliding window mechanism may cause data transmission to stagnate in the confirmation mode, which cannot meet the requirements of high data transmission rates and low latency.

Method used

By introducing a threshold mechanism in the sending and receiving devices, the number of unrecognized packets and the number of unreceived packets is counted. When these quantities are less than the preset threshold, packets are continued to be sent or received to avoid stagnation of the sliding window.

Benefits of technology

It effectively reduces the stagnation time of the sliding window, improves the data transmission rate, and better meets the latency requirements of the user plane.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024134269_12062025_PF_FP_ABST
    Figure CN2024134269_12062025_PF_FP_ABST
Patent Text Reader

Abstract

The present application discloses a data sending method, a data receiving method, an apparatus, a sending device, a receiving device, and a storage medium. The data sending method comprises: the sending device sending a data packet, and counting the number of unacknowledged data packets; and when the counted number is smaller than a first threshold, continuing to send the data packet.
Need to check novelty before this filing date? Find Prior Art

Description

Data sending method, receiving method, device, related equipment and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the Chinese patent application with application number 202311667314.2 and application date of December 6, 2023, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into this application as a reference. Technical Field

[0003] The present application relates to the field of wireless communication technology, and in particular to a data sending method, a data receiving method, an apparatus, related equipment and a storage medium. Background Art

[0004] In related technologies, the transmission modes (also known as transmission mechanisms) of the Radio Link Control (RLC) layer include Acknowledged Mode (AM), Unacknowledged Mode (UM), and Transparent Mode. AM implements a feedback-based sliding window mechanism, which enables highly reliable data transmission.

[0005] However, with the development of sixth-generation mobile communication technology (6G), the requirements for data transmission rates and user-plane latency are increasing. Furthermore, in AM, the sliding window mechanism used in related technologies may experience sliding window stagnation, which means that data transmission is stalled, significantly reducing the data transmission rate and increasing the transmission latency, failing to meet the user-plane latency requirements. Summary of the Invention

[0006] To solve related technical problems, embodiments of the present application provide a data sending method, a data receiving method, an apparatus, a sending device, a receiving device, and a storage medium.

[0007] The technical solution of the embodiment of the present application is implemented as follows:

[0008] An embodiment of the present application provides a data sending method, applied to a sending device, including:

[0009] Send data packets and count the number of unacknowledged data packets;

[0010] When the counted number is less than the first threshold, the data packet continues to be sent.

[0011] In the above solution, the continuing to send the data packet includes at least one of the following:

[0012] Retransmit unacknowledged data packets;

[0013] Send a new data packet.

[0014] In the above solution, the method further includes:

[0015] When the sequence number (SN) of the sent data packet reaches the upper limit and there are unconfirmed data packets, stop sending new data packets;

[0016] retransmitting an unacknowledged data packet and sending first information to a receiving device, wherein the first information is used to instruct the receiving device to send a status report for the retransmitted unacknowledged data packet;

[0017] A status report sent by the receiving device is received, where the received status report indicates whether the retransmitted unacknowledged data packet is acknowledged.

[0018] In the above solution, counting the number of unacknowledged data packets includes:

[0019] Record the sequence numbers of unconfirmed data packets and obtain the number of recorded sequence numbers;

[0020] The number of unacknowledged data packets is determined using the number of sequence numbers.

[0021] In the above solution, recording the sequence numbers of the unconfirmed data packets to obtain the number of recorded sequence numbers; and determining the number of unconfirmed data packets using the number of sequence numbers includes:

[0022] Arranging the sequence numbers of the unacknowledged data packets in order in an array, wherein the number of elements in the array is associated with the first threshold;

[0023] Count the number of non-zero elements in the array and use the counted number as the number of unacknowledged data packets.

[0024] In the above solution, the method further includes:

[0025] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, where the first information is used to instruct the receiving device to send a status report for the data packets;

[0026] The number of unacknowledged data packets is counted according to the status report fed back by the receiving device.

[0027] The present application also provides a data receiving method, which is applied to a receiving device and includes:

[0028] Receive data packets and count the number of data packets that were not received;

[0029] When the counted number is less than the first threshold, continue to receive data packets.

[0030] In the above solution, counting the number of unreceived data packets includes:

[0031] Record the sequence numbers of the data packets that were not received and obtain the number of recorded sequence numbers;

[0032] The number of unreceived data packets is determined using the number of sequence numbers.

[0033] In the above solution, recording the sequence numbers of the unreceived data packets to obtain the number of recorded sequence numbers; and determining the number of unreceived data packets using the number of sequence numbers includes:

[0034] Setting the sequence numbers of the unreceived data packets in an array according to the data, wherein the number of elements in the array is associated with the first threshold;

[0035] The number of non-zero elements in the statistical data group is counted, and the counted number is used as the number of data packets that have not been received.

[0036] In the above solution, the method further includes:

[0037] receiving instruction information sent by a sending device, where the instruction information is used to instruct the receiving device to send a status report for a data packet;

[0038] A status report for the data packet is fed back to the sending device, where the status report indicates whether the data packet is confirmed.

[0039] The present invention further provides a data transmission device, including:

[0040] a first statistical unit configured to count the number of unacknowledged data packets;

[0041] The sending unit is configured to send data packets; when the counted number is less than a first threshold, continue to send data packets.

[0042] The present invention further provides a data receiving device, including:

[0043] a second statistical unit configured to count the number of unreceived data packets;

[0044] The receiving unit is configured to receive data packets; if the counted number is less than a first threshold, continue to receive data packets.

[0045] The present application also provides a sending device, including:

[0046] a first processor configured to count the number of unacknowledged data packets;

[0047] The first communication interface is configured to send data packets; when the counted number is less than a first threshold, continue to send data packets.

[0048] The present application also provides a receiving device, including:

[0049] a second processor configured to count the number of unreceived data packets;

[0050] The second communication interface is configured as a receiving unit to receive data packets; when the counted number is less than the first threshold, the receiving unit continues to receive data packets.

[0051] An embodiment of the present application further provides a sending device, comprising: a first processor and a first memory for storing a computer program that can be run on the processor,

[0052] Wherein, the first processor is configured to execute the steps of any of the above-mentioned methods on the sending device side when running the computer program.

[0053] An embodiment of the present application further provides a receiving device, comprising: a second processor and a second memory for storing a computer program that can be run on the processor,

[0054] The second processor is configured to execute the steps of any of the above-mentioned methods on the receiving device side when running the computer program.

[0055] An embodiment of the present application also provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-mentioned methods on the sending device side, or implements the steps of any of the above-mentioned methods on the receiving device side.

[0056] The data sending method, data receiving method, apparatus, related equipment and storage medium provided by the embodiments of the present application are as follows: the sending device sends data packets and counts the number of unconfirmed data packets; if the counted number is less than a first threshold, the sending device continues to send data packets; and the receiving device receives data packets and counts the number of unreceived data packets; if the counted number is less than the first threshold, the receiving device continues to receive data packets. The embodiment of the present application provides a solution in which the sliding window of the sending device keeps sliding before the number of unconfirmed data packets reaches a threshold, and the sending device continues to send data packets. Correspondingly, the sliding window of the receiving device keeps sliding before the number of unreceived data packets reaches a threshold, and the receiving device continues to receive data packets, and will not stagnate due to a small number of unconfirmed data packets. In this way, the stagnation time of the sliding window can be reduced, thereby ensuring the data transmission rate and better meeting the latency requirements of the user plane. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] FIG1 is a schematic diagram of the structure of a sending window for sending data packets in the related art;

[0058] FIG2 is a schematic diagram of a structure of a sending window stagnation in the related art;

[0059] FIG3 is a flow chart of a method for sending data according to an embodiment of the present application;

[0060] FIG4 is a schematic diagram showing a structure of a sending window corresponding to unacknowledged data packets counted by a sending end according to an embodiment of the present application;

[0061] FIG5 is a flow chart of a method for receiving data according to an embodiment of the present application;

[0062] FIG6 is a schematic diagram of a data transmission process in the related art;

[0063] FIG7 is a schematic diagram of a flow chart of data transmission between a transmitting end and a receiving end in a data transmission system according to an example of an application of the present application;

[0064] FIG8 is a schematic diagram of a data transmission process using an example of the present application;

[0065] FIG9 is a schematic diagram of the structure of the sending window in the case of SN inversion in an application example of this application;

[0066] FIG10 is a schematic diagram of a data transmission process in the case of SN reversal in an application example of the present application;

[0067] FIG11 is a schematic structural diagram of a data sending device according to an embodiment of the present application;

[0068] FIG12 is a schematic structural diagram of a data receiving device according to an embodiment of the present application;

[0069] FIG13 is a schematic diagram of the structure of a sending device according to an embodiment of the present application;

[0070] FIG14 is a schematic diagram of the structure of a receiving device according to an embodiment of the present application;

[0071] FIG15 is a schematic diagram of the structure of the data transmission system according to an embodiment of the present application. DETAILED DESCRIPTION

[0072] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0073] In related technologies, when the RLC layer operates in AM mode, guaranteed data packet transmission is performed between a transmitting device (also referred to as a transmitting end or an RLC transmitting end) and a receiving device (also referred to as a receiving end or an RLC receiving end).

[0074] To ensure reliable data transmission, after receiving a data packet, the receiving device sends a status report to the sending device. This report informs the sending device which data packets were successfully received (i.e., acknowledged) and which were not. After receiving the status report, the sending device resends (also known as retransmits) the unacknowledged data packets. This ensures reliable transmission by detecting and retransmitting unacknowledged data packets.

[0075] In related technologies, when a sending device sends data packets to a receiving device according to the SN, it needs to maintain a maximum range of data packets to be sent (i.e., a sliding window, which can also be called a sending window at the sending end). The sending device only needs to process data packets within the sending window and ignores data packets outside the sending window. The size of the sending window and the sliding mechanism (i.e., the determination and change of the boundary value of the sending window) can be determined by at least the following parameters:

[0076] Window size (AM_Window_Size): This indicates the size of the sending window and is determined by the number of bits occupied by the SN and the transmission speed of the data transmission system.

[0077] Next SN (Tx_Next_Ack): This is the SN of the first packet waiting to be acknowledged. It is also used to represent the lower bound of the send window. The initial value of the Next SN is 0. It is updated when the acknowledgment information of the packet corresponding to the Next SN is received in the status report.

[0078] Next SN (Tx_Next in English): represents the SN corresponding to the next newly generated (i.e., to be sent) data packet.

[0079] Thus, the range of the sending window can be specifically expressed as greater than or equal to the next SN to be confirmed, and less than the sum of the next SN to be confirmed and the window size (i.e., [the next SN to be confirmed, the next SN to be confirmed + window size) or [TX_Next_Ack, TX_Next_Ack + AM_Window_Size)). Specifically, when performing data transmission, when the next SN is less than the sum of the next SN to be confirmed and the window size (i.e., Tx_Next < TX_Next_Ack + AM_Window_Size), the sending device can continue to send the data packet corresponding to the next SN; when the next SN is equal to the sum of the next SN to be confirmed and the window size (i.e., Tx_Next = TX_Next_Ack + AM_Window_Size), the next SN exceeds the range of the sending window, the sending window stalls, and the sending device stops sending new data packets (i.e., the data packet corresponding to the next SN); when the sending device retransmits the data packet corresponding to the next SN to be confirmed, and the received status report indicates that the data packet corresponding to the next SN to be confirmed has been successfully received (i.e., confirmed), the sending window slides forward until the lower bound is equal to the new next SN to be confirmed. At this time, the next SN falls back into the range of the sending window, and the sending device can send the data packet corresponding to the next SN.

[0080] Exemplarily, as shown in FIG. 1, assume that at the first moment, the window size is 10, the next SN to be confirmed is 3, and the next SN is 5. At this time, it can be determined that the range of the sending window is [3, 13). At the same time, assume that after the first moment, the sending device receives a status report, and the status report indicates that the data packet with SN 3 has been successfully received (i.e., confirmed), and the sending device sends the data packet with SN 5 to the receiving device. Thus, at the second moment after the first moment, the sending window slides. At this time, the next SN to be confirmed is updated to 4, the next SN is updated to 6, and the range of the sending window is updated to [4, 14).

[0081] However, with the progress of technology, the requirement for the transmission rate is getting higher and higher. When there are more data packets to be sent, the sending window is often filled, that is, the data packet corresponding to the next SN will quickly exceed the range of the sending window. At this time, since the data packet corresponding to the next SN to be confirmed at the lower bound of the window has not been confirmed, the sending window stalls (i.e., cannot continue to slide), and the sending device cannot continue to send new data packets, which will lead to a significant reduction in the data transmission rate and a high transmission delay, making it difficult to meet the delay requirements of the user plane.

[0082] For example, as shown in Figure 2, assuming that at the first moment, the window size is 10, the next SN to be confirmed is 3, the next SN is 13, and the range of the sending window is [3, 13). At this time, since the next SN is outside the sending window, the sending window stagnates. At the same time, assuming that after the first moment, the sending device receives a status report, and the status report indicates that the data packet with SN 3 has not been successfully received (that is, it has not been confirmed), and at the same time, the data packets with SNs 4 to 12 have been successfully received, so that at the second moment after the first moment, since the data packet with SN 3 is still not confirmed, even if the data packets with SNs 4 to 12 have been confirmed, the sending window cannot slide, that is, the sending window remains stagnant. Only after the sending device retransmits the data packet with SN 3 and receives the corresponding status report confirming that the data packet with SN 3 has been successfully received, can the sending window slide forward so that the sending device can continue to send the data packet corresponding to the next SN (that is, the data packet with SN 13).

[0083] Based on this, in various embodiments of the present application, the sliding window of the sending device keeps sliding before the number of unconfirmed data packets reaches a threshold, and the sending device continues to send data packets and will not stagnate due to a small number of unconfirmed data packets. In this way, the stagnation time of the sliding window can be reduced, thereby ensuring the data transmission rate and better meeting the user-side delay requirements.

[0084] In the embodiments of the present application, the transmitting device may be referred to as a transmitting end or an RLC transmitting end or a transmitting end device, etc., and correspondingly, the receiving device may be referred to as a receiving end or an RLC receiving end or a receiving end device, etc., and the embodiments of the present application do not limit this. In actual application, the transmitting device may include a network device; correspondingly, the receiving device may include a terminal; of course, the transmitting device may also include a terminal, and correspondingly, the receiving device may also include a network device. Specifically, the network device may be a base station, such as a gNB; the terminal may be referred to as a user equipment (UE, User Equipment), a terminal device, a device, or a user, etc., and the embodiments of the present application do not limit this.

[0085] An embodiment of the present application provides a data sending method, which is applied to a sending device, as shown in FIG3 , including:

[0086] Step 301: Send data packets and count the number of unacknowledged data packets;

[0087] Step 302: When the counted number is less than the first threshold, continue sending data packets.

[0088] Here, in actual application, the first threshold value can be set as needed, and the first threshold value represents the timing when the sending window stops sliding (i.e., the window stagnates). Specifically, when the number of unacknowledged data packets in the sending device equals the first threshold value, the sending window stops sliding, and the sending device stops sending new data packets.

[0089] Among them, the unconfirmed data packet refers to the data packet that has been sent by the sending device but has not been confirmed to be received by the receiving device. Therefore, in actual application, the sending device can instruct the receiving device to feedback a status report for the data packet, so that the sending device can know the status of the receiving device receiving the data packet (that is, whether the data packet is confirmed or not) based on the status report, and realize the statistics of the number of unconfirmed data packets.

[0090] Based on this, in one embodiment, during the execution of step 301 and step 302, the method may further include:

[0091] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, where the first information is used to instruct the receiving device to send a status report for the data packets;

[0092] The number of unacknowledged data packets is counted according to the status report fed back by the receiving device.

[0093] Here, in actual application, the size of the second threshold can be set as needed. The second threshold represents the period at which the receiving device is required to send a status report for the data packet. That is, by setting the second threshold, each time the sending device sends a number of data packets corresponding to the second threshold, the sending device can send a first message to the receiving device to instruct the receiving device to feedback a status report. In this way, the sending device can confirm the data packets that have been sent based on the received status report, and count the number of unconfirmed data packets, thereby ensuring that the sending window can continue to slide.

[0094] Specifically, one bit of information may be used in the data packet (which may specifically include a header of the data packet) to instruct the receiving device to send or not send a status report for the data packet. Exemplarily, when the bit is set to 1, it indicates that the receiving device is instructed to send a status report for the data packet, and when the bit is set to 0, it indicates that the receiving device is instructed not to send a status report for the data packet. Of course, it is also possible to set the bit to 1 to indicate that the receiving device is instructed not to send a status report for the data packet, and set the bit to 0 to indicate that the receiving device sends a status report for the data packet.

[0095] The sending device may set the first information (i.e., the above-mentioned indication information) in the next sent data packet after each sending of a preset number (i.e., the above-mentioned second threshold), that is, the first information is sent once every preset number of data packets. Here, the data packet containing the first information can also be understood as a polling data packet or a polling protocol data unit (Poll PDU, Poll Protocol Data Unit), which is specifically used to instruct the receiving device to regularly feedback a status report; wherein, in actual application, a count byte (which can be expressed as PollByte in English) can be defined in the sending device, with an initial value of 0. The count byte is incremented after each data packet is sent. When the value of the count byte reaches the preset second threshold, the first information is set in the next sent data packet, and the value of the count byte is reset to zero. Accordingly, after receiving the data packet with the first information set, the receiving device feedbacks a status report for the data packet to the sending device, so that the sending device can know which data packets have not been confirmed and need to be retransmitted.

[0096] In actual application, the status report may include the SN corresponding to the last acknowledged data packet (expressed as ACK_SN in English) and the SN corresponding to the unacknowledged data packet (expressed as NACK_SN in English). In this way, the transmitting end can obtain the SN corresponding to the unacknowledged data packet from the received status report, thereby determining which data packets are unacknowledged and counting the number of unacknowledged data packets.

[0097] Based on this, in one embodiment, the specific implementation of counting the number of unacknowledged data packets may include:

[0098] Record the sequence numbers of unconfirmed data packets and obtain the number of recorded sequence numbers;

[0099] The number of unacknowledged data packets is determined using the number of sequence numbers.

[0100] Here, in actual application, the statistical method adopted by the sending device to count the number of unconfirmed data packets may specifically include: using an array to count the number of unconfirmed data packets, wherein each non-zero element (also understood as a non-zero item) in the array corresponds to an unconfirmed data packet.

[0101] Specifically, in one embodiment, recording the sequence numbers of the unacknowledged data packets to obtain the number of recorded sequence numbers; and determining the number of unacknowledged data packets using the number of sequence numbers may be specifically implemented by:

[0102] Arranging the SNs of the unconfirmed data packets in order in an array, wherein the number of elements in the array is associated with the first threshold;

[0103] Count the number of non-zero elements in the array and use the counted number as the number of unacknowledged data packets.

[0104] In actual application, the sending device can set an array with an initial value of 0 and a number of elements (which can also be understood as the array length) equal to a first threshold. In this way, when a sent data packet is not confirmed, the sending device can set the SN corresponding to the unconfirmed data packet in the array; at the same time, when the data packet corresponding to the set element in the array is confirmed, the sending device can set the value of the corresponding element in the array to zero. Since the SN corresponding to the data packet is not equal to 0, the sending device can count the number of non-zero elements in the array to obtain the number of unconfirmed data packets; specifically, when all elements in the array are non-zero, the sending device can determine that the number of unconfirmed data packets is equal to the first threshold.

[0105] Exemplarily, as shown in FIG4 , it is assumed that an array Tx Next Ack is defined in the sending device for recording the SNs of unconfirmed data packets, wherein the array size of Tx Next Ack is equal to 5 (i.e., the first threshold) and the initial value of the array is 0; at the same time, it is assumed that at a first moment, the sending device has sent data packets with SN=1, 2,…, 9, and data packets with SN=3, 5, 7 are not confirmed. At this time, Tx Next Ack=[3, 5, 7, 0, 0], the sending device can determine the number of unconfirmed data packets (here equal to 3) by counting the array length (i.e., the number of non-zero elements) before the first 0 (also called the terminator) in Tx Next Ack, and the sending device can continue to send new data packets (i.e., data packets with SN=10, 11) when the number of unconfirmed data packets is less than the array size of Tx Next Ack until the number of unconfirmed data packets is equal to the array size of Tx Next Ack. At the same time, assuming that at a second moment after the first moment, the transmitting end determines, based on the received status report, that the receiving end has received data packets with SN = 5, 10 (i.e., when data packets with SN = 5, 10 are acknowledged), the transmitting device can update Tx Next Ack to [3, 7, 0, 0, 0]. At this time, the next data packet to be sent is the data packet with SN = 11, and the transmitting window can slide. Since the number of unacknowledged data packets is 2, the transmitting device can still send at least 3 data packets (specifically, this can be determined by the difference between the window size of the transmitting window and the number of unacknowledged data packets), that is, it can send data packets with SN = 11, 12, and 13, until Tx_Next_Ack is filled.

[0106] In actual application, in order to ensure the reliability of data transmission, after receiving the status report, the sending device needs to retransmit the unconfirmed data packets corresponding to the status report when continuing to send data packets.

[0107] Based on this, in one embodiment, the continuing to send the data packet includes at least one of the following:

[0108] Retransmit unacknowledged data packets;

[0109] Send a new data packet.

[0110] Specifically, when the sending device continues to send data packets, it may send unconfirmed data packets that need to be retransmitted and / or new data packets that need to be sent in ascending order of SN.

[0111] In actual application, when the SN of the data packet sent reaches the maximum value (i.e., the upper limit) (which can also be understood as when the SN is reversed), the sending device can stop sending new data packets and confirm the data packets that have been sent, thereby ensuring the reliability of data transmission (i.e., the receiving end can receive all the data packets that have been sent). After all the data packets that have been sent have been confirmed to be received, new data packets will continue to be sent.

[0112] Based on this, in one embodiment, the method may further include:

[0113] When the SN of the sent data packet reaches the upper limit and there are unconfirmed data packets, stop sending new data packets;

[0114] retransmitting an unacknowledged data packet and sending first information to a receiving device, wherein the first information is used to instruct the receiving device to send a status report for the retransmitted unacknowledged data packet;

[0115] A status report sent by the receiving device is received, where the received status report indicates whether the retransmitted unacknowledged data packet is acknowledged.

[0116] Here, in actual application, when the SN of the sent data packet reaches the upper limit and there are unconfirmed data packets, the sending device can first retransmit the unconfirmed data packet and receive the status report for the retransmitted data packet fed back by the receiving device. When the status report indicates that the retransmitted data packet is successfully received (that is, after all the sent data packets are confirmed), the sending device can re-SN the new data packet and continue to send new data packets.

[0117] In actual application, the specific implementation of the sending device sending the first information to the receiving device may include: when the sending device retransmits an unconfirmed data packet, 1 bit of information is used in the data packet (specifically, it can be the header of the data packet) to instruct the receiving device to send or not send a status report for the retransmitted unconfirmed data packet; illustratively, when the bit is set to 1, it indicates that the receiving device is instructed to send a status report for the retransmitted unconfirmed data packet, and when the bit is set to 0, it indicates that the receiving device is instructed not to send a status report for the retransmitted unconfirmed data packet. Of course, the bit can also be set to 1 to indicate that the receiving device is instructed not to send a status report for the retransmitted unconfirmed data packet, and when the bit is set to 0, it indicates that the receiving device sends a status report for the retransmitted unconfirmed data packet.

[0118] In actual application, if the status report received by the sending device indicates that the retransmitted unconfirmed data packets are not confirmed, the sending device may retransmit the unconfirmed data packets again until all data packets are confirmed, and then continue to send new data packets.

[0119] In actual application, during the execution of step 302, if the counted number of data packets is equal to the first threshold, the sending window enters a stagnant state, and the sending device stops sending new data packets. At this time, the sending device can actively retransmit the unconfirmed data packets and send an indication message to the receiving device to instruct the receiving device to feedback a status report, and then re-count the number of unconfirmed data packets based on the received status report. Until the counted number is less than the first threshold, the sending window can continue to slide, and the sending device can continue to send new data packets.

[0120] Accordingly, an embodiment of the present application further provides a data receiving method, which is applied to a receiving device, as shown in FIG5 , and includes:

[0121] Step 501: Receive data packets and count the number of unreceived data packets;

[0122] Step 502: When the counted number is less than the first threshold, continue receiving data packets.

[0123] Here, in actual application, the first threshold value can be set as needed. The first threshold value indicates the timing at which a receiving window (i.e., a sliding window, which may also be referred to as a receiving window on the receiving end) stops sliding (i.e., the window stagnates). Specifically, when the number of unreceived data packets on the receiving device equals the first threshold value, the receiving window stops sliding, and the receiving device stops receiving new data packets.

[0124] In actual application, the receiving device can, according to the instructions of the sending device, provide feedback to the sending device on which data packets the receiving device has received and which data packets have not been received, so that the sending device can retransmit the data packets not received by the receiving device based on the feedback information, thereby ensuring the reliability of data transmission.

[0125] Based on this, in one embodiment, the method may further include:

[0126] receiving instruction information sent by a sending device, where the instruction information is used to instruct the receiving device to send a status report for a data packet;

[0127] A status report for the data packet is fed back to the sending device, where the status report indicates whether the data packet is confirmed.

[0128] Specifically, the sending device may use 1 bit of information in the data packet (specifically, the header of the data packet) to instruct the receiving device to send or not send a status report for the data packet; illustratively, when the bit is set to 1, it indicates that the receiving device is instructed to send a status report for the data packet, and when the bit is set to 0, it indicates that the receiving device is instructed not to send a status report for the data packet. Of course, the bit may also be set to 1 to indicate that the receiving device is instructed not to send a status report for the data packet, and when the bit is set to 0, it indicates that the receiving device sends a status report for the data packet. Accordingly, the receiving device may determine whether to send a status report for the data packet to the sending device based on the value of the bit.

[0129] In actual application, the serial numbers of the data packets received by the receiving device should be continuous. When there is a gap (i.e., discontinuous) in the serial numbers of the received data packets, the receiving device can determine that the data packet corresponding to the gap is successfully received, that is, the data packet belongs to the unreceived data packet.

[0130] In actual application, the receiving device may specifically use the sequence numbers of the unreceived data packets to determine the number of the unreceived data packets.

[0131] Specifically, in one embodiment, the specific implementation of counting the number of unreceived data packets may include:

[0132] Record the sequence numbers of the data packets that were not received and obtain the number of recorded sequence numbers;

[0133] The number of unreceived data packets is determined using the number of sequence numbers.

[0134] Here, in actual application, the statistical method used by the receiving device to count the number of unreceived data packets may specifically include: using an array to count the number of unreceived data packets, wherein each non-zero element (also understood as a non-zero item) in the array corresponds to an unreceived data packet.

[0135] Specifically, in one embodiment, recording the sequence numbers of the unreceived data packets to obtain the number of recorded sequence numbers; and determining the number of unreceived data packets using the number of sequence numbers may be specifically implemented by:

[0136] Setting the SNs of the unreceived data packets in an array according to the data, wherein the number of elements in the array is associated with the first threshold;

[0137] The number of non-zero elements in the statistical data group is counted, and the counted number is used as the number of data packets that have not been received.

[0138] In actual application, the receiving device can set an array with an initial value of 0 and the number of elements (which can also be understood as the length of the array) equal to the first threshold. In this way, when the receiving device does not receive the data packet sent by the sending device, the SN corresponding to the unreceived data packet can be set in the array; at the same time, when the receiving device receives the data packet corresponding to the set element in the array, the value of the corresponding element in the array can be set to zero. Since the SN corresponding to the data packet is not equal to 0, the receiving device can obtain the number of unreceived data packets by counting the number of non-zero elements in the array; specifically, when all elements in the array are non-zero, the receiving device can determine that the number of unreceived data packets is equal to the first threshold.

[0139] Exemplarily, assume that an array Rx Next Ack is defined in the receiving device for recording the SNs of unreceived data packets, wherein the array size of Rx Next Ack is equal to 5 (i.e., the first threshold) and the initial value of the array is 0; at the same time, assume that the sending device has sent data packets with SN = 1, 2, ..., 9, and the receiving device has not received data packets with SN = 3, 5, 7. At this time, Rx Next Ack = [3, 5, 7, 0, 0]. The receiving device can determine the number of unreceived data packets (here equal to 3) by counting the array length (i.e., the number of non-zero items) before the first 0 (also called the terminator) in the array, and the receiving device can continue to receive new data packets (i.e., data packets with SN = 10, 11) when the number of unreceived data packets is determined to be less than the array size of Rx Next Ack until the number of unreceived data packets is equal to the array size of Rx Next Ack.

[0140] In actual application, during the execution of step 502, if the counted number of data packets is equal to the first threshold, the receiving window enters a stagnant state, and the receiving device stops receiving new data packets. At this time, the receiving device can actively feedback a status report to the sending device to instruct the sending device to retransmit the unreceived data packets, and after receiving the data packets retransmitted by the sending device (that is, the data packets not received before), re-count the number of unreceived data packets until the counted number of data packets is less than the first threshold. The receiving window can continue to slide, and the receiving device can continue to receive new data packets.

[0141] In the data transmission method and data receiving method provided by the embodiments of the present application, a transmitting device transmits data packets and counts the number of unacknowledged data packets; if the counted number is less than a first threshold, the transmitting device continues to transmit data packets; at the same time, a receiving device receives data packets and counts the number of unreceived data packets; if the counted number is less than the first threshold, the receiving device continues to receive data packets. The solution provided by the embodiments of the present application allows the transmitting device to continue transmitting data packets until the number of unacknowledged data packets reaches a threshold, and will not stall due to a small number of unacknowledged data packets, thereby accelerating the data transmission rate and reducing the data transmission latency.

[0142] The present application will be described in further detail below in conjunction with application examples.

[0143] In actual business scenarios, when the RLC layer works in AM mode, the sending window is often stagnant because the data packets at the lower limit of the window are not confirmed. As a result, the sending end cannot continue to send new data packets, the data transmission rate is greatly reduced, the transmission delay is high, and the delay requirements of the user plane cannot be met.

[0144] Exemplarily, as shown in FIG6 , when the transmitting end (i.e., the transmitting device) sends a data packet to the receiving end (i.e., the receiving device), it is assumed that the window size of the transmitting window is 10, and the SN of the transmitted data packet is 3, 4, ..., 12, wherein the data packet with SN = 8 is a Poll PDU (which can be expressed as poll = 1), and the remaining data packets are not Poll PDUs. At this time, since the number of data packets sent (here 10) is equal to the window size of the transmitting window, the transmitting window is stagnant, and the transmitting end cannot continue to send new data packets; at the same time, it is assumed that when the receiving end receives data packets with SN = 3, 4 ... 12, the data packet with SN = 3 is not received. At the same time, the receiving end can send a status report to the transmitting end based on the polling indication (i.e., poll = 1) contained in the received data packet with SN = 8, the status report includes: the last received data packet ACK_SN = 12, and the unreceived data packet NACK_SN = 3; after receiving the status report, the transmitting end can According to the status report, it is determined that the data packet with SN=3 needs to be retransmitted, and poll=1 corresponding to the retransmitted data packet can be set; after the receiving end receives the retransmitted data packet with SN=3, it can send a status report to the sending end based on the polling indication contained in the data packet (i.e., poll=1), and the status report includes: the last received data packet ACK_SN=3 (i.e., confirmation information of the data packet with SN=3); after the sending end receives the status report corresponding to the retransmitted data packet with SN=3, it can confirm that the data packet has been successfully received. At this time, the sending window can continue to slide, and the sending end can continue to send new data packets.

[0145] Based on this, the application example of this application provides a data transmission method between a transmitter and a receiver, which can ensure that the data transmission process will not be stalled due to a small number of unacknowledged data packets, thereby speeding up the data transmission rate and reducing the data transmission delay. As shown in Figure 7, it includes the following steps:

[0146] Step 701: The sender starts sending data packets and counts the number of unacknowledged data packets;

[0147] Specifically, the transmitting end may place the SNs of the unconfirmed data packets in an array in order, and use the array to determine the number of the unconfirmed data packets.

[0148] Accordingly, the receiving end starts receiving data packets and counts the number of unreceived data packets;

[0149] Specifically, the receiving end may place the SNs of the unreceived data packets in an array in order, and use the array to determine the number of the unreceived data packets.

[0150] In actual application, the sender can send a Poll PDU to the receiver to indicate that the receiver needs to feedback a status report. The sender can then determine whether the sent data packet is an unconfirmed data packet based on the status report fed back by the receiver.

[0151] Specifically, when the number of data packets sent reaches a preset threshold (i.e., the second threshold mentioned above), the sending end can determine the next data packet sent as a Poll PDU and set poll = 1 (i.e., the first information mentioned above) corresponding to the next data packet sent; accordingly, after receiving the Poll PDU, the receiving end can trigger the sending status report (i.e., determine that a status report needs to be fed back to the sending end).

[0152] In actual application, if the receiving end does not receive the Poll PDU, the sending end will not be able to receive the status report in time, and it will be difficult to determine the unconfirmed data packets in time. In order to avoid the above situation, the sending end can start the polling retransmit timer (which can be expressed as Poll Retransmit Timer or t_PollRetransmit in English) after sending the Poll PDU, and terminate the polling retransmit timer when the sending end receives the status report fed back by the receiving end; when the polling retransmit timer times out and there are still data packets to be sent, the next data packet to be sent is determined to be the Poll PDU, and the corresponding poll=1 is set to instruct the receiving end to feedback the status report.

[0153] At the same time, since the relevant technology does not define a reordering mechanism for the RLC layer, when the receiving end receives out-of-order (i.e., SN non-sequential) data packets, it can submit the out-of-order data packets to the Packet Data Convergence Protocol (PDCP) layer, and the PDCP layer will reorder the out-of-order data packets. At the same time, the PDCP layer can start the PDCP reordering timer (which can be expressed as a Re-Ordering Timer in English), and when the PDCP reordering timer expires, the PDCP layer can discard the unreceived data packets (i.e., no new data packets submitted by the RLC layer for this reordering process are received). At this time, the PDCP layer can be set to inform the RLC layer not to continue retransmitting the discarded data packets after the PDCP reordering timer expires (specifically, it can include not indicating the discarded data packets as unreceived data packets in the status report). In this way, the RLC layer can avoid retransmitting the discarded data packets and reduce the waste of air interface resources.

[0154] Step 702: The sending end determines whether the number of unacknowledged data packets is less than a preset threshold (i.e., the first threshold mentioned above);

[0155] Accordingly, the receiving end determines whether the number of unreceived data packets is less than a preset threshold;

[0156] Step 703: When the number of unacknowledged data packets is less than a preset threshold, the sender continues to send data;

[0157] When the number of unacknowledged data packets is greater than or equal to a preset threshold, the sender stops sending data;

[0158] In practical applications, the sender can use the send window size parameter (i.e., AM_Window_Size) of the related art as the preset threshold, i.e., reuse the send window size parameter. In this case, each item in the send window corresponds to the SN of an unacknowledged data packet. When the number of unacknowledged data packets is less than the send window size parameter, the sender can continue to send data. When the number of unacknowledged data packets equals the send window size parameter, the send window is full, the send window stops sliding, and the sender stops sending data.

[0159] In actual applications, when the number of unacknowledged data packets is less than the send window size parameter, the sender may continue to send data by sending a new data packet to the receiver and / or retransmitting the unacknowledged data packet to the receiver based on the received status information. Furthermore, after sending the data packet, the sender may update the count of unacknowledged data packets.

[0160] Accordingly, when the number of data packets not received by the receiving end is less than a preset threshold, the receiving end continues to receive data;

[0161] When the number of data packets not received by the receiving end is greater than or equal to a preset threshold, the receiving end stops receiving data;

[0162] In practical applications, the receiving end can use the window size parameter of the receiving window (i.e., AM_Window_Size) in related art as the preset threshold, i.e., the window size parameter of the multiplexed receiving window. In this case, each item in the receiving window corresponds to the SN of an unreceived data packet. When the number of unreceived data packets is less than the receiving window size parameter, the receiving end can continue to receive data. When the number of unreceived data packets equals the receiving window size parameter, the receiving window is full, the receiving window stops sliding, and the receiving end stops receiving data.

[0163] In actual applications, when the number of unreceived data packets is less than the receive window size parameter, the receiving end may continue to receive data by: receiving new data packets sent by the sending end and / or receiving unreceived data packets retransmitted by the sending end. Furthermore, after receiving data packets, the receiving end may update the number of unreceived data packets counted.

[0164] Step 704: After the sending end stops sending data, the sending end retransmits the unacknowledged data packets;

[0165] In actual application, when the sender stops sending data because the number of unconfirmed data packets is equal to a preset threshold (that is, the sending window is full and stops sliding), the sender can actively retransmit the unconfirmed data packets and determine that the last retransmitted data packet is a Poll PDU to instruct the receiving end to feedback a status report for the retransmitted data packets. The sender can then update the number of counted unconfirmed data packets based on the received status report, and when the updated number of unconfirmed data packets is less than the preset threshold (that is, when at least one data packet among the retransmitted data packets is confirmed), it is determined that the sending window can continue to slide, and the sender can continue to send data until the sending window is full again.

[0166] Accordingly, after the receiving end stops receiving data, the receiving end feeds back a status report;

[0167] In actual application, when the receiving end stops receiving data because the number of unreceived data packets is equal to a preset threshold (that is, the receiving window is full and stops sliding), the receiving end can actively send a status report to the sending end; the sending end retransmits the unreceived data packets based on the received status report; after the receiving end receives the retransmitted data packets, it updates the counted number of unreceived data packets, and when the updated number of unreceived data packets is less than the preset threshold (that is, when at least one retransmitted data packet (that is, a data packet that was not received before) is successfully received), it determines that the receiving window can continue to slide, and the receiving end can continue to receive data until the receiving window is filled again.

[0168] It can be seen from the above description that the sending end and the receiving end can perform data transmission by executing steps 701 to 704. At this time, the sending window will only stagnate when the unconfirmed data packets fill the sending window. Correspondingly, the receiving window will only stagnate when the unreceived data packets fill the receiving window. Compared with the sliding window mechanism of the related technology, the stagnation time of the sending window and the receiving window can be greatly shortened, thereby ensuring the data transmission rate and better meeting the user-side delay requirements.

[0169] For example, as shown in FIG8 , assuming that the size of the sending window is 10, a Poll PDU is set for every six data packets (i.e., every time 6 data packets are sent, poll is set to 1 for the 6th data packet). When a new data transmission task starts, the number of unconfirmed (i.e., not Acked or ACKed) data packets is 0. Before the number of unconfirmed data packets at the sending end equals the size of the sending window, at least 10 data packets can be sent continuously, and the SNs of the 10 data packets are 1, 2, ..., 10, respectively, wherein poll is set to 1 for the data packet with SN=6. Due to the fast sending speed, the sending end still does not receive a status report after sending the data packet with SN=10. At this time, the data packets with SN=1, 2, ..., 10 are all unconfirmed, i.e., the number of unconfirmed data packets is 10, which is equal to the size of the sending window (i.e., equal to the preset threshold). At this time, the sending window is stagnant, and the sending end stops sending new data packets.

[0170] Accordingly, after the new data transmission task starts, the receiving end starts to receive data packets. Specifically, data packets with SN=2, 3, ..., 10 are received, and data packets with SN=1 are not received. Among them, poll=1 corresponding to the received data packet with SN=6 indicates that the receiving end needs to feedback a status report; thus, the receiving end sends a status report to the sending end, and the status report includes the last confirmed received data packet SN (ACK_SN)=10 and the unreceived data packet SN (NACK_SN)=1.

[0171] The sender receives a status report and determines, based on the status report, that the packet with SN = 1 is unacknowledged, while packets with SN = 2, 3, ..., 10 are acknowledged. The updated count of unacknowledged packets is 1. Since the updated count of unacknowledged packets is less than the send window size, the send window can continue sliding, and the sender can continue sending packets. At this point, based on the status report, the sender can determine to retransmit the packet with SN = 1. Furthermore, it can continue sending new packets (i.e., packets with SN = 11, 12, ..., 19) before the send window is full again, until the number of unacknowledged packets again equals the send window size of 10. In this case, poll is set to 1 for the packet with SN = 15. Thus, compared to sliding window mechanisms in related arts, the send window does not need to wait for the retransmission of the packet with SN = 1 and for a status report confirming the receipt of the packet with SN = 1 before it can slide forward. That is, it will not be stalled due to a small number of unacknowledged packets (i.e., packets with SN = 1), thereby reducing the stagnation time of the sliding window, ensuring data transmission rate, and better meeting user plane latency requirements.

[0172] In actual application, when the solution of the application example of this application is used to send and receive data, due to the fast transmission rate of the data packet, the SN may quickly reach the upper limit of the SN number, resulting in SN reversal. As shown in Figure 9, assuming that the window size of the sending window is 10, the upper limit of the SN number is 20, the array Tx_Next_Ack = [3,5,7,0,0,0,0,0,0,0], that is, the number of unconfirmed data packets is 3. At this time, since the data packet with SN = 20 has been sent and the number of unconfirmed data packets is less than 10, before receiving the status report, the sending window should slide to the right, that is, continue to send new data packets. However, since the SN number reaches the upper limit, the sending window will stop sliding and the sender will stop sending new data packets.

[0173] At this time, as shown in Figure 10, after stopping sending new data packets, the sender can actively retransmit the unconfirmed data packets in SN order, that is, resend the data packets with SN=3, 5, 7, and set poll=1 corresponding to the last retransmitted data packet (that is, the data packet with SN=7); the receiving end receives the data packets with SN=3, 5, 7, and identifies the poll=1 corresponding to the data packet with SN=7, and sends a status report, which includes: ACK_SN=7; the sending end receives the status report and determines that the data packets with SN=3, 5, 7 are all confirmed. At this time, the sending window slides, the SN starts numbering from 1 again, and a new data packet is sent.

[0174] In the application example of this application, the sending device can continue to send data packets before the number of unconfirmed data packets reaches a threshold, and will not stagnate due to a small number of unconfirmed data packets. It can speed up the data transmission rate and reduce the data transmission delay.

[0175] In order to implement the method on the sending device side of the embodiment of the present application, the embodiment of the present application further provides a data sending device, which is provided on the sending device, as shown in FIG11 , and includes:

[0176] A first counting unit 1101 is configured to count the number of unacknowledged data packets;

[0177] The first sending unit 1102 is configured to send data packets; if the counted number is less than a first threshold, continue to send data packets.

[0178] In one embodiment, the first sending unit 1102 is configured as follows:

[0179] When the SN of the sent data packet reaches the upper limit and there are unconfirmed data packets, stop sending new data packets;

[0180] retransmitting an unacknowledged data packet and sending first information to a receiving device, wherein the first information is used to instruct the receiving device to send a status report for the retransmitted unacknowledged data packet;

[0181] The sending device further includes:

[0182] The first receiving unit is configured to receive a status report sent by the receiving device, where the received status report indicates whether the retransmitted unconfirmed data packet is confirmed.

[0183] In one embodiment, the first statistics unit 1101 is configured to:

[0184] Record the sequence numbers of unconfirmed data packets and obtain the number of recorded sequence numbers;

[0185] The number of unacknowledged data packets is determined using the number of sequence numbers.

[0186] In one embodiment, the first statistics unit 1101 is configured to:

[0187] Arranging the SNs of the unconfirmed data packets in order in an array, wherein the number of elements in the array is associated with the first threshold;

[0188] Count the number of non-zero elements in the array and use the counted number as the number of unacknowledged data packets.

[0189] In one embodiment, the first sending unit 1102 is configured to:

[0190] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, where the first information is used to instruct the receiving device to send a status report for the data packets;

[0191] The first statistical unit 1101 is configured to:

[0192] The number of unacknowledged data packets is counted according to the status report fed back by the receiving device.

[0193] In actual application, the first sending unit 1102 and the first receiving unit can be implemented by a communication interface in the data sending device; the first statistical unit 1101 can be implemented by a processor in the data sending device.

[0194] It should be noted that the data transmission device provided in the above embodiment is only illustrated by the division of the above program units when performing data transmission. In actual applications, the above processing can be assigned to different program units as needed, that is, the internal structure of the device can be divided into different program units to complete all or part of the above-described processing. In addition, the data transmission device provided in the above embodiment and the data transmission method embodiment are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0195] In order to implement the method on the receiving device side of the embodiment of the present application, the embodiment of the present application further provides a data receiving device, which is provided on the receiving device, as shown in FIG12 , and includes:

[0196] The second counting unit 1201 is configured to count the number of unreceived data packets;

[0197] The second receiving unit 1202 is configured to receive data packets; if the counted number is less than the first threshold, continue to receive data packets.

[0198] In one embodiment, the second statistical unit 1201 is configured as follows:

[0199] Record the sequence numbers of the data packets that were not received and obtain the number of recorded sequence numbers;

[0200] The number of unreceived data packets is determined using the number of sequence numbers.

[0201] In one embodiment, the second statistical unit 1201 is configured to:

[0202] Setting the SNs of the unreceived data packets in an array according to the data, wherein the number of elements in the array is associated with the first threshold;

[0203] The number of non-zero elements in the statistical data group is counted, and the counted number is used as the number of data packets that have not been received.

[0204] In one embodiment, the second receiving unit 1202 is configured to:

[0205] receiving instruction information sent by a sending device, where the instruction information is used to instruct the receiving device to send a status report for a data packet;

[0206] The data receiving device further includes:

[0207] The second sending unit is configured to feed back a status report for the data packet to the sending device, where the status report indicates whether the data packet is confirmed.

[0208] In actual application, the second sending unit and the second receiving unit 1202 can be implemented by a communication interface in the data receiving device; the second statistical unit 1201 can be implemented by a processor in the data receiving device.

[0209] It should be noted that the data receiving device provided in the above embodiments is merely illustrated by the division of the aforementioned program units when performing data reception. In actual applications, the aforementioned processing can be assigned to different program units as needed, that is, the internal structure of the device can be divided into different program units to complete all or part of the aforementioned processing. Furthermore, the data receiving device provided in the above embodiments and the data receiving method embodiment are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0210] Based on the hardware implementation of the above program modules, and in order to implement the method on the sending device side of the embodiment of the present application, the embodiment of the present application further provides a sending device, as shown in FIG13 , the sending device 1300 includes:

[0211] The first communication interface 1301 is capable of exchanging information with a receiving device;

[0212] The first processor 1302 is connected to the first communication interface 1301 to implement information interaction with the receiving device, and is configured to execute the method provided by one or more technical solutions on the sending device side when running a computer program; the computer program is stored in the first memory 1303.

[0213] Specifically, the first processor 1302 is configured to:

[0214] Count the number of unacknowledged data packets;

[0215] The first communication interface 1301 is configured as follows:

[0216] Send data packets; if the counted number is less than the first threshold, continue sending data packets.

[0217] In one embodiment, the first communication interface 1301 is configured as follows:

[0218] When the SN of the sent data packet reaches the upper limit and there are unconfirmed data packets, stop sending new data packets;

[0219] retransmitting an unacknowledged data packet and sending first information to a receiving device, wherein the first information is used to instruct the receiving device to send a status report for the retransmitted unacknowledged data packet;

[0220] A status report sent by the receiving device is received, where the received status report indicates whether the retransmitted unacknowledged data packet is acknowledged.

[0221] In one embodiment, the first processor 1302 is configured to:

[0222] Record the sequence numbers of unconfirmed data packets and obtain the number of recorded sequence numbers;

[0223] The number of unacknowledged data packets is determined using the number of sequence numbers.

[0224] In one embodiment, the first processor 1302 is configured to:

[0225] Arranging the SNs of the unconfirmed data packets in order in an array, wherein the number of elements in the array is associated with the first threshold;

[0226] Count the number of non-zero elements in the array and use the counted number as the number of unacknowledged data packets.

[0227] In one embodiment, the first communication interface 1301 is configured as follows:

[0228] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, where the first information is used to instruct the receiving device to send a status report for the data packets;

[0229] The first processor 1302 is configured to count the number of unacknowledged data packets according to the status report fed back by the receiving device.

[0230] It should be noted that the specific processing process of the first processor 1302 and the first communication interface 1301 can be understood by referring to the above method.

[0231] Of course, in actual application, the various components in the transmitting device 1300 are coupled together via a bus system 1304. It is understood that the bus system 1304 is used to implement connections and communications between these components. In addition to the data bus, the bus system 1304 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in FIG13 , all of the various buses are labeled as the bus system 1304.

[0232] The first memory 1303 in the embodiment of the present application is used to store various types of data to support the operation of the sending device 1300. Examples of such data include: any computer program used to operate on the sending device 1300.

[0233] The methods disclosed in the above embodiments of the present application can be applied to the first processor 1302 or implemented by the first processor 1302. The first processor 1302 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the first processor 1302 or by instructions in the form of software. The above first processor 1302 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The first processor 1302 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium located in the first memory 1303. The first processor 1302 reads the information in the first memory 1303 and completes the steps of the above method in combination with its hardware.

[0234] In an exemplary embodiment, the sending device 1300 can be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to execute the aforementioned method.

[0235] Based on the hardware implementation of the above program modules, and in order to implement the method on the receiving device side of the embodiment of the present application, the embodiment of the present application further provides a receiving device, as shown in FIG14 , the receiving device 1400 includes:

[0236] The second communication interface 1401 is capable of exchanging information with the sending device;

[0237] The second processor 1402 is connected to the second communication interface 1401 to implement information interaction with the sending device, and is configured to execute the methods provided by one or more technical solutions on the above-mentioned receiving device side when running a computer program; the computer program is stored in the second memory 1403.

[0238] Specifically, the second processor 1402 is configured to:

[0239] Count the number of data packets not received;

[0240] The second communication interface 1401 is configured as follows:

[0241] Receive data packets; and continue receiving data packets when the counted number is less than the first threshold.

[0242] In one embodiment, the second processor 1402 is configured to:

[0243] Record the sequence numbers of the data packets that were not received and obtain the number of recorded sequence numbers;

[0244] The number of unreceived data packets is determined using the number of sequence numbers.

[0245] In one embodiment, the second processor 1402 is configured to:

[0246] Setting the SNs of the unreceived data packets in an array according to the data, wherein the number of elements in the array is associated with the first threshold;

[0247] The number of non-zero elements in the statistical data group is counted, and the counted number is used as the number of data packets that have not been received.

[0248] In one embodiment, the second communication interface 1401 is configured as follows:

[0249] receiving instruction information sent by a sending device, where the instruction information is used to instruct the receiving device to send a status report for a data packet;

[0250] A status report for the data packet is fed back to the sending device, where the status report indicates whether the data packet is confirmed.

[0251] It should be noted that the specific processing process of the second processor 1402 and the second communication interface 1401 can be understood by referring to the above method.

[0252] Of course, in actual use, the various components in receiving device 1400 are coupled together via bus system 1404. It will be appreciated that bus system 1404 is used to enable communication between these components. In addition to a data bus, bus system 1404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in FIG14 , all of these buses are labeled as bus system 1404.

[0253] The second memory 1403 in the embodiment of the present application is used to store various types of data to support the operation of the receiving device 1400. Examples of such data include: any computer program used to operate on the receiving device 1400.

[0254] The methods disclosed in the above embodiments of the present application can be applied to or implemented by the second processor 1402. The second processor 1402 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits or software instructions in the second processor 1402. The above second processor 1402 may be a general-purpose processor, a DSP, or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc. The second processor 1402 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium located in the second memory 1403. The second processor 1402 reads the information in the second memory 1403 and, in conjunction with its hardware, completes the steps of the above method.

[0255] In an exemplary embodiment, the receiving device 1400 may be implemented by one or more ASICs, DSPs, PLDs, CPLDs, FPGAs, general-purpose processors, controllers, MCUs, Microprocessors, or other electronic components to perform the aforementioned method.

[0256] It can be understood that the memory (first memory 1303, second memory 1403) of the embodiment of the present application can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a magnetic disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus random access memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0257] In order to implement the method provided in the embodiment of the present application, the embodiment of the present application also provides a data transmission system, as shown in Figure 15, which includes: a sending device 1501 and a receiving device 1502.

[0258] Here, it should be noted that the specific processing procedures of the sending device 1501 and the receiving device 1502 have been described in detail above and will not be repeated here.

[0259] In an exemplary embodiment, the present application also provides a storage medium, namely, a computer storage medium, specifically, a computer-readable storage medium, such as a first memory 1303 storing a computer program, which can be executed by the first processor 1302 of the sending device 1300 to complete the steps of the aforementioned sending device-side method. Another example includes a second memory 1403 storing a computer program, which can be executed by the second processor 1402 of the receiving device 1400 to complete the steps of the aforementioned receiving device-side method. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface storage, optical disk, or CD-ROM.

[0260] It should be noted that: "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0261] In addition, the technical solutions described in the embodiments of the present application can be combined arbitrarily without conflict.

[0262] The above description is merely a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application.

Claims

1. A data sending method, applied to a sending device, comprising: Send data packets and count the number of unacknowledged data packets; When the counted number is less than the first threshold, the data packet continues to be sent.

2. The method according to claim 1, wherein: The continuing to send data packets includes at least one of the following: Retransmit unacknowledged packets; Send a new packet.

3. The method according to claim 1, wherein: The method further comprises: When the sequence number of the sent data packet reaches the upper limit and there are unconfirmed data packets, stop sending new data packets; retransmitting an unconfirmed data packet, and sending first information to a receiving device, wherein the first information is used to instruct the receiving device to send a status report for the retransmitted unconfirmed data packet; A status report sent by the receiving device is received, wherein the received status report indicates whether the retransmitted unconfirmed data packet is confirmed.

4. The method according to claim 1, wherein: The counting of the number of unconfirmed data packets includes: Record the sequence numbers of the unconfirmed data packets and obtain the number of recorded sequence numbers; Using the number of sequence numbers, the number of unacknowledged data packets is determined.

5. The method according to claim 4, wherein: The recording of the sequence numbers of the unconfirmed data packets obtains the number of the recorded sequence numbers; Determining the number of unacknowledged data packets using the number of sequence numbers includes: The sequence numbers of the unconfirmed data packets are arranged in order in an array, wherein the number of elements in the array is associated with the first threshold; The number of non-zero elements in the count array is used as the number of unconfirmed data packets.

6. The method according to any one of claims 1 to 5, wherein: The method further comprises: When the number of sent data packets reaches a second threshold, sending first information to a receiving device, where the first information is used to instruct the receiving device to send a status report for the data packets; The number of unconfirmed data packets is counted according to the status report fed back by the receiving device.

7. A data receiving method, applied to a receiving device, comprising: Receive data packets and count the number of data packets that were not received; When the counted number is less than the first threshold, data packets continue to be received.

8. The method according to claim 7, wherein: The counting of the number of data packets not received includes: Record the sequence numbers of the data packets that have not been received, and obtain the number of recorded sequence numbers; The number of unreceived data packets is determined using the number of sequence numbers.

9. The method according to claim 8, wherein: The recording of the sequence numbers of the data packets not received, and obtaining the number of the recorded sequence numbers; Determining the number of unreceived data packets using the number of sequence numbers includes: The sequence numbers of the unreceived data packets are set in an array according to the data, and the number of elements in the array is associated with the first threshold; The number of non-zero elements in the statistical data group is counted, and the counted number is used as the number of data packets that have not been received.

10. The method according to any one of claims 7 to 9, wherein: The method further comprises: Receiving instruction information sent by a sending device, where the instruction information is used to instruct the receiving device to send a status report for a data packet; A status report for the data packet is fed back to the sending device, where the status report indicates whether the data packet is confirmed.

11. A data sending device, comprising: A first counting unit configured to count the number of unconfirmed data packets; a sending unit configured to send a data packet; When the counted number is less than the first threshold, the data packet continues to be sent.

12. A data receiving device, comprising: a second statistical unit configured to count the number of unreceived data packets; a receiving unit configured to receive a data packet; When the counted number is less than the first threshold, data packets continue to be received.

13. A sending device, comprising: A first processor configured to count the number of unacknowledged data packets; The first communication interface is configured to send data packets; when the counted number is less than a first threshold, continue to send data packets.

14. A receiving device, comprising: a second processor configured to count the number of unreceived data packets; The second communication interface is configured as a receiving unit to receive data packets; When the counted number is less than the first threshold, data packets continue to be received.

15. A sending device, comprising: a first processor and a first memory for storing a computer program executable on the processor, Wherein, the first processor is configured to execute the steps of the method according to any one of claims 1 to 6 when running the computer program.

16. A receiving device, comprising: a second processor and a second memory for storing a computer program executable on the processor, Wherein, the second processor is configured to execute the steps of the method according to any one of claims 7 to 10 when running the computer program.

17. A storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 6, or implements the steps of the method according to any one of claims 7 to 10.

Citation Information

Patent Citations

  • Method, device and system for reporting capability information

    CN109862622A

  • Dynamic reallocation of transmit power on dual connectivity devices

    US11737075B1

  • Method and device for processing packet loss feedback message

    WO2014117359A1

  • Data transmission method and apparatus

    WO2016161594A1

  • Method and system for network performance detection based on receiving end in TCP transmission stream

    WO2017133014A1