CN117397346A - non-R-TWT member STA access grant for bursty traffic transmission - Google Patents

Abstract

Enabling a non-AP STA to initiate R-TWT negotiations with a scheduling AP within an ongoing R-TWT SP to request temporary or long-term membership of the current ongoing R-TWT SP, or to set a new temporary or long-term R-TWT SP after the current SP but before its initially membership SP, or to contend for an RA-RU in the current R-TWT SP if the UORA feature is enabled, wherein the non-AP STA is a scheduled STA with membership in the R-TWT scheduled STA that has queued emergency bursts for RTA traffic of the AP during the ongoing R-TWT SP that does not have R-TWT membership. Thus, non-R-TWT member STAs are granted access for their bursty traffic transmissions.

Description

non-R-TWT member STA access grant for bursty traffic transmission

Cross Reference to Related Applications

The present application claims priority and benefit from U.S. patent application Ser. No. 18/052,664, filed on 4/11/2022, which is incorporated herein by reference in its entirety. The present application claims priority and benefit from U.S. provisional patent application Ser. No. 63/264,127 filed 11/16 of 2021, which provisional patent application is incorporated herein by reference in its entirety.

Statement regarding federally sponsored research or development

Is not suitable for

Notification of copyrighted material

Some of the material in this patent document may be subject to copyright protection in accordance with the united states and other national copyright laws. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not disclaim any rights to the patent document to which it remains secret, including, but not limited to, its rights in accordance with 37c.f.r. ≡1.14.

Technical Field

The technology of the present disclosure relates generally to wireless network communications under CSMA/CA, and more particularly to increasing real-time packet traffic when using R-TWT SPs.

Background

Current wireless technologies using CSMA/CA focus on high throughput network performance. However, more and more applications, such as real-time applications (RTAs), require low latency communications. The data generated from the RTA is referred to as RTA traffic and is packed into RTA frames at the sender STA. Also, data generated from non-time sensitive applications is referred to as non-RTA traffic and will be packed into non-RTA frames at the sender STA. The transmitter STA then transmits packets carrying frames over the channel to the receiver STA.

RTA frames require low latency communication due to their high timeliness delivery requirements. RTA frames are generally only delivered valid for a certain period of time.

One contemplated solution under CSMA/CA is to schedule a Service Period (SP) of a limited target wakeup time (R-TWT) as defined in 802.11be for RTA frame exchange. The R-TWT SP grants higher priority to the scheduled RTA frames, but the unscheduled RTA frames may suffer significant delays, even if the information being transmitted is very important.

Thus, there is a need to improve the processing of R-TWT SPs. The present disclosure overcomes this problem and provides additional benefits.

Disclosure of Invention

non-AP STAs that are R-TWT scheduled STAs that do not have R-TWT membership queue emergency bursts of RTA traffic for the AP during an ongoing R-TWT SP. In this disclosure, a non-AP STA may initiate an R-TWT negotiation with a scheduling AP within an ongoing R-TWT SP to request temporary or long-term membership of the current ongoing R-TWT SP, or to request setting of a new temporary or long-term R-TWT SP after the current R-TWT SP but before the R-TWT SP that it originally had R-TWT membership, or if the UORA feature is enabled, contend for the RA-RU in the current R-TWT SP.

Further aspects of the technology described herein will be presented in the following section of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

Drawings

The techniques described herein will be more fully understood by reference to the following drawings for illustrative purposes only:

FIG. 1 is a data field diagram of a TWT element.

Fig. 2 is a data field diagram of a control field of the TWT element of fig. 1.

Fig. 3 is a data field diagram of a broadcast TWT parameter set.

Fig. 4 is a data field diagram of a request type field in a broadcast TWT parameter set field.

Fig. 5 is a data field diagram of a broadcast TWT information subfield in a TWT parameter set field.

Fig. 6 is a data field diagram of a limited TWT traffic information field.

Fig. 7 is a data field diagram of the traffic information control field of the limited TWT traffic information field.

Fig. 8 is a data field diagram of a frame format of the TWT information field.

Fig. 9 is an interworking communication diagram of a TWT setting frame defined in IEEE 802.11 ax.

Fig. 10 is a data field diagram of a TWT setting frame.

Fig. 11 is a communication diagram for an example of executing the R-TWT SP.

Fig. 12 is a block diagram of communication station hardware in accordance with at least one embodiment of the present disclosure.

Fig. 13 is a block diagram of multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure.

Fig. 14 is a network topology used in an example in accordance with at least one embodiment of the present disclosure.

Fig. 15 is a communication diagram of RA-RU processing for a non-R-TWT member STA in accordance with at least one embodiment of the present disclosure.

Fig. 16 is a communication diagram of unicast RU access process (es) in accordance with at least one embodiment of the present disclosure.

Fig. 17 is a communication diagram of a process for assigning RA-RU 6 to a new group AID in accordance with at least one embodiment of the present disclosure.

Fig. 18-21 are flowcharts of operations of an R-TWT scheduled STA in accordance with at least one embodiment of the present disclosure.

Fig. 22-24 are flowcharts of operations of an R-TWT scheduling AP in accordance with at least one embodiment of the present disclosure.

Fig. 25 is a data field diagram of a temporary member subfield in a request type field in a broadcast TWT parameter set field for an R-TWT in accordance with at least one embodiment of the disclosure.

FIG. 26 is a data field diagram of an R-TWT information frame format with temporary member subfield for R-TWT according to at least one embodiment of the present disclosure.

Fig. 27 and 28 are communication diagrams of a process for performing emergency R-TWT membership for non-R-TWT member STAs during an R-TWT SP in accordance with at least one embodiment of the disclosure.

Fig. 29 and 30 are communication diagrams of a setup procedure for a new R-TWT SP for a non-R-TWT member STA during an ongoing R-TWT SP, in accordance with at least one embodiment of the disclosure.

Fig. 31 is a communication diagram of a non-R-TWT member STA transmitting using UORA in its non-membership R-TWT SP in accordance with at least one embodiment of the disclosure.

Fig. 32 and 33 are communication diagrams of a non-R-TWT member STA transmitting a BSR using an RA-RU in its non-membership R-TWT SP in accordance with at least one embodiment of the present disclosure.

Fig. 34 is a communication diagram of a non-R-TWT member STA performing initiation using UORA during its non-membership R-TWT SP in accordance with at least one embodiment of the disclosure.

Fig. 35 is a communication diagram of a non-R-TWT member STA transmitting using unicast RU(s) in its initially non-membership R-TWT SP in accordance with at least one embodiment of the present disclosure.

Fig. 36 is a network topology of a simple topology of an MLO scenario, consisting of three MLDs used in an example in accordance with at least one embodiment of the present disclosure.

Fig. 37 is a communication diagram of setting up an emergency R-TWT agreement on multiple links for an MLD STA that does not have R-TWT membership in the current R-TWT SP(s) on any link in accordance with at least one embodiment of the present disclosure.

Detailed Description

Introduction to R-TWT operation

Non-access point (non-AP) ultra high throughput (EHT) STAs establish one or more membership preserving target latency (R-TWT) schedule with their associated EHT AP through an associated (or re-associated) TWT setup frame exchange.

The R-TWT SP is scheduled to complete transmissions to or from a group of non-AP STAs that are members of the R-TWT of this SP. A non-AP EHT STA transmission opportunity (TXOP) holder that agrees to R-TWT scheduling but is not a member of the R-TWT SP should transmit within the R-TWT SP scheduled for itself.

A non-AP EHT STA that does not have membership in the R-TWT SP should still be able to autonomously access the R-TWT SP, but it may not have the same priority given to the R-TWT SP member STA, especially when transmissions are initiated/triggered by the R-TWT scheduling AP.

Bursts of RTA traffic from the application may be generated at any time and this RTA traffic request sent out as soon as possible. However, if the non-AP EHT STA does not have membership in the current R-TWT SP, but still needs to deliver this bursty RTA traffic, then the bursty RTA traffic may suffer from delays under the R-TWT schedule.

Elements in IEEE 802.11

TWT element 1.1

Fig. 1 depicts the format of TWT elements defined in IEEE 802.11be, showing element Identification (ID) fields, length fields, control fields, TWT parameter information.

Fig. 2 depicts the control fields of the TWT element of fig. 1. The subfields of the control field are as follows. The NDP paging indicator is set to a value of 1 to indicate that NDP paging is to be performed; otherwise, the NDP paging field is set to 0. The responder PM mode subfield indicates a power management mode. The negotiation type subfield indicates whether the information included in the TWT element is for broadcasting a negotiation of a TWT (B-TWT) or an individual TWT (I-TWT) or a wakeup TBTT interval. It should be noted that the MSB of the negotiation type subfield is a B-TWT. The TWT information frame disable subfield is set to 1 to instruct the STA to disable reception of the TWT information frame; otherwise, it is set to 0. The wake duration unit subfield indicates the unit of the nominal minimum TWT wake duration field. If the unit is 265 mus, the wakeup duration unit subfield is set to 0, and if the unit is a TU, the subfield is set to 1. If the link ID bitmap presence field is equal to 1, then the link ID bitmap field is present; otherwise, the link ID bitmap field does not exist.

Fig. 3 depicts a broadcast TWT parameter set field format. If the broadcast field of the negotiation type subfield is 2 or 3, one or more broadcast TWT parameter sets are included in the TWT element. The request type subfield broadcasting the TWT parameter set field is shown in fig. 4. The target wake-up time field contains an unsigned integer corresponding to the TSF time the STA requests to wake up. It should be noted that if a STA is requested by the TWT or a STA scheduled by the TWT transmits, and the TWT set command subfield contains a value corresponding to the command "request TWT", then the target wake time field contains a value of 0.

The nominal minimum TWT wake duration field indicates the minimum amount of time that the TWT requesting STA or the TWT scheduled STA expects to wake in units indicated by the wake duration unit subfield in order to complete the frame exchange within the period of the TWT wake interval. The TWT wake interval mantissa subfield is set to the binary value of the mantissa of the TWT wake interval value in microseconds. The broadcast TWT information subfield is shown in fig. 5. When the limited TWT traffic information present subfield of the request type field is set to 1, the limited TWT traffic information field is present; and its format is defined in fig. 6.

Fig. 4 depicts a request type field in a broadcast TWT parameter set field. The STA transmitting the TWT element with the TWT request subfield equal to 1 is the TWT requesting STA or the TWT scheduled STA. Otherwise, it is a TWT responding STA or TWT scheduling AP.

The TWT set command subfield value indicates the type of TWT. For example, the TWT set command field values are as follows: 0= "request TWT"; 1= "suggested TWT"; 2= "demand TWT", 3= "TWT packet"; 4= "accept TWT"; 5= "replace TWT"; 6= "specify TWT" and 7= "reject TWT".

The meaning of "requesting TWT" is that the requesting STA does not provide a set of TWT parameters for the TWT protocol, leaving the choice of parameters to the responding STA. The "suggested TWT" indicates that the requesting STA provides a set of preferred TWT parameters for the TWT protocol, but may still accept alternative TWT parameters indicated by the responding STA, while the "required TWT" indicates that the requesting STA will currently accept only the indicated TWT parameters for the TWT protocol.

