Data frame submission method and apparatus

Abstract

Provided in the present application are a data frame submission method and apparatus. The method comprises: on the basis of arrival situations, which are recorded in a block acknowledgement scoreboard, of data frames corresponding to sequence numbers, determining whether each of at least one data frame having a sequence number has arrived; and for a first data frame, the arrival situation of which, recorded in the block acknowledgement scoreboard, indicates that the first data frame has not arrived, after the first data frame having a corresponding sequence number arrives, executing a submission operation on the first data frame. The method can prevent repeated submission of a data frame. The present application supports IEEE protocols, such as an IEEE 802.11be / Wi-Fi 7 / EHT protocol, an IEEE 802.11bn / UHR / Wi-Fi 8 protocol, an IEEE 802.15 / UWB protocol, or an IEEE 802.11bf / sensing protocol.

Description

Method and device for submitting data frame Technical Field

[0001] The present application relates to the field of communications, and in particular to a method and device for delivering a data frame. Background Art

[0002] In the communications field, IEEE 802.11 wireless local area networks, also commonly known as Wireless Fidelity (Wi-Fi) networks, have become a common solution for last-hop access to the Internet. Wi-Fi technology is constantly evolving to further reduce latency and improve reliability.

[0003] However, there are still some problems that need to be solved. For example, in the 802.11 standard, when the Medium Access Control (MAC) layer delivers the Medium Access Control Protocol Data Unit (MPDU), that is, the data frame of the MAC layer, to the Logical Link Control (LLC) layer, there is a problem of duplicate delivery, which increases overhead. How to avoid the duplicate delivery of data frames has become a problem that needs to be solved.

[0004] Summary of the Invention

[0005] The present application provides a method and apparatus for delivering a data frame, which can avoid repeated delivery.

[0006] In a first aspect, the present application provides a method for data frame delivery, comprising: determining whether each data frame in at least one data frame with a sequence number has arrived based on the arrival status of the data frame corresponding to the sequence number recorded in the block confirmation scoreboard; for the first data frame whose arrival status recorded in the block confirmation scoreboard is that it has not arrived, performing a delivery operation on it after the first data frame with the corresponding sequence number arrives.

[0007] Optionally, the data frame submission method is executed by a data frame submission device, which is deployed in a receiving end, hereinafter referred to as the receiving end.

[0008] The receiving end includes a block confirmation scoreboard for recording the arrival status of each data frame. During the transmission of the data frame, each data frame sent by the sending end will carry a corresponding sequence number. After receiving the data frame, the receiving end determines the arrival status of the data frame based on the sequence number corresponding to each data frame and the corresponding block confirmation scoreboard. If a data frame currently received is the first data frame, and the arrival status of the block confirmation scoreboard corresponding to the first data frame is "not arrived", then a delivery operation can be performed on the first data frame. This method of deciding whether to perform a delivery operation based on whether the data frame has arrived can determine that the delivered data frames are all data frames that have arrived for the first time, and can effectively avoid repeated delivery.

[0009] In a possible implementation, the method further includes: for a second data frame whose arrival status is recorded in the block confirmation scoreboard as having arrived, discarding it after the second data frame with the corresponding sequence number arrives again.

[0010] If the data frame currently being received is the second data frame, and the arrival status of the block confirmation scoreboard corresponding to the second data frame is "arrived", then the second data frame can be discarded. The block confirmation frame scoreboard can record the arrival status of both data frames that have arrived at the receiving end and have been submitted, and data frames that have arrived at the receiving end and are temporarily stored at the receiving end as "arrived". By recording the arrival status of the data frames, when the second data frame is received, the block confirmation frame scoreboard can be queried according to the sequence number corresponding to the second data frame to confirm that the second data frame is an arrived data frame, and it will no longer be submitted repeatedly, and the second data frame will be discarded.

[0011] Optionally, performing the delivery operation on at least one data frame includes performing the delivery operation according to order-preserving delivery and performing the delivery operation according to non-order-preserving delivery. When performing the delivery operation on multiple data frames, it also includes a case where order-preserving delivery data frames and non-order-preserving delivery data frames are mixed.

[0012] In one possible implementation, the arrival status recorded in the block confirmation scoreboard is the first data frame that has not arrived, and a delivery operation is performed on it after the first data frame with the corresponding sequence number arrives, including: after receiving the first data frame with the corresponding sequence number, judging that the first data frame is an order-preserving delivery data frame, and storing the first data frame in a reordering cache queue; after waiting for the first data frame delivered in order to be stored in the reordering cache queue, the first data frame is delivered together with the first data frame.

[0013] For order-preserving delivery data frames, they need to be delivered in the order of sequence numbers, such as from small to large sequence numbers. Therefore, in order to avoid the delivery order not meeting the requirements of order-preserving delivery, each data frame of order-preserving delivery can be stored in the corresponding reordering cache queue according to its sequence number after arriving at the receiving end. If the first data frame is the first data frame of order-preserving delivery that arrives, it is stored in the reordering cache queue. Between the head of the reordering cache queue and the window where the first data frame is stored, there may be a window occupied by the sequence number corresponding to the data frame that has been delivered due to non-order-preserving delivery, and the window is empty. According to the method provided in the present application, if the first data frame is stored at the head of the queue, the first data frame no longer has to wait for the forced delivery time to arrive because of the existence of an empty window. Instead, it waits until the first data frame of order-preserving delivery is stored in the reordering cache queue, and then the first data frame is delivered together with the first data frame. This is because according to the block confirmation scoreboard, it can be determined that the data frame corresponding to the empty window between the head of the reordering cache queue and the window storing the first data frame has arrived. Therefore, the data frames from the first data frame to the first data frame are considered to be continuously collected and can be delivered together according to the order-preserving delivery requirements.

[0014] Optionally, submitting together includes submitting from the first data frame to the first data frame one by one, or submitting from the first data to the first data frame together.

[0015] In one possible implementation, the arrival status recorded in the block confirmation scoreboard is the first data frame that has not arrived, and a delivery operation is performed on the first data frame with the corresponding sequence number after it arrives, including: after receiving the first data frame with the corresponding sequence number, judging that the first data frame is an order-preserving delivery data frame, and storing the first data frame in a reordering cache queue; after waiting for each data frame with a smaller sequence number than the corresponding sequence number of the first data frame, including the first data frame, to be stored in the reordering cache queue, the first data frame is delivered together with the preceding data frame, and the aforementioned data frames include the first data frame and each data frame with a smaller sequence number than the corresponding sequence number of the first data frame.

[0016] Exemplarily, when the first data frame and the first data frame are between the reordering cache queues, other data frames delivered in an order-preserving manner, such as the third data frame, and the sequence number of the third data frame is smaller than the sequence number of the first data frame, when the first data frame is stored in the head of the queue, the receiving end starts checking from the head of the reordering cache queue and the joint block confirmation scoreboard to determine that the first data frame and the first data frame are between the reordering cache queues, including the empty window corresponding to the submitted non-order-preserving data frame, and the window stored with the third data frame, and the non-order-preserving data frame has arrived, it is deemed that there are one or more consecutive data frames starting from the head of the queue, and the first data frame, the third data frame and the first data frame are delivered together.

[0017] In a possible implementation, after the first data frame is delivered together with the first data frame, the reordering buffer queue is refreshed.

[0018] The first data frame is delivered together with the first data frame, including delivering the first data frame and the first data frame together, or delivering the first data frame, the first data frame, and each data frame with a sequence number smaller than the first data frame together. After delivery, the reordering buffer queue is refreshed and the sliding window is slid. This ensures timely updates to the reordering buffer queue, providing more accurate data support for determining whether a data frame has arrived.

[0019] In one possible implementation, the arrival status recorded in the block confirmation scoreboard is the first data frame that has not arrived, and a delivery operation is performed on it after the first data frame with the corresponding sequence number arrives, including: after receiving the first data frame with the corresponding sequence number, determining that the first data frame is the first data frame to be delivered in order; delivering the first data frame, and refreshing the reordering cache queue.

[0020] If the first data frame received is the first data frame to be delivered in order, it can be delivered immediately without being stored in the reorder buffer queue. The reorder buffer queue is then refreshed, and the reorder buffer queue window slides. The next data frame to be delivered in order after the first data frame slides to the head of the queue and is then delivered in order. This simplifies the process of storing the first data frame in the reorder buffer queue and then delivering it, reducing the latency of order-preserving delivery.

[0021] In one possible implementation, the arrival status recorded in the block confirmation scoreboard is the first data frame that has not arrived, and a delivery operation is performed on it after the first data frame with the corresponding sequence number arrives, including: after receiving the first data frame with the corresponding sequence number, determining that the first data frame is a non-sequence-preserving delivery data frame, and immediately delivering the first data frame.

[0022] In a possible implementation, the method further includes: after successfully delivering the first data frame, updating the arrival status corresponding to the first data frame in the block confirmation scoreboard to "arrived".

[0023] The first data frame can be a data frame delivered in sequence or a data frame delivered out of sequence. After the first data frame is successfully delivered, the arrival status of the first data frame is updated to arrived. In the event that the first data frame is subsequently erroneously retransmitted and successfully received, the duplicated first data frame can be discarded to avoid duplicate delivery of the first data frame.

[0024] In a second aspect, the present application provides a method for data frame delivery, comprising: determining whether each data frame in at least one data frame with a sequence number has arrived based on the cache status of the window of the data frame corresponding to the sequence number in the reordering cache queue, and the delivery status of the data frame corresponding to the sequence number recorded in the delivery scoreboard; for the first data frame whose arrival status is determined by the delivery scoreboard and the reordering cache queue to be not arrived, performing a delivery operation on it after the first data frame with the corresponding sequence number arrives.

[0025] Optionally, the data frame submission method is executed by a data frame submission device, which is deployed in a receiving end, hereinafter referred to as the receiving end.

[0026] The receiving end includes a delivery scoreboard for recording the delivery status of data frames with different sequence numbers, and a reordering buffer queue for caching data frames corresponding to sequence numbers for order-preserving delivery. Upon receiving a first data frame carrying a sequence number, the receiving end queries the delivery scoreboard corresponding to that sequence number to obtain the delivery status of the first data frame. The receiving end then queries the window in the reordering buffer queue corresponding to that sequence number and determines the cache status of the first data frame based on whether the window is empty, that is, whether the first data frame is stored.

[0027] The submission method provided herein can query a submission scoreboard and a reordering buffer queue to jointly determine whether a data frame has arrived. The determination method includes: if the submission status of the scoreboard window corresponding to the sequence number of the first data frame in the submission scoreboard is "not delivered," and the window corresponding to the sequence number of the first data frame in the reordering buffer queue is empty, i.e., the first data frame is not stored, then it can be determined that the first data frame has not arrived; otherwise, it is determined that the first data frame has arrived. If the first data frame currently received does not arrive, a submission operation can be performed on the first data frame. This method of determining whether to perform a submission operation based on whether the data frame has arrived can ensure that all submitted data frames are first-arriving data frames, effectively avoiding duplicate submissions. Moreover, this submission method, which determines whether a data frame has arrived based on the submission scoreboard and the reordering buffer queue, is equivalent to determining whether to submit based on the cache status in the reordering buffer queue. This method is updated to determine whether to submit based on the submission scoreboard and the reordering buffer queue. This method has a relatively small change to the basis for determining submission operation, is easier to implement, and has a lower implementation cost.

[0028] In a possible implementation, the method further includes: determining, with respect to the submission scoreboard and the reordering buffer queue, that the second data frame has arrived, and discarding the second data frame with the corresponding sequence number after it arrives again.

[0029] In one possible implementation, the submission scoreboard and the reordering cache queue determine that the arrival status is the first data frame that has never arrived, and perform a submission operation on the first data frame with the corresponding sequence number after it arrives, including: after receiving the first data frame with the corresponding sequence number, judging that the first data frame is an order-preserving submission data frame, and storing the first data frame in the reordering cache queue; after waiting for the first data frame to be submitted in order to be stored in the reordering cache queue, the first data frame is submitted together with the first data frame.

[0030] In one possible implementation, the submission scoreboard and the reordering cache queue determine that the arrival status of the first data frame is not arrived, and perform a submission operation on the first data frame with the corresponding sequence number after it arrives, including: after receiving the first data frame with the corresponding sequence number, judging that the first data frame is an order-preserving submission data frame, and storing the first data frame in the reordering cache queue; if at least one data frame with a smaller sequence number than the corresponding sequence number of the first data frame has completed submission, refreshing the reordering cache queue, and updating the submission status corresponding to the at least one data frame in the submission scoreboard to submitted; after waiting for each order-preserving submission data frame with a smaller sequence number than the corresponding sequence number of the first data frame, including the first data frame, to be stored in the reordering cache queue, the first data frame is submitted together with the preceding data frame, and the preceding data frame includes the first data frame and each order-preserving submission data frame with a smaller sequence number than the corresponding sequence number of the first data frame.

[0031] In a possible implementation, after the first data frame is submitted together with the first data frame, the reordering buffer queue and the submission scoreboard are refreshed.

[0032] In one possible implementation, the delivery scoreboard and the reordering cache queue determine that the arrival status is the first data frame that has never arrived, and perform a delivery operation on the first data frame with a corresponding sequence number after it arrives, including: after receiving the first data frame with a corresponding sequence number, judging that the first data frame is the first data frame to be delivered in order; delivering the first data frame, and refreshing the reordering cache queue and the delivery scoreboard.

[0033] In one possible implementation, the delivery scoreboard and the reordering cache queue determine that the arrival status is the first data frame that has never arrived, and perform a delivery operation on the first data frame with the corresponding sequence number after it arrives, including: after receiving the first data frame with the corresponding sequence number, judging that the first data frame is a non-sequence-preserving delivery data frame, and immediately delivering the first data frame.

[0034] In one possible implementation, the method further includes: after successfully submitting the first data frame, updating the submission status corresponding to the first data frame in the submission scoreboard to submitted, and updating the cache status corresponding to the first data frame in the reordering cache queue to empty.

[0035] It should be understood that the second aspect of this application corresponds to the technical solution of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar, which will not be repeated here.

[0036] In a third aspect, the present application provides a first device comprising at least one control module, wherein the at least one control module comprises a coupled block confirmation scoreboard control module and a reordering cache queue control module, to implement the method described in the first aspect.

