Permission for non-R-TWT member STAs to transmit bursty traffic

Abstract

A non-AP STA that is a scheduled STA with membership in an R-TWT scheduled STA queues an urgent burst of RTA traffic to the AP during an ongoing R-TWT SP, but in the ongoing R-TWT SP, the non-AP STA does not have R-TWT membership. This non-AP STA initiates an R-TWT negotiation with the scheduling AP within the ongoing R-TWT SP to request temporary or long-term membership in the current ongoing R-TWT SP, or requests to set up a new temporary or long-term R-TWT SP after the current SP but before the SP in which the non-AP STA originally had membership, or, if the UORA feature is enabled, allows contending for a RA-RU in the current R-TWT SP. Thus, the non-R-TWT member STA is granted access for its burst traffic transmission.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Patent Application No. 18 / 052,664, filed November 4, 2022, which is incorporated herein by reference in its entirety. This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 264,127, filed November 16, 2021, which is incorporated herein by reference in its entirety.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] Not applicable

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

[0004]

[0005] The techniques of this disclosure relate generally to wireless network communications under CSMA / CA, and more particularly to increasing real-time packet traffic when using R-TWT SP. [Background technology]

[0005]

[0007] Current wireless technologies using CSMA / CA focus on high-throughput network performance. However, an increasing number of applications, such as real-time applications (RTA), require low-latency communication. Data generated from RTA is called RTA traffic and is packetized as RTA frames at the transmitter STA. Data generated from non-time-sensitive applications is called non-RTA traffic and is packetized as non-RTA frames at the transmitter STA. The transmitter STA then transmits packets carrying the frames over a channel to the receiver STA.

[0006]

[0008] RTA frames require low latency communication due to their high timely delivery requirements: RTA frames are generally only valid if delivered within a certain period of time.

[0007]

[0009] One intended solution under CSMA / CA is to schedule Restricted Target Wake Time (R-TWT) Service Periods (SPs) for RTA frame exchange, as specified in 802.11be. R-TWT SPs allow higher priority to scheduled RTA frames, but non-scheduled RTA frames may suffer significant delays, even if the information being transmitted is very important. Summary of the Invention [Problem to be solved by the invention]

[0008]

[0010] Therefore, there is a need for improved processing of R-TWT SPs. The present disclosure overcomes that problem and provides additional benefits. [Means for solving the problem]

[0009]

[0011] A non-AP STA that is an R-TWT scheduled STA queues an urgent burst of RTA traffic to the AP during an ongoing R-TWT SP, in which the scheduled STA does not have an R-TWT membership. Under the present disclosure, the non-AP STA can either initiate R-TWT negotiation with the scheduling AP within the ongoing R-TWT SP to request temporary or long-term membership in the current ongoing R-TWT SP, or request to set up a new temporary or long-term R-TWT SP after the current SP but before the SP in which the non-AP STA originally had R-TWT membership, or, if the UORA feature is enabled, can contend for an RA-RU in the current R-TWT SP.

[0010]

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

[0011]

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

[0012] [Figure 1] FIG. 10 is a data field diagram of a TWT element. [Figure 2] FIG. 2 is a data field diagram of the control field of the TWT element of FIG. 1. [Figure 3] FIG. 10 is a data field diagram of a broadcast TWT parameter set. [Figure 4] FIG. 10 is a data field diagram of a request type field in a broadcast TWT parameter set field. [Figure 5] This is a data field diagram of the Broadcast TWT Information subfield in the TWT parameter set field. [Figure 6]FIG. 10 is a data field diagram of the Limited TWT Traffic Information field. [Figure 7] FIG. 10 is a data field diagram of the traffic information control field of the limited TWT traffic information field. [Figure 8] FIG. 10 is a data field diagram of the frame format of the TWT information field. [Figure 9] FIG. 1 is an interaction diagram of a TWT setup frame specified in IEEE 802.11ax. [Figure 10] FIG. 10 is a data field diagram of a TWT setup frame. [Figure 11] FIG. 1 is a communication diagram of an embodiment for implementing R-TWT SP. [Figure 12] FIG. 2 is a block diagram of communication station hardware in accordance with at least one embodiment of the present disclosure. [Figure 13] FIG. 1 is a block diagram of multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure. [Figure 14] FIG. 1 illustrates a network topology used in examples consistent with at least one embodiment of the present disclosure. [Figure 15] FIG. 1 is a communication diagram of a RA-RU process for a non-R-TWT member STA, in accordance with at least one embodiment of the present disclosure. [Figure 16] FIG. 1 is a communication diagram of a unicast RU access process in accordance with at least one embodiment of the present disclosure. [Figure 17] FIG. 10 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. [Figure 18] 1 is a flowchart of operations by an R-TWT scheduled STA in accordance with at least one embodiment of the present disclosure. [Figure 19] 1 is a flowchart of operations by an R-TWT scheduled STA in accordance with at least one embodiment of the present disclosure. [Figure 20]1 is a flowchart of operations by an R-TWT scheduled STA in accordance with at least one embodiment of the present disclosure. [Figure 21] 1 is a flowchart of operations by an R-TWT scheduled STA in accordance with at least one embodiment of the present disclosure. [Figure 22] 1 is a flowchart of an operation by an R-TWT scheduling AP in accordance with at least one embodiment of the present disclosure. [Figure 23] 1 is a flowchart of an operation by an R-TWT scheduling AP in accordance with at least one embodiment of the present disclosure. [Figure 24] 1 is a flowchart of an operation by an R-TWT scheduling AP in accordance with at least one embodiment of the present disclosure. [Figure 25] FIG. 10 is a data field diagram of a temporary member subfield within a request type field within a broadcast TWT parameter set field for an R-TWT in accordance with at least one embodiment of the present disclosure. [Figure 26] FIG. 10 is a data field diagram of an R-TWT information frame format including a temporary member subfield for R-TWT, in accordance with at least one embodiment of the present disclosure. [Figure 27] FIG. 10 is a communication diagram 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 present disclosure. [Figure 28] FIG. 10 is a communication diagram 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 present disclosure. [Figure 29] FIG. 10 is a communication diagram of a procedure for setting up 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 present disclosure. [Figure 30]FIG. 10 is a communication diagram of a procedure for setting up 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 present disclosure. [Figure 31] 1 is a communication diagram of a non-R-TWT member STA transmitting using a UORA in an R-TWT SP in which it does not have membership, in accordance with at least one embodiment of the present disclosure. [Figure 32] FIG. 10 is a communication diagram in which a non-R-TWT member STA transmits a BSR using an RA-RU in an R-TWT SP in which it does not have membership, in accordance with at least one embodiment of the present disclosure. [Figure 33] FIG. 10 is a communication diagram in which a non-R-TWT member STA transmits a BSR using an RA-RU in an R-TWT SP in which it does not have membership, in accordance with at least one embodiment of the present disclosure. [Figure 34] FIG. 10 is a communication diagram illustrating a non-R-TWT member STA initiating the use of a UORA during an R-TWT SP in which it does not have membership, in accordance with at least one embodiment of the present disclosure. [Figure 35] 1 is a communication diagram of a non-R-TWT member STA transmitting using unicast RU(s) in an R-TWT SP in which it does not initially have membership, in accordance with at least one embodiment of the present disclosure. [Figure 36] FIG. 1 illustrates a network topology for a simple topology of an MLO scenario consisting of three MLDs as utilized in an example in accordance with at least one embodiment of the present disclosure. [Figure 37] FIG. 10 is a communication diagram of an emergency R-TWT agreement setup over multiple links for an MLD STA that has no 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 OF THE INVENTION

[0013] 1. Overview of R-TWT operation

[0044] A non-access point (non-AP) Very High Throughput (EHT) STA establishes membership to one or more Reserved Target Wait Time (R-TWT) schedules that include the associated EHT AP through an association (or re-association) TWT setup frame exchange.

[0014]

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

[0015]

[0046] Non-AP EHT STAs that do not have membership in the R-TWT SP should still be able to spontaneously access the R-TWT SP, but may not have the same priority given to R-TWT SP member STAs, especially when transmissions are initiated / triggered by the R-TWT scheduling AP.

[0016]

[0047] Bursts of RTA traffic from an application can be generated at any time and require delivery as soon as possible. However, bursty RTA traffic may be subject to delays under the R-TWT schedule if a non-AP EHT STA does not have membership in the current R-TWT SP but still needs to deliver the bursty RTA traffic.

[0017] 1.1. IEEE 802.11 Elements 1.1.1.TWT element

[0050] FIG. 1 shows the format of the TWT element defined in IEEE 802.11be, and shows an element identification (ID) field, a length field, a control field, and TWT parameter information.

[0018]

[0051] Figure 2 shows the control field of the TWT element in Figure 1. The subfields of the control field are as follows: The NDP Paging Indicator, when set to a value of 1, indicates that NDP paging should be performed; otherwise, the NDP Paging field is set to 0. The Responder PM Mode subfield indicates the power management mode. The Negotiation Type subfield indicates whether the information contained in the TWT element is for Broadcast TWT (B-TWT), Individual TWT (I-TWT), or wake TBTT interval negotiation. Note that the MSB of the Negotiation Type subfield is B-TWT. The TWT Information Frame Disabled subfield, when set to 1, indicates that reception of TWT information frames has been disabled by the STA; otherwise, it is set to 0. The Wake Duration Units subfield indicates the units of the Nominal Minimum TWT Wake Duration field. The Wake Duration Units subfield is set to 0 if the unit is 265 μs, or 1 if the unit is TU. The Link ID Bitmap field is present if the Link ID Bitmap Present field is equal to 1, otherwise the Link ID Bitmap field is not present.

[0019]

[0052] Figure 3 shows the Broadcast TWT Parameter Sets field format. If the Broadcast field of the Negotiation Type subfield is equal to 2 or 3, the TWT element contains one or more Broadcast TWT Parameter Sets. Figure 4 shows the Request Type subfield of the Broadcast TWT Parameter Sets field. The Target Wake Time field contains an unsigned integer corresponding to the TSF time the STA requests to wake up. Note that if the Target Wake Time field is sent by a TWT requesting STA or a TWT scheduled STA and the TWT Setup Command subfield contains a value corresponding to the command "Request TWT", the Target Wake Time field contains the value 0.

[0020]

[0053] The Nominal Minimum TWT Wake Duration field indicates the minimum amount of time, in units indicated by the Wake Duration Units subfield, that a TWT requesting STA or a TWT scheduled STA is expected to be awake to complete a frame exchange over the duration 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. Figure 5 shows the Broadcast TWT Information subfield. The Limited TWT Traffic Information field is present when the Limited TWT Traffic Information Present subfield of the Request Type field is set to 1, and its format is defined in Figure 6.

[0021]

[0054] Figure 4 shows the Request Type field in the Broadcast TWT Parameter Sets field. A STA that sends a TWT element with a TWT Request subfield equal to 1 is a TWT requesting STA or a TWT scheduled STA. Otherwise, the STA is a TWT responding STA or a TWT scheduling AP.

[0022]

[0055] The TWT Setup command subfield value indicates the type of TWT. For example, the TWT Setup command field values ​​are: 0 = "Request TWT", 1 = "Suggest TWT", 2 = "Demand TWT", 3 = "TWT Grouping", 4 = "Accept TWT", 5 = "Alternate TWT", 6 = "Dictate TWT", and 7 = "Reject TWT".

[0023]

[0056] "Request TWT" means that the requesting STA does not provide a set of TWT parameters for the TWT agreement, leaving the selection of parameters to the responding STA. "Propose TWT" indicates that the requesting STA provides a set of preferred TWT parameters for the TWT agreement, but is also willing to accept alternative TWT parameters indicated by the responding STA. "Request TWT" indicates that the requesting STA currently accepts only the TWT parameters indicated for the TWT agreement.

[0024]

[0057] The value "Accept TWT", when sent by the responding STA, indicates that the responding STA has initiated a TWT agreement with the given parameters. The value "Alternate TWT" indicates an alternative TWT parameter proposal, but the alternative TWT parameters may also be accepted without creating a TWT agreement. The value "Commanded TWT" indicates that no TWT agreement has been made, but that a TWT agreement would likely be accepted only if the requesting STA sends a new TWT setup request containing the indicated TWT parameters. The value "Rejected TWT", sent by the responding STA as part of the negotiation for a new TWT agreement, is used to indicate that the negotiation has ended and that a new TWT agreement has not been created.

