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

By introducing a threshold mechanism and a status report request mechanism in 6G communication, the problem of sliding window stagnation is solved, the data transmission rate is improved and the user delay requirements are met.

CN120111564APending Publication Date: 2025-06-06CHINA MOBILE COMM LTD RES INST +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202311667314.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-12-06
Publication Date
2025-06-06

AI Technical Summary

Technical Problem

In the sixth generation mobile communication technology (6G), the existing sliding window mechanism may cause the sliding window to stagnate in the confirmation mode (AM), resulting in a decrease in data transmission rate and an increase in delay, which cannot meet the user's delay requirements.

Method used

By introducing a threshold mechanism in the sending device and the receiving device, the number of unconfirmed packets is counted, the data packets are continued to be sent when the number is less than the first threshold, and the unconfirmed packets are retransmitted when necessary, and the status report request is sent to the receiving device to ensure the continuous sliding of the sliding window.

Benefits of technology

It effectively reduces the stagnation time of the sliding window, improves the data transmission rate, and meets the user's delay requirements.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120111564A_ABST
    Figure CN120111564A_ABST
Patent Text Reader

Abstract

The invention discloses a data sending method and device, a data receiving method and device, sending equipment, receiving equipment and a storage medium. The method comprises the following steps that: sending equipment sends data packets, and counts the number of unconfirmed data packets; and when the counted number is less than the first threshold value, continuing to send the data packet.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] 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

[0002] In the related art, the transmission modes (also known as transmission mechanisms) of the Radio Link Control (RLC) layer include: Acknowlegde Mode (AM), Unacknowledge Mode (Unacknowledge Mode) and Transparent Mode (Transparent Mode). Among them, under AM, a feedback-based sliding window mechanism is implemented, through which data transmission with high reliability can be achieved.

[0003] However, with the development of the sixth generation mobile communication technology (6G), the requirements for data transmission rate are getting higher and higher, and the requirements for user plane delay are also getting higher and higher. In addition, under AM, the use of the existing sliding window mechanism may cause the sliding window to stagnate, that is, data transmission is stagnant, the data transmission rate is greatly reduced, and the transmission delay is high, which cannot meet the delay requirements of the user plane. Summary of the invention

[0004] 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.

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

[0006] The embodiment of the present application provides a data sending method, which is applied to a sending device, including:

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

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

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

[0010] Retransmit unacknowledged packets;

[0011] Send a new packet.

[0012] In the above scheme, the method further includes:

[0013] 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;

[0014] retransmitting an unconfirmed data packet, and sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the retransmitted unconfirmed data packet;

[0015] A status report sent by the receiving device is received, wherein the received status report indicates whether the retransmitted unconfirmed data packet is confirmed.

[0016] In the above solution, the counting of the number of unconfirmed data packets includes:

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

[0018] Using the number of sequence numbers, determine the number of unacknowledged packets

[0019] In the above scheme, 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:

[0020] 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;

[0021] The number of non-zero elements in the count array is used as the number of unconfirmed data packets.

[0022] In the above scheme, the method further comprises:

[0023] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the data packets;

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

[0025] The embodiment of the present application also provides a data receiving method, which is applied to a receiving device, including:

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

[0027] When the counted number is less than the first threshold, data packets continue to be received.

[0028] In the above solution, the counting of the number of data packets not received includes:

[0029] Record the sequence numbers of the data packets that have not been received, and obtain the number of recorded sequence numbers;

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

[0031] In the above scheme, recording the sequence numbers of the data packets that have not been received to obtain the number of recorded sequence numbers; and determining the number of data packets that have not been received using the number of sequence numbers includes:

[0032] 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;

[0033] 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.

[0034] In the above scheme, the method further includes:

[0035] 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;

[0036] 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.

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

[0038] A first statistical unit, used for counting the number of unconfirmed data packets;

[0039] The sending unit is used to send data packets; when the counted number is less than a first threshold, the sending of data packets continues.

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

[0041] A second statistical unit, used for counting the number of data packets not received;

[0042] The receiving unit is used to receive data packets; when the counted number is less than a first threshold, continue to receive data packets.

[0043] The embodiment of the present application also provides a sending device, including:

[0044] A first processor, configured to count the number of unacknowledged data packets;

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

[0046] The embodiment of the present application also provides a receiving device, including:

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

[0048] The second communication interface is used for the receiving unit to receive data packets; when the counted number is less than the first threshold, the receiving unit continues to receive data packets.

[0049] The 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,

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

[0051] The 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,

[0052] Wherein, the second processor is used to execute the steps of any one of the above-mentioned methods on the receiving device side when running the computer program.

[0053] An embodiment of the present application also provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned methods on the sending device side are implemented, or the steps of any of the above-mentioned methods on the receiving device side are implemented.