[0037] In a fourth aspect, the present application provides a second device comprising at least one control module, wherein the at least one control module comprises a coupled block confirmation scoreboard control module and a reordering cache queue control module, to implement the method described in the first aspect.

[0038] In a fifth aspect, the present application provides a communication device, which includes a processor and a storage medium, wherein the storage medium stores instructions. When the instructions are executed by the processor, the processor is used to execute the method described in any of the above aspects and the operations involved in any possible implementation of any aspect.

[0039] In a sixth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements part or all of the operations included in the method described in any of the aforementioned aspects and any possible implementation method of any of the aforementioned aspects.

[0040] In a seventh aspect, the present application provides a computer program product comprising instructions which, when executed on a processor, implement part or all of the operations included in the method described in any of the foregoing aspects and any possible implementation of any of the foregoing aspects.

[0041] In an eighth aspect, the present application provides a chip, comprising: a port circuit and a processor. The port circuit is connected to the processor, and the processor is configured to cause the chip to perform some or all of the operations included in the method described in any of the aforementioned aspects and any possible implementation of any of the aforementioned aspects.

[0042] It should be understood that the third to eighth aspects of the present application are consistent with or correspond to the technical solutions of the first or second aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] FIG1 is a schematic diagram of an MPDU stored in a reordering buffer queue according to an embodiment of the present application;

[0045] FIG2 is a flow chart of a method for submitting a data frame according to an embodiment of the present application;

[0046] FIG3 is a flow chart of another method for submitting a data frame provided in an embodiment of the present application;

[0047] FIG4 is a schematic diagram of a delivery process of an MPDU provided in an embodiment of the present application;

[0048] FIG5 is a schematic diagram of one of the MPDU delivery scenarios provided in an embodiment of the present application;

[0049] FIG6 is a second schematic diagram of an MPDU delivery process provided in an embodiment of the present application;

[0050] FIG7 is a second schematic diagram of an MPDU delivery scenario provided in an embodiment of the present application;

[0051] FIG8 is a flow chart of another method for submitting a data frame according to an embodiment of the present application;

[0052] FIG9 is a schematic structural diagram of a submission scoreboard provided in an embodiment of the present application;

[0053] FIG10 is a third schematic diagram of an MPDU delivery process provided in an embodiment of the present application;

[0054] FIG11 is a third schematic diagram of an MPDU delivery scenario provided in an embodiment of the present application;

[0055] FIG12 is a schematic diagram of a structure of a first device provided in an embodiment of the present application;

[0056] FIG13 is a second structural diagram of a first device provided in an embodiment of the present application;

[0057] FIG14 is a third structural diagram of a first device provided in an embodiment of the present application;

[0058] FIG15 is a schematic diagram of a structure of a second device provided in an embodiment of the present application;

[0059] FIG16 is a second structural diagram of a second device provided in an embodiment of the present application;

[0060] FIG17 is a schematic structural diagram of a system for delivering a data frame according to an embodiment of the present application;

[0061] FIG18 is a schematic structural diagram of a device 60 according to an embodiment of the present application;

[0062] FIG19 is a schematic structural diagram of a communication device 70 according to an embodiment of the present application;

[0063] FIG20 is a schematic structural diagram of a device 80 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] In order to enable people in this technical field to better understand the solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in combination with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0065] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0066] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0067] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0068] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0069] For ease of understanding, the following first explains the relevant nouns or terms used in the embodiments of this application:

[0070] 1. Submit in order

[0071] Including the order-preserving delivery mechanism of the MAC layer in the 802.11 standard, including: the sender will assign an increasing sequence number (SN) to each MPDU sent, and the order-preserving delivery requires the receiver to deliver MDPUs to the LLC layer in the order of increasing SNs.

[0072] 2. Reordering Buffer Queue

[0073] The buffer cache has received at least one MPDU. Only when all the MPDUs at the head of the reordering buffer queue are received, will the consecutive received MPDUs be delivered to the LLC layer. That is, the receiving end starts checking whether one or more consecutive MPDUs are received from the head of the reordering buffer queue. If they are received, they are delivered to the LLC layer until the first empty buffer position is encountered.

[0074] 3. Out-of-Order Delivery

[0075] This includes the receiving end immediately submitting the MPDU to the LLC layer after receiving it.

[0076] When delivering data frames, there are usually two situations. One is that the data frame can be delivered immediately after it is received, which can be called non-sequence-preserving delivery. The other is that the data frame needs to be delivered in the order of increasing SN, which can be called sequence-preserving delivery.

[0077] In the embodiment of the present application, the data frame to be submitted is the MAC layer, and the data frame to be submitted to the LLC layer, that is, the MPDU, is used as an example to illustrate the method of submitting the data frame. When submitting data frames of other layers, the example of the embodiment of the present application can be referred to. The data frame can be judged whether it needs to be submitted or discarded by whether it has reached the data frame submission device set at the receiving end (hereinafter referred to as the receiving end). Different data frames will not be expanded for detailed description. In actual application scenarios, the device set at the sending end (hereinafter referred to as the sending end) can send a service flow including at least one MPDU to the receiving end based on different services. Each MPDU can carry an MPDU with a different SN identifier. The embodiment of the present application is explained by taking the example of the sending end assigning incremental SNs to the MPDUs one by one according to the order in which the services are generated. The order of other SNs can refer to the example of the embodiment of the present application. In some examples, the SN can be carried in the message header of the MPDU.

[0078] For example, in a MAC layer delivery scenario, the transmitter has two service flows that need to be delivered from the MAC layer to the LLC layer, denoted as service flow A and service flow B. Service flow A requires in-order delivery by the receiver, while service flow B requires a non-sequence-preserving delivery mechanism by the receiver. To transmit and deliver services of these two service flows, the multiple MPDUs sent by the transmitter to the receiver and received by the receiver fall into three categories: one in which all the MPDUs are in-order delivered for service flow A, one in which all the MPDUs are non-sequence delivered for service flow B, and the third in which the MPDUs are a mixture of in-order delivered MPDUs and non-sequence delivered MPDUs.

[0079] The following examples are given for each of these three situations to illustrate that when delivering MPDUs, there may be problems such as duplicate delivery and abnormal delivery, which result in high delivery overhead and long delivery delay.

[0080] In one possible implementation scenario, the transmitter sends service flow B to the receiver, which is carried on at least one MPDU. Once the MPDU of service flow B reaches the receiver, it can be submitted to the LLC layer. However, since there is no duplicate checking mechanism for non-sequence-preserving MPDUs, once an MPDU is mistakenly sent repeatedly, it will cause duplicate MPDU submission. For example, the service flow B sent by the transmitter is carried on 5 MPDUs, whose SNs are identified as 1, 2, 3, 4, and 5 respectively (hereinafter, the SN identified as 1 is simply recorded as SN=1, the SN identified as 2 is recorded as SN=2, and so on). After the MPDU of service flow B is submitted, the transmitter mistakenly believes that the transmission of these five MPDUs has failed due to reasons such as not receiving a block confirmation frame, so it sends it again. The receiver receives the MPDUs identified as SN=1, SN=2, SN=3, SN=4, and SN=5 again, and submits them to the LLC layer again, resulting in duplicate submission.

[0081] In one possible implementation scenario, the transmitter sends service flow A, carried by multiple MPDUs, to the receiver. The transmitter assigns an increasing SN to each MPDU sent. Since service flow A requires order-preserving delivery, the receiver, after receiving at least one MPDU, must deliver these multiple MPDUs to the LLC layer in ascending SN order. Due to the uncertainty of the wireless link, which can lead to packet loss and retransmission, the order in which these multiple MPDUs arrive at the receiver may be different from the order in which the SNs are ascending. Therefore, the receiver maintains a buffer queue, such as a reordering buffer, to temporarily store the MPDUs that have arrived, waiting for the delivery of consecutive MPDUs starting with the first MPDU. That is, the receiver will only deliver the consecutively received MPDUs to the LLC layer after the MPDU at the head of the reordering buffer queue is collected. The collection of the MPDUs at the head of the reordering buffer queue includes determining whether one or more consecutive MPDUs are cached in their corresponding positions in the reordering buffer queue. If so, they are delivered to the LLC layer until the first empty buffer position is encountered. With reference to FIG1 , a scenario in which multiple MPDUs need to be delivered in order is described. FIG1 is a schematic diagram of an MPDU stored in a reordering buffer queue provided by an embodiment of the present application. As shown in FIG1 , it is assumed that the transmitting end sends 64 MPDUs to carry the services of service flow A. When sending, SN identifiers SR, SR+1, SR+2 to SR+63 are assigned to them in the order of sending. After the multiple MPDUs arrive at the receiving end, they are first stored in the reordering buffer queue. The order of caching is: starting from the head of the reordering buffer queue, the first window (which can be recorded as window 1) corresponds to the MPDU with SN identifier SR, the second window (which can be recorded as window 2) corresponds to the MPDU with SN identifier SR+1, and so on. The receiving end can start delivering to the LLC from the MPDU stored in window 1 in the reordering buffer queue. Typically, the receiving end can submit one or more consecutive MPDUs to the LLC, starting with the MPDUs stored in window 1 of the reordering buffer queue. For example, in this example, after submitting the MPDUs stored in window 1, the MPDUs stored in window 2 can be submitted, and so on. Alternatively, the receiving end can wait until all MPDUs from SR, SR+1, SR+2 to SR+63 are received before submitting them in sequence. This embodiment of the present application uses the first method of continuous submission as an example for explanation.

[0082] If packet loss occurs during transmission, such as the loss of the MPDU with SN identification SR+2, the third window (which can be recorded as window 3) in the reordering buffer queue of the receiver, where the MPDU with SN identification SR+2 should be stored, is empty. Based on the requirement of order-preserving delivery in ascending order of SN, the receiver can start from the first window at the head of the reordering buffer queue, and determine that the windows corresponding to the MPDUs with SN identifications SR and SR+1 are non-empty, and the window corresponding to the MPDU identified as SR+2 is empty. Therefore, the receiver starts to deliver the MPDU stored in window 1 in the reordering buffer queue to the LLC layer, and after delivering window 2 (the stored MPDU), if the first cached window is empty, the delivery is stopped, and the window of the reordering buffer queue is slid, that is, the original window 3 moves forward 2 positions to the first window, and the original fourth window (which can be recorded as window 4) moves forward 2 Position, move to the second window, and the other subsequent windows are similarly moved forward. After delivery, the sliding window is empty at the head of the reordering buffer queue, and waits for the first MPDU stored in the head of the queue to be stored before continuing to deliver. In some examples, after the delivery encounters an empty window (such as the original window 3 corresponding to the MPDU of SR+2 in this example), a timer can be started, such as a timer of 20 milliseconds to 100 milliseconds. If the timer times out and the empty window does not store the MPDU, continue to slide the window of the reordering buffer queue, slide the next non-empty window to the head of the queue and start delivering. For example, if the timer times out and the MPDU of SR+2 is still not received, refer to the example in Figure 1, and the next window will be delivered. A non-empty MPDU, i.e. the original window 4, slides to the first window of the reordering buffer queue and starts to be delivered as the head of the queue. If the sender successfully receives the SR+2 MPDU before the timer expires, it queries the cache status of the reordering buffer queue. Since the window corresponding to the SR+2 MPDU has slid to the first window and is empty, the SR+2 MPDU is stored in the head of the reordering buffer queue and continues to be delivered to the LLC layer starting from the head of the queue, referring to the above-mentioned order-preserving delivery example. The reordering buffer queue can reduce the possibility of duplicate delivery to a certain extent. For example, when the MPDU needs to be resent, if the sender resends, the sender If the receiver receives an MPDU with an SN of SR+2 and an MPDU with an SN of SR+63, it can query the cache status of the reordering buffer queue and determine that the position of the MPDU with an SN of SR+63 in the reordering buffer queue is not empty. Therefore, the newly received MPDU with SR+63 is discarded to avoid duplicate delivery. However, if all MPDUs carrying service flow A are delivered, and the sender retransmits 64 identical MPDUs due to some error, when the receiver queries the reordering buffer queue, the cache status of each window is empty. In this case, the receiver may still encounter the situation of duplicate MPDU delivery, and the duplicate delivery problem still exists.

[0083] In one possible implementation scenario, the transmitter sends an MPDU carrying service flow A and service flow B to the receiver, that is, the MPDU of service flow A and the MPDU of service flow B are sent mixedly. In this scenario, if the MPDU of service flow B is also required to be delivered to the LLC layer in order-preserving delivery, unnecessary delay will be added. Therefore, when the receiver receives the MPDU, it delivers the MPDU of service flow A in accordance with the order-preserving delivery requirements, and delivers the MPDU of service flow B in an immediate manner upon arrival. Due to the existence of services that require order-preserving delivery, the receiver maintains a reordering buffer queue, and each window in the reordering buffer queue corresponds to a received MPDU. In other words, the MPDU of service flow B will also have a corresponding window in the reordering buffer queue. Because the MPDU of service flow B will be delivered immediately after arriving at the receiver, after delivery, the cache status of the window corresponding to the MPDU of service flow B in the reordering buffer queue is empty. Referring to the in-order delivery requirement described in the above example, if the window in the reordering buffer queue is empty, the MPDU of service flow A that requires in-order delivery may not be delivered normally.