[0025]

[0058] The Trigger field indicates whether the TWT SP indicated by the TWT element contains a trigger frame. When Trigger Frame is set to 1, it indicates that at least one trigger frame is transmitted during the TWT SP. Otherwise, Trigger Frame is set to 0.

[0026]

[0059] The Last Broadcast Parameter Set subfield, when set to 0, indicates that another Broadcast TWT parameter set follows this set. The Last Broadcast Parameter Set subfield, when set to 1, indicates that this is the last Broadcast TWT parameter set in the Broadcast TWT element.

[0027]

[0060] The flow type subfield indicates the type of interaction between the TWT requester STA or TWT scheduled STA and the TWT responder STA or TWT scheduling AP in the TWT. Setting the flow type subfield to 0 indicates announced TWT. In announced TWT, the TWT requester STA or TWT scheduled STA sends a PS-Poll or APSD trigger frame to signal its awake state to the TWT responder STA or TWT scheduling AP. After that, a frame that is not a trigger frame is sent from the TWT responder STA or TWT scheduling AP to the TWT requester STA or TWT scheduled STA. Setting the flow type subfield to 1 indicates unannounced TWT. In non-announced TWT, the TWT responding STA or TWT scheduling AP transmits a frame to the TWT requesting STA or TWT scheduled STA in the TWT without waiting to receive a PS poll or APSD trigger frame from the TWT requesting STA or TWT scheduled STA.

[0028]

[0061] A TWT SP set up under an announced TWT agreement is an announced TWT SP. A TWT SP set up under an unannounced TWT agreement is an unannounced TWT SP.

[0029]

[0062] The Broadcast TWT Recommendation subfield indicates a recommendation regarding the type of frames transmitted by the TWT-scheduled STAs and the scheduling AP during a Broadcast TWT SP and includes the following values: A value of 0 indicates that there are no restrictions on the frames transmitted during a Broadcast TWT SP; A value of 1 indicates that a trigger frame is transmitted by the TWT scheduling AP during a Broadcast TWT SP and does not include RUs for random access and Orthogonal Frequency Division Multiple Access (OFDMA)-based Random Access (UORA); A value of 2 indicates that the number of trigger frames transmitted by the TWT scheduling AP during a Broadcast TWT SP includes at least one resource unit (RU) for random access and uplink OFDMA Random Access (UORA); A value of 3 indicates that there are no restrictions on the frames transmitted during a Broadcast TWT SP, except that the AP transmits a Traffic Indication Map (TIM) frame or a Fast Initial Link Setup (FILS) discovery frame containing a TIM element at the beginning of each TWT SP; and A value of 4 indicates that the corresponding Broadcast TWT service period is a Limited TWT SP. Values ​​5 through 7 are reserved.

[0030]

[0063] The TWT Wake Interval Exponent subfield is set to the value of the TWT Wake Interval Exponent, which is a binary value representing microseconds.

[0031]

[0064] 5 shows the Broadcast TWT Information subfield within the TWT Parameter Sets field, with the following subfields: The Limited TWT Traffic Information Present subfield, when included in the Limited TWT Parameter Sets field, indicates the presence of a Limited TWT Traffic Information field when set to 1, and is set to 0 otherwise.

[0032]

[0065] In a TWT element containing a TWT setup command value for a Request TWT, Proposed TWT, or Requested TWT, the Broadcast TWT ID (if present) indicates the specific broadcast TWT that the sending STA is requesting to join. In a TWT element containing a TWT setup command value for an Accept TWT, Alternate TWT, Command TWT, or Reject TWT, the Broadcast TWT ID (if present) indicates the specific broadcast TWT for which the sending STA is providing TWT parameters. In a TWT element containing a TWT setup command value for a TWT grouping, the Broadcast subfield is 0 and the Broadcast TWT ID is not present. 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.

[0033]

[0066] Note that the Broadcast TWT ID subfield in the R-TWT parameter set field is always set to a non-zero value. The Broadcast TWT Duration subfield indicates the number of TBTTs for which there are Broadcast TWT SPs corresponding to this Broadcast TWT parameter set.

[0034]

[0067] Figure 6 shows the Limited TWT Traffic Information field with the following subfields: The Traffic Information Control subfield is described in Figure 7. The Limited TWT DL TID Bitmap and Limited TWT UL TID Bitmap subfields specify which TID(s) are identified as latency-sensitive traffic streams in the downlink and uplink directions by the TWT scheduling AP or the TWT scheduled STAs, respectively. If the value in bit position k in the bitmap is set to 1, this indicates that TID k has been classified as a latency-sensitive traffic stream. If the value in bit position k in the bitmap is set to 0, this indicates that TID k is not classified as a latency-sensitive traffic stream.

[0035]

[0068] Figure 7 shows the Traffic Information Control field for the Limited TWT Traffic Information field, with the following subfields: The DL TID Bitmap Valid subfield indicates whether the Limited TWT DL TID Bitmap field has valid information. When set to a value of 0, this indicates that DL traffic for all TIDs has been identified as latency sensitive traffic, and the Limited TWT DL Bitmap field is reserved.

[0036]

[0069] The UL TID Bitmap Valid subfield indicates whether the Qualified TWT UL TID Bitmap field has valid information. When set to 0, it indicates that UL traffic for all TIDs has been identified as latency sensitive traffic, and the Qualified TWT UL Bitmap field is reserved.

[0037] TWT Information Field

[0071] Figure 8 shows the frame format of the TWT Information field, which has the following subfields: The TWT Flow Identifier subfield contains the TWT flow identifier for which TWT information is requested or being provided.

[0038]

[0072] The TWT Flow Identifier subfield is reserved if the All TWT subfield is 1. The Response Requested subfield indicates whether the transmitter of the frame containing the TWT Information field requests that a TWT Information frame be sent in response to this frame. If the Response Requested subfield is set to 0, it requests the receiver not to send a TWT Information frame in response to the frame; otherwise, it requests the receiver to send a TWT Information frame in response to the frame.

[0039]

[0073] The Next TWT Request subfield, when set to 1, indicates that the TWT Information frame is a request for delivery of a TWT Information frame containing a non-zero-length Next TWT field; otherwise, the value is set to 0.

[0040]

[0074] 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 that the size is 32 bits, a value of 2 indicates that the size is 48 bits, and a value of 3 indicates that the size is 64 bits.

[0041]

[0075] The All TWT subfield, when set to 1 by the HE STA, indicates that the TWT information frame reschedules all TWTs; otherwise, the value is set to 0.

[0042]

[0076] The Next TWT subfield has a variable size as determined by the value of the Next TWT subfield. The value contained in the Next TWT subfield is the least significant portion of the TSF in the Next TWT for the TWT specified by the TWT Flow Identifier subfield.

[0043] 1.2.R-TWT Signaling

[0078] An example of a TWT setup as specified in IEEE 802.11ax is shown in Figure 9. The STA interaction model can be the same as that specified in the IEEE 802.11 standard.

[0044]

[0079] A non-AP STA decides to initiate a TWT setup procedure with the AP. The station management entity (SME) of the non-AP STA sends an MLME-TWTSETUP.request message to the medium access control (MAC) sublayer management entity (MLME) of the non-AP STA. Upon receiving the MLME-TWTSETUP.request message, the MLME of the non-AP STA collects the information in the MLME-TWTSETUP.request message and sends a TWT setup frame (i.e., a TWT request frame) to the AP. The MLME of the AP receives the frame and generates an MLME-TWTSETUP.indication message to the SME of the AP.

[0045]

[0080] Next, the SME of the AP sends an MLME-TWTSETUP.response message containing the TWT setup result to the MLME of the AP. Next, the MLME of the AP sends a TWT setup frame (i.e., a 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 the SME of the non-AP STA. From that message, the non-AP STA can know whether the TWT setup was successful or not.

[0046]

[0081] The format of the TWT Setup frame is shown in Figure 10. The TWT elements within that frame are those shown in Figure 1. As specified 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 to 1 in the transmitted EHT Capabilities element.

[0047]

[0082] 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 Capabilities element to a value of 1.

[0048]

[0083] An R-TWT-scheduled STA can establish membership in one or more R-TWTs scheduled by the R-TWT scheduling AP. The R-TWT setup signaling is the same as broadcast TWT, with additional parameter settings used for R-TWT membership negotiation between the R-TWT-scheduled STA and the R-TWT scheduling AP. After establishing membership in an 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 R-TWT SP. 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 scheduling AP during the R-TWT SP.

[0049]

[0084] FIG. 11 shows an example of executing an R-TWT SP. AP1 is an R-TWT scheduling AP that announces R-TWT1 scheduling and manages R-TWT1 members. STA1 and STA2 are R-TWT1 member STAs. During the R-TWT1 SP, AP1 schedules and prioritizes frame exchanges with member STAs (e.g., UL PPDUs of SCS1 with STA1 and DL PPDUs of SCS2 with STA2). A STA that can receive (listen) and recognize (understand) the R-TWT scheduling is called an R-TWT scheduled STA. STA3 is an R-TWT scheduled STA but is not a member STA of the R-TWT1. STA3 must end its TXOP before the start time of the R-TWT1 SP. STA3 can enter quiet mode or decide not to contend for the channel during the R-TWT1 SP. The scheduling AP can broadcast a quiet element to announce the quiet interval during the R-TWT SP, and STAs that receive (listen to) this element can choose to enter quiet mode.

[0050] 1.3.UL OFDMA-based Random Access (UORA)

[0086] UORA is an IEEE 802.11ax feature for non-AP HE STAs to access the channel using RA-RUs assigned by the associated HE AP. The HE AP can transmit a basic trigger frame, a BQRP trigger frame, or a BSRP trigger frame containing one or more RUs for random access. The AP should initiate random access following receipt of the trigger frame transmitted by the AP, indicating the range of the OFDMA contention window (OCW) for the non-AP STAs.

[0051]

[0087] The OCW, which is an integer within the range of OCWmin to OCWmax, is set in a UORA parameter set element included in a management frame such as a beacon frame, a probe response frame, or a (re)association response frame.

[0052]

[0088] Each time a non-AP HE STA associates with a different AP and before its first attempt at RA-RU transmission towards that AP, the non-AP HE STA should set the value of OCW to the OCWmin value and initialize its OFDMA Random Access Backoff (OBO) counter within the range of 0 to OCW. The (OBO) counter is used by the non-AP HE STA to count down before accessing the RA-RU.

[0053]

[0089] When an HE STA with a pending frame to the AP receives a trigger frame containing at least one eligible RA-RU, it may randomly select one of the eligible RA-RUs for transmission and should set its OBO counter to zero if the OBO counter is less than or equal to the number of eligible RA-RUs. Otherwise, the HE STA decrements its OBO counter by the number of eligible RA-RUs in the trigger frame. Note that 802.11BE currently does not support UORA in R-TWT.

[0054] 2. Problem statement

[0091] In current wireless communication systems that use enhanced distributed channel access (EDCA) and R-TWT to prioritize RTA traffic transmission during an R-TWT SP, RTA traffic is prioritized for transmission. However, while the duration of an R-TWT SP is scheduled for R-TWT member STAs, non-AP STAs that are not members of a particular R-TWT SP generally have restricted channel access to the R-TWT SP. One reason for this access restriction is that the R-TWT scheduling AP does not know whether non-R-TWT members are asleep or awake and therefore does not spontaneously trigger non-R-TWT members. STAs can still compete for R-TWT SPs in which they do not have membership, but they may have fewer opportunities to obtain a TXOP than the scheduling AP because the AP may have a faster arbitration inter-frame spacing (AIFS) (its AIFS number (AIFSN) is greater than or equal to 1) than non-AP STAs (its AIFSN [AC] is greater than or equal to 2). In this situation, bursts of RTA packets may be queued at STAs that are not members of the ongoing R-TWT SP and may therefore be delayed until their own scheduled R-TWT SP arrives.

[0055]

[0092] Therefore, a mechanism is needed to set up temporary or long-term R-TWT membership for STAs that were not originally members of the current R-TWT SP, but that have bursts of RTA traffic to transmit in the current ongoing R-TWT SP.

[0056] 3. Contributions of this Disclosure

[0094] By utilizing this disclosure, a STA that has queued burst RTA traffic but does not have membership in the current ongoing R-TWT SP can immediately negotiate with the scheduling AP within the current R-TWT SP to set up temporary or long-term membership to use this R-TWT SP, or set up a new R-TWT SP following the current R-TWT SP to transmit RTA traffic with equal priority as given to the R-TWT member.

[0057] 4. Embodiment 4.1. Communication Station (STA and MLD) Hardware

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

[0058]

[0098] The bus 14 allows for connecting various devices to the CPU, e.g., sensors, actuators, etc. Executing on the processor 18 are instructions from the memory 20 for executing programs that implement a communication protocol, which enables the STA to perform the functions of an Access Point (AP) station or a regular station (non-AP STA). It should also be understood that the programming is configured to operate in different modes (TXOP holder, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, AP in OBSS, STA in OBSS, etc.) depending on what role it is performing in the current communication context.

[0059]

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

[0060]

[0100] Furthermore, it should be noted that multiple instances of station hardware such as that shown in this figure can be combined into a multi-link device (MLD), which typically has a processor and memory for coordinating activity, but it should be understood that separate CPUs and memory are not always required for each STA within the MLD, and these resources can be shared.

[0061]

[0101] FIG. 13 shows an example embodiment 40 of a multi-link device (MLD) hardware configuration. A soft AP MLD is an MLD consisting of one or more associated STAs operating as APs. The soft AP MLD should support multi-radio operation at 2.4 GHz, 5 GHz, and 6 GHz. Among the multi-radio, a basic link set is a link pair that satisfies simultaneous transmit / receive (STR) mode, such as a basic link set (2.4 GHz and 5 GHz) or a basic link set (2.4 GHz and 6 GHz).

[0062]

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

[0063]

[0103] Multiple STAs are associated with the MLD, each operating on a different frequency link. The MLD has external I / O access to applications, which connect to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to run programs that implement communication protocols at the MLD level. The MLD distributes tasks to each associated station (shown here as STA 1 42, STA 2 44, ..., STA N 46) to which the MLD is connected, collects information from each associated station, and can share information among the associated STAs.

[0064]

[0104] In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54, which in turn is connected to at least one RF circuit 56, which in turn has one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c, ..., 60n, e.g., an antenna array. The modem cooperates with the RF circuit and associated antennas to transmit / receive data frames to / from neighboring STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

[0065]

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

[0066] 4.2.STA Topology Example

[0107] 14 illustrates an exemplary STA topology 70 considered in embodiments of the present disclosure. This diagram is provided to aid in explaining the techniques involved to improve understanding of the proposed technology. It should be understood that the present disclosure is in no way limited to this example topology, as the protocol can be utilized for communication between WLAN STAs and MLDs in any desired topology.

[0067]

[0108] A multi-link device (MLD) is a device that has more than one associated STA and has one Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC) that contains one MAC data service.