When transmitted by a responding STA, the value of "accept TWT" indicates that the responding STA has initiated a TWT agreement with the given parameters. The value of "substitute TWT" indicates the counter offer (counter offer) of the TWT parameter, but substitute TWT parameters may also be accepted without creating a TWT agreement. The value of "prescribed TWT" indicates that no TWT agreement is created, but rather that a TWT agreement is only possible to accept when the requesting STA transmits a new TWT setting request with indicated TWT parameters, and the value of "reject TWT" transmitted by the responding STA as part of the negotiation for the new TWT agreement is used to indicate that the negotiation has ended and that the new TWT agreement has not been created.

The trigger field indicates whether the TWT SP indicated by the TWT element includes a trigger frame. The trigger field is set to 1 to indicate that at least one trigger frame is transmitted during the TWT SP. Otherwise, the trigger field is set to 0.

The last broadcast parameter set subfield is set to 0 to indicate that another set of broadcast TWT parameters follows this set. The last broadcast parameter set subfield is set to 1 to indicate that this is the last broadcast TWT parameter set in the broadcast TWT element.

The flow type subfield indicates the type of interaction at the TWT between the requesting STA or TWT scheduled STA and the TWT responding STA or TWT scheduling AP. Setting the flow type subfield to 0 indicates an advertised TWT, wherein the requesting STA of the TWT or the TWT scheduled STA will send a PS-Poll or APSD trigger frame to signal its awake state to the TWT responding STA or TWT scheduled AP before a frame that is not a trigger frame is sent from the TWT responding STA or TWT scheduled AP to the requesting STA of the TWT. Setting the flow type subfield to 1 indicates an unaware TWT where the TWT responding STA or TWT scheduling AP will send frames at the TWT to the requesting STA or TWT scheduled STA, without waiting for the PS-Poll or APSD trigger frame to be received from the requesting STA or TWT scheduled STA.

The TWT SP set under the advertised TWT agreement is the advertised TWT SP. The TWT SP set under the non-advertised TWT agreement is the non-advertised TWT SP.

The broadcast TWT recommendation subfield contains a value indicating a recommendation regarding the type of frames scheduled by the TWT and scheduled for transmission by the AP during broadcast TWT SP, the values of which are as follows. A value of 0 indicates that there is no constraint on the frames transmitted during broadcast TWT SP. A value of 1 indicates that a trigger frame to be transmitted by a TWT scheduling AP during broadcasting of the TWT SP does not contain RUs for random access and Orthogonal Frequency Division Multiple Access (OFDMA) based random access (UORA). A value of 2 indicates that the plurality of trigger frames transmitted by the TWT scheduling AP during broadcast of the TWT SP contain at least one Resource Unit (RU) for random access and Uplink OFDMA Random Access (UORA). The value of 3 indicates that there is no constraint on the frames transmitted during broadcast TWT SPs, except that the AP transmits a Fast Initial Link Setup (FILS) discovery frame, or Traffic Indication Map (TIM) frame, that includes a TIM element at the beginning of each TWT SP. A value of 4 indicates that the corresponding broadcast TWT service period is a limited TWT SP. Values 5 to 7 are reserved.

The TWT wake interval exponent subfield is set to the value of the exponent of the TWT wake interval, which is a binary value representing microseconds.

Fig. 5 depicts the broadcast TWT information subfield in the TWT parameter set field, with the following subfields. The limited TWT traffic information presence subfield, when included in the limited TWT parameter set field, is set to 1 to indicate that the limited TWT traffic information field is present; otherwise set to 0.

Within a TWT element that includes a TWT setting command value that requests a TWT, suggests a TWT, or requires a TWT, the broadcast TWT ID (if present) indicates the particular broadcast TWT in which the transmitting STA requests participation. Within the TWT element that includes a TWT setting command value that accepts a TWT, replaces a TWT, specifies a TWT, or rejects a TWT, the broadcast TWT ID (if present) indicates the particular broadcast TWT for which the transmitting STA provides TWT parameters. Within the TWT element that includes the TWT set command value of the TWT packet, the broadcast subfield is 0 and the broadcast TWT ID does not exist. A value of 0 in the broadcast TWT ID subfield indicates a broadcast TWT whose membership corresponds to all STAs that are members of the BSS corresponding to the BSSID of the management frame carrying the TWT element.

It should be noted that the broadcast TWT ID subfield in the R-TWT parameter set field is always set to a non-zero value. The broadcast TWT persistence subfield indicates the number of TBTTs of the broadcast TWT SP during which there is a corresponding broadcast TWT parameter set.

Fig. 6 depicts a limited TWT traffic information field with the following subfields. The flow information control subfield is depicted in fig. 7. The limited TWT DL TID bitmap and the limited TWT UL TID bitmap subfields specify which TID(s) are identified by the TWT scheduling AP or the TWT scheduled STA as delay sensitive traffic flows in the downlink and uplink directions, respectively. If this value is set to 1 at bit position k in the bitmap, it indicates that TID k is classified as a latency sensitive traffic stream. If the value at bit position k in the bitmap is set to 0, this indicates that TID k is not classified as a latency sensitive traffic stream.

Fig. 7 depicts the traffic information control field of the limited TWT traffic information field, which has the following subfields. The DL TID bitmap valid subfield indicates whether the limited TWT DL TID bitmap field has valid information. When the value is set to 0, this indicates that DL traffic for all TIDs is identified as delay sensitive traffic and the limited TWT DL bitmap field is reserved.

The UL TID bitmap valid subfield indicates whether the limited TWT UL TID bitmap field has valid information. When this value is set to 0, this indicates that UL traffic for all TIDs is identified as delay sensitive traffic and that the limited TWT UL bitmap field is reserved.

Twt information field 1.1.2

Fig. 8 depicts the frame format of the TWT information field, with the following subfields. The TWT flow identifier subfield contains the TWT flow identifier for which TWT information is requested or provided.

If all TWT subfields are 1, then the TWT flow identifier subfield is reserved. The request response subfield indicates whether a sender of a frame containing the TWT information field is requesting a TWT information frame to be transmitted in response to this frame. The request response subfield is set to 0 to request that the receiver not transmit the TWT information frame in response to the frame. Otherwise, the requesting recipient transmits a TWT information frame in response to the frame.

The next TWT request subfield is set to 1 to indicate that the TWT information frame is a request for delivery of a TWT information frame that contains a next TWT field of non-zero length; otherwise, the value is set to 0.

The next TWT subfield size subfield describes the size of the next TWT subfield. For example, a value of 0 indicates that the size of the next TWT subfield is 0 bits; a value of 1 indicates a size of 32 bits; a value of 2 indicates a size of 48 bits and a value of 3 indicates a size of 64 bits.

All TWT subfields are set to 1 by the HE STA to instruct the TWT information frame to reschedule all TWTs; otherwise, the value is set to 0.

The next TWT subfield has a variable size determined by the next TWT subfield value. The value contained in the next TWT subfield is the least significant portion of the TSF at the next TWT of the TWT specified by the TWT flow identifier subfield.

R-TWT signaling

Fig. 9 depicts an example of TWT settings defined in IEEE 802.11 ax. The interworking model of the STA may be the same as defined in the IEEE 802.11 standard.

The non-AP STA decides (determines) to initiate a TWT setup procedure with the AP. A Station Management Entity (SME) of a non-AP STA sends a MLME-twtsetup.request message to its Medium Access Control (MAC) sub-layer management entity (MLME). When the MLME of the non-AP STA receives the MLME-twtsetup.request message, it gathers the information in the MLME-twtsetup.request message and sends a TWT setup frame (i.e., TWT request frame) to the AP. The MLME of the AP receives the frame and generates a MLME-twtsetup. Indication message to its SME.

Then, the SME of the AP transmits a MLME-twtsetup.response message containing the TWT setting result to its MLME. The MLME of the AP then transmits a TWT setup frame (i.e., TWT response frame) to the non-AP STA. The MLME of the non-AP STA receives the frame and sends an MLME-TWTSETUP. Confirm message to its SME; the non-AP may identify therefrom whether the TWT setting was successful.

Fig. 10 depicts the format of a TWT setup frame in which its TWT elements are shown in fig. 1. According to the definition in IEEE 802.11be, a limited TWT (R-TWT) scheduling AP, referred to as an R-TWT scheduling AP, is an EHT AP that supports limited TWT operation and sets the limited TWT support subfield in the transmitted EHT capability element to 1.

A limited TWT (R-TWT) scheduled STA, referred to as an R-TWT scheduled STA, is a non-AP EHT STA that supports limited TWT operation and sets the limited TWT support subfield in the transmitted EHT capability element to a value of 1.

The R-TWT scheduled STA may establish membership of one or more R-TWT scheduled by the R-TWT scheduling AP. The R-TWT setting signaling is the same as broadcast TWT, but with additional parameter settings that are used for membership negotiation of R-TWTs between the STA of the R-TWT schedule and the R-TWT scheduling AP. After the R-TWT scheduled STA establishes membership of the R-TWT scheduled by the R-TWT scheduling AP, the R-TWT scheduled STA has a higher priority or is allowed to exchange frames with the R-TWT scheduling AP during the SP of the R-TWT. On the other hand, an R-TWT scheduled STA that is not a member of the R-TWT has a lower priority or is not allowed to exchange frames with the R-TWT scheduled AP during the SP of the R-TWT.

FIG. 11 depicts an example of executing an R-TWT SP. AP1 is an R-TWT scheduling AP that advertises R-TWT1 schedules and manages the members of R-TWT 1. STA1 and STA2 are member STAs of R-TWT 1. During R-TWT1 SP, AP1 schedules and prioritizes frame exchanges with member STAs (e.g., UL PPDUs with SCS1 of STA1 and DL PPDUs with SCS2 of STA 2). STAs that can receive (hear) and recognize (understand) the R-TWT schedule are referred to as R-TWT scheduled STAs. STA3 is an R-TWT scheduled STA, but not a member STA of R-TWT 1. STA3 must end its TXOP before the start time of the R-TWT1 SP. STA3 may also enter quiet mode or may decide not to contend for the channel during R-TWT1 SP. The scheduling AP may broadcast a quiet element to announce the quiet interval during the R-TWT SP and the STA receiving (hearing) this element may choose to enter quiet mode.

Ul OFDMA-based random access (UORA)

UORA is a feature of ieee802.11ax for non-AP HE STAs to access channels using RA-RUs assigned by the associated HE AP. The HE AP may transmit a basic trigger frame, BQRP trigger frame, or BSRP trigger frame containing one or more RUs for random access. The AP should indicate the range of an OFDMA Contention Window (OCW) for non-AP STAs to initiate random access after receiving a trigger frame sent by the AP.

The OCW (which is an integer ranging from OCWmin to OCWmax) is set in a UORA parameter set element contained in a management frame such as a beacon, probe response or (re) association response frame.

Each time a non-AP HE STA associates with a different AP, and before attempting an RA-RU transmission to it initially, the non-AP HE STA should set the value of OCW to the OCWmin value, and should initialize its OFDMA random access backoff (OBO) counter in the range of 0 to OCW. The (OBO) counter is used by non-AP HE STAs to count down before accessing the RA-RU.

After receiving a trigger frame containing at least one eligible RA-RU, if the OBO counter is not greater than the number of eligible RA-RUs, the HE STA with a pending frame for the AP may randomly select one of the eligible RA-RUs for transmission and should set its OBO counter to zero. Otherwise, HE STA decrements its OBO counter by the number of eligible RA-RUs in the trigger frame. It should BE noted that 802.11BE does not currently support UORA in R-TWT.

