WO2023069344A1 - Opération de rapport d'état de mémoire tampon de qualité de service - Google Patents

Opération de rapport d'état de mémoire tampon de qualité de service Download PDF

Info

Publication number
WO2023069344A1
WO2023069344A1 PCT/US2022/046845 US2022046845W WO2023069344A1 WO 2023069344 A1 WO2023069344 A1 WO 2023069344A1 US 2022046845 W US2022046845 W US 2022046845W WO 2023069344 A1 WO2023069344 A1 WO 2023069344A1
Authority
WO
WIPO (PCT)
Prior art keywords
traffic
sta
bsr
specific
qos
Prior art date
Application number
PCT/US2022/046845
Other languages
English (en)
Inventor
Liangxiao Xin
Mohamed Abouelseoud
Li-Hsiang Sun
Qing Xia
Original Assignee
Sony Group Corporation
Sony Corporation Of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/936,755 external-priority patent/US20230117842A1/en
Application filed by Sony Group Corporation, Sony Corporation Of America filed Critical Sony Group Corporation
Publication of WO2023069344A1 publication Critical patent/WO2023069344A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/10—Access point devices adapted for operation in multiple networks, e.g. multi-mode access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the technology of this disclosure pertains generally to wireless local area networks operating under IEEE 802.11 , and more particularly to a buffer status collection mechanism which allows an Access Point station to properly arrange transmissions, such as of non-AP stations, such as to satisfy Quality of Service (QoS) requirements.
  • QoS Quality of Service
  • the AP has a limited ability to adjust transmissions toward meeting QoS requirements. These limitations are particularly problematic when handling latency sensitive traffic, as the data can become expired (no longer valid) even before it is sent.
  • a wireless local area network communication apparatus, method and protocol are described which enhance network communications, in particular in regard to fulfilling quality-of-service (QoS) requirements.
  • QoS quality-of-service
  • some traffic can be subject to latency constraints, whereby the data loses its value if the constraint is exceeded.
  • wireless communication are performed in an IEEE 802.11 protocol between stations of a wireless communication network.
  • the described protocol describes a form(s) of specific Buffer Status Report (BSR) and operations making use of the specific BSR.
  • the specific BSR is either received in response to an AP transmitting a specific Buffer Status Request Pole (BSRP) to the non-AP STA, or is received as an unsolicited specific BSR from a non-AP STA.
  • the specific BSR contains specific buffer characteristics, such as: access categories (ACs), traffic identifiers (TIDs), traffic streams, traffic directions, types of traffic and quality of service (QoS) requirements.
  • ACs access categories
  • TIDs traffic identifiers
  • QoS quality of service
  • the AP In response to the specific BSR information received from the non-AP STA, the AP arranges transmissions to optimize communications, such as in satisfying QoS requirements.
  • the present disclosure exemplifies instances of how this information is utilized, such as for handling latency sensitive traffic.
  • FIG. 1 and FIG. 2 are data field diagrams depicting a Medium Access Control (MAC) frame header in FIG. 1 , and its frame body in FIG. 2.
  • MAC Medium Access Control
  • FIG. 3 is a data field diagram depicting a Buffer Status Report (BSR) control subfield as carried by an A-Control subfield of the High Efficiency (HE) variant High Throughput (HT) control field, as defined in IEEE 802.11 ax.
  • BSR Buffer Status Report
  • HE High Efficiency
  • HT High Throughput
  • FIG. 4 is a data field diagram of a Trigger Frame (TF).
  • FIG. 5 is a data field diagram of subfield content within the Common
  • FIG. 6 is a data field diagram of subfield content within the User Information field in the Trigger frame of FIG. 4.
  • FIG. 7 is a hardware block diagram of station (STA) hardware according to at least one embodiment of the present disclosure.
  • FIG. 8 is a hardware block diagram of Multiple-Link Device (MLD) hardware according to at least one embodiment of the present disclosure.
  • MLD Multiple-Link Device
  • FIG. 9 is a flow diagram of an AP sending a specific Buffer Status Report Pole (BSRP) to request a specified (augmented) Buffer Status Report (BSR) from its associated STAs, according to at least one embodiment of the present disclosure.
  • BSRP Buffer Status Report Pole
  • BSR Buffer Status Report
  • FIG. 10 is a flow diagram of a non-AP STA sending a specific Buffer Status Report (BSR) to report its buffer status after it receives a specific BSRP with specific requirements from its associated AP, according to at least one embodiment of the present disclosure.
  • BSR Buffer Status Report
  • FIG. 11 is a data field diagram of a trigger dependent User Info subfield in the user info field of a specific BSRP Trigger frame, according to at least one embodiment of the present disclosure.
  • FIG. 12 is a data field diagram of a specific BSR control subfield, denoted by QoS BSR control subfield, according to at least one embodiment of the present disclosure.
  • FIG. 13 is a data field diagram of specific QoS BSR control subfields, according to at least one embodiment of the present disclosure.
  • FIG. 14 is a network topology for use in the communication examples according to at least one embodiment of the present disclosure.
  • FIG. 15 is a communications diagram of an AP sending a specific BSRP trigger frame with specific requirements for the specific BSR, according to at least one embodiment of the present disclosure.
  • FIG. 16 is a communications diagram of a STA reporting TXOP duration requested for P2P traffic in its buffer, according to at least one embodiment of the present disclosure.
  • FIG. 17 is a communications diagram of an AP requesting buffer status for P2P traffic only, according to at least one embodiment of the present disclosure.
  • FIG. 18 is a communications diagram of an AP sending a specific BSRP trigger frame to request buffer status of multiple ACs, according to at least one embodiment of the present disclosure.
  • FIG. 19 is a communications diagram of a PPDll carrying multiple frames with QoS control fields, according to at least one embodiment of the present disclosure.
  • the Access Point can collect buffer status of the non-AP stations (STAs).
  • FIG. 1 and FIG. 2 depict a Medium Access Control (MAC) frame header in FIG. 1 , and its frame body and its Frame Check Sequence (FCS).
  • An AP sends a Buffer Status Report Poll (BSRP) Trigger Frame (TF) to request a Buffer Status Report (BSR) from the non-AP STAs.
  • BSRP Buffer Status Report Poll
  • TF Buffer Status Report
  • the non-AP STA shall include one or more Quality of Service (QoS) Null frames with QoS Control fields and/or BSR Control subfields in a High Efficiency (HE) Trigger Based (TB) Physical Layer Protocol Data Unit (PPDU).
  • QoS Quality of Service
  • HE High Efficiency
  • TB Physical Layer Protocol Data Unit
  • the BSR can be carried in the BSR control subfield and the QoS control field of the frames.
  • the QoS control field reports the buffer status at the Access Class (AC) level and can be carried in QoS data or QoS Null frames.
  • the BSR control subfield reports the buffer status of a Traffic Identifier (TID) and can be carried in the High Throughput (HT) control field in the QoS data or QoS Null frame or management frame.
  • a non-AP STA can send an unsolicited BSR to the AP.
  • the non-AP STA can aggregate one or more QoS data frames or QoS Null frames carrying QoS control fields in an Aggregate MAC Protocol Data Unit (A-MPDU) to report the buffer status for different TIDs.
  • A-MPDU Aggregate MAC Protocol Data Unit
  • FIG. 3 depicts a BSR control subfield as carried by an A-Control subfield of the High Efficiency (HE) variant HT control field, which is defined in IEEE 802.11 ax.
  • the BSR control subfield is able to report the buffer status of one or more ACs.
  • HE High Efficiency
  • the QoS control field can be used to report the Queue Size and the TXOP Duration Requested.
  • Bit 7 A-MDSU Present
  • Bits 8-15 AP PS Buffer State
  • BSS Service Set
  • TPU Transmit Power Used
  • Bit 4 EOSP
  • Bit 7 A-MDSU Present
  • Bits 8-15 Reserved
  • Bit 4 Reserved
  • Bit 7 A-MDSU Present
  • Bits 8-15 Reserved
  • Bits 11-15 Reserved.
  • the AP can send a BSRP trigger frame to request BSRs from the non-AP STAs.
  • FIG. 4 depicts a Trigger Frame (TF) having the following fields: Frame Control, Duration, Receiver Address (RA), Transmitter Address (TA), Common Information, User Information, and FCS.
  • TF Trigger Frame
  • FIG. 5 depicts the subfield content within the Common Information field of FIG. 4 having the following subfields: Trigger type, UL Length, More TF, CS Required, UL Bandwidth (BW), Gl and HE-LTF Type, MU MIMO HE-LTF Mode, Number of HE-LTF symbols and mid-amble periodicity, UL STBC, LDPC Extra Symbol Segment, AP TX Power, Pre-FEC Padding Factor, PE Disambiguity, UL Spatial Reuse, Doppler, UL High Efficiency Signal (HE- SIG)-A2 Reserved, Reserved, and Trigger Dependent Common Info.
  • Trigger type Trigger type
  • UL Length More TF
  • CS Required UL Bandwidth
  • BW Bandwidth
  • Gl and HE-LTF Type MU MIMO HE-LTF Mode
  • Number of HE-LTF symbols and mid-amble periodicity UL STBC, LDPC Extra Symbol Segment
  • the trigger type field in the common info field of the trigger frame indicates it is a BSPR trigger frame.
  • FIG. 6 depicts the subfield content of the User Information field of the Trigger frame of FIG. 4, having the following subfields: Association Identification (AID12) (12 least significant bits of the intended beamformee's association ID), Resource Unit (RU) Allocation, Coding Type, Modulation Coding Scheme (MCS), Dual Carrier Modulation (DCM), Spatial Stream (SS) Allocation, Target Received signal strength indicator (RSSI), Reserved and Trigger Dependent User Information.
  • Association Identification AID12
  • RU Resource Unit
  • MCS Modulation Coding Scheme
  • DCM Dual Carrier Modulation
  • SS Spatial Stream Allocation
  • RSSI Target Received signal strength indicator
  • Reserved Trigger Dependent User Information
  • Trigger dependent common info field in the common info field or the trigger dependent user info field in the user info field when the trigger frame is a BSRP.
  • the present disclosure notes that the present buffer status report request poll (BSRP) cannot specify requirements for the buffer status report which might be most useful for the AP to receive.
  • the AP may receive buffer status reports carried by the QoS control field, or BSR control subfield in the HT control field in a frame from the non-AP STA.
  • the BSR control subfield in the HT control field cannot differentiate the traffic from different TIDs of the same AC.
  • the AP could be significantly aided by being able to obtain buffer status per TID in some scenarios, such as during Multi-Link Operations (MLOs), so that it can distribute the buffer of different TIDs to the corresponding links according to the TID-to-link mapping setting of the AP.
  • MLOs Multi-Link Operations
  • the current Buffer Status Report cannot differentiate the Peer-2- Peer (P2P) traffic buffer and Uplink (UL) traffic buffer in the same TID of a non-AP STA. It is better for the non-AP STA to report the queue size of UL traffic buffer, instead of the TXOP required time of P2P traffic buffer, so that enough channel resource is allocated by the AP for transmitting P2P traffic.
  • the MCS of the transmitting UL traffic buffer is decided by the AP.
  • the AP estimates and allocates the UL transmission time when it launches a trigger-based UL transmission.
  • the MCS of the transmitting P2P traffic buffer is decided by the non-AP STA, but not the AP.
  • the AP cannot estimate the TXOP time required for transmitting the P2P traffic based on the queue size of the P2P traffic.
  • the non-AP STA estimates the TXOP required time for its P2P traffic based on the MCS. If the non-AP STA reports the TXOP required time for its P2P traffic to the AP, then the AP can allocate TXOP time for the non-AP transmitting the P2P traffic.
  • the current buffer status report cannot report the buffer status per Stream Classification Service (SCS) traffic stream.
  • SCS Stream Classification Service
  • the traffic of a SCS traffic stream may have different QoS requirements, such as Medium Access Control (MAC) Service Data Unit (MSDU) expiration time, than the other traffic in the same TID.
  • MAC Medium Access Control
  • MSDU Service Data Unit
  • the AP can indicate its requirements for the buffer status report from the non-AP STAs. That is to say that the AP can specify the format of the buffer status report from the non- AP STAs, such as the following.
  • the AP can specify that it requires the buffer status at the AC level, TID level, or Traffic Stream (TS) (e.g., SCS) level.
  • TS Traffic Stream
  • the AP can specify the type of traffic, such as latency sensitive traffic or regular traffic, that it requires the buffer status for.
  • the AP can specify the direction of traffic, such as UL, P2P, or UL+P2P, it requires to get buffer status of.
  • the AP can specify whether the QoS requirement, such as the MSDU expiration time, of the buffer is needed in the buffer status report.
  • the non-AP STA can report the buffer status of P2P traffic and UL traffic in the same TID or AC to its associated AP separately, such as exemplified by the following.
  • the AP can launch a trigger-based UL transmission for those UL traffic.
  • the AP can share its TXOP time as required with the non-AP STA and the non-AP STA can transmit P2P traffic of the TID during the shared TXOP time.
  • the non-AP STA may report the TXOP required time of the UL traffic. Then, the AP can share its TXOP time as required with the non-AP STA and the non-AP STA can transmit UL traffic of the TID during the shared TXOP time.
  • the non-AP STA may report the TXOP required time of a traffic stream (e.g., a SCS traffic stream), a TID or an AC, including UL traffic and P2P traffic.
  • the non-AP STA can report the QoS requirement, such as MSDU expiration time, of the buffer to its associated AP.
  • the AP can arrange the transmission to satisfy the QoS requirements of that traffic. For example, the AP should finish the transmission of the traffic before the MSDU expiration time of the traffic.
  • FIG. 7 illustrates an example embodiment 10 of STA hardware configured for executing the protocol of the present disclosure.
  • An external I/O connection 14 preferably couples to an internal bus 16 of circuitry 12 upon which are connected a CPU(s) 18 and memory (e.g., RAM) 20 for executing a program(s) which implement the communication protocol.
  • the host machine accommodates at least one modem 22 to support communications coupled to at least one RF module 24, 28 each connected to one or multiple antennas 29, 26a, 26b, 26c through 26n.
  • An RF module with multiple antennas allows for performing beamforming during transmission and reception. In this way, the STA can transmit signals using multiple sets of beam patterns.
  • Bus 14 allows connecting various devices to the CPU, such as to sensors, actuators and so forth.
  • Instructions from memory 20 are executed on processor 18 to execute a program which implements the communications protocol, which is executed to allow the STA to perform the functions of an access point (AP) station or a regular station (non-AP STA).
  • AP access point
  • non-AP STA non-AP STA
  • the programming is configured to operate in different modes (TXOP holder, TXOP share participant, source, intermediate, destination, first AP, other AP, stations associated with the first AP, stations associated with other AP, coordinator, coordinatee, AP in an OBSS, STA in an OBSS, and so forth), depending on what role it is performing in the current communication context.
  • the STA HW is shown configured with at least one modem, and associated Radio-Frequency (RF) circuitry for providing communication on at least one band.
  • RF Radio-Frequency
  • the present disclosure can be configured with multiple modems 22, with each modem coupled to an arbitrary number of RF circuits. In general, using a larger number of RF circuits will result in broader coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and number of antennas being utilized is determined by hardware constraints of a specific device. A portion of the RF circuitry and antennas may be disabled when the STA determines it is unnecessary to communicate with neighboring STAs.
  • the RF circuitry includes frequency converter, array antenna controller, and so forth, and is connected to multiple antennas which are controlled to perform beamforming for transmission and reception. In this way the STA can transmit signals using multiple sets of beam patterns, each beam pattern direction being considered as an antenna sector.
  • MLD multi-link device
  • FIG. 8 illustrates an example embodiment 40 of a multi-link device (MLD) hardware configuration.
  • a soft AP MLD is a MLD that consists of one or more affiliated STAs, which are operated as APs.
  • the soft AP MLD should support multiple radio operations, such as on 2.4GHz, 5GHz and/or 6GHz.
  • basic link sets are the link pairs that satisfy simultaneous transmission and reception (STR) mode, e.g., basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz).
  • STR simultaneous transmission and reception
  • the conditional link is a link that forms a Non-Simultaneous Transmission and Reception (NSTR) link pair with some basic link(s).
  • these link pairs may comprise a 6 GHz link as the conditional link corresponding to 5 GHz link when 5 GHz is a basic link; 5 GHz link is the conditional link corresponding to 6 GHz link when 6 GHz is a basic link.
  • the soft AP is used in different scenarios including Wi-Fi hotspots and tethering.
  • Multiple STAs are affiliated with an MLD, with each STA operating on a link of a different frequency.
  • the MLD has external I/O access to applications, this access connects to a MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to allow executing a program(s) that implement communication protocols at the MLD level.
  • the MLD can distribute tasks to, and collect information from, each affiliated station to which it is connected, exemplified here as STA 1 42, STA 2 44 through to STA N 46 and the sharing of information between affiliated STAs.
  • each STA of the MLD has its own CPU 50 and memory (RAM) 52, which are coupled through a bus 58 to at least one modem 54 which is connected to at least one RF circuit 56 which has one or more antennas.
  • the RF circuit has multiple antennas 60a, 60b, 60c through 60n, such as in an antenna array.
  • the modem in combination with the RF circuit and associated antenna(s) transmits/receives data frames with neighboring STAs.
  • the RF module includes frequency converter, array antenna controller, and other circuits for interfacing with its antennas.
  • each STA of the MLD does not necessarily require its own processor and memory, as the STAs may share resources with one another and/or with the MLD management entity, depending on the specific MLD implementation. It should be appreciated that the above MLD diagram is given by way of example and not limitation, whereas the present disclosure can operate with a wide range of MLD implementations. [0079] 4. QoS BSR Operation
  • QoS BSR operation defines the Trigger Dependent User Info subfield in the user info field of the specific BSRP Trigger frame to indicate the requirement of the format of the specific BSR for the user (the receiver STA of the user info field). It is important to note that in the current IEEE 802.11 ax standard, the Trigger Dependent User Info subfield is empty in BSRP trigger frame.
  • AP sends a specific BSRP trigger frame with Trigger Dependent User Info subfield in the user info field to request specific information of the buffer status of the user which could help AP or its affiliated MLD allocate channel resource for the transmission of the non-AP STAs which sends BSRs and satisfies the QoS requirement of those transmission.
  • the AP can use a reserved value in the trigger type field in the common info field of the trigger frame to indicate that the trigger frame is a specific BSRP trigger frame under QoS BSR operation (a BSRP trigger frame with the requirement of the format of the BSR for the user). Then, legacy STAs will not parse the trigger dependent user info in the BSRP trigger frame under QoS BSR operation.
  • the QoS BSR operation defines a new BSR control subfield, denoted by QoS BSR control subfield, to allow the non-AP STA to report QoS status of the buffer in the specific BSR, such as expiration time of the MSDll lifetime, or delay bound as indicated in the corresponding QoS characteristics element.
  • FIG. 9 illustrates an example embodiment 110 of an AP sending a specific BSRP to request a specified buffer status report from its associated STAs.
  • the AP determines 112 to collect buffer status from its associated STAs, it specifies 114 its requirement for a specific buffer status report from its associated STA in a specific BSRP trigger frame. Then the AP sends 116 the specific BSRP trigger frame.
  • a check 118 determines if the non-AP STA has received a report of TXOP duration requested of its buffer to the AP. If it has received the report, then at block 122 the AP can send a Single User (Sil) trigger frame, such as in a Multiple-User (MU) Ready-To-Send (RTS) TXS frame to share a TXOP with a non-AP STA according to the TXOP duration requested.
  • MU Multiple-User
  • RTS Ready-To-Send
  • the AP can send a basic trigger frame to trigger UL traffic from the non-AP according to the queue size.
  • FIG. 10 illustrates an example embodiment 150 of a non-AP STA sending a BSR to report its buffer status after it receives a specific BSRP with specific requirement from its associated AP.
  • the non-AP STA receives 152 a specific BSRP containing specific requirements from its associated AP.
  • the non-AP STA sends a specific buffer status report (BSR) to the AP according to the requirements of the AP.
  • the specific buffer status report (BSR) can utilize the format exemplified in FIG. 11 through FIG. 14, and the QoS control fields described following the description of those figures, as well as the existing QoS control field and BSR control subfield as defined in IEEE 802.11 ax.
  • FIG. 11 illustrates an example embodiment 170 of a trigger dependent User Info subfield in the user info field of a specific BSRP Trigger frame.
  • the fields shown in the figure are added to the Trigger dependent user info subfield in the user info field in the specific BSRP trigger frame to indicate the requirement of the BSR of the AP for each user (the intended receiver of the user info field).
  • the AP can set one reserved bit in the user Info field to a first state (e.g., “1”) in the trigger frame as shown in FIG. 4 to indicate the presence of the trigger dependent user info subfield in the user info field when the trigger frame is BSRP.
  • a Buffer Type subfield can be set by the AP to indicate whether the intended receiver of the user info field should report its buffer at the TID level, the AC level, or the traffic stream level. If this field is set to the TID level, then the receiver should send the buffer status per TID. If this field is set to the AC level, then the receiver should send the buffer status per AC. If this field is set to the traffic stream level, then the receiver should send the buffer status per traffic stream, e.g., per SCS traffic stream.
  • a QoS status subfield can be set by the AP to indicate whether the intended receiver of the user info field should report the QoS status of the buffer in the buffer status report.
  • this field comprises a one bit indication, for example when this bit is set to a first state (e.g., “1”), then the receiver should report the QoS status of the buffer in the BSR.
  • the receiver can report the earliest MSDll expiration time of the buffer using QoS BSR Control subfield as shown in FIG. 12 or QoS Control field for QoS BSR in the HT control field as shown in FIG. 13.
  • a Type of traffic subfield can be set by the AP to indicate which type of traffic whose buffer should be reported in the BSR. For example, this field can be set to “latency sensitive traffic” or “all types of traffic”, “EPCS traffic” (as defined in IEEE 802.11 be). When this field is set to “latency sensitive traffic” (or “EPCS traffic”), then the receiver of this field should only report the buffer status of latency sensitive traffic (or “EPCS traffic”, respectively). If this field is set to “all types of traffic”, then the receiver of this field should report the buffer status of all types of traffic.
  • a Traffic Direction subfield is set by the AP to indicate which direction of traffic whose buffer should be reported in the BSR. For example, this field can be set to “UL and P2P”, “P2P only”, and “UL only”. When the receiver of this field reports buffer status of the UL traffic only, it may report queue size in terms of bytes (or bits). When the receiver of this field reports buffer status of the traffic including the P2P traffic, it may report TXOP duration requirements for transmitting the reported traffic. If this field is set to “UL and P2P”, then the receiver of this field should report the buffer status of UL and P2P traffic. If this field is set to “UL only”, then the receiver of this field should only report the buffer status of UL traffic. If this field is set to “P2P only”, then the receiver of this field should report the buffer status of only the P2P traffic.
  • a TID bitmap subfield is set by the AP to indicate which TIDs whose buffer should be reported in the specific BSR. Each bit in this field represents a TID. When the bit is set to a first state (e.g., “1”), then the receiver of this field should report the buffer status of the TID with respect to this bit. Otherwise, the bit is set to a second state (e.g., “0”), and the receiver of this field may not report the buffer status of the TID with respect to this bit.
  • a first state e.g., “1”
  • a second state e.g., “0”
  • a Preferred TID subfield is set by the AP to indicate which TID whose buffer must be reported in the BSR.
  • the receiver of this field has to report the buffer status of the TID indicated in this field in the BSR.
  • An ACI bitmap subfield is set by the AP to indicate which ACs whose buffer should be reported in the specific BSR. Each bit in this field represents an AC. When the bit is set to a first state (e.g., “1”), then the receiver of this field should report the specific buffer status of the AC with respect to this bit. Otherwise, if the bit is set to a second state (e.g., “0”), then the receiver of this field may not report the buffer status of the AC with respect to this bit.
  • a first state e.g., “1”
  • a second state e.g., “0”
  • a Preferred ACI subfield is set by the AP to indicate which AC whose buffer must be reported in the specific BSR.
  • the receiver of this field has to report the buffer status of the AC indicated in this field in the specific BSR.
  • a SCS bitmap subfield is set by the AP to indicate which SCSs whose buffer should be reported in the BSR. Each bit in this field represents a SCS. When the bit is set to a first state (e.g., “1”), then the receiver of this field should report the buffer status of the SCS with respect to this bit. Otherwise, if the bit is set to a second state (e.g., “0”), then the receiver of this field is not to report the buffer status of the SCS with respect to this bit.
  • a first state e.g., “1”
  • a second state e.g., “0”
  • a Preferred SCSID subfield is set by the AP to indicate which SCS whose buffer must be reported in the BSR.
  • the receiver of this field has to report the buffer status of the SCS indicated in this field in the BSR.
  • I mode I option the fields of TID bitmap and Preferred TID are only present when the buffer type field is set to the TID level. In at least one embodiment I mode I option the fields of the ACI bitmap and Preferred ACI are only present when the buffer type field is set to the AC level. In at least one embodiment / mode / option the fields of SCS bitmap and Preferred SCSID are only present when the buffer type field is set to SCS level.
  • the subfield shown in the figure can also be the Trigger Dependent Common Info subfield in the BSRP Trigger frame; which is set by the AP to indicate its specific requirement of the BSRs for all the intended receivers of the specific BSRP trigger frame. If the fields in FIG. 11 become the trigger dependent common info subfield, then the AP can use one reserved bit in the common info field in the specific BSRP trigger frame and set this one reserved bit to a first state (e.g., “1”) to indicate the presence of the trigger dependent common info subfield as shown in FIG. 4 in the common info field in the specific BSRP trigger frame.
  • a first state e.g., “1”
  • FIG. 12 illustrates an example embodiment 210 of a new BSR control subfield, denoted by QoS BSR control subfield, in the HT control field in a MAC frame to report buffer status with more information compared with the current BSR control subfield in IEEE 802.11 ax.
  • FIG. 1 The figure depicts example fields that can be included in the QoS BSR control subfield according to the present disclosure as described below.
  • a Buffer Type field is set by the non-AP STA to indicate the format of SCSID I TID I ACI field.
  • SCS SCSID I TID I ACI field
  • TID SCSID I TID I ACI field
  • AC SCSID I TID I ACI field
  • a SCSID I TID I ACI field is set by the non-AP STA to represent a SCS, then the receiver can recognize that the buffer status reported in the same QoS BSR Control subfield is for buffer status of the SCS. If non-AP STA sets this field to represent a TID, then the receiver can recognize that the buffer status reported in the QoS BSR Control subfield is for buffer status of the TID. If a non-AP STA sets this field to represent an AC, then the receiver can recognize that the buffer status reported in the QoS BSR Control subfield is for buffer status of the AC.
  • a Queue Size Indication field is set by the non-AP STA to indicate whether the buffer status in the QoS BSR Control subfield is reported in terms of TXOP duration or Queue Size. For example, if this field is set to a first state (e.g., “1”), then the buffer status is reported in terms of TXOP duration which can be indicated in the TXOP duration requested before the Expiration field and the TXOP duration requested field. If this field is set to a first state (e.g., “1”), then the buffer status is reported in terms of bytes which could be indicated in the Expiring queue size field and queue size field.
  • a first state e.g., “1”
  • An Expiring Queue Size field is set by the non-AP STA to indicate the queue size (buffer size) that will be expired by the earliest MSDll expiration time (or the queue size that is required to be transmitted by the earliest MSDll expiration time).
  • the AP receiving this field should finish the buffer reported in this field before the earliest MSDll expiration time.
  • the Expiring Queue Size field can represent a partial queue size of the traffic indicated in the SCSID I TID I ACI field.
  • a Queue Size field is set by the non-AP STA to indicate the total queue size (in terms of bits) of the traffic indicated in the SCSID I TID I ACI field that is reported in the QoS BSR subfield.
  • the AP receiving this field can arrange the trigger-based transmission for the traffic reported in this field.
  • a TXOP duration requested before Expiration field is set by the non-AP STA to indicate the TXOP duration it is requesting so that it may complete traffic transmission that will be expired by the earliest MSDU expiration time.
  • the AP receiving this field should trigger a TXOP sharing (e.g., triggered TXOP sharing procedure as defined in IEEE 802.11 be) with the non-AP STA and shares the TXOP duration indicated in this field before the earliest MSDU expiration time.
  • this field could be set to a value, for instance in units of milliseconds or microseconds, to represent the channel time (e.g., in units of milliseconds or microseconds) that the non-AP STA requires the AP to share TXOP with it on a 20 MHz channel bandwidth.
  • the AP may vary the TXOP sharing time with the non-AP, depending on the exact BW utilized by the AP sharing the TXOP with the non-AP STA.
  • this field can be set to a value, for instance in units of milliseconds, to represent the channel time (e.g., in units of milliseconds or microseconds) over the channel bandwidth of the current TXOP.
  • the non- AP sets the value of this field, e.g., y ms, to represent that it requires y ms TXOP sharing time over x MHz channel BW. If the AP can only share TXOP over z MHz channel BW later, it may share TXOP time with y/x*z ms.
  • a TXOP duration requested field is set by the non-AP STA to indicate the TXOP duration it is requesting so that it may complete the transmission of all the traffic that is indicated in the SCSID I TID I ACI field of the QoS BSR subfield.
  • the AP receiving this field can trigger a TXOP sharing (e.g., triggered TXOP sharing procedure as defined in IEEE 802.11 be) with the non- AP STA and shares the TXOP duration indicated in this field.
  • the value of this field can be similar to the TXOP duration requested before Expiration field.
  • An Earliest MSDll Expiration Time field is set by the non-AP STA to indicate the earliest expiration time of the MSDll lifetime (or latency bound) of the buffer reported in the QoS BSR control field.
  • the AP receiving this field should arrange the transmission before the earliest MSDll expiration time to let the MSDU be transmitted before its lifetime expires (or before latency bound is reached).
  • this field is set to the remaining time before the MSDU expires (or before latency bound is reached) since the frame carrying the QoS BSR control subfield is received by the AP.
  • I mode I option this field is set to the TSF time of the AP at which time an MSDU would expire in the buffer.
  • TSF time When this field is set to TSF time, some least significant bits and some most significant bits may not be included in this field due to limited bit size. If so, then those least significant bits are considered as zeros (or ones). TSF time represents the nearest future time that matches the bits in the field plus those least significant bits not included in the field.
  • a Traffic Direction field is set by the non-AP to indicate the direction of the traffic reported in the QoS BSR control subfield.
  • this field can be set to a value for at least indicating “UL and P2P”, “P2P only”, and “UL only”.
  • the station receiving this field reports buffer status of the UL traffic only, it may report queue size in terms of bytes (or bits).
  • the station receiving of this field reports buffer status of the traffic including the P2P traffic, it may report TXOP duration it needs to transmit the traffic reported.
  • this field is set to “UL and P2P”, then the receiver of this field knows the QoS BSR control subfield reports the buffer status of UL and P2P traffic.
  • this field is set to “UL only”, then the receiver of this field knows the QoS BSR control subfield reports the buffer status of UL traffic only.
  • Type of traffic non-AP STA sets this field to indicate which type of traffic is reported in the QoS BSR Control subfield. For example, this field can be set to “latency sensitive traffic” or “all types of traffic” or “EPCS traffic”. When this field is set to “latency sensitive traffic” (or “EPCS traffic”), then the receiver of this field will recognize that the QoS BSR control field only reports the buffer status of latency sensitive traffic (or EPCS traffic, respectively). If this field is set to “all types of traffic”, then the receiver of this field will recognize that the QoS BSR control field reports the buffer status of all types of traffic.
  • FIG. 13 illustrates an example embodiment 250 of a specific QoS BSR control subfield. Due to the limited length of the HT control field, QoS BSR control subfield cannot be longer than 26 bits if it is carried in the A-Control subfield of the HT control field. Then, in this instance only some of the fields as shown in this figure may be utilized in the QoS BSR control subfield.
  • the Control ID field in the A-control subfield can be set to indicate that there is a QoS BSR control subfield following it. Inside the QoS BSR control subfield, it contains buffer type field, SCSID I TID I ACI field, Queue Size Indication field, Queue Size I TXOP duration requested field (or expiring queue size I TXOP duration requested before expiration field), Earliest MSDU Expiration time field; as explained in previous sections. The following should be noted.
  • Queue Size indication is set to indicate whether the Queue Size I TXOP duration requested field represents a Queue Size field or a TXOP duration requested field. For example, if this field is set to a first state (e.g., “1”), then the Queue Size I TXOP duration requested field represents a Queue Size field. Otherwise, this field is set to a second state (e.g., “0”) and the Queue Size I TXOP duration requested field represent a TXOP duration requested field.
  • the bits in the figure represent the length of each field in the QoS BSR Control subfield. It will be noted that the Queue size I TXOP duration requested field is exemplified using 10 bits for establishing queue size.
  • Implementations of the present disclosure may be configured with these bits being utilized as a single size value or as a scaling value plus a size value. It should be appreciated that the sizing of the queue can utilize any desired number of bits and format without departing from the teachings of the present disclosure.
  • the QoS BSR control subfield can be transmitted the same as the BSR control field. It should also be noted that multiple values in the Control ID field can be used to indicate different types of QoS BSR Control subfields. Each value in the Control ID field represents one different QoS BSR control subfield.
  • I mode I option when a non-AP STA reports the Queue size in the QoS BSR control subfield, it is expected to: (a) receive at least one TF from the AP before the earliest MSDll Expiration time indicated in the QoS BSR control subfield, and/or (b) finish the transmission of the buffer indicated in the Queue size subfield before the earliest MSDll Expiration time.
  • I mode I option when a non-AP STA reports the TXOP duration requested in the QoS BSR control subfield, it is expected to: (a) receive a MU RTS TXS trigger frame from AP before the earliest MSDU Expiration time indicated in the QoS BSR control subfield, and/or (b) receive one or more periods of triggering TXOP sharing time (which is allocated by MU RTS TXS trigger frame from AP) as indicated in TXOP duration request subfield in the QoS BSR control subfield whereby the end time of the last period of triggering TXOP sharing time is earlier than the earliest MSDU Expiration time.
  • I mode I option the QoS control field can be used to carry QoS status; as exemplified below. Formats are described below for QoS control fields for QoS BSR based on application frame type. In each of these instances Bits 0-3 are for TID and Bits 5-6 are for Ack policy indication.
  • bits 8-15 MSDll expiration time.
  • bits 8-15 TXOP Duration Requested and MSDll expiration time
  • bits 8-15 Queue size and MSDll expiration time.
  • bits 8-15 can be used to indicate the MSDU expiration time of the buffer of the TID indicated in Bit 0-3.
  • a new application frame type is used to carry buffer status.
  • a QoS R-TWT Data I Null frame is defined as a new application frame type.
  • Bit 7 is set to a second state (e.g., “0”), then Bits 8-15 can be used to indicate the TXOP duration requested and MSDU expiration time of the buffer of the TID indicated in Bits 0-3.
  • Bits 8-15 can be used to indicate the Queue size and MSDU expiration time of the buffer of the TID indicated in Bits 0-3.
  • Bit 4 can be used to indicate whether the transmitter of this field has more data to transmit during a R-TWT SP. For example, if more data is set to a first state (e.g., “1”), then the transmitter of this field does not have data to transmit during the R-TWT SP.
  • a first state e.g., “1”
  • the Bits 5-15 can be reserved or used for other purposes. Otherwise, when this More data field is set to a second state (e.g., “0”).
  • I mode I option Bit 4 can be used to indicate whether the frame carries latency sensitive traffic or not. If it is set to a first state (e.g., “1”), then the frame carries latency sensitive traffic. Otherwise, this field is set to a second state (e.g., “0”) indicating that the frame does not carry latency sensitive traffic.
  • Ack Policy Indicator can be identical to that defined in IEEE 802.11.
  • FIG. 14 illustrates an example network topology 310 utilized for the following example cases. It should be appreciated that the topology is utilized by way of example and not limitation, as the teachings of the present disclosure are not limited to any specific network topology.
  • the example topology depicts a single AP (AP1 ) 316 and multiple STAs, depicted as STA2 318 and STA3 320 that are associated with AP1 .
  • the topology is shown in an area 312 (depicted as room 312 having with apertures (doors/windows) 314).
  • AP1 may be affiliated with a Multi-Link Device (MLD); while STA2 and/or STA3 may also be affiliated with an MLD.
  • MLD Multi-Link Device
  • AP1 is able to send a specific BSRP frame containing specific requirements for the BSR.
  • the specific requirement for each user can be carried in the trigger dependent user info subfield in the user info field in the BSRP trigger frame.
  • the format of trigger dependent user info subfield was shown in FIG. 11 .
  • STA2 and STA3 are able to send a frame carrying the BSR or QoS BSR control subfield in the HT control field and/or the QoS control field.
  • the format of QoS BSR control subfield is shown in FIG. 12 and FIG. 13.
  • the format of QoS control field could be the same as defined in IEEE 802.11 or as described in Section 6.1 .
  • the format of BSR control subfield can be the same as in the IEEE 802.11 ax.
  • Table 1 exemplifies buffer status for non-AP STAs in the following examples.
  • Example 1 AP1 Collecting SCS2 Buffer Status w/QoS Status
  • FIG. 15 illustrates an example embodiment 350 of AP1 sending a specific BSRP trigger frame with specific requirements for the specific BSR.
  • the interaction is between AP1 316, STA2 318 and STA 320.
  • AP1 sends a specific BSRP trigger frame 352 to request STA2 to send its buffer status of SCS2 traffic stream with QoS status over RU1 and STA3 to its buffer status of TID5 over RU2.
  • STA2 After STA2 receives the specific BSRP trigger frame, it sends a QoS Null frame with preamble 354 and having an HT control field carrying a QoS BSR control subfield through RU1 358. In the QoS specific BSR control subfield, STA2 reports that it has 50 bytes of SCS2 traffic in the buffer and the earliest MSDll lifetime expiration time 362 of SCS2 traffic is in 3ms.
  • STA3 After STA3 receives the BSRP trigger frame, it sends a QoS null frame with preamble 356 and a QoS control field carrying the buffer status report through RU2 360. In the QoS control field, it reports that it has 100 bytes TID5 traffic in the buffer.
  • AP1 should arrange the transmission for the traffic reported in the BSRs.
  • AP1 in this example finishes the transmission of SCS2 in 3 ms in order to avoid the expiration of MSDlls in SCS2.
  • AP1 sends a TF 364.
  • STA2 sends UL traffic for SCS2, having preamble 366 and RU3 data 370; and STA3 sends preamble 368 with RU4 372 having TID5.
  • AP1 allocated more resources for the traffic of SCS2 of STA2 (i.e., RU3) than for the traffic of TID5 of STA3 (i.e. , RU4), as can be seen by their relative sizes in the figure.
  • AP1 responds with a BA 374.
  • FIG. 16 illustrates an example embodiment 410 of a STA reporting TXOP duration requested for P2P traffic in its buffer. As in the previous figure, the interaction is between AP1 316, STA2 318 and STA3 320.
  • AP1 sends a specific BSRP trigger frame 412 to request STA2 to report its buffer status of the latency sensitive traffic of TID6 with QoS status, and for STA3 to report its buffer status.
  • STA2 After STA2 receives the specific BSRP trigger frame, it sends a QoS null frame, shown with preamble 414 and with RU1 418 having QoS BSR control subfield in the HT control field through RU1 to report its buffer status as requested by AP1 .
  • the QoS BSR control subfield indicates that STA2 has latency sensitive traffic of TID6 (i.e. , SCSI and SCS2) in its buffer. Since the latency sensitive traffic of TID6 contains P2P traffic (i.e., SCSI ), the QoS BSR control subfield reports the TXOP duration it requests within which to transmit the latency sensitive traffic of TID6 in its buffer. Also, the QoS BSR control subfield indicates that there is at least one MSDll of the latency sensitive traffic of TID6 that will expire 422 in 2 ms.
  • STA3 After STA3 receives the BSRP trigger frame, it realizes that the AP has not specified any requirements for the BSR. Thus, it sends a QoS null frame with preamble 416 and RU2 420 carrying the legacy BSR control subfield in the HT control field back to AP1 . It reports that it only has 400 bytes AC_VI traffic in the buffer.
  • AP1 sends a RTS TXS trigger frame 424 to launch a trigger TXOP sharing with STA2.
  • STA2 responds with CTS frame 426, it is provided in this example a sharing time 428 of 0.5 ms of the TXOP time as shared by AP1 to transmit its latency sensitive traffic P2P data of SCSI 430 and UL data of SCS2 434.
  • the BA 432 in response to the data frame of SCSI is sent by a non-AP STA which is not AP1 .
  • AP1 sends BA 436.
  • AP1 sends a basic trigger frame 438 to trigger the UL transmission 440 of STA3 for traffic buffer reporting.
  • FIG. 17 illustrates an example embodiment 510 of an AP requesting buffer status for P2P traffic only. As in the previous figure, the interaction is between AP1 316, STA2 318 and STA 320.
  • AP1 sends a specific BSRP trigger frame 512 to request BSRs from STA2 and STA3.
  • AP1 requests STA2 to report its buffer status of the P2P traffic of AC_V0, and for STA3 to report its buffer status with no specific requirement.
  • STA2 sends its buffer status report shown with preamble 514, in a frame in RU1 518 carrying the QoS BSR subfield in the HT control field to indicate its buffer status.
  • the QoS BSR subfield indicates that STA2 has the P2P traffic of AC_VO (i.e., SCS0 and SCSI ) in its buffer and requesting an 0.8 ms TXOP duration 528 to transmit those P2P traffic of AC_VO.
  • the earliest MSDll expiration time in that P2P traffic is 2 ms 522.
  • STA3 After STA3 receives the BSRP trigger frame, it realizes that the AP has not specified any requirements for the BSR. Thus, it sends a QoS null frame having preamble 516 and carrying in RU2 520 with the legacy BSR control subfield in the HT control field back to AP1 . It reports that it only has 400 bytes AC_VI traffic in the buffer.
  • AP1 first sends a RTS TXS trigger frame 524 to launch a triggered TXOP sharing with STA2 to ensure the P2P traffic of AC_V0 of STA2 can be transmitted in 2 ms.
  • the RTS TXS trigger frame allocates 0.8 ms TXOP sharing time 528 to STA2.
  • STA2 responds with a CTS frame 526, STA2 starts to transmit the P2P traffic of AC_V0. Since the traffic of SCSI is latency sensitive but the traffic of SCS0 is not latency sensitive, STA2 transmits the traffic of SCSI 530 earlier than the traffic of SCS0 534. After receiving these transmissions, AP1 responds with BAs 532 and 536.
  • AP1 triggers 538 the UL transmission of STA3 for the traffic buffer reported by STA3.
  • STA3 responds by sending UL Data 540; to which AP1 responds with a BA 542.
  • FIG. 18 illustrates an example embodiment 610 of an AP sending a specific BSRP trigger frame to request buffer status of multiple ACs. As in the previous figure, the interaction is between AP1 316, STA2 318 and STA 320.
  • the AP can specify which ACs whose buffer status it would like information on in the BSRP trigger frame.
  • AP1 sends a specific BSRP trigger frame 612 and specifies that it needs the buffer status report of the UL traffic of AC_V0 and AC_VI from STA2.
  • AP1 also requests buffer status report from STA3 in the BSRP trigger frame but does not specify any special requirements.
  • STA2 sends two frames within this transmission in the TB PPDII to report its buffer status of AC_VO and AC_VI. This transmission is seen with preamble 614 and using RU1 618.
  • Each frame carries the QoS BSR control subfield in the HT control field.
  • the first frame reports 450 bytes UL traffic of AC_VO in its buffer. Since there is latency sensitive traffic in the UL traffic of AC_VO (i.e., SCS2), the QoS BSR control subfield also indicates the earliest MSDU expiration time for the buffer is 2 ms.
  • the second frame indicates 150 bytes UL traffic of AC_VI in the buffer.
  • STA3 Since there is no specific requirements given it from AP1 , STA3 sends a frame with preamble 616 and RU2 620 carrying a legacy BSR control subfield in the HT control field to report its 400 bytes UL traffic buffer.
  • AP1 can arrange the transmission for STA2 and STA3 according to the buffer status reports it receives from STA2 and STA3 (not shown in the figure).
  • FIG. 19 illustrates an example embodiment 710 of a PPDU carrying multiple frames with QoS control fields. As in the previous figure, the interaction is between AP1 316, STA2 318 and STA 320.
  • the QoS control fields in the same PPDU can be used for the buffer status report of the same TID as well as the buffer status reports of the different TIDs.
  • AP1 When AP1 sends a BSRP trigger frame 712, it requests STA2 to report the buffer status of its UL latency sensitive traffic of TID6 with QoS status. AP1 also requests STA3 to report the buffer status of its traffic of TID4 and TID5.
  • STA2 sends a TB PPDU carrying two frames as a transmission with preamble 714 and RU1 718.
  • Each frame carries the QoS control field.
  • One QoS control field reports that the queue size of the UL latency sensitive traffic of TID6 (i.e., SCS2) in the buffer of STA2 is 50 bytes.
  • the other QoS control field reports that at least one MSDU of the UL latency sensitive traffic of TID6 will expire in 3 ms.
  • STA3 also sends two frames in the TB PPDU in response to the BSPR trigger frame. This transmission is shown with preamble 716 and RU2 720.
  • One frame carries the QoS control field which reports its buffer status of TID5, and the other frame carries the QoS control field which reports its buffer status of TID6.
  • AP1 can arrange the transmission for STA2 and STA3 according to the buffer status reports it receives from STA2 and STA3 (not shown in the figure).
  • the different sets should have at least a common setup link for the AP MLD to solicit TB PPDUs for the TIDs if there is a (setup/enabled) link between the non-AP MLD and the AP MLD to which all the (UL) TIDs of the AC is not mapped (and buffer status of any of the TIDs is not provided to an AP MLD).
  • I mode I option the (UL) TIDs are always mapped to the same AC to the same set of links in the UL direction if there is a (setup/enabled) link between the non-AP MLD and the AP MLD to which all the (UL) TIDs of the AC is not mapped (and buffer status of any of the TIDs is not provided to an AP MLD).
  • one MPDU (e.g., QoS Null frame) can carry one BSR (or QoS BSR) in the A-control field of the HE variant HT control field and one QoS control field (carrying queue size or TXOP duration requested) at the same time.
  • the ACI High could be set to an AC and the queue size High can be set to the buffer status of the AC.
  • the TID field of the QoS control field is set to one TID of the AC and the corresponding queue size is set to the queue size of that TID.
  • the AP receives this MPDU, it thus knows the queue size of the other TID of the AC is (queue size of the ACI High in BSR - queue size of the TID in QoS control field).
  • the buffer status report in the QoS control field is not subject to the TID-to-Link mapping.
  • a QoS null frame carrying the queue size or TXOP duration request of a TID in the QoS control field can be transmitted over any link, even if the TID indicated in the QoS control field is not mapped to that link.
  • I mode I option that only the BSR or QoS BSR reports the buffer status of the TIDs that is mapped to the link where the BSR is transmitted.
  • I mode I option only BSR or QoS BSR report the buffer status of the TIDs that the non-AP STA expects to let AP trigger over the link where the BSR or QoS BSR is transmitted.
  • the buffer status reported to the AP can be less than that in the buffer of the non-AP STA.
  • I mode I option the BSR or QoS BSR of an AC from a non-AP STA can be shared between different links of the AP if the (UL) TID-to-Link mapping of that AC of that non-AP STA on those links is the same.
  • UL TID6 and TID7 of the non-AP STA are mapped to Linkl and Link2, and only UL TID6 of the non-AP STA is mapped to Link3 and Link4.
  • the AP MLD can share the BSR or QoS BSR of AC_VO (received on Link 1 or Link2) (AC for TIDs 6 and 7) of the non-AP STA between Linkl and Link2 (but cannot share with Link3 and Link4).
  • the AP MLD can share the BSR or QoS BSR of AC_VO (received on Link3 or Link4) of the non-AP STA between Link3 and Link4 (but cannot share with Linkl and Link2).
  • I mode I option the AP can allocate different channel resources (e.g., the UL length subfield in the common info field of BSRP, RU allocation subfield, UL HE-MCS subfield in user info field of BSRP) in the BSRP trigger frame to indicate the granularity of the BSR (e.g., AC level or TID level) it expects to receive from the non-AP STA.
  • the non-AP STA should report as many details as possible to the AP using the channel resource allocated by the AP in the BSRP.
  • the non-AP STA should send as many QoS Null frames carrying queue size (or TXOP duration requested) of a TID as possible using the channel resource allocated by BSRP.
  • the AP allocates a channel resource(s) in BSRP that allows a non-AP STA to transmit a QoS Null frame carrying BSR subfield in the A-control field of the HE variant HT control field and QoS control field (e.g., queue size of a TID)
  • the non-AP STA has to respond with a QoS Null frame carrying BSR subfield in A-control field of the HE variant HT control field and QoS control field.
  • the AP allocates a channel resource in BSRP that allows a non-AP STA to transmit multiple QoS Null frames (e.g., one QoS Null frame with BSR subfield and QoS control field + three QoS Null frames with QoS control field), then the non-AP STA has to respond with the corresponding number of QoS Null frames.
  • QoS Null frames e.g., one QoS Null frame with BSR subfield and QoS control field + three QoS Null frames with QoS control field
  • I mode I option only one QoS null frame will carry BSR subfield in response to the BSRP of AP.
  • I mode I option no QoS null frame carries BSR subfield in response to BSRP.
  • I mode I option if the BSR subfield is included in the response to the BSRP, then only one of the QoS control fields of the TIDs of the ACI High subfield in the BSR. For example, if SCI High is AC_VO (corresponding to TID6 and TID7), then the response to the BSRP could only carry the QoS control field of TID6 (or the QoS control field of TID7 instead).
  • I mode I option the QoS control fields should report the buffer status of the TID with higher priority first.
  • the non-AP STA may only report the QoS control fields of the TIDs that are mapped to the link of the non-AP STA.
  • the non-AP STA may only report the QoS control fields of the TIDs of which the ACs has at least one TID that is not mapped to the link of the non- AP STA. For example, if TID6 of AC_VO is mapped to the link of the non-AP STA, but TID7 of AC_VO is not, then the non-AP STA can only report the QoS control fields of TID6. If both TID6 and TID7 are mapped to the link, then the non-AP STA does not report the QoS control fields of TID6 or TID7.
  • Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and/or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products.
  • each block or step of a flowchart, and combinations of blocks (and/or steps) in a flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer-readable program code.
  • any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for implementing the function(s) specified.
  • blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s).
  • each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.
  • these computer program instructions may also be stored in one or more computer-readable memory or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).
  • the computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer- implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure (s) algorithm(s), step(s), operation(s), formula(e), or computational depiction(s).
  • programming or “program executable” as used herein refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein.
  • the instructions can be embodied in software, in firmware, or in a combination of software and firmware.
  • the instructions can be stored local to the device in non-transitory media, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely. Instructions stored remotely can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.
  • processor hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.
  • An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit, as a wireless station (STA) which is a separate STA or as a STA in a multiple-link device (MLD), and operating as either an Access Point (AP) STA or a non-AC STA, for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to said wireless communication circuit for operating on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein said instructions, when executed by the processor, perform steps of a wireless communications protocol for said wireless communication circuit, comprising: (d)(i) transmitting a specific buffer status request pole (BSRP), from said STA operating as an AP, for a specific buffer status report (BSR) from a non-AP STA; (d)
  • BSRP buffer
  • An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit, as a wireless station (STA) which is a separate STA or as a STA in a multiple-link device (MLD), and operating as either an Access Point (AP) STA or a non-AC STA, for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to said wireless communication circuit for operating on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein said instructions, when executed by the processor, perform steps of a wireless communications protocol for said wireless communication circuit, comprising: (d)(i) receiving a buffer status report (BSR) by said STA operating as an access point (AP), as received from a non-AP STA; (d)(ii) wherein said BSR is
  • a method of performing wireless communication in a network comprising: (a) performing wireless communication between stations of a wireless communication network using communications protocol including performing carrier sense multiple access/collision avoidance (CSMA/CA); (b) receiving a specific buffer status report (BSR) from a non-AP STA, by a STA operating as an access point (AP); (c) wherein said specific BSR is either received in response to said AP transmitting a specific buffer status request pole (BSRP) to the non-AP STA, or is received as an unsolicited specific BSR from said non-AP STA; (d) wherein said specific BSR contains specific buffer characteristics consisting of: access categories (ACs), traffic identifiers (TIDs), traffic streams, traffic directions, types of traffic and quality of service (QoS) requirements; and (e) wherein in response to receiving said specific BSR from said non-AP STA, the AP arranges transmissions to satisfy QoS requirements.
  • CSMA/CA carrier sense multiple access/collision avoidance
  • TXOP transmit opportunity
  • TID traffic identifier
  • AC access class
  • TXOP required time is for either uplink (UL) traffic and/or peer-to-peer (P2P) traffic.
  • UL uplink
  • P2P peer-to-peer
  • TXOP required time is for a traffic stream comprising a stream classification service (SCS) traffic stream.
  • SCS stream classification service
  • TXOP transmit opportunity
  • UL uplink
  • the AP arranges transmissions to satisfy quality of service (QoS) requirements with the AP completing transmission of traffic, identified by the non-AP STA in its response to the buffer status request, before the medium access control (MAC) service data unit (MSDll) expiration time of the traffic.
  • QoS quality of service
  • MSDll medium access control
  • Phrasing constructs such as “A, B and/or C”, within the present disclosure describe where either A, B, or C can be present, or any combination of items A, B and C.
  • references in this disclosure referring to “an embodiment”, “at least one embodiment” or similar embodiment wording indicates that a particular feature, structure, or characteristic described in connection with a described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a specific embodiment which differs from all the other embodiments being described.
  • the embodiment phrasing should be construed to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system or method.
  • a set refers to a collection of one or more objects.
  • a set of objects can include a single object or multiple objects.
  • Relational terms such as first and second, top and bottom, upper and lower, left and right, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
  • the terms can refer to a range of variation of less than or equal to ⁇ 10% of that numerical value, such as less than or equal to ⁇ 5%, less than or equal to ⁇ 4%, less than or equal to ⁇ 3%, less than or equal to ⁇ 2%, less than or equal to ⁇ 1 %, less than or equal to ⁇ 0.5%, less than or equal to ⁇ 0.1 %, or less than or equal to ⁇ 0.05%.
  • substantially aligned can refer to a range of angular variation of less than or equal to ⁇ 10°, such as less than or equal to ⁇ 5°, less than or equal to ⁇ 4°, less than or equal to ⁇ 3°, less than or equal to ⁇ 2°, less than or equal to ⁇ 1 °, less than or equal to ⁇ 0.5°, less than or equal to ⁇ 0.1 °, or less than or equal to ⁇ 0.05°.
  • Coupled as used herein is defined as connected, although not necessarily directly and not necessarily mechanically.
  • a device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un mécanisme de rapport d'état de mémoire tampon, tel que dans un sondage de demande d'état de mémoire tampon (BSRP), le point d'accès (AP) communiquant le type spécifique d'informations que la station non AP (STA) doit communiquer en retour, par exemple dans un rapport d'état de mémoire tampon (BSR), en ce qui concerne les mémoires tampons. Les exigences spécifiées par l'AP pour le BSR sont des caractéristiques : des catégories d'accès (AC), des identifiants de trafic (TID), des flux de trafic, des directions de trafic et/ou des types de trafic et des exigences de qualité de service (QoS) qui permettent à l'AP d'agencer correctement des transmissions pour satisfaire aux exigences de QoS.