[0054] The data sending method, data receiving method, apparatus, related equipment and storage medium provided by the embodiments of the present application, the sending device sends data packets and counts the number of unconfirmed data packets; when the counted number is less than a first threshold, the data packets continue to be sent; and the receiving device receives data packets and counts the number of unreceived data packets; when the counted number is less than the first threshold, the data packets continue to be received. In the scheme provided by the 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. 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

[0055] Figure 1 A schematic diagram of the structure of a sending window for sending a data packet in the related art;

[0056] Figure 2 It is a structural diagram of sending window stagnation in the related art;

[0057] Figure 3 A schematic diagram of a method flow for sending data according to an embodiment of the present application;

[0058] Figure 4A schematic diagram of the structure of a sending window corresponding to unconfirmed data packets counted by a sending end in an embodiment of the present application;

[0059] Figure 5 A schematic diagram of a method flow for receiving data according to an embodiment of the present application;

[0060] Figure 6 It is a schematic diagram of a process of data transmission in the related technology;

[0061] Figure 7 This is a schematic diagram of the process of data transmission between the sending end and the receiving end in the data transmission system of the application example of this application;

[0062] Figure 8 A flowchart of data transmission for example of this application;

[0063] Fig. 9 This is a schematic diagram of the structure of the sending window in the case of SN reversal in the application example of this application;

[0064] Fig.10 This is a flowchart of data transmission in the case of SN reversal in the application example of this application;

[0065] Fig.11 This is a schematic diagram of the structure of a data sending device according to an embodiment of the present application;

[0066] Fig.12 This is a schematic diagram of the structure of a data receiving device according to an embodiment of the present application;

[0067] Fig.13 A schematic diagram of the structure of the sending device for the embodiment of the present application;

[0068] Fig.14 This is a schematic diagram of the structure of a receiving device according to an embodiment of the present application;

[0069] Fig.15 This is a schematic diagram of the structure of the data transmission system according to an embodiment of the present application. DETAILED DESCRIPTION

[0070] The present application will be further described in detail below through the accompanying drawings and specific embodiments.

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

[0072] In order to ensure the reliability of data transmission, after receiving the data packet, the receiving device sends a status report (which can be expressed as Status Report in English) to the sending device to inform the sending device which data packets are successfully received (that is, confirmed) and which data packets are not successfully received (that is, unconfirmed). After receiving the status report, the sending device resends (which can also be understood as retransmitting) the unconfirmed data packets. In this way, by detecting unconfirmed data packets and retransmitting them, a reliable transmission service can be provided.

[0073] In the related art, when a sending device sends a data packet to a receiving device according to the SN, it needs to maintain a maximum range of sending data packets (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 does not need to care about 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:

[0074] Window size (AM_Window_Size in English): It indicates the size of the sending window and can be determined by the number of bits occupied by the SN and the transmission speed of the data transmission system.

[0075] Next SN (Tx_Next_Ack): represents the SN of the first data packet waiting to be confirmed. The initial value is 0. It is updated when the confirmation information of the data packet corresponding to the next SN is received in the status report. It is also used to represent the lower limit of the sending window (also called the lower boundary).

[0076] Next SN (Tx_Next in English): represents the SN corresponding to the next newly generated (ie, to-be-sent) data packet.

[0077] Thus, the sending window can be specifically expressed as being greater than or equal to the next SN to be acknowledged, and less than the sum of the next SN to be acknowledged and the window size (i.e., [the next SN to be acknowledged, the next SN to be acknowledged + 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 acknowledged 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 acknowledged 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 acknowledged, and the received status report indicates that the data packet corresponding to the next SN to be acknowledged has been successfully received (i.e., acknowledged), the sending window slides forward until the lower bound is equal to the new next SN to be acknowledged. At this time, the next SN falls back within the range of the sending window, and the sending device can send the data packet corresponding to the next SN.

[0078] Exemplarily, as Figure 1 shown, at the first moment, the window size is 10, the next SN to be acknowledged is 3, and the next SN is 5. At this time, the sending window is [3, 13). Assume that after the first moment, the sending device receives a status report indicating that the data packet with SN 3 has been successfully received (i.e., acknowledged), 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 acknowledged is updated to 4, the next SN is updated to 6, and the sending window is updated to [4, 14).

[0079] 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 up, 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 acknowledged at the lower bound of the window has not been acknowledged, the sending window stalls, and the sending device cannot continue to send new data packets, resulting in a significant reduction in the data transmission rate and a high transmission delay, which cannot meet the delay requirements of the user plane.

[0080] Exemplarily, as Figure 2As shown, at the first moment, the window size is 10, the next SN to be confirmed is 3, the next SN is 13, and the sending window is [3,13). At this time, the next SN is outside the sending window, and the sending window is stagnant. 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). At the same time, the data packets with SNs of 4 to 12 have been successfully received. At this time, 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 of 4 to 12 have been confirmed, the sending window cannot slide, that is, the sending window is stagnant. The sending window needs to retransmit the data packet with SN 3 and receive the corresponding status report confirming that the data packet with SN 3 has been successfully received before it can 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).

[0081] 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 stall due to a small number of unconfirmed data packets. In this way, the stall time of the sliding window can be reduced, thereby ensuring the data transmission rate and better meeting the user-side latency requirements.

[0082] In the embodiment of the present application, the sending device may be referred to as a sending end or an RLC sending end or a sending 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 embodiment of the present application does not limit this. In actual application, the sending device may include a network device; correspondingly, the receiving device may include a terminal; of course, the sending device may be a terminal, and correspondingly, the receiving device may include a network device. In particular, the network device may be a base station, such as a gNB, and the terminal may be referred to as a user equipment (UE, User Equipment), a terminal device, a device, or a user, etc., and the embodiment of the present application does not limit this.

[0083] The present application embodiment provides a data sending method, which is applied to a sending device, such as Figure 3 As shown, including:

[0084] Step 301: Send data packets and count the number of unconfirmed data packets;

[0085] Step 302: When the counted number is less than the first threshold, continue to send data packets.

[0086] Here, in actual application, the size of the first threshold can be set as needed. The first threshold represents the timing when the sending window stops sliding (that is, the window stagnates). When the number of unconfirmed data packets in the sending device is equal to the first threshold, the sending window stops sliding and the sending device stops sending new data packets.

[0087] Among them, the unconfirmed data packet refers to a 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) according to the status report, and realize the statistics of the number of unconfirmed data packets.

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