2. Statement of problem

In current wireless communication systems that use Enhanced Distributed Channel Access (EDCA) and R-TWT to prioritize RTA traffic transmissions during R-TWT SP, the RTA traffic is prioritized for transmission. However, the duration of the R-TWT SP is scheduled for the R-TWT member STA; non-AP STAs that are not members of a particular R-TWT SP typically have limited channel access to the R-TWT SP. One reason for this access restriction is because the R-TWT scheduling AP does not know whether the state of the non-RTWT member is sleeping or awake and therefore does not spontaneously trigger the non-R-TWT member. While STAs may still contend for R-TWT SPs for which they are not membership, they may have a smaller chance to acquire a TXOP than a scheduled AP because the AP may have a faster arbitration interframe space (AIFS) than a non-AP STA (where AIFSN AC is greater than or equal to 2) (where the AIFS number (AFSN) is greater than or equal to 1). In this context, bursts of RTA packets may be queued in STAs that are not members of the ongoing R-TWT SP and thus suffer from delays until their own scheduled R-TWT SP arrives.

Thus, there is a need for a mechanism to set temporary or long-term R-TWT membership for STAs that are not initially members of the current R-TWT SP, but that have bursts of RTA traffic to be transmitted in the currently ongoing R-TWT SP.

3. Contribution of the present disclosure

By utilizing the present disclosure, STAs that have queued bursty RTA traffic but do not have membership in the currently ongoing R-TWT SP may immediately negotiate with the scheduling AP within the current R-TWT SP to set temporary or long-term membership using this R-TWT SP or to set a new R-TWT SP that transmits RTA traffic after the current R-TWT SP with the same priority given to the R-TWT members.

4. Examples

4.1. Communication station (STA and MLD) hardware

Fig. 12 illustrates an example embodiment 10 of STA hardware configured to perform the protocols of the present disclosure. External I/O connection 14 is preferably coupled to an internal bus 16 of circuitry 12, with a CPU 18 and memory (e.g., RAM) 20 connected to internal bus 16 for executing program(s) implementing a communication protocol. The host machine houses at least one modem 22 to support communications coupled to at least one RF module 24, 28, each RF module 24, 28 being connected to one or more antennas 29, 26a, 26b, 26c through 26n. An RF module having multiple antennas (e.g., an antenna array) allows beamforming to be performed during transmission and reception. In this way, the STA may transmit signals using multiple sets of beam patterns.

Bus 14 allows various devices to be connected to the CPU, such as to sensors, actuators, etc. The instructions from the memory 20 are executed on the processor 18 to execute a program implementing a communication protocol that is executed to allow the STA to perform the functions of an Access Point (AP) station or a conventional station (non-AP STA). It should also be appreciated that programming is configured to operate in different modes (TXOP holder, TXOP sharing participant, source, intermediary, destination, first AP, other AP, stations associated with first AP, stations associated with other AP, coordinator, AP in OBSS, STA in OBSS, etc.), depending on the role it performs in the current communication context.

Thus, STA HW is shown configured with at least one modem and associated RF circuitry for providing communication over at least one frequency band. It should be appreciated that the present disclosure may be configured with a plurality of modems 22, each coupled to any number of RF circuits. In general, the use of a greater number of RF circuits will result in a wider coverage area for the antenna beam direction. It should be appreciated that the number of RF circuits and the number of antennas used is determined by the hardware constraints of the particular device. When the STA determines that it is not necessary to communicate with a neighboring STA, the RF circuitry and a portion of the antenna may be disabled. In at least one embodiment, the RF circuitry includes a frequency converter, an array antenna controller, and the like, and is connected to a plurality of antennas that are controlled to perform beamforming for transmission and reception. In this way, the STA may transmit signals using multiple sets of beam patterns, each beam pattern direction being considered an antenna sector.

Further, it should be noted that multiple instances of station hardware such as that shown in this figure may be combined into a multi-link device (MLD) that will typically have processors and memory for coordinated activities, but it should be appreciated that these resources may be shared, as each STA within the MLD does not always require a separate CPU and memory.

Fig. 13 illustrates an example embodiment 40 of a multi-link device (MLD) hardware configuration. A soft AP MLD is an MLD that consists of one or more dependent STAs that operate as APs. Soft AP MLD should support multiple radio operations at 2.4GHz, 5GHz and 6 GHz. In a plurality of radios, the basic link set is a link pair that satisfies Simultaneous Transmission and Reception (STR) modes, e.g., basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz).

A conditional link is a link that forms a non-simultaneous transmission and reception (NSTR) link pair with some basic links. For example, when 5GHz is the primary link, these link pairs may include a 6GHz link as the conditional link corresponding to the 5GHz link. When 6GHz is the base link, the 5GHz link is a conditional link corresponding to the 6GHz link. Soft APs are used in different scenarios, including Wi-Fi hotspots and network sharing.

Multiple STAs are attached to the MLD, each STA operating on a different frequency link. The MLD has external I/O access to the application, which is connected to an MLD management entity 48 having a CPU 62 and a memory (e.g. RAM) 64 to allow execution of program(s) implementing the communication protocol at the MLD level. The MLD may distribute tasks to and collect information from each of the affiliated stations (illustrated here as STA 1, STA 2, 44 through STA N46) to which it is connected, and may share information among the affiliated STAs.

In at least one embodiment, each STA of the MLD has its own CPU 50 and memory (RAM) 52 coupled to at least one modem 54 by a bus 58, the modem 54 being connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has a plurality of antennas 60a, 60b, 60c to 60n, such as in an antenna array. A modem in combination with RF circuitry and associated antenna(s) transmits/receives data frames with neighboring STAs. In at least one embodiment, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with its antenna.

It should be appreciated that each STA of the MLD does not have to require its own processor and memory, as the STAs may share resources with each other and/or with the MLD management entity, depending on the particular MLD implementation. It should be appreciated that the above MLD graphs are given by way of example and not limitation, and that the present disclosure may operate with a wide range of MLD implementations.

Sta topology example

Fig. 14 illustrates an example STA topology 70 for consideration in examples of the present disclosure. The figures are provided to assist in discussing the techniques involved to enhance understanding of the proposed techniques. It should be appreciated that the present disclosure is in no way limited to this example topology, as the protocol may be used for communication between WLAN STAs and MLDs of any desired topology.

A multi-link device (MLD) is a device having more than one dependent STA and having one Medium Access Control (MAC) Service Access Point (SAP) to Logical Link Control (LLC), which includes one MAC data service.

If an AP is attached to an MLD, then the MLD is an AP MLD. If the non-AP STA is attached to the MLD, then the MLD is a non-AP MLD.

As shown in fig. 14, the scenario is illustrated with three total stations, shown as one Access Point (AP) 72, and two non-AP STAs in communication with the AP: STA1 74 and STA276. All STAs use EDCA for random channel access.

The R-TWT scheduling AP is capable of scheduling and advertising R-TWT SPs. An R-TWT scheduled STA is a non-AP STA capable of receiving and identifying an R-TWT announcement from an R-TWT scheduling AP and supporting R-TWT operation. The STA of the R-TWT schedule can negotiate the membership of the R-TWT with the AP serving as the R-TWT scheduling AP. When an R-TWT scheduled STA becomes a member STA of an R-TWT, traffic (e.g., UL, DL, P2P) of the R-TWT scheduled STA (i.e., R-TWT member STA) is scheduled and prioritized for transmission during the SP of that R-TWT.

In this example diagram, the AP is an R-TWT scheduled AP and both STA1 and STA2 are R-TWT scheduled STAs.

4.3. Emergency R-TWT membership request in current R-TWT SP

In this section, a mechanism is described in which a non-AP R-TWT scheduled STA (STA) with at least one R-TWT membership of the R-TWT SP(s) (which is different from the currently ongoing R-TWT SP) has an emergency burst UL stream to transmit and may immediately initiate R-TWT negotiation with the scheduling AP instead of waiting for its scheduled R-TWT SP. non-R-TWT member STAs may request acceptance as new members (temporary or long term) of the current R-TWT SP so that after STAs receive agreement from the scheduling AP they may deliver the emergency burst UL stream with the same priority as the original R-TWT member in the current R-TWT SP.

The R-TWT negotiation between the non-R-TWT member STA and the scheduling AP is based on a frame-based exchange (e.g., TWT request frames and TWT response frames carrying TWT elements, with negotiation type subfields indicating this type of action, such as equal to 3 in the examples herein).

The reserved subfield of the request type field in the broadcast TWT parameter set field may be used by non-AP STAs to request membership (temporary or long term) of the current R-TWT SP using a newly defined "temporary member" subfield as shown in fig. 25. The scheduling AP may also use it to indicate membership acceptance or assign a new R-TWT membership for the current R-TWT for the requested STA.

In at least one embodiment, this field provides a number of options (two options in this example) to indicate that temporary or long term membership is requested by a scheduled non-AP STA or assigned by a scheduling AP.

The scheduled non-AP STA assigned temporary membership of the current R-TWT SP only provides a one-time-use agreement for the R-TWT member to be a member of the currently ongoing R-TWT SP.

A scheduling AP agreeing to assign long-term membership to a requesting non-AP STA to use a particular R-TWT SP should maintain membership of the requesting non-AP scheduled STA using this R-TWT SP (identified by, for example, a broadcast TWT ID) until this non-AP STA performs the tear down of the R-TWT agreement.

The scheduling AP may accept or reject a request from a STA that has issued a request to become a new member of the current R-TWT SP, or it may indicate an alternative R-TWT setting, or specify a preferred R-TWT setting from the STA.

4.4. Emergency new R-TWT SP settings during a current R-TWT SP

In this section, mechanisms are described for STAs that have an emergency burst UL flow, but that do not initially acquire R-TWT membership in the current R-TWT SP; where they attempt to set other (temporary or long-term) R-TWT SPs with the scheduling AP during this current R-TWT SP. The other (temporary or long-term) R-TWT SPs may follow the current R-TWT SP and should be set as soon as possible before the time of arrival of the originally scheduled R-TWT SP(s) of the requesting STA.

It should be noted that a new (temporary or long-term) R-TWT SP for a requesting STA may overlap with an existing R-TWT SP in the time domain, where the requesting STA does not have R-TWT membership. In this case, the requesting STAs should still have high access priority because they are members of the new R-TWT SP.

The new R-TWT SP may be set by sending a new proposed R-TWT information frame to the scheduling AP.

After receiving the R-TWT information frame from the non-AP STA, the scheduling AP should respond with a frame to schedule the next TWT and indicate whether the next R-TWT is a temporary or long-term R-TWT SP for the scheduled STA that sent the R-TWT information frame.

The new R-TWT information frame is designed based on the TWT information field and maintains the flexible TWT features defined in ieee 802.11ax_d8.0. In addition, the proposed R-TWT information frame may contain a limited TWT traffic information field as introduced in fig. 6 to indicate the RTA traffic information requested/accepted in the new R-TWT SP, and a temporary R-TWT field to indicate whether the request is for a temporary or long-term R-TWT SP. The frame format of the proposed R-TWT information frame will be shown in fig. 26.

The non-AP STA that initiates the R-TWT information frame exchange may use the new temporary or long-term R-TWT SP to transmit the bursty UL stream after receiving an agreement from the scheduling AP.

4.5. Emergency non-R-TWT member STA transmissions using UORA