PCT/US2022/046845 2021-10-20 2022-10-17 Opération de rapport d'état de mémoire tampon de qualité de service WO2023069344A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202163262801P 2021-10-20 2021-10-20
US63/262,801 2021-10-20
US202263324701P 2022-03-29 2022-03-29
US63/324,701 2022-03-29
US17/936,755 2022-09-29
US17/936,755 US20230117842A1 (en) 2021-10-20 2022-09-29 Quality of service buffer status report operation

Publications (1)

Publication Number Publication Date
WO2023069344A1 true WO2023069344A1 (fr) 2023-04-27

Family

ID=84357788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/046845 WO2023069344A1 (fr) 2021-10-20 2022-10-17 Opération de rapport d'état de mémoire tampon de qualité de service

Country Status (1)

Country Link
WO (1) WO2023069344A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210259033A1 (en) * 2020-01-31 2021-08-19 Lg Electronics Inc. Techniques for performing multi-link communication in wireless local area network system
WO2021185211A1 (fr) * 2020-03-16 2021-09-23 华为技术有限公司 Procédé et dispositif de transmission de données

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210259033A1 (en) * 2020-01-31 2021-08-19 Lg Electronics Inc. Techniques for performing multi-link communication in wireless local area network system
WO2021185211A1 (fr) * 2020-03-16 2021-09-23 华为技术有限公司 Procédé et dispositif de transmission de données
EP4114076A1 (fr) * 2020-03-16 2023-01-04 Huawei Technologies Co., Ltd. Procédé et dispositif de transmission de données

