A data transmission method and apparatus

Abstract

One or more embodiments of the present specification relate to the technical field of computer network, and particularly relate to a data transmission method and device. The data transmission method comprises: obtaining a retransmission request of a receiving end; the retransmission request is used to indicate a data packet judged as lost at the receiving end; performing recoverability simulation evaluation on the data packet indicated by the retransmission request; the recoverability simulation evaluation is used to judge whether at least part of the data packet indicated by the retransmission request can be locally recovered by forward error correction at the receiving end; according to the result of the recoverability simulation evaluation, determining the data packet judged as unable to be recovered by forward error correction as a data packet to be retransmitted, and performing a retransmission operation on the data packet to be retransmitted. The method effectively avoids redundant retransmission, and significantly improves the bandwidth utilization efficiency.

Description

Technical Field

[0001] This specification relates to the field of computer network technology, and more particularly to a data transmission method and apparatus. Background Technology

[0002] In scenarios with high real-time requirements, such as real-time audio and video communication, network packet loss is one of the main factors affecting communication quality. To address network packet loss, the Automatic Repeat reQuest (ARQ) mechanism is typically used to recover lost data packets. When the receiving end detects packet loss, it sends a retransmission request to the sending end, indicating the lost data packets. Upon receiving the retransmission request, the sending end directly adds all the indicated data packets to the retransmission queue and executes the transmission.

[0003] In the above manner, the sending end will retransmit the requested data packet indiscriminately after receiving the retransmission request, which may cause unnecessary bandwidth waste and transmission delay, reducing the overall transmission efficiency. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a data transmission method is proposed, applied at a sending end, comprising: acquiring a retransmission request from a receiving end; the retransmission request indicating a data packet determined to be lost at the receiving end; performing a recoverability simulation evaluation on the data packet indicated by the retransmission request; the recoverability simulation evaluation determining whether at least a portion of the data packet indicated by the retransmission request can be locally recovered at the receiving end through forward error correction; and, based on the result of the recoverability simulation evaluation, identifying data packets determined to be unrecoverable through forward error correction as data packets to be retransmitted, and performing a retransmission operation on the data packets to be retransmitted.

[0005] According to a second aspect of one or more embodiments of this specification, a data transmission method is proposed, applied at a receiving end, comprising: acquiring data transmission status information; determining out-of-order characteristic information for characterizing the current degree of out-of-order reception based on the data transmission status information; adjusting a current adaptive waiting time based on the out-of-order characteristic information; the adaptive waiting time being a waiting time for determining data packet loss; determining data packets that have not arrived after the adaptive waiting time as lost data packets; and sending a retransmission request to a sending end based on the determined lost data packets.

[0006] According to a third aspect of one or more embodiments of this specification, a data transmission apparatus is provided, applied at a transmitting end, comprising: an acquisition module, configured to acquire a retransmission request from a receiving end; the retransmission request indicating a data packet determined to be lost at the receiving end; a recoverability simulation evaluation module, configured to perform a recoverability simulation evaluation on the data packet indicated by the retransmission request; the recoverability simulation evaluation determining whether at least a portion of the data packets indicated by the retransmission request can be locally recovered at the receiving end through forward error correction; and a retransmission module, configured to, based on the result of the recoverability simulation evaluation, identify data packets determined to be unrecoverable through forward error correction as data packets to be retransmitted, and perform a retransmission operation on the data packets to be retransmitted.

[0007] According to a fourth aspect of one or more embodiments of this specification, a data transmission apparatus is provided, applied at a receiving end, comprising: an acquisition module for acquiring data transmission status information; a determination module for determining, based on the data transmission status information, out-of-order characteristic information characterizing the current degree of out-of-order reception; an adjustment module for adjusting a current adaptive waiting time based on the out-of-order characteristic information; wherein the adaptive waiting time is a waiting time for determining data packet loss; and a retransmission request sending module for determining data packets that have not arrived after the adaptive waiting time as lost data packets, and sending a retransmission request to the sending end based on the determined lost data packets.

[0008] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the data transmission method described above by executing the executable instructions, or implements the steps of the data transmission method described above.

[0009] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the data transmission method described above, or implement the steps of the data transmission method described above.

[0010] According to a seventh aspect of one or more embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the data transmission method described above, or implement the steps of the data transmission method described above.

[0011] As can be seen from the above embodiments, after receiving a retransmission request, the sending end does not directly retransmit the data packet indicated by the retransmission request. Instead, it performs a recoverability simulation assessment on the data packet indicated by the retransmission request, and only identifies data packets that cannot be locally recovered through forward error correction as data packets to be retransmitted. This effectively avoids redundant retransmissions and significantly improves bandwidth utilization efficiency. Because the retransmission of unnecessary data packets is reduced, the processing burden on the sending end is lessened, the queuing time for data packets is shortened, and data packets that truly need retransmission can be sent more promptly. At the same time, the receiving end does not need to process a large number of redundant retransmission packets, thereby shortening the overall time for packet loss recovery.

[0012] Furthermore, the receiving end dynamically adjusts the waiting time for packet loss assessment based on the current network's out-of-order severity and sends retransmission requests after a timeout, effectively reducing false retransmissions caused by network out-of-order issues. For example, when out-of-order packets are severe, the waiting time can be appropriately extended to avoid sending invalid retransmission requests prematurely, thereby saving uplink bandwidth; when out-of-order packets are minor, the waiting time can be automatically shortened, allowing the receiving end to identify packet loss and initiate retransmissions earlier, reducing packet loss recovery delay. This adaptive adjustment mechanism effectively improves transmission performance under different network conditions. Attached Figure Description

[0013] Figure 1 This is a flowchart of a data transmission method provided in an exemplary embodiment of this specification; Figure 2 This is a flowchart of a data transmission method provided by another exemplary embodiment of this specification; Figure 3 This is a schematic diagram of the overall logical interaction of the data transmission method provided in an exemplary embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a device 400 provided in an exemplary embodiment of this specification; Figure 5 This is a schematic diagram of a data transmission device 500 applied to a data transmission system at the transmitting end, provided in an exemplary embodiment of this specification. Figure 6 This is a schematic diagram of a data transmission device 600 applied to a receiving end of a data transmission system, provided in an exemplary embodiment of this specification. Detailed Implementation

[0014] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0015] The technical solutions described in this specification can be applied to real-time media transmission scenarios, especially audio and video communication systems with strict requirements for low latency and high reliability, such as real-time audio and video calls, video conferencing, interactive live streaming, online education, and cloud gaming based on Web Real-Time Communication (WebRTC). In these scenarios, data transmission typically uses the Real-time Transport Protocol (RTP) as the media data carrier protocol, supplemented by the RTP Control Protocol (RTCP) to implement transmission quality feedback and control.

[0016] In a real-time communication system, the sending end is responsible for sending consecutive RTP data packets to the receiving end. Upon receiving the data packets, the receiving end monitors the continuity of the packet sequence numbers. When a gap in the sequence number is detected (i.e., some packets with certain sequence numbers have not arrived as expected), the receiving end starts a fixed-length wait timer to handle potential delays caused by network out-of-order delivery. If the missing packets still do not arrive within the wait time, they are considered lost packets, and a retransmission request is initiated to the sending end via a Negative Acknowledgment (NACK) message in the RTCP protocol, indicating the sequence number of the data packet that needs to be retransmitted.

[0017] After receiving a retransmission request from the receiver, the sending end adds the corresponding data packet to the retransmission queue according to the sequence number indicated in the request. The sending scheduler (Pacer) then performs the actual retransmission based on the currently estimated available bandwidth and queue priority. This process relies on the Automatic RepeatreQuest (ARQ) mechanism between the sending and receiving ends.

[0018] However, the aforementioned retransmission mechanism has several shortcomings in its implementation. For example, upon receiving a retransmission request, the sender often retransmits all requested data packets indiscriminately, resulting in redundant retransmission of a large number of data packets that the receiver could recover locally, leading to wasted bandwidth and reduced transmission efficiency. Furthermore, the receiver's fixed waiting time makes it difficult to adapt to dynamically changing network out-of-order conditions. This can easily lead to misjudgment of packet loss and unnecessary retransmission requests when network out-of-order conditions are severe, or delayed recovery due to excessive waiting time when out-of-order conditions are minor.

[0019] The technical solutions in this specification will be described in detail below with reference to specific embodiments and accompanying drawings.