[0068]

[0109] If an AP is associated with an MLD, the MLD is an AP MLD. If a non-AP STA is associated with an MLD, the MLD is a non-AP MLD.

[0069]

[0110] 14, the example scenario has a total of three stations, as shown, one access point (AP) 72 and two non-AP STAs, STA1 74 and STA2 76, that communicate with the AP. All STAs use EDCA for random channel access.

[0070]

[0111] An R-TWT scheduling AP can schedule and announce R-TWT SPs. An R-TWT-scheduled STA is a non-AP STA that can receive and recognize R-TWT announcements from the R-TWT scheduling AP and support R-TWT operation. An R-TWT-scheduled STA can negotiate R-TWT membership with an AP acting as the R-TWT scheduling AP. When an R-TWT-scheduled STA becomes an R-TWT member STA, the traffic (e.g., UL, DL, P2P) of the R-TWT-scheduled STA (i.e., the R-TWT member STA) is scheduled and prioritized for transmission during the R-TWT SP.

[0071]

[0112] In this exemplary diagram, the AP is an R-TWT scheduling AP, and both STA1 and STA2 are R-TWT scheduled STAs.

[0072] 4.3 Urgent R-TWT Membership Request at Current R-TWT SP

[0114] This section describes a mechanism by which an R-TWT scheduled non-AP STA (STA), which has at least one R-TWT membership in a different R-TWT SP(s) than its current ongoing R-TWT SP, can immediately initiate R-TWT negotiation with the scheduling AP if it has an emergency burst UL flow to transmit, instead of waiting for the STA's scheduled R-TWT SP. The non-R-TWT member STA can request to be accepted (temporarily or longer term) as a new member of the current R-TWT SP, so that once the STA receives agreement from the scheduling AP, it can deliver its emergency burst UL flow with the same priority as the original R-TWT member in the current R-TWT SP.

[0073]

[0115] R-TWT negotiation between a non-R-TWT member STA and a scheduling AP is based on the exchange of frames, such as TWT Request and TWT Response frames, carrying a TWT element including a Negotiation Type subfield indicating this type of action (e.g., equal to "3" in the present embodiment).

[0074]

[0116] The Reserved subfield of the Request Type field in the Broadcast TWT Parameter Set field can be used by non-AP STAs to request membership (temporary or long-term) in the current R-TWT SP using the newly defined "Temporary Member" subfield as shown in Figure 25. The Reserved subfield can also be used by the scheduling AP to indicate acceptance of membership or to assign the requesting STA a new R-TWT membership in the current R-TWT.

[0075]

[0117] In at least one embodiment, this field provides multiple options, in this example two options, to indicate whether temporary or long-term membership is requested by a scheduled non-AP STA or assigned by the scheduling AP.

[0076]

[0118] Scheduled non-AP STAs that are assigned temporary membership in a current R-TWT SP are only providing a one-time use consent for an R-TWT member to become a member of the current ongoing R-TWT SP.

[0077]

[0119] A scheduling AP that agrees to assign a long-term membership to a requesting non-AP STA to use a particular R-TWT SP should maintain membership for the requesting scheduled non-AP STA to use this R-TWT SP (e.g., identified by a broadcast TWT ID) until this non-AP STA performs a revocation of the R-TWT agreement.

[0078]

[0120] The scheduling AP can accept or reject requests from STAs requesting to become new members of the current R-TWT SP, or can suggest alternative R-TWT setups or dictate preferred R-TWT setups from the STAs.

[0079] 4.4. Emergency New R-TWT SP Setup During Current R-TWT SP

[0122] This section describes a mechanism by which a STA that has an emergency burst UL flow but did not initially obtain R-TWT membership in the current R-TWT SP attempts to set up a scheduling AP and another (temporary or long-term) R-TWT SP during this current R-TWT SP. The other (temporary or long-term) R-TWT SP can immediately follow the current R-TWT SP and should be set up as soon as possible before the time of the requesting STA's originally scheduled R-TWT SP(s) arrives.

[0080]

[0123] Note that a new (temporary or long-term) R-TWT SP for a requesting STA can overlap in the time domain with an existing R-TWT SP for which the requesting STA does not have R-TWT membership. In this case, the requesting STA should still have high access priority because it is a member of the new R-TWT SP.

[0081]

[0124] A new R-TWT SP can be set up by sending new proposed R-TWT information to the scheduling AP.

[0082]

[0125] When a scheduling AP receives an R-TWT information frame from a non-AP STA, it 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.

[0083]

[0126] The new R-TWT information frame is designed based on the TWT information field and maintains the flexible TWT function as specified in IEEE 802.11ax_D8.0. Furthermore, the proposed R-TWT information frame includes a Limited TWT Traffic Information field, as described in Figure 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 is shown in Figure 26.

[0084]

[0127] Once the non-AP STA that initiated the R-TWT information frame exchange receives agreement from the scheduling AP, it can transmit the bursty UL flow using the new temporary or long-term R-TWT SP.

[0085] 4.5. Urgent Non-R-TWT Member STA Transmission Using UORA

[0129] Currently, IEEE 802.11be supports UORA in B-TWT by setting the Broadcast TWT Recommendations subfield for the B-TWT element to a value of 2. A Broadcast TWT parameter set with a Broadcast TWT Recommendations field equal to a value of 4 indicates an R-TWT parameter set, and there is currently no restriction or requirement to use UORA for R-TWT.

[0086]

[0130] This section defines a new value for the Broadcast TWT Recommendation field to indicate that the trigger frame sent by the R-TWT scheduling AP during the R-TWT SP contains at least one RU for random access, in which case the RA-RU can be used by both non-R-TWT member STAs and R-TWT member STAs.

[0087]

[0131] A new value of the Broadcast TWT Recommendation field, for example, "5," can be set up to indicate that the UORA feature is enabled in the R-TWT SP. The new feature can be initially enabled at the beginning of each R-TWT SP. Alternatively, this feature can be initiated by a STA that has not yet obtained R-TWT membership in this R-TWT SP by exchanging negotiation frames (e.g., R-TWT Request and R-TWT Response) with the scheduling AP during a current ongoing R-TWT SP.

[0088]

[0132] When the UORA function is enabled in the current ongoing R-TWT SP, non-R-TWT member STAs that have a burst of RTA packets to transmit can use the RA-RU in the current R-TWT SP based on the UORA transmission procedure as specified in the standard.

[0089]

[0133] Both R-TWT member STAs and non-R-TWT member STAs can compete for RA-RUs to transmit. When the OFDMA backoff (OBO) counter counts down to zero, the non-R-TWT member STAs can use one random access resource unit (RA-RU) to directly transmit an uplink (UL) physical layer convergence procedure protocol data unit (PPDU), or can send a buffer status report (BSR) in the RA-RU to allow the scheduling AP to allocate a specific RU to the non-R-TWT member STA for direct access in the next triggered UL PPDU transmission.

[0090]

[0134] 15 illustrates an example embodiment 90 of the RA-RU process for a non-R-TWT member STA (e.g., STA2) and R-TWT member STAs (e.g., STA1, STA3, and STA4) when UORA is enabled in the R-TWT SP. The illustrated RUs span a portion of the frequency spectrum. The figure shows the AID values ​​(92) of STA1-STA4, each of which had an initial OBO value before the trigger frame was transmitted by the scheduling AP.

[0091]

[0135] Upon receiving a trigger frame (94) from the scheduling AP, the following assignments (96) occur: STA1 and STA3 are both members of this R-TWT SP and have pending frames for the scheduling AP. STA1 is assigned dedicated RUs (RU1 and RU2) and STA3 is assigned dedicated RUs (RU3 and RU4). STA1 and STA3 do not contend for the RA-RU, but instead transmit their pending frames on their assigned RUs.

[0092]

[0136] STA4 is a member of this R-TWT SP and has a pending frame for the scheduling AP. STA4 does not receive an assigned RU from the trigger frame and therefore contends for an 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 STA4's OBO counter has been decremented to a non-zero value, STA4 maintains the new OBO value until it receives a subsequent trigger frame from the scheduling AP carrying an RA-RU.

[0093]

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

[0094]

[0138] Receipt of these transmitted PPDUs at the RU is acknowledged (98) in this case by a Multi-User Block Acknowledgement (MU BA).

[0095] 4.6. Urgent Non-R-TWT Member STA Transmission Using Guaranteed Unicast RU(s)

[0140] A STA that does not have membership in the current ongoing R-TWT SP can request to become a temporary member of the current R-TWT SP and request unicast RU(s) for delivering its bursty RTA traffic in the current ongoing R-TWT SP. If the R-TWT scheduling AP accepts the STA's request, it can guarantee the unicast RU(s) to the STA.

[0096]

[0141] This section describes the setup to guarantee unicast RU(s) by defining a new value for the Broadcast TWT Recommendation subfield. The guaranteed unicast RU(s) are assigned by the scheduling AP to a specific AID and used by new temporary R-TWT member STAs to send burst traffic to the AP.

[0097]