[0089] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the data packets;

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

[0091] Here, in actual application, the size of the second threshold can be set as needed. The second threshold represents the period for requiring the receiving device to send a status report for the data packet. That is, by setting the second threshold, the sending device sends the first information to the receiving device after each time it sends a number of data packets corresponding to the second threshold, instructing the receiving device to feedback the status report, so that the sending device can confirm the data packets that have been sent according to the status report, and count the number of data packets that have not been confirmed, thereby ensuring that the sending window can continue to slide.

[0092] Specifically, 1 bit of information may be used 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.

[0093] The sending device can set the first information (i.e., the above-mentioned indication information) in the sent data packet every interval of a preset number (i.e., the second threshold) of data packets. At this time, 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 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, and the count byte is increased by one 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 feeds back 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.

[0094] In actual application, the status report may include the SN corresponding to the last confirmed data packet (expressed as ACK_SN in English) and the SN corresponding to the unconfirmed data packet (expressed as NACK_SN in English). That is, the sending end can determine the SN corresponding to the unconfirmed data packet by using the status report, and then determine which data packets are unconfirmed, and count the number of unconfirmed data packets.

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

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

[0097] Using the number of sequence numbers, the number of unacknowledged data packets is determined.

[0098] Here, in actual application, when the sending device counts the number of unconfirmed data packets, the counting method may include: using an array to count the number of unconfirmed data packets, each non-zero element (also understood as a non-zero item) in the array corresponds to an unconfirmed data packet.

[0099] Specifically, in one embodiment, the recording of the sequence numbers of the unconfirmed data packets to obtain the number of recorded sequence numbers; and the use of the number of sequence numbers to determine the number of unconfirmed data packets may include:

[0100] 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;

[0101] The number of non-zero elements in the count array is used as the number of unconfirmed data packets.

[0102] In actual application, the sending device can set an array with an initial value of 0, and the number of elements in the array (which can also be understood as the array length) is equal to the first threshold. When the sent data packet is not confirmed, the SN corresponding to the unconfirmed data packet is set in the array. When the data packet corresponding to the set element in the array is confirmed, the value of the corresponding element in the array is set to zero. Since SN is not equal to 0, the sending device can obtain the number of unconfirmed data packets by counting the number of non-zero elements in the array. At the same time, when all elements in the array are non-zero, it can be determined that the number of unconfirmed data packets is equal to the first threshold.