[0020] First, the improvement scheme for the sending end will be explained. As mentioned earlier, if the sending end indiscriminately retransmits all requested data packets after receiving a retransmission request, it may lead to a large amount of redundant transmission. For example, some lost packets could be recovered locally at the receiving end using methods such as Forward Error Correction (FEC). This indiscriminate retransmission will result in a serious waste of bandwidth. To address this, this specification proposes a data transmission method that filters the retransmission requests from the receiving end at the sending end, retransmitting only the data packets that cannot be recovered locally at the receiving end, thereby maximizing bandwidth utilization efficiency while ensuring recovery effectiveness. The method will be described in detail below with specific embodiments.

[0021] Figure 1 This specification illustrates a flowchart of a data transmission method provided in an exemplary embodiment, which is applied at the sending end, such as... Figure 1 As shown, the method includes: S101: Obtain a retransmission request from the receiving end; the retransmission request is used to indicate data packets that are determined to be lost at the receiving end.

[0022] In real-time audio and video communication, the receiving end continuously monitors the reception of RTP data packets from the sending end. When the receiving end detects that the sequence numbers of some data packets are not consecutive, and after internal dynamic NACK delay judgment, confirms that they are truly lost, it generates a retransmission request. This retransmission request is generally a Negative Acknowledgment (NACK) message based on the RTP control protocol. The retransmission request indicates the sequence numbers of the data packets that the receiving end determined to be lost and need to be retransmitted by the sending end when sending the retransmission request. The sending end determines the data packets that the receiving end expects to retransmit by parsing the retransmission request.

[0023] S102: Perform a recoverability simulation evaluation on the data packets indicated by the retransmission request; the recoverability simulation evaluation is used to determine whether at least a portion of the data packets indicated by the retransmission request can be locally recovered at the receiving end through forward error correction.

[0024] In practice, after receiving a retransmission request, the sending end does not blindly retransmit all the data packets requested by the receiving end. Instead, it uses its own maintained data packet reception status to perform a recoverability simulation assessment for each data packet claimed to be lost by the receiving end. The data packet reception status indicates the status of data packets received or lost by the receiving end. This includes, for example, the status of data packets (including original media packets and redundant packets) already received by the receiving end inferred by the sending end based on Transport-wide Congestion Control (Transport-CC) feedback information, or the status of lost data packets determined by the NACK message carrying the retransmission request. Here, the Transport-CC feedback information mainly includes packet-by-packet feedback information such as the transport-level sequence number of each data packet, its reception status (indicating whether it arrived successfully), and arrival time offset. Through this information, the sending end can determine the receiving end's reception status for the sent data packets (including original media packets and FEC redundant packets) and maintain a receiving end data packet reception status table. Based on this table, the sending end can determine the data packets currently received by the receiving end. The NACK message is mainly used to indicate information about data packets lost by the sending end. The receiver explicitly lists the sequence numbers of the packets it determines to be lost (e.g., sequence numbers 3, 5, 7) in the NACK message. Upon receiving the NACK message, the sender can infer that packets not appearing in this list but within the normal transmission window have most likely been received by the receiver. Because Transport-CC feedback provides positive acknowledgments packet-by-packet (i.e., whether each sequence number has arrived, and the arrival time offset), it can maintain the receiver's packet reception status more accurately than NACK messages.

[0025] The aforementioned simulation evaluation of data packet recoverability is used to determine whether the receiving end can actually recover a claimed lost data packet using only the received media packets and redundant packets, without needing to retransmit the packet. If the simulation results show that a data packet cannot be recovered by FEC, the data packet is included in the minimum retransmission set; if it shows that it can be recovered, the data packet is filtered out from the retransmission request list.

[0026] In one implementation, the recoverability simulation evaluation of the data packets indicated by the retransmission request can be performed in the following manner: based on the forward error correction grouping information recorded by the sending end, determine the forward error correction group to which each data packet indicated by the retransmission request belongs and the data packet information in the forward error correction group; based on the data packet reception status and forward error correction redundancy packet reception status of the receiving end, determine the data packets and redundancy packets that have arrived at the receiving end in each forward error correction group; based on the data packets and redundancy packets that have arrived at the receiving end in the forward error correction group, and the data packet information in the forward error correction group, determine whether the lost data packets in the forward error correction group can be recovered locally at the receiving end through forward error correction, and obtain the result of the recoverability simulation evaluation.

[0027] Each of the aforementioned forward error correction (FEC) groups typically includes multiple original data packets (media packets) and at least one redundant packet. For example, when the sending end performs FEC encoding, it divides the multiple original media packets into a protection group and generates one or more redundant packets based on that group. For instance, the four original media packets with sequence numbers 4, 5, 6, and 7 are grouped together, and an XOR FEC packet, i.e., a redundant packet, is generated. This redundant packet can be used to recover any one of the lost packets from the four original media packets.

[0028] In the above implementation, the sending end uses its own recorded FEC encoding structure information, combined with its speculation on the data packets and redundant packets already received by the receiving end, to simulate the process of the receiving end performing FEC decoding, thereby determining whether a data packet requested for retransmission can be directly recovered locally by FEC at the receiving end without actually being retransmitted.

[0029] In practice, the sending end first determines the FEC group to which the lost packet belongs and the information within that group. Upon receiving a retransmission request, the sending end extracts a list of sequence numbers of the data packets identified as lost by the receiving end, such as packets with sequence numbers 5, 6, and 7. Then, based on its recorded FEC group information, the sending end determines which FEC group each lost packet belongs to and obtains all data packet information within that group, including which original media packets (e.g., packets 4, 5, 6, and 7) are included in the group, which redundant packets were generated, and the encoding dependencies between these packets.

[0030] Next, the sender determines the media packets and redundant packets that have arrived at the receiver within the FEC group. For each lost packet's FEC group, the sender queries its maintained receiver packet reception status table. This table records the media packets and redundant packets that the sender infers from the receiver's feedback, indicating that the receiver has already received them. For example, for the group with sequence numbers 4, 5, 6, and 7, the sender might infer that the receiver has received media packets 4 and 7, but is missing media packets 5 and 6; simultaneously, the receiver has received the redundant packet FEC (4,5,6,7).

[0031] Next, the sending end simulates a determination of whether the lost packet can be recovered locally at the receiving end using FEC. Based on the obtained FEC grouping information and the media packets and redundant packets that have arrived at the receiving end within that group, the sending end performs a virtual FEC decoding calculation. If the calculation result shows that a lost packet can be recovered using the existing media packets and redundant packets, the lost packet is marked as "recoverable via FEC" and thus filtered out in subsequent retransmission operations; conversely, if the simulation calculation finds that the lost packet cannot be recovered even using all the arrived packets, it is marked as "unrecoverable via FEC" and retained in the retransmission list.

[0032] For example, in the above example, suppose the sender divides the original RTP packets 4, 5, 6, and 7 into a FEC protection group. This group uses an XOR encoding rule to generate an XOR FEC redundancy packet based on these four packets, denoted as FEC(4,5,6,7), whose content is the XOR result of packets 4, 5, 6, and 7. The sender receives a NACK request from the receiver, requesting the retransmission of packet 5. The sender queries its maintained receiver data packet reception status table and infers that the receiver has currently received media packets 4, 7, and the FEC redundancy packet (4,5,6,7), while packets 5 and 6 are missing. At this point, the sender needs to simulate determining whether packet 5 can be recovered locally at the receiver using FEC.

[0033] For a protection group that generates an XOR FEC redundancy packet from four original media packets, the FEC redundancy packet provides only one constraint equation. When only one original media packet is missing, the missing packet can be uniquely solved using the remaining three original media packets and the FEC redundancy packet; however, when two or more original media packets are missing, this single constraint equation cannot solve for multiple unknowns, and therefore, none of the missing packets can be recovered. In this example, the receiver is missing both packets 5 and 6. With only the three known quantities, neither packet 5 nor packet 6 can be solved. Therefore, after simulation and evaluation, the sender determines that neither packet 5 nor packet 6 can be recovered locally at the receiver using FEC, and both need to be added to the retransmission list and retransmitted. In contrast, if the receiver is missing only packet 5, and packets 4, 6, 7, and the FEC redundancy packet are all received, the sender can determine that packet 5 can be recovered using FEC. In this case, packet 5 can be uniquely calculated using the XOR result of packets 4, 6, 7, and the FEC redundancy packet, without the need for retransmission.

[0034] Through the above implementation method, the sending end can use its existing FEC grouping information and the receiving end's data packet reception status data to filter out invalid retransmission requests that the receiving end can recover on its own through FEC, thereby reducing unnecessary retransmission traffic and improving bandwidth utilization efficiency, without requiring the receiving end to report additional information.

