Enhanced quality of service status reporting to support latency requirements

Abstract

A protocol extension of IEEE 802.11 that handles buffer status reporting (BSR) to provide real-time information about Quality of Service (QoS) requirements. By reporting the QoS status of some of its buffers, non-AP STAs can enable the AP to schedule the transmission of these buffers to meet the QoS requirements. Non-AP STAs can also change the parameters of existing SCS QoS characteristic elements so that the AP can immediately schedule the transmission of SCS traffic with the new parameters. Non-AP STAs can also report on upcoming buffers so that the AP can trigger transmission before the arrival of these buffers. It also provides additional benefits.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 374,658, filed September 6, 2022, which is incorporated herein by reference in its entirety. This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 375,831, filed September 15, 2022, which is incorporated herein by reference in its entirety.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT Not applicable

[0003] Notification of copyrighted material Portions of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner has no objection to the reproduction by any third party of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office publicly available files or records, but otherwise reserves all copyright rights. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including, but not limited to, the right pursuant to 37 CFR § 1.14.

[0004] The techniques of this disclosure relate generally to wireless networks, and more particularly to enhanced buffer status reporting for real-time application (RTA) traffic. [Background technology]

[0005] The current IEEE 802.11 protocol (ie, 802.11be) allows an AP to collect buffer status information from non-AP STAs using a Buffer Status Report (BSR) mechanism. Summary of the Invention [Problem to be solved by the invention]

[0006] However, current buffer status reporting (BSR) mechanisms cannot provide real-time information of QoS requirements, thus leading to inefficient resource allocation, especially for the transmission of real-time application (RTA) traffic whose delivery time according to QoS requirements may expire.

[0007] Therefore, there is a need for a means to more efficiently support RTA traffic when using BSR. The present disclosure meets these needs and provides further advantages over existing systems. [Means for solving the problem]

[0008] A wireless communication device, method, and protocol enables transmission of frames between the medium access control (MAC) layer of an IEEE 802.11 network, where a station (STA) using carrier sense multiple access with collision avoidance (CSMA / CA) for channel contention transmits physical layer protocol data units (PPDUs) between the physical (PHY) layer of the IEEE 802.11 network. A non-access point (non-AP) STA can transmit an enhanced quality of service (QoS) status report (QSR) to an AP, indicating the latency requirements of a certain amount (a certain portion, such as a block) of buffered traffic. The AP schedules trigger-based (TB) transmissions of the buffered traffic in the QSR to meet the latency requirements of the buffered traffic. The QSR carries traffic identification information, such as the access class (AC), traffic identifier (TID), and stream classification service ID (SCSID), of the buffered traffic.

[0009] Further aspects of the technology described herein will become apparent in the remainder of this specification, and this detailed description is intended to fully disclose preferred embodiments of the technology without limiting them.

[0010] The techniques described herein will be better understood by reference to the following drawings, which are for illustrative purposes only. [Brief explanation of the drawings]

[0011] [Figure 1] This is a Medium Access Control (MAC) frame format based on IEEE802.11. [Figure 2] This is the Buffer Status Report (BSR) control subfield. [Figure 3] FIG. 2 is a block diagram of communication station hardware in accordance with at least one embodiment of the present disclosure. [Figure 4] FIG. 1 is a block diagram of multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure. [Figure 5] FIG. 10 is a data field diagram of a control information subfield format within a QSR control subfield as part of Example 1, in accordance with at least one embodiment of the present disclosure. [Figure 6] FIG. 1 is a data field diagram of an Very High Throughput (EHT) MAC Capability Information field format in accordance with at least one embodiment of the present disclosure. [Figure 7] FIG. 1 is a communication diagram as Example 1-1 in which a QSR reports a buffer size of a TID along with an expiration date, according to at least one embodiment of the present disclosure. [Figure 8] FIG. 10 is a communication diagram as Example 1-2 in which a QSR reports a buffer size of a TID along with an expiration date, in accordance with at least one embodiment of the present disclosure. [Figure 9] FIG. 10 is a data field diagram of a control information subfield within a QSR control subfield as part of Example 2, in accordance with at least one embodiment of the present disclosure. [Figure 10] FIG. 2 is a communication diagram as Example 2-1 in which a QSR reports a buffer size for a TID associated with a QoS control subfield, in accordance with at least one embodiment of the present disclosure. [Figure 11]11 is a queue content diagram of the buffer status of TID5 of STA1 of FIG. 10 in accordance with at least one embodiment of the present disclosure. [Figure 12] FIG. 2 is a communication diagram as Example 2-2 in which a QSR reports a requested TXOP duration for a TID associated with a QoS control subfield, in accordance with at least one embodiment of the present disclosure. [Figure 13] FIG. 10 is a data field diagram as part of Example 3 in which a QSR modifies parameters of a QoS characteristic element of an existing SCS, in accordance with at least one embodiment of the present disclosure. [Figure 14] FIG. 10 is a data field diagram of a control information subfield within a QSR control subfield as part of Example 4, in accordance with at least one embodiment of the present disclosure. [Figure 15] FIG. 4 is a communication diagram as part of Example 4-1 in which AP scheduling TB PPDUs for buffers arriving in the near future follows the QSR status report of an existing SCS, in accordance with at least one embodiment of the present disclosure. [Figure 16] FIG. 10 is a data field diagram of a format as part of Example 5 in which a QSR reports expected transmissions during an R-TWT SP, in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1. Buffer Status Report Overview In the current IEEE 802.11be protocol, an AP can collect buffer status information from non-AP STAs by transmitting a Buffer Status Report Poll (BSRP) trigger frame to request a Buffer Status Report (BSR) from the non-AP STAs. After receiving the BSRP trigger frame, the non-AP STA must include one or more Quality of Service (QoS) Null frames containing a QoS Control field and a BSR Control subfield in a High Efficiency (HE) Trigger-Based (TB) Physical Layer Protocol Data Unit (PPDU). The BSR can be carried in the BSR Control subfield and the QoS Control field of the frame.

[0013] FIG. 1 shows the Medium Access Control (MAC) frame format, which includes Frame Control, Duration / ID, Address 1 to Address 3, Sequence Control, Address 4, QoS Control, HT Control, Frame Body, and finally, Frame Check Sequence (FCS).

[0014] The QoS Control field reports buffer status at the Access Category (AC) level and can be carried in QoS Data or QoS Null frames.

[0015] Figure 2 shows a Buffer Status Report (BSR) control subfield that reports the buffer status of a Transmission Identification (TID), which may be carried in a High Throughput (HT) control field in a QoS Data or QoS Null frame or a management frame. The BSR control subfield is shown to include the following subfields: Adjacent Channel Interference (ACI), Delta TID, ACI High, Scaling Factor, Queue Size High, and Queue Size All.

[0016] A non-AP STA can send an unsolicited BSR to the AP, in which the non-AP STA can aggregate one or more QoS data or QoS null frames carrying a QoS control field into an aggregated-MPDU (A-MPDU) to report buffer status for different TIDs.

[0017] The BSR Control subfield is used to contain information reporting the buffer status of one or more ACs. In the IEEE 802.11 MAC frame, the QoS Control field can be used to report the queue size and TXOP duration requested.

[0018] The contents of the different frame types and subtypes are shown in Table 1. The table indicates the applicable frame type and subtype, and the use of the specific bit settings for that type / subtype.

[0019] 2. Problem statement Current buffer status reporting (BSR) mechanisms cannot provide real-time information on QoS requirements, such as the expiration time of data in the buffer. This can lead to situations where an AP allocates resources to transmit traffic, especially real-time application (RTA) traffic, when the delivery time according to the QoS requirements has already expired, resulting in wasted communication resources.

[0020] For traffic with stringent latency requirements, the AP must immediately allocate resources for transmission, but current protocols may not even be aware of the existence of these latency requirements until the AP sends the BSRP.

[0021] 3. Contribution of this Disclosure Some of the main contributions of this disclosure are described below.