[0084] For example, the sender and receiver pre-agreed on the SN of the first of multiple MPDUs to be transmitted, such as SN=1. Assume the sender sends five MPDUs, with SNs 1, 2, 3, 4, and 5, respectively. SN=1, 4, and 5 are MPDUs for service flow A and require in-order delivery, while SN=2 and 3 are MPDUs for service flow B and require non-in-order delivery. This transmission is recorded as the first transmission. An error occurred during the transmission of MPDU SN=1, and the receiver failed to receive the MPDU SN=1. All other MPDUs were received successfully. Because the receiver did not receive any MPDUs before the sender's first transmission, the cache status of the windows corresponding to each MPDU in its reordering buffer queue is: all empty. After the receiver receives the first transmitted data frame, each window in the reorder buffer queue corresponds to an MPDU with a specific SN. Starting from the front of the queue, the windows in the reorder buffer queue are designated as Window 1, Window 2, Window 3, Window 4, and Window 5. Window 1 corresponds to an MPDU with SN = 1, Window 2 corresponds to an MPDU with SN = 2, and so on. The receiver can identify the correctly received MPDUs with SN = 2, SN = 3, SN = 4, and SN = 5. For example, based on the identification bit agreed upon by the sender and receiver in each MPDU header, the receiver determines whether the MPDU is delivered in-order or out-of-order. It then stores the MPDUs with SN = 4 and 5 in-order, such as those with SN = 5 in this example, in the reorder buffer queue and delivers the MPDUs with out-of-order delivery, such as those with SN = 2 and 3 in this example, to the LLC layer. After the MPDUs with SN = 2 and 3 are delivered, the reorder buffer queue is flushed, and Window 1, Window 2, and Window 3 are empty, while Window 4 and Window 5 are not empty. Because it didn't receive the MPDU with SN = 1, the receiver generates a block acknowledgment frame, instructing the transmitter to resend the MPDU with SN = 1. Following the instruction in the block acknowledgment frame, the transmitter successfully transmits the MPDU with SN = 1 a second time. The receiver correctly receives the MPDU with SN = 1 and stores it in the corresponding position in the reordering buffer, i.e., window 1. The receiver then checks the reordering buffer again to see if there are any consecutive MPDUs available for delivery, starting from the head of the queue. For example, after storing the MPDU with SN = 1, window 1 is not empty and is at the head of the queue, allowing delivery. However, the MPDU with SN = 4 stored in window 4 and the MPDU with SN = 5 stored in window 5 are empty in the reordering buffer because the MPDUs with smaller sequence numbers, SN = 2 and SN = 3, have already been delivered. This blocks the delivery of the MPDUs with SN = 4 and SN = 5 in windows 2 and 3, preventing them from being delivered. These MPDUs can only be delivered after the timer expires, resulting in a significant delivery delay.

[0085] In order to solve the above problems, an embodiment of the present application provides a method for data frame delivery, which is based on whether the MPDU reaches the receiving end for delivery. It can effectively solve the problem of repeated MPDU delivery, and can further solve the problem of sequence-preserving MPDU being blocked and unable to be delivered normally, thereby reducing the delay of sequence-preserving delivery.

[0086] FIG2 is a flow chart of a method for submitting a data frame provided in an embodiment of the present application. As shown in FIG2 , the method may be executed by a receiving end, and the method includes: S101 and S102.

[0087] S101. A receiving end determines whether each data frame in at least one data frame with a sequence number has arrived based on arrival status of data frames corresponding to the sequence numbers recorded in a block confirmation scoreboard.

[0088] Referring to the above example, the sender assigns an SN to each MPDU. For example, an SN can be carried in the message header of each MPDU generated in the service order in ascending order. The following examples are all based on the example that the receiver and the sender pre-agree to transmit multiple MPDUs starting with SN=1, and the sender sends MPDUs with SN=1, SN=2, SN=3, SN=4 and SN=5 respectively.

[0089] The receiving end maintains a block acknowledgment scoreboard, which includes multiple windows. Each window can record the arrival of an MPDU to determine whether the MPDU corresponding to each SN has arrived. Exemplarily, the multiple windows of the block acknowledgment scoreboard include the first window (to distinguish it from the window of the reordering buffer queue, it can be recorded as scoreboard window 1), the second window (can be recorded as scoreboard window 2), through the sixty-fourth window (can be recorded as scoreboard window 64), etc., where scoreboard window 1 can be used to record the arrival of the MPDU with SN = 1, scoreboard window 2 can be used to record the arrival of the MPDU with SN = 2, and so on for the other scoreboard windows.

[0090] Optionally, in the scoreboard window of the block confirmation scoreboard, different numerical values ​​can be used to indicate the arrival of the MPDU. For example, a value of 1 in the scoreboard window indicates that the MPDU has arrived, and a value of 0 in the scoreboard window indicates that the MPDU has not arrived. This value is only an example, and a value of 0 can also be used to indicate arrival, a value of 1 can be used to indicate non-arrival, or numerical values ​​of different bits, such as 00, 01, 000, etc., can be used to indicate the arrival of the MPDU, etc. In the embodiment of the present application, a value of 1 in the scoreboard window indicates that the MPDU has arrived, and a value of 0 in the scoreboard window indicates that the MPDU has not arrived, as an example. In actual application scenarios, the values ​​can be set according to needs and are not limited to the examples in the embodiment of the present application.

[0091] The receiving end considers an MPDU that has already arrived at the receiving end as having arrived and updates the block acknowledgment scoreboard accordingly. Typically, each scoreboard window in the block acknowledgment scoreboard has an initial value (in this example, 0). When an MPDU arrives at the receiving end, the scoreboard window corresponding to the MPDU's SN in the updated acknowledgment block scoreboard is updated to 1. In other words, after an MPDU arrives at the receiving end, whether it is delivered or stored in the reorder buffer, the receiving end considers it as having arrived and updates the scoreboard window corresponding to its SN in the block acknowledgment scoreboard to record its arrival. For example, suppose the sending end sends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5. SN=1 is lost, while MPDUs with SN=2, SN=3, SN=4, and SN=5 arrive successfully. MPDUs with SN=2 and SN=3 are delivered, while MPDUs with SN=4 and SN=5 are stored in the reorder buffer. The receiving end can refresh the block acknowledgment scoreboard after the delivery of MPDUs with SN=2 and SN=3. The values ​​of the multiple scoreboard windows in the block acknowledgment scoreboard are refreshed from the initial 0 to the following values: scoreboard window 1 corresponding to the MPDU with SN=1 is 0, scoreboard window 2 corresponding to the MPDU with SN=2 is 1, scoreboard window 3 corresponding to the MPDU with SN=3 is 1, scoreboard window 4 corresponding to the MPDU with SN=4 is 1, and scoreboard window 5 corresponding to the MPDU with SN=5 is 1. This indicates that the MPDU with SN=1 has not arrived, but the MPDUs with SN=2, SN=3, SN=4, and SN=5 have arrived.

[0092] S102: The receiving end confirms that the block scoreboard records the first data frame that has not arrived, and performs a delivery operation on the first data frame with the corresponding sequence number after the frame arrives.

[0093] For example, if the first data frame is an MPDU with SN=1, and the receiving end determines based on the block confirmation scoreboard that the MPDU with SN=1 has not arrived, the sending end sends the MPDU with SN=1 again and performs a delivery operation on it. If the MPDU with SN=1 needs to be delivered according to the order-preserving service, the receiving end can first store it in the reordering cache queue and deliver it according to the SN requirements for order-preserving delivery, such as in order from small to large SN. Since SN=1 is the smallest and corresponds to the window at the head of the reordering cache queue, the receiving end can first deliver the MPDU stored in the reordering cache queue and in the window corresponding to SN=1, and then deliver it, or refresh the reordering cache queue after delivering it immediately. If the MPDU with SN=1 needs to be delivered according to the non-order-preserving service, the receiving end can immediately deliver it to the LLC layer.

[0094] Optionally, after the delivery operation is performed on the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, the receiving end may refresh the block confirmation scoreboard again, that is, refresh the scoreboard window 1 corresponding to the MPDU with SN=1 to 1, the scoreboard window 2 corresponding to the MPDU with SN=2 to 1, the scoreboard window 3 corresponding to the MPDU with SN=3 to 1, the scoreboard window 4 corresponding to the MPDU with SN=4 to 1, and the scoreboard window 5 corresponding to the MPDU with SN=5 to 1. This indicates that the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 have all arrived.

[0095] The first data frame can be delivered in order or out of order, and the sending end and the receiving end can pre-agree on a method for identifying the delivery requirements of the first data frame. For example, the first data frame can carry indication information to indicate whether the first data frame is delivered in order or out of order; or, according to a pre-agreement, the first data frame can carry a field, which can identify whether the first data frame is delivered in order or out of order, for example, the field can be an agreed field in the message header. The receiving end performs the delivery operation according to the delivery requirements of the identified first data frame. As long as the receiving end can first confirm the scoreboard through the query block and determine that the first data frame is a data frame that has not arrived, and then perform the delivery operation on it, the possibility of repeated delivery of the first data frame can be effectively avoided, saving the delivery overhead.

[0096] FIG3 is a flow chart of another method for submitting data frames provided in an embodiment of the present application. As shown in FIG3 , the method can be executed by a receiving end. The difference between the method and FIG2 is that, after S101, the method further includes: S103.

[0097] S103: The receiving end confirms that the arrival status of the second data frame recorded in the block confirmation scoreboard is that the second data frame has arrived, and discards the second data frame with the corresponding sequence number after it arrives again.

[0098] For example, if the second data frame is any one of the MPDUs with SN=2, SN=3, SN=4, or SN=5, and the receiving end determines that the second data frame has already arrived based on the arrival status recorded in the block acknowledgment scoreboard, it will discard it upon successful reception again. For example, if the second data frame is an MPDU with SN=2. The transmitting end retransmits the MPDU with SN=2 due to some error, and the receiving end receives the MPDU with SN=2, and determines that the arrival status of the MPDU with SN=2 has already arrived based on the block acknowledgment scoreboard, it will discard the second received MPDU with SN=2.

[0099] The second data frame can be delivered in order or out of order. When the receiving end receives the second data frame, it determines that its arrival status is too late and discards it. This effectively avoids the possibility of duplicate delivery of the second data frame and saves delivery overhead.

[0100] Combining the method flow shown in Figure 2 and Figure 3, an embodiment of the present application provides a method for submitting a data frame, including step S101. When the arrival status of the data frame is the first data frame that has not arrived, step S102 is executed; when the arrival status of the first data frame is the second data frame that has arrived, step S103 is executed.

[0101] In some delivery scenarios, data frames can be delivered based on IEEE protocols, such as IEEE 802.11 protocols, including 802.11a, 802.11b, 802.11g, 802.11n (Wi-Fi 4), 802.11ac (Wi-Fi 5), 802.11ax (Wi-Fi 6), IEEE 802.11be / Wi-Fi7 / EHT protocols, IEEE 802.11bn / UHR / Wi-Fi 8 protocols, or IEEE 802.11bf / sensing / perception protocols. The delivery method provided in the embodiments of the present application can implement delivery corresponding to the above protocols, thereby achieving the delivery effect of avoiding duplicate delivery and reducing latency.

[0102] The following examples illustrate how, in a Wi-Fi MPDU delivery scenario, duplicate deliveries are avoided and the latency of in-order delivery is reduced by using the block confirmation scoreboard to determine whether a packet has arrived and whether to perform the delivery operation.

[0103] One example is that multiple MPDUs sent by the transmitter need to be delivered out of order, that is, delivered immediately upon arrival at the receiver. Figure 4 is one of the schematic diagrams of an MPDU delivery process provided by an embodiment of the present application, and Figure 5 is one of the schematic diagrams of an MPDU delivery scenario provided by an embodiment of the present application. As shown in Figure 4, the method is performed by the transmitter and the receiver, and includes: S201 to S207.

[0104] S201: A transmitting end sends multiple MPDUs that require non-sequence-preserving delivery.

[0105] Optionally, the sender and the receiver may pre-agreed on an identifier to identify whether an MPDU is delivered in-order or out-of-order. For example, the sender and the receiver may pre-agreed on a field in the MPDU header (referred to as the agreed field). If a value, such as 1, is set, it indicates that the MPDU is an in-order service requiring in-order delivery and must be stored in the reorder buffer queue before being delivered according to the sequence number. If another value, such as 0, is set, it indicates that the MPDU is an out-of-order service and can be delivered immediately.

[0106] Optionally, the MPDU may also carry indication information, which is used to indicate an in-order service, thereby instructing the receiving end to deliver in order, or to indicate a non-in-order service, thereby instructing the receiving end to deliver in a non-in-order manner. This indication information may be carried in the message header.

[0107] Referring to Figure 5, the multiple MPDUs sent by the sender that require non-sequence-preserving delivery are 5 MPDUs, namely SN=1, SN=2, SN=3, SN=4 and SN=5, and all correspond to the MPDUs of service flow B, and when sent for the first time, all 5 MPDUs are sent successfully.

[0108] S202: The receiving end receives multiple MPDUs that require non-sequence-preserving delivery, queries the block confirmation scoreboard, and determines whether each MPDU has arrived based on the arrival status recorded in the block confirmation scoreboard.

[0109] The receiving end uses the same method as the sending end to determine whether an MPDU is a sequence-preserving or non-sequence-preserving service. For example, if the sending end, in accordance with a pre-agreed agreement, writes 0 in the agreed field in the message header of each MPDU sent, indicating that the MPDU is a non-sequence-preserving service, the receiving end can determine that the MPDU is a non-sequence-preserving service based on the value of the agreed field in the message header of each received MPDU being 0, and deliver it as a non-sequence-preserving service. Similarly, if the MPDU sent by the sending end carries indication information, the receiving end determines that the MPDU is a non-sequence-preserving service based on the indication of this indication information.

[0110] Referring to Figure 5, the block confirmation scoreboard queried by the receiving end has an initial value of 0 in each window because no MPDU has been delivered yet. Therefore, it is confirmed that the MPDUs with SN=1, SN=2, SN=3, SN=4 and SN=5 have not arrived.

[0111] S203: The receiving end delivers the MPDU that has not arrived and refreshes the block confirmation scoreboard.

[0112] Because the receiving end determines that the five received MPDUs were all delivered out of order, it can immediately deliver these five previously received MPDUs and refresh the block acknowledgment scoreboard. After the block acknowledgment scoreboard is refreshed, the scoreboard window value for each SN's MPDU is refreshed to 1, as shown in the block acknowledgment scoreboard corresponding to the first transmission in Figure 5.

[0113] S204: The receiving end generates and feeds back a block confirmation frame.

[0114] After refreshing the block acknowledgment scoreboard, the receiver can send a block acknowledgment frame to the transmitter to indicate the receipt of the MPDU. Typically, the receiver needs to quickly feedback the block acknowledgment frame to the transmitter, such as within 16 microseconds.

[0115] S205: The transmitting end resends at least one MPDU according to the feedback of the block acknowledgment frame.