[0035] S103: Based on the results of the recoverability simulation evaluation, data packets that are determined to be unrecoverable through forward error correction are identified as data packets to be retransmitted, and a retransmission operation is performed on the data packets to be retransmitted.

[0036] After completing the FEC recoverability simulation evaluation at the sending end, a filtered and streamlined minimum retransmission set is obtained. The sending end then hands these data packets over to the underlying transmission controller (Pacer, the scheduling module used by the sending end to smoothly transmit data packets), and actually sends them out based on the current bandwidth estimate and transmission queue priority.

[0037] Furthermore, this specification proposes a retransmission compensation mechanism. If a retransmission is delayed or dropped due to bandwidth constraints or scheduling issues, it can be placed in a compensation buffer queue and resent at a later time, ensuring that the retransmission operation is performed as effectively as possible. This will be explained in detail later.

[0038] In one implementation, a retransmission operation can be performed on the data packet to be retransmitted according to the following steps: Based on the current available bandwidth and the status of the sending scheduling queue, at least one schedulable data packet is determined from the data packets to be retransmitted, and actual retransmission is performed; data packets in the data packets to be retransmitted that were not actually sent in this scheduling are written into the compensation buffer queue; when the preset compensation trigger condition is met, data packets that have not exceeded the preset validity period are read from the compensation buffer queue and retransmission is initiated.

[0039] The above implementation provides a retransmission compensation mechanism to address situations where retransmitted packets cannot be actually sent due to bandwidth constraints or transmission scheduling congestion. Specifically, after the sending end determines the list of data packets to be retransmitted through FEC recoverability simulation evaluation, when performing a retransmission operation, it first determines at least one schedulable data packet from the list of data packets to be retransmitted based on the current available bandwidth and the queue status of the transmission scheduler, and then performs the actual retransmission. This ensures that the retransmission behavior does not exceed the current network bandwidth capacity and does not interfere with normal real-time media transmission due to sudden retransmission traffic.

[0040] For data packets not selected in the retransmission list due to insufficient bandwidth or queue congestion, they are not discarded but written into a compensation buffer queue, with the write time of each packet recorded. Subsequently, the preset compensation trigger conditions are monitored. When these conditions are met, data packets that have not yet exceeded their preset validity period are read from the compensation buffer queue and resubmitted to the sending scheduler, initiating a new round of retransmission attempts. For data packets that have exceeded their validity period, no compensation retransmission is performed to avoid sending expired data packets that are no longer of practical significance.

[0041] Through the above compensation mechanism, retransmission packets that are delayed during short-term network fluctuations or scheduling congestion can still have a chance to be successfully sent later, thus enhancing the packet loss recovery capability in weak network environments.

[0042] For example, the compensation triggering conditions may include receiving a new retransmission request from the receiving end and / or a preset compensation timer timeout.

[0043] Specifically, the preset compensation trigger condition can be met when either a new retransmission request is received from the receiver or a preset compensation timer expires. This can refer to either of these two conditions being met. In other words, as long as one of the conditions is met, a new round of retransmission attempts can be initiated.

[0044] In other words, the two triggering conditions mentioned above can be enabled simultaneously, using an "OR" logic relationship to jointly control the timing of compensation retransmission. This dual-triggering-condition design ensures the timeliness of compensation retransmission, avoids the additional overhead that may result from relying solely on timers, and prevents the compensation task from being permanently shelved due to the lack of new retransmission requests from the receiving end.

[0045] Regarding the first triggering condition mentioned above, when the sending end subsequently receives any new retransmission request from the same receiving end, it actively scans and reads the data packets to be retransmitted that have not yet expired and were previously unsuccessfully sent from the compensation buffer queue. These compensated retransmission data packets are then included in the sending scheduler along with the currently requested retransmission data packets, and retransmission is retried. This triggering method utilizes the subsequent retransmission requests naturally sent by the receiving end as a wake-up signal, asynchronously driving the execution of compensation retransmission without requiring additional control messages.

[0046] For the second triggering condition mentioned above, a separate compensation timer is configured. The timeout period of this timer can be dynamically configured according to the actual application scenario, such as based on Round-Trip Time (RTT), packet loss rate, media type, or service priority. Whenever the timer expires, a compensation retransmission scan is actively triggered, reading data packets that have not yet expired from the compensation buffer queue and re-initiating a retransmission attempt. This triggering method ensures that even if the receiving end does not send new retransmission requests for a long time, the retransmission requests accumulated in the compensation buffer queue can still be retried in a timely manner, instead of waiting indefinitely.

[0047] For example, the compensation triggering conditions may also include detecting that the network conditions meet preset packet loss retransmission triggering conditions. For instance, when the packet loss rate exceeds a preset threshold, or the round-trip time jitter exceeds a preset range, or the estimated available bandwidth is lower than a preset threshold, it indicates that the current network conditions have deteriorated. Even if no new retransmission request is received from the receiver and the compensation timer has not expired, the sender can actively read data packets that have not exceeded the preset validity period from the compensation buffer queue and re-initiate retransmission.

[0048] The aforementioned mechanism for filtering retransmission requests through FEC recoverability simulation assessment can effectively reduce redundant retransmissions. However, due to network feedback delays, packet loss, or out-of-order delivery, the receiver status data maintained by the sender may deviate from the actual situation. This could lead to some data packets that are not recoverable through FEC being incorrectly judged as recoverable and thus not retransmitted, ultimately affecting the media recovery quality at the receiver. Therefore, this specification further introduces a fallback mechanism to address potential misjudgments in the FEC recoverability assessment.

[0049] In practice, after performing a recoverability simulation evaluation on the data packet indicated by the retransmission request, the data packets that are determined to be recoverable at the receiving end through forward error correction in the result of the recoverability simulation evaluation are marked; if a retransmission request for the marked data packet is received again within a preset time window, the marked data packet is identified as a data packet to be retransmitted, and a retransmission operation is performed.

[0050] Specifically, after the sender performs the aforementioned FEC recoverability simulation assessment, for data packets determined to be recoverable locally at the receiver via FEC, the sender does not immediately discard the relevant information but marks them and records the marking time. Although these data packets are filtered out in the current retransmission request, the sender still places them within an observation window. Subsequently, the sender continuously monitors subsequent retransmission requests from the same receiver. If, within a preset time window (e.g., a duration set as a multiple of the round-trip time, or a fixed timeout threshold), the sender receives another retransmission request for a marked data packet, it indicates that the previous recovery determination for that data packet may have been incorrect. Based on this determination, the sender removes the data packet from the recoverable state, reclassifies it as a data packet to be retransmitted, and performs the actual retransmission operation.

[0051] Furthermore, when the frequency of fallback retransmissions is high, the sender can adjust its FEC filtering strategy accordingly. For example, it can count the number of data packets forcibly retransmitted due to the fallback mechanism within a unit of time. If this number exceeds a preset threshold, it indicates that the receiver state model maintained by the sender deviates significantly from the actual situation. In this case, the sender can proactively reduce the aggressiveness of FEC filtering, making it more conservative. For instance, the aggressiveness of filtering can be adjusted based on the certainty of the receiver's state feedback. In conservative mode, only when the sender can clearly confirm that the receiver has received sufficient redundant information for recovery (e.g., receiving feedback from the receiver clearly confirming the arrival of a redundant packet, such as a definite confirmation from Transport-CC) is the packet considered recoverable and filtered; otherwise, even if recovery is theoretically possible, it is considered unrecoverable and retransmission is performed (no definite feedback has been received, such as only determining that a redundant packet has been received based on time estimation). The sender can also choose to narrow the scope of FEC filtering, for example, enabling filtering only for high-redundancy protection groups with multiple redundant packets, while temporarily disabling filtering for single-redundancy protection groups and directly performing retransmission. In addition, the sending end can implement exemption policies for specific types of data packets. For example, for key frame data packets or data packets that are sensitive to their position in the group, regardless of the FEC simulation evaluation results, they can be directly regarded as unrecoverable and retransmitted to ensure the transmission reliability of extremely important data packets.

[0052] Through the aforementioned fallback mechanism, this manual can effectively address filtering misjudgments caused by feedback delays, packet loss, or state prediction errors without affecting the bandwidth-saving effect in normal scenarios. It ensures that even in extreme cases or when the maintained receiver state data is inaccurate, critical data packets can still be delivered to the receiver through retransmission, thereby enhancing fault tolerance and overall reliability.