Current IEEE 802.11be supports UORA in B-TWTs by setting the value of the broadcast TWT recommendation subfield for the B-TWT element to 2. The broadcast TWT parameter set with the broadcast TWT recommendation field equal to a value of 4 indicates the R-TWT parameter set, and there is no current limit nor requirement to use UORA for R-TWTs.

In this section, a new value is defined for the broadcast TWT recommendation field to indicate that a trigger frame transmitted by the R-TWT scheduling AP during the R-TWT SP contains at least one RU for random access. In this case, the RA-RU may be used by both the non-R-TWT member STA and the R-TWT member STA.

A new value of the broadcast TWT recommendation field, e.g., 5, may be set to indicate that the UORA feature is enabled in the R-TWT SP. The new feature may be initially enabled at the beginning of each R-TWT SP. Alternatively, this feature may be initiated by a STA that has not acquired R-TWT membership in this R-TWT SP by exchanging negotiation frames (e.g., R-TWT requests and R-TWT responses) with the scheduling AP during the currently ongoing R-TWT SP.

When the UORA feature is enabled in the currently ongoing R-TWT SP, the non-R-TWT member STA to which bursts of RTA packets are to be transmitted may use the RA-RU in the current R-TWT SP based on the UORA transmission procedure as defined in the standard.

Both R-TWT member STAs and non-R-TWT member STAs may contend for the RA-RU for transmission. When the OFDMA Backoff (OBO) counter counts down to zero, the non-R-TWT member STA may directly transmit an Uplink (UL) physical layer convergence Procedure Protocol Data Unit (PPDU) using one random access-resource unit (RA-RU), or may transmit a Buffer Status Report (BSR) in the RA-RU to allow the scheduling AP to allocate a specific RU for it so that it may have direct access in the next triggered UL PPDU transmission.

Fig. 15 illustrates an example embodiment 90 of RA-RU processing for a non-R-TWT member STA (e.g., STA 2) and an R-TWT member STA (e.g., STA1, STA3, and STA 4) when UORA is enabled in an R-TWT SP. RU is shown spanning a portion of the spectrum. The figure depicts the AID values 92 for STA1 through STA4, each of STA1 through STA4 having an initial OBO value before scheduling the AP to transmit a trigger frame.

After receiving the trigger frame 94 from the scheduling AP, the following allocation 96 occurs. STA1 and STA3 are members of this R-TWT SP and have pending frames for scheduling the AP. STA1 is allocated dedicated RUs (RU 1 and RU 2) and STA3 is allocated dedicated RUs (RU 3 and RU 4). STA1 and STA3 do not contend for the RA-RU, but instead transmit their pending frames on their assigned RU.

STA4 is a member of this R-TWT SP and has a pending frame for scheduling the AP. STA4 does not receive the allocated RU from the trigger frame and therefore it will contend for the RA-RU. STA4 decrements its OBO counter by the number of eligible RA-RUs indicated in the trigger frame (i.e., in this case, two RA-RUs for the associated STA). Assuming that STA 4's OBO counter is decremented to a non-zero value, STA4 maintains the new OBO value until it receives a subsequent trigger frame from the scheduling AP carrying the RA-RU.

STA2 is not a member of this R-TWT SP but it has a pending frame for scheduling the AP. STA2 decrements its OBO counter by the number of eligible RA-RUs indicated in the trigger frame (i.e., in this case, two RA-RUs for the associated STA). Assuming that STA 2's OBO counter is decremented to a final (e.g., zero) value, it sends its pending frame on RU6, which it randomly selects from the qualified set of RUs (i.e., RU5 and RU 6).

In this case, the reception of these transmitted PPDUs in the RU is acknowledged 98 by a multi-user block acknowledgement (MU BA).

4.6. Emergency non-R-TWT member STA transmissions using guaranteed unicast RU(s)

For STAs that do not have membership in the currently ongoing R-TWT SP, they may request to become temporary members of the current R-TWT SP and request the unicast RU(s) to deliver their bursty RTA traffic in the currently ongoing R-TWT SP. The R-TWT scheduling APs may guarantee unicast RU(s) for them after accepting their request.

In this section, it is described to guarantee the setting of unicast RU(s) by defining new values for broadcast TWT recommendation subfields. The guaranteed unicast RU(s) are assigned by the scheduling AP to a specific AID, which the new temporary R-TWT member STA uses to transmit burst traffic to the AP.

A new value of the broadcast TWT recommendation field, e.g., 6, may be used to enable unicast RU feature(s) in the R-TWT. The new feature cannot be scheduled at the beginning of any R-TWT SP because the scheduling AP has no information (no knowledge) of which non-member STA will request to become a member of this R-TWT SP, and therefore the scheduling AP cannot set the unicast RU(s) for a particular AID.

The new unicast RU(s) in this R-TWT feature may be initiated by the non-R-TWT member STA by exchanging negotiation frames (e.g., TWT requests and TWT responses) with the scheduling AP during the currently ongoing R-TWT SP.

Fig. 16 illustrates an example embodiment 110 of unicast RU access process (es), showing station AIDs 112 for a new R-TWT member STA (e.g., STA 2) and R-TWT member STAs (e.g., STA1 and STA 3) temporarily when guaranteed unicast RU(s) are enabled in the R-TWT SP.

STA2 is not a member of this triggered R-TWT SP, but it has a pending RTA burst to be sent to the scheduling AP. STA2 may send a TWT request frame to the scheduling AP to request or suggest to add it as a new temporary member and request unicast RU(s) during this R-TWT SP. The scheduling AP may accept, suggest/prescribe alternatives, or reject requests or suggested TWT setting commands from STA 2.

Assuming that the scheduling AP accepts the new TWT setting command from STA2, the AP responds with a TWT response frame and sets the TWT setting command field to "accept TWT" and the broadcast TWT recommendation field to the new design value (e.g., 6) to enable the unicast RU feature(s) in the current R-TWT SP.

After receiving the TWT response frame from the scheduling AP, which includes an indication that the new TWT setting command has been accepted, STA2 becomes a new temporary member of the requested R-TWT SP.

Upon receiving trigger frame 114 from the scheduling AP, both STA1 and STA3 are considered the original members of this triggered R-TWT SP and have a pending frame for the scheduling AP. STA1 is allocated dedicated RUs (RU 1 and RU 2) and STA3 is allocated dedicated RUs (RU 3, RU4, and RU 5). STA1 and STA3 should transmit their pending frames using their assigned RUs.

The scheduling AP allocates RU6 to STA2 in the following trigger frame (as indicated from AID 8). The new R-TWT member STA2 receives a trigger frame indicating that unicast RU6 is assigned to it and may immediately access RU6 to transmit the UL PPDU.

The reception of these transmitted PPDUs in the RU is acknowledged by the MU BA 118.

4.7. Assigning RA-RU group AIDs for non-R-TWT member STAs

In this section, a mechanism is described for assigning RA-RU(s) to a new group AID that is used for non-AP STAs that do not have membership in the currently ongoing R-TWT SP, but that can buffer UL RTA traffic.

The new group AID that assigns RA-RU(s) to non-R-TWT members should be contained by the beacon frame body, which indicates when the R-TWT applies, and will be specifically assigned to RA-RU(s) for providing access to non-R-TWT member STAs during any R-TWT SP.

In at least one embodiment/mode/option, the new set of AID values may be one of the reserved values in the AID12 subfield of the user information field of the trigger frame based on the values seen in table 1 (which contains the material of tables 9-29h of the 802.11ax specification).

The new group AID value, e.g., 2050, indicates that the user information field has allocated one or more consecutive RA-RUs in any R-TWT SP for the associated non-R-TWT member STA. It should be noted that the pre-EHT devices do not recognize the new group AID, and therefore they cannot compete for access to the RA-RU(s) assigned to the new group AID. A new value of the broadcast TWT recommendation field, such as 7, may be used to enable RA-RU(s) allocated for the new group AID of non-R-TWT members in the R-TWT SP.

Fig. 17 illustrates an example embodiment 130 of a process for assigning RA-RU 6 to a new group AID (e.g., 2050) for a non-R-TWT member STA (e.g., STA 2). The state 132 shows STA1 through STA4 and their associated AID. The R-TWT member STAs (e.g., STA1, STA3, and STA 4) cannot contend for access using RA-RU 6 because RU6 has been allocated to STA(s) with group AID 2050.

Trigger frame 134 contains an allocation from the scheduling AP. STA1 and STA3 are members of this R-TWT SP and have pending frames for scheduling the AP. STA1 is allocated dedicated RUs (RU 1 and RU 2), and STA2 is allocated dedicated RUs (RU 3 and RU 4). Thus, STA1 and STA3 need not contend for the RA-RU, but instead transmit their pending frames on their assigned RU.

STA4 is a member of this R-TWT SP with pending frames for scheduling the AP. However, STA4 is not allocated RU in the trigger frame, so it will contend for RA-RU. STA4 decrements its OBO counter by the number of eligible RA-RUs indicated in the trigger frame (i.e., in this case, two RA-RUs for the associated STA). Assuming that STA 4's OBO counter is decremented to a non-zero value, it maintains the new OBO value until it receives a subsequent trigger frame from the scheduling AP carrying the RA-RU.

STA2 is not a member of this R-TWT SP and has a pending frame for scheduling the AP. STA2 decrements its new group AID OBO counter by the number of eligible RA-RUs indicated in the trigger frame (i.e., in this case, one RA-RU for the associated STA). Assuming that STA 2's OBO counter has been decremented to a final (zero) value, it transmits its pending frame on RU 6.

Thus, RU1 through RU4 and RU6 are shown transmitting 136TB PPDUs, in response to which 138MU BAs are received.

Emergency R-TWT membership settings for non-R-TWT member STAs in MLO

An MLD STA that does not have R-TWT membership in the currently ongoing R-TWT SP(s) on multiple links should be able to set the proposed R-TWT agreement(s) for multiple links through negotiations over any available links. It should be noted that ML R-TWT SP setup through negotiated frame exchange over one link has been proposed in the assignee's previous application.

Different proposed R-TWT conventions may be set on different links (section 4.3 to section 4.6). For example, R-TWT-X SP with UORA features on L2 (as set forth in section 4.5) and R-TWT-Z SP with unicast features on L3 (as set forth in section 4.6).

After receiving the TWT request frame, the scheduling AP should respond with a TWT response frame to announce acceptance of the new R-TWT agreement on any requested operating link(s).

4.9. Flow chart of protocol

Fig. 18-21 illustrate an example embodiment 150 of operations performed by an R-TWT scheduled STA.

In block 152, the STA obtains bursts of traffic from its application layer, which are placed in its EDCA queue. A check 154 determines whether the station has membership in the R-TWT SP on the transmission link. If it does have membership, then at block 156 the STA simply waits for a trigger from the scheduling AP and may then transmit.

If the STA is found not to be membership at block 154, then at block 158 the STA determines whether it will send a negotiation frame to request (or suggest) to be added as a member of the current R-TWT on the transmission link.

If the STA determines to request membership, at block 160 in fig. 19, a check is performed to determine if the STA has received a negotiation frame from the scheduling AP to accept its addition as a member of the current R-TWT on the transmission link.

If it is determined at block 160 that the STA has been added to the R-TWT on the transmission link, then execution moves to block 156 in fig. 18 where the STA waits for a trigger from the scheduling AP.