[0103] For example, Figure 4 As shown, assuming that at the first moment, the sending device has sent data packets with SN=1, 2, ..., 9, among which the data packets with SN=3, 5, 7 are not confirmed, an array Tx Next Ack is defined, the array size is equal to 5 (i.e., the first threshold), the array initial value is 0, and the SNs corresponding to the unconfirmed data packets are stored in the array in sequence, that is, Tx NextAck=[3, 5, 7, 0, 0]. At this time, the array length (i.e., the number of non-zero elements) before the first 0 (also called the terminator) in the array is counted to determine the number of unconfirmed data packets, which is equal to 3 here. When the number of unconfirmed data packets is less than the array size, the sending device can send new data packets (i.e., data packets with SN=10, 11) until the number of unconfirmed data packets is equal to the array size. At the second moment after the first moment, when the sending end determines that the receiving end has received the SN=5 data packet (i.e., when the SN=5 data packet is confirmed) based on the received status report, the array is updated. At this time, the array Tx_Next_Ack=[3,7,0,0,0]. At the same time, the sending end sends and confirms the SN=10 data packet. At this time, the next data packet to be sent is the SN=11 data packet. The sending window slides, and the number of unconfirmed data packets is 2. The sending end can at least send data packets equal to the difference between the window size of the sending window and the number of unconfirmed data packets (i.e., 3), that is, it can send data packets of SN=11, 12, and 13 until the array Tx_Next_Ack is filled.

[0104] 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.

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

[0106] Retransmit unacknowledged packets;

[0107] Send a new packet.

[0108] Specifically, when continuing to send data packets, the sending device 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.

[0109] In actual application, when the SN of the sent data packet reaches the maximum value (that is, the upper limit) (which can also be understood as the SN inversion), the sending device needs to stop sending new data packets. In order to ensure the reliability of data transmission (that is, the receiving end can receive all the sent data packets), it is necessary to make sure that all the sent data packets are confirmed before continuing to send data packets.

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

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

[0112] retransmitting an unconfirmed data packet, and sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the retransmitted unconfirmed data packet;

[0113] A status report sent by the receiving device is received, wherein the received status report indicates whether the retransmitted unconfirmed data packet is confirmed.

[0114] Here, it should be noted that when the SN of the sent data packet reaches the upper limit and there are unconfirmed data packets, the sending device needs to retransmit the unconfirmed data packets. After retransmitting the unconfirmed data packets, the receiving device needs to feedback a status report on the retransmitted unconfirmed data packets to confirm the retransmitted data packets. After confirming the retransmitted data packets (that is, after all the sent data packets are confirmed), the sending device can re-SN the new data packets and continue to send new data packets.