[0116] If a Block Ack frame indicates that an MPDU was not successfully received, the transmitter retransmits the MPDU. If the Ack frame is lost, the transmitter does not receive the Block Ack frame. Based on the lack of Block Ack frames, the transmitter determines that the receiver has not received any MPDUs and retransmits all previously sent MPDUs. For example, if the transmitter does not receive a Block Ack frame within 16 microseconds due to a Block Ack frame loss, the transmitter mistakenly believes that the receiver has not received the five MPDUs. Therefore, the transmitter retransmits MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5.

[0117] S206: The receiving end receives at least one MPDU and queries the block confirmation scoreboard, and determines whether the at least one MPDU has arrived according to the arrival status recorded in the block confirmation scoreboard.

[0118] For example, if the sending end sends the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 for the second time, and the receiving end receives the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 again, it queries the block confirmation scoreboard. Referring to Figure 5, the block confirmation scoreboard is refreshed before the second sending, and the recorded arrival status includes that the scoreboard windows corresponding to the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 are all 1. Therefore, the receiving end confirms that the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 have all arrived.

[0119] S207: The receiving end discards the MPDU that has arrived.

[0120] The receiving end determines that the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 have all arrived, and may discard the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5.

[0121] In the embodiment of the present application, after the transmitting end sends at least one MPDU for the second time, if the receiving end determines that a certain MPDU has arrived, then the receiving end executes S207 for the MPDU; if it determines that a certain MPDU has not arrived, then the receiving end executes S203 for the MPDU that has not arrived.

[0122] As can be seen from the delivery process in Figures 4 and 5, the delivery method provided in the embodiments of the present application also requires determining whether an MPDU has arrived before based on the block confirmation scoreboard before deciding whether to deliver it, even for non-sequentially delivered MPDUs. For previously arrived MPDUs, even if they have been delivered, the block confirmation scoreboard has a value of 1, indicating that they have arrived. Therefore, when receiving them again, the receiving end can determine that they are duplicate MPDUs and discard them, effectively avoiding the delivery of duplicate non-sequentially delivered MPDUs.

[0123] In one example, multiple MPDUs sent by the transmitter require in-order delivery. This means they must first be stored in a reorder buffer queue and then delivered in order. Because received MPDUs must be delivered in order, the receiver maintains a reorder buffer queue (see Figure 1 or Figure 5 for the structure of the reorder buffer queue). The receiver allocates a window to each MPDU with a specific SN. For example, if the transmitter sends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, and the receiver determines that these MPDUs are all in-order delivery, it stores the MPDUs with each SN in the reorder buffer queue. Referring to the example above, the windows in the reorder buffer queue, starting from the head of the queue, are designated as window 1, window 2, window 3, window 4, and window 5. The receiver, starting from window 1, stores the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, respectively. Since the reorder buffer queue has five consecutive non-empty windows starting from the head of the queue, the MPDUs cached in these consecutive non-empty windows can be delivered together. This includes delivering MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 one by one in ascending SN order, or delivering MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 together. After delivery, the receiver refreshes the block acknowledgment scoreboard and the reorder buffer queue. Since the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 have all been delivered, the windows corresponding to each MPDU in the reorder buffer queue are empty, and the windows can slide, that is, the sixth window slides to the first window. Scoreboard Window 1, Scoreboard Window 2, Scoreboard Window 3, Scoreboard Window 4, and Scoreboard Window 5 in the block acknowledgment scoreboard are all refreshed to 1, indicating that the MPDU has arrived. In this case, if the MPDU corresponding to any one of SN=1, SN=2, SN=3, SN=4 and SN=5 is received again, that is, the MPDU arrives repeatedly, the method provided in the embodiment of the present application can effectively avoid repeated delivery. For example, if the MPDU with SN=3 is received again, according to the traditional technology, whether to deliver is determined based on whether the reordering cache queue is empty. Since window 3 in the reordering cache queue is empty, the MPDU with SN=3 will be delivered again, resulting in repeated delivery. According to the method provided in the embodiment of the present application, whether to deliver is determined based on the arrival of the MPDU corresponding to the SN recorded in the block confirmation scoreboard. Since the arrival recorded in window 3 of the block confirmation scoreboard is that it has arrived, the receiving end discards the MPDU with SN=3 received again and will not deliver it again, which can effectively avoid repeated delivery.

[0124] One example is that among the multiple MPDUs sent by the transmitter, there are a mixture of MPDUs that require order-preserving delivery and MPDUs that are not delivered in order. Figure 6 is a second schematic diagram of an MPDU delivery process provided by an embodiment of the present application, and Figure 7 is a second schematic diagram of an MPDU delivery scenario provided by an embodiment of the present application. As shown in Figure 6, the method is performed by the transmitter and the receiver, and includes: S301 to S310.

[0125] S301: A transmitting end sends multiple MPDUs, including MPDUs that require non-sequence-preserving delivery and MPDUs that require sequence-preserving delivery.

[0126] Exemplarily, referring to Figure 7, the transmitting end sends 5 MPDUs, namely, MPDUs with SN=1, SN=2, SN=3, SN=4 and SN=5, among which SN=1, SN=4 and SN=5 are MPDUs for sequence-preserving services, i.e., they need to be delivered in sequence, and SN=2 and SN=3 are MPDUs for non-sequence-preserving services, i.e., they need to be delivered non-sequence-preserving. When sending, indication information can be carried in each MPDU, such as carrying indication information in the message header, the indication information in the message header of the MPDU with SN=1, SN=4 or SN=5 is used to indicate that the MPDU with SN=1, SN=4 or SN=5 is the MPDU for sequence-preserving services, and the indication information in the message header of the MPDU with SN=2 or SN=3 is used to indicate that the MPDU with SN=2 or SN=3 is the MPDU for non-sequence-preserving services.

[0127] S302: The receiving end receives multiple MPDUs and queries the block confirmation scoreboard, and determines whether each MPDU has arrived based on the arrival status recorded in the block confirmation scoreboard.

[0128] The receiving end determines whether the received MPDU has arrived. If it has arrived, it executes S303; if it has not arrived, it executes S304.

[0129] For example, as shown in the example of Figure 7, after the transmitter sends 5 MPDUs for the first time, it is assumed that an error occurs in the transmission of the MPDU with SN=1, and the receiver does not correctly receive the MPDU with SN=1, but correctly receives the MPDUs with SN=2, SN=3, SN=4 and SN=5.

[0130] Referring to Figure 7, the receiving end queries the block confirmation scoreboard. Scoreboard Window 1 of the block confirmation scoreboard corresponds to the MPDU with SN=1, scoreboard Window 2 corresponds to the MPDU with SN=2, scoreboard Window 3 corresponds to the MPDU with SN=3, scoreboard Window 4 corresponds to the MPDU with SN=4, and scoreboard Window 5 corresponds to the MPDU with SN=5. Before receiving the first multiple MPDUs sent by the sending end, the values ​​in each scoreboard window are initial values. For example, if the value is 0, it indicates that the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 have not arrived. When the receiving end receives these four MPDUs and queries the block confirmation scoreboard, it can determine that the MPDUs with SN=2, SN=3, SN=4, and SN=5 have not arrived.

[0131] Optionally, the receiving end may also query whether the windows corresponding to the MPDUs of each SN in the reordering buffer queue are empty. Typically, the windows corresponding to the MPDUs of SN=1, SN=2, SN=3, SN=4, and SN=5 in the reordering buffer queue may be window 1, window 2, window 3, window 4, and window 5, respectively. Initially, each window is empty.

[0132] S303: The receiving end discards the MPDU that has arrived.

[0133] S304: The receiving end refreshes the block confirmation scoreboard.

[0134] According to the arrival of MPDUs with SN=2, SN=3, SN=4 and SN=5, the arrival status recorded in the block confirmation scoreboard is refreshed. The resulting block confirmation scoreboard is shown in FIG7 . The scoreboard window 1 corresponding to the MPDU with SN=1 is still 0 after the refresh, while the scoreboard windows corresponding to the MPDUs with SN=2, SN=3, SN=4 and SN=5 are refreshed to 1, that is, the scoreboard windows 2, 3, 4 and 5 are all refreshed to 1.

[0135] After S304, it is determined whether the MPDU is an MPDU delivered in sequence. If it is an MPDU delivered in sequence, S305 is executed; otherwise, S307 is executed.

[0136] The receiving end and the sending end have pre-agreed on indication information. The receiving end determines that the MPDUs with SN=2, SN=3, SN=4 and SN=5 need to be delivered in a non-sequential manner, and the MPDUs with SN=4 and SN=5 need to be delivered in a sequence-preserving manner based on the indication information carried in the received MPDUs with SN=2, SN=3, SN=4 and SN=5.

[0137] S305: The receiving end stores at least one MPDU delivered in order into a corresponding window of a reordering buffer queue.

[0138] If the receiving end determines that among the received MPDUs, the MPDU with SN=4 and the MPDU with SN=5 need to be delivered in order, referring to Figure 7, the MPDU with SN=4 is stored in window 4 of the reordering buffer queue, and the MPDU with SN=4 is stored in window 5 of the reordering buffer queue.

[0139] S306: The receiving end queries the block confirmation scoreboard to determine whether one or more consecutive MPDUs have arrived in the reordering buffer queue starting from the head of the queue. If they have all arrived, the MPDUs that need to be delivered in order are delivered.

[0140] Referring to the example in Figure 7, if the receiving end queries the block confirmation scoreboard and determines that the MPDU at the head of the reordering buffer queue, i.e., in window 1, has not arrived, then, according to the in-order delivery requirement, the in-order delivery process, which starts with the MPDU with the smallest SN, cannot be delivered due to the empty head of the queue. The receiving end waits for the receipt of the MPDU with SN = 1, stores it in window 1, and then checks the reordering buffer queue starting from the head of the queue to see if one or more consecutive MPDUs have arrived. If so, it delivers the MPDUs that require in-order delivery.

[0141] For example, if the receiving end queries the block confirmation scoreboard and determines that the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 have all arrived, then the reordering cache queue is judged. Starting from the head of the queue, 5 consecutive MPDUs (i.e., MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5) have arrived, among which SN=1, SN=4 and SN=5 need to be delivered in order, and the MPDUs of SN=1, SN=4 and SN=5 can be delivered.

[0142] S307: The receiving end immediately delivers at least one MPDU that is not delivered in sequence.

[0143] If the receiving end determines that the MPDU with SN=2 and the MPDU with SN=3 among the received MPDUs need to be delivered out of sequence (see FIG7 ), the receiving end immediately delivers the MPDUs with SN=2 and SN=3 after receiving them.

[0144] S308 is executed after S302.

[0145] S308: The receiving end generates a block confirmation frame and feeds the block confirmation frame back to the sending end.

[0146] In the example shown in FIG7 , the block acknowledgment frame is used to instruct the transmitting end to resend the MPDU with SN=1.

[0147] S309: The transmitting end resends at least one MPDU according to the feedback of the block acknowledgment frame.

[0148] If a Block Acknowledgement frame indicates that an MPDU was not successfully received, the transmitter retransmits the MPDU. If a Block Acknowledgement frame is lost, the transmitter does not receive the Block Acknowledgement frame. Based on the absence of the Block Acknowledgement frame, the transmitter determines that the receiver has not received any MPDUs and retransmits all previously sent MPDUs. This example uses the transmitter sending an MPDU with SN = 1 for the second time.

[0149] S310: The receiving end receives at least one MPDU and queries the block confirmation scoreboard, and determines whether the at least one MPDU has arrived based on the arrival status recorded in the block confirmation scoreboard.

[0150] If the received MPDU has arrived, execute S303; if the received MPDU has not arrived, execute S304.