[0053] Furthermore, the aforementioned forced retransmission fallback mechanism for filtering failures can be implemented in conjunction with the aforementioned retransmission compensation mechanism. The retransmission compensation mechanism ensures that data packets already in the retransmission queue can still be retransmitted when bandwidth scheduling is limited, while the fallback mechanism can correct data packets that were not included in the retransmission queue due to misjudgment in FEC recoverability assessment. Both provide redundancy protection for the retransmission process from different dimensions, which not only does not affect the bandwidth saving effect in normal scenarios, but also ensures the final reliable delivery of data packets in abnormal scenarios, effectively improving the transmission robustness in weak network environments.

[0054] The following describes the improved solution for the receiving end. As mentioned earlier, after detecting a sequence number gap, the receiving end typically uses a fixed waiting time to distinguish between out-of-order packets and actual packet loss, and initiates a retransmission request after the timeout. However, in network environments with severe out-of-order issues, a fixed short waiting time will misjudge a large number of packets that could arrive late as lost, triggering unnecessary retransmission requests and wasting uplink bandwidth; while in environments with minor out-of-order issues or stable networks, a fixed long waiting time will unnecessarily delay the actual packet loss recovery process, increasing end-to-end latency. Therefore, this packet loss judgment strategy with a fixed waiting time is difficult to adapt to dynamically changing network conditions. To address this, this specification further proposes a data transmission method that dynamically adjusts the waiting time for packet loss judgment at the receiving end according to the real-time network out-of-order status, reducing the generation of invalid retransmission requests from the source while ensuring the timeliness of packet loss recovery. The method will be described in detail below with specific embodiments.

[0055] Figure 2 A flowchart illustrating a data transmission method provided in another exemplary embodiment of this specification is shown. This method is applied at a receiving end, such as... Figure 2 As shown, the method includes: S201: Obtain data transmission status information.

[0056] Here, the receiving end obtains data transmission status information related to data packet reception by monitoring the ongoing media transmission process in real time.

[0057] The aforementioned data transmission status information may include, but is not limited to: the sequence number of currently received data packets, the arrival interval between adjacent data packets, the actual arrival time, the arrival order of data packets, and out-of-order events that occurred within a historical time window. The receiving end can maintain a receive buffer. Whenever a new RTP data packet is received, its sequence number can be extracted and compared with the sequence numbers of previously received data packets to identify whether there are any discontinuous sequence numbers.

[0058] S202: Based on the data transmission status information, determine out-of-order feature information to characterize the current degree of out-of-order reception.

[0059] In practice, after obtaining the data transmission status information, the receiving end can process and refine the raw data to generate disorder feature information that can quantitatively describe the degree of disorder in the current network.

[0060] The out-of-order characteristic information can include any one or a combination of various statistical indicators. For example, the receiver can count the proportion of data packets arriving in a different order than in the original sending order within a preset time window, out of the total number of received packets within that window; this is the out-of-order ratio. Another example is that the receiver can count the degree of deviation of out-of-order data packets relative to their original order, such as calculating the average or variance of the sequence number offset of all out-of-order packets. Furthermore, severe out-of-order situations are often accompanied by drastic fluctuations in arrival intervals; therefore, the receiver can also count the distribution of arrival intervals between adjacent packets.

[0061] The out-of-order feature information calculated in the above manner can reflect the true out-of-order status of the current network path in a relatively objective and accurate way.

[0062] In one implementation, the data transmission status information may include the sequence number, actual arrival time, and arrival order of each data packet received by the receiving end; the out-of-order characteristic information may include the out-of-order ratio and out-of-order delay distribution characteristics; based on this, out-of-order characteristic information for characterizing the current degree of out-of-order reception can be determined according to the following steps: Within a preset statistical window, the ratio of the number of data packets whose arrival order does not match the sequence number order to the total number of received data packets is used to obtain the out-of-order ratio. Based on the difference between the actual arrival time of the out-of-order data packets within the preset statistical window and the expected arrival time corresponding to their sequence number order, the out-of-order delay distribution characteristics are determined.

[0063] Here, the data transmission status information includes the sequence number, actual arrival time, and arrival order of each data packet received by the receiving end. The sequence number is the original number of the data packet when it is sent by the sending end, reflecting the original sending order the data packets should have followed; the actual arrival time is the local timestamp when the receiving end receives the data packet; and the arrival order reflects the actual order in which the data packets are received by the receiving end. By comparing the sequence number order and arrival order of the same group of data packets, it can be determined whether out-of-order delivery has occurred in the network.

[0064] Based on the aforementioned data transmission status information, the receiving end uses two dimensions—out-of-order ratio and out-of-order delay distribution characteristics—to quantify the degree of out-of-order behavior in the current network.

[0065] To determine the out-of-order ratio, the receiving end counts the number of data packets whose arrival order does not match the sequence number order within a preset statistical window (e.g., the time window corresponding to the 100 most recently received data packets, or the time window corresponding to data packets received within the last 100 milliseconds). This number is then divided by the total number of data packets received within the window; the resulting ratio is the out-of-order ratio. A higher out-of-order ratio indicates a higher frequency of out-of-order events in the network, and a more prevalent deviation of data packets from their original order.

[0066] Out-of-order delay distribution characteristics reflect the degree of delay deviation of out-of-order data packets. For each out-of-order data packet, the difference between its actual arrival time and its expected arrival time according to its sequence number is calculated. This expected arrival time can be estimated based on the average arrival interval of adjacent data packets or historical arrival patterns. For example, assuming that data packets arrive sequentially according to their sequence numbers under normal circumstances, the expected arrival time of packet N can be estimated by adding the average arrival interval to the actual arrival time of packet N-1. When the actual arrival time of a data packet is significantly later than its expected arrival time, the difference between the actual arrival time and the expected arrival time is the out-of-order delay. The receiving end collects the above differences of all out-of-order data packets within a statistical window, forming a set of delay values. The distribution characteristics of this set (e.g., the mean, variance, median, percentile, or maximum value of the delay) are the out-of-order delay distribution characteristics. This characteristic reflects the severity of the late arrival of out-of-order data packets. For example, the greater the out-of-order delay, the more severely the data packets are affected by network path differences or queuing, requiring a longer waiting time to complete reordering.

[0067] Using the methods described above, the receiving end can not only determine the frequency of out-of-order packets in the network (out-of-order ratio) but also grasp the degree of packet delay caused by out-of-order packets (out-of-order delay distribution characteristics). Combining these two aspects allows for a more comprehensive and accurate description of the current out-of-order situation, providing a more refined basis for subsequent dynamic adjustments to the adaptive waiting time. For example, when the out-of-order ratio is high and the out-of-order delay distribution characteristics indicate significant delay, the adaptive waiting time can be significantly increased; conversely, when the out-of-order ratio is high but the out-of-order delay is generally low, only a moderate increase in the waiting time is necessary.

[0068] S203: Adjust the current adaptive waiting time according to the out-of-order feature information; the adaptive waiting time is the waiting time for determining data packet loss.

[0069] Here, if the packet loss detection mechanism uses a fixed waiting time: after detecting a sequence number gap, it waits for a fixed period of time (e.g., 50 milliseconds). If the missing packet still hasn't arrived after this time, it is considered lost and a retransmission request is sent. However, in network environments with severe out-of-order issues, data packets may arrive late due to traversing different routing paths. A shorter fixed waiting time would cause a large number of data packets that could have arrived later to be mistakenly judged as lost, thus triggering unnecessary retransmission requests and wasting bandwidth. On the other hand, in network environments with mild out-of-order issues, an excessively long fixed waiting time would unnecessarily delay the actual packet loss recovery process.

[0070] Based on this, this specification employs an adaptive waiting time adjustment mechanism. Specifically, the receiving end dynamically calculates or adjusts the current waiting time used to determine packet loss based on the out-of-order characteristic information determined in S202. For example, when the out-of-order characteristic information shows that the current network out-of-order ratio is high or has increased compared to the last adjustment of the adaptive waiting time, or the out-of-order deviation is large or has increased compared to the last adjustment of the adaptive waiting time, the receiving end actively increases the adaptive waiting time, giving late-arriving packets a longer buffer time to reduce the probability of misjudging them as packet loss. Conversely, when the out-of-order characteristic information shows that the network is relatively stable, the out-of-order ratio is low or has decreased compared to the last adjustment of the adaptive waiting time, or the out-of-order deviation is small or has decreased compared to the last adjustment of the adaptive waiting time, the receiving end actively shortens the adaptive waiting time, thereby enabling faster detection of actual packet loss and triggering retransmission, reducing recovery delay.

[0071] In one implementation, the current adaptive waiting time can be adjusted according to the following steps: determining the adjustment direction of the adaptive waiting time based on the out-of-order ratio in the out-of-order feature information, wherein the adjustment direction indicates increasing or decreasing the adaptive waiting time; and determining the adjustment magnitude of the adaptive waiting time based on the out-of-order delay distribution characteristics in the out-of-order feature information; and adjusting the current adaptive waiting time according to the adjustment direction and the adjustment magnitude to obtain the adjusted adaptive waiting time.