[0022] (A) The disclosed technology provides a mechanism that allows a non-AP STA to report the QoS status of a particular portion of a buffer so that the AP can schedule the transmission of the buffer to meet its QoS requirements.

[0023] (B) The disclosed technology provides a mechanism that allows a non-AP STA to modify parameters of existing stream classification service (SCS) QoS characteristic elements so that the AP can immediately schedule the transmission of SCS traffic containing the new parameters.

[0024] (C) The disclosed technology provides a mechanism for allowing non-AP STAs to report buffers with traffic arriving in the near future (e.g., the "expected trigger time" shown in FIG. 14) so ​​that the AP can begin triggering transmissions before the arrival of these buffers.

[0025] 4. Embodiment of HW communication 4.1. Communication Station (STA and MLD) Hardware FIG. 3 illustrates an example embodiment 10 of STA hardware configured to execute the protocol of the present disclosure. An external I / O connection 14 couples to an internal bus 16 of circuitry 12, on which a CPU 18 and memory (e.g., RAM) 20 are preferably connected for executing program(s) implementing the communications protocol. The host machine contains at least one modem 22 supporting communications, coupled to at least one RF module 24, 28, each connected to one or more antennas 29, 26a, 26b, 26c-26n. RF modules with multiple antennas (e.g., antenna arrays) enable beamforming during transmission and reception. In this manner, the STA can transmit signals using multiple sets of beam patterns.

[0026] The bus 14 can connect various devices, such as sensors and actuators, to the CPU. Executing on the processor 18 are instructions from memory 20 for executing programs that implement communication protocols that are executed to enable the STAs to perform the functions of an Access Point (AP) station or a regular station (non-AP STA). It should also be understood that this programming is configured to operate in different modes (TXOP owner, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, AP in OBSS, STA in OBSS, etc.) depending on what role it plays in the current communication protocol and situation.

[0027] Thus, the illustrated STA HW comprises at least one modem and associated RF circuitry for providing communications on at least one band. It should be understood that the present disclosure may be configured using multiple modems 22, each coupled to any number of RF circuits. In general, the more RF circuits used, the greater the coverage of the antenna beam directions. It should be understood that the number of RF circuits and antennas utilized is determined by the hardware constraints of a particular device. Some of the RF circuits and antennas may be disabled when a STA determines that it does not need to communicate with neighboring STAs. In at least one embodiment, the RF circuitry includes a frequency converter, an array antenna controller, etc., and is connected to multiple antennas that are controlled to perform beamforming for transmission and reception. In this manner, a STA may transmit signals using a set of multiple beam patterns, with each beam pattern direction considered an antenna sector.

[0028] It should also be understood that multiple instances of station hardware such as that shown in this figure can be combined into a multi-link device (MLD), which typically has a processor and memory for coordinating activity, but does not necessarily require a separate CPU and memory for each STA within the MLD, as these resources can be shared.

[0029] FIG. 4 shows an example embodiment 40 of a multi-link device (MLD) hardware configuration. A "soft AP MLD" is an MLD consisting of one or more associated STAs operating as an AP. The soft AP MLD should support multiple radio operations, e.g., on 2.4 GHz, 5 GHz, and 6 GHz. The basic link set among the multiple radios is a link pair that satisfies simultaneous transmit / receive (STR) mode, e.g., basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz), etc.

[0030] A conditional link is a link that forms a non-simultaneous transmit / receive (NSTR) link pair with some fundamental link. For example, these link pairs can include a 6 GHz link as a conditional link corresponding to the 5 GHz link when 5 GHz is the fundamental link, and can include a 5 GHz link as a conditional link corresponding to the 6 GHz link when 6 GHz is the fundamental link. Soft APs are used in different scenarios, including Wi-Fi hotspots and tethering.

[0031] An MLD has multiple STAs attached to it, each operating on a different frequency link. The MLD has external I / O access to applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to enable the execution of program(s) that implement the communication protocol at the MLD level. The MLD can distribute tasks to its attached stations, illustrated here as STA1 42, STA2 44 through STA N 46, collect information from them, and share that information among its attached STAs.

[0032] In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c-60n, such as in the form of an antenna array. The modem in combination with the RF circuit and associated antenna(s) transmits / receives data frames to / from nearby STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

[0033] It should be understood that each STA in an MLD does not necessarily require its own processor and memory, as they may share resources with each other and / or with an MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagram is provided by way of example and not limitation, and that the present disclosure can work with a wide variety of MLD implementations.

[0034] 5. QoS Status Report The disclosed technology enables a non-AP STA to report its QoS requirements and / or buffer status to an AP. The QoS requirements and / or status can be conveyed in different ways, such as using a QoS Status Report (QSR), which can be carried in the A-Control subfield of the HT-Control field of a QoS Data frame or a QoS Null frame. According to the QSR, the AP can schedule and allocate resources for transmission of the corresponding data reported in the QSR to meet the QoS requirements.

[0035] A QSR can provide expiration information (time) for a desired portion of a buffer. When a non-AP STA reports such a QSR, the AP can generate a trigger to complete the transmission of these buffers before the expiration date of the associated data. The same buffer cannot be reported by multiple QSRs in the same PPDU.

[0036] If the QoS information in the QoS Control subfield in the same frame is not sufficient, the QSR can carry additional supplemental information, this time for traffic of the same TID reported in the QoS Control subfield.

[0037] Multiple QSRs can be carried in the same PPDU. Also, a QSR for a TID in a PPDU can override a QSR for the same TID in a previous PPDU. Through the use of the QSRs of the present disclosure, parameters for existing QoS characteristic elements and for reporting the status of existing SCS traffic streams can be changed. The QSRs of the present disclosure can be used to indicate that a buffer is expected to arrive at an R-TWT member STA in the near future (i.e., in the near future relative to the delivery requirements of the buffered RTA data), but that this requires the transmission to be terminated (completed) before the end of the current R-TWT SP.

[0038] 6. Examples of usable data structures Example 1 In this example 1, QSR is used to report the buffer size of a TID along with its expiration time.

[0039] 5 illustrates an example embodiment 70 of a control information subfield format within the QSR control subfield. The format of the QSR is shown as being carried in the A control subfield of the HT control field. It should be understood that the bit size (width) of each subfield within the QSR can vary. The control information subfield within the QSR control subfield contains QoS status information used for UpLink (UL) Multiple User (MU) operation (e.g., as found in Section 26.5.2 (UL MU Operation)) of the IEEE 802.11be D2.0 specification.

[0040] The First TID QSR subfield, when set to a first state (e.g., "1"), indicates that the QSR control subfield is the first QSR control subfield of the TID identified by the TID subfield transmitted in the same PLCP Service Data Unit (PSDU) (PLCP stands for PHY Layer Convergence Protocol), and is otherwise set to a second state (e.g., "0").

[0041] The TID subfield indicates the transmission identifier (TID) for which the QoS status is being reported.

[0042] The Scaling Factor (SF) subfield indicates the units, in octets, of the SF of the Queue Size subfield. The Queue Size subfield indicates the amount of buffered traffic for the TID identified by the TID subfield, intended for the STA identified by the recipient address of the frame containing the QSR control subfield, that should be delivered before the earliest MSDU expiration date, excluding any portion of the buffered traffic reported in other QSR control subfield(s) with earlier expiration dates within the same PSDU.

[0043] The size value in the Queue Size subfield is set to be less than or equal to the total queue size, rounded up to the nearest multiple of SF octets, of all MAC Service Data Units (MSDUs) and Aggregated MSDUs (A-MSDUs) buffered in the MLD (including MSDUs or A-MSDUs of SCS traffic streams in the same PSDU as the frame containing the QSR control subfield) in the delivery queue used for MSDUs and A-MSDUs with the TID specified in the TID subfield.

[0044] Note the following about these subfield values: (a) Total size is based on data received by the STA at the MAC Service Access Point (SAP) (MA-UNITDATA.request). Data from layers above the MAC layer is not considered. (b) Buffered MSDUs are those received in an MA-UNITDATA.request that have not yet been successfully transmitted but have not been discarded. (c) Queue size includes the size of MSDUs and A-MSDUs within the same PSDU with the same TID and the same earliest expiration time indicated in this QSR control subfield.