Similar Documents

Publication Publication Date Title
CN112074020B (zh) 一种适用于多链路的通信方法及相关设备
RU2771290C2 (ru) Устройство передачи и способ передачи
US11516846B2 (en) RTA packet duplication in time and frequency
WO2021203850A1 (fr) Procédé de négociation pour mode de fonctionnement, extrémité de lancement, extrémité de réception, système de puce et support
US20230199847A1 (en) Fast restricted target wait time update
US20230058871A1 (en) Stream classification service (scs) with restricted target wait time (r-twt) setup
US20230117842A1 (en) Quality of service buffer status report operation
KR20080022208A (ko) 스마트 안테나를 갖는 무선 통신 시스템에서 데이터를송수신하는 방법 및 장치
US11758471B2 (en) Broadcast frame with feedback
US20230269788A1 (en) Dynamic edca in r-twt initial access
US20230199647A1 (en) Multiple station access in a reserved target-wait-time service period
US20220345973A1 (en) Secondary link access to a mobile soft access point multi-link device
WO2023069344A1 (fr) Opération de rapport d'état de mémoire tampon de qualité de service
WO2023017340A1 (fr) Achèvement de période de service de temps de réveil cible limité
US20240080891A1 (en) Enhanced quality of service status report that supports latency requirements
US20240008081A1 (en) Triggered txop sharing with ac limitation
US20230319620A1 (en) Transmit identifier to user priority / ac mapping
WO2023114673A1 (fr) Accès à plusieurs stations dans une période de service à temps d'attente cible réservé
WO2022054628A1 (fr) Dispositif de communication
US20230262770A1 (en) Transmit opportunity sharing in a restricted target wait time
US20230254897A1 (en) Block acknowledgement agreement for latency sensitive traffic stream
WO2022130277A1 (fr) Trame de diffusion avec retour d'information
WO2022224084A1 (fr) Accès de liaison secondaire à un dispositif multi-liaison point d'accès logiciel mobile
KR20230001539A (ko) 무선랜에서 emlsr 동작을 위한 방법 및 장치
WO2024091480A1 (fr) Sélection de schéma de transmission multi-ap

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22802804

Country of ref document: EP

Kind code of ref document: A1