Otherwise, if it is determined at block 160 that the STA has not been added as a member for the transmission link, then the STA may still contend for the channel as a non-R-TWT member at block 162.

In the check 158 of fig. 18, if the STA does not request membership, a check 164 is made at block 164 of fig. 20 to determine if RA-RU(s) are enabled for all STAs.

If it is enabled for all STAs, the non-RWT STAs may contend for the RA-RU allocated for the associated STA at block 166. Otherwise, if RA-RU is not enabled for all stations, then at block 168 a check is made to determine if RA-RU is enabled only for non-RTWT STAs.

If the RA-RU is enabled only for non-R-TWT STAs, then the STAs may contend for the RA-RU allocated only to non-R-TWT STAs at block 170. Otherwise, execution moves to check 172 of FIG. 21.

At check 172, if RU(s) are guaranteed for the non-R-TWT STA, then the STA transmits on the guaranteed RU(s) at block 174. Otherwise, execution moves to block 176, where block 176 checks whether the STA has set a new R-TWT SP after the current R-TWT SP but before its own R-TWT SP. If there is no setting for R-TWT, then the process ends.

Otherwise, at block 178, a check is made to determine whether the STA has received a frame from the scheduling AP to accept the new setting of the new R-TWT. If it does not receive the frame, execution moves to block 162 in FIG. 19, which has been described. If it does receive the frame, the STA may contend for the channel or wait for a trigger from the scheduling AP in the new R-TWT SP at block 180.

Fig. 22-24 illustrate an example embodiment 190 of operations performed by an R-TWT scheduling AP. A check at block 192 determines whether the AP has received a negotiation frame requesting (suggesting) to be added as a temporary or long-term member of the current R-TWT, or to set a new temporary or long-term R-TWT on the transmission link.

If the condition of check 192 is not met, execution reaches block 198 in FIG. 23 and the AP does not spontaneously (automatically) trigger the non-R-TWT member STA and the process ends.

Otherwise, if the check 192 is satisfied, the AP responds to the requesting STA to indicate its acceptance or rejection at block 194. It is then determined at a check 196 whether the AP has accepted the requesting STA as a member of the requested R-TWT on the designated transmission link. If not, execution moves to block 198 in FIG. 23, as already described.

Otherwise, execution moves to block 200 in fig. 23 and the AP may trigger the non-R-TWT member station as an R-TWT member. Then, at check 202, it is determined whether RA-RU(s) are enabled for all associated STA transmissions. If the condition is met, the AP indicates at least one RA-RU for the STA in the trigger at block 204 and the process ends.

Otherwise, if the condition of check 202 is not met, then at check 206 in fig. 24, it is determined whether RA-RU(s) are enabled for non-R-TWT STA transmissions only. If the condition is met, at block 208, the AP indicates in the trigger at least one RA-RU assigned to the particular group AID only for non-R-TWT member STAs, and the process ends.

If the above condition is not met, a check 210 is performed to determine if the guaranteed RU(s) are enabled for the requesting non-R-TWT STA. If the condition is not satisfied, the process ends. Otherwise, block 212 is performed and the AP indicates that there is at least one guaranteed RU(s) for the requesting non-R-TWT STA.

4.10. New field and frame

Fig. 25 illustrates an example embodiment 230 of a temporary member subfield in a request type field in a broadcast TWT parameter set field for an R-TWT. The new subfield in the request type field of the broadcast TWT parameter set field is used by the non-AP STA to request a new member to be added as the current R-TWT SP. The scheduling AP may also use it to indicate acceptance of the request or assign new R-TWT membership for the current R-TWT for the requesting STA.

This new field is located inside the TWT element carried by negotiation frames (e.g., TWT requests and TWT responses) exchanged between the scheduling AP and the scheduled non-AP STA that has requested to become a temporary or long-term member of the R-TWT SP.

This newly proposed field (i.e., temporary member) may have two phases to indicate temporary membership (e.g., phase 0) or long-term membership (e.g., phase 1) requested by the scheduled STA or assigned by the scheduling AP.

The scheduled STA assigned temporary membership of the current R-TWT SP is given one-time R-TWT membership in the current R-TWT SP, where it should have the same priority as the original member of the current R-TWT SP.

Assigning long-term membership to requesting scheduled STAs so that a scheduling AP using a particular R-TWT SP should maintain membership for requesting non-AP scheduled STAs to use this R-TWT SP (identified by, for example, a broadcast TWT ID) until this non-AP STA tears down the R-TWT agreement.

All other subfields in the request type field in the broadcast TWT parameter set field are the same as described in fig. 4.

FIG. 26 illustrates an example embodiment 250 of an R-TWT information frame format with a temporary member subfield for the R-TWT. A STA that has an emergency burst Upload (UL) stream to transmit, but is not a member of the current R-TWT SP, may initiate an R-TWT information frame exchange with the scheduling AP. The non-R-TWT member STA may request to set a new (temporary or long term) R-TWT SP after the current R-TWT SP, and this should be earlier than its own R-TWT SP.

Upon receiving the R-TWT information frame from the non-AP STA, the scheduling AP may respond with a frame carrying the same field as the R-TWT information frame to indicate the next TWT start time and whether the new R-TWT SP is a temporary or long-term SP for the scheduled STA that requested this setting.

The fields preceding the new "temporary R-TWT" subfield are the same as those in the TWT information frame introduced in fig. 8, which should maintain the flexible TWT features defined in ieee 802.11ax_d8.0.

The temporary R-TWT field indicates that the new R-TWT SP temporary setting is only used for one time (if set to phase 1, for example) or long-term setting (set to phase 0, for example), which needs to be torn down by the STA that initiated the schedule of the setting.

The fields following the "temporary R-TWT" are the same as those in the limited TWT traffic information field introduced in fig. 6, which indicates TWT traffic information that has been requested/accepted in the new R-TWT SP.

The non-AP STAs that initiated the R-TWT information frames exchange and receive agreements from the scheduling AP and may use the new temporary/long-term R-TWT SPs to transmit prioritized burst UL streams.

4.11. Operation example

4.11.1. Emergency (temporary/permanent) R-TWT membership settings within a current R-TWT SP

Fig. 27 and 28 illustrate an example embodiment 310 of a process for performing emergency R-TWT membership for non-R-TWT member STAs during an R-TWT SP. Interactions between AP 312, STA1 314 and STA2 316 are seen.

The AP broadcasts beacon frame(s) 320 containing different broadcast TWT parameter sets 318 to set different R-TWT SPs, such as R-TWT-X SP and R-TWT-Y SP, identified by the broadcast TWT ID.

Both R-TWT-X SP and R-TWT-Y SP in this example are scheduled to enable the triggered R-TWT SP. STA1 is only a member of R-TWT-X SP; whereas STA2 is only a member of the R-TWT-Y SP. STA1 and STA2 are both Power Save (PS) STAs that wake up to receive beacon frame(s) to determine the R-TWT. When there is no communication, these STAs may doze 322, 324, such as seen at the beginning of the figure and after receiving a beacon frame from the scheduling AP.

During the trigger-enabled TWT SPs 326 and 356, the AP first sends a basic trigger frame 328 for which STA1 and STA2 indicate that they are awake during the TWT SP. STA1 and STA2 should wake up to receive DL PPDUs in the scheduled R-TWT SPs, which have R-TWT membership in the scheduled R-TWT SPs, and may enter a doze state outside of their R-TWT SPs.

In R-TWT-X SP, the following is shown. STA1, which is a member of the R-TWT-X SP, responds with a PS-Poll 330 to indicate that it is awake and receives an ACK/BA 332 from the AP. STA2 does not respond to the basic trigger frame, indicating that it is still dozing.

STA1 receives its DL PPDU 334 and sees a response with ACK/BA 336. After this exchange, STA1 goes to doze state 352 outside of this R-TWT-X SP.

STA2, which is a non-member of the R-TWT-X SP, is shown to wake up in the event that an emergency UL RTA stream is to be transmitted, which causes STA2 to change from the dozing state to the awake state. STA2 is shown initiating an R-TWT negotiation request 338 with the scheduling AP by sending a negotiation frame (e.g., TWT request) carrying a TWT element.

The TWT set command subfield in the broadcast TWT parameter set field should be set to either "request TWT" or "suggest TWT" to leave the decision to the scheduling AP.

The requesting/suggesting non-AP STA shall indicate its request to be a temporary or long-term member of the requested R-TWT-X SP by indicating this in a new temporary member subfield in the request type field in the broadcast TWT parameter set field as described in fig. 25.

If the scheduling AP agrees to the requested/proposed TWT parameter set, it should respond with a TWT response frame 340 with a TWT set command field set to "accept TWT" and indicate the period of agreed membership (i.e., temporary or long term) in the newly proposed temporary member subfield in the request type field in the broadcast TWT parameter set field as described in fig. 25.

The scheduling AP may send a BSRP frame 342 to STA2 to trigger a BSR frame 344 and use BSR information to allocate RUs to STA2 for transmission of UL TB PPDUs. The allocation of RU information for STA2 is carried in the basic trigger frame 346. Upon receiving the basic trigger frame, STA2 should transmit the UL trigger-based (TB) PPDU 348(s) using the allocated RU. The scheduling AP should respond with an ACK/BA 350 after receiving the PPDU(s) from STA 2. STA2 is then seen to return to the dozing state 354.

In R-TWT-Y SP, the following is shown:

STA2, which is a member of R-TWT-Y SP 356 wakes up and responds with PS-Poll 360 to a basic trigger frame 358 from the scheduling AP to indicate that it is awake, and an ACK/BA 362 is sent by the AP. It will be noted that STA1 does not respond to the basic trigger frame, indicating that it is sleeping (dozing) 352.

STA2 receives its DL PPDU 364 and responds with an ACK/BA 366 in subsequent exchanges with the AP and may then return to the doze state outside this R-TWT-Y SP.

4.11.2. Emergency new R-TWT SP settings during a current R-TWT SP

Fig. 29 and 30 illustrate an example embodiment 410 of a setup procedure for a new R-TWT SP for a non-R-TWT member STA during an ongoing R-TWT SP. Again, the interaction between AP 312, STA1 314, and STA2 316 is seen.

The AP broadcast beacon frame(s) 320 contain different broadcast TWT parameter sets 318 to set different R-TWT SPs (e.g., R-TWT-X SP, R-TWT-Y SP, and R-TWT-Z SP) identified by the broadcast TWT ID.

In this example, both R-TWT-X SP 412 and R-TWT-Y SP 446 are scheduled to enable the triggered R-TWT SP. The R-TWT-Z SP 436 is not an enabled triggered R-TWT SP.

STA1 is only a member of R-TWT-X SP; whereas STA2 is only a member of the R-TWT-Y SP. STA1 and STA2 are both Power Save (PS) STAs that wake up to receive the beacon frame(s) to determine the R-TWT and may doze after receiving the beacon frame from the scheduling AP.

During the trigger-enabled TWT SP, the AP first sends basic trigger frames 414 and 438 for which STA1 and STA2 indicate that they are awake during the TWT SP.

STA1 and STA2 should wake up in their scheduled R-TWT SPs with R-TWT membership to receive the DL PPDU and return to the doze state outside of their R-TWT SPs.

In R-TWT-X SP:

STA1, which is a member of the R-TWT-X SP, responds with a PS-Poll 416 to the basic trigger frame 414 to indicate that it is awake. STA2 does not respond to the basic trigger frame, indicating that it is dozing.