[0072] In practice, the receiving end can determine the direction of adjusting the adaptive waiting time based on the out-of-order ratio. The out-of-order ratio reflects the frequency of out-of-order events in the network, that is, the proportion of data packets whose arrival order does not match the sequence number order. When the out-of-order ratio is high, it indicates that out-of-order phenomena are more common in the network. In this case, the receiving end can increase the adaptive waiting time, giving late-arriving data packets a longer buffer time to avoid misjudging data packets that are delayed due to out-of-order arrival as lost. Conversely, when the out-of-order ratio is low, it indicates that out-of-order phenomena are less common in the network, and most data packets arrive in their original order. In this case, the receiving end can reduce the adaptive waiting time, thereby detecting packet loss more quickly and triggering retransmission in a timely manner, reducing recovery latency.

[0073] The out-of-order delay distribution characteristic reflects the degree to which the actual arrival time of out-of-order data packets deviates from their expected arrival time. This characteristic can be expressed as statistical quantities such as the mean, variance, maximum value, or a certain percentile (the delay value at a certain percentage position) of the out-of-order delay. When the out-of-order delay distribution characteristic shows a large delay, it means that the out-of-order data packets arrive late for a long time. A more lenient waiting window can be given to effectively accommodate these delayed packets, so the adjustment range can be increased accordingly, that is, the original waiting time can be significantly increased. Conversely, when the out-of-order delay distribution characteristic shows a small delay, even if out-of-order packets exist, they only deviate from the original order for a very short time. In this case, only a small increase in the waiting time is needed, without excessive adjustment. Accordingly, in scenarios that reduce waiting time, the out-of-order delay distribution characteristic can also be used to control the magnitude of the reduction. For example, when the out-of-order delay is generally small, the waiting time can be reduced more significantly; when the out-of-order delay fluctuates to a certain extent, it can be reduced more conservatively to retain a certain fault tolerance margin.

[0074] Finally, the receiving end combines the adjustment direction and adjustment magnitude determined in the above steps to actually adjust the current adaptive waiting time, obtaining the new adjusted waiting time. For example, if the current adaptive waiting time is T, the out-of-order ratio indicator needs to be increased, and the adjustment magnitude of the out-of-order delay distribution characteristic indicator is ΔT1 (positive value), then the adjusted waiting time is T+ΔT1; conversely, if the out-of-order ratio indicator needs to be decreased, and the adjustment magnitude is ΔT2, then the adjusted waiting time is T-ΔT2. In addition, a lower limit value can be set to avoid frequent misjudgments caused by an excessively short waiting time.

[0075] In this way, the receiving end can finely adjust the adaptive waiting time according to the out-of-order characteristics, which ensures that delayed packets can be fully accommodated when the out-of-order situation is severe, while avoiding unnecessary recovery delays caused by excessively increasing the waiting time when the out-of-order situation is mild.

[0076] S204: Data packets that have not arrived after the adaptive waiting time are identified as lost data packets, and a retransmission request is sent to the sending end based on the identified lost data packets.

[0077] After determining the current adaptive waiting time, the receiver applies it to the packet loss determination process. Specifically, when the receiver detects a sequence number gap (i.e., a expected data packet has not yet arrived), it does not immediately classify it as lost. Instead, it starts a timer, the timeout of which is the adaptive waiting time determined in S203. During the timer's operation, the receiver continues to wait for the data packet to arrive. If the data packet arrives successfully within the adaptive waiting time, it is determined to be a delayed arrival caused by network out-of-order delivery, and no packet loss is processed. Conversely, if the data packet still has not arrived after the timer expires, the receiver formally classifies it as a lost data packet. For data packets identified as lost, the receiver generates a corresponding retransmission request and sends it to the sender to request the sender to retransmit the lost data packet.

[0078] Through the steps S201 to S204 described above, the receiving end can adaptively adjust the waiting time for packet loss determination according to the real-time network out-of-order status, thereby achieving a dynamic balance between avoiding misjudging packet loss due to out-of-order delivery and quickly detecting and recovering real packet loss, reducing the generation of invalid retransmission requests from the source and improving overall transmission efficiency.

[0079] In one implementation, determining a data packet that has not arrived after the adaptive waiting time as a lost data packet may include: detecting missing sequence numbers in the sequence numbers of data packets received by the receiving end based on the data transmission status information; calculating the waiting time from the first detection of the missing sequence number to the current time for each data packet corresponding to the missing sequence number; and determining the data packet corresponding to the missing sequence number whose waiting time exceeds the adaptive waiting time as a lost data packet.

[0080] For example, the receiving end first identifies the currently missing sequence number by detecting the continuity of the data packet sequence numbers. For each data packet corresponding to a missing sequence number, the receiving end records the moment when its absence is first detected and continuously calculates the waiting time from that moment to the current moment. This waiting time is compared with the aforementioned adaptive waiting time. If the waiting time has not exceeded the adaptive waiting time, the receiving end continues to wait; if the waiting time has exceeded the adaptive waiting time, the data packet is determined to be a lost data packet.

[0081] The above implementation maintains an independent waiting timer for each missing packet. The receiver records the moment each missing sequence number is first detected, i.e., the moment the receiver first discovers a gap in the corresponding sequence number. Then, at each current moment, for each missing packet corresponding to a missing sequence number, the time difference between the moment the missing packet was first detected and the current moment is calculated to determine the waiting time for each missing packet. By keeping an independent timer for each missing packet, each packet has its own independent waiting deadline, thereby achieving fine-grained control over the packet loss determination for each data packet.

[0082] In other implementations, different packet loss determination strategies can be adopted. For example, a unified waiting timer can be started when the first sequence number hole is detected. When the timer expires, all missing data packets that have not yet arrived can be determined as lost packets. Alternatively, the number or proportion of missing data packets can be counted within a sliding time window. When the degree of loss exceeds a preset threshold, packet loss determination is triggered in batches, thus balancing the accuracy and timeliness of the determination. Another option is to perform overall packet loss determination on a per-frame or FEC group basis. When the number of missing packets in a group exceeds the FEC recovery capacity, a retransmission request is triggered uniformly. These various determination methods can be flexibly selected according to different requirements for implementation complexity, determination accuracy, and recovery latency in actual application scenarios.

[0083] In real-time media transmission, retransmission requests from the receiving end need to be transmitted through the uplink network to reach the sending end. In weak network environments, packet loss may occur in the uplink, causing the retransmission request from the receiving end to fail to be received by the sending end. Consequently, the sending end cannot know about the packet loss situation at the receiving end, ultimately resulting in the inability to recover from packet loss in a timely manner. To further improve the reliability of retransmission request transmission, a NACK redundant transmission strategy based on packet loss rate and round-trip time (RTT) is introduced. Under this redundant transmission strategy, the probability of a single retransmission request successfully reaching the sending end in the uplink is calculated based on the current packet loss rate and RTT, obtaining a single success probability. Based on the single success probability and a preset target arrival rate, the minimum number of transmissions required to meet the preset target arrival rate is calculated, and the redundant transmission count of the retransmission request is determined based on the minimum number of transmissions. The retransmission request is then sent to the sending end based on the redundant transmission count.

[0084] This implementation provides a redundant transmission mechanism for retransmission requests to improve the reliable arrival probability of retransmission requests (NACK messages) in the uplink.

[0085] Specifically, when the receiving end determines that a data packet has been lost and prepares to send a retransmission request to the sending end, it first estimates the probability that a single retransmission request will successfully reach the sending end based on the currently measured packet loss rate and round-trip time (RTT), i.e., the single-success probability. The packet loss rate reflects the severity of packet loss in the uplink, while the RTT reflects the latency characteristics of the link; both together determine the likelihood that the retransmission request will be successfully received by the sending end. For example, in an environment with a high uplink packet loss rate, the probability that the retransmission request will be discarded is correspondingly higher, and the single-success probability is lower.

[0086] Secondly, the receiver presets a target arrival rate, which represents the probability level at which retransmission requests are successfully delivered to the sender, for example, a target arrival rate of 99%. Based on the calculated single-transmission success probability and the preset target arrival rate, the receiver calculates how many repeated retransmission requests need to be sent to ensure that the probability of at least one successful request reaching the sender reaches or exceeds the target arrival rate. The minimum number of transmissions calculated is the redundancy transmission count. For example, if the single-transmission success probability is 70%, then according to the probability formula, sending two repeated retransmission requests will achieve a 91% probability of at least one successful delivery, and sending three will achieve 97.3%. The receiver selects the appropriate number of redundancy transmissions based on the target arrival rate requirement. The probability formula is as follows: . Let n be the probability of a single successful transmission, n be the number of retransmissions, and P be the probability of at least one successful arrival.