[0142] A new value of the Broadcast TWT Recommendation field, e.g., "6," can be used to enable the unicast RU feature in R-TWT. The new feature cannot be scheduled at the start of any R-TWT SP because the scheduling AP does not have information (knowledge) about which non-member STAs request to become members of this R-TWT SP, and therefore the scheduling AP cannot configure unicast RU(s) for a specific AID.

[0098]

[0143] A new unicast RU(s) in this R-TWT function can be initiated by a non-R-TWT member STA during a current ongoing R-TWT SP by exchanging negotiation frames (e.g., R-TWT Request and R-TWT Response) with the scheduling AP.

[0099]

[0144] FIG. 16 illustrates an example embodiment 110 of a unicast RU access process, showing the station AIDs (112) of the temporary new R-TWT member STA (e.g., STA2) and R-TWT member STAs (e.g., STA1 and STA3) when guaranteed unicast RU(s) are enabled in the R-TWT SP.

[0100]

[0145] STA2 was a member of this triggered R-TWT SP but has a pending RTA burst to send to the scheduling AP. STA2 can request unicast RU(s) during this R-TWT SP by sending a TWT request frame to the scheduling AP, requesting or proposing to add STA2 as a new temporary member. The scheduling AP can accept the requested or proposed TWT setup command from STA2, propose / command an alternative, or reject it.

[0101]

[0146] Assuming that the scheduling AP accepts the new TWT setup command from STA2, the AP responds with a TWT response frame, setting the TWT setup command field to "Accept TWT" and the Broadcast TWT recommendation field to a new designed value (e.g., 6) to enable the unicast RU feature in the current R-TWT SP.

[0102]

[0147] After STA2 receives a TWT response frame from the scheduling AP containing an indication that the new TWT setup command has been accepted, STA2 becomes the new temporary member of the requested R-TWT SP.

[0103]

[0148] Upon receiving the trigger frame (114) from the scheduling AP, STA1 and STA3 are both original members of this triggered R-TWT SP and have pending frames for the scheduling AP. STA1 is assigned dedicated RUs (RU1 and RU2), and STA3 is assigned dedicated RUs (RU3, RU4, and RU5). STA1 and STA3 should transmit their pending frames using their assigned RUs.

[0104]

[0149] The scheduling AP allocates RU6 to STA2 in a later trigger frame (as indicated by AID 8). The new R-TWT member STA2 receives the trigger frame indicating that unicast RU6 has been allocated to STA2 and can immediately access RU6 to transmit an UL PPDU.

[0105]

[0150] Receipt of these transmitted PPDUs at the RU is acknowledged by the MU BA (118).

[0106] 4.7. RA-RU Group AID Allocation for Non-R-TWT Member STAs

[0152] This section describes a mechanism for assigning RA-RU(s) to a new group AID to be used for non-AP STAs that do not have membership in the current ongoing R-TWT SP but are capable of buffering UL RTA traffic.

[0107]

[0153] A new group AID allocating RA-RU(s) to non-R-TWT members should be included by the beacon frame body indicating when R-TWT applies, and the new group AID is exclusively allocated to the RA-RU(s) for non-R-TWT member STAs to provide access during any R-TWT SP.

[0108]

[0154] In at least one embodiment / mode / option, the new group AID value may be one of the reserved values ​​of the AID12 subfield of the User Information field of the trigger frame, based on the values ​​found in Table 1 (including material from Table 9-29h of the 802.11ax specification).

[0109]

[0155] A new Group AID value, e.g., 2050, indicates that the User Information field has assigned one or more consecutive RA-RUs to associated non-R-TWT member STAs in any R-TWT SP. Note that pre-EHT devices are unaware of the new Group AID and therefore cannot contend for access to the RA-RU(s) assigned to the new Group AID. A new value in the Broadcast TWT Recommendation field, e.g., "7," can be used to validate the RA-RU(s) assigned to the new Group AID for non-R-TWT members in the R-TWT SP.

[0110]

[0156] 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., STA2). Status 132 shows STA1-STA4 and their associated AIDs. The R-TWT member STAs (e.g., STA1, STA3, and STA4) cannot contend for access using RA-RU 6 because RU 6 has been assigned to the STA(s) with group AID 2050.

[0111]

[0157] The trigger frame (134) contains an allocation from the scheduling AP. STA1 and STA3 are both members of this R-TWT SP and have pending frames for the scheduling AP. STA1 is assigned dedicated RUs (RU1 and RU2), and STA3 is assigned dedicated RUs (RU3 and RU4). Therefore, STA1 and STA3 do not need to contend for the RA-RU, but instead transmit their pending frames on their assigned RUs.

[0112]

[0158] STA4 is a member of this R-TWT SP and has a pending frame for the scheduling AP. However, STA4 has no RUs assigned to it in the trigger frame, so it contends for an RA-RU. STA4 decrements its OBO counter by the number of eligible RA-RUs indicated in the trigger frame (i.e., two RA-RUs for the associated STA in this case). Assuming that STA4's OBO counter has been decremented to a non-zero value, STA4 maintains the new OBO value until it receives a subsequent trigger frame from the scheduling AP carrying an RA-RU.

[0113]

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

[0114]

[0160] Thus, RU1-RU4 and RU6 transmit TB PPDUs (136) as shown, and in response receive MU BAs (138).

[0115] 4.8. Emergency R-TWT Membership Setup for Non-R-TWT Member STAs in MLO

[0162] An MLD STA that does not have R-TWT membership in a current ongoing R-TWT SP(s) on multiple links should be able to set up proposed R-TWT agreement(s) for multiple links through negotiation on any available link. Note that ML R-TWT SP setup through negotiation frame exchange on one link has been proposed in Applicant's previous application.

[0116]

[0163] On different links, different proposed R-TWT agreements (Sections 4.3-4.6) can be set up, e.g., an R-TWT-X SP on L2 including UORA functionality (as proposed in Section 4.5) and an R-TWT-Z SP on L3 including unicast functionality (as proposed in Section 4.6).

[0117]

[0164] Upon receiving a TWT Request frame, the scheduling AP should respond with a TWT Response frame announcing acceptance of the new R-TWT agreement on any requested operational link(s).

[0118] 4.9. Protocol Flow Diagram

[0166] 18-21 illustrate an example embodiment 150 of operation by an R-TWT scheduled STA.

[0119]

[0167] In block 152, the STA gets a burst of traffic from its application layer, which is queued in the STA's EDCA queue. A check 154 determines whether the station has membership in an R-TWT SP on the transmit link. If the station does not have membership, in block 156, the STA simply waits for a trigger from the scheduling AP before it can transmit.

[0120]

[0168] If in block 154 it is determined that the STA does not have membership, then in block 158 the STA determines whether to send a negotiation frame to request (or propose) to be added as a member of the current R-TWT on the transmit link.

[0121]

[0169] If the STA decides to request membership, a check is performed in block 160 of FIG. 19 to determine whether the STA has received a negotiation frame from the scheduling AP to accept adding the STA as a member of the current R-TWT on the transmit link.

[0122]

[0170] If, at block 160, it is determined that the STA has been added to the R-TWT on the transmit link, execution proceeds to block 156 of FIG. 18, where the STA waits for a trigger from the scheduling AP.

[0123]

[0171] On the other hand, if it is determined in block 160 that the STA has not been added as a member for the transmission link, then in block 162 the STA may still contend for the channel as a non-R-TWT member.

[0124]

[0172] If the STA did not request membership in check 158 of FIG. 18, then a check is made in block 164 of FIG. 20 to determine whether RA-RU(s) are enabled for all STAs (164).

[0125]

[0173] If the RA-RU is enabled for all STAs, then non-R-TWT STAs may contend for the RA-RU to be assigned to their associated STAs in block 166. On the other hand, if the RA-RU is not enabled for all stations, then a check is made in block 168 to determine whether the RA-RU is enabled for only non-R-TWT STAs.

[0126]

[0174] If the RA-RU is enabled for non-R-TWT STAs only, the STAs may contend for the RA-RU that is allocated to non-R-TWT STAs only in block 170. Otherwise, execution proceeds to check 172 of FIG.

[0127]

[0175] If RU(s) are guaranteed for the non-R-TWT STA at check 172, the STA transmits on the guaranteed RU(s) at block 174. Otherwise, execution proceeds to block 176, which checks whether the STA has set up a new R-TWT SP after the current R-TWT SP but before the STA's own R-TWT SP. If no R-TWT is set up, the process ends.

[0128]

[0176] Otherwise, in block 178, a check is made to determine whether the STA has received a frame from the scheduling AP to accept the new setup of a new R-TWT. If the STA has not received a frame, execution proceeds to block 162 of Figure 19 (already described). If the STA has received a frame, in block 180, the STA can either contend for the channel or wait for a trigger from the scheduling AP on the new R-TWT SP.

[0129]

[0177] 22-24 illustrate an example embodiment 190 of operation by an R-TWT scheduling AP. In block 192, a check is made to determine whether the AP has received a negotiation frame to request (propose) to be added as a temporary or long-term member of a current R-TWT, or to set up a new temporary or long-term R-TWT on the transmit link.

[0130]

[0178] If the condition of check 192 is not met, execution proceeds to block 198 of FIG. 23, where the AP does not spontaneously (automatically) trigger non-R-TWT member STAs and ends the process.

[0131]

[0179] On the other hand, if check 192 is satisfied, the AP responds to the requesting STA indicating acceptance or rejection of the request in block 194. Next, check 196 determines whether the AP accepted the requesting STA as a member of the requested R-TWT on the specified transmit link. If the AP did not accept, execution proceeds to block 198 of Figure 23 (already described).

[0132]

[0180] If not, execution proceeds to block 200 of Figure 23, where the AP can trigger the non-R-TWT member station as an R-TWT member. Next, in check 202, it is determined whether the RA-RU(s) are enabled for all associated STA transmissions. If the condition is met, in block 204, the AP indicates at least one RA-RU for the STA in the trigger and ends the process.

[0133]

[0181] On the other hand, if the condition of check 202 is not met, check 206 of Figure 24 determines whether the RA-RU(s) are enabled for non-R-TWT STA transmissions only. If the condition is met, then in block 208 the AP indicates in the trigger at least one RA-RU assigned to a particular group AID for non-R-TWT member STAs only and ends the process.

[0134]

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

[0135] 4.10. New Fields and Frames

[0184] 25 illustrates an example embodiment 230 of a Temporary Member subfield in the Request Type field in the Broadcast TWT Parameter Sets field for R-TWT. The new subfield in the Request Type field of the Broadcast TWT Parameter Sets field can be used by non-AP STAs to request to be added as new members of a current R-TWT SP. The new subfield can also be used by a scheduling AP to indicate that the request is accepted or that the requesting STA should be assigned a new R-TWT membership in the current R-TWT.

[0136]

[0185] This new field is present in the TWT element carried by negotiation frames (e.g., TWT Request and TWT Response) exchanged between the scheduling AP and a scheduled non-AP STA that has requested to become a temporary or long-term member of the R-TWT SP.

[0137]

[0186] This new proposed field (i.e., Temporary Member) has two stages and can indicate temporary membership (e.g., Stage 0) or long-term membership (e.g., Stage 1) as requested by the scheduled STA or assigned by the scheduling AP.

[0138]

[0187] A scheduled STA that is assigned temporary membership in the current R-TWT SP is given a one-time R-TWT membership in the current R-TWT SP in which the STA should have the same priority as an original member of the current R-TWT SP.

[0139]

[0188] A scheduling AP that agrees to assign long-term membership to a requesting scheduled STA to use a particular R-TWT SP should maintain membership for the requesting scheduled non-AP STA to use this R-TWT SP (e.g., identified by a broadcast TWT ID) until this non-AP STA rescinds the R-TWT agreement.

[0140]

[0189] All other subfields in the Request Type field in the Broadcast TWT Parameter Set field are the same as those described in FIG.

[0141]

[0190] Figure 26 shows an example embodiment 250 of an R-TWT information frame format including a temporary member subfield for R-TWT. A STA that has an urgent burst upload (UL) flow to transmit but is not a member of the current R-TWT SP can initiate an R-TWT information frame exchange with the scheduling AP. A non-R-TWT member STA can request that a new (temporary or longer-term) R-TWT SP be set up after the current R-TWT SP, which should be earlier than the STA's own R-TWT SP.