STA1 receives its DL Buffer Unit (BU) 420 depicted with DL SU/MU PPDU(s) and responds with an ACK/BA 422. After R-TWT-X SP, STA1 may return/enter dozing state 430.

STA2, which is a non-member of the R-TWT-X SP, is shown as having an urgent UL RTA stream to be transmitted, whereby STA2 changes from the dozing state to the awake state. STA2 is seen to send R-TWT information frame 424 to the scheduling AP to request/suggest that the scheduling AP set a new (temporary/long-term) R-TWT SP after the current R-TWT-X SP and before its own R-TWT-Y SP.

The R-TWT information frame should set the request response field and the next TWT request field to zero to indicate that the response need not be an R-TWT information frame. The requesting/suggesting non-AP STA should indicate whether a temporary or long-term R-TWT SP is needed by indicating this in the temporary R-TWT field in the R-TWT information frame as defined in fig. 26.

After receiving the R-TWT information frame from the non-AP STA, the AP is scheduled to respond with a frame 426 carrying the fields contained in the R-TWT information frame and set the next TWT to the earliest time to start a new R-TWT SP. The request response field and the next TWT request field should be set to zero.

The scheduling AP should indicate whether to agree to a temporary or long-term R-TWT SP in this setting by indicating this in the temporary R-TWT field in the R-TWT information frame as defined in fig. 26.

In the new (temporary or long term) R-TWT-X+1SP 428, the following is shown. This SP is seen to overlap partially with the existing R-TWT-Z SP in the time domain. In this case, although STA2 does not have R-TWT membership of R-TWT-Z, it should still have high access priority as a member of R-TWT during all R-TWT-x+1sps.

During R-TWT-x+1sp, the scheduling AP may send a Buffer Status Report Poll (BSRP)/Trigger Response Scheduling (TRS) frame 432 to STA2 to trigger a BSR frame 434, wherein the AP may allocate an RU to STA2 to transmit the UL TB PPDU with BSR information. The allocation of RU for STA2 is carried in the basic trigger frame 438. After receiving the basic trigger frame, STA2 should transmit UL TB PPDU 440 using the allocated RU. The scheduling AP should respond with an ACK/BA 442 after receiving the PPDU(s) from STA 2. STA2 may return to the dozing state 444 after this R-TWT-X+1SP.

In R-TWT-Y SP:

STA2, which is a member of the R-TWT-Y SP, responds with PS-Poll 450 to the basic trigger frame 448 from the scheduling AP to indicate that it is awake, for which the AP sends an ACK/BA 452. However, STA1 does not respond to the basic trigger frame, which indicates that it is dozing.

STA2 receives its DL BU (e.g., DL SU/MU PPDU) 454 in exchange with the AP and responds with an ACK/BA 456. STA2 may return to the dozing state beyond this R-TWT-Y SP.

4.11.3. Emergency non-R-TWT member STA transmissions using UORA

The following example is based on the new implementation described in section 4.5.

Fig. 31 illustrates an example embodiment 510 of a non-R-TWT member STA transmitting using UORA in its non-membership R-TWT SP. The STA and AP shown are the same as in the first two figures.

The AP broadcasts beacon frame(s) 320 containing different broadcast TWT parameter sets 318 to set different R-TWT SPs. For example, R-TWT-X SP is shown with a broadcast TWT recommendation field set to a value of "5" to indicate that UORA is enabled in R-TWT-X SP 512 and a broadcast TWT recommendation field set to a value of "4" in R-TWT-Y SP 528 to indicate that it is the original R-TWT-Y SP.

STA1 is only a member of R-TWT-X SP; whereas STA2 is only a member of the R-TWT-Y SP.

In R-TWT-X SP 512, the scheduling AP may broadcast trigger frames 518 and 524 (e.g., the first two trigger frames as shown in this figure) along with RA-RU 516.

Upon receiving the first trigger frame, STA1, which is a member of the R-TWT-X SP, does not need to contend for RA-RU 514, but instead transmits its pending PPDU 520 on the assigned RUs (e.g., RU1 through RU 3) as indicated in the trigger frame. STA2, which is a non-R-TWT-X member STA, may decrement its OBO counter to contend for a qualified RA-RU (e.g., RU4, 5) as indicated in the trigger frame. In this example, STA 2's OBO counter counts down to zero after receiving the first trigger frame, STA2 selects RU4 from among the eligible RA-RUs to transmit UL PPDUs 522. The AP should respond with an ACK/BA (not shown) as a reception of the UL PPDU.

Upon receiving the second trigger frame 524, STA1, which is a member of the R-TWT-X SP, does not contend for the RA-RU, but instead transmits its pending PPDU 526 on the assigned RU (e.g., RU 1-7) as indicated in the trigger frame. STA2, which is a non-R-TWT-X member STA, may decrement its OBO counter to contend for a qualified RA-RU (e.g., RU 8) as indicated in the trigger frame. In this example, STA 2's OBO counter decrements to a non-final (non-zero) value after receiving the first trigger frame, and STA2 maintains the OBO value until it later receives a trigger frame carrying the RA-RU for the associated STA, restoring the countdown.

In R-TWT-Y SP 528, UORA 530 is not allowed. When a non-R-TWT-Y member STA (e.g., STA 1) has bursty UL traffic to transmit, it may need to first acquire temporary or long-term membership of R-TWT-Y, as described in sections 4.3 and 4.4.

Fig. 32 and 33 illustrate an example embodiment 610 of a non-R-TWT member STA transmitting a BSR using a RA-RU in its non-membership R-TWT SP. The STA and AP are the same as described in the above figures, with other aspects similar to this example, the differences being as follows.

The beacon 320 is transmitted with the broadcast TWT parameter set 318, defining R-TWT-X SP with RA-RU 614 and describing the triggered-enabled R-TWT-Y SP 630 with no guarantees 632 of RA-RU.

Within trigger-enabled R-TWT-X SP 612, since STA1 is a member, when STA1 receives the first and second trigger frames (618 and 624), it sees that UL PPDUs 620 and 626 (e.g., the first PPDU on RU1 through RU3, and the second PPDU on RU1 through RU 7) are transmitted on the assigned RUs, respectively.

Upon receiving this first trigger frame 618, STA2 responds as a non-R-TWT-X member STA by decrementing its OBO counter to contend for the eligible RA-RUs (e.g., RU4 and RU 5) as indicated in the trigger frame. In this example, the OBO counter of STA2 counts down to a final count (zero) after receiving this first trigger frame, and STA2 selects RU4 from among the eligible RA-RUs to transmit BSR 622. The AP should allocate RU to STA2 in the next trigger frame based on the buffer status information indicated in the BSR.

Upon receiving the second trigger frame 624, STA2 is assigned RUs (e.g., RU8 and RU 9), and it should be able to directly transmit UL PPDU(s) 628 using the assigned RUs without competing for a qualified RA-RU.

Fig. 34 illustrates an example embodiment 710 of a non-R-TWT member STA performing initialization to use UORA during its non-membership R-TWT SP. The STA and AP are the same as described in the above figures.

The AP broadcasts beacon frame(s) 320 containing different broadcast TWT parameter sets 318 to set different R-TWT SPs (e.g., R-TWT-X SP 712 and R-TWT-Y SP 726). Both R-TWTs SPs in this example are provided with a broadcast TWT recommendation field of value "4", indicating that only R-TWTs are absent of UORA. STA1 is only a member of R-TWT-X SP; whereas STA2 is only a member of the R-TWT-Y SP.

In R-TWT-X SP 712, the scheduling AP broadcasts the trigger frame without the guarantee of RA-RU 714. Thus, only the triggered non-AP STAs may transmit a TB UL PPDU using the allocated RU indicated in each trigger frame.

When a non-R-TWT-X member STA (e.g., STA 2) has bursts of RTA traffic to transmit, it attempts to establish an R-TWT agreement with the scheduling AP during the R-TWT-X SP to request the scheduling AP to initiate UORA in the R-TWT-X SP, either temporarily or within a long-term setting.

In this example, the non-R-TWT-X member STA2 initiates the setting by transmitting a TWT setting request frame 716, and wherein the broadcast TWT recommendation field is set to a value indicating that R-TWT SP has UORA enabled, e.g. "5", and wherein the TWT setting command field is set to "request/propose TWT" to leave the decision to the scheduling AP.

Upon receiving the TWT request frame 716 from the non-R-TWT-X member STA2, the scheduling AP responds with a TWT response 718 frame to indicate whether it accepts the new R-TWT parameters. In this example, the scheduling AP accepts the request and indicates 720 a new R-TWT parameter set in a TWT response frame, with the TWT set command field set to "accept TWT" and the broadcast TWT recommendation field set to a value, example "5".

It should be noted that STA2 becomes a temporary or long-term R-TWT-X member STA after receiving the TWT response frame from the scheduling AP, and if the AP allocation is based on the received BSR, it should be able to transmit the TB PPDU by accessing the RA-RU or the access allocated RU, as described in section 4.3.

The transmission procedure in the R-TWT-X SP with RA-RU is similar to the previous examples of fig. 32 and 33, except that STA2 gets membership in the R-TWT-X SP in this example case.

After sending the TWT response 718 with its parameter set 721, the AP changes the R-TWT SP to UORA, allowing RA-RU 724. The AP then transmits a trigger frame 722.

After the R-TWT-X SP ends, then an enabled trigger R-TWT-Y SP 726 is shown that has no guarantee 728 of RA-RU.

When a non-R-TWT-Y member STA (e.g., STA 1) has bursty UL traffic to transmit, it may need to first acquire temporary or long-term membership of R-TWT-Y, as described in sections 4.3 and 4.4.

4.11.4. Emergency non-R-TWT member STA Tx using unicast RU(s)

Fig. 35 illustrates an example embodiment 810 of a non-R-TWT member STA transmitting using unicast RU(s) in its initially non-membership R-TWT SP. The AP and STA are the same as in the previous figures.

The AP broadcasts beacon frame(s) 320 containing different broadcast TWT parameter sets 318, which are used to set different R-TWT SPs (e.g., R-TWT-X SP and R-TWT-Y SP). Both R-TWTs SPs in this example are provided with a broadcast TWT recommendation field set to a value, example "4", indicating that only R-TWTs without unicast RU(s) are to be performed. STA1 is only a member of R-TWT-X SP; whereas STA2 is only a member of the R-TWT-Y SP.

In R-TWT-X SP 812, the scheduling AP broadcasts a trigger frame without RA-RU. Thus, only triggered non-AP STAs may transmit a TB UL PPDU using the assigned RU indicated in each trigger frame.

When a non-R-TWT-X member STA (e.g., STA 2) has bursts of RTA traffic to transmit, it is shown that an R-TWT-X agreement is established with the scheduling AP as a temporary setting for unicast RU request(s) in the R-TWT-X SP during the R-TWT-X SP 812.

The non-R-TWT-X member STA2 may initiate the setting by transmitting a TWT setting request frame 814, wherein the broadcast TWT recommendation field is set to a value, e.g., "6", indicating that the R-TWT SP with unicast RU(s) is enabled, and wherein the TWT setting command field is set to "request/suggest a TWT" to allow the scheduling AP to make a decision.