[0087] Finally, the receiving end sends a retransmission request to the sending end according to the calculated number of redundant transmissions. Through this redundant transmission strategy, the receiving end can significantly improve the reliable arrival rate of retransmission requests in high packet loss environments, thereby improving the overall success rate of packet loss recovery. Furthermore, since the number of redundant transmissions in this specification is dynamically calculated based on the current network status, it will not cause unnecessary uplink bandwidth waste in low packet loss environments, achieving a dynamic balance between reliability and efficiency.

[0088] In some embodiments, before sending a retransmission request to the sender, the receiver may perform a local FEC recoverability assessment to further reduce unnecessary retransmission requests. For example, the receiver may perform a forward error correction recoverability assessment on the lost data packets based on the data transmission status information and the forward error correction grouping information sent by the sender; determine the minimum set of retransmission data packets based on the result of the forward error correction recoverability assessment; and initiate a retransmission request to the sender based on the minimum set of retransmission data packets.

[0089] This implementation provides a local FEC recoverability assessment mechanism at the receiving end before sending a retransmission request, used to filter out lost packets that can be recovered by FEC on their own at the source.

[0090] For example, after identifying a lost data packet and before sending a retransmission request to the sender, the receiving end first obtains the forward error correction (FEC) grouping information provided by the sender via out-of-band signaling or a dedicated control message. This information describes the grouping structure used by the sender for FEC protection of the original media packets, including the original media packet information contained in each FEC protection group, the corresponding FEC redundancy packet information, and the encoding rules used. Next, the receiving end, combining its existing data transmission status information—that is, the actual situation of the locally received original media packets and FEC redundancy packets—performs an FEC recoverability assessment for each lost data packet, determining whether a lost media packet can be recovered using the FEC redundancy packets based on the currently received data packets. Then, based on the assessment results, the receiving end removes data packets determined to be recoverable locally via FEC from the original lost data packet list, retaining only those data packets that cannot be recovered via FEC, forming a minimum retransmission data packet set. Finally, the receiving end generates and sends a retransmission request only for this minimum retransmission data packet set to the sender.

[0091] By performing a local FEC recoverability assessment at the receiver, unnecessary retransmission requests can be significantly reduced, uplink bandwidth consumption can be lowered, and the burden on the sender to handle invalid retransmission requests can be alleviated.

[0092] In the above implementation of the receiver-side local FEC recoverability assessment, when the receiver detects a missing data packet, it first evaluates it based on the original data packets and redundant packets already received within the same FEC group. If the currently received packets are sufficient to recover the missing data packet through FEC decoding, the receiver directly performs local FEC decoding to complete the recovery without initiating a retransmission request to the sender. If the currently received packets are insufficient to recover the missing data packet, but the redundant packets of the FEC group have not yet fully arrived (for example, the redundant packet transmission window corresponding to the group has not yet closed), the receiver does not make a final determination temporarily, but instead starts an FEC recovery waiting timer to continue receiving subsequent potentially arriving redundant packets or other original data packets. The timeout duration of this timer can be dynamically configured according to the current adaptive waiting duration or the time span of the FEC group.

[0093] If the number of packets received by the receiver reaches the FEC decoding threshold before the timer expires, the packet is recovered; if the decoding threshold is not reached after the timer expires, the packet is determined to be unrecoverable through FEC and included in subsequent retransmission requests.

[0094] In one implementation, the recoverability assessment of the lost data packets can be performed as follows: based on the forward error correction grouping information, determine the forward error correction group to which each lost data packet belongs and the data packet information in that forward error correction group; based on the data packet reception status and forward error correction redundancy packet reception status in the data transmission status information, determine the data packets and redundancy packets that have arrived at the receiving end in each forward error correction group; based on the data packets and redundancy packets that have arrived at the receiving end in the forward error correction group, and the data packet information in the forward error correction group, determine whether the lost data packets in the forward error correction group can be recovered locally through forward error correction, and obtain the recoverability assessment result.

[0095] For example, after receiving the forward error correction (FEC) grouping information from the sender, the receiver uses this information to locate the FEC protection group to which each lost data packet belongs, and obtains all data packet information within that group, including the original data packets (media packets) contained in the group, the corresponding generated FEC redundancy packets, and the encoding dependencies between these packets (e.g., XOR encoding rules or RS encoding parameters). Next, for each lost packet's FEC group, the receiver queries its own maintained data transmission status information. This data transmission status information records the specific details of the original media packets and FEC redundancy packets actually received by the receiver. Then, based on the FEC grouping information (such as encoding rules) obtained in the first step and the data packets and redundancy packets that have arrived within the group obtained in the second step, the receiver performs a virtual FEC decoding calculation. If the calculation shows that a lost packet can be recovered using existing known packets, the lost packet is marked as recoverable via FEC; otherwise, if the calculation finds that the lost packet cannot be recovered even using all known packets, it is marked as unrecoverable via FEC. For example, in a protection group consisting of four original media packets and one XOR FEC redundancy packet, if the receiver finds that only one original media packet is lost, while the other three original media packets and the FEC redundancy packet have been received, it is determined that the lost packet can be recovered locally through FEC; if two or more original media packets are lost, it is determined that recovery is not possible.

[0096] It's important to note that the FEC recoverability assessment performed by the receiving end before initiating a retransmission request and the FEC recoverability simulation assessment performed by the sending end after receiving the retransmission request are not redundant. The receiving end's assessment is based on its state at the time it sends the retransmission request, while the sending end's assessment is based on its state at the time it receives the retransmission request. Due to network transmission delays, the receiving end may continue to receive new redundant packets or data packets after sending a retransmission request, making previously unrecoverable lost packets recoverable. The sending end can detect these newly arriving packets through feedback mechanisms such as Transport-CC, thus discovering in the simulation assessment that the receiving end has recovery capabilities, and subsequently filtering out the retransmission request to avoid invalid retransmissions. The assessments at both ends can complement each other, jointly improving retransmission efficiency.

[0097] Figure 3 A schematic diagram illustrating the overall logical interaction of a data transmission method provided in an exemplary embodiment of this specification is shown below. Figure 3 This section explains the interaction process between the sending and receiving ends, as well as their respective internal processing logic.

[0098] like Figure 3 As shown, during the normal data transmission phase, the sending end sends raw RTP data packets and accompanying FEC redundancy packets to the receiving end. The receiving end continuously receives these data packets and obtains data transmission status information, including the sequence number, actual arrival time, and arrival order of each data packet.

[0099] Following this, the receiving end performs internal processing and packet loss determination. Based on the acquired data transmission status information, the receiving end statistically analyzes the out-of-order ratio and out-of-order delay distribution characteristics within a preset time window. The out-of-order ratio reflects the frequency of out-of-order occurrences in the network, while the out-of-order delay distribution characteristics reflect the severity of late arrival of out-of-order packets. The receiving end determines the adjustment direction (increase or decrease) of the adaptive waiting time based on the out-of-order ratio and the adjustment magnitude based on the out-of-order delay distribution characteristics, thereby dynamically adjusting the current adaptive waiting time used to determine packet loss. For each detected missing sequence number, the receiving end records the time of its first detection and calculates the waiting time, identifying packets with waiting times exceeding the adaptive waiting time as lost packets. Based on this, the receiving end performs a local FEC recoverability assessment, determining whether lost packets can be recovered locally through FEC based on the FEC grouping information provided by the sending end and the locally received packet status, thus determining the minimum set of retransmission packets. Simultaneously, the receiving end executes a NACK redundant transmission strategy, calculating the single-pass success probability based on the current packet loss rate and round-trip time (RTT), and determining the number of redundant transmissions for retransmission requests based on a preset target arrival rate.

[0100] Afterwards, the receiving end generates a retransmission request based on the above processing results and sends it to the sending end. The retransmission request indicates the sequence number of the data packet that needs to be retransmitted by the sending end.

[0101] Next, the sending end performs internal processing and retransmission decisions. After receiving the retransmission request from the receiving end, the sending end performs an FEC recoverability simulation assessment. Specifically, the sending end determines the FEC group to which each requested retransmission data packet belongs based on its recorded FEC grouping information, and combines this with feedback information such as the receiving end's data packet reception status table (which is maintained based on Transport-CC and used to infer the data packets and redundant packets already received by the receiving end) to simulate the FEC decoding process. For data packets that the simulation determines can be recovered locally at the receiving end through FEC, the sending end filters them and does not include them in the retransmission; only data packets that are determined not to be recovered through FEC are identified as data packets to be retransmitted, i.e., the minimum retransmission set.