[0142]

[0191] When a scheduling AP receives an R-TWT information frame from a non-AP STA, it responds with a frame carrying the same fields as the R-TWT information frame, indicating 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 setup.

[0143]

[0192] The fields before the new "Temporary R-TWT" subfield are the same as those in the TWT information frame as described in Figure 8, which should maintain the flexible TWT functionality as specified in IEEE 802.11ax_D8.0.

[0144]

[0193] The Temporary R-TWT field indicates whether the new R-TWT SP is set up temporarily for one time (e.g., if set to stage 1) or for a long period of time (e.g., if set to stage 0) and must be discarded by the scheduled STA that initiated this setup.

[0145]

[0194] The fields after "Temporary R-TWT" are the same as those in the Limited TWT Traffic Information field as described in Figure 6, indicating the RTA traffic information requested / accepted in the new R-TWT SP.

[0146]

[0195] The non-AP STA that initiated the R-TWT information frame can exchange and receive agreement from the scheduling AP and transmit prioritized bursty UL flows using the new temporary / long-term R-TWT SP.

[0147] 4.11. Example of operation 4.11.1. Emergency (Temporary / Permanent) R-TWT Membership Setup within the Current R-TWT SP

[0198] 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 an AP 312, STA1 314, and STA2 316 are shown.

[0148]

[0199] The AP broadcasts beacon frame(s) (320) containing different broadcast TWT parameter sets (318) to set up different R-TWT SPs (e.g., R-TWT-X SP and R-TWT-Y SP) identified by broadcast TWT IDs.

[0149]

[0200] In this example, both the R-TWT-X SP and the R-TWT-Y SP are scheduled as trigger-enabled R-TWT SPs. STA1 is a member of only the R-TWT-X SP, while STA2 is a member of only the R-TWT-Y SP. Both STA1 and STA2 are power-saving (PS) STAs that wake to receive beacon frame(s) to determine the R-TWT. In the absence of communication, these STAs can be in a doze state (322) (324), as seen at the start of the figure and after receiving a beacon frame from the scheduling AP.

[0150]

[0201] During triggerable TWT SPs 326 and 356, the AP first transmits a basic trigger frame 328, in response to which STA1 and STA2 indicate that they are awake during the TWT SP. STA1 and STA2 should wake up to receive DL PPDUs in scheduled R-TWT SPs in which they have R-TWT membership, and can be in a doze state outside of their own R-TWT SPs.

[0151]

[0202] In the R-TWT-X SP, the following occurs: STA1, as a member of the R-TWT-X SP, responds to the basic trigger frame with a PS poll (330), indicating that STA1 is awake, and receives an ACK / BA (332) from the AP. STA2 does not respond to the basic trigger frame, indicating that STA2 is still in a doze state.

[0152]

[0203] STA1 receives the DL PPDU (334) and responds with an ACK / BA (336) as shown. After this exchange, STA1 enters the Doze state (352) except for this R-TWT-X SP.

[0153]

[0204] STA2, which is not a member of the R-TWT-X SP, wakes up with an urgent UL RTA flow to transmit, which causes STA2 to transition from a doze state to a wake-up state, as shown. As shown, STA2 initiates an R-TWT negotiation request (338) with the scheduling AP by transmitting a negotiation frame (e.g., TWT Request) carrying TWT elements.

[0154]

[0205] The TWT Setup Command subfield in the Broadcast TWT Parameter Set field should be set as "Request TWT" or "Proposed TWT" to leave the decision to the scheduling AP.

[0155]

[0206] The requesting / proposing non-AP STA should indicate its request to become a temporary or long-term member of the requested R-TWT-X SP by indicating a new temporary member subfield in the request type field in the broadcast TWT parameter set field as described with respect to FIG. 25.

[0156]

[0207] If the scheduling AP agrees to the requested / proposed TWT parameter set, it should respond with a TWT Response frame (340) with the TWT Setup Command field set as "Accept TWT" and indicate the agreed-upon duration of membership (i.e., temporary or long-term) in the New Proposed Temporary Member subfield in the Request Type field in the Broadcast TWT Parameter Sets field as described with respect to FIG. 25.

[0157]

[0208] The scheduling AP can send a BSRP frame (342) to STA2 to trigger a BSR frame (344), which uses the BSR information to assign RUs to STA2 for transmission of an UL TB PPDU. The assignment of RU information for STA2 is carried in a basic trigger frame (346). Upon receiving the basic trigger frame, STA2 should transmit UL trigger-based (TB) PPDU(s) (348) using the assigned RUs. The scheduling AP should respond with an ACK / BA (350) after receiving the PPDU(s) from STA2. STA2 then returns to the doze state (354) as shown.

[0158]

[0209] In R-TWT-Y SP, the following occurs:

[0159]

[0210] STA2, as a member of the R-TWT-Y SP (356), wakes up and responds to the basic trigger frame (358) from the scheduling AP with a PS Poll (360), indicating that STA2 is awake, and an ACK / BA (362) is sent by the AP. Note that STA1 does not respond to the basic trigger frame, indicating that STA1 is in the asleep (doze) state (352).

[0160]

[0211] STA2 receives the DL PPDU (364) and responds with an ACK / BA (366) in a subsequent exchange with the AP, after which it can return to a doze state except for this R-TWT-Y SP.

[0161] 4.11.2. Urgent New R-TWT SP Setup During Current R-TWT SP

[0213] 29 and 30 illustrate an example embodiment 410 of a new R-TWT SP setup procedure for a non-R-TWT member STA during an ongoing R-TWT SP. The interaction between AP 312, STA1 314, and STA2 316 is again shown.

[0162]

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

[0163]

[0215] In this example, both the R-TWT-X SP (412) and the R-TWT-Y SP (446) are scheduled as triggerable R-TWT SPs, while the R-TWT-Z SP (436) is not a triggerable R-TWT SP.

[0164]

[0216] STA1 is a member of only the R-TWT-X SP, while STA2 is a member of only the R-TWT-Y SP. Both STA1 and STA2 are power-saving (PS) STAs that wake to receive beacon frame(s) to determine the R-TWT and can be in a doze state after receiving a beacon frame from the scheduling AP.

[0165]

[0217] During a triggerable TWT SP, the AP first transmits basic trigger frames (414) and (438), in response to which STA1 and STA2 indicate that they are awake during the TWT SP.

[0166]

[0218] STA1 and STA2 should wake up to receive DL PPDUs in scheduled R-TWT SPs in which they have R-TWT membership, and return to doze state in R-TWT SPs other than their own.

[0167]

[0219] In the R-TWT-X SP, the following occurs:

[0168]

[0220] STA1, a member of the R-TWT-X SP, responds to the basic trigger frame (414) with a PS poll (416) to indicate that STA1 is awake. STA2 does not respond to the basic trigger frame, indicating that STA2 is in a doze state.

[0169]

[0221] STA1 receives its DL buffered unit (BU) (420) (including DL SU / MU PPDU as shown) and responds with an ACK / BA (422). After the R-TWT-X SP, STA1 can return / enter the doze state (430).

[0170]

[0222] STA2, which is not a member of the R-TWT-X SP, has an urgent UL RTA flow to transmit, as shown, which causes STA2 to transition from the doze state to the wake-up state. As shown, STA2 transmits an R-TWT information frame (424) to the scheduling AP to request / propose that the scheduling AP set up a new (temporary / long-term) R-TWT SP after the current R-TWT-X SP and before STA2's own R-TWT-Y SP.

[0171]

[0223] The R-TWT Information frame should set the Response Request field and Next TWT Request field to zero to indicate that the response does not need to be an R-TWT Information frame. The requesting / proposing non-AP STA should indicate whether a temporary or long-term R-TWT SP is required by indicating it in the Temporary R-TWT field in the R-TWT Information frame as described in Figure 26.

[0172]

[0224] When the scheduling AP receives an R-TWT information frame from a non-AP STA, it responds with a frame (426) carrying the fields contained in the R-TWT information frame, sets the next TWT to the earliest time, and starts a new R-TWT SP. The Response Request and Next TWT Request fields should be set to zero.

[0173]

[0225] The scheduling AP should indicate whether a temporary or long-term R-TWT SP has been agreed upon in this setup by indicating it in the Temporary R-TWT field in the R-TWT Information frame as described in FIG.

[0174]

[0226] In the new (temporary / long-term) R-TWT-X+1 SP (428), the following occurs: This SP overlaps the existing R-TWT-Z SP in the time domain as shown. In this case, STA2 does not have R-TWT membership in R-TWT-Z, but should still have high access priority as an R-TWT member during all R-TWT-X+1 SPs.

[0175]

[0227] During the R-TWT-X+1 SP, the scheduling AP can send a Buffer Status Report Poll (BSRP) / Trigger Response Scheduling (TRS) frame (432) to STA2 to trigger a BSR frame (434). The AP can then use the BSR information to assign RUs to STA2 to transmit the UL TB PPDU. The RU assignment for STA2 is carried in a basic trigger frame (438). Upon receiving the basic trigger frame, STA2 should transmit the UL TB PPDU (440) using the assigned RUs. After receiving the PPDU(s) from STA2, the scheduling AP should respond with an ACK / BA (442). STA2 can return to the doze state (444) after this R-TWT-X+1 SP.

[0176]

[0228] In R-TWT-Y SP, the following occurs:

[0177]

[0229] STA2, as a member of the R-TWT-Y SP, responds to the basic trigger frame (448) from the scheduling AP with a PS Poll (450) to indicate that STA2 is awake, and the AP responds with an ACK / BA (452). Meanwhile, STA1 does not respond to the basic trigger frame, indicating that STA1 is in a doze state.

[0178]

[0230] STA2 receives a DL BU (e.g., DL SU / MU PPDU) 454 in an exchange with the AP and responds with an ACK / BA 456. STA2 can return to the doze state outside of this R-TWT-Y SP.

[0179] 4.11.3 Urgent Non-R-TWT Member STA Transmission Using UORA

[0232] The following example is based on the new implementation described in Section 4.5.

[0180]

[0233] 31 illustrates an example embodiment 510 in which a non-R-TWT member STA transmits using a UORA in an R-TWT SP in which it does not have membership. The STAs and APs shown are the same as in the previous two figures.

[0181]

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

[0182]

[0235] STA1 is a member of only the R-TWT-X SP, while STA2 is a member of only the R-TWT-Y SP.

[0183]

[0236] In the R-TWT-X SP (512), the scheduling AP can broadcast trigger frames (518) and (524) containing the RA-RU (516) (e.g., the first two trigger frames shown in this figure).

[0184]

[0237] Upon receiving the first trigger frame, STA1, as a member of the R-TWT-X SP, does not need to contend for an RA-RU (514) and instead transmits its pending PPDU (520) on an assigned RU (e.g., RU1-RU3) as indicated in the trigger frame. STA2, as a non-R-TWT-X member STA, can decrement its OBO counter and contend for eligible RA-RUs (e.g., RU4, RU5) as indicated in the trigger frame. In this example, STA2's OBO counter counts down to zero after receiving the first trigger frame, and STA2 selects RU4 from the eligible RA-RUs and transmits an UL PPDU (522). The AP should respond with an ACK / BA (not shown) as receipt of the UL PPDU.

[0185]

[0238] Upon receiving the second trigger frame (524), STA1, as a member of the R-TWT-X SP, does not need to contend for an RA-RU and instead transmits its pending PPDU (526) on an RU (e.g., RU1-RU7) assigned as indicated in the trigger frame. STA2, as a non-R-TWT-X member STA, can decrement its OBO counter to contend for an eligible RA-RU (e.g., RU8) as indicated in the trigger frame. In this example, STA2's OBO counter decrements to a non-terminating (non-zero) value after receiving the first trigger frame, and STA2 maintains the OBO value and resumes counting down until it later receives a trigger frame carrying an RA-RU for the associated STA.

[0186]

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

[0187]