[0115] In actual application, the specific implementation of sending the first information to the receiving device may include: when retransmitting an unconfirmed data packet, using 1 bit of information in the data packet (specifically, it may 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 may 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.

[0116] In actual application, if the received status report indicates that the retransmitted unconfirmed data packets are not confirmed, the sending device needs to retransmit the unconfirmed data packets again until all data packets are confirmed.

[0117] In actual application, during the execution of step 302, when the statistical number is equal to the first threshold, the sending window stagnates and the sending device stops sending new data packets. At this time, the sending device can actively retransmit the unconfirmed data packets and send information indicating a feedback status report to the receiving device, and then re-count the number of unconfirmed data packets based on the received status report. When the number is less than the first threshold, the sending window slides and the sending device can continue to send data packets.

[0118] Accordingly, the embodiment of the present application also provides a data receiving method, which is applied to a receiving device, such as Figure 5 As shown, including:

[0119] Step 501: receiving data packets and counting the number of data packets that have not been received;

[0120] Step 502: When the counted number is less than the first threshold, continue to receive data packets.

[0121] Here, in actual application, the size of the first threshold can be set as needed. The first threshold represents the timing when the receiving window (also known as a sliding window, which may also be called a receiving window at the receiving end) stops sliding (also known as a window stagnation). When the number of unreceived data packets in the receiving device is equal to the first threshold, the receiving window stops sliding and the receiving device stops receiving new data packets.

[0122] In actual applications, in order to ensure the reliability of data transmission, the receiving device can provide feedback to the sending device on which data packets are received and which are not received in the receiving device, so that the sending device can retransmit the data packets that the receiving device has not received based on the feedback information.

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

[0124] 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;

[0125] 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.

[0126] Specifically, 1 bit of information may be used 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.

[0127] Based on this, in one embodiment, the specific implementation of counting the number of data packets that have not been received may include:

[0128] Record the sequence numbers of the data packets that have not been received, and obtain the number of recorded sequence numbers;

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

[0130] Here, in actual application, when the receiving device counts the number of unreceived data packets, the counting method may include: using an array to count the number of unreceived data packets, each non-zero element (also understood as a non-zero item) in the array corresponds to an unreceived data packet.

[0131] Specifically, in one embodiment, the recording of the sequence numbers of the data packets that have not been received to obtain the number of the recorded sequence numbers; and the specific implementation of determining the number of the data packets that have not been received using the number of sequence numbers may include:

[0132] The SNs of the unreceived data packets are arranged in an array according to the data, and the number of elements in the array is associated with the first threshold;

[0133] 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.

[0134] In actual application, the receiving device can set an array with an initial value of 0, and the number of elements in the array (which can also be understood as the length of the array) is equal to the first threshold. When the sent data packet is not received, the SN corresponding to the unreceived data packet is set in the array. When the data packet corresponding to the set element in the array is received, the value of the corresponding element in the array is set to zero. Since SN 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. At the same time, when all elements in the array are non-zero, it can be determined that the number of unreceived data packets is equal to the first threshold.

[0135] Exemplarily, assuming 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, an array Rx Next Ack is defined, the array size is equal to 5 (i.e., the first threshold), the array initial value is 0, and the SNs corresponding to the data packets that have not been received are stored in the array in sequence, that is, Rx Next Ack = [3, 5, 7, 0, 0]. At this time, the array length (i.e., the number of non-zero items) before the first 0 (also called the terminator) in the array is counted to determine the number of data packets that have not been received, which is equal to 3 here. When the number of data packets that have not been received is less than the array size, the receiving device can receive new data packets (i.e., data packets with SN = 10, 11) until the number of data packets that have not been received is equal to the array size.

[0136] In actual application, during the execution of step 502, when the statistical number is equal to the first threshold, the receiving window stagnates and the receiving device stops receiving new data packets. At this time, the receiving device can instruct the sending device to retransmit the unreceived data packets through active feedback status report, and then after receiving the previously unreceived data packets, re-count the number of unreceived data packets. When the number is less than the first threshold, the receiving window slides and the receiving device can continue to receive data packets.

[0137] In the data sending method and data receiving method provided by the embodiments of the present application, the sending device sends a data packet and counts the number of unconfirmed data packets; when the counted number is less than a first threshold, the data packet continues to be sent; at the same time, the receiving device receives the data packet and counts the number of unreceived data packets; when the counted number is less than the first threshold, the data packet continues to be received. In the scheme provided by the embodiments of the present 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, which can speed up the data transmission rate and reduce the data transmission delay.

[0138] The present application is further described in detail below in conjunction with application examples.

[0139] In actual business scenarios, when the RLC layer works in AM mode, the sender often stalls the sending window because the data packets at the lower limit of the window are not confirmed, resulting in the sender being unable to continue sending 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.

[0140] For example, Figure 6As shown, the sender sends a data packet to the receiver, the window size of the sending window is 10, and the SN of the sent data packet is 3, 4, ..., 12, among which the data packet with SN = 8 is a Poll PDU (which can be expressed as poll = 1), and the rest of the data packets are not Poll PDU, at this time, since the number of data packets sent 10 is equal to the window size of the sending window, the sending window is stagnant and the sender cannot send new data packets. Accordingly, at the receiving end, data packets of SN=3, 4...12 are received, among which the data packet of SN=3 is not received. At the same time, based on the polling indication (i.e., poll=1) contained in the received data packet of SN=8, a status report is sent to the sending end, and the status report includes: the last received data packet ACK_SN=12, and the unreceived data packet NACK_SN=3; the sending end determines that the data packet of SN=3 needs to be retransmitted according to the status report, and poll=1 corresponding to the data packet can be set; the receiving end receives the retransmitted data packet of SN=3, and at the same time, based on the polling indication (i.e., poll=1) contained in the received data packet of SN=3, a status report is sent, and the status report includes the last received data packet ACK_SN=3 (i.e., confirmation information of the data packet of SN=3); after the sending end receives the confirmation information of the data packet of SN=3, the sending window can slide, so that the sending end can continue to send new data packets.

[0141] Based on this, in the application example of the present application, it can be achieved that there will be no stagnation due to a small number of data packets not being confirmed, and the data transmission rate can be accelerated and the data transmission delay can be reduced.

[0142] like Figure 7 As shown, one implementation of the data transmission system for data transmission includes:

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

[0144] Specifically, the SNs of the unconfirmed data packets may be arranged in an array in sequence, and the number of the unconfirmed data packets may be determined using the array.

[0145] Accordingly, the receiving end starts receiving data packets and counts the number of data packets that have not been received;

[0146] Specifically, the SNs of the unreceived data packets may be arranged in an array in sequence, and the number of the unreceived data packets may be determined using the array.

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

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

[0149] It should be noted that in order to prevent the receiving end from not receiving the Poll PDU and thus being unable to feedback the status report in time, the sending end can start the polling retransmit timer (which can be expressed in English as Poll RetransmitTimer or t_PollRetransmit) after sending the Poll PDU. When the sending end receives the status report fed back by the receiving end, the polling retransmit timer is terminated; when the polling retransmit timer times out and there are still data packets to be sent, it is determined that the next data packet to be sent is the Poll PDU, and the corresponding poll=1 is set to instruct the receiving end to feedback the status report.

[0150] At the same time, since the RLC layer does not have a reordering mechanism in the related technology, when the receiving end receives out-of-order (i.e., SN non-sequentially arranged) data packets, it can submit the out-of-order data packets to the Packet Data Convergence Protocol (PDCP) layer. After receiving the out-of-order data packets, the PDCP layer reorders the data packets. At the same time, the PDCP layer starts the PDCP reordering timer (which can be expressed as Re-Ordering Timer in English). When the PDCP reordering timer times out, the PDCP layer discards the unreceived data packets (that is, the new data packets submitted by the RLC layer are no longer received for this reordering process). At this time, the PDCP layer can be set to inform the RLC layer not to continue to retransmit the discarded data packets after the PDCP reordering timer times out (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 be prevented from retransmitting the discarded data packets and reducing the waste of air interface resources.

[0151] Step 702: The sending end determines whether the number of unconfirmed data packets is less than a preset threshold;

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

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

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

[0155] In actual application, in the transmitting end, the window size parameter (i.e., AM_Window_Size) of the transmitting window in the related art can be reused as the preset threshold. That is, each item in the transmitting window corresponds to the SN of an unconfirmed data packet. When the number of unconfirmed data packets is less than the size parameter of the transmitting window, the transmitting end can continue to send data until the number of unconfirmed datagrams is equal to the size parameter of the transmitting window. At this time, the transmitting window is full, the transmitting window stops sliding, and the transmitting end stops sending data.

[0156] It should be noted that when the number of unconfirmed data packets is less than the size parameter of the sending window, the sending end continues to send data, specifically including: sending a new data packet to the receiving end, and / or, according to the received status information, retransmitting the unconfirmed data packet. At this time, the sending end updates the number of unconfirmed data packets counted.

[0157] 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;

[0158] 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;

[0159] Specifically, in the receiving end, the window size parameter (i.e., AM_Window_Size) of the receiving window in the related art can be reused as the preset threshold. That is, at this time, 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 size parameter of the receiving window, the receiving end can continue to receive data until the number of unreceived datagrams is equal to the size parameter of the receiving window, the receiving window is filled, the receiving window stops sliding, and the receiving end stops receiving data.

[0160] It should be noted that when the number of unreceived data packets is less than the size parameter of the receiving window, the receiving end continues to receive data specifically including: receiving new data packets sent by the sending end, and / or receiving unreceived data packets retransmitted by the sending end. At this time, the receiving end updates the number of unreceived data packets counted.

[0161] Step 704: After the sending end stops sending data, the sending end retransmits the data packets that have not been confirmed;

[0162] 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 the Poll PDU, so that when the receiving end receives the Poll PDU, it determines that a status report needs to be fed back for the retransmitted data packets. The sender updates the number of unconfirmed data packets counted according to the received status report. When the number of unconfirmed data packets is less than the preset threshold, that is, at least one data packet among the retransmitted data packets is confirmed, the sending window can continue to slide, and the sender can continue to send data until the sending window is filled again.

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

[0164] 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, and the sending end retransmits the unreceived data packets according to the received status report. The receiving end receives the retransmitted data packets and updates the number of counted unreceived data packets. When the 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, the receiving window can continue to slide, and the receiving end can continue to receive data until the receiving window is filled again.

[0165] In this way, when the sending end and the receiving end transmit data, by executing steps 701 to 704, the sending window will only stagnate when the sending window is filled with unconfirmed data packets. Correspondingly, the receiving window will only stagnate when the receiving window is filled with unreceived data packets. Compared with the existing sliding window mechanism, 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 delay requirements of the user side.

[0166] For example, Figure 8As shown, assuming that the size of the sending window is 10, a PollPDU is set for every six data packets (that is, every time 6 data packets are sent, poll corresponding to the 6th data packet is set to 1). In this way, at the beginning of a new data transmission task, the number of unconfirmed (unacknowledged) 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, and poll corresponding to the data packet with SN = 6 is set to 1; 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 not confirmed, that is, the number of unconfirmed data packets is 10, which is equal to the size of the sending window (that is, equal to the preset threshold). At this time, the sending window is stagnant, and the sending end stops sending new data packets;

[0167] Correspondingly, after the new data transmission task starts, the receiving end starts to receive data packets, specifically, receives data packets with SN=2, 3, ..., 10, and does not receive data packets with SN=1, wherein 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.

[0168] The sender receives the status report, and determines from the status report that the data packet with SN=1 is not confirmed, and the data packets with SN=2,3,…,10 are confirmed. The number of unconfirmed data packets in the statistics is updated to 1. Since the updated number of unconfirmed data packets is less than the size of the sending window, the sending window can continue to slide, and the sender continues to send data packets. At this time, the sender can determine to retransmit the data packet with SN=1 according to the status report, and at the same time, it can continue to send new data packets (i.e., data packets with SN=11,12,…,19) before the sending window is full again, until the number of unconfirmed data packets is equal to the size of the sending window 10 again, wherein poll=1 is set corresponding to the data packet with SN=15. In this way, compared with the existing sliding window mechanism, the sending window does not need to wait for the retransmission of the data packet with SN=1 and receive the status report confirming that the data packet with SN=1 is received before it can slide forward, that is, it will not stagnate due to a small number of data packets (i.e., data packets with SN=1) not being confirmed, thereby reducing the stagnation time of the sliding window, ensuring the data transmission rate, and better meeting the delay requirements of the user plane.

[0169] It should be noted that when the scheme 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, such as Fig. 9 As shown, 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, 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 stops sliding and stops sending new data packets.

[0170] At this time, if Fig.10 As shown, after stopping sending new data packets, the sending end actively retransmits the unconfirmed data packets in SN order, that is, retransmits the data packets of SN=3, 5, 7, and sets poll=1 corresponding to the last retransmitted data packet (that is, the data packet of SN=7); the receiving end receives the data packets of SN=3, 5, 7, and identifies the poll=1 corresponding to the data packet of SN=7, and sends a status report, and the status report includes: ACK_SN=7; the sending end receives the status report and determines that the data packets of 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.

[0171] 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 be stalled due to a small number of unconfirmed data packets. It can speed up the data transmission rate and reduce the data transmission delay.

[0172] In order to implement the method of the sending device side of the embodiment of the present application, the embodiment of the present application also provides a data sending device, which is arranged on the sending device, such as Fig.11 As shown, the device comprises:

[0173] A first statistical unit 1101 is used to count the number of unconfirmed data packets;

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

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

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

[0177] retransmitting an unconfirmed data packet, and sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the retransmitted unconfirmed data packet;

[0178] The sending device also includes:

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

[0180] In one embodiment, the first statistical unit 1101 is specifically configured to:

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

[0182] Using the number of sequence numbers, the number of unacknowledged data packets is determined.

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

[0184] 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;

[0185] The number of non-zero elements in the count array is used as the number of unconfirmed data packets.

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

[0187] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the data packets;

[0188] The first statistical unit 1101 is further configured to:

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

[0190] 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.

[0191] It should be noted that: the data sending device provided in the above embodiment only uses the division of the above program units as an example to illustrate when sending data. In actual applications, the above processing can be assigned to different program units as needed, that is, the internal structure of the device is divided into different program units to complete all or part of the processing described above. In addition, the data sending device provided in the above embodiment and the data sending method embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0192] In order to implement the method on the receiving device side of the embodiment of the present application, the embodiment of the present application also provides a data receiving device, which is arranged on the receiving device, such as Fig.12 As shown, the device comprises:

[0193] The second statistical unit 1201 is used to count the number of unreceived data packets;

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

[0195] In one embodiment, the second statistical unit 1201 is specifically used for:

[0196] Record the sequence numbers of the data packets that have not been received, and obtain the number of recorded sequence numbers;

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

[0198] In one embodiment, the second statistical unit 1201 is specifically used to:

[0199] The SNs of the unreceived data packets are arranged in an array according to the data, and the number of elements in the array is associated with the first threshold;

[0200] 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.

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

[0202] 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;

[0203] The data receiving device further includes:

[0204] The second sending unit is used 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.

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

[0206] It should be noted that: when the data receiving device provided in the above embodiment performs data reception, only the division of the above program units is used as an example. In actual applications, the above processing can be assigned to different program units as needed, that is, the internal structure of the device is divided into different program units to complete all or part of the processing described above. In addition, the data receiving device provided in the above embodiment and the data receiving method embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0207] Based on the hardware implementation of the above program modules, and in order to implement the method of the sending device side of the embodiment of the present application, the embodiment of the present application also provides a sending device, such as Fig.13 As shown, the sending device 1300 includes:

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

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

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