[0102] Subsequently, the sending end determines schedulable data packets from the minimum retransmission set based on the current available bandwidth and the status of the sending scheduling queue, and performs actual retransmission. Data packets that fail to be sent due to insufficient bandwidth or queue congestion are written to the compensation buffer queue. When the preset compensation trigger condition is met (such as receiving a new NACK or the compensation timer expires), data packets that have not exceeded their validity period are read from the compensation buffer queue, and retransmission is re-initiated. In addition, the sending end also implements a fallback mechanism: data packets determined to be recoverable in the FEC simulation evaluation are marked; if a retransmission request for the same data packet is received again within a preset time window, the data packet is re-identified as a data packet to be retransmitted and forced to be retransmitted.

[0103] Finally, the sending end returns a retransmission data packet to the receiving end. The sending end sends the actual retransmission data packet to the receiving end. Upon receiving the retransmission packet, the receiving end, in conjunction with any FEC redundancy packets it may have received, completes the packet loss recovery.

[0104] Through the above interaction process, the receiving end reduces invalid retransmission requests from the source by adaptive waiting time and local FEC filtering, while the sending end performs secondary filtering through FEC simulation evaluation and ensures retransmission reliability through compensation mechanisms and fallback strategies. The two work together to significantly reduce retransmission bandwidth waste, shorten packet loss recovery delay, and improve the quality of real-time media transmission in weak network environments.

[0105] Figure 4 This is a schematic diagram of the structure of a device 400 provided in an exemplary embodiment. For example... Figure 4As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0106] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by an indicator or cursor described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0107] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0108] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0109] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0110] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0111] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0112] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0113] Please refer to Figure 5 The data transmission device 500 can be applied to the transmitting end of a data transmission system to implement the technical solution of this specification. The data transmission device 500 at the transmitting end may include: The acquisition module 51 is used to acquire retransmission requests from the receiving end; the retransmission request is used to indicate data packets that are determined to be lost at the receiving end. The recoverability simulation evaluation module 52 is used to perform a recoverability simulation evaluation on the data packets indicated by the retransmission request; the recoverability simulation evaluation is used to determine whether at least a portion of the data packets indicated by the retransmission request can be locally recovered at the receiving end through forward error correction. The retransmission module 53 is used to identify data packets that are determined to be unrecoverable through forward error correction as data packets to be retransmitted based on the results of the recoverability simulation evaluation, and to perform a retransmission operation on the data packets to be retransmitted.

[0114] In one implementation, the recoverability simulation evaluation module 52 performs a recoverability simulation evaluation on the data packets indicated by the retransmission request, including: determining the forward error correction group to which each data packet indicated by the retransmission request belongs and the data packet information in the forward error correction group based on the forward error correction grouping information recorded by the sending end; determining the data packets and redundant packets that have arrived at the receiving end in each forward error correction group based on the data packet reception status and forward error correction redundancy packet reception status of the receiving end; and determining whether the lost data packets in the forward error correction group can be recovered locally at the receiving end through forward error correction based on the data packets and redundant packets that have arrived at the receiving end in the forward error correction group and the data packet information in the forward error correction group, thereby obtaining the result of the recoverability simulation evaluation.

[0115] In one embodiment, the retransmission module 53 performs a retransmission operation on the data packet to be retransmitted, including: determining at least one schedulable data packet from the data packet to be retransmitted based on the current available bandwidth and the state of the sending scheduling queue, and performing actual retransmission; writing data packets from the data packet to be retransmitted that were not actually sent in the current scheduling into a compensation buffer queue; and when a preset compensation trigger condition is met, reading data packets that have not exceeded a preset validity period from the compensation buffer queue and re-initiating retransmission.

[0116] In one implementation, when a preset compensation trigger condition is met, the retransmission module 53 reads data packets that have not exceeded a preset validity period from the compensation buffer queue and re-initiates retransmission, including: when any one of the following preset compensation trigger conditions is met, reading data packets that have not exceeded a preset validity period from the compensation buffer queue and re-initiating retransmission: receiving a new retransmission request from the receiving end; or a preset compensation timer expires.

[0117] In one embodiment, after the recoverability simulation evaluation module 52 performs a recoverability simulation evaluation on the data packet indicated by the retransmission request, the retransmission module 53 further includes: marking the data packets that are determined to be recoverable at the receiving end through forward error correction in the result of the recoverability simulation evaluation; if a retransmission request for the marked data packet is received again within a preset time window, the marked data packet is identified as a data packet to be retransmitted, and a retransmission operation is performed.

[0118] Please refer to Figure 6The data transmission device 600 can be applied to the receiving end of a data transmission system to implement the technical solution of this specification. The data transmission device 600 at the receiving end may include: Module 61 is used to acquire data transmission status information; The determining module 62 is used to determine, based on the data transmission status information, out-of-order feature information that characterizes the current degree of out-of-order reception; The adjustment module 63 is used to adjust the current adaptive waiting time according to the out-of-order feature information; the adaptive waiting time is the waiting time for determining data packet loss. The retransmission request sending module 64 is used to determine that data packets that have not arrived after the adaptive waiting time are lost data packets, and send a retransmission request to the sending end based on the determined lost data packets.

[0119] In one embodiment, the data transmission status information includes the sequence number, actual arrival time, and arrival order of each data packet received by the receiving end; the out-of-order characteristic information includes the out-of-order ratio and out-of-order delay distribution characteristics. The determining module 62 determines out-of-order feature information to characterize the current degree of out-of-order reception based on the data transmission status information, including: calculating the ratio of the number of data packets whose arrival order is inconsistent with the sequence number order to the total number of received data packets within a preset statistical window to obtain the out-of-order ratio; and determining the out-of-order delay distribution feature based on the difference between the actual arrival time of the out-of-order data packets within the preset statistical window and the expected arrival time corresponding to their sequence number order.

[0120] In one implementation, the adjustment module 63 adjusts the current adaptive waiting time based on the out-of-order feature information, including: determining the adjustment direction of the adaptive waiting time based on the out-of-order ratio in the out-of-order feature information, wherein the adjustment direction indicates increasing or decreasing the adaptive waiting time; and determining the adjustment magnitude of the adaptive waiting time based on the out-of-order delay distribution characteristics in the out-of-order feature information; and adjusting the current adaptive waiting time based on the adjustment direction and the adjustment magnitude to obtain the adjusted adaptive waiting time.

[0121] In one implementation, the retransmission request sending module 64 determines data packets that have not arrived after the adaptive waiting time as lost data packets, including: detecting missing sequence numbers in the sequence numbers of data packets received by the receiving end according to the data transmission status information; calculating the waiting time from the first detection of the missing sequence number to the current time for each data packet corresponding to the missing sequence number; and determining the data packets corresponding to the missing sequence numbers whose waiting time exceeds the adaptive waiting time as lost data packets.

[0122] In one implementation, the retransmission request sending module 64 sends a retransmission request to the sending end based on the determined lost data packet, including: calculating the probability that a single retransmission request will successfully reach the sending end on the uplink based on the current packet loss rate and round-trip time (RTT), and obtaining a single success probability; calculating the minimum number of transmissions required to meet the preset target arrival rate based on the single success probability and the preset target arrival rate, determining the redundant transmission count of the retransmission request based on the minimum number of transmissions; and sending the retransmission request to the sending end based on the redundant transmission count.

[0123] In one implementation, the retransmission request sending module 64 sends a retransmission request to the sending end based on the determined lost data packets, including: performing a forward error correction recoverability assessment on the lost data packets based on the data transmission status information and the forward error correction grouping information sent by the sending end; determining a minimum set of retransmission data packets based on the result of the forward error correction recoverability assessment; and initiating a retransmission request to the sending end based on the minimum set of retransmission data packets.

[0124] In one implementation, the retransmission request sending module 64 performs a forward error correction recoverability assessment on the lost data packets based on the data transmission status information and the forward error correction grouping information sent by the sending end. This includes: determining, based on the forward error correction grouping information, the forward error correction grouping to which each lost data packet belongs and the data packet information within that group; determining, based on the data packet reception status and forward error correction redundancy packet reception status in the data transmission status information, the data packets and redundancy packets that have arrived at the receiving end in each forward error correction group; and determining, based on the data packets and redundancy packets that have arrived at the receiving end in the forward error correction group, and the data packet information within the forward error correction group, whether the lost data packets in the forward error correction group can be recovered locally through forward error correction, thereby obtaining a recoverability assessment result.