[0045] The queue size value may also indicate a special condition, for example, in one embodiment, a queue size value of a first predetermined value (e.g., 62) in the queue size subfield indicates that the amount of buffered traffic is greater than the first predetermined value multiplied by SF octets (e.g., 62 x SF octets), and a queue size value of a second predetermined value (e.g., 63) in the queue size subfield indicates that the amount of buffered traffic is an unspecified or unknown size.

[0046] The queue size value of a QoS data frame containing fragments may remain constant for all fragments even if the amount of traffic in the queue changes as successive fragments are transmitted (see section 10.23.3.5.1 (General) of the IEEE 802.11be D2.0 specification). If a QoS data frame containing fragments is carried in an A-MPDU, the queue size value of the MPDU containing the fragments is set according to the rules of section 10.18 (HT Control Field Operation) of the same specification.

[0047] In at least one embodiment, the queue size subfield may be replaced with a requested TXOP duration that indicates that the non-AP expects the AP to trigger TXOP sharing with the non-AP for that duration, as indicated before the earliest MSDU expiration time in this subfield.

[0048] The Earliest MSDU Expiration Time subfield contains an unsigned integer that specifies, in microseconds (μs), the point in time when the first MSDU or A-MSDU indicated in the Queue Size subfield reaches the delay limit indicated in the corresponding QoS characteristic element. In this example embodiment, this field represents the lower 14 bits of the TSF timer at which the first MSDU or A-MSDU indicated in the Queue Size subfield reaches the delay limit. This field shall be set to a value representing the TSF timer for the link on which the QSR control subfield is transmitted after the end of the PPDU containing the QSR control subfield (or the point in ms or μs after the end of the PPDU carrying the QSR).

[0049] Note that, as described in this disclosure, the expiration time can be set to a timing synchronization function (TSF) timer or a time point in ms or μs, such as the Earliest MSDU Expiration Time subfield here.

[0050] Table 2 shows the Control ID subfield values ​​for an embodiment of the present disclosure.

[0051] FIG. 6 illustrates an example embodiment 90 of an Extremely High Throughput (EHT) MAC Capability Information field format.

[0052] A non-AP STA delivers a QoS Status Report (QSR) to assist its associated AP in allocating UL MU resources to meet the QoS requirements of the traffic to be delivered by the non-AP STA. A non-AP STA can deliver a QSR either implicitly in the QSR control subfield of any frame sent to the AP (unsolicited QSR) or explicitly in the QSR control subfield of any frame sent to the AP in response to a Buffer Status Report Poll (BSRP) trigger frame (TF) (solicited QSR). In at least one embodiment, the QoS status reported in the QSR control field includes one TID, one queue size, and one earliest MSDU expiration time (see Section 9.2.4.7.xx (QSR Control)) of the IEEE 802.11be D2.0 specification.

[0053] An EHT STA shall set the QSR Support subfield in the EHT Capabilities element it sends to a first value (e.g., "1") if the setting for EHT QSR Control (dot11EHTQSRControlImplemented) is set to true, and shall set it to a second state (e.g., "0") otherwise.

[0054] An EHT STA with the QSR Support subfield set to the first state (e.g., "1") shall notify the AP of its buffer status according to the rules specified in Section 26.5.5 (Buffer Status Reporting Behavior) of the IEEE 802.11be D2.0 Specification, and shall notify the AP of its QoS status according to the additional rules specified below.

[0055] A non-AP STA reports its QoS status (unsolicited QSR) to its associated AP in the QoS Null, QoS Data, and QSR Control subfields (if present) of management frames as defined below.

[0056] An EHT STA may report its QoS status in the QSR Control subfield of frames it transmits if the AP indicates support in the QSR Support subfield of the EHT Capabilities element; otherwise, the STA shall not report its QoS status in the QSR Control subfield.

[0057] The EHT STA shall report the TID, queue size, and earliest MSDU expiration time of the buffered traffic in the TID subfield, queue size subfield, and earliest MSDU expiration time subfield of the QSR control subfield. The EHT STA may set the queue size to be less than or equal to the total size of all MSDUs and A-MSDUs buffered for the TID.

[0058] A non-AP STA can transmit PPDUs carrying multiple QoS Null, QoS Data, and management frames, and each frame in the PPDU can carry one QSR control subfield. These QSR control subfields in a PPDU can be used to report the QoS status of the same TID. If there are multiple QSR control fields reporting the QoS status of the same TID, each QSR control field reports the QoS status of a partial buffer for the TID. For a given (same) portion of a buffer for a TID, it cannot be reported by multiple QSR control fields in a PPDU. The QSR control subfield with the earliest MSDU expiration time must be transmitted earlier in the PPDU.

[0059] An AP may also solicit QSR(s) or BSR(s) from one or more associated non-AP STAs by transmitting a BSRP trigger frame (see Section 9.3.1.22.6 (BSRP Trigger Frame Format)) (IEEE 802.11be D2.0 Specification). The non-AP STAs respond (Solicited QSR) as defined below.

[0060] A non-AP STA that receives a BSRP trigger frame must generate a TB PPDU if the trigger frame contains the 12 LSBs of the non-AP STA's AID in any of the user information fields, according to the rules specified in Section 26.5.2.3 (Non-AP STA Behavior for UL MU Operation) of the IEEE 802.11be D2.0 Specification; on the other hand, if the non-AP STA's buffer is not empty and the non-AP STA supports the Uplink OFDMA-based Random Access (UORA) procedure, it can gain access to the RA-RU and generate a TB PPDU if the trigger frame contains one or more RA-RUs, according to the rules specified in Section 26.5.4 (UL OFDMA-based Random Access (UORA)) (IEEE 802.11be D2.0 Specification).

[0061] If a non-AP STA is buffering SCS traffic with delay bound requirements and the AP indicates support in the QSR Support subfield of the EHT Capability element, the non-AP STA shall include one or more QoS Null frames in the TB PPDU containing one or more QSR Control subfields with a TID subfield, a Queue Size subfield, and an Earliest MSDU Expiration Date subfield to indicate that the non-AP STA has a queue size for the specified TID to be delivered to the AP before the Earliest MSDU Expiration Date.

[0062] A non-AP STA may include one or more QoS Null frames containing multiple QSR control subfields for the same TID subfield in a TB PPDU. A non-AP STA must not count the queue size of the same value in multiple QSR control subfields of the same TB PPDU. A QSR control subfield with an earlier MSDU expiration time must be transmitted earlier in the PPDU.

[0063] Non-AP STAs must not request an immediate response to frames carried in a TB PPDU (e.g., must not set the Ack Policy Indicator subfield of a QoS Null frame to Normal Ack or Implicit BAR).

[0064] The subfields of the EHT MAC Capability Information field include a QSR Support subfield, which indicates support for receiving frames with a QSR Control subfield in the case of an AP. For non-AP STAs, this QSR Support subfield indicates support for generating frames with a QSR Control subfield. The coding of the +HTC-HE Support subfield is set to a first state (e.g., "1") to indicate that the STA supports the QSR Control subfield feature; otherwise, this value is set to a second state (e.g., "0"). This subfield is also reserved when the +HTC-HE Support subfield is set (e.g., "0") to indicate that +HTC-HE support is not present.

[0065] 6.2. Example 1-1 7 shows Example 1-1 as an embodiment 110 in which a QSR reports the buffer size of a TID along with an expiration time. The format of the QSR is shown in FIG. 2 and is carried in a QoS Null frame.