[0211] Count the number of unacknowledged packets;

[0212] The first communication interface 1301 is used for:

[0213] Send data packets; and continue to send data packets when the counted number is less than the first threshold.

[0214] In one embodiment, the first communication interface 1301 is further used for:

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

[0216] retransmitting an unconfirmed data packet, and sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the retransmitted unconfirmed data packet;

[0217] A status report sent by the receiving device is received, wherein the received status report indicates whether the retransmitted unconfirmed data packet is confirmed.

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

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

[0220] Using the number of sequence numbers, the number of unacknowledged data packets is determined.

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

[0222] 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;

[0223] The number of non-zero elements in the count array is used as the number of unconfirmed data packets.

[0224] In one embodiment, the first communication interface 1301 is further used for:

[0225] When the number of sent data packets reaches a second threshold, sending first information to a receiving device, wherein the first information instructs the receiving device to send a status report for the data packets;

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

[0227] 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.

[0228] Of course, in actual application, the various components in the transmitting device 1300 are coupled together through the bus system 1304. It can be understood that the bus system 1304 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 04 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Fig.13 Various buses are labeled as bus system 1304 .

[0229] 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.

[0230] The method disclosed in the above embodiment 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. In the implementation process, each step of the above method can be completed by an integrated logic circuit of the hardware in the first processor 1302 or an instruction in the form of software. The above-mentioned first processor 1302 may be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates 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. In combination with the steps of the method disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in the first memory 1303, and 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.