[0151] 7 , the transmitting end sends the MPDU with SN=1 for the second time. After receiving the MPDU with SN=1, the receiving end queries the block confirmation scoreboard to confirm that the MPDU with SN=1 is in the scoreboard window 1 corresponding to the block confirmation scoreboard (the value is 0, i.e., it is determined that the MPDU with SN=1 has not arrived and it is the first time it has arrived. Therefore, the MPDU with SN=1 is stored in the corresponding window of the reordering buffer queue, i.e., window 1, and the block confirmation scoreboard is refreshed, and the scoreboard window 1 is refreshed to 1, indicating that the MPDU with SN=1 has arrived.

[0152] Optionally, in the example shown in FIG7 , the reordering buffer queue includes windows corresponding to MPDUs with multiple SNs. After the transmitter sends at least one MPDU for the second time, such as an MPDU with SN=1, the receiver receives and determines that it is the first MPDU to arrive, refreshes the block acknowledgment scoreboard, and stores the MPDU with SN=1 in window 1 of the reordering buffer queue. This means that the reordering buffer queue is refreshed. After the refresh, windows 1, 4, and 5 corresponding to MPDUs with SN=1, SN=4, and SN=5 in the reordering buffer queue are all non-empty, and in-order delivery can begin from window 1. This is equivalent to the receiver waiting for the first MPDU to be delivered in-order to be stored in the reordering buffer queue after the transmitter sends multiple MPDUs for the first time. After storage, since the MPDUs with SN=2 and SN=3 have already been delivered but the block acknowledgment scoreboard records their arrival, the receiver believes that the five consecutive MPDUs, starting from the head of the queue, have arrived and can deliver the MPDUs with SN=1, SN=4, and SN=5 together. In the embodiments of the present application, the "collective delivery" includes two situations: one is simultaneous delivery, and the other is delivering the MPDUs one by one in ascending order of SN (or other agreed order, etc.). In this example, the "collective delivery" of the MPDUs with SN=1, SN=4, and SN=5 can be the simultaneous delivery of the MPDUs with SN=1, SN=4, and SN=5, or the delivery of the MPDUs one by one in the order of SN=1, SN=4, and SN=5.

[0153] Optionally, when the receiving end determines that the received MPDU with SN=1 is the first MPDU to be delivered in order, it can immediately deliver the MPDU with SN=1 and refresh the reordering buffer queue. If the MPDUs with SN=2 and SN=3 have already been delivered in a non-order-preserving manner, the reordering buffer queue will be refreshed at this time, and the sliding window will slide the window corresponding to the MPDU with SN=4, that is, from window 4 to the first window. Similarly, the window corresponding to the MPDU with SN=5, that is, window 5, will slide to the second window, and then deliver them together from the head of the queue, that is, deliver the MPDUs with SN=4 and SN=5 together. This can further reduce the delay of delivering the MPDUs in order.

[0154] Alternatively, in one example, the transmitter sends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 for the first time, but the receiver fails to successfully receive the MPDUs with SN=1 and SN=4. The receiver needs to wait until all MPDUs with SNs smaller than the MPDU with SN=5, including the first MPDU, are stored in the reordering buffer queue before submitting them all together. That is, the receiver successfully receives and stores the MPDUs with SN=1 and SN=4 in the reordering buffer queue before submitting them all together.

[0155] In one possible implementation scenario, when the receiving end executes S308, the feedback acknowledgment frame block is lost. The sending end mistakenly believes that the first transmission failed and resends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5. After receiving the MPDUs, the receiving end queries the block acknowledgment scoreboard. If the window corresponding to the MPDUs with SN=2, SN=3, SN=4, and SN=5 in the block acknowledgment scoreboard is 1, it can be determined that the MPDUs with SN=2, SN=3, SN=4, and SN=5 have all arrived, and the MPDUs with SN=2, SN=3, SN=4, and SN=5 are discarded. The window corresponding to the MPDU with SN=1 is 0, and it is determined that the MPDU with SN=1 has not arrived. The block acknowledgment scoreboard is refreshed, and the delivery operation is performed again according to the above example for the MPDU with SN=1. In this way, even if the MPDUs with SN=2, SN=3, SN=4, and SN=5 are received repeatedly, duplicate delivery can be avoided.

[0156] Optionally, after each MPDU is delivered, the receiver can refresh the corresponding arrival status in the block acknowledgment scoreboard, updating its arrival status to "arrived." For example, in the example shown in Figure 7, after the transmitter sends five MPDUs for the first time, the receiver receives and delivers MPDUs with SN=2 and SN=3. The receiver then refreshes the block acknowledgment scoreboard, updating the window 2 corresponding to SN=2 and the window 2 corresponding to SN=3 to 1, indicating that the MPDUs with SN=2 and SN=3 have arrived. After the transmitter sends an MPDU with SN=1 again, which is successfully received by the receiver, the receiver delivers the MPDUs with SN=1, SN=4, and SN=5, and refreshes the block acknowledgment scoreboard again, updating the window corresponding to the MPDUs with SN=1, SN=4, and SN=5 to 1, indicating that the MPDUs with SN=1, SN=4, and SN=5 have arrived. Timely updating the block acknowledgment scoreboard based on the delivery status can improve the accuracy of determining whether an MPDU has arrived.

[0157] In an embodiment of the present application, the multiple MPDUs sent by the transmitter include MPDUs with SN=1, SN=4, and SN=5 that need to be delivered in order, and MPDUs with SN=2 and SN=3 that are not delivered in order. The MPDUs with SN=2 and SN=3 are delivered immediately after arrival. After the MPDUs with SN=1, SN=4, and SN=5 arrive at the receiver, since the MPDUs with consecutive SNs have all arrived, in this case, the receiver does not need to wait for the forced delivery time to expire before delivering the MPDUs with SN=4 and SN=5, which reduces the delay in delivering the MPDUs that are delivered in order. The delivery method provided in the embodiment of the present application determines whether the MPDU is delivered or discarded by whether the MPDU has arrived.

[0158] After the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 have all arrived, that is, they have all been received and delivered, the receiving end refreshes the reordering buffer queue again, and the window of the reordering buffer queue slides, that is, slides the sixth window to the current first window, to prepare for receiving subsequent data frames.

[0159] FIG8 is a flow chart of another method for submitting a data frame provided in an embodiment of the present application. As shown in FIG8 , the method may be executed by a receiving end, and the method includes: S401 and S402.

[0160] S401. The receiving end determines whether each data frame in at least one data frame with a sequence number has arrived based on whether the window of the data frame corresponding to the sequence number in the reordering buffer queue is not empty and the delivery status of the data frame corresponding to the sequence number recorded in the delivery scoreboard.

[0161] For example, the transmitter assigns an SN to each data frame and sends it. The following examples are all based on the example that the transmitter sends MPDUs with SNs of SN=1, SN=2, SN=3, SN=4, and SN=5.

[0162] The receiving end maintains a delivery scoreboard, which includes multiple scoreboard windows. Each scoreboard window records the delivery status of the MPDU corresponding to a sequence number. The delivery scoreboard can be refreshed after each MPDU is delivered, and the delivery status of the MPDU corresponding to the sequence number is updated to maintain the accuracy of the record. Unlike the block confirmation scoreboard provided in the above example, which records the arrival status of the MPDU corresponding to each sequence number, the delivery scoreboard is mainly used to record the delivery status of the MPDU. It cannot be used alone to determine whether the MPDU has arrived at the receiving end. Instead, it needs to be judged together with whether the window of the MPDU corresponding to the sequence number in the reordering buffer queue is not empty.

[0163] As shown in Figure 9, the submission scoreboard includes multiple scoreboard windows, each of which can record the submission status of an MPDU to determine whether the MPDU corresponding to each SN has been submitted. As shown in the example of Figure 9, the starting position of the submission scoreboard, i.e., scoreboard window 1 (denoted as w=1 in Figure 9) to scoreboard window 64 (denoted as w=64 in Figure 9), includes 64 window positions, wherein scoreboard window 1 can be used to record the submission status of the MPDU with SN=1, scoreboard window 2 can be used to record the submission status of the MPDU with SN=2, and so on.

[0164] Optionally, different numerical values ​​can be used in the scoreboard window of the submission scoreboard to indicate the status of the MPDU submission. For example, a value of 1 in the scoreboard window indicates that the MPDU has been submitted, and a value of 0 in the scoreboard window indicates that the MPDU has not been submitted. This value is only an example, and 0 can also be used to indicate that the MPDU has been submitted, 1 can be used to indicate that the MPDU has not been submitted, or other values ​​such as 00, 01, 000 can be used to indicate the status of the MPDU submission. In the embodiment of the present application, the example in which the value of 1 in the scoreboard window indicates that the MPDU has been submitted, and the value of 0 in the scoreboard window indicates that the MPDU has not been submitted is used for illustration. In actual application scenarios, the values ​​can be set according to requirements and are not limited to the examples in the embodiment of the present application.

[0165] The receiving end also maintains a reordering buffer queue, which can refer to the above example and include window 1, window 2, window 3, window 4, window 5, etc. starting from the head of the queue.

[0166] The receiving end can determine whether the MPDU has arrived by checking whether the window corresponding to each SN's MPDU received in the reordering buffer queue is empty and the scoreboard window value corresponding to the delivery scoreboard indicates whether it has been delivered. Based on whether an MPDU has arrived, the receiving end can determine whether to perform an operation on the MPDU. Querying the delivery scoreboard and the reordering buffer queue to jointly determine whether the MPDU has arrived includes: if the value of the window corresponding to an SN's MPDU in the delivery scoreboard is 0, and the window corresponding to the SN's MPDU in the reordering buffer queue is empty, it can be determined that the MPDU of this SN has not arrived; otherwise, it is determined that the MPDU has arrived.

[0167] For example, the sender sends MPDUs with SN = 1, SN = 2, SN = 3, SN = 4, and SN = 5. The MPDU with SN = 1 corresponds to the scoreboard submission window 1, which is the scoreboard window and the reordering buffer queue window 1. The MPDU with SN = 2 corresponds to the scoreboard submission window 2, which is the scoreboard window and the reordering buffer queue window 2. The same applies to MPDUs with other SNs. Assume that the receiving end receives MPDUs with SN=1, SN=2 and SN=3. If, in the submitted scoreboard, the value of the scoreboard window 1 corresponding to the MPDU with SN=1 is 0, and the window 1 corresponding to the MPDU with SN=1 in the reordering cache queue is empty, it can be determined that the MPDU with SN=1 has not arrived; if, in the submitted scoreboard, the value of the scoreboard window 2 corresponding to the MPDU with SN=2 is 1, and the window 2 corresponding to the MPDU with SN=2 in the reordering cache queue is empty, it can be determined that the MPDU with SN=2 has arrived and has been submitted, that is, it is determined that it has arrived; if, in the submitted scoreboard, the value of the scoreboard window 3 corresponding to the MPDU with SN=3 is 0, and the window 3 corresponding to the MPDU with SN=3 in the reordering cache queue is not empty, it can be determined that the MPDU with SN=3 has arrived and is cached in the reordering cache queue, and is determined to have arrived.

[0168] S402: The receiving end determines, based on the delivery scoreboard and the reordering buffer queue, that the first data frame that has arrived has not arrived before, and performs a delivery operation on the first data frame with the corresponding sequence number after it arrives.

[0169] If the receiving end determines that the first data frame is a data frame that has not arrived, then after the first data frame arrives, a delivery operation is performed. This step can refer to S102 and will not be described in detail.

[0170] Optionally, the method further includes: determining, with respect to the delivery scoreboard and the reordering cache queue, that the second data frame has arrived, and discarding the second data frame with the corresponding sequence number after it arrives again.

[0171] For example, if the second data frame is any one of the MPDUs with SN=2, SN=3, SN=4, or SN=5, for example, if the second data frame is an MPDU with SN=2, referring to the judgment method in S401, it is determined that the MPDU with SN=2 has already arrived. Then, upon receiving the MPDU with SN=2 again, the receiving end discards the MPDU with SN=2. Regardless of whether the second data frame is delivered in-order or out-of-order, upon receiving the second data frame, the receiving end discards it as long as it determines that it has already arrived. This effectively avoids the possibility of duplicate delivery of the second data frame, effectively saving delivery overhead.

[0172] The following examples illustrate how Wi-Fi MPDU delivery can be implemented. Using the delivery scoreboard and reordering buffer queue, the delivery is determined based on whether an MPDU has arrived before. This helps prevent duplicate deliveries and reduce latency for in-order delivery.

[0173] Optionally, in an embodiment of the present application, the transmitting end may pre-agree with the receiving end on an identifier for identifying whether the MPDU is delivered in-order or not. For example, the transmitting end may pre-agree with the receiving end on an agreed field in the message header of the MPDU. If it is 0, it indicates that the MPDU is an in-order service that needs to be delivered in-order. If it is 1, it indicates that the MPDU is a non-sequence-preserving service that can be delivered immediately. Alternatively, the MPDU carries indication information, and the indication information is used to indicate that the in-order service needs to be delivered in-order, or the indication information is used to indicate that the non-sequence-preserving service can be delivered immediately. Among them, if in a scenario where the MPDU for in-order delivery and the MPDU for non-sequence delivery are mixed, it is usually adopted to carry indication information in the MPDU to indicate whether the MPDU needs to be delivered in-order or not.

[0174] For example, when all MPDUs in Wi-Fi are delivered out of order, determining whether to perform a delivery operation is based on whether the MPDU has arrived before, effectively avoiding duplicate delivery. Before the sender sends an MPDU, the delivery scoreboard maintained by the receiver, including scoreboard window 1, scoreboard window 2, scoreboard window 3, scoreboard window 4, and scoreboard window 5, all have initial values ​​of 0. In a delivery method that requires jointly determining whether an MPDU has arrived based on the delivery scoreboard and the reordering buffer queue, regardless of whether the MPDUs sent by the sender include MPDUs delivered in order, the receiver must maintain a reordering buffer queue. Before receiving the first transmitted MPDU, each window in the reordering buffer queue, starting from the head of the queue, including window 1, window 2, window 3, window 4, and window 5, is empty. Suppose the sender first sends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, all of which are delivered out of order. After the first transmission, the receiver successfully receives the five MPDUs. Because they are non-sequence-preserving, it immediately delivers them and refreshes the delivery scoreboard. In the delivery scoreboard, scoreboard windows 1, 2, 3, 4, and 5, corresponding to MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, are all refreshed to 1, indicating delivery. At this point, the windows in the reordering buffer remain empty. If the receiver sends a block acknowledgment frame to the transmitter indicating successful reception of MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, but the block acknowledgment frame is lost during transmission, the transmitter does not receive the block acknowledgment frame and mistakenly believes that the receiver did not successfully receive the frame. Therefore, the transmitter sends the MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 a ​​second time. After receiving MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 again, the receiver queries the delivery scoreboard and reordering buffer queue. Based on the scoreboard window 1 corresponding to the MPDU with SN=1 being 1 and the reordering buffer queue window 1 being empty, it determines that the MPDU with SN=1 has already arrived. It then discards the MPDU with SN=1, and the same applies to the MPDUs with SN=2, SN=3, SN=4, and SN=5. The receiver uses the delivery scoreboard and reordering buffer queue to jointly determine whether the MPDU has arrived and discards the duplicate MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, effectively preventing duplicate delivery.

[0175] For example, when all MPDUs in Wi-Fi are delivered in order, determining whether to perform the delivery operation based on whether the MPDU has arrived can effectively avoid duplicate delivery. Before the sender sends the MPDU, the delivery scoreboard maintained by the receiver includes scoreboard window 1, scoreboard window 2, scoreboard window 3, scoreboard window 4, and scoreboard window 5, etc. Each scoreboard window is an initial value, that is, 0. The maintained reordering buffer queue, including window 1, window 2, window 3, window 4, and window 5, etc., are all empty. If the sender sends SN=1, SN=2, SN=3, SN=4, and SN=5 for the first time, and all are delivered in order, but the MPDU with SN=1 fails to be sent, and the MPDUs with SN=2, SN=3, SN=4, and SN=5 are all sent successfully. After receiving the MPDUs, the receiver stores the MPDUs with SN=2, SN=3, SN=4, and SN=5 in windows 2, 3, 4, and 5 of the reorder buffer queue, respectively. It also refreshes the delivery scoreboard and the reorder buffer queue. At this point, because no MPDUs have been delivered, the values ​​in each scoreboard window of the delivery scoreboard remain at 0. In the reorder buffer queue, window 1 corresponding to the MPDU with SN=1 is empty, while windows 2, 3, 4, and 5 are not empty. This means that the MPDU with SN=1 has not arrived, while the MPDUs with SN=2, SN=3, SN=4, and SN=5 have all arrived. In this case, the receiver sends a block acknowledgment frame to the transmitter, instructing it to retransmit the MPDU with SN=1. The transmitter mistakenly retransmits the MPDU with SN=2 during its second transmission, effectively sending both the MPDUs with SN=1 and SN=2. After receiving MPDUs with SN=1 and SN=2, the receiving end queries the delivery scoreboard and reordering buffer queue and determines that the MPDU with SN=1 has not arrived, while the MPDUs with SN=2, SN=3, SN=4, and SN=5 have all arrived. Therefore, the receiving end discards the MPDU with SN=2 and stores the MPDU with SN=1 in window 1 of the reordering buffer queue. The delivery is performed according to the delivery method for MPDUs with in-order delivery in the above example. After the delivery, the first five scoreboard windows in the delivery scoreboard are all refreshed to 1. For example, if the block acknowledgment frame fed back by the receiving end is lost at this time, and the transmitting end retransmits the MPDUs with SN=1 and SN=2, the receiving end can determine that the MPDUs with SN=1 and SN=2 have already arrived based on the fact that the windows corresponding to SN=1 and SN=2 in the reordering buffer queue are empty, but the corresponding scoreboard windows in the delivery scoreboard have a value of 1. Therefore, the receiving end discards the MPDUs with SN=1 and SN=2, effectively avoiding duplicate delivery.

[0176] For example, when implementing a Wi-Fi MPDU that includes both sequence-preserving MPDUs and non-sequence-preserving MPDUs, determining whether to perform a delivery operation is based on whether the MPDU has arrived. This can effectively avoid duplicate deliveries, ensure the normal delivery of sequence-preserving MPDUs, and reduce latency. Figure 10 is a third schematic diagram of an MPDU delivery process provided by an embodiment of the present application, and Figure 11 is a third schematic diagram of an MPDU delivery scenario provided by an embodiment of the present application. As shown in Figure 10, the method is performed by a transmitting end and a receiving end, and includes: S501 to S509.

[0177] S501: A transmitting end sends multiple MPDUs, including MPDUs that require non-sequence-preserving delivery and MPDUs that require sequence-preserving delivery.

[0178] Referring to Figure 10, the transmitter sends five MPDUs, namely, MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5. SN=1, SN=4, and SN=5 are MPDUs for sequence-preserving services, which require sequence-preserving delivery, and SN=2 and SN=3 are MPDUs for non-sequence-preserving services, which require non-sequence-preserving delivery. When sending, indication information can be carried in each MPDU, such as in the message header. The indication information of SN=1, SN=4, or SN=5 is used to indicate that SN=1, SN=4, or SN=5 is an MPDU for sequence-preserving services, and the indication information of SN=2 or SN=3 is used to indicate that SN=2 or SN=3 is an MPDU for non-sequence-preserving services.

[0179] As shown in the example of FIG10 , when the transmitter sends for the first time, an error occurs in the transmission of the MPDU with SN=1, while the other MPDUs are sent correctly.

[0180] S502. The receiving end receives multiple MPDUs and queries the delivery scoreboard and the reordering buffer queue. Based on the delivery status of the MPDU corresponding to the sequence number recorded in the delivery scoreboard and whether the window of the MPDU corresponding to the sequence number in the reordering buffer queue is empty, it is determined whether the MPDU has arrived.

[0181] Assume that the receiving end does not correctly receive the MPDU with SN=1, but correctly receives the MPDUs with SN=2, SN=3, SN=4, and SN=5.

[0182] 10 , the receiving end queries the submission scoreboard. Referring to the above example, in the initial state of the submission scoreboard, each scoreboard window is 0. The reordering cache queue is queried. In the initial state of the reordering cache queue, each window is empty.

[0183] The receiving end determines whether a received MPDU has arrived based on the delivery scoreboard and the reordering buffer queue. If the scoreboard window corresponding to an MPDU of a SN in the delivery scoreboard is 0 and the window corresponding to the MPDU of the SN in the reordering buffer queue is empty, it can be determined that the MPDU of this SN has not arrived. Otherwise, it is determined that the MPDU has arrived. If the receiving end determines that the MPDU has arrived, it executes S503. If it determines that the MPDU has not arrived, it determines whether the MPDU is an MPDU delivered in sequence. If it is an MPDU delivered in sequence, it executes S504; otherwise, it executes S506.

[0184] As shown in the example of FIG10 , after the receiving end receives the MPDUs of SN=2, SN=3, SN=4 and SN=5, it determines that the MPDUs of SN=2, SN=3, SN=4 and SN=5 have not arrived, and then executes S505.

[0185] S503: The receiving end discards the MPDU that has arrived.

[0186] S504: The receiving end stores at least one MPDU delivered in order into a corresponding window of a reordering buffer queue.

[0187] S505: The receiving end combines the delivery scoreboard and the reordering buffer queue to determine whether one or more consecutive MPDUs have arrived in the reordering buffer queue starting from the head of the queue. If so, the MPDUs that need to be delivered in order are delivered and the delivery scoreboard is refreshed.

[0188] S506: The receiving end immediately delivers at least one non-sequence-preserving MPDU and refreshes the delivery scoreboard.

[0189] As shown in Figure 10, after receiving MPDUs with SN=2, SN=3, SN=4, and SN=5, the receiver determines that the MPDUs with SN=2 and SN=3 require non-sequential delivery. Therefore, the receiver immediately delivers the MPDUs with SN=2 and SN=3. The delivery scoreboard is refreshed to the following: the values ​​of scoreboard window 2 for SN=2 and window 3 for SN=3 are set to 1, while the values ​​of the other windows remain 0.

[0190] MPDUs with SN=4 and SN=5 require in-order delivery and are stored in the corresponding windows of the reorder buffer queue. That is, the MPDU with SN=4 is stored in window 4 of the reorder buffer queue, and the MPDU with SN=5 is stored in window 5 of the reorder buffer queue. The reorder buffer queue is refreshed so that windows 4 and 5 of the reorder buffer queue are not empty, while the other windows remain empty. Referring to the judgment method provided in the above example, it can be determined that MPDUs with SN=2, SN=3, SN=4, and SN=5 have arrived, but the MPDU with SN=1 has not. In the example shown in Figure 10, when the receiver queries the reorder buffer queue, it finds that the first window at the head of the queue, window 1, is empty. Therefore, according to the in-order delivery requirement, the delivery process starting with the MPDU with the smallest SN cannot begin. It must wait for the MPDU with SN=1 to be received and stored in window 1 before in-order delivery can begin.

[0191] S507 is executed after S502.

[0192] S507: The receiving end generates a block confirmation frame and feeds the block confirmation frame back to the transmitting end.

[0193] In this example, the block acknowledgment frame is used to instruct the transmitting end to resend the MPDU with SN=1.

[0194] S508: The transmitting end resends at least one MPDU according to the feedback of the block acknowledgment frame.

[0195] The method by which the transmitting end determines the retransmitted MPDU according to the block confirmation frame can refer to the above example and will not be described in detail. In this example, the transmitting end transmits the MPDU with SN=1 for the second time according to the instruction of the block confirmation frame and transmits it successfully.

[0196] S509. The receiving end receives at least one MPDU and queries the delivery scoreboard and the reordering buffer queue. Based on the delivery status of the MPDU corresponding to the sequence number recorded in the delivery scoreboard and whether the window of the MPDU corresponding to the sequence number in the reordering buffer queue is empty, it is determined whether the MPDU has arrived.

[0197] Referring to the example of Figure 10, at least one MPDU sent by the transmitter for the second time is an MPDU with SN=1. After the receiver receives the MPDU with SN=1, based on the scoreboard window 1 corresponding to the MPDU with SN=1 in the delivery scoreboard, which is 0, and the window 1 corresponding to the MPDU with SN=1 in the reordering cache queue is empty, the receiver jointly determines that the MPDU with SN=1 has not arrived, that is, it has arrived for the first time, and based on the indication information carried by the MPDU with SN=1, it is determined that it is an MPDU that needs to be delivered in order. The MPDU with SN=1 is stored in window 1 of the reordering cache queue, and the reordering cache queue is refreshed. After the reordering cache queue is refreshed, window 1, window 4, and window 5 are non-empty, and window 2 and window 3 are empty. The delivery status of the delivery scoreboard is: the value of the scoreboard window 2 of SN=2 and the scoreboard window 3 of SN=3 is 1, and the others are still 0. The receiving end can determine that MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5 have all arrived. Although the MPDUs with SN=2 and SN=3 in the reordering buffer queue corresponding to windows 2 and 3 are empty, the delivery scoreboard shows that MPDUs with SN=2 and SN=3 have been delivered, indicating that MPDUs with SN=2 and SN=3 have arrived. Therefore, it can be considered that the consecutive SNs in the order-preserving delivery have been collected, and the delivery of MPDUs in windows 4 and 5 is not affected. The receiving end can deliver the MPDUs with SN=1, SN=4, and SN=5 according to the order-preserving delivery requirements.

[0198] Optionally, when delivering the MPDUs delivered in sequence, the receiving end may wait for the first MPDU delivered in sequence to be stored in the reordering buffer queue and then deliver them together. The method of delivering together may refer to the example of S308 and will not be elaborated on herein.

[0199] Optionally, when the receiving end determines that the received MPDU with SN=1 is the first MPDU to be delivered in order, it can immediately deliver the MPDU with SN=1 and refresh the reordering buffer queue and delivery scoreboard. If the MPDUs with SN=2 and SN=3 have been delivered in a non-order-preserving manner, the refreshed reordering buffer queue will slide the window and slide the window 4 corresponding to the MPDU with SN=4 to the first window. Similarly, the window 5 corresponding to the MPDU with SN=5 will slide to the second window. Then, the MPDUs with SN=4 and SN=5 will be delivered together. This can reduce the delay of delivering the MPDUs in order.

[0200] After the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 are delivered, the delivery scoreboard and the reordering buffer queue are refreshed. The delivery scoreboard is refreshed as follows: the scoreboard window value corresponding to the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 is 1, and the others are still 0. The reordering buffer queue is refreshed as follows: the corresponding positions of the MPDUs of SN=1, SN=2, SN=3, SN=4 and SN=5 are empty, and the window of the reordering buffer queue slides, that is, the sixth window slides to the position of the first window, preparing for receiving the next data frame group.

[0201] The delivery method provided in the embodiments of the present application can jointly determine whether an MPDU has arrived through the delivery scoreboard and the reordering buffer queue. This method can utilize the existing delivery status of the delivery scoreboard and the cache status of whether the window in the reordering buffer queue is empty to jointly determine the arrival of the MPDU, thereby avoiding repeated delivery of the MPDU. This method can also add the delivery status of the delivery scoreboard to jointly determine the arrival of the MPDU based on the logic of whether the reordering buffer queue is empty in the 802.11 protocol. This is equivalent to making minor modifications to the current delivery method, effectively avoiding repeated delivery and ensuring low latency for order-preserving delivery during mixed delivery. Therefore, the cost of delivery using this method can be effectively reduced.

[0202] Optionally, in the scenario provided by the embodiment of the present application where the arrival of the MPDU is determined based on the delivery scoreboard, the delivery status, and the cache status in the reordering buffer queue, the receiving end may also maintain a block confirmation scoreboard. The block confirmation scoreboard is refreshed after each MPDU arrives, recording the arrival status of each MPDU. The block confirmation scoreboard is mainly used to generate a block confirmation frame and feedback the reception status of the MPDU to the sending end. In this scenario, assuming that the sending end first sends MPDUs with SN=1, SN=2, SN=3, SN=4, and SN=5, but the MPDU with SN=1 is lost, then after the receiving end correctly receives the MPDUs with SN=2, SN=3, SN=4, and SN=5, it refreshes the block confirmation scoreboard and records that the MPDU with SN=1 has not arrived and the MPDUs with SN=2, SN=3, SN=4, and SN=5 have arrived. Refer to the examples of in-order delivery, non-order delivery, or mixed delivery in Figures 8-10. The reordering buffer queue is refreshed each time an MPDU is stored, and the submission scoreboard is refreshed each time an MPDU is submitted. At this time, the MPDU with SN=1 has not reached the receiving end, so it is naturally not stored in the reordering buffer queue, let alone submitted. The MPDU with SN=2 and the MPDU with SN=3 are non-sequence-preserving submission MPDUs and will not be stored in the reordering buffer queue and will be submitted directly. The MPDU with SN=4 and the MPDU with SN=5 are sequence-preserving submission MPDUs, which are stored in the reordering buffer queue and temporarily not submitted. At this time, the submission scoreboard records that the MPDU with SN=1 is not submitted, the MPDU with SN=2 is submitted, the MPDU with SN=3 is submitted, the MPDU with SN=4 is not submitted, and the MPDU with SN=5 is not submitted.

[0203] The sender retransmits the MPDU with SN=1 for the second time. After the receiver correctly receives the MPDU with SN=1, it updates the block acknowledgement scoreboard and records the arrival of the MPDU with SN=1. The receiver does not perform operations on the MPDU with SN=1 based on the block acknowledgement scoreboard. Instead, it uses the delivery status recorded in the delivery scoreboard and the buffer status in the reordering buffer queue (i.e., the MPDU with SN=1 is empty and the MPDUs with SN=4 and SN=5 are buffered (i.e., not empty) to determine that the MPDU with SN=1 has not been delivered, that the MPDUs with SN=2 and SN=3 have been delivered, and that the MPDUs with SN=4 and SN=5 have not been delivered but are buffered. It then performs in-order delivery on the MPDUs with SN=1, SN=4, and SN=5, and then updates the delivery scoreboard, recording that the MPDUs with SN=1, SN=4, and SN=5 have been delivered.

[0204] In this scenario, the block confirmation scoreboard is mainly used to record the arrival status of the MPDU of each SN.

[0205] The method involved in the above embodiment can be applied to a data frame delivery device, which can be a communication device serving as a Non-AP site (logical function). The communication device can be a terminal or a communication module in the terminal, or a circuit or chip responsible for the communication function (such as a modem chip, also known as a baseband chip, or a system on chip (SoC) chip or system in package (SIP) chip containing a modem core).

[0206] The data frame delivery device may also be a communication device serving as an access point AP (logical function), which may be an AP device or a communication module in an AP device, or a circuit or chip responsible for the communication function (such as a modem chip, also known as a baseband chip, or a system on chip (SoC) chip or a system in package (SIP) chip containing a modem core).

[0207] An embodiment of the present application provides a data frame delivery device. Figure 12 is one of the structural schematic diagrams of a first device provided by an embodiment of the present application. The first device 10 includes at least one control module, and each control module is coupled to each other. As shown in Figure 12, the control module includes a block confirmation scoreboard control module 101 and a reordering cache queue control module 102.

[0208] The block acknowledgment scoreboard control module 101 is configured to refresh the arrival status of data frames corresponding to sequence numbers recorded in the block acknowledgment scoreboard. For example, refreshing is performed each time a data frame is received, including refreshing after a non-sequence-preserving data frame, such as an MPDU, is delivered, and refreshing after a sequence-preserving data frame, such as an MPDU, is stored in a reordering buffer queue. Optionally, the block acknowledgment scoreboard control module 101 can refresh the block acknowledgment scoreboard with reference to the examples in S101 to S103, S201 to S207, and S301 to S308.

[0209] The reordering buffer queue control module 102 is configured to determine whether each data frame in at least one data frame with a sequence number has arrived according to the arrival status of the data frame corresponding to the sequence number recorded in the block confirmation scoreboard.

[0210] The reordering buffer queue control module 102 is configured to perform a delivery operation on the first data frame whose arrival status is recorded in the block confirmation scoreboard as having not arrived after the first data frame with the corresponding sequence number arrives.

[0211] In a possible implementation, the reordering buffer queue control module 102 is further configured to discard the second data frame whose arrival status is recorded in the block confirmation scoreboard as having arrived after the second data frame with the corresponding sequence number arrives again.

[0212] The first device can be applied to the delivery method shown in the examples of S101 to S103, S201 to S207, S301 to S308 shown in Figures 2 to 7. The first device may also include a transceiver module, which is mainly used to receive data frames of multiple different SNs sent by the transmitter, such as MPDUs. After receiving the MPDU, the reordering cache queue control module 102 queries the block confirmation scoreboard to determine whether the MPDU received for each SN is an MPDU that has arrived. If it has arrived, it is discarded. If it has not arrived, that is, it arrives for the first time, it is determined according to the above example whether it is an MPDU delivered in sequence or an MPDU delivered out of sequence, and then the MPDU delivered in sequence is stored in the reordering cache queue, or the MPDU delivered out of sequence is delivered immediately. The reordering buffer queue control module 102 controls a refresh of the reordering buffer queue each time an in-order MPDU is stored. Optionally, the refresh of the reordering buffer queue control module 102 may refer to the examples of S201 to S207 and S301 to S308. The block confirmation scoreboard control module 101 controls a refresh of the block confirmation scoreboard each time an MPDU is delivered or an in-order MPDU is stored in the reordering buffer queue. The arrival status recorded after the refresh may refer to the examples of Figures 2 to 7 and will not be further described.

[0213] In one possible implementation, the reordering buffer queue control module 102 is specifically configured to, after the transceiver module receives the first data frame with the corresponding sequence number, determine that the first data frame is a data frame for pre-sequence delivery and store the first data frame in the reordering buffer queue; and after the first data frame for pre-sequence delivery is stored in the reordering buffer queue, deliver the first data frame together with the first data frame. The specific delivery method can be referred to the examples of S301 to S308.

[0214] In one possible implementation, the reordering buffer queue control module 102 is specifically configured to, after the transceiver module receives the first data frame with a corresponding sequence number, determine that the first data frame is a data frame to be delivered in order, and store the first data frame in the reordering buffer queue; after waiting for each data frame with a smaller sequence number than the first data frame, including the first data frame, to be stored in the reordering buffer queue, deliver the first data frame together with the preceding data frame, wherein the aforementioned data frames include the first data frame and each data frame with a smaller sequence number than the first data frame. The specific delivery method can be referred to in the examples of S301 to S308.

[0215] In a possible implementation, the reordering buffer queue control module 102 is specifically configured to refresh the reordering buffer queue after the first data frame is delivered together with the first data frame. The buffer queue window sliding may refer to the above example.

[0216] In one possible implementation, the reordering buffer queue control module 102 is specifically configured to, after the transceiver module receives the first data frame with the corresponding sequence number, determine that the first data frame is the first data frame to be delivered in-order, deliver the first data frame, and flush the reordering buffer queue. For example, if the receiving end determines that the received MPDU with SN=1 is the first MPDU to be delivered in-order, it can immediately deliver the MPDU with SN=1 and flush the reordering buffer queue, further reducing the latency of delivering MPDUs in-order.

[0217] In one possible implementation, after receiving the first data frame with the corresponding sequence number, the first data frame is determined to be a non-sequence-preserving delivery data frame, and the first data frame is delivered immediately. Specific delivery methods can refer to the examples of S201 to S207.

[0218] In a possible implementation, the block confirmation scoreboard control module 101 is further configured to update the arrival status corresponding to the first data frame in the block confirmation scoreboard to "arrived" after the first data frame is successfully delivered.

[0219] When the first device receives a data frame, the block acknowledgment scoreboard control module 101 is also responsible for generating and sending a block acknowledgment frame. This frame has a high latency requirement, such as requiring feedback within 16 microseconds. Therefore, the block acknowledgment scoreboard control module 101 that generates and sends the block acknowledgment frame is typically implemented in hardware. The reordering buffer queue control module, on the other hand, performs operations with relatively relaxed latency requirements and can be implemented in both software and hardware.

[0220] Therefore, the first device can be implemented in the following ways:

[0221] As an example, FIG13 is a second structural diagram of a first device provided by an embodiment of the present application. As shown in FIG13 , the block confirmation scoreboard control module 101 in the first device 10 is a hardware module, and the reordering cache queue control module 102 is also a hardware module. For example, the block confirmation scoreboard control module 101 can be a chip manufactured according to different standards (including), such as a hardware module in an 802.11 chip, and the reordering cache queue control module 102 can be another hardware module in the 802.11 chip. Alternatively, the block confirmation scoreboard control module 101 and the reordering cache queue control module 102 are integrated into a hardware module in an 802.11 chip, and so on.

[0222] As an example, FIG14 is a third structural diagram of a first device provided in an embodiment of the present application. As shown in FIG14, the first device 20 includes a first confirmation scoreboard control module 201, a second confirmation scoreboard control module 202, and a reordering cache queue control module 203. Since the reordering cache queue control operation of the reordering cache queue control module can be implemented in software, but the latency requirement for block confirmation frames is high, it needs to be implemented in hardware to minimize latency. Therefore, in this embodiment of the present application, the control operation of the confirmation scoreboard control module 202 is divided into two parts: the first confirmation scoreboard control module 201 is used to generate and send block confirmation frames, and the second confirmation scoreboard control module 202 is used to write and read the block confirmation scoreboard, that is, to refresh the arrival status of the record and provide the reordering cache queue control module 203 with the arrival status of the data frame to be queried. Referring to FIG14, the first confirmation scoreboard control module 201 is a hardware module, and the second confirmation scoreboard control module 202 and the reordering cache queue control module 203 are software modules that can run on a CPU. In this case, the first confirmation scoreboard control module 201 can be integrated with the software modules, namely the second confirmation scoreboard control module 202 and the reordering cache queue control module 203, into a single chip, or they can be separately provided in two chips. Referring to the delivery method in the above example, the data frame delivery is completed interactively. Referring to the above embodiment, the second confirmation scoreboard control module 202 and the reordering cache queue control module 203 interact at the software level to complete the data frame delivery, while avoiding the bottleneck of the software-generated block confirmation frame speed, which affects the speed of block confirmation frame generation and feedback.

[0223] It should be understood that the modules shown in Figures 12 to 14 are only examples, and each module can perform its operation with reference to the method part in the embodiment of the present application, or perform a variation of its operation. In the example provided in the embodiment of the present application, the block confirmation scoreboard control module (or the first block confirmation scoreboard control module and the second block confirmation scoreboard control module). It is mainly responsible for recording the arrival of the block confirmation scoreboard and replying the block confirmation frame to the sending end; the reordering cache queue control module is mainly responsible for MPDU delivery, deduplication, and reordering of sequence-preserving service MPDUs. In actual applications, these modules can also perform other operations and are not limited to the examples in the embodiment of the present application.

[0224] An embodiment of the present application provides another data frame delivery device. Figure 15 is one of the structural schematic diagrams of a second device provided by an embodiment of the present application. The second device 30 includes at least one control module, and each control module is coupled to each other. As shown in Figure 15, the control module includes a delivery scoreboard control module 301 and a reordering cache queue control module 302.

[0225] The submission scoreboard control module 301 is used to control the submission scoreboard to record the submission status of the data frame corresponding to the sequence number.

[0226] The reordering buffer queue control module 302 is used to control the reordering buffer queue, which is used to buffer data frames corresponding to sequence numbers.

[0227] The reordering cache queue control module 302 is further configured to determine whether each data frame in at least one data frame with a sequence number has arrived based on the cache status of the window of the data frame corresponding to the sequence number in the reordering cache queue and the delivery status of the data frame corresponding to the sequence number recorded in the delivery scoreboard; and for the first data frame whose arrival status is determined by the delivery scoreboard and the reordering cache queue to be not arrived, perform a delivery operation on it after the first data frame with the corresponding sequence number arrives.

[0228] In a possible implementation, the reordering buffer queue control module 302 is further configured to determine, based on the submission scoreboard and the reordering buffer queue, that the second data frame has arrived, and discard the second data frame with the corresponding sequence number after it arrives again.

[0229] The second device can be applied to the delivery method shown in the examples such as S401 to S402, S501 to S508 shown in Figures 8 to 11. The second device may also include a transceiver module, which is mainly used to receive data frames of multiple different SNs sent by the transmitter, such as MPDUs. After receiving the MPDU, the reordering cache queue control module 302 queries the delivery scoreboard and the reordering cache queue to determine whether the MPDU received for each SN is an MPDU that has arrived. For example, if the value of the window corresponding to the MPDU of an SN in the delivery scoreboard is 0, and the window corresponding to the MPDU of the SN in the reordering cache queue is empty, it can be determined that the MPDU of this SN has not arrived; otherwise, it is determined that the MPDU has arrived. If it is determined that it is an MPDU that has arrived, it is discarded. If it is determined that it is an MPDU that has not arrived, that is, an MPDU that arrives for the first time, then according to the above example, it is determined whether it is an MPDU delivered in order or an MPDU delivered out of order. If it is delivered in order, the MPDU is stored in the reordering cache queue. If it is delivered out of order, it is delivered immediately. After each delivery, the delivery scoreboard control module 301 controls the refresh of the delivery scoreboard once. The reordering cache queue control module 302 controls the refresh of the reordering cache queue once after each storage of the MPDU delivered in order, and controls the refresh of the reordering cache queue once after the MPDU in the reordering cache queue is delivered. Optionally, the refresh of the delivery scoreboard control module 301 and the reordering cache queue control module 302 can refer to the examples of S501 to S508 and the examples of reference Figures 8 to 11, and will not be repeated here.

[0230] In one possible implementation, the reordering cache queue control module 302 is specifically used to determine that the first data frame is an order-preserving delivery data frame after the receiving module receives the first data frame of the corresponding sequence number, and store the first data frame in the reordering cache queue; after waiting for the first data frame of order-preserving delivery to be stored in the reordering cache queue, the first data frame is delivered together with the first data frame according to the reordering cache queue and the delivery scoreboard.

[0231] In one possible implementation, the reordering cache queue control module 302 is specifically used to determine that the first data frame is an order-preserving delivery data frame after the receiving module receives the first data frame with the corresponding sequence number, and store the first data frame in the reordering cache queue; if at least one data frame with a smaller sequence number than the first data frame has completed delivery, the reordering cache queue is refreshed, and the delivery status corresponding to at least one data frame in the delivery scoreboard is updated to delivered; after waiting for each order-preserving delivery data frame with a smaller sequence number than the first data frame, including the first data frame, to be stored in the reordering cache queue, the first data frame is delivered together with the preceding data frame, and the preceding data frame includes the first data frame and each order-preserving delivery data frame with a smaller sequence number than the first data frame.

[0232] In a possible implementation, after the first data frame is submitted together with the first data frame, the reordering buffer queue control module 302 refreshes the reordering buffer queue, and the submission scoreboard control module 301 refreshes the submission scoreboard.

[0233] In one possible implementation, after the transceiver module receives the first data frame with the corresponding sequence number, the reordering cache queue control module 302 determines that the first data frame is the first data frame to be delivered in order; delivers the first data frame, refreshes the reordering cache queue, and delivers the scoreboard control module 301.

[0234] In the above possible implementations, the specific submission method, the method of refreshing the reordering cache queue, and the method of refreshing the submission scoreboard may refer to the examples of S301 to S308.

[0235] In one possible implementation, after receiving the first data frame with the corresponding sequence number, the first data frame is determined to be a non-sequence-preserving delivery data frame and is immediately delivered. For example, the non-sequence-preserving delivery MPDU delivery method shown in FIG8 to FIG11 is provided.

[0236] In one possible implementation, the submission scoreboard control module 301 is further configured to update the submission status corresponding to the first data frame in the submission scoreboard to submitted after the reordering cache queue control module 302 successfully submits the first data frame, and the reordering cache queue control module 302 updates the cache status corresponding to the first data frame in the reordering cache queue to empty.

[0237] The submission scoreboard control module 301 and the reordering cache queue control module 302 in the second device 30 can both be implemented by software or hardware. For example, the submission scoreboard control module 301 can be a hardware module, and the reordering cache queue control module 302 can also be a hardware module. For example, the submission scoreboard control module 301 can be a chip manufactured according to different standards (including), such as a hardware module in an 802.11 chip, and the reordering cache queue control module 302 can be another hardware module in the 802.11 chip. Alternatively, the submission scoreboard control module 301 and the reordering cache queue control module 302 are integrated into a hardware module in an 802.11 chip. Alternatively, both the submission scoreboard control module 301 and the reordering cache queue control module 302 are software modules that can run on a CPU. Alternatively, one of the submission scoreboard control module 301 and the reordering cache queue control module 302 is a software module, and the other is a hardware module.

[0238] It should be understood that the modules shown in FIG15 are merely examples, and each module may perform its operations, or variations thereof, with reference to the method sections in the embodiments of the present application. The functions implemented by the modules shown in FIG15 are also examples. In one possible implementation, after the second device 30 receives a data frame, the delivery scoreboard control module 301 may deliver the data frame based on whether the data frame has not arrived, or discard the data frame based on whether the data frame has arrived, etc., without being limited to the above examples.

[0239] Furthermore, when the second device receives a data frame, it is also necessary to maintain a block confirmation scoreboard control module for generating and sending block confirmation frames. The delay requirement of the block confirmation frame is relatively high. Therefore, as shown in Figure 16, the second device 30 also includes a block confirmation scoreboard control module 303 for generating and sending block confirmation frames, which is implemented using hardware. The submission scoreboard control module 301 and the reordering cache queue control module 302 can both be implemented through software or hardware.

[0240] Optionally, the block confirmation scoreboard control module 303 may further control the block confirmation scoreboard to record the arrival status when each data frame corresponding to the sequence number arrives. This control function may be implemented through software or hardware.

[0241] Figure 17 is a structural diagram of a system for submitting data frames provided in an embodiment of the present application. The submission method provided in an embodiment of the present application can be applied in the scenario of the system. The system includes a transmitter 40 and a receiver 50, wherein the transmitter 40 and the receiver 50 are both devices that support IEEE 802.11be / Wi-Fi 7 / EHT protocol, IEEE 802.11bn / UHR / Wi-Fi 8 protocol, and IEEE 802.15 / UWB protocol. For example, the transmitter 40 can be a communication device serving as an access point (AP) site (logical function), and the communication device can be a terminal or a communication module in the terminal, or a circuit or chip responsible for the communication function (such as a modem chip, also known as a baseband chip, or a system on chip (SoC) chip or a system in package (SIP) chip containing a modem core).

[0242] The receiving end 50 can be a communication device serving as a Non-AP site (logical function), which can be a terminal or a communication module in the terminal, or a circuit or chip responsible for the communication function (such as a modem chip, also known as a baseband chip, or a system on chip (SoC) chip or system in package (SIP chip) containing a modem core).

[0243] The transmitter 40 is mainly used to generate a SN for each transmitted data frame, such as an MPDU, according to the order in which the services are generated, such as generating an incremental SN. It is also responsible for transmitting the MPDU and retransmitting the MPDU that failed to be transmitted based on the block confirmation frame.

[0244] The receiving end 50 is primarily responsible for determining whether to deliver an MPDU based on whether it has already arrived. It is also responsible for reading and writing (i.e., querying and refreshing) the block confirmation scoreboard's arrival status, controlling the reordering buffer queue's reordering of in-order service MPDUs, and reading and writing the delivery status of the delivery scoreboard. For details, see the examples in Figures 1 to 16 above to implement MPDU delivery.

[0245] In addition, as shown in Figure 18, Figure 18 is a schematic diagram of the structure of a device 60 according to an embodiment of the present application. The device 60 shown in Figure 18 includes a transceiver unit 601 and a processing unit 602. The device 60 can be used to perform methods S101 to S103, S201 to S207, S301 to S310, S401 to S402, or S501 to S509 in the above embodiments. When the device 60 is used to perform methods S101 to S103, S201 to S207, or S301 to S310 in the above embodiments, it is equivalent to the first device exemplified in the method. When the device 60 is used to perform methods S401 to S402, or S501 to S509 in the above embodiments, it is equivalent to the second device exemplified in the method.

[0246] It should be noted that the division of units in the embodiments of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation. The functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. For example, in the above embodiment, the device 60 includes a transceiver unit 601 and a processing unit 602, which can be the same unit or different units; the device 60 includes a transceiver unit 601 and a processing unit 602, which can be the same unit or different units. The above-mentioned integrated units can be implemented in the form of hardware, such as a chip, or in the form of software functional units.

[0247] In addition, an embodiment of the present application further provides a communication device 70, as shown in FIG19 , which is a schematic structural diagram of the communication device 70 according to an embodiment of the present application. The communication device 70 includes a storage medium 701 and a processor 702 connected to the storage medium 701. The storage medium 701 can buffer data frames, such as MPDUs. The processor 702 can be used to perform the various operations of the methods in the above embodiments.

[0248] In addition, an embodiment of the present application further provides a device 80, as shown in FIG20 , which is a schematic diagram of the structure of a device 80 provided in an embodiment of the present application. As shown in FIG20 , the device 80 may include a processor 801, a memory 802 coupled to the processor 801, and a transceiver 803. The transceiver 803 may be a communication interface, an optical module, etc., and is used to receive messages or data information. The processor 801 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and a NP, and is used to perform the forwarding processing steps in the device exemplified in the above embodiment. The processor may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 801 may be a single processor or may include multiple processors. The memory 802 may include a volatile memory, such as a random-access memory (RAM); the memory may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); the memory 802 may also include a combination of the above types of memory. The memory 802 may refer to a single memory or may include multiple memories for storing program instructions. In one embodiment, the memory 802 stores computer-readable instructions, which include multiple software modules, such as a sending module, a processing module, and a receiving module. After executing each software module, the processor 801 may perform corresponding operations according to the instructions of each software module. In this embodiment, the operation performed by a software module actually refers to the operation performed by the processor 801 according to the instructions of the software module. Optionally, the processor 801 may also store program codes or instructions for executing the embodiments of the present application. In this case, the processor 801 does not need to read the program codes or instructions from the memory 802.

[0249] The device 80 can be used to execute the method in the above embodiment. Specifically, the device 80 can execute the operations performed by the receiving end in methods S101 to S103, S201 to S207, S301 to S310, S401 to S402, or S501 to S509.

[0250] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is executed on a processor, it implements part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0251] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed on a processor, implements part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0252] The present application also provides a chip including an interface circuit and a processor connected to each other, wherein the processor is configured to cause the chip to execute part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0253] An embodiment of the present application also provides a chip system, including: a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, when the program or instructions are executed by the processor, the chip system implements part or all of the operations of any one of the methods of any one of the embodiments described above.