[0066] This example shows communication between AP 112, STA1 114, and STA2 116. The AP transmits a BSRP trigger frame 118 to its associated STAs, STA1 and STA2. STA1 then responds with two QSRs, shown as QSR1 120 and QSR2 124, in a single PPDU 128. In QSR1, STA1 reports that it has a TID6 with a buffer size of x bytes, indicating an earliest MSDU expiration time as Expiry 1. In QSR2, STA1 reports that it has a TID6 with a buffer size of y bytes, indicating an earliest MSDU expiration time as Expiry 2. From this information, the AP can recognize that STA1 has a TID6 with x bytes that should trigger before Expiry 1 and another TID6 with y bytes that should trigger before Expiry 2. Note that QSR1 sets its first TID QSR subfield to a first state (e.g., "1"), and QSR2 sets its first TID QSR subfield to a second state (e.g., "0").

[0067] Meanwhile, STA2 responds with one QSR, shown as QSR3 122, and one BSR 126 in one PPDU 128. In QSR3, STA2 reports that it has a TID5 with a buffer size of z bytes, indicating the earliest MSDU expiration date as Expiry Date 3. In the BSR, STA2 reports the buffer size of AC3 as specified in IEEE 802.11be. Thus, the AP can recognize that STA2 has a TID5 with z bytes that should trigger before Expiry Date 3, but that the specified portion of the buffer size of AC3 does not have an expiration date.

[0068] To satisfy the expiration date requirements reported by STA1 and STA2's QSRs, the AP first triggers 130 a TID6 132 of x bytes from STA1, ensuring that these bytes complete before Expiry Date 1. The AP then sends a Block Ack (BA) 134. Next, the AP triggers 136 a TID6 140 of y bytes from STA1 and a TID5 142 of z bytes from STA2, ensuring that these bytes complete before Expiry Date 1. The AP then responds again with a BA 144. Expiry Date 1 is shown as 138, and Expiry Dates 2 and 3 are shown as 146.

[0069] 6.3. Examples 1-2 8 illustrates Example 1-2 as an embodiment 210 in which a QSR reports the buffer size of a TID along with its expiration time. The figure shows communication between an AP 212 and STA1 214 to illustrate a QSR carried in a QoS data frame.

[0070] The AP transmits a BSRP trigger frame 216 to its associated STAs, of which only STA1 is shown in this figure. STA1 then responds with one QSR, shown as QSR1 218. In QSR1, STA1 reports that it has a TID6 with a buffer size of x bytes, indicating the earliest MSDU expiration time as Expiry 1. Upon receiving this, the AP knows that STA1 has a TID6 with x bytes that should be triggered before Expiry 1. The AP transmits a TF 220, and STA1 responds by transmitting one PPDU 226.

[0071] PPDU 226 carries two QoS data frames to the AP, shown as QoS Data Frame 1 224 and Frame 2 232. QoS Data Frame 1 carries QSR1 228, which reports duplicate information as found in the response to the BSRP, and Frame Body 230. However, in this example, this exchange of Frame 1 has failed.

[0072] QoS data frame 2 232 carries QSR2 234 reporting another y byte TID6 with the earliest MSDU expiration time, shown as Expiry Time 2, and has a frame body 236. Each QoS data frame carries half of the x bytes of data reported by QSR1. Therefore, it can be seen that QoS data frame 1 failed, but QoS data frame 2 succeeded.

[0073] In at least one embodiment, the AP estimates the length of the data frame carried by QoS Data Frame 1 by the modulation coding scheme (MCS), duration, and bandwidth. Thus, the AP can recognize that half of the x-byte TID6 was not successfully received. The AP recognizes the failed transmission of at least QoS Data Frame 1 and retriggers a successful retransmission in QoS Data Frame 2 232.

[0074] Also, STA1 reported in QSR 234 that it has another y byte TID6 to send before expiration date 2, so the AP sends another trigger frame 240 that triggers the transmission of half 246 of the x byte TID6 and another y byte TID6 from STA1.

[0075] STA1 responds to the second trigger frame 240 from the AP by transmitting two data frames, shown as QoS Data Frame 3 244 and QoS Data Frame 4 250, in one (TB)PPDU 242. QoS Data Frame 3 carries QSR3 246 indicating that it still has half of TID6 of x bytes of buffer size with expiration time 1 and half of x bytes of data in frame body 248.

[0076] QoS Data Frame 4 250 contains QSR2 252 (copied from QoS Data Frame 2) and y type data in frame body 256. The AP responds with BA 258, which indicates Expiry Date 1 with Expiry Date 260, so the transmission was successful.

[0077] Example 2 Example 2 shows a QSR that reports the QoS status associated with the QoS control subfield in the same frame.

[0078] 9 illustrates an example embodiment 290 showing the format of the control information subfield within the QSR control subfield. The QSR is carried in the A-Control subfield of the HT Control field and can be used with the QoS Control subfield within the same frame. Note that the bit size (subfield width) of each subfield within the QSR subfield is described by way of example and not limitation, and these values ​​can be modified without departing from the teachings of this disclosure. The control information subfield of the QSR has the following subfields:

[0079] The Min Queue Size / TXOP Duration Requested Ratio subfield is set to the queue size / requested TXOP duration ratio starting from the first MSDU or A-MSDU (or first byte) reported in the QoS Control subfield within the same QoS Null / Data frame. This field represents the queue size ratio when the QoS Control subfield reports the queue size. This field represents the requested TXOP duration ratio when the QoS Control subfield reports the requested TXOP duration.

[0080] The Max Queue Size / TXOP Duration Requested Ratio subfield is set to the queue size / requested TXOP duration ratio starting from the first MSDU or A-MSDU (or first byte) reported in the QoS Control subfield within the same QoS Null / Data frame. This field represents the queue size ratio when the QoS Control subfield reports the queue size. This field represents the requested TXOP duration when the QoS Control subfield reports the requested TXOP duration.

[0081] The Earliest MSDU Expiry Time subfield is set to the expiration time of the earliest MSDU or A-MSDU between the minimum queue size / requested TXOP duration ratio and the maximum queue size / requested TXOP duration ratio.

[0082] The Latest MSDU Expiry Time subfield is set to the expiration time of the latest MSDU or A-MSDU between the minimum queue size / requested TXOP duration ratio and the maximum queue size / requested TXOP duration ratio.

[0083] In at least one embodiment, the requested TXOP duration is determined based on a bandwidth, where a bandwidth of 20 MHz or other bandwidth size such as 40 MHz, 80 MHz, 160 MHz, or 320 MHz is indicated as the reference bandwidth. The reference bandwidth size may be predetermined by the network system, such as in at least one example embodiment. The AP may then adjust the TXOP sharing duration based on the actual bandwidth it occupies and shares with non-AP STAs. For example, the actual TXOP sharing duration may be calculated as (requested TXOP duration in QSR / reference bandwidth size). * It can be the actual bandwidth size.

[0084] 6.5. Example 2-1 10 illustrates an example 2-1 as an embodiment 310 in which the QSR reports the buffer size of the TID associated with the QoS control subfield (see FIG. 9). This figure illustrates an example of communication between an AP 312 and a STA 1 314.

[0085] 11 illustrates an example embodiment 370 of the buffer status for TID5 for STA1. This figure shows 100% 372 of the x bytes of the buffer for TID5, as well as z% 374 of the x bytes of TID5, y% to z% of the bytes of TID5 MSDUs and A-MSDUs 376, and y% of the x bytes of TID5 378. The first byte 380 of TID5 is also shown.

[0086] Referring again to FIG. 10, the AP transmits a BSRP trigger frame 316 to an associated STA, indicated by STA1 314. STA1 then responds to the AP with a QoS Null frame 318 carrying a QoS Control subfield 320 and a QSR, indicated by QSR 322. STA1 reports in the QoS Control subfield that it has x bytes of TID5 in its buffer. STA1 then reports in QSR3 322 that y% to z% of the MSDUs and A-MSDUs in x-byte TID5 376 (of FIG. 11) have the earliest and latest MSDU expiration times of Expiry1 and Expiry2, respectively. That is, y% to z% of the MSDUs and A-MSDUs in x-byte TID5 (of FIG. 11) are scheduled to expire between Expiry1 330 and Expiry2 338.