[0231] In an exemplary embodiment, the sending device 1300 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), field programmable gate array (FPGA), general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the aforementioned method.

[0232] Based on the hardware implementation of the above program modules, and in order to implement the method of the receiving device side of the embodiment of the present application, the embodiment of the present application also provides a receiving device, such as Fig.14 As shown, the receiving device 1400 includes:

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

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

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

[0236] Count the number of packets not received;

[0237] The second communication interface 1401 is used for:

[0238] Receive data packets; and continue to receive data packets when the counted number is less than the first threshold.

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

[0240] Record the sequence numbers of the data packets that have not been received, and obtain the number of recorded sequence numbers;

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

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

[0243] The SNs of the unreceived data packets are arranged in an array according to the data, and the number of elements in the array is associated with the first threshold;

[0244] 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.

[0245] In one embodiment, the second communication interface 1401 is further used for:

[0246] 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;

[0247] 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.

[0248] 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.

[0249] Of course, in actual application, the various components in the receiving device 1400 are coupled together through the bus system 1404. It can be understood that the bus system 1404 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 1404 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Fig.14 Various buses are labeled as bus system 1404.

[0250] 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.

[0251] The method disclosed in the above embodiment of the present application can be applied to the second processor 1402, or implemented by the second processor 1402. The second processor 1402 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the second processor 1402. The above-mentioned second processor 1402 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, 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, etc. In combination with the steps of the method disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in the second memory 1403. The second processor 1402 reads the information in the second memory 1403 and completes the steps of the above method in combination with its hardware.

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