[0254] Optionally, there may be one or more processors in the chip system. The processor may be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.

[0255] Optionally, the memory in the chip system may be one or more. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in the embodiments of the present application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on different chips. The embodiments of the present application do not specifically limit the type of memory or the configuration of the memory and the processor.

[0256] Exemplarily, the chip system can be an FPGA, an ASIC, a system on chip (SoC), a CPU, an NP, a digital signal processing circuit (DSP), a microcontroller (MCU), a programmable logic device (PLD), or other integrated chips.

[0257] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0258] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical business division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0260] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0261] In addition, each business unit in each embodiment of the present application can be integrated into a processing unit, each unit can exist physically separately, or two or more units can be integrated into a single unit. The above-mentioned integrated units can be implemented in the form of hardware or software business units.

[0262] If the integrated unit is implemented in the form of a software business unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the present application can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, Random Access Memory, disk or optical disk, etc. Various media that can store program code.

[0263] Those skilled in the art will appreciate that, in one or more of the examples above, the services described herein may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one location to another. Storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0264] The above specific implementation methods further describe in detail the purpose, technical solutions and beneficial effects of this application. It should be understood that the above are only specific implementation methods of this application.

[0265] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for submitting a data frame, characterized in that: include: Determine whether each data frame in at least one data frame with a sequence number has arrived according to the arrival status of the data frame corresponding to the sequence number recorded in the block confirmation scoreboard; For the first data frame whose arrival status is recorded in the block confirmation scoreboard and has not arrived, a delivery operation is performed on the first data frame with a corresponding sequence number after the frame arrives.