[0087] Assume that all MSDUs and A-MSDUs are sorted by ascending expiration time (i.e., MSDUs or A-MSDUs with earlier expiration times are buffered closer to the front of the queue), and QSR3 also indicates that y% 378 (FIG. 11) of x byte TID5s have expiration times before Expiry Time 1 330, and (100%-z%) of x byte TID5s have expiration times after Expiry Time 2 338.

[0088] The AP immediately triggers these bytes by first transmitting a trigger frame (TF) 324 shown in Figure 10 to finish transmitting y% of x bytes before Expiration 1, according to the two expiration dates reported in QSR3. STA1 transmits a TB PPDU 326 with a data frame containing TID5, which is y% of x bytes, and its receipt can be seen acknowledged with BA 328.

[0089] The AP then sends another TF 332 to trigger the transmission of (zy)% of x bytes shown as a TB PPDU 334 with a data frame containing TID5 that is (zy)% of x bytes to finish sending these bytes before Expiry Date 2 338. The AP responds to the TB PPDU with a BA 336.

[0090] 12 illustrates Example 2-2 as an embodiment 410 in which the QSR reports the requested TXOP duration for the TID associated with the QoS control subfield. Illustrated in this figure are example communications from an AP 412 and STA1 414.

[0091] The AP sends a BSRP trigger frame 416 to an associated STA, denoted by STA1. STA1 then responds to the AP with a QoS Null frame 418 carrying a QoS Control subfield 420 and a QSR 422, denoted by QSR3. STA1 reports in the QoS Control subfield 420 that it requires x μs to transmit the buffer for TID5. STA1 then reports in QSR3 422 that the earliest and latest MSDU expiration times of the MSDUs and A-MSDUs that make up y% to z% of the requested TXOP period of x μs for TID5 are Expiry Date 1 and Expiry Date 2, respectively. That is, the MSDUs and A-MSDUs that make up y% to z% of the requested TXOP period of x μs for TID5 will expire between Expiry Date 1 and Expiry Date 2. In this example, it is assumed that all MSDUs and A-MSDUs are sorted by ascending expiration date (i.e., MSDUs or A-MSDUs with earlier expiration dates are buffered closer to the front of the queue). QSR3 also indicates that x μs of TID5 have an expiration date of y% of the requested TXOP period before expiration date 1, and that x μs of TID5 have an expiration date of (100%-z%) of the requested TXOP period after expiration date 2.

[0092] The AP immediately triggers a TXOP with STA1 sharing y% of x μs by first transmitting an MU RTS TXS trigger frame 424 to complete transmission of the corresponding bytes before Expiration 1, according to the two Expiration Dates 432 and 442 reported in QSR3. The figure shows that STA1 responds with a Clear-To-Send (CTS) 426 and then transmits a TB PPDU 428 containing data for TID5. The AP acknowledges receipt of this PPDU with BA 430, which in this example can be seen to occur just before Expiration Date 1 432.

[0093] The AP then transmits another MU RTS TXS trigger frame 434 sharing the TXOP with STA1 for (zy)% of the TXOP duration of x μs to complete (finish) the transmission of the corresponding byte before Expiry 2 442. STA1 responds to the MU RTS with a Clear to Send (CTS) 436 and transmits a TB PPDU 438 containing a data frame with TID 5. The transmission is then acknowledged by the AP (440).

[0094] Example 3 13 shows an example embodiment 450 of the format of a QSR for changing the parameters of the QoS characteristic element of an existing SCS. As mentioned above, the bit size of each subfield of the QSR can be changed.

[0095] The SCS ID (SCSID) subfield is set to the identity of an existing SCS established between the non-AP and the AP.

[0096] The QoS characteristics element field is set to indicate the corresponding field of the QoS characteristics element of the SCS indicated in the SCSID subfield. Each value can be set to indicate the field of the QoS characteristics element as shown in Table 3.

[0097] The Offset Value field is set to indicate the change in value compared to the value set in the QoS characteristic element. When the AP receives this field, it changes the value of the corresponding subfield in the QoS characteristic element of the SCS. For example, assume that the Offset Value subfield has x bits (e.g., 14 bits as shown) and the non-AP sets the offset value to y. In this case, the AP changes the value of the corresponding subfield in the QoS characteristic element of the SCS to y-2. x In other words, if the value of the subfield in the QoS characteristic element of the SCS was z before the AP received the QSR, the AP will change it to z+y-2 after receiving the QSR. x The AP can terminate the SCS if it cannot meet the QoS requirements of the SCS after the parameter change.

[0098] Table 3 shows an example of the encoding of the QoS characteristic element subfield.

[0099] Example 4 Example 4 uses QSR to report the status of an existing SCS.

[0100] 14 illustrates Example 4 as an embodiment 470 of a control information subfield format within a QSR control subfield. Note that in this example field, the bit size of each subfield within the QSR can be changed without departing from the teachings of this disclosure. The fields of the control information subfield are as follows:

[0101] The SCSID subfield is set to the identity of an existing SCS established between the non-AP and the AP.

[0102] The Buffer Size subfield is set to the (MAC layer) buffer or queue size (in bytes or as a percentage of the buffer size of the corresponding TID reported by the TID Control subfield in the same frame) of the SCS indicated in the SCSID subfield at the time the non-AP reports the QSR. If the buffer size is set to a value in bytes, it may be separated by a Scaling Factor subfield and a Queue Size subfield (see, for example, FIG. 2). Note that in at least one embodiment of the present disclosure, the Buffer Size field is optional.

[0103] The Token of SCS field is set to the bits corresponding to the token indicated by l(t0) in the SCS as indicated in the SCSID subfield at the time the non-AP reports the QSR, where t0 is the time the QSR is sent. This allows the AP to understand the state of the SCS bucket model at that time. This field can be set to a value in bytes or a value in units of a percentage of the burst size in the SCS QoS characteristic element. If set to a value in bytes, this field can be separated by a scaling factor subfield and a subfield similar to the queue size, as shown in Figure 2.

[0104] The Greedy Starting subfield, when set to a first state (e.g., "1"), indicates that the SCS is performing a greedy start (which involves using a different buffer size prediction method) when a non-AP STA sends a QSR. Otherwise, this field is set to a second state (e.g., "0").

[0105] In this example, QSR can help the AP predict the buffer status of SCS in the near future and allocate resources in advance for the next MSDU and A-MSUD transmission. For example, if the peak rate of SCS is C (bytes / sec) and the buffer size reported by QSR is Q at time t0, if greedy start is set to 1, the AP can calculate the buffer size x(t) of SCS that needs to be transmitted from non-AP STAs by time t as follows: x(t) = Min[C], where ρ is the average sustainable rate. * (t-t0),l(t0)+(t-t0) * ρ] + Q. When the greedy start is set to the second state (e.g., "0"), the value of ρ is equal to the average data rate in the QoS characteristic element of the SCS, and Q <x(t)<Min[C * (t-t0),l(t0)+(t-t0) * ρ]+Q (or Min[C_min * (t-t0),l(t0)+(t-t0) * ρ]+Q <x(t)<Min[C * (t-t0),l(t0)+(t-t0) * ρ]+Q, where C_min is the minimum data rate in the QoS characteristic element of the SCS).

[0106] In at least one embodiment, this QSR information is valid only for a short (selected) time period, such as (a) until the current TXOP (the TXOP in which the QSR is sent) ends, (b) until the current R-TWT SP (the SP in which the QSR is sent) ends, or (c) up to a fixed period such as 3 milliseconds that can be predetermined by the network system. In at least one embodiment, this time information is also conveyed by the QSR control subfield (not shown).

[0107] In at least one embodiment, another peak rate subfield may be added within the QSR (not shown) of FIG.

[0108] When the greedy start subfield is set to the second state (e.g., "0"), this subfield is set to the value C representing the peak rate of the SCS, or this subfield can be spare.

[0109] When the greedy start subfield is set to the second state (e.g., "0"), this subfield is set to the value C_notpeak < C, and the buffer size x(t)=Min[C_notpeak * (t - t0), l(t0)+(t - t0) * ρ]+Q.

[0110] x(t) represents (a) the amount of buffer to be delivered by time t, or (b) the amount of buffer arriving at the buffer by time t.