Upon receiving the TWT request frame from the non-R-TWT-X member STA2, the scheduling AP responds with a TWT response frame 816 to indicate whether it accepts the new R-TWT parameter set. In this example, the scheduling AP accepts the new R-TWT parameter indicated 818 in the TWT response frame with the TWT set command field being "accept TWT" and the broadcast TWT recommendation field being a value exemplified as "6".

The R-TWT-X SP 812 is changed according to the broadcast TWT parameter set 820 and the AP sends a trigger 822 with RU information. STA2 transmits a UL PPDU 826 on RU5, which is received 824 by the AP.

It should be noted that STA2 becomes a temporary R-TWT-X member STA after receiving the TWT response frame from the scheduling AP, and thus STA2 should be able to transmit the TB PPDU by accessing the allocated RU (i.e., RU 5).

In the next SP (which is R-TWT-Y SP 828), unicast RU(s) 830 are not allowed. When a non-R-TWT-Y member STA (e.g., STA 1) has bursts of UL traffic to transmit, it may first need to acquire temporary membership in R-TWT-Y.

4.11.5. Emergency non-R-TWT member STA transmissions

Fig. 36 illustrates an example embodiment 850 of a simple topology of an MLO scene, which consists of three MLDs. AP MLD 852 has three affiliated APs operating on three different links, exemplified by AP1 858 on L1, AP2 860 on L2, and AP3 862 on L3.

MLD2 854 has two dependent STAs operating on two different links, namely STA1 864 on L1 and STA2 866 on L2. MLD3 856 has two dependent STAs operating on two different links, namely STA3 868 on L2 and STA4870 on L3.

Fig. 37 illustrates an example embodiment 910 of setting up an emergency R-TWT agreement on multiple links for an MLD STA that does not have R-TWT membership in the current R-TWT SP(s) on any link. The MLDs that interact are those seen in fig. 36.

Scheduling MLD AP has scheduled R-TWT-X SPs for MLD2 on L1 912 and L2 914, and has scheduled R-TWT-Y SPs for MLD3 on L2 930 and 934 and on L3 932 and 936. The MLD2 is not shown in the figure, as it is not the focus of this example.

This example assumes that MLD3 has emergency burst UL traffic 916 to be transmitted during R-TWT-X SP, where MLD3 has not yet acquired membership on L1 and L3. MLD3 may use L3 to transmit buffered packets, which is shown as a packet exchange on L3 between STA4 and AP3 during R-TWT-XSP on L1 and L2. In this case, STA4 transmits an RTS 918 and receives a CTS 920, and then STA4 transmits a UL PPDU 922 and receives an ACK/BA 924. In addition to using only L3, MLD3 may request to become a member of the current R-TWT-X SP on L2 and may request to set a new R-TWT-ZSP on L3. It should negotiate new R-TWT-X settings and new R-TWT-Z settings with MLD1 on L2 and L3, respectively, by sending R-TWT negotiation frames on any available link.

In this example, different broadcast TWT agreements may be established on different links; for example, R-TWT-X SP with UORA features on L2 (as set forth in section 4.5) and R-TWT-Z SP with unicast features on L3 (as set forth in section 4.6).

Negotiation frames (e.g., TWT requests and TWT responses) are exchanged between STA4 and AP3 on L3. Upon receiving the TWT request frame 926 on L3, AP3 should respond with a TWT response frame 928 to advertise acceptance of the new R-TWT-X agreement on L2 and/or the new R-TWT-Z agreement on L3. After receiving the TWT response frame, STA3 from MLD3 is added as a temporary/long-term member on L2 using R-TWT-X SPs 930 and 934. Meanwhile, STA4 from MLD3 is a member on L3 that uses new R-TWT-Z SPs 932 and 936.

MLD3 is a member of R-TWT-Y SP on L2 and L3, so R-TWT-Y SP on L2 938 and L3 940 can be accessed with the highest priority of R-TWT members.

5. General scope of the examples

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, formulas, or other computational depictions that may also be implemented as a computer program product. In this regard, each block or step of the flowcharts, combinations of blocks (and/or steps) in the flowcharts, and any process, algorithm, step, operation, formula, or computational depiction may be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions contained in computer readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors (including, but not limited to, general purpose or special purpose computers, or other programmable processing devices that produce a machine), such that the computer program instructions, which execute on the computer processor(s) or other programmable processing devices, create means for implementing the specified function(s).

Thus, blocks and processes of the flowcharts, algorithms, steps, operations, formulas, or computational descriptions described herein support combinations of means for performing the specified functions(s), combinations of steps for performing the specified functions(s), and computer program instructions for performing the specified functions(s) (such as implemented in computer readable program code logic means). It will also be understood that each block of the flowchart illustrations described herein, and any process, algorithm, step, operation, formula, or computational depiction, and combinations thereof, 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.

Furthermore, such computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer-readable memories 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 memories 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 flowchart block(s), process(s), algorithm(s), step(s), operation(s), formula(s), or computational depiction(s).

It will also be appreciated that the term "programming" or "program executable" as used herein refers 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 may be implemented as software, firmware, or a combination of software and firmware. The instructions may be stored locally in a device that is a non-transitory medium, or may be stored remotely, such as on a server, or all or part of the instructions may be stored locally and remotely. The remotely stored instructions may be downloaded (pushed) to the device either by user initiation or automatically based on one or more factors.

It will also be appreciated that as used herein, the terms processor, hardware processor, computer processor, central Processing Unit (CPU), and computer are synonymously used to denote a device capable of executing 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 include single or multiple devices, single and multi-core devices, and variations thereof.

From the description herein, it will be appreciated that the present disclosure encompasses various embodiments of the technology, including but not limited to the following:

An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit that is a wireless Station (STA) that is a stand-alone Station (STA) or an STA in a multi-link device (MLD) and that operates as a regular STA or an Access Point (AP) STA for wireless communication with other wireless Stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links; (b) A processor coupled to the wireless communication circuit for operating on a WLAN; (c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs; and (d) wherein the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, comprising:

(d) (i) queuing, by a non-AP STA, an emergency burst of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership; (d) (ii) initiating, within an ongoing R-TWT SP, from the non-AP STA, an R-TWT negotiation with an AP that performs scheduling as a scheduling AP, wherein the negotiation comprises a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled; (d) (iii) wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs; and (d) (iv) wherein the non-AP STA transmits an emergency burst of its RTA traffic in response to the membership request being accepted: (a) in the specific R-TWT SP; or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled.

An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit that is a wireless Station (STA) that is a stand-alone Station (STA) or an STA in a multi-link device (MLD) and that operates as a regular STA or an Access Point (AP) STA for wireless communication with other wireless Stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links; (b) A processor coupled to the wireless communication circuit for operating on a WLAN; (c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs; and (d) wherein the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, comprising:

(d) (i) queuing, by a non-AP STA, an emergency burst of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership; (d) (ii) initiating, within an ongoing R-TWT SP, from the non-AP STA, an R-TWT negotiation with an AP that performs scheduling as a scheduling AP, wherein the negotiation comprises a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled; (d) (iii) wherein the R-TWT negotiation is based on the non-AP STA transmitting TWT request frames and receiving TWT response frames, each of these frames carrying a TWT information element that includes a negotiation type subfield indicating this negotiation form; (d) (iv) wherein the TWT information element includes a subfield for a request type field indicating temporary or long term membership in a current R-TWT, the subfield being usable by the scheduling AP to indicate whether membership is accepted; (d) (v) wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs; (d) (vi) wherein in response to a membership request being accepted, the non-AP STA transmits an emergency burst of its RTA traffic: (a) in the specific R-TWT SP; or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled; and (d) (vii) wherein UORA can be enabled in response to setting a value in the broadcast TWT recommendation field for requesting that UORA having at least one RA-RU feature be enabled in the R-TWT.

A method of performing wireless communication in a network, the method comprising: (a) Communicating between wireless Stations (STAs), which are STAs within a single STA or multi-link device (MLD), and each operating as an Access Point (AP) or a non-AP STA, for wireless communication with other wireless STAs using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links; (b) Queuing, by a non-AP STA, emergency bursts of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership; (c) Initiating, from the non-AP STA, an R-TWT negotiation with an AP performing scheduling as a scheduling AP within an ongoing R-TWT SP, wherein the negotiation includes a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled; (d) Wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs; and (e) wherein the non-AP STA transmits an emergency burst of its RTA traffic in response to the membership request being accepted: (a) in the specific R-TWT SP; or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled.

The apparatus or method of any preceding embodiment, wherein the R-TWT negotiation is based on the non-AP STA transmitting TWT request frames and receiving TWT response frames, each of these frames carrying a TWT information element that includes a negotiation type subfield that indicates this form of negotiation.

The apparatus or method of any preceding embodiment, wherein the TWT information element further includes a subfield for a request type field indicating temporary or long term membership in a current R-TWT, the subfield being usable by the scheduling AP to indicate whether membership is accepted.

The apparatus or method of any of the preceding embodiments, wherein the UORA can be enabled in response to setting a value in the broadcast TWT recommendation field requesting that UORA having at least one RA-RU feature be enabled in the R-TWT.

The apparatus or method of any of the preceding embodiments, wherein if UORA is enabled, the non-AP STAs scheduled for any R-TWT are able to contend for RA-RU transmissions in the current R-TWT SP.

The apparatus or method of any of the preceding embodiments, wherein if UORA is enabled, non-AP STAs that are not scheduled for any R-TWT are able to contend for RA-RU transmissions in the current R-TWT SP.

An apparatus or method of any of the preceding embodiments, wherein after an OFDMA Backoff (OBO) counter of a non-AP STA reaches a final count, the non-AP STA, although not an R-TWT member STA, can send a UL PPDU directly using one RA-RU or can send a Buffer Status Report (BSR) in the RA-RU to allow the scheduling AP to allocate a specific RU for it to perform direct access in the next triggered UL PPDU transmission.

The apparatus or method of any of the preceding embodiments, wherein the non-AP STA that is the STA of the R-TWT schedule requests to join the current R-TWT SP using a guaranteed unicast RU assigned to a specific Association Identifier (AID) that it owns.

The apparatus or method of any of the preceding embodiments, wherein the value of the broadcast TWT recommendation field indicates a request for the guaranteed unicast RU allocation.

The apparatus or method of any of the preceding embodiments, wherein the guaranteed unicast RU allocation cannot be scheduled at the beginning of any R-TWT SP.

The apparatus or method of any of the preceding embodiments, wherein the non-AP STA for any R-TWT schedule is capable of initiating the guaranteed unicast RU allocation during a currently ongoing R-TWT SP by exchanging negotiation frames with the scheduling AP.

The apparatus or method of any of the preceding embodiments, wherein upon receiving an acceptance message from the scheduling AP, the non-AP STA is able to immediately access the guaranteed unicast RU assigned to its AID for transmission in this R-TWT SP.

The apparatus or method of any of the preceding embodiments, wherein the non-AP STA being an R-TWT scheduled STA is capable of competing for a new group Association Identification (AID) on an assigned RA-RU designated for non-AP STAs that are not R-TWT members.

The apparatus or method of any of the preceding embodiments, wherein the broadcast TWT recommendation field is set to a particular value to indicate that a non-AP STA that is not a member of the R-TWT enables RA-RU access.

The apparatus or method of any of the preceding embodiments, wherein competing for a new group Association Identity (AID) on the allocated RA-RU can be scheduled at the beginning of any R-TWT SP.

The apparatus or method of any of the preceding embodiments, wherein the new AID is carried in a beacon frame and broadcast periodically.

The apparatus or method of any of the preceding embodiments, wherein non-AP STAs that have not acquired membership in the current R-TWT SP are able to contend for access to RA-RUs specifically assigned to the new group AID for transmission in this R-TWT SP.

The apparatus or method of any of the preceding embodiments, wherein the non-AP STA that is a scheduled R-TWT STA is capable of: (A) Temporary membership of the R-TWT SP assigned to be currently ongoing once; (B) assigned long-term membership that can be revoked at any time.

The apparatus or method of any of the preceding embodiments, wherein the non-AP STA that is a member of the scheduled R-TWT as a MLD STA is capable of requesting different R-TWT agreements to be set on its multiple links.

As used herein, the term "embodiment" is intended to include, but not be limited to, examples, illustrations, or other forms of practicing the techniques described herein.

As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. References to objects in the singular are not intended to mean "one and only one" unless explicitly so stated, but rather "one or more.

Phrase constructs within the present disclosure (such as "A, B and/or C") describe any combination in which A, B or C, or terms A, B and C, can be present. Phrase constructs indicating that a group of elements such as "at least one" is followed by a list of elements indicate that at least one of the group elements is present, including any possible combination of the listed elements (as applicable).

Reference in the present disclosure to "an embodiment," "at least one embodiment," or similar embodiment phrases, indicates that a particular feature, structure, or characteristic described in connection with the 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 particular embodiments different from all other embodiments described. The embodiment language should be construed to mean that a particular feature, structure, or characteristic of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

As used herein, the term "collection" refers to an aggregate of one or more objects. Thus, for example, a collection of objects may 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 "comprises," "comprising," "having," "containing," "including," "containing," "involving," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the elements preceded by "include," "have," "contain," and "contain" do not preclude the presence of exactly the same element in a process, method, article, or apparatus that comprises, has, contains the element.

As used herein, the terms "approximately," "substantially," and "about" or any variation thereof are used to describe and explain within a context of a minor variation. When used in connection with an event or circumstance, the term can refer to instances where the event or circumstance happens to occur and instances where the event or circumstance similarly occurs. When used in conjunction with a numerical value, the term may refer to a range of variation of less than or equal to ±10% of the 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%. For example, aligned "substantially" may 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°.

Additionally, quantities, ratios, and other numerical values may sometimes be presented herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be interpreted flexibly to include the numerical values explicitly recited as the limits of the range, as well as to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. For example, a ratio in 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 sub-ranges such as about 10 to about 50, about 20 to about 100, etc.

The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in some way is configured in at least this way, but may also be configured in ways that are not listed.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Furthermore, in the foregoing disclosure, various features may be combined together in various embodiments for the purpose of simplifying 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 lie in less than all features of a single disclosed embodiment.

The Abstract of the disclosure is provided 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.

It will be appreciated that the practice of some jurisdictions may require that one or more portions of the present disclosure be deleted after the filing of the present application. Thus, the reader should review the filed application to obtain the original disclosure. Any deletion of the present disclosure should not be construed as giving up, or leaving out, or dedicating any subject matter of the initially filed application to the public.

The following claims are hereby incorporated into the disclosure, with each claim standing on its own as a separately claimed subject matter.

While the description herein contains many specifics, these should not be construed as limiting the scope of the present disclosure, but merely as providing illustrations of some of the presently preferred embodiments. Accordingly, it should be understood that the scope of the present disclosure fully encompasses other embodiments that may become obvious to those skilled in the art.

All structural and functional equivalents to the elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims of this application. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. The claim elements herein should not be construed as "means plus function" elements unless the use of the phrase "means for..once more. The claim elements herein should not be construed as "step plus function" elements unless the use of the phrase "step for..once.

Table 1AID12 subfield coding

/>

Claims (21)

1. An apparatus for wireless communication in a network, the apparatus comprising:

(a) A wireless communication circuit that is a wireless Station (STA) that is a stand-alone Station (STA) or an STA in a multi-link device (MLD) and that operates as a regular STA or an Access Point (AP) STA for wireless communication with other wireless Stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links;

(b) A processor coupled to the wireless communication circuit for operating on a WLAN;

(c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs; and

(d) Wherein the instructions, when executed by a processor, perform steps of a wireless communication protocol for the wireless communication circuit, comprising:

(i) Queuing, by a non-AP STA, emergency bursts of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership;

(ii) Initiating, from the non-AP STA, an R-TWT negotiation with an AP performing scheduling as a scheduling AP within an ongoing R-TWT SP, wherein the negotiation includes a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled;

(iii) Wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs; and

(iv) Wherein in response to a membership request being accepted, the non-AP STA transmits an emergency burst of its RTA traffic: (a) in the specific R-TWT SP;

or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled.

2. The apparatus of claim 1, wherein the R-TWT negotiation is based on the non-AP STA transmitting TWT request frames and receiving TWT response frames, each of these frames carrying a TWT information element that includes a negotiation type subfield that indicates this form of negotiation.

3. The apparatus of claim 2, wherein the TWT information element further includes a subfield for a request type field indicating temporary or long term membership in a current R-TWT, the subfield operable by the scheduling AP to indicate whether to accept membership.

4. The apparatus of claim 1, wherein UORA is enabled in response to setting a value in a broadcast TWT recommendation field for requesting that UORA with at least one RA-RU feature be enabled in R-TWT.

5. The apparatus of claim 1, wherein if UORA is enabled, non-AP STAs scheduled for any R-TWT are able to contend for RA-RU transmissions in a current R-TWT SP.

6. The apparatus of claim 1, wherein if UORA is enabled, non-AP STAs not scheduled for any R-TWT are able to contend for RA-RU transmissions in a current R-TWT SP.

7. The apparatus of claim 6, wherein after an OFDMA Backoff (OBO) counter of a non-AP STA reaches a final count, the non-AP STA can directly transmit UL PPDUs using one RA-RU, although not an R-TWT member STA, or can transmit a Buffer Status Report (BSR) in the RA-RU to allow the scheduling AP to allocate a specific RU for it to perform direct access in a next triggered UL PPDU transmission.

8. The apparatus of claim 1, wherein a non-AP STA that is an R-TWT scheduled STA requests to join a current R-TWT SP using a guaranteed unicast RU assigned to a particular Association Identification (AID) that it owns.

9. The apparatus of claim 8, wherein a value of a broadcast TWT recommendation field indicates a request for the guaranteed unicast RU allocation.

10. The apparatus of claim 8, wherein the guaranteed unicast RU allocation cannot be scheduled at the beginning of any R-TWT SP.

11. The apparatus of claim 8, wherein a non-AP STA scheduled for any R-TWT is capable of initiating the guaranteed unicast RU allocation during a currently ongoing R-TWT SP by exchanging negotiation frames with the scheduling AP.

12. The apparatus of claim 8, wherein upon receiving an accept message from the scheduling AP, a non-AP STA can immediately access a guaranteed unicast RU assigned to its AID for transmission in this R-TWT SP.

13. The apparatus of claim 1, wherein the non-AP STA that is an R-TWT scheduled STA is capable of competing for a new group Association Identification (AID) on an assigned RA-RU designated for non-AP STAs that are not R-TWT members.

14. The apparatus of claim 13, wherein the broadcast TWT recommendation field is set to a particular value to indicate that a non-AP STA that is not a member of the R-TWT enables RA-RU access.

15. The apparatus of claim 13, wherein competing for a new group Association Identity (AID) on an allocated RA-RU can be scheduled at the beginning of any R-TWT SP.

16. The apparatus of claim 13, wherein the new AID is carried in a beacon frame and broadcast periodically.

17. The apparatus of claim 13, wherein non-AP STAs that have not acquired membership in a current R-TWT SP are able to contend for access to RA-RUs specifically assigned to a new group AID for transmission in this R-TWT SP.

18. The apparatus of claim 1, wherein the non-AP STA that is a scheduled R-TWT STA is capable of: (A) Temporary membership of the R-TWT SP assigned to be currently ongoing once; (B) assigned long-term membership that can be revoked at any time.

19. The apparatus of claim 1, wherein the non-AP STA that is a member of a scheduled R-TWT that is a MLD STA is capable of requesting different R-TWT agreements to be set on its multiple links.

20. An apparatus for wireless communication in a network, the apparatus comprising:

(a) A wireless communication circuit that is a wireless Station (STA) that is a stand-alone Station (STA) or an STA in a multi-link device (MLD) and that operates as a regular STA or an Access Point (AP) STA for wireless communication with other wireless Stations (STAs) using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links;

(b) A processor coupled to the wireless communication circuit for operating on a WLAN;

(c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs; and

(d) Wherein the instructions, when executed by a processor, perform steps of a wireless communication protocol for the wireless communication circuit, comprising:

(i) Queuing, by a non-AP STA, emergency bursts of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership;

(ii) Initiating, from the non-AP STA, an R-TWT negotiation with an AP performing scheduling as a scheduling AP within an ongoing R-TWT SP, wherein the negotiation includes a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled;

(iii) Wherein the R-TWT negotiation is based on the non-AP STA transmitting TWT request frames and receiving TWT response frames, each of these frames carrying a TWT information element comprising a negotiation type subfield indicating such a negotiation format;

(iv) Wherein the TWT information element includes a subfield for a request type field indicating temporary or long term membership in a current R-TWT, the subfield being usable by the scheduling AP to indicate whether membership is accepted;

(v) Wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs;

(vi) Wherein in response to a membership request being accepted, the non-AP STA transmits an emergency burst of its RTA traffic: (a) in the specific R-TWT SP;

or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled; and

(vii) Wherein UORA can be enabled in response to setting a value in the broadcast TWT recommendation field for requesting that UORA having at least one RA-RU feature be enabled in the R-TWT.

21. A method of performing wireless communication in a network, the method comprising:

(a) Communicating between wireless Stations (STAs), which are STAs within a single STA or multi-link device (MLD), and each operating as an Access Point (AP) or a non-AP STA, for wireless communication with other wireless STAs using a carrier sense multiple access/collision avoidance (CSMA/CA) mechanism over a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is used for random channel access on all links;

(b) Queuing, by a non-AP STA, emergency bursts of real-time application (RTA) traffic for transmission to an AP during an ongoing random target wait time (R-TWT) Service Period (SP), wherein the non-AP R-TWT STA does not have R-TWT membership;

(c) Initiating, from the non-AP STA, an R-TWT negotiation with an AP performing scheduling as a scheduling AP within an ongoing R-TWT SP, wherein the negotiation includes a request for: (A) Temporary or long-term membership in a particular R-TWT SP that is a current R-TWT SP, or an R-TWT SP that follows a currently ongoing R-TWT SP but precedes an R-TWT SP that the non-AP STA initially has R-TWT membership, or (B) contend for a random access-resource unit (RA-RU) in the current R-TWT SP if uplink orthogonal frequency division multiple access based random access (UORA) feature is enabled;

(d) Wherein the scheduling AP is capable of accepting or rejecting membership requests from non-AP STAs issuing membership requests, or it is capable of indicating alternative R-TWT settings or specifying preferred R-TWT settings from STAs; and

(e) Wherein in response to a membership request being accepted, the non-AP STA transmits an emergency burst of its RTA traffic: (a) in the specific R-TWT SP; or (B) contend for RA-RU in the current R-TWT SP if UORA is enabled.