2. The method for submitting a data frame according to claim 1, characterized in that: The method further comprises: for the second data frame whose arrival status is recorded in the block confirmation scoreboard as having arrived, after the second data frame with the corresponding sequence number arrives again, discarding it.

3. The method for submitting a data frame according to claim 1 or 2, characterized in that: The arrival status of the block confirmation scoreboard record is the first data frame that has not arrived, and after the first data frame with a corresponding sequence number arrives, a delivery operation is performed on it, including: After receiving the first data frame with the corresponding sequence number, determining that the first data frame is an order-preserving delivery data frame, and storing the first data frame in a reordering buffer queue; After the first data frame waiting for order-preserving delivery is stored in the reordering buffer queue, the first data frame is delivered together with the first data frame.

4. The method for submitting a data frame according to claim 1 or 2, characterized in that: The arrival status of the block confirmation scoreboard record is the first data frame that has not arrived, and after the first data frame with a corresponding sequence number arrives, a delivery operation is performed on it, including: After receiving the first data frame with the corresponding sequence number, determining that the first data frame is an order-preserving delivery data frame, and storing the first data frame in a reordering buffer queue; After waiting for each data frame including the first data frame and having a smaller sequence number than the first data frame to be stored in the reordering cache queue, the first data frame is submitted together with the preceding data frame, wherein the preceding data frames include the first data frame and each data frame having a smaller sequence number than the first data frame.