[0240] 32 and 33 show an example embodiment 610 in which a non-R-TWT member STA transmits a BSR using an RA-RU in an R-TWT SP in which it does not have membership. The STA and AP are the same as described in the previous figures, and in other respects this example is similar, with the differences described below.

[0188]

[0241] A beacon (320) is transmitted that includes a broadcast TWT parameter set (318) that defines an R-TWT-X SP (614) that includes the RA-RU and describes a triggerable R-TWT-Y SP (630) that does not include the guarantee of the RA-RU (632).

[0189]

[0242] In the triggerable R-TWT-X SP (612), STA1 is a member, so upon receiving the first and second trigger frames (618) and (624), STA1 transmits UL PPDUs (620) and (626) on its assigned RUs, respectively (e.g., the first PPDU on RU1-RU3 and the second PPDU on RU1-RU7), as shown.

[0190]

[0243] Upon receiving this first trigger frame (618), STA2 responds as a non-R-TWT-X member STA by decrementing its OBO counter and contending for eligible RA-RUs (e.g., RU4 and RU5) as indicated in the trigger frame. In this example, STA2's OBO counter counts down to terminal count (zero) after receiving this first trigger frame, and STA2 selects RU4 from the eligible RA-RUs and sends a BSR (622). The AP should allocate RUs to STA2 in the next trigger frame based on the buffer status information indicated in the BSR.

[0191]

[0244] Upon receiving the second trigger frame (624), STA2 should be assigned RUs (e.g., RU8 and RU9) and be able to transmit UL PPDU(s) (628) directly using the assigned RUs without contending for eligible RA-RUs.

[0192]

[0245] 34 illustrates an example embodiment 710 in which a non-R-TWT member STA performs initialization to use a UORA during an R-TWT SP in which it does not have membership. The STA and AP are the same as described in the previous figure.

[0193]

[0246] The AP broadcasts beacon frame(s) (320) containing different broadcast TWT parameter sets (318) to set up different R-TWT SPs (e.g., R-TWT-X SP (712) and R-TWT-Y SP (726)). In this example, both R-TWT SPs are set up with the Broadcast TWT Recommendations field set to a value of "4," indicating only R-TWTs that do not include a UORA. STA1 is a member of only the R-TWT-X SP, while STA2 is a member of only the R-TWT-Y SP.

[0194]

[0247] In the R-TWT-X SP (712), the scheduling AP broadcasts trigger frames (714) that do not include RA-RU guarantees, so that only triggered non-AP STAs can transmit TB UL PPDUs using the RUs assigned to them as indicated in each trigger frame.

[0195]

[0248] When a non-R-TWT-X member STA (e.g., STA2) has a burst of RTA traffic to transmit, it attempts to establish an R-TWT agreement with the scheduling AP during the R-TWT-X SP and request the scheduling AP to initiate a UORA for temporary or long-term setup in the R-TWT-X SP.

[0196]

[0249] The non-R-TWT-X member STA2 initiates the setup by sending a TWT Setup Request frame (716) that includes, in this example, the Broadcast TWT Recommendation field set to a value (e.g., "5") indicating that UORA is enabled in the R-TWT SP, and the TWT Setup Command field set to "Request / Propose TWT" to leave the decision to the scheduling AP.

[0197]

[0250] When the scheduling AP receives a TWT Request frame (716) from non-R-TWT-X member STA2, it responds with a TWT Response (718) frame indicating whether the scheduling AP accepted the new R-TWT parameters. In this example, the scheduling AP accepts the request and indicates the new R-TWT parameter set in the TWT Response frame with the TWT Setup Command field set to "Accept TWT" and the Broadcast TWT Recommendation field set to a value (illustrated as "5") (720).

[0198]

[0251] Note that after receiving a TWT response frame from the scheduling AP, STA2 becomes a temporary or long-term R-TWT-X member STA and should be able to transmit a TB PPDU by accessing the RA-RU, or by accessing the assigned RU if the AP assignment is based on the received BSR, as described in Section 4.3.

[0199]

[0252] The transmission procedure in the R-TWT-X SP including the RA-RU is similar to the previous examples of Figures 32 and 33, except that in this example, STA2 obtains membership in the R-TWT-X SP.

[0200]

[0253] After transmitting a TWT response (718) including a parameter set (721), the AP authorizes the RA-RU by changing the R-TWT SP to UORA (724), after which the AP transmits a trigger frame (722).

[0201]

[0254] After the R-TWT-X SP has finished, there is an R-TWT-Y SP (726) that can be triggered without RA-RU guarantees (728), as shown.

[0202]

[0255] When a non-R-TWT-Y member STA (e.g., STA1) has bursty UL traffic to transmit, it may first need to obtain temporary or long-term membership in R-TWT-Y, as described in Sections 4.3 and 4.4.

[0203] 4.11.4 Urgent Non-R-TWT Member STA Transmission Using Unicast RU(s)

[0257] FIG. 35 illustrates an example embodiment 810 in which a non-R-TWT member STA transmits using unicast RU(s) in an R-TWT SP in which it does not initially have membership.

[0204]

[0258] Beacon frame(s) (320) broadcast by the AP containing different broadcast TWT parameter sets (318) are used to set up different R-TWT SPs (e.g., R-TWT-X SP and R-TWT-Y SP). In this example, both R-TWT SPs are set up with the Broadcast TWT Recommendation field set to a value (illustrated as "4") indicating that only R-TWT without unicast RU(s) should be performed. STA1 is a member of only the R-TWT-X SP, while STA2 is a member of only the R-TWT-Y SP.

[0205]

[0259] In R-TWT-X SP (812), the scheduling AP broadcasts trigger frames that do not include RA-RUs, so that only triggered non-AP STAs can transmit TB UL PPDUs using the RUs assigned to them as indicated in each trigger frame.

[0206]

[0260] When a non-R-TWT-X member STA (e.g., STA2) has a burst of RTA traffic to transmit, it establishes an R-TWT-X agreement with the scheduling AP during the R-TWT-X SP (812) as shown, and requests unicast RU(s) in the R-TWT-X SP as a temporary setup.

[0207]

[0261] A non-R-TWT-X member STA2 can initiate setup by sending a TWT Setup Request frame (814) with the Broadcast TWT Recommendation field set to a value (e.g., "6") indicating an R-TWT SP with enabled unicast RU(s) and the TWT Setup Command field set to "Request / Propose TWT" for the scheduling AP to decide.

[0208]

[0262] When the scheduling AP receives a TWT request frame from non-R-TWT-X member STA2, it responds with a TWT response frame (816) indicating whether the scheduling AP accepted the new R-TWT parameters. In this example, the scheduling AP accepts the new R-TWT parameters indicated in the TWT response frame (818) with the TWT Setup Command field set to "Accept TWT" and the Broadcast TWT Recommendation field set to a value (illustrated as "6").

[0209]

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

[0210]

[0264] 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 therefore STA2 should be able to transmit the TB PPDU by accessing the assigned RU (i.e., RU5).

[0211]

[0265] In the next SP, which is the R-TWT-Y SP 828, unicast RU(s) are not allowed 830. When a non-R-TWT-Y member STA (e.g., STA1) has a burst of UL traffic to send, it may need to first obtain temporary membership in the R-TWT-Y.

[0212] Urgent Non-R-TWT Member STA Transmission

[0267] Figure 36 shows an example 850 of a simple topology for an MLO scenario consisting of three MLDs. The AP MLD 852 has three affiliated APs operating on three different links, e.g., AP1 858 on L1, AP2 860 on L2, and AP3 862 on L3.

[0213]

[0268] MLD2 854 has two associated STAs operating on two different links: STA1 864 on L1 and STA2 866 on L2. MLD3 856 has two associated STAs operating on two different links: STA3 868 on L2 and STA4 870 on L3.

[0214]

[0269] 37 illustrates an example embodiment 910 of emergency R-TWT agreement setup over multiple links for MLD STAs that do not have R-TWT membership in the current R-TWT SP(s) on any link. The interacting MLDs are those seen in FIG.

[0215]

[0270] The scheduling MLD AP scheduled R-TWT-X SPs for MLD2 on L1 (912) and L2 (914), and R-TWT-Y SPs for MLD3 on L2 (930) and (934) and L3 (932) and (936). MLD2 is not shown as it is not the focus of this example.

[0216]

[0271] In this example, assume that MLD3 has urgent burst UL traffic (916) to transmit during an R-TWT-X SP for which it has not obtained membership on L1 and L3. MLD3 can use L3 to transmit the buffered packets. This is shown as a packet exchange between STA4 and AP3 on L3 during the R-TWT-X SP on L1 and L2. In this case, STA4 sends an RTS (918) and receives a CTS (920), and then STA4 sends an UL PPDU (922) and receives an ACK / BA (924). In addition to using L3, MLD3 can request to become a member of the current R-TWT-X SP on L2 and request to set up a new R-TWT-Z SP on L3. MLD3 should negotiate a new R-TWT-X setup and a new R-TWT-Z setup with MLD1 on L2 and L3, respectively, by transmitting R-TWT negotiation frames on any available link.

[0217]

[0272] In this example, different broadcast TWT agreements can be established on different links, e.g., an R-TWT-X SP on L2 that includes UORA functionality (as proposed in Section 4.5) and an R-TWT-Z SP on L3 that includes unicast functionality (as proposed in Section 4.6).

[0218]

[0273] Negotiation frames (e.g., TWT Request and TWT Response) are exchanged between STA4 and AP3 on L3. When AP3 receives the TWT Request frame (926) on L3, it should respond with a TWT Response frame (928) to announce 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 of MLD3 is added as a temporary / long-term member using the R-TWT-X SPs (930) and (934) on L2. At the same time, STA4 of MLD3 is a member using the new R-TWT-Z SPs (932) and (936) on L3. MLD3 is a member of the R-TWT-Y SP on L2 and L3 and therefore has access to the R-TWT-Y SP on L2 (938) and L3 (940) with the highest priority of the R-TWT members.

[0219] 5. General Scope of Embodiments

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

[0220]

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

[0221]

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

[0222]

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

[0223]

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

[0224]

[0280] From the description herein, it will be understood that the present disclosure includes multiple implementations of the technology, including but not limited to the following:

[0225]

[0281] 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry, the wireless communication circuitry being a wireless station (STA) that is a separate STA or a STA in a multi-link device (MLD), the wireless communication circuitry operating as a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism over a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating over the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuitry, the steps including: (i) transmitting to the AP during an ongoing random-target wait time (R-TWT) service period (SP); (d)(ii) initiating, from the non-AP STA, an R-TWT negotiation with the AP to perform scheduling as a scheduling AP within the ongoing R-TWT SP, the R-TWT negotiation being initiated by the non-AP STA upon receipt of a request for temporary or long-term membership in a particular R-TWT SP, which may be either a current R-TWT SP or an R-TWT SP subsequent to the current R-TWT SP but preceding an R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) if an uplink orthogonal frequency division multiplexing access-based random access (UORA) feature is enabled, upon receipt of a request for temporary or long-term membership in a particular R-TWT SP, the R-TWT SP being initiated by the non-AP STA upon receipt of a request for temporary or long-term membership in a particular R-TWT SP, which may be a current R-TWT SP or an R-TWT SP subsequent to the current R-TWT SP in which the non-AP STA originally had R-TWT membership, or (C) if an uplink orthogonal frequency division multiplexing access-based random access (UORA) feature is enabled, the R-TWT SP being initiated by the non-AP STA upon receipt of a request for temporary or long-term membership in a particular R-TWT SP, which may be a R-TWT SP subsequent to the current R-TWT SP in which the non-AP STA originally had R-TWT membership.(d)(iii) the scheduling AP can accept or reject the membership request from the non-AP STA making the membership request, or can indicate an alternative R-TWT setup or command a preferred R-TWT setup from the STA; and (d)(iv) in response to the membership request being accepted, the non-AP STA either (A) transmits an emergency burst of RTA traffic in the particular R-TWT SP, or (B) if UORA is enabled, contends for an RA-RU in the current R-TWT SP.

[0226]