[0125] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0126] This specification also provides a data transmission system, which includes the aforementioned sending end and receiving end. The sending end can execute the data transmission method executed by the sending end as described in any of the foregoing embodiments, and the receiving end can execute the data transmission method executed by the receiving end as described in any of the foregoing embodiments. The sending end and the receiving end cooperate with each other, which can significantly reduce retransmission bandwidth, shorten packet loss recovery delay, and improve the real-time media transmission quality in weak network environments.

[0127] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0128] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0129] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0130] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0131] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0132] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0133] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0134] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0135] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0136] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A data transmission method, characterized in that, Applied to the sending end, including: Obtain a retransmission request from the receiving end; the retransmission request is used to indicate data packets that are determined to be lost at the receiving end. A recoverability simulation evaluation is performed on the data packets indicated by the retransmission request; the recoverability simulation evaluation is used to determine whether at least a portion of the data packets indicated by the retransmission request can be locally recovered at the receiving end through forward error correction; Based on the results of the recoverability simulation evaluation, data packets that are determined to be unrecoverable through forward error correction are identified as data packets to be retransmitted, and a retransmission operation is performed on the data packets to be retransmitted.

2. The method according to claim 1, characterized in that, The recoveryability simulation evaluation of the data packet indicated by the retransmission request includes: Based on the forward error correction group information recorded by the sending end, determine the forward error correction group to which each data packet indicated by the retransmission request belongs and the data packet information in the forward error correction group; Based on the data packet reception status and forward error correction redundancy packet reception status of the receiving end, determine the data packets and redundancy packets that have arrived at the receiving end in each forward error correction group; Based on the data packets and redundant packets that have arrived at the receiving end in the forward error correction group, as well as the data packet information in the forward error correction group, it is determined whether the lost data packets in the forward error correction group can be recovered locally at the receiving end through forward error correction, and the result of the recoverability simulation evaluation is obtained.

3. The method according to claim 1, characterized in that, The retransmission operation for the data packet to be retransmitted includes: Based on the current available bandwidth and the status of the sending scheduling queue, at least one schedulable data packet is determined from the data packets to be retransmitted, and the actual retransmission is performed. Write the data packets that were not actually sent in this scheduling into the compensation buffer queue from the data packets to be retransmitted; When the preset compensation triggering condition is met, data packets that have not exceeded the preset validity period are read from the compensation cache queue and retransmission is initiated.

4. The method according to claim 3, characterized in that, The step of re-initiating retransmission by reading data packets that have not exceeded the preset validity period from the compensation buffer queue when the preset compensation trigger condition is met includes: If any of the following preset compensation trigger conditions are met, the data packet that has not exceeded the preset validity period is read from the compensation buffer queue and retransmission is initiated: A new retransmission request is received from the receiving end; the preset compensation timer times out.

5. The method according to any one of claims 1 to 4, characterized in that, After performing a recoverability simulation evaluation on the data packet indicated by the retransmission request, the method further includes: Data packets that are determined to be recoverable at the receiving end through forward error correction in the results of the recoverability simulation evaluation are marked; If a retransmission request for the marked data packet is received again within the preset time window, the marked data packet is identified as a data packet to be retransmitted, and a retransmission operation is performed.

6. A data transmission method, characterized in that, Applied to the receiving end, including: Obtain data transmission status information; Based on the data transmission status information, determine the out-of-order feature information used to characterize the current degree of out-of-order reception; Based on the out-of-order feature information, the current adaptive waiting time is adjusted; the adaptive waiting time is the waiting time for determining data packet loss. Data packets that have not arrived after the adaptive waiting time are identified as lost data packets, and a retransmission request is sent to the sending end based on the identified lost data packets.

7. The method according to claim 6, characterized in that, The data transmission status information includes the sequence number, actual arrival time, and arrival order of each data packet received by the receiving end; the out-of-order characteristic information includes the out-of-order ratio and out-of-order delay distribution characteristics. The step of determining the out-of-order characteristic information used to characterize the current degree of out-of-order reception based on the data transmission status information includes: Within a preset statistics window, the ratio of the number of data packets whose arrival order does not match the sequence number order to the total number of received data packets is used to obtain the out-of-order ratio. The out-of-order delay distribution characteristics are determined based on the difference between the actual arrival time of out-of-order data packets within the preset statistical window and the expected arrival time corresponding to their sequence number order.

8. The method according to claim 6, characterized in that, The step of adjusting the current adaptive waiting time based on the disordered feature information includes: Based on the out-of-order ratio in the out-of-order feature information, the adjustment direction of the adaptive waiting time is determined, and the adjustment direction indicates increasing or decreasing the adaptive waiting time; and based on the out-of-order delay distribution characteristics in the out-of-order feature information, the adjustment magnitude of the adaptive waiting time is determined. Based on the adjustment direction and the adjustment magnitude, the current adaptive waiting time is adjusted to obtain the adjusted adaptive waiting time.

9. The method according to claim 6, characterized in that, Data packets that have not arrived after the adaptive waiting time are identified as lost data packets, including: Based on the data transmission status information, detect the missing sequence number in the data packet sequence number received by the receiving end; For each data packet corresponding to a missing sequence number, calculate the waiting time from the first detection of the missing sequence number to the current time, and determine the data packets corresponding to missing sequence numbers whose waiting time exceeds the adaptive waiting time as lost data packets.

10. The method according to claim 6, characterized in that, Based on the identified lost data packets, a retransmission request is sent to the sender, including: The probability of a single retransmission request successfully reaching the sender on the uplink is calculated based on the current packet loss rate and round-trip time (RTT), thus obtaining the single success probability. Based on the single success probability and the preset target arrival rate, calculate the minimum number of transmissions required to meet the preset target arrival rate, and determine the redundant transmission count of the retransmission request based on the minimum number of transmissions. The retransmission request is sent to the sending end according to the number of redundant transmissions.

11. The method according to claim 6, characterized in that, Based on the identified lost data packets, a retransmission request is sent to the sender, including: Based on the data transmission status information and the forward error correction grouping information sent by the sender, the recoverability of the lost data packet is evaluated. Based on the results of the forward error correction recoverability assessment, determine the minimum set of retransmitted data packets; A retransmission request is initiated to the sender based on the minimum set of retransmission data packets.

12. The method according to claim 11, characterized in that, Based on the data transmission status information and the forward error correction grouping information sent by the sender, a forward error correction recoverability assessment is performed on the lost data packet, including: Based on the forward error correction grouping information, determine the forward error correction group to which each lost data packet belongs and the data packet information in that forward error correction group; Based on the data packet reception status and forward error correction redundancy packet reception status in the data transmission status information, determine the data packets and redundancy packets that have arrived at the receiving end in each forward error correction group. Based on the data packets and redundant packets that have arrived at the receiving end in the forward error correction group, as well as the data packet information in the forward error correction group, it is determined whether the lost data packets in the forward error correction group can be recovered locally through forward error correction, and a recoverability assessment result is obtained.

13. A data transmission device, characterized in that, Applied to the sending end, including: The acquisition module is used to acquire retransmission requests from the receiving end; the retransmission requests are used to indicate data packets that are determined to be lost at the receiving end. A recoverability simulation evaluation module is used to perform a recoverability simulation evaluation on the data packets indicated by the retransmission request; the recoverability simulation evaluation is used to determine whether at least a portion of the data packets indicated by the retransmission request can be locally recovered at the receiving end through forward error correction. The retransmission module is used to identify data packets that are determined to be unrecoverable through forward error correction as data packets to be retransmitted based on the results of the recoverability simulation evaluation, and to perform retransmission operations on the data packets to be retransmitted.

14. A data transmission device, characterized in that, Applied to the receiving end, including: The acquisition module is used to acquire data transmission status information; The determining module is used to determine, based on the data transmission status information, out-of-order characteristic information that characterizes the current degree of out-of-order reception; The adjustment module is used to adjust the current adaptive waiting time based on the out-of-order feature information; the adaptive waiting time is the waiting time for determining data packet loss. The retransmission request sending module is used to identify data packets that have not arrived after the adaptive waiting time as lost data packets, and to send a retransmission request to the sending end based on the identified lost data packets.

15. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as claimed in any one of claims 1-5, or the steps of the method as claimed in any one of claims 6-12, by executing the executable instructions.

16. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-5, or implement the steps of the method as described in any one of claims 6-12.

17. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the steps of the method as described in any one of claims 1-5, or implements the steps of the method as described in any one of claims 6-12.

Images