[0253] 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 ferromagnetic random access memory, 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 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, SyncLink Dynamic Random Access Memory), and direct RAM bus random access memory (DRRAM, Direct Rambus Random Access Memory).The memories described in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

[0254] 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, such as Fig.15 As shown, the system includes: a sending device 1501 and a receiving device 1502.

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

[0256] In an exemplary embodiment, the embodiment of the present application further provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, for example, including a first memory 1303 storing a computer program, the computer program can be executed by the first processor 1302 of the sending device 1300 to complete the steps of the aforementioned sending device side method, and for another example, including a second memory 1403 storing a computer program, the computer program 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 memory, optical disk, or CD-ROM.

[0257] 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.

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

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

Claims

1. A data transmission method, It is characterized in that Applicable to sending equipment, including: 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, It is characterized in that 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, It is characterized in that 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 instructs 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, It is characterized in that 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, It is characterized in that 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, It is characterized in that The method further comprises: When the number of sent data packets reaches a second threshold, sending first information to a receiving device, wherein the first information instructs 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, It is characterized in that Applicable to receiving equipment, including: 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, It is characterized in that 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, It is characterized in that 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, It is characterized in that 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 transmitting device, It is characterized in that include: A first statistical unit, used for counting the number of unconfirmed data packets; The sending unit is used to send data packets; when the counted number is less than a first threshold, the sending of data packets continues.

12. A data receiving device, It is characterized in that include: A second statistical unit, used for counting the number of data packets not received; A receiving unit, used for receiving a data packet; When the counted number is less than the first threshold, data packets continue to be received.

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

14. A receiving device, It is characterized in that include: a second processor, configured to count the number of unreceived data packets; The second communication interface is used for the receiving unit to receive the data packet; When the counted number is less than the first threshold, data packets continue to be received.

15. A sending device, It is characterized in that include: a first processor and a first memory for storing a computer program executable on the processor, Wherein, when the first processor is used to run the computer program, the steps of the method described in any one of claims 1 to 6 are executed.

16. A receiving device, It is characterized in that include: a second processor and a second memory for storing a computer program executable on the processor, Wherein, when the second processor is used to run the computer program, the steps of the method described in any one of claims 7 to 10 are executed.

17. A storage medium having a computer program stored thereon, It is characterized in that 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.