[0282] 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry, the wireless communication circuitry being a wireless station (STA) that is a separate STA or a STA in a multi-link device (MLD), the wireless communication circuitry operating as a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism over a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating over the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuitry, the steps including: (i) queuing an urgent burst of real-time application (RTA) traffic by a non-AP STA for transmission to the AP during an ongoing random target wait time (R-TWT) service period (SP), the steps including: (i) queuing an urgent burst of real-time application (RTA) traffic by a non-AP STA for transmission to the AP during an ongoing R-TWT ... (d)(ii) initiating, from the non-AP STA, an R-TWT negotiation with the AP to perform scheduling as a scheduling AP within the ongoing R-TWT SP, the negotiation being initiated upon (A) a request for temporary or long-term membership in a particular R-TWT SP, which is either a current R-TWT SP or an R-TWT SP after the ongoing R-TWT SP but before an R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) if an uplink orthogonal frequency division multiplexing access-based random access (UORA) feature is enabled, a request for temporary or long-term membership in a particular R-TWT SP, which is either a current R-TWT SP or an R-TWT SP after the ongoing R-TWT SP but before an R-TWT SP in which the non-AP STA originally had R-TWT membership,(d)(iii) the R-TWT negotiation is based on the non-AP STA sending a TWT request frame and receiving a TWT response frame, each of which carries a TWT information element including a negotiation type subfield indicating this form of negotiation; (d)(iv) the TWT information element includes a subfield of a request type field to indicate temporary or long-term membership in the current R-TWT, which subfield can be used by the scheduling AP to indicate whether membership is accepted; (d)(v) the scheduling AP can accept or reject the membership request from the non-AP STA making the membership request, or can indicate an alternative R-TWT setup or command a preferred R-TWT setup from the STA; and (d)(vi) in response to the membership request being accepted, the non-AP STA: (A) The device may enable a UORA in response to (a) transmitting an emergency burst of RTA traffic at an SP, or (b) contending for an RA-RU at a current R-TWT SP if UORA is enabled, and (d)(vii) setting a value in a broadcast TWT recommendation field to request that a UORA including at least one RA-RU function be enabled in the R-TWT.

[0227]

[0283] 1. A method for performing wireless communication in a network, the method comprising: (a) communicating between wireless stations (STAs), which may be separate STAs or STAs within a multi-link device (MLD), each of the wireless stations (STAs) operating as an access point (AP) or a non-AP STA, wirelessly communicating with other wireless STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) queuing an urgent burst of real-time application (RTA) traffic by the non-AP STA for transmission to the AP during an ongoing random target wait time (R-TWT) service period (SP), wherein the non-AP STA does not have an R-TWT membership during the ongoing R-TWT SP; and (c) receiving a notification from the non-AP STA of the ongoing R-TWT. and initiating R-TWT negotiation with the AP within an R-TWT SP to perform scheduling with the AP as a scheduling AP, the negotiation including (A) a request for temporary or long-term membership in a specific R-TWT SP, which is either a current R-TWT SP or an R-TWT SP subsequent to an ongoing R-TWT SP but preceding an R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) a request to contend for a random access resource unit (RA-RU) in a current R-TWT SP if an uplink orthogonal frequency division multiplexing access based random access (UORA) feature is enabled; (d) the scheduling AP may accept or reject the membership request from the non-AP STA making the membership request, or may indicate an alternative R-TWT setup or direct a preferred R-TWT setup from the STA; and (e) in response to the membership request being accepted, the non-AP STA may:A method for transmitting an emergency burst of RTA traffic in an SP, or (B) contending for an RA-RU in a current R-TWT SP if UORA is enabled.

[0228]

[0284] An apparatus or method of any of the preceding implementations, wherein the R-TWT negotiation is based on the non-AP STA sending a TWT request frame and receiving a TWT response frame, each of which carries a TWT information element including a negotiation type subfield indicating this form of negotiation.

[0229]

[0285] An apparatus or method of any of the preceding implementations, wherein the TWT information element further includes a subfield of the request type field to indicate temporary or long-term membership in the current R-TWT, which subfield can be used by the scheduling AP to indicate whether membership has been accepted.

[0230]

[0286] An apparatus or method of any of the preceding implementations, wherein the UORA can be enabled in response to setting a value in a Broadcast TWT Recommendation field to request that the UORA including at least one RA-RU function be enabled in the R-TWT.

[0231]

[0287] An apparatus or method of any of the preceding implementations, wherein a non-AP STA scheduled for any R-TWT can contend for RA-RU transmission in the current R-TWT SP if UORA is enabled.

[0232]

[0288] An apparatus or method of any of the preceding implementations, wherein a non-AP STA that is not scheduled for any R-TWT can contend for RA-RU transmission in the current R-TWT SP if UORA is enabled.

[0233]

[0289] An apparatus or method of any of the preceding implementations, wherein a non-AP STA, when its OFDMA backoff (OBO) counter reaches a terminal count, can directly transmit an UL PPDU using one RA-RU despite not being an R-TWT member STA, or can transmit a Buffer Status Report (BSR) in the RA-RU to enable the scheduling AP to assign a specific RU to the non-AP STA to perform direct access in the next triggered UL PPDU transmission.

[0234]

[0290] An apparatus or method of any of the preceding implementations, wherein the non-AP STA, which is an R-TWT scheduled STA, requests to join the current R-TWT SP using a guaranteed unicast RU assigned to a specific association identification (AID) owned by the non-AP STA.

[0235]

[0291] An apparatus or method of any of the preceding implementations, wherein a value of a Broadcast TWT Recommendation field indicates a request for allocation of the guaranteed unicast RU.

[0236]

[0292] An apparatus or method of any preceding implementation, wherein the guaranteed unicast RU allocation cannot be scheduled at the start of any R-TWT SP.

[0237]

[0293] An apparatus or method of any of the preceding implementations, wherein the non-AP STA scheduled for any R-TWT can initiate allocation of the guaranteed unicast RU during a current ongoing R-TWT SP by exchanging negotiation frames with the scheduling AP.

[0238]

[0294] An apparatus or method of any of the preceding implementations, wherein upon receiving an accept message from the scheduling AP, the non-AP STA can immediately access the guaranteed unicast RU assigned to its AID for transmission in this R-TWT SP.

[0239]

[0295] The apparatus or method of any of the preceding implementations, wherein the non-AP STAs that are R-TWT scheduled STAs can contend for a new group association identity (AID) on the assigned RA-RU(s) designated for non-AP STAs that are not R-TWT members.

[0240]

[0296] An apparatus or method of any of the preceding implementations, wherein the Broadcast TWT Recommendation field is set to a particular value to indicate that RA-RU access is enabled for non-AP STAs that are not R-TWT members.

[0241]

[0297] An apparatus or method of any of the preceding implementations, wherein contending for a new group association identity (AID) on the assigned RA-RU(s) can be scheduled at the start of any R-TWT SP.

[0242]

[0298] An apparatus or method of any preceding implementation, wherein the new AID is carried in a beacon frame and broadcast periodically.

[0243]

[0299] The apparatus or method of any of the preceding implementations, wherein the non-AP STAs that do not have membership in the current R-TWT SP can contend for access to the RA-RU(s) dedicated to the new group AID for transmission in this R-TWT SP.

[0244]

[0300] An apparatus or method of any of the preceding implementations, wherein the non-AP STA that is a scheduled R-TWT STA (A) is assigned temporary membership in the current ongoing R-TWT SP only once, and (B) can be assigned long-term membership that can be revoked at any time.

[0245]

[0301] An apparatus or method of any of the preceding implementations, wherein the non-AP STA that is a scheduled R-TWT member that is an MLD STA can request to set up different R-TWT agreements on its multiple links.

[0246]

[0302] As used herein, the term "implementation" is intended to include, but is not limited to, an embodiment, example, or other form of implementing the techniques described herein.

[0247]

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

[0248]

[0304] Phrasal constructs within this disclosure such as "A, B and / or C" refer to any combination of items A, B, and C, where either A, B, or C can be present. Phrasal constructs such as "at least one of" followed by a listed group of elements indicate that at least one of the group elements is present, and, where applicable, includes any possible combination of the listed elements.

[0249]

[0305] Reference herein to "one embodiment," "at least one embodiment," or similar embodiment terminology 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 do not necessarily all refer to the same embodiment or to a specific embodiment that is different from all other embodiments described. The embodiment phrase should be interpreted to mean that the particular feature, structure, or characteristic of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed devices, systems, or methods.

[0250]

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

[0251]

[0307] Relative terms such as first and second, top and bottom, upper and lower, left and right, etc. may be used only to distinguish one entity or action from another and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.

[0252]

[0308] The terms "comprises," "comprising," "has," "having," "includes," "including," "contains," "containing," or any other variations of these terms, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises, includes, contains, or has a list of elements may include other elements not expressly listed or inherent to such process, method, article, or apparatus, rather than including only those elements. An element introduced by "comprises...a," "has...a," "includes...a," or "contains...a" does not, in the absence of further constraints, exclude the presence of additional identical elements within the process, method, article, or apparatus that comprises, includes, contains, or has that element.

[0253]

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

[0254]

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

[0255]

[0311] 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 a particular way is configured in at least that way, but may also be configured in unrecited ways.

[0256]

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

[0257]

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

[0258]

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

[0259]

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

[0260]

[0316] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as separately claimed subject matter.

[0261]

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

[0262]

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

[0263] AID12 subfield encoding [Table 1] [Explanation of symbols]