5. The method for submitting a data frame according to claim 3 or 4, characterized in that: After the first data frame is submitted together with the first data frame, the reordering buffer queue is refreshed.

6. The method for submitting a data frame according to any one of claims 1 to 5, characterized in that: The arrival status of the block confirmation scoreboard record is the first data frame that has not arrived, and after the first data frame with a corresponding sequence number arrives, a delivery operation is performed on it, including: After receiving the first data frame of the corresponding sequence number, determining that the first data frame is the first data frame delivered in order; The first data frame is delivered, and the reordering buffer queue is refreshed.

7. The method for submitting a data frame according to claim 1 or 2, characterized in that: The arrival status of the block confirmation scoreboard record is the first data frame that has not arrived, and after the first data frame with a corresponding sequence number arrives, a delivery operation is performed on it, including: After receiving the first data frame with the corresponding sequence number, it is determined that the first data frame is a non-sequence-preserving delivery data frame, and the first data frame is delivered immediately.

8. The method for submitting a data frame according to any one of claims 1 to 7, characterized in that: The method further comprises: After the first data frame is successfully submitted, the arrival status corresponding to the first data frame in the block confirmation scoreboard is updated to arrived.

9. A method for submitting a data frame, characterized in that: include: Determine whether each data frame in at least one data frame with a sequence number has arrived according to the cache status of the window of the data frame corresponding to the sequence number in the reordering cache queue and the delivery status of the data frame corresponding to the sequence number recorded in the delivery scoreboard; The delivery scoreboard and the reordering buffer queue determine that the arrival status is a first data frame that has not arrived, and after the first data frame with a corresponding sequence number arrives, a delivery operation is performed on it.

10. The method for submitting a data frame according to claim 9, characterized in that: The method further includes: determining, with respect to the submission scoreboard and the reordering cache queue, that the second data frame has arrived, and discarding the second data frame with the corresponding sequence number after it arrives again.

11. The method for submitting a data frame according to claim 9 or 10, characterized in that: The step of determining, for the delivery scoreboard and the reordering cache queue, that the first data frame has not arrived before, and performing a delivery operation on the first data frame with a corresponding sequence number after the first data frame arrives, comprises: After receiving the first data frame with the corresponding sequence number, determining that the first data frame is an order-preserving delivery data frame, and storing the first data frame in the reordering buffer queue; After the first data frame waiting for order-preserving delivery is stored in the reordering buffer queue, the first data frame is delivered together with the first data frame.

12. The method for submitting a data frame according to claim 9 or 10, characterized in that: The step of determining, for the delivery scoreboard and the reordering cache queue, that the first data frame has not arrived before, and performing a delivery operation on the first data frame with a corresponding sequence number after the first data frame arrives, comprises: After receiving the first data frame with the corresponding sequence number, determining that the first data frame is an order-preserving delivery data frame, and storing the first data frame in the reordering buffer queue; If at least one data frame with a smaller sequence number than the first data frame has completed delivery, the reordering cache queue is refreshed, and the delivery status corresponding to the at least one data frame in the delivery scoreboard is updated to delivered; After waiting for each data frame submitted in an order-preserving manner, including the first data frame, whose sequence number is smaller than that of the first data frame, to be stored in the reordering cache queue, the first data frame is submitted together with the preceding data frame, wherein the preceding data frame includes the first data frame and each data frame submitted in an order-preserving manner, whose sequence number is smaller than that of the first data frame.

13. The method for submitting a data frame according to claim 11 or 12, characterized in that: After the first data frame is submitted together with the first data frame, the reordering buffer queue and the submission scoreboard are refreshed.

14. The method for submitting a data frame according to any one of claims 9 to 13, characterized in that: The step of determining, for the delivery scoreboard and the reordering cache queue, that the first data frame has not arrived before, and performing a delivery operation on the first data frame with a corresponding sequence number after the first data frame arrives, comprises: After receiving the first data frame of the corresponding sequence number, determining that the first data frame is the first data frame delivered in order; The first data frame is submitted, and the reordering buffer queue and the submission scoreboard are refreshed.

15. The method for submitting a data frame according to claim 9 or 10, characterized in that: The step of determining, for the delivery scoreboard and the reordering cache queue, that the first data frame has not arrived before, and performing a delivery operation on the first data frame with a corresponding sequence number after the first data frame arrives, comprises: After receiving the first data frame with the corresponding sequence number, it is determined that the first data frame is a non-sequence-preserving delivery data frame, and the first data frame is delivered immediately.

16. The method for submitting a data frame according to any one of claims 9 to 15, characterized in that: The method further comprises: After the first data frame is successfully submitted, the submission status corresponding to the first data frame in the submission scoreboard is updated to submitted, and the cache status corresponding to the first data frame in the reordering cache queue is updated to empty.

17. A first device, comprising at least one control module, wherein the at least one control module comprises a coupled block confirmation scoreboard control module and a reorder buffer queue control module, characterized in that: The at least one control module implements the method according to any one of claims 1 to 8.

18. A second device, comprising at least one control module and a transceiver module, wherein the at least one control module comprises a coupled block confirmation scoreboard control module and a reordering buffer queue control module, characterized in that: The at least one control module implements the method according to any one of claims 9 to 16.

19. A communication device, characterized in that: The communication device includes a processor and a storage medium, wherein the storage medium stores instructions, and when the instructions are executed by the processor, the method according to any one of claims 1 to 8 is implemented, or the method according to any one of claims 9 to 16 is implemented.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises instructions, which, when executed by a processor, enable the method according to any one of claims 1 to 8 to be implemented, or enable the method according to any one of claims 9 to 16 to be implemented.

21. A computer program product, characterized in that The computer program product comprises instructions, which, when executed by a processor, enable the method according to any one of claims 1 to 8 to be implemented, or enable the method according to any one of claims 9 to 16 to be implemented.

Images