[0111] 6.7. Example 4-1 FIG. 15 shows Example 4-1 as Embodiment 510 in which the AP schedules a TB PPDU for a buffer arriving in the near future according to a QSR reporting the state of an existing SCS. This figure shows the communication between the AP 512 and the STA1 514.

[0112] The AP transmits a BSRP trigger frame 516 to the relevant STA indicated by the STA1. Next, the STA1 responds to the AP with a QoS null frame 520 carrying the QSR at time 0 5:18. The STA1 reports in the QSR that the buffer size of SCS1 at time t0 is Q bytes, the token of SCS1 is I bytes, and the greedy start is set to the first state (e.g., "1"). The AP can transmit a trigger frame 522 to trigger the traffic 524 of SCS1 from the STA1. The TB PPDU 524 ends at time t 52:8. Thereafter, the AP, Min[C * (t - t0), l(t0)+(t - t0) * ρ]+Q bytes of SCS1 traffic can be expected to be triggered from the STA1. The AP responds to the TB PPDU 524 with a BA 526.

[0113] In some cases, the end time of the TB PPDU may be later than time t due to a low MCS or narrow RU of the TB PPDU.

[0114] In at least one embodiment, the TB PPDU for transmission of SCS1 is determined based on the expected buffer size of SCS1 at time t1 being Min[C * (t1-t0),l(t0)+(t1-t0) * It can only start after time t1 when ρ]+Q>=L_max, where L_max is the maximum MSDU size in the QoS characteristic element of the SCS.

[0115] Example 5 illustrates an embodiment 550 of the format of a QSR for reporting expected transmissions during an R-TWT SP in Figure 16. As mentioned above, the bit size of each subfield in the QSR can vary.

[0116] The R-TWT ID subfield is set to the identity of the R-TWT to which the non-AP STA intends to transmit the buffer as reported in the QSR.

[0117] The Scaling Factor subfield can be the same as that shown in the first embodiment.

[0118] The Expected Queue Size / TXOP Duration Requested subfield represents the expected queue size or the expected requested TXOP duration. If this field contains an expected queue size, it is set to a value in bytes that indicates the amount of data that the non-AP STA needs to transmit during the R-TWT SP (e.g., triggered by the AP). If it is an expected requested TXOP duration, it is set to the TXOP duration that the non-AP STA expects TXOP sharing to be triggered by the AP during the R-TWT SP.

[0119] Note that there may also be a 1-bit indication subfield within the QSR (not shown in Figure 16) that indicates whether the expected queue size / requested TXOP duration subfield represents the expected queue size or the expected requested TXOP duration.

[0120] The Expected Trigger Time subfield is set to indicate the time frame in which non-AP STAs can expect the AP to trigger transmission of the expected queue size or TXOP sharing at the expected request period.

[0121] In at least one embodiment, the QSR shown in Example 5 takes effect only over the next or current SP of the R-TWT indicated in the R-TWT ID subfield.

[0122] In at least one embodiment, the QSR shown in Example 5 takes effect only over the current R-TWT SP, in which case the R-TWT ID field can be replaced with a TID or ACI subfield indicating the TID or AC information of the buffer reported in the QSR.

[0123] 7. General Scope of Embodiments Embodiments of the present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and / or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowcharts, and combinations of blocks (and / or steps) of the flowcharts, and any procedures, algorithms, steps, operations, formulas, or computational expressions, may be implemented by various means, such as hardware, firmware, and / or software that includes one or more computer program instructions embodied in computer-readable program code. It will be appreciated that any such computer program instructions may be executed by one or more computer processors, including, but not limited to, a general-purpose computer or a special-purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).

[0124] Thus, the flowchart blocks and procedures, algorithms, steps, operations, formulas, or computational expressions described herein support combinations of means for performing a particular function(s), combinations of steps for performing a particular function(s), and computer program instructions for performing a particular function(s) as embodied in computer-readable program code logic means. It will also be understood that each flowchart block and any procedures, algorithms, steps, operations, formulas, or computational expressions described herein, and combinations thereof, can also be implemented by a dedicated hardware-based computer system that performs the particular function(s) or step(s), or a combination of dedicated hardware and computer-readable program code.

[0125] Furthermore, these computer program instructions, embodied in computer-readable program code or the like, may be stored in one or more computer-readable memories or memory devices that can direct a computer processor or other programmable processing device to function in a particular manner, such that the instructions stored in these computer-readable memories or memory devices produce an article of manufacture that includes instruction means for performing the functions specified in the flowchart(s). The computer program instructions may be executed by the computer processor or other programmable processing device to cause a series of operational steps to be performed on the computer processor or other programmable processing device to generate a computer-implemented process, such that the instructions executing on the computer processor or other programmable processing device provide steps for performing the function specified in the flowchart(s) block(s), procedure(s), algorithm(s), step(s), operation(s), mathematical formula(s), or computational expression(s).

[0126] Furthermore, as used herein, the terms "program" or "program executable" will be understood to mean one or more instructions executable by one or more computer processors to perform one or more functions described herein. The instructions may be embodied in software, firmware, or a combination of software and firmware. The instructions may be stored locally on a non-transitory medium of the device or remotely, such as on a server, or all or a portion of the instructions may be stored locally or remotely. Remotely stored instructions may be downloaded (pushed) to the device upon user initiation or automatically based on one or more factors.

[0127] Furthermore, as used herein, the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used interchangeably to refer to devices capable of executing instructions and communicating with input / output interfaces and / or peripheral devices, and it will be understood that the terms processor, hardware processor, computer processor, CPU, and computer are intended to include single or multiple devices, single-core devices and multi-core devices, and variations thereof.

[0128] From the description herein, it will be understood that the present disclosure encompasses multiple technology implementations, including but not limited to the following.

[0129] A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each connected to one or more antennas; (b) the stations (STAs) configured as independent STAs or as STAs within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN), (e) the instructions, when executed by the processor, cause (e)(i) the STA to function as an access point (AP) STA or a non-AP STA communicating with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless communication protocol. and (e)(ii) conveying medium access control (MAC) service data units (MSDUs) or aggregated MSDUs (A-MSDUs) from a buffer in a MAC layer based on a quality of service (QoS) and transmitting them as physical layer protocol data units (PPDUs) between physical layers of a WLAN; (e)(iii) transmitting a QoS status report (QSR) from the non-AP STA to an AP STA, the QSR including information regarding latency requirements of a particular portion of the buffered MSDUs on the non-AP STA; and (e)(iv) receiving, by the non-AP STA, scheduling for triggered transmission of the buffered MSDUs indicated in the QSR from the AP STA to meet the latency requirements of the buffered MSDUs.

[0130] A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each connected to one or more antennas; (b) the stations (STAs) configured as independent STAs or as STAs within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN), (e) the instructions, when executed by the processor, cause (e) (i) the STA to function as an access point (AP) STA or a non-AP STA communicating with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless communication protocol. (e)(ii) conveying medium access control (MAC) service data units (MSDUs) or aggregated MSDUs (A-MSDUs) from a buffer in a MAC layer based on quality of service (QoS) and transmitting them as physical layer protocol data units (PPDUs) between physical layers of a WLAN; (e)(iii) transmitting a QoS status report (QSR) from the non-AP STA to an AP STA, the QSR including information about latency requirements of a particular portion of the buffered MSDUs on the non-AP STA; (e)(iv) the QSR carrying (A) information about the size of the buffered MSDUs or A-MSDUs relative to the latency requirements in the QSR, (B) information about the earliest expiration date of an MSDU or A-MSDU in the buffered traffic, (C) a report about buffers with upcoming content so that the AP can correctly allocate resources to the buffer content in advance, or a combination thereof; and (v) the non-AP STA instructs the AP to schedule for triggered transmission of the buffered MSDUs indicated in the QSR to meet the latency requirements of the buffered MSDUs. and receiving from the STA a signal indicating a timestamp of a wireless communication protocol.