[0264] 10 Example of Implementation 12 circuits 14 External I / O Connections / Bus 16 Internal Bus 18 CPUs / Processors 20 memory 22 Modem 24,28 RF Module 26a, 26b, 26c, ... 26n, 29 Antenna 40 Example of Implementation 42 Station 1 44 STATION 2 46 STATION N 48 MLD Management Entity 50 CPU 52 Memory (RAM) 54 Modem 56 RF circuit 58 Bus 60a, 60b, 60c, ..., 60n antennas 62 CPU 64 memory (RAM) 70 Example STA Topology 72 Access Points (AP) 74 STA1 76 STA2 90 Example of Implementation 92 AID value 94 Trigger Frame 96 Allocation 98 MU BA 110 Example of an embodiment 112 Station AID 114 Trigger Frame 118 MU BA 130 Example of Implementation 132 Status 134 Trigger Frame 136TB PPDU 138 MU BA 150 Example of Implementation 152 STAs have bursts of RTA traffic to send 154 Is there an R-TWT SP on the transmitting link where the STA has R-TWT membership? 156 STAs can wait for a trigger from the scheduling AP 158 Does the STA send a negotiation frame to request / propose to be added as a member of the current R-TWT on the transmit link? 160 Has the STA received a negotiation frame from the scheduling AP to accept adding the STA as a member of the current R-TWT on the transmit link? 162 STAs can still compete for channel access as non-R-TWT members. 164 Is RA-RU(s) enabled for all STAs? 166 Non-R-TWT STAs can compete for RA-RUs allocated to associated STAs. 168 Is RA-RU(s) enabled for non-R-TWT STAs only? 170 STAs can compete for RA-RUs that are allocated only to non-R-TWT STAs 172 Are RU(s) guaranteed for non-R-TWT STAs? 174 STA transmits on guaranteed RU(s) 176 Has the STA set up a new R-TWT SP after the current R-TWT SP but before the STA's own R-TWT SP? 178 Has the STA received a frame from the scheduling AP to accept the setup of a new R-TWT? 180 STAs can contend for the channel or wait for a trigger from the scheduling AP on a new R-TWT SP. 190 Example of Implementation 192 Has the AP received a negotiation frame to request / propose to be added as a temporary / long-term member of the current R-TWT or to set up a new temporary / long-term R-TWT on the transmit link? 194 The AP responds to the requesting STA indicating acceptance or rejection of the request. 196 Did the AP accept the requesting STA as a member of the requested R-TWT on the outgoing link? 198 AP does not spontaneously trigger non-R-TWT member STAs 200 AP can trigger non-R-TWT member STAs as R-TWT members 202 Are RA-RU(s) enabled for all associated STA transmissions? 204 AP indicates at least one RA-RU for all STAs in the trigger 206 Is RA-RU(s) enabled for non-R-TWT STA transmissions only? 208 The AP indicates in the trigger at least one RA-RU assigned to a specific group AID for non-R-TWT member STAs only. 210 Are guaranteed RU(s) enabled for the requesting non-R-TWT STA? 212 The AP indicates at least one guaranteed RU for the requesting non-R-TWT STA. 230 Example of Implementation 250 Example of Implementation 310 Example of Implementation 312 AP 314 STA1 316 STA2 318 Broadcast TWT Parameter Set 320 Beacon 322 doses 324 doses 326 Triggerable R-TWT-X SP 328 Basic Trigger 330 PS pole 332 ACK / BA 334 DL PPDU 336 ACK / BA 338 TWT request 340 TWT Response 342 BSRP 344 BSR 346 Basic Trigger 348 UL PPDU 350 ACK / BA 352 doses 354 doses 356 Triggerable R-TWT-Y SP 358 Basic Trigger 360 PS Pole 362 ACK / BA 364 DL PPDU 366 ACK / BA 410 Example of Implementation 412 Triggerable R-TWT-X SP 414 Basic Trigger 416 PS Pole 420 DL SU / MU PPDU 422 ACK / BA 424 TWT information frame 426 TWT Information Frame ACK 428 Triggerable R-TWT-X+1 SP 430 doses 432 BSRP / TRS 434 BSR 436 R-TWT-Z SP 438 Basic Trigger 440 UL PPDU 442 ACK / BA 444 Dose 446 Triggerable R-TWT-Y SP 448 Basic Trigger 450 PS pole 452 ACK / BA 454 DL SU / MU PPDU 456 ACK / BA 510 Example of Implementation 512 Triggerable R-TWT-X SP 514 R-TWT-X SP including RA-RU 516 Trigger frame containing RA-RU 518 Trigger 520 UL PPDU 522 UL PPDU 524 Trigger 526 UL PPDU 528 Triggerable R-TWT-Y SP 530 R-TWT-Y SP without RA-RU warranty 610 Example of Implementation 612 Triggerable R-TWT-X SP 614 R-TWT-X SP including RA-RU 616 Trigger frame containing RA-RU 618 First Trigger 620 UL PPDU 622 BSR 624 Second Trigger 626 UL PPDU 628 UL PPDU 630 Triggerable R-TWT-Y SP 632 R-TWT-Y SP without RA-RU warranty 710 Example of Implementation 712 Triggerable R-TWT-X SP 714 R-TWT-X SP not including RA-RU warranty 716 TWT request 718 TWT Response 720 shows the new R-TWT parameter set 721 Broadcast TWT Parameter Set 722 Trigger frame containing RA-RU R-TWT-X SP including 724 RA-RU 726 Triggerable R-TWT-Y SP 728 R-TWT-Y SP without RA-RU warranty 810 Example of embodiment 812 Triggerable R-TWT-X SP 814 TWT request 816 TWT Response 818 New R-TWT parameters are shown. 820 Broadcast TWT Parameter Set 822 Trigger 824 UL PPDU is received 826 UL PPDU 828 Triggerable R-TWT-Y SP 830 R-TWT-Y SP without RA-RU warranty 850 Example of embodiment 852 AP MLD 854 MLD2 856 MLD3 858 AP1 860 AP2 862 AP3 864 STA1 866 STA2 868 STA3 870 STA4 910 Example of Implementation R-TWT-X for 912 STA1 R-TWT-X for 914 STA2 UL burst flow to 916 AP 918 RTS 920 CTS 922 UL PPDU 924 ACK / BA 926 TWT request 928 TWT Response R-TWT-X for 930 STA3 R-TWT-Z for 932 STA4 R-TWT-X for 934 STA3 R-TWT-Z for 936 STA4 938 R-TWT-Y for STA3 R-TWT-Y for 940 STA4

Claims

1. 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit being a wireless station (STA) that is a separate STA or a STA in a multi-link device (MLD), the wireless communication circuit operating as a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by said processor for communicating with other STAs; Equipped with (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, the steps comprising: (i) queuing an urgent burst of real-time application (RTA) traffic by a non-AP STA for transmission to the AP during an ongoing random-target wait time (R-TWT) service period (SP), wherein the non-AP STA does not have R-TWT membership during the ongoing R-TWT SP; (ii) initiating, from the non-AP STA, within the ongoing R-TWT SP, an R-TWT negotiation with the AP to perform scheduling as a scheduling AP, the negotiation including (A) a request for temporary or long-term membership in a particular R-TWT SP, which may be the current R-TWT SP or an R-TWT SP after the ongoing R-TWT SP but before the R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) a request to contend for a random access resource unit (RA-RU) in the current R-TWT SP if an uplink orthogonal frequency division multiplexing access-based random access (UORA) function is enabled; Including, (iii) in the case where the R-TWT negotiation includes a request of (A), the scheduling AP can accept or reject the membership request from the non-AP STA making the membership request, or can indicate an alternative R-TWT setup or direct a preferred R-TWT setup from the STA; (iv) if the R-TWT negotiation includes a request of (A), in response to the membership request being accepted, the non-AP STA transmits an emergency burst of RTA traffic on the particular R-TWT SP; When the R-TWT negotiation includes a request of (B), the non-AP STA contends for an RA-RU in the current R-TWT SP; An apparatus characterized in that

2. 2. The apparatus of claim 1, wherein the R-TWT negotiation is based on the non-AP STA transmitting a TWT request frame and receiving a TWT response frame, each of which carries a TWT information element including a negotiation type subfield indicating a negotiation.

3. The device described in claim 2, characterized in that when the R-TWT negotiation includes a request (A), the TWT information element further includes a subfield of the request type field to indicate temporary or long-term membership in the current R-TWT, which subfield can be used by the scheduling AP to indicate whether membership has been accepted.

4. The device described in claim 1, characterized in that when the R-TWT negotiation includes a request (B), the device is capable of enabling a UORA in response to setting a value in a broadcast TWT recommendation field to request that a UORA including at least one RA-RU function be enabled in the R-TWT.

5. The device described in claim 1, characterized in that when the R-TWT negotiation includes a request (B), another non-AP STA scheduled for any R-TWT can compete for RA-RU transmission in the current R-TWT SP if UORA is enabled.

6. The device described in claim 1, characterized in that when the R-TWT negotiation includes a request (B), another non-AP STA that is not scheduled for any R-TWT can compete for RA-RU transmission in the current R-TWT SP if UORA is enabled.

7. The device described in claim 6, characterized in that when the R-TWT negotiation includes a request (B), another non-AP STA, when its OFDMA backoff (OBO) counter reaches a terminal count, can directly transmit a UL PPDU using one RA-RU despite not being an R-TWT member STA, or can transmit a buffer status report (BSR) in the RA-RU so that the scheduling AP can assign a specific RU to the other non-AP STA and perform direct access in the next triggered UL PPDU transmission.

8. 2. The apparatus of claim 1, wherein the non-AP STA, which is an R-TWT scheduled STA, requests to join the current R-TWT SP using a guaranteed unicast RU assigned to a specific association identification (AID) owned by the non-AP STA.

9. 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 start of any R-TWT SP.

11. The apparatus of claim 8, wherein the non-AP STA scheduled for any R-TWT can initiate allocation of the guaranteed unicast RU during a current 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, the non-AP STA can immediately access the guaranteed unicast RU assigned to its AID for transmission in this R-TWT SP.

13. The device described in claim 1, characterized in that when the R-TWT negotiation includes a request (B), the non-AP STA that is an R-TWT scheduled STA can compete for a new group association identification (AID) on an assigned RA-RU designated for a non-AP STA that is not an R-TWT member.

14. The apparatus of claim 13, further comprising: setting a Broadcast TWT Recommendation field to a specific value to indicate that RA-RU access is enabled for another non-AP STA that is not an R-TWT member.

15. The apparatus of claim 13, wherein contending for a new group association identification (AID) on an assigned RA-RU can be scheduled at the start of any R-TWT SP.

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

17. 14. The apparatus of claim 13, wherein the non-AP STAs that have not acquired membership in a current R-TWT SP can contend for access to the RA-RUs that are assigned exclusively to the 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 can be assigned a temporary membership in the current ongoing R-TWT SP only once, or can be assigned a long-term membership that can be revoked at any time.

19. 10. The apparatus of claim 1, wherein the non-AP STA that is a scheduled R-TWT member that is an MLD STA can request to set up different R-TWT agreements on its multiple links.

20. 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit being a wireless station (STA) that is a separate STA or a STA in a multi-link device (MLD), the wireless communication circuit operating as a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by said processor for communicating with other STAs; Equipped with (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, the steps comprising: (i) queuing an urgent burst of real-time application (RTA) traffic by a non-AP STA for transmission to the AP during an ongoing Random Target Wait Time (R-TWT) Service Period (SP), wherein during the ongoing R-TWT SP, the non-AP STA does not have an R-TWT membership; (ii) initiating, from the non-AP STA, within the ongoing R-TWT SP, an R-TWT negotiation with the AP to perform scheduling as a scheduling AP, the negotiation including (A) a request for temporary or long-term membership in a particular R-TWT SP, which may be the current R-TWT SP or an R-TWT SP after the ongoing R-TWT SP but before the R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) a request to contend for a random access resource unit (RA-RU) in the current R-TWT SP if an uplink orthogonal frequency division multiplexing access-based random access (UORA) function is enabled; Including, (iii) the R-TWT negotiation is based on the non-AP STA transmitting TWT request frames and receiving TWT response frames, each of which carries a TWT information element including a negotiation type subfield indicating this form of negotiation; (iv) if the R-TWT negotiation includes a request of (A), the TWT information element includes a subfield of the request type field to indicate temporary or long-term membership in the current R-TWT, which subfield can be used by the scheduling AP to indicate whether the membership has been accepted; (v) in the case where the R-TWT negotiation includes a request of (A), the scheduling AP can accept or reject the membership request from the non-AP STA making the membership request, or can indicate an alternative R-TWT setup or direct a preferred R-TWT setup from the STA; (vi) if the R-TWT negotiation includes a request of (A), in response to the membership request being accepted, the non-AP STA transmits an emergency burst of RTA traffic in the specific R-TWT SP, and if the R-TWT negotiation includes a request of (B), the non-AP STA contends for an RA-RU in the current R-TWT SP; (vii) when the R-TWT negotiation includes a request of (B), the UORA can be enabled in response to setting a value in a Broadcast TWT Recommendation field to request that the UORA including at least one RA-RU function be enabled in the R-TWT; An apparatus characterized in that

21. 1. A method for performing wireless communication in a network, the method comprising: (a) communicating between wireless stations (STAs) that are separate STAs or STAs within a multi-link device (MLD), each of the wireless stations (STAs) operating as an access point (AP) or a non-AP STA to wirelessly communicate with other wireless STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) queuing an urgent burst of real-time application (RTA) traffic by a non-AP STA for transmission to the AP during an ongoing random target wait time (R-TWT) service period (SP), wherein the non-AP STA does not have R-TWT membership during the ongoing R-TWT SP; (c) initiating, from the non-AP STA, within the ongoing R-TWT SP, an R-TWT negotiation with the AP to perform scheduling as a scheduling AP, the negotiation including (A) a request for temporary or long-term membership in a specific R-TWT SP, which may be the current R-TWT SP or an R-TWT SP after the ongoing R-TWT SP but before the R-TWT SP in which the non-AP STA originally had R-TWT membership, or (B) a request to contend for a random access resource unit (RA-RU) in the current R-TWT SP if an uplink orthogonal frequency division multiplexing access-based random access (UORA) function is enabled; Including, (d) in the case where the R-TWT negotiation includes a request of (A), the scheduling AP can accept or reject the membership request from the non-AP STA making the membership request, or can indicate an alternative R-TWT setup or direct a preferred R-TWT setup from the STA; (e) if the R-TWT negotiation includes a request of (A), in response to the membership request being accepted, the non-AP STA transmits an emergency burst of RTA traffic in the specific R-TWT SP, and if the R-TWT negotiation includes a request of (B), the non-AP STA contends for an RA-RU in the current R-TWT SP. A method characterized by:

Images