[0131] A method for performing communications in a wireless network, comprising: (a) wirelessly communicating over an IEEE 802.11 wireless local area network (WLAN) between stations (STAs) configured as independent STAs or STAs in a multi-link device (MLD) when executing a wireless communication protocol; (b) the STAs operating in the wireless communication protocol as access point (AP) STAs or non-AP STAs that communicate with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; (c) conveying medium access control (MAC) service data units (MSDUs) or aggregated MSDUs (A-MSDUs) from a buffer in a MAC layer based on quality of service (QoS) and transmitting them as physical layer protocol data units (PPDUs) between physical layers of the WLAN; (d) transmitting a QoS status report (QSR) from the non-AP STA to an AP STA, the QSR including information regarding latency requirements of a particular portion of the buffered MSDUs on the non-AP STA; and (e) transmitting a QoS status report (QSR) from the non-AP STA to an AP STA, the QSR including information regarding latency requirements of a particular portion of the buffered MSDUs on the non-AP STA. and the STA receiving from the AP STA scheduling for triggered-based transmission of the buffered MSDUs indicated in the QSR to meet latency requirements of the buffered MSDUs.

[0132] A wireless communication device or method that performs frame transmission between MAC layers of an IEEE 802.11 network, performing PPDU transmission between PHY layers of the IEEE 802.11 network, and in which STAs use CSMA / CA for channel contention, comprising: (a) a non-AP STA transmitting a QoS Status Report (QSR) to an AP, the QoS Status Report providing latency requirements for a certain amount (block) of buffered traffic; and (b) the AP scheduling trigger-based transmission of the buffered traffic in the QSR to meet the latency requirements of the buffered traffic.

[0133] The QSR conveys information regarding latency requirements, including traffic identification, of any preceding implementation of the apparatus or method.

[0134] The apparatus or method of any preceding implementation, wherein the traffic identification includes an access class (AC), a traffic identifier (TID), and a stream classification service identifier (SCSID).

[0135] An apparatus or method of any preceding implementation, wherein the QSR carries information regarding the size of the buffered MSDU or A-MSDU relative to the latency requirements within the QSR.

[0136] A QSR conveys information about the earliest expiration time of an MSDU or A-MSDU in the buffered traffic, as in any prior implementation of the apparatus or method.

[0137] The apparatus or method of any preceding implementation, wherein the earliest expiration date of an MSDU or A-MSDU in buffered traffic includes information about the period for which the MSDU or A-MSDU is valid, and the period after which the validity of the MSDU or A-MSDU expires.

[0138] The apparatus or method of any preceding implementation, wherein a non-AP STA transmits multiple QSRs in a single PPDU to accommodate the latency requirements of multiple blocks of buffered MSDUs.

[0139] The apparatus or method of any preceding implementation, wherein a QSR indicates that the QSR is the first QSR for a TID in a transmitted PPDU, while further QSRs in the transmitted PPDU that expire after the first QSR contain buffered traffic for the same TID.

[0140] The apparatus or method of any preceding implementation, wherein information in a subsequent QSR overrides information received in a previous QSR.

[0141] An apparatus or method of any preceding implementation in which the QSR carries information about the number of tokens remaining in the token bucket for SCS traffic, and the mean data rate, peak data rate, and burst size are given as parameters of the token bucket model in a traffic specification (TSPEC) element or a QoS characteristic element.

[0142] Any prior implementation of the apparatus or method in which the QSR contains reports about buffers that will soon have content arriving, so that the AP can correctly allocate resources to these buffer contents in advance.

[0143] The QSR may carry traffic identifiers such as the AC, TID, SCSID, etc. of the buffered traffic, as in any preceding implementation of the apparatus or method.

[0144] The apparatus or method of any preceding implementation, wherein the QSR can convey the size of the buffered traffic relative to the latency requirements at the QSR.

[0145] Any prior implementation of the apparatus or method may carry the earliest expiration date of an MSDU or A-MSDU in the buffered traffic (i.e., the deadline by which the MSDU or A-MSDU must be transmitted).

[0146] Any preceding implementation of the apparatus or method allows a non-AP STA to send multiple QSRs in the same PPDU to meet the latency requirements of multiple blocks of buffered traffic.

[0147] Any prior implementation of the apparatus or method may indicate that a QSR is the first QSR for a TID within a PPDU, and that buffered traffic for the same TID in other QSRs within the same PPDU will expire after the first QSR.

[0148] An apparatus or method of any preceding implementation, wherein a QSR for a TID / AC / SCSID in a PPDU can override a QSR for the same TID / AC / SCSID in a previous PPDU.

[0149] QSR is any prior implementation of an apparatus or method capable of conveying the amount of tokens remaining in the bucket of SCS traffic. (Note that the mean data rate, peak data rate, and burst size in the TSPEC or QoS characteristic element are parameters of the token bucket model, which provides a standard term for describing the behavior of traffic sources. The token bucket model is described in IETF RFC2212 [B25], IETF RFC2215 [B26], and IETF RFC3290 [B35].)

[0150] QSR is any prior implementation of a device or method that can report buffers arriving in the near future so that the AP can pre-allocate resources for these buffers.

[0151] As used herein, the term "implementation" is intended to include, without limitation, any embodiment, example, or other form of implementing the techniques described herein.

[0152] As used herein, the singular forms "a," "an," and "the" can include plural references unless the context clearly indicates otherwise. Reference to an object in the singular does not mean "one and only one" unless expressly stated otherwise, but rather "one or more."

[0153] In this disclosure, phrases such as "A, B, and / or C" indicate that either A, B, or C, or any combination of items A, B, and C, can be present. Phrases such as "at least one of" followed by a group of listed elements indicate that at least one of the group of elements is present, including, where applicable, any possible combination of the listed elements.

[0154] References in this disclosure to "one embodiment," "at least one embodiment," or similar embodiment phrases indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the disclosure. Thus, these references to various embodiments do not necessarily refer to all the same embodiment, or to a specific embodiment that is different from all other embodiments described. Reference to an embodiment should be interpreted to mean that the particular feature, structure, or characteristic of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed device, system, or method.

[0155] As used herein, the term "set" means a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[0156] Relative terms such as first and second, top and bottom, upper and lower, and left and right in this document are used merely to distinguish one entity or action from another and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.

[0157] The terms "comprises, compris- ing, has, having, includes, including, contains, containing," or any other variations of these terms, are intended to cover non-exclusive inclusions, and thus a process, method, article, apparatus, or system that comprises, has, or includes a list of elements does not include only those elements, but may also include other elements not expressly listed or that are inherent to such process, method, article, apparatus, or system. An element following "comprises ... a, has ... a, includes ... a, or contains ... a" does not exclude, without further constraint, the presence of additional identical elements in the process, method, article, apparatus, or system that comprises, has, or includes that element.

[0158] As used herein, the terms “approximately,” “approximate,” “substantially,” “essentially,” and “about,” or any variation thereof, are used to describe and explain slight variations. When used in connection with events or circumstances, these terms can mean that the events or circumstances will definitely occur and that the events or circumstances are highly likely to occur. When used in connection with a numerical value, these terms can mean a variation range of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less of the numerical value. For example, “substantially” aligned can mean an angular variation range of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

[0159] Additionally, amounts, ratios, and other numerical values ​​may be presented in range format herein. Such range formats are used for convenience and simplicity, and should be understood to include numerical values ​​explicitly specified as the limits of the range, but also to include all individual numerical values ​​or subranges within the range, as if each such numerical value and subrange were expressly set forth. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also to include individual ratios such as about 2, about 3, and about 4, as well as subranges such as about 10 to about 50 and about 20 to about 100.

[0160] The term "coupled," as used herein, is defined as connected, but not necessarily by a direct mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in unlisted ways.

[0161] Benefits, advantages, solutions to problems, and any element(s) that cause or make more pronounced any benefit, advantage, or solution should not be construed as a critical, necessary, or essential feature or element of the technology described herein or any or all of the claims.

[0162] Also, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may comprise less than all features of a single disclosed embodiment.

[0163] The Abstract of the Disclosure is intended to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0164] It is understood that some jurisdictions have a practice of requiring the deletion of one or more portions of the disclosure after filing. Accordingly, the reader should refer to the application as of its filing date for the original content of the disclosure. The deletion of any of the disclosed content should not be construed as an abandonment, forfeiture, or dedication to the public of any subject matter of the application as originally filed.

[0165] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as a separate inventive subject matter.

[0166] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure, but merely as exemplifying some of the presently preferred embodiments, and therefore, the scope of the disclosure will be understood to fully encompass other embodiments that may become apparent to those skilled in the art.

[0167] Structural and functional equivalents of elements of embodiments of the present disclosure known to those skilled in the art are also expressly incorporated herein by reference and are intended to be within the scope of the claims. Furthermore, no elements, components, or method steps of the present disclosure are intended to be publicly disclosed, regardless of whether they are explicitly recited in the claims. No claim element herein should be construed as a "means-plus-function" element unless the element is expressly recited using the phrase "means for." Also, no claim element herein should be construed as a "step-plus-function" element unless the element is expressly recited using the phrase "step for." [Explanation of symbols]

[0168] 110 Embodiments 112 AP 114 STA1 116 STA2 118 BSRP 120 QSR1 (TID 6, buffer size x bytes, earliest MSDU expiration time 1) 122 QSR3 (TID 5, buffer size z bytes, earliest MSDU expiration time 3) 124 QSR2 (TID 6, buffer size y bytes, earliest MSDU expiration time 2) 126 BSR(ACK) 128 one PPDU (other components of the PPDU and frames are not shown here) 130 TF 132 TB PPDU (data frame: TID6, x bytes) 134 BA 136 TF 138 Expiration Date 1 140 TB PPDU (data frame: TID6, y bytes) 142 TB PPDU (data frame: TID5, z bytes) 144 BA 146 Expiration Date 2, 3

[0169] [Table 1] [Table 2] [Table 3]

Claims

1. A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each modem coupled to one or more antennas; (b) the station (STA) is configured as an independent STA or as a STA within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN); (e) the instructions, when executed by the processor: (i) the STA operates in a wireless communication protocol as an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism; (ii) conveying Medium Access Control (MAC) Service Data Units (MSDUs) or Aggregated MSDUs (A-MSDUs) from a buffer in the MAC layer based on a Quality of Service (QoS) and transmitting them as Physical Layer Protocol Data Units (PPDUs) between physical layers of the WLAN; (iii) transmitting a QoS Status Report (QSR) from the non-AP STA to the AP STA, the QSR including information regarding the latency requirements of a particular portion of the buffered MSDU on the non-AP STA; (iv) the non-AP STA receiving from the AP STA a scheduling for trigger-based transmission of the buffered MSDU indicated in the QSR to meet the latency requirement of the buffered MSDU; performing steps of a wireless communication protocol including: An apparatus characterized in that

2. The QSR conveys information regarding latency requirements, including traffic identification.

10. The apparatus of claim 1.

3. The traffic identification includes an access class (AC), a traffic identifier (TID), and a stream classification service identifier (SCSID); 3. The apparatus of claim 2.

4. the QSR conveys information regarding the size of buffered MSDUs or A-MSDUs relative to the latency requirements within the QSR; 10. The apparatus of claim 1.

5. The QSR carries information about the earliest expiration time of an MSDU or A-MSDU in the buffered traffic; 10. The apparatus of claim 1.

6. The earliest expiration date of an MSDU or A-MSDU in the buffered traffic includes information about the period during which the MSDU or A-MSDU is valid, and the period after which the validity of the MSDU or A-MSDU expires; 6. The apparatus of claim 5.

7. The non-AP STA transmits multiple QSRs in a single PPDU to accommodate the latency requirements of multiple blocks of buffered MSDUs.

10. The apparatus of claim 1.

8. the QSR indicates that the QSR is the first QSR for a TID in the transmitted PPDU, while a further QSR in the transmitted PPDU that expires after the first QSR contains buffered traffic for the same TID; 10. The apparatus of claim 1.

9. Information in a subsequent QSR overrides information received in a previous QSR; 10. The apparatus of claim 1.

10. The QSR carries information about the number of tokens remaining in the token bucket of the SCS traffic, and the mean data rate, peak data rate, and burst size are given as parameters of the token bucket model in the traffic specification (TSPEC) element or QoS characteristics element.

10. The apparatus of claim 1.

11. The QSR contains reports about the buffers so that the AP can correctly allocate resources in advance to the contents of the buffers that are due to arrive soon.

10. The apparatus of claim 1.

12. A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each modem coupled to one or more antennas; (b) the station (STA) is configured as an independent STA or as a STA within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN); (e) the instructions, when executed by the processor: (i) the STA operates in a wireless communication protocol as an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism; (ii) conveying Medium Access Control (MAC) Service Data Units (MSDUs) or Aggregated MSDUs (A-MSDUs) from a buffer in the MAC layer based on a Quality of Service (QoS) and transmitting them as Physical Layer Protocol Data Units (PPDUs) between physical layers of the WLAN; (iii) transmitting a QoS Status Report (QSR) from the non-AP STA to the AP STA, the QSR including information regarding the latency requirements of a particular portion of the buffered MSDU on the non-AP STA; (iv) the QSR conveys (A) information about the size of the buffered MSDUs or A-MSDUs relative to the delay requirements at the QSR, (B) information about the earliest expiration date of the MSDUs or A-MSDUs in the buffered traffic, (C) reports about the buffers so that the AP can correctly allocate resources in advance to the soon-to-arrive buffer contents, or a combination thereof; (v) the non-AP STA receiving from the AP STA a scheduling for trigger-based transmission of the buffered MSDU indicated in the QSR to meet the latency requirement of the buffered MSDU; performing steps of a wireless communication protocol including: An apparatus characterized in that

13. The QSR conveys information regarding latency requirements, including traffic identification.

13. The apparatus of claim 12.

14. The traffic identification includes an access class (AC), a traffic identifier (TID), and a stream classification service identifier (SCSID); 14. The apparatus of claim 13.

15. The earliest expiration date of an MSDU or A-MSDU in the buffered traffic includes information about the period during which the MSDU or A-MSDU is valid, and the period after which the validity of the MSDU or A-MSDU expires; 13. The apparatus of claim 12.

16. The non-AP STA transmits multiple QSRs in a single PPDU to accommodate the latency requirements of multiple blocks of buffered MSDUs.

13. The apparatus of claim 12.

17. the QSR indicates that the QSR is the first QSR for a TID in the transmitted PPDU, while a further QSR in the transmitted PPDU that expires after the first QSR contains buffered traffic for the same TID; 13. The apparatus of claim 12.

18. Information in a subsequent QSR overrides information received in a previous QSR; 13. The apparatus of claim 12.

19. The QSR carries information about the number of tokens remaining in the token bucket of the SCS traffic, and the mean data rate, peak data rate, and burst size are given as parameters of the token bucket model in the traffic specification (TSPEC) element or QoS characteristics element.

13. The apparatus of claim 12.

20. 1. A method of performing communications in a wireless network, comprising: (a) communicating wirelessly between stations (STAs) configured as independent STAs or STAs within a multi-link device (MLD) when executing a wireless communication protocol over an IEEE 802.11 wireless local area network (WLAN); (b) the STA operates in a wireless communication protocol as an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism; and (c) conveying Medium Access Control (MAC) Service Data Units (MSDUs) or Aggregated MSDUs (A-MSDUs) from a buffer in the MAC layer based on a Quality of Service (QoS) and transmitting them as Physical Layer Protocol Data Units (PPDUs) between physical layers of the WLAN; (d) transmitting a QoS Status Report (QSR) from the non-AP STA to the AP STA, the QSR including information regarding the latency requirements of a particular portion of the buffered MSDU on the non-AP STA; (e) the non-AP STA receiving from the AP STA a scheduling for trigger-based transmission of the buffered MSDU indicated in the QSR to meet the latency requirement of the buffered MSDU; A method comprising:

Images