Sharing transmission opportunities with limited target wait times
Patent Information
- Application Number
- JP2024548472
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-02-16
- Filing Date
- 2023-02-07
- Publication Date
- 2025-02-28
Smart Images

Figure 2025505782000001_ABST
Abstract
Description
[Technical field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 268,085, filed February 16, 2022, which is incorporated by reference in its entirety.
[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT N / A
[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 copying by any third party of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office public files or records, but otherwise reserves all copyright rights. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including, but not limited to, the right pursuant to 37 CFR §1.14.
[0004] The techniques of this disclosure relate generally to wireless network interworking between TXOPs and R-TWT SPs, and more specifically to sharing overlapping TXOP time with R-TWT SPs to enable an AP to act as a TXOP owner. [Background technology]
[0005] The industry is constantly seeking to increase network efficiency and reduce latency for latency sensitive traffic.
[0006] In current IEEE 802.11be networking, when a non-access point (non-AP) Very High Throughput (EHT) Station (STA) that is a member STA of the next Reserved Target Wait Time (R-TWT) Service Period (SP) gets channel access and becomes a Transmission Opportunity (TXOP) owner, this STA must ensure that its TXOP ends before the start time of the R-TWT SP. Then, the R-TWT scheduling AP and / or the member STAs of the R-TWT SP must contend for the channel again at the start time of the R-TWT SP to exchange delay-sensitive traffic during the R-TWT SP.
[0007] Member STAs of an R-TWT SP cannot contend for the channel during a trigger-based (TB) R-TWT SP, and the scheduling AP is the only STA that can contend for the channel during an R-TWT SP.
[0008] Current Enhanced Distributed Channel Access (EDCA) protocols impose a TXOP limit that restricts the maximum TXOP duration that a TXOP holder can reserve a channel for once it has gained access to the channel.
[0009] Currently, these mechanisms and their interactions limit the efficiency and timeliness of these TXOP and R-TWT SP operations. Summary of the Invention [Problem to be solved by the invention]
[0010] Therefore, there exists a need for an enhanced mechanism for addressing TXOP and R-TWT SP operations. The present disclosure addresses existing shortcomings and provides further advantages. [Means for solving the problem]
[0011] A wireless protocol for enhanced frame transmission between the Medium Access Control (MAC) layer of IEEE 802.11 networks operating as either a regular STA (non-AP) or an Access Point (AP) STA that communicates wirelessly with other STAs (STAs) using Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) in which Enhanced Distributed Channel Access (EDCA) is utilized for random channel access on all links, either as an independent STA or as a STA within a Multilink Device (MLD).
[0012] As described below, the extended protocol is configured to reserve channel resources for frame exchange of delay-sensitive traffic with member STAs for a restricted target wait time (R-TWT) service period (SP).
[0013] A non-AP STA obtains channel access rights and reserves a transmission opportunity (TXOP) that overlaps with the R-TWT SP before the scheduled start time of the R-TWT SP. The non-AP STA performs any desired TXOP operation as the TXOP owner before the scheduled start time of the R-TWT SP. The non-AP STA shares the TXOP with an AP (e.g., the scheduling AP) that can act as the TXOP owner until the end of the TXOP or R-TWT SP.
[0014] Either an AP station or a non-AP station can take the following actions: Obtain channel access before the scheduled start time of the R-TWT SP Reserve a TXOP until the scheduled end time of the R-TWT SP Transmit frames of R-TWT delay-sensitive traffic from both primary access categories (ACs) and non-primary ACs and serve these ACs with a higher priority than is given to other frames during the R-TWT SP.
[0015] Further aspects of the technology described herein will become apparent in the following portions of this specification, and this detailed description is intended to fully disclose preferred embodiments of the technology without limiting them.
[0016] The techniques described herein will be better understood with reference to the following drawings, which are for illustrative purposes only. [Brief description of the drawings]
[0017] [Figure 1] FIG. 2 is a block diagram of communication station hardware in accordance with at least one embodiment of the present disclosure. [Diagram 2] FIG. 1 is a block diagram of a multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure. [Diagram 3] 1 is a network topology used in an example according to at least one embodiment of the present disclosure. [Figure 4] 1 is a flow diagram of a non-AP STA reserving a TXOP that overlaps with an R-TWT SP, in accordance with at least one embodiment of the present disclosure. [Diagram 5] 1 is a flow diagram of a non-AP STA reserving a TXOP that overlaps with an R-TWT SP, in accordance with at least one embodiment of the present disclosure. [Figure 6] 1 is a flow diagram for an AP to obtain a shared TXOP from a non-AP STA in accordance with at least one embodiment of the present disclosure. [Figure 7] FIG. 13 is a flow diagram of an AP acting as a TXOP owner inside and outside an R-TWT SP in accordance with at least one embodiment of the present disclosure. [Figure 8] FIG. 1 is a communication diagram of an example R-TWT scheduling embodiment 1 in accordance with at least one embodiment of the present disclosure. [Figure 9] FIG. 1 is a communication diagram of an example R-TWT scheduling embodiment 1 in accordance with at least one embodiment of the present disclosure. [Figure 10] FIG. 11 is a communication diagram of Example 2 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 11] FIG. 11 is a communication diagram of Example 2 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 12]FIG. 11 is a communication diagram of Example 3 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 13] FIG. 11 is a communication diagram of Example 3 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 14] FIG. 11 is a communication diagram of Example 4 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 15] FIG. 11 is a communication diagram of Example 4 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 16] FIG. 5 is a communication diagram of an example 5 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 17] FIG. 5 is a communication diagram of an example 5 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 18] FIG. 11 is a communication diagram of Example 6 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 19] FIG. 11 is a communication diagram of Example 6 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 20] FIG. 11 is a communication diagram of Example 7 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 21] FIG. 11 is a communication diagram of Example 7 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 22] FIG. 11 is a communication diagram of an eighth example of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 23] FIG. 11 is a communication diagram of an eighth example of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 24] FIG. 13 is a communication diagram of an example 9 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Diagram 25] FIG. 13 is a communication diagram of an example 9 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 26]FIG. 10 is a communication diagram of an example 10 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 27] FIG. 10 is a communication diagram of an example 10 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 28] FIG. 11 is a communication diagram of an eleventh example of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Figure 29] FIG. 11 is a communication diagram of an eleventh example of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Diagram 30] FIG. 12 is a communication diagram of an example 12 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. [Diagram 31] FIG. 12 is a communication diagram of an example 12 of R-TWT scheduling in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0018] 1. Introduction Current wireless technologies using Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) are focused on high network throughput but do not provide the support necessary to handle low latency traffic required by real-time applications (RTA), thus a technology gap exists.
[0019] RTA requires low latency communication and uses best effort communication. Data generated from RTA is called latency sensitive traffic, while data generated from non-time sensitive applications is called normal traffic.
[0020] Delay-sensitive traffic requires low delay due to high timeliness requirements in delivery. Hence, a MAC Service Data Unit (MSDU) or an Aggregated-MSDU (A-MSDU) of delay-sensitive traffic is only valid if it can be delivered within a certain period or a given expiration time.
[0021] At the time of this disclosure, the current IEEE 802.11be standard allows the use of Restricted TWT (R-TWT) to reserve channel resources for the transmission of delay-sensitive traffic. A non-Access Point (non-AP) Extremely High Throughput (EHT) STA as a TXOP owner with the R-TWT option enabled (e.g., "dot11RestrictedTWTOptionImplemented" set to true) must ensure that the TXOP ends before the start time of any R-TWT SP advertised by the associated AP.
[0022] An R-TWT scheduling AP, referred to as an R-TWT scheduling AP, is an EHT AP that supports R-TWT operation and sets the Restricted TWT Support subfield in a transmitted EHT Capabilities element to a first state (e.g., “1”) indicating R-TWT support.
[0023] An R-TWT scheduled STA, referred to as an R-TWT scheduled STA, is a non-AP EHT STA that supports R-TWT operation and has the Limited TWT Support subfield set to a first state (e.g., "1") in the transmitted EHT Capabilities element.
[0024] An R-TWT scheduling AP that includes a restricted TWT parameter set field in a broadcast TWT element must set the restricted TWT Traffic Info Present subfield of the restricted TWT parameter set field to a second state (e.g., “0”) if the Negotiation Type subfield of the TWT element is equal to a particular value (e.g., “2”).
[0025] The R-TWT scheduling AP should indicate in the Restricted TWT Downlink (DL) Traffic Identifier (TID) Bitmap subfield and the Restricted TWT Uplink (UL) TID Bitmap subfield only the TIDs that are mapped to links for which R-TWT membership is configured.
[0026] The R-TWT scheduled STA should indicate in the R-TWT DL TID Bitmap and Restricted TWT UL TID Bitmap subfields only the TIDs that are mapped to links for which R-TWT membership is established.
[0027] In the following subsections, a TID specified in an R-TWT DL TID Bitmap subfield or a Restricted TWT UL TID Bitmap subfield with the corresponding DL or UL TID Bitmap Valid subfield in a TWT Response frame that accepts the TWT is referred to as an R-TWT DL TID or an R-TWT UL TID, and collectively referred to as an R-TWT TID.
[0028] During the SP of the R-TWT, the traffic of the R-TWT TID of the R-TWT is considered as delay-sensitive traffic and is preferentially transmitted during the SP of the R-TWT.
[0029] In this disclosure, tuples<R-TWTx TID、STAy> represents the R-TWT TID specified during the R-TWTx membership negotiation between the R-TWT scheduling AP and the member STAy. The R-TWT TID (or R-TWTx TID) of R-TWTx is the tuple of all member STAs of R-TWTx.<R-TWTx TID、メンバーSTA> The R-TWT TID may also include peer-to-peer (P2P) traffic, which is designated as delay-sensitive traffic.
[0030] 2. Problem Statement When a non-AP EHT STA that is a member STA of the next R-TWT service period (SP) acquires channel access and becomes a transmission opportunity (TXOP) owner, it must ensure that its TXOP ends before the start time of the R-TWT SP. After that, the R-TWT scheduling AP and / or the member STAs of the R-TWT SP must contend for the channel again at the start time of the R-TWT SP to exchange delay-sensitive traffic during the R-TWT SP. This process not only reduces the transmission efficiency but also reduces the chance of acquiring channel access in a timely manner, which may cause significant delays in transmission and the loss of real-time packets during the process.
[0031] An R-TWT SP may be trigger-based (TB). That is, member STAs of an R-TWT SP can only transmit soliciting frames in response to the R-TWT scheduling AP. For example, member STAs can only transmit UL data frames in a TB physical layer protocol data unit (PPDU) in response to a trigger frame to the R-TWT scheduling AP. Member STAs can only transmit UL or P2P data frames in a single-user (SU) PPDU in response to a multi-user (MU) request-to-send (RTS) trigger frame transmission. Member STAs of an R-TWT SP may not be able to contend for a channel during a trigger-based R-TWT SP. That is, the R-TWT scheduling AP is the only AP that can contend for a channel during an R-TWT SP. This can increase the chances of the R-TWT scheduling AP to obtain channel access rights closer to the start time of the R-TWT SP, since there are other STAs that do not support R-TWT that are also contending for the channel.
[0032] In an ideal scenario, the scheduling AP gets the TXOP and finishes all frame exchanges of delay-sensitive traffic during that TXOP. However, current EDCA rules set a TXOP limit that limits the maximum TXOP duration that a TXOP owner can reserve when gaining channel access, which may be shorter than the R-TWT SP duration. It is inefficient to require the R-TWT scheduling AP or member STAs of the R-TWT SP to re-contend for the channel during that R-TWT SP.
[0033] 3. Contribution of this Disclosure By utilizing the proposed technique, a member STA of an R-TWT SP does not need to terminate its TXOP before the scheduled start time of the R-TWT SP if it acquires channel access rights before the scheduled start time of the R-TWT SP. If the R-TWT SP is trigger-based, it is configured to share the TXOP time overlapping with the R-TWT SP with the R-TWT scheduling AP, thus allowing the AP to act as the TXOP owner for frame exchange of delay-sensitive traffic during the R-TWT SP.
[0034] By utilizing the disclosed technology, the R-TWT scheduling AP and the member STAs of the R-TWT SP can both contend for the channel before the scheduled start time of the R-TWT SP. When one of these STAs gains channel access, it can reserve a TXOP until the scheduled end time of the R-TWT SP, extending it beyond (longer than) the normal TXOP limit.
[0035] 4. Embodiments of the present disclosure 4.1. Communication Station (STA and MLD) Hardware FIG. 1 illustrates an example embodiment 10 of STA hardware configured to execute the protocol of the present disclosure. An external I / O connection 14 couples to an internal bus 16 of the circuitry 12 on which a CPU 18 and memory (e.g., RAM) 20 are preferably connected for executing a program(s) implementing the communication protocol. The host machine contains at least one modem 22 supporting communications coupled to at least one RF module 24, 28 each coupled to one or more antennas 29, 26a, 26b, 26c-26n. RF modules with multiple antennas (e.g., antenna arrays) allow for beamforming to be performed during transmission and reception. In this manner, the STA can transmit signals using multiple sets of beam patterns.
[0036] The bus 14 can connect various devices such as sensors and actuators to the CPU. On the processor 18, instructions are executed from the memory 20 to execute a program implementing a communication protocol that is executed to enable the STA to perform the functions of an Access Point (AP) station or a normal station (non-AP STA). It is also understood that this programming is configured to operate in different modes (TXOP owner, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, AP in OBSS, STA in OBSS, etc.) depending on what role it plays in the current communication situation.
[0037] Thus, the illustrated STA HW is comprised of at least one modem and associated RF circuitry for providing communication on at least one band. It should be understood that the present disclosure may be configured using multiple modems 22, each coupled to any number of RF circuits. In general, the more RF circuits used, the greater the coverage of the antenna beam directions. It should be understood that the number of RF circuits and antennas utilized is determined by the hardware constraints of a particular device. Some of the RF circuits and antennas may be disabled when a STA determines that it does not need to communicate with neighboring STAs. In at least one embodiment, the RF circuitry includes a frequency converter and an array antenna controller, etc., and is connected to multiple antennas that are controlled to perform beamforming for transmission and reception. In this manner, a STA may transmit signals using a set of multiple beam patterns, with each beam pattern direction considered an antenna sector.
[0038] It should also be understood that multiple instances of station hardware such as that shown in this figure may be combined into a multi-link device (MLD), which typically has a processor and memory for coordinating activity, but does not necessarily require a separate CPU and memory for each STA within the MLD; these resources may be shared.
[0039] FIG. 2 shows an embodiment 40 of a multi-link device (MLD) hardware configuration. Note that a "soft AP MLD" is an MLD consisting of one or more affiliated STAs operating as an AP. The soft AP MLD should support multiple radio operation on, for example, 2.4 GHz, 5 GHz, and 6 GHz. The basic link set among the multiple radios is a link pair that satisfies simultaneous transmit / receive (STR) mode, such as basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz), etc.
[0040] A conditional link is a link that forms a non-simultaneous transmit / receive (NSTR) link pair with some fundamental link. For example, these link pairs can include a 6 GHz link as a conditional link corresponding to the 5 GHz link when the 5 GHz is the fundamental link, and can include a 5 GHz link as a conditional link corresponding to the 6 GHz link when the 6 GHz is the fundamental link. Soft APs are used in different scenarios including Wi-Fi hotspots and tethering.
[0041] A MLD has multiple STAs, each operating on a different frequency link. The MLD has external I / O access to applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to allow the execution of program(s) that implement the communication protocol at the MLD level. The MLD can distribute tasks to its associated stations, illustrated here as STA1 42, STA2 44 through STA N 46, to collect information from them and share the information among its associated STAs.
[0042] In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled over a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c-60n, such as in the form of an antenna array. The modem in combination with the RF circuit and associated antenna(s) transmits / receives data frames to / from nearby STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.
[0043] It should be understood that each STA in an MLD does not necessarily require its own processor and memory, as they may share resources with each other and / or with an MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagram is provided by way of example and not limitation, and that the present disclosure can work with a wide variety of MLD implementations.
[0044] 3 illustrates an example network topology embodiment 70 that will be used to aid in the following discussion, with the understanding that the disclosure is in no way limited to this example topology, as the protocol may be utilized in communications between WLAN STAs and MLDs of any desired topology.
[0045] In this example, assume that there is one AP, shown as AP1 72, and four STAs, shown as STA1 74, STA2 76, STA3 78, and STA4 80, in a given area 82, shown in this example as a conference room. All STAs are associated with AP1 and use carrier sense multiple access with collision avoidance (CSMA / CA) for random channel access. AP1 is the R-TWT scheduling AP and advertises R-TWT1 and R-TWT2.
[0046] STA1 is a member STA of R-TWT1. STA2 is a member STA of R-TWT2. STA3 is a STA that supports R-TWT but is not a member STA of either R-TWT. STA4 is a STA that does not support R-TWT. It should be understood that the AP and any of the STAs can be STAs that belong to the MLD.
[0047] 4.2.TXOP Sharing in R-TWT According to the current channel access rules for R-TWT Service Period (SP), a non-AP STA supporting R-TWT as a TXOP owner must end its TXOP before the scheduled start time of the R-TWT SP. However, if the TXOP owner is a member STA of the R-TWT SP, it should not end its TXOP before the end of the R-TWT SP. Otherwise, the member STA and other member STAs, as well as the R-TWT scheduling AP, must contend for the channel again at the scheduled start time of the R-TWT SP to perform frame exchange for the remaining delay-sensitive traffic. In addition, the second channel contention does not guarantee that the TXOP will be obtained close to (near) the scheduled start time of the R-TWT SP, which may cause a significant delay in the frame exchange.
[0048] The disclosed technique allows a member STA of an R-TWT SP acting as a TXOP owner to reserve a TXOP that overlaps with the R-TWT SP before the scheduled start time of the R-TWT SP. In other words, the member STA of an R-TWT SP does not need to end the TXOP at the scheduled start time of the R-TWT SP.
[0049] This disclosure also describes the operation of a wireless communication protocol that allows a member STA of an R-TWT SP to obtain a TXOP before the scheduled start time of the R-TWT SP, reserve a TXOP that overlaps with the R-TWT SP, share the TXOP with the R-TWT scheduling AP, and allow the R-TWT scheduling AP to act as a TXOP owner during the R-TWT SP.
[0050] The present disclosure is configured to allow the R-TWT scheduling AP and the member STAs of the R-TWT SP to contend for the channel together before and during the R-TWT SP. If one of them gets a TXOP before the scheduled start time of the R-TWT SP, it can transmit frames according to the current EDCA rules of sharing the EDCA TXOP. Below are some examples:
[0051] (a) If the R-TWT scheduling AP is the TXOP owner at the start of an R-TWT SP, it may transmit or trigger frames of the R-TWT TID of the R-TWT SP (and frames of P2P traffic as delay-sensitive traffic to be transmitted during the R-TWT SP) earlier than frames from the primary AC. Thus, during an R-TWT SP, frames of the R-TWT traffic identifier (TID) of the R-TWT SP and frames of P2P traffic as delay-sensitive traffic to be transmitted during the R-TWT SP are considered as frames from the primary AC.
[0052] (b) If a member STA is a TXOP owner at the beginning of an R-TWT SP, it can share a TXOP with the AP and have the AP act as the TXOP owner. The member STA can send an unsolicited Clear-To-Send (CTS) frame to the R-TWT scheduling AP to indicate TXOP sharing. When the member STA sends a CTS frame to share a TXOP with the AP, it can set the RA field of the CTS frame to the Medium Access Control (MAC) address of the AP or a special MAC address that the AP assigns to all member STAs of the R-TWT SP. Any member STA of the same R-TWT SP sets the Receiver Address (RA) field to the same special MAC address in the CTS frame to share a TXOP with the AP. In at least one embodiment / mode / option, any member STA of the same R-TWT SP uses the same scrambling number in the CTS frame to share a TXOP with the AP during the R-TWT SP. In at least one embodiment / mode / option, only member STAs of an R-TWT SP that have the R-TWT UL TID of the R-TWT SP and / or peer-to-peer (P2P) traffic scheduled during the R-TWT SP can contend for the channel during the R-TWT SP and share a TXOP with the AP.
[0053] (c) If the R-TWT SP is trigger-based, member STAs of the R-TWT SP cannot contend for the channel after the AP obtains a TXOP (including a TXOP shared by a non-AP STA) during the R-TWT SP until the end of the R-TWT SP.
[0054] This disclosure describes a protocol whereby when a member STA of an R-TWT SP or an R-TWT scheduling AP acquires a TXOP before the scheduled start time of an R-TWT SP, they can reserve a TXOP, which may or may not be restricted by the TXOP restrictions of a primary access category (AC), until the scheduled end time of the R-TWT SP. Note that the primary AC refers to the AC from which the Enhanced Distributed Channel Access Function (EDCAF) acquires the TXOP.
[0055] 4.3. Non-AP STA reserving TXOPs that overlap with R-TWT SP 4 and 5 show an example embodiment 110 in which a non-AP STA reserves a TXOP that overlaps with an R-TWT SP.
[0056] A non-AP STA accesses the channel to reserve a TXOP (112). In check 114, it is determined whether the non-AP STA obtains a TXOP outside of the R-TWT SP (before the R-TWT SP starts) and requires that the TXOP time overlaps with the R-TWT SP. If the condition is not met, execution proceeds to block 116 of FIG. 5, described below. If the condition is met, in check 118, it is determined whether the non-AP STA plans to obtain a TXOP outside of the R-TWT SP. If this condition is not met, execution proceeds to block 120 of FIG. 5.
[0057] If the conditions of check 118 are met, the non-AP STA reserves a TXOP covering the entire duration of the R-TWT SP in block 122. The non-AP STA acts as a TXOP owner according to the current EDCA rules during the TXOP time before the scheduled start time of the R-TWT SP (124). The non-AP STA shares the TXOP with the AP from at least the scheduled start time of the R-TWT SP and allows the AP to act (perform) as the TXOP owner until the end of the R-TWT SP.
[0058] In at least one embodiment / mode / option, when the AP acts as a TXOP owner, it can trigger transmission of traffic from the R-TWT downlink (DL) TID of the R-TWT SP during a shared TXOP, or traffic from the R-TWT (uplink) UL TID of the R-TWT SP and P2P traffic (or P2P traffic that is considered delay-sensitive traffic and scheduled with high priority to be transmitted during the R-TWT SP) as if such traffic is from the primary AC.
[0059] In at least one embodiment / aspect / option, the non-AP STAs mentioned above represent member STAs of the R-TWT SP (and / or STAs supporting the R-TWT SP). In at least one embodiment / aspect / option, the TXOPs mentioned above represent TXOPs obtained by the EDCAF of the AC of the R-TWT TID of the R-TWT SP, or P2P traffic that is considered as delay-sensitive traffic and scheduled with high priority to be transmitted during the R-TWT SP.
[0060] Consider the case where the condition of check 118 is not met. In block 120 of FIG. 5, after the non-AP STA acquires a TXOP during the R-TWT SP, it reserves a TXOP covering the remaining time of the R-TWT SP, shares the TXOP with the AP, and allows the AP to act as the TXOP owner until the end of the R-TWT SP, as shown in block 126.
[0061] When a non-AP STA acquires a channel during an R-TWT SP, it can share a TXOP with the AP after first completing transmission of frames of the R-TWT UL TID of the R-TWT SP or frames of P2P traffic to be transmitted during the R-TWT SP in the buffer.
[0062] In at least one embodiment / mode / option, the non-AP STAs represent member STAs of an R-TWT SP (and / or STAs that support the R-TWT SP). In at least one such embodiment, a member STA of an R-TWT SP can only contend for a channel during an R-TWT SP if it has in its buffer a frame for the R-TWT UL TID of the R-TWT SP or a frame for P2P traffic that is to be transmitted during the R-TWT SP.
[0063] Consider the case where the condition of check 114 is not met and therefore the non-AP STA does not require TXOP time to overlap with the R-TWT SP, execution proceeds to block 116 of FIG. 5, where the non-AP STA reserves a TXOP according to current IEEE 802.11 (e.g., IEEE 802.11ax) rules and then executes blocks 124 and 126 as described above.
[0064] In at least one embodiment / mode / option, a TXOP cannot be reserved that overlaps with an R-TWT SP beyond the scheduled end of the R-TWT SP.
[0065] In at least one embodiment / mode / option, TXOPs that overlap with the R-TWT SP are not limited by the TXOP limit of the primary AC. TXOP time that extends outside the R-TWT SP cannot exceed the TXOP limit of the primary AC.
[0066] In at least one embodiment / mode / option, if the TXOP ends before the scheduled end time of the R-TWT SP, the TXOP time is not limited by the TXOP limit of the primary AC.
[0067] In at least one embodiment / mode / option, a non-AP reserves a TXOP beyond the R-TWT SP (i.e., the non-AP reserves a TXOP after the scheduled end time of the R-TWT SP), and the TXOP cannot exceed the TXOP limit of the primary AC.
[0068] 4.4. AP receiving a shared TXOP from a non-AP STA 6 illustrates an example embodiment 210 in which an AP acquires a shared TXOP from a non-AP STA. The AP acquires 212 a TXOP that is shared by the non-AP STAs associated with the AP. The AP then acts 214 as the TXOP owner during the shared TXOP, an example of which is illustrated in FIG.
[0069] 6, check 216 determines whether the AP has finished transmitting before the shared TXOP has finished. If the condition is not met, the process ends. On the other hand, if the condition is met, the AP shares the TXOP with the non-AP STAs (218) or returns the TXOP to the non-AP STAs, after which the process ends.
[0070] 7 illustrates an example embodiment 310 in which an AP acts as a TXOP owner inside and outside an R-TWT SP, where the TXOP can be obtained by the AP contending for the channel or by the TXOP being shared by another STA.
[0071] In this case, the AP is the TXOP owner (312) and the TXOP overlaps with the R-TWT SP. In check 314, it is determined whether the AP initiates a frame exchange during the R-TWT SP (e.g., sending a DL PPDU requiring BA / ACK, sending a trigger frame for a UL TB PPDU, or sending a MU RTS frame for TXOP sharing). If the condition is met, the AP prioritizes the frame exchange of delay-sensitive traffic (e.g., R-TWT DL / UL TIDs and P2P traffic for all member STAs of the R-TWT SP) (316).
[0072] On the other hand, if the condition is not met and the AP has initiated frame exchange outside the R-TWT SP, the AP follows the IEEE 802.11ax EDCA TXOP during the TXOP time outside the R-TWT SP (318).
[0073] In either case, check whether the TXOP has finished (320). If not, execution returns to check 314, otherwise the process ends. Thus, if the TXOP is acquired due to channel contention of the AP, the TXOP may not be limited by the TXOP limit of the primary AC.
[0074] In at least one embodiment / mode / option, the AP may reserve the TXOP until the end of the R-TWT SP. In at least one embodiment / mode / option, the AP may be required to terminate the TXOP by the end of the R-TWT SP. In at least one embodiment / mode / option, the AP may be required to terminate the TXOP at the end of the R-TWT SP.
[0075] If a TXOP overlaps (or is longer than) an R-TWT SP, the TXOP time outside the R-TWT SP cannot exceed the TXOP limit of the primary AC. If the TXOP limit of the primary AC is 0, the TXOP time outside the R-TWT SP should be equal to the time of one frame exchange of the primary AC.
[0076] In at least one embodiment / mode / option, the TXOP obtained due to channel contention of the AP ends by the scheduled end time of the R-TWT SP, and therefore the TXOP time is not limited by the TXOP limit of the primary AC.
[0077] In at least one embodiment / mode / option, an AP reserves a TXOP beyond the R-TWT SP (i.e., a non-AP reserves a TXOP after the scheduled end time of the R-TWT SP), and the TXOP cannot exceed the TXOP limit of the primary AC.
[0078] 5. Communication diagram example 5.1. Example 1 8 and 9 show an example embodiment 410 of R-TWT scheduling where the AP acquires a TXOP before the scheduled start time of the R-TWT SP. The network topology is shown in FIG.
[0079] AP1 72 is the R-TWT scheduling AP and advertises two R-TWTs, R-TWT1 and R-TWT2. STA1 74 is a member STA of R-TWT1, and STA2 76 is a member STA of R-TWT2. STA3 78 supports R-TWT but is not a member of either R-TWT. STA4 80 does not support R-TWT.
[0080] AP1 performs a backoff 412 to contend for channel access using the EDCAF(s) corresponding to any AC(s) whose buffers are not empty. Once AP1 has acquired channel access, it initiates a MU-RTS / CTS exchange by sending a MU-RTS 414 and receiving a CTS 416 to reserve a TXOP 418.
[0081] As shown in this example, the AP reserves a portion 420 of the TXOP that extends until the end of the scheduled end time of the R-TWT1 SP portion 422. The TXOP duration can exceed the TXOP limit of the TXOP's primary AC. In at least one embodiment / mode / option, the TXOP must end before the scheduled end time of the R-TWT1 SP. In at least one embodiment / mode / option, the TXOP must end before the scheduled end time of the R-TWT1 SP if the TXOP exceeds the TXOP limit of the TXOP's primary AC.
[0082] AP1 follows current EDCA TXOP rules during the TXOP time before the scheduled start time of R-TWT1 SP. For example, AP1 transmits frame 424 from the primary AC and receives an acknowledgment shown as BA 426. In at least one embodiment / mode / option, the frame must not be from the R-TWT1 TID.
[0083] AP1 prioritizes frame exchange for the R-TWT1 TID during the R-TWT1 SP. As shown, AP1 transmits a downlink PPDU 428 carrying a frame for the R-TWT1 TID to STA1 and receives a BA 430. The frame for the R-TWT1 TID is not from the primary AC of the TXOP. It then transmits a BSRP 432 to request buffer status for STA1 and receives a Buffer Status Report (BSR) 434. Note that STA1 only needs to report buffer status for the R-TWT1 UL TID. AP1 then triggers 436 a UL PPDU 438 from STA1 and acknowledges its receipt with a BA 440. STA1 can only transmit frames from the R-TWT UL TID of R-TWT1, which must not be from the primary AC.
[0084] It should be noted that in at least one embodiment / mode / option, AP1 may perform frame exchange with non-member STAs of R-TWT1 during R-TWT1 SP.
[0085] 5.2. Example 2 10 and 11 show an example embodiment 510 of a TXOP reservation where the R-TWT1 SP duration is divided by bandwidth. This figure also shows communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80.
[0086] Compared with the examples shown in Figures 8 and 9, AP1 successfully reserves N*20MHz bandwidth when it initiates MU-RTS / CTS exchange to reserve TXOP, and the TXOP time during R-TWT1 SP should not be longer than the R-TWT1 SP period (the time from the scheduled start time of R-TWT SP1 to the scheduled end time of R-TWT SP1) divided by N.
[0087] Specifically, the figure shows AP1 performing a backoff 512 to contend for channel access rights. Once AP1 has acquired channel access rights, it initiates a MU-RTS / CTS exchange for “N” 20 MHz bandwidths by sending MU-RTS(N*20MHz) 514 and receiving CTS(N*20MHz) 516 to reserve a TXOP 518.
[0088] As shown in this example, AP reserves a TXOP 520 until the end of the scheduled end time of R-TWT1 SP 522. The TXOP duration is allowed to exceed the TXOP limit of the primary AC for the TXOP. AP1 transmits a frame 524 and receives a BA 526 from the primary AC.
[0089] AP1 prioritizes frame exchange for R-TWT1 TID during R-TWT1 SP. As shown, AP1 transmits a downlink PPDU 528 containing a frame for R-TWT1 TID to STA1 and receives a BA 530. The frame for R-TWT1 TID is not from the primary AC of the TXOP. AP1 then transmits a BSRP 532 to request the buffer status of STA1 and receives a Buffer Status Report (BSR) 534. AP1 then triggers 536 a UL PPDU 540 from STA1 and responds to its reception with a BA 542.
[0090] 5.3. Example 3 12 and 13 show an example embodiment 610 of a TXOP reservation according to the TXOP restriction of a primary AC. This figure also shows communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80.
[0091] Compared with the examples shown in Figures 8 and 9, when AP1 initiates a MU-RTS / CTS exchange to reserve a TXOP, the TXOP time cannot exceed the TXOP limit of the primary AC.
[0092] In at least one embodiment / mode / option, AP1 may start frame exchange of traffic of R-TWT1 TID before the scheduled start time of R-TWT1 SP. In addition, AP1 may need to confirm that member STAs of R-TWT1 are awake before starting frame exchange of traffic of R-TWT1 TID. Depending on the embodiment / mode / option, the above content may apply to all examples.
[0093] Specifically, the figure shows AP1 performing a backoff 612 to contend for channel access rights. Once AP1 has acquired channel access rights, it initiates a MU-RTS / CTS exchange by sending a MU-RTS 614 and receiving a CTS 616 to reserve a TXOP 618.
[0094] As shown in this example, the AP reserves a TXOP 618 according to the TXOP restrictions of the primary AC. AP1 transmits a PPDU frame 624 and receives a BA 626 from the primary AC within a normal EDCA TXOP period 620.
[0095] AP1 then prioritizes frame exchange for the R-TWT1 TID during the R-TWT1 SP 622 and sends a downlink PPDU 628 carrying a frame for the R-TWT1 TID to STA1 and receives a BA 630. AP1 then sends a BSRP 632 to request buffer status for STA1 and receives a Buffer Status Report (BSR) 634. AP1 then triggers 636 a UL PPDU 638 from STA1 and responds to its receipt with a BA 640. Note that the R-TWT1 SP has been extended until its scheduled end time 642, which is beyond the scheduled end time of the TXOP 618.
[0096] 5.4. Example 4 14 and 15 show an example embodiment 710 of member STAs of an R-TWT operating in power save mode. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0097] 8 and 9, when AP1 starts MU-RTS / CTS exchange to reserve TXOP, it sends MU-RTS only to STAs that are not in power save mode, which are STA3 and STA4 in this example. When R-TWT1 SP starts, AP1 starts exchanging trigger frames or PS polling frames (or trigger frames / QoS Null frames) to confirm that member STAs of R-TWT1 SP, such as STA1, are awake before starting frame exchange with member STAs of R-TWT1 SP.
[0098] Specifically, the figure shows AP1 performing a backoff 712 to contend for channel access rights, gaining channel access rights, sending an MU-RTS 714 to reserve a TXOP 718, and initiating a MU-RTS / CTS exchange by receiving CTS 716 from STA2 and STA3 since STA1 is in a sleep state.
[0099] AP1 transmits a frame 724 from the primary AC and receives a BA 726 from STA2 and STA3 during a normal EDCA TXOP period 720.
[0100] AP1 then sends a trigger frame 728 during R-TWT1 SP 722 and receives a PS Poll 730 from STA1. AP1 sends a PPDU 732 to STA1 and receives a BA 734. AP1 then sends a BSRP 736 to request STA1's buffer status and receives a Buffer Status Report (BSR) 738. AP1 then sends a trigger frame 740, which triggers a STA1 PPDU 742 to AP1, which AP1 acknowledges with a BA 744.
[0101] 5.5 Example 5 16 and 17 show an example embodiment 810 in which an R-TWT member STA reserves a TXOP over an R-TWT SP prior to the scheduled start time of the R-TWT SP. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0102] Compared with Example 1, STA1 acquires channel access rights after backoff (BO) 812 before the scheduled start time 822 of R-TWT1 SP. STA1 starts RTS / CTS frame exchange to reserve TXOP 818 until the scheduled end time of R-TWT1 SP, and sends RTS 814 and receives CTS 816 from AP1. STA1 can transmit PPDU 824 according to the current EDCA TXOP rules during the TXOP portion 820 before the scheduled start time of R-TWT1 SP. Note that the PPDU 824 and BA response 826 from AP1 extend within R-TWT1-SP 822. In this example, STA1 transmits a frame from the primary AC of the TXOP. STA1 transmits a PPDU indicating sharing the TXOP with AP before the scheduled start time, allowing AP to act as the TXOP owner. Note that this PPDU may need to start transmitting before the scheduled start time of R-TWT1 SP.
[0103] Then, AP1 acts as the TXOP owner and prioritizes frame exchange for R-TWT1 TID during the shared TXOP as shown in Example 1. Specifically, AP1 sends a downlink PPDU 828 carrying a frame for R-TWT1 TID to STA1 and receives a BA 830. AP1 then sends a BSRP 832 to request STA1's buffer status and receives a Buffer Status Report (BSR) 834. AP1 then sends a trigger frame 836, in response to which STA1 sends a PPDU 838, to which AP1 responds with a BA 840.
[0104] In at least one embodiment / mode / option, the TXOP time reserved by STA1 is subject to the TXOP restriction of the primary AC, i.e., STA1 cannot reserve a TXOP until the scheduled end time of R-TWT1 SP due to the TXOP restriction of the primary AC.
[0105] In at least one embodiment / aspect / option, the TXOP time reserved by STA1 does not comply with the TXOP restrictions of the primary AC.
[0106] In at least one embodiment / mode / option, the TXOP time reserved by STA1 must end before the scheduled end time of R-TWT1 SP.
[0107] In at least one embodiment / mode / option, other STAs that are not member STAs of R-TWT1, such as STA2 and STA3, may operate similarly to STA1 as shown.
[0108] In at least one embodiment / mode / option, the PPDU indicating TXOP sharing with the AP may carry a frame similar to the MU-RTS transmit frame defined in IEEE 802.11be, where the frame transmitted in response to the MU-RTS transmit frame is a CTS rather than a BA / ACK as shown.
[0109] In at least one embodiment / mode / option, the frame indicating TXOP sharing with the AP is a CTS frame with the Receiver Address (RA) field set to the AP MAC address (or other special address shared between the AP and all member STAs of the same R-TWT). In this case, the AP does not need to send a frame in response to the CTS frame, and no BA / ACK is required in response to the frame indicating TXOP sharing with the AP as shown.
[0110] In at least one embodiment / mode / option, the frame indicating TXOP sharing with the AP is a Reverse Direction Grant (RDG) frame.
[0111] 5.6. Example 6 18 and 19 show an example embodiment 910 of reserving TXOPs subject to TXOP restriction + R-TWT SP duration. Note that this constraint can apply to APs and other STAs. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0112] Compared with Example 5, in this case, STA2 acquires channel access rights after BO 912 and before the scheduled start time of R-TWT1 SP 918. STA2 starts RTS / CTS frame exchange to reserve TXOP beyond the scheduled end time of R-TWT1 SP, and sends RTS 914 and receives CTS 916 from AP1. However, the TXOP time cannot exceed the TXOP limit of the primary AC + R-TWT1 SP duration. STA2 can send PPDU 924 and receive BA 926 from AP1 according to the current EDCA TXOP rule during the TXOP before the scheduled start time of R-TWT1 SP. For example, STA2 can send a frame from the primary AC of the TXOP. Therefore, STA2 sends a PPDU indicating sharing the TXOP with AP1 before the scheduled start time to allow AP1 to act as the TXOP owner.
[0113] In this case, AP1 acts as the TXOP owner and prioritizes frame exchange for R-TWT1 TID during the shared TXOP as shown in Example 1. Specifically, AP1 transmits a downlink PPDU 928 and receives a BA 930. AP1 then transmits a BSRP 932 to request the buffer status of STA1 and receives a Buffer Status Report (BSR) 934. AP1 then triggers 936 a PPDU 938 from STA1 and responds to its reception with a BA 940.
[0114] After the scheduled end time of the R-TWT1 SP, AP1 transmits an MU-RTS TXS frame 942 to STA2 to return the TXOP to STA2. It can be seen that STA2 becomes the TXOP owner again after transmitting a CTS 944 in response to the MU-RTS TXS frame, and transmits a PPDU 946 to AP1.
[0115] 5.7. Example 7 20 and 21 show an example embodiment 1010 in which the AP finishes the frame exchange for the R-TWT1 TID before the scheduled end time of the R-TWT1 SP. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0116] Compared with Example 5, STA2 acquires channel access rights after BO 1012 and before the scheduled start time 1018 of R-TWT1 SP. STA2 starts RTS / CTS frame exchange, sending RTS 1014 and receiving CTS 1016 from AP1. During the TXOP, STA2 can send PPDU 1024 and receive BA 1026 according to the current EDCA TXOP rules before the scheduled start time of R-TWT1 SP. In this example, STA2 sends a PPDU indicating that it shares the TXOP with AP1, and allows AP1 to act as the TXOP owner.
[0117] Then, AP1 acting as TXOP owner prioritizes frame exchange of R-TWT1 TID during shared TXOP as shown in Example 1. Specifically, AP1 transmits downlink PPDU 1028 and receives BA 1030. Next, AP1 transmits BSRP 1032 to request buffer status of STA1 and receives Buffer Status Report (BSR) 1034. After that, AP1 triggers 1038 PPDU 1036 from STA1 and responds to its reception with BA 1040.
[0118] AP1 completes the frame exchange for the R-TWT1 TID during the R-TWT1 SP by sending an MU-RTS TXS frame 1042 to STA2 to return the TXOP to STA2. It can be seen that STA2 again acts as the TXOP owner after sending a CTS 1044 in response to the MU-RTS TXS frame and sends a PPDU 1046.
[0119] 5.8. Example 8 22 and 23 show an example embodiment 1110 of a non-AP STA sharing a TXOP using MU-RTS TXS frames. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0120] This figure is similar to Example 7, and STA2 acquires channel access rights after BO 1112, during normal EDCA TXOP 1120, and before the scheduled start time of R-TWT1 SP 1118. STA2 starts RTS / CTS frame exchange, sending RTS 1114 and receiving CTS 1116 from AP1. During the TXOP, STA2 can send PPDU 1124 and receive BA 1126 from AP1 according to the current EDCA TXOP rules, before the scheduled start time of R-TWT1 SP 1122. In this example, STA2 sends a PPDU indicating that it shares the TXOP with AP1, and allows AP1 to act as the TXOP owner.
[0121] STA2 transmits an MU-RTS TXS frame 1128 at the scheduled start time of the R-TWT1 SP to share the TXOP with AP1 and allows AP1 to act as the TXOP owner during the R-TWT1 SP 1122. The AP responds with a CTS 1130 to the MU-RTS TXS.
[0122] Next, AP1 performs the operation as described in Example 7, and is found to transmit a downlink PPDU 1132 and receive a BA 1134 from STA1. Next, AP1 transmits a BSRP 1136 to request the buffer status of STA1, and receives a Buffer Status Report (BSR) 1138. After that, AP1 triggers a PPDU 1140 (1142) from STA1 and responds to its reception with a BA 1144.
[0123] AP1 completes the frame exchange for the R-TWT1 TID during the R-TWT1 SP by sending an MU-RTS TXS frame 1146 to STA2 to return the TXOP to STA2. It can be seen that STA2 becomes the TXOP owner again after sending a CTS 1148 in response to the MU-RTS TXS frame, and is sending a PPDU 1150.
[0124] Example 9 24 and 25 show an example EDCA-based R-TWT SP embodiment 1210. As in the previous figures, example communications between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 are shown.
[0125] STA2 acquires channel access rights after BO 1212 and reserves TXOP 1218 until the scheduled end time 1222 of R-TWT1 SP as shown in Example 8. STA2 transmits RTS 1214 and receives CTS 1216 from AP1. STA3 and STA4 respond to CTS 1216 by setting NAV 1228, 1230 according to the RTS / CTS exchange, and STA1 sets only NAV 1224 until the scheduled start time of R-TWT1 SP 1222.
[0126] Next, STA2 transmits PPDU 1226 during the TXOP time and before the scheduled start time of the R-TWT1 SP, and receives BA 1232. After that, STA2 sets NAV 1233 during the R-TWT1 SP.
[0127] AP1 and STA1 start contending for the channel at BO 1234, 1236, respectively. In at least one embodiment / mode / option, AP1 can only use the EDCAF of the AC that corresponds to the R-TWT DL TID of R-TWT1. STA1<R-TWT1のTID、STA1> Only the EDCAF of the AC corresponding to the R-TWT UL TID of the R-TWT can be used.
[0128] When AP1 or STA1 acquires the channel, it can transmit a frame with the TID of R-TWT1. In this example, it can be seen that STA1 acquires the channel and transmits PPDU1238 during BO1234 of AP1. AP1 responds to PPDU1238 with BA1240. AP1 then transmits PPDU1242 to STA1 and receives BA1244.
[0129] Example 10 26 and 27 show an example embodiment 1310 in which an AP uses a CTS frame (with the RA field set to the AP MAC address) to reserve a TXOP and indicate TXOP sharing. As in the previous figures, an example communication is shown between AP1 72, STA1 74, STA2 76, STA3 78, and STA4 80. In this example, STA1 is a member of R-TWT1, STA2 is a member of R-TWT2, STA3 supports R-TWT operation but is not a member of either R-TWT, and STA4 does not support R-TWT.
[0130] During the R-TWT1 SP 1311, all member STAs (AP1 and STA1) of the R-TWT SP and the R-TWT scheduling AP contend for the channel together as shown as BO 1312, 1314. They both acquire the channel during the R-TWT SP and transmit CTS frames 1316 and 1318, respectively.
[0131] As shown, AP1 and STA1 both contend for the channel during the R-TWT1 SP. AP1 uses the EDCAF of the AC corresponding to the R-TWT1 DL TID. STA1 uses the EDCAF of the AC corresponding to STA1's R-TWT1 UL TID.
[0132] As shown, AP1 and STA1 acquire channel access rights at the same time. They transmit CTS to AP frame at the same time. Other STAs that are not member STAs of R-TWT1 set NAV 1320, 1322, 1324 according to the CTS frame, but member STAs of R-TWT1 can ignore the NAV setting. Note that when CTS are transmitted at the same time, the scrambling seeds of CTS are set to the same value. For example, the scrambling seeds of CTS can be based on the R-TWT end time.
[0133] AP1 then becomes the TXOP owner and starts exchanging frames for the R-TWT1 TID during the R-TWT1 SP. Specifically, AP1 sees that it has sent a BSRP 1326 and received a BSR 1328 from STA1. AP1 then sends a trigger frame (TF) 1330, to which STA1 responds with a PPDU 1332, which AP1 acknowledges with a BA 1334. AP1 then sends a PPDU 1336, which STA1 acknowledges with a BA 1338.
[0134] In at least one embodiment / mode / option, only member STAs of R-TWT1 that have frames of R-TWT1's UL R-TWT TID in their buffers may contend for the channel. In at least one embodiment / mode / option, only EDCAFs serving frames of R-TWT1's UL R-TWT TID (and / or P2P traffic scheduled for transmission prioritization during R-TWT1 SP) may perform backoff during R-TWT1 SP.
[0135] In at least one embodiment / mode / option, the R-TWT1 SP is a trigger-based R-TWT SP, and a member STA of the R-TWT1 that gains channel access during the R-TWT1 SP needs to transmit a frame (such as a CTS frame) to share a TXOP with the AP, thus allowing the AP to act as the TXOP owner immediately after gaining channel access. If any member STA of the R-TWT1 transmits or receives a CTS frame to the AP during the R-TWT1 SP, this member STA should not contend for the channel until the end of the R-TWT1 SP.
[0136] In at least one embodiment / mode / option, when the AP obtains a TXOP (including a TXOP shared by a non-AP STA) during R-TWT1, the TXOP can be used to transmit a frame of a DL R-TWT TID of any member STA of R-TWT1. For example, the AP can first transmit a frame of a DL R-TWT TID of a non-primary AC, and then transmit a frame of another DL R-TWT TID of the primary AC. Thus, the AP can decide to transmit any frame of all DL R-TWT TIDs of all member STAs of R-TWT1.
[0137] In at least one embodiment / mode / option, a CTS to AP frame sent by the AP or a member STA must reserve a TXOP until the end of the R-TWT SP.
[0138] Example 11 28 and 29 show an example embodiment 1410 of TXOP recovery when a transmission error occurs during a TXOP. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78 and STA4 80 is shown.
[0139] As in Example 10, during R-TWT1 SP 1412, all member STAs (AP1 and STA1) of the R-TWT SP and the R-TWT scheduling AP contend for the channel together as shown as BO 1414, 1416. They both acquire the channel during the R-TWT SP and transmit CTS 1418 and 1420, respectively. Other STAs set NAV 1422, 1424, and 1426 for the duration of R-TWT1 SP 1412.
[0140] However, if the R-TWT scheduling AP receives or transmits a CTS to AP frame during the R-TWT SP, this AP is the only STA that can contend for the channel during the R-TWT SP. In other words, if a member STA receives or transmits a CTS to AP frame during the R-TWT SP, it cannot contend for the channel until the end of the R-TWT SP.
[0141] AP1 becomes the TXOP owner and sends a BSRP frame 1428 to STA1, but does not receive a response within timeout 1429. STA1 cannot contend for the channel until the end of the R-TWT1 SP.
[0142] After the timeout, AP1 contends for the channel (1430), gets the channel and sends BSRP 1432, to which STA1 responds with BSR 1434. AP1 then sends TF 1436, to which STA1 responds by sending PPDU 1438, to which AP1 responds with BA 1440. AP1 then sends PPDU 1442 to STA1, to which STA1 sends BA 1444.
[0143] Example 12 30 and 31 show an example embodiment 1510 of TXOP recovery when a transmission error occurs during a TXOP. As in the previous figures, communication between AP1 72, STA1 74, STA2 76, STA3 78, and STA4 80 is shown.
[0144] As in Example 11, during R-TWT1 SP 1512, all member STAs (AP1 and STA1) of the R-TWT SP and the R-TWT scheduling AP contend for the channel together as shown as BO 1514, 1516. They both acquire the channel during the R-TWT SP and transmit CTS 1518 and 1520, respectively. Other STAs set NAV 1522, 1524, and 1526 for the duration of R-TWT1 SP 1512.
[0145] If the R-TWT scheduling AP receives or transmits a CTS to AP frame during the R-TWT SP, this AP is the only STA that can contend for the channel during the R-TWT SP. In other words, if a member STA receives or transmits a CTS to AP frame during the R-TWT SP, it cannot contend for the channel until the end of the R-TWT SP.
[0146] Thereafter, if the R-TWT1 SP is EDCA-based (or not trigger-based), the AP and the R-TWT1 member STAs, in this case STA1, contend for the channel again (1528, 1530). During the R-TWT1 SP, the R-TWT1 member STAs can ignore the NAV with the CTS frame and contend for the channel.
[0147] In this figure, we can see that STA1 acquires the channel and sends PPDU1532 to AP1, and AP1 responds with BA1534. AP1 acquires the channel and sends PPDU1536 to STA1, and STA1 responds with BA1538.
[0148] 6. General Scope of the Embodiments Embodiments of the present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and / or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) of the flowchart, 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 a computer readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including, but not limited to, a general purpose computer or a special purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).
[0149] Thus, the blocks of the flowcharts 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 block of the flowcharts described herein and any procedures, algorithms, steps, operations, formulas, or computational expressions, 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.
[0150] Moreover, 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 capable of directing 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 including instruction means for performing the functions specified in the flowchart(s). The computer program instructions may be executed by the computer processor or other programmable processing device to generate a computer-implemented process by causing a series of operational steps to be performed on the computer processor or other programmable processing device, such that the instructions executing on the computer processor or other programmable processing device provide steps for performing the function specified in the flowchart(s) block(s), procedure(s), algorithm(s), step(s), operation(s), mathematical formula(s), or computational expression(s).
[0151] Additionally, the terms "program" or "program executable" as used herein 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.
[0152] Furthermore, as used herein, the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to indicate a device 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.
[0153] From the description herein, it will be understood that the present disclosure encompasses multiple technology implementations, including but not limited to the following.
[0154] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit that performs transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network as an STA that is an independent wireless station (STA) or as an STA in a multi-link device (MLD) and that operates as either a normal STA or an access point (AP) STA that wirelessly communicates 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 circuit and operating on the WLAN; and (c) a non-transitory memory that stores instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing channel access rights for reserving channel resources for frame exchange of delay-sensitive traffic with member STAs of a restricted target wait time (R-TWT) service period (SP), the instructions being: (i) a non-AP STA acquires channel access rights before a scheduled start time of the R-TWT SP; and (ii) a non-AP STA acquires channel access rights before a scheduled start time of the R-TWT SP. (d)(iii) the non-AP STA performs any desired TXOP operation as a TXOP owner prior to the scheduled start time of the R-TWT SP; and (d)(iv) the non-AP STA shares the TXOP with an AP that can act as the TXOP owner until the end of the TXOP or the R-TWT SP.
[0155] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit that operates as either a normal STA or an access point (AP) STA performing transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network as an STA that is an independent wireless station (STA) or as an STA in a multi-link device (MLD) and 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 circuit and operating on 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: (i) a STA operating as an AP or a non-AP STA performs transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network as an independent wireless station (STA) or as an STA in a multi-link device (MLD) and wirelessly communicating with other 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; (d)(ii) an STA operating as an AP or a non-AP STA reserving a TXOP until a scheduled end time of the R-TWT SP; and (d)(iii) an STA operating as an AP or a non-AP STA transmitting frames of R-TWT delay-sensitive traffic from both a primary access category (AC) and a non-primary access category during the R-TWT SP with a higher priority than other frames.
[0156] A method for performing wireless communication in a network, the method comprising: (a) performing transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network between wireless stations (STAs), each of which is an independent wireless station (STA) or a STA in a multilink device (MLD), and which operates as either a normal STA or an access point (AP) STA that communicates wirelessly 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, to perform steps of a wireless communication protocol in reserving channel resources for frame exchange of delay-sensitive traffic with member STAs of a restricted target wait time (R-TWT) service period (SP); (b) a non-AP STA acquires channel access rights prior to a scheduled start time of the R-TWT SP; (c) the non-AP STA reserves a transmit opportunity (TXOP) that overlaps with the R-TWT SP; and (d) the non-AP STA reserves a transmit opportunity (TXOP) that overlaps with the R-TWT SP. (e) performing any desired TXOP operation as the TXOP owner prior to the scheduled start time of the SP; and (f) a non-AP STA sharing the TXOP with the AP, which can act as the TXOP owner until the end of the TXOP or R-TWT SP.
[0157] An apparatus or method of any preceding implementation, wherein a non-AP STA that reserves a TXOP that overlaps with an R-TWT SP ignores the TXOP restrictions of the primary AC.
[0158] The apparatus or method of any preceding implementation, wherein a non-AP STA reserving a TXOP that overlaps with an R-TWT SP reserves the TXOP until the scheduled end time of the R-TWT SP.
[0159] The apparatus or method of any preceding implementation, wherein a non-AP STA reserving a TXOP that overlaps with an R-TWT SP cannot exceed the primary AC's TXOP limit plus the R-TWT SP duration.
[0160] An apparatus or method of any preceding implementation, wherein a non-AP STA reserving a TXOP that overlaps with an R-TWT SP reserves a portion of the TXOP that does not exceed the scheduled end time of the R-TWT SP.
[0161] An apparatus or method of any preceding implementation, wherein a non-AP STA shares a TXOP with an AP before or at the scheduled start time of an R-TWT SP.
[0162] The apparatus or method of any preceding implementation, wherein a non-AP STA cannot share with an AP any portion of a TXOP that exceeds a scheduled end time of an R-TWT SP.
[0163] The apparatus or method of any preceding implementation, wherein an AP acting as a TXOP owner shares the TXOP with a non-AP STA if it has finished transmitting during an R-TWT SP.
[0164] An apparatus or method of any preceding implementation, wherein member STAs of an R-TWT SP cannot contend for the channel until the end of the R-TWT SP after the AP has completed its operation as a TXOP owner.
[0165] An apparatus or method of any preceding implementation, in which a non-AP STA reserving a TXOP that overlaps with an R-TWT SP (a) reserves the TXOP until the scheduled end time of the R-TWT SP, (b) cannot exceed the primary AC's TXOP limit + R-TWT SP duration, and / or (c) reserves a portion of the TXOP that does not exceed the scheduled end time of the R-TWT SP.
[0166] The term "implementation" as used herein is intended to include, without limitation, embodiments, examples, or other forms for practicing the techniques described herein.
[0167] As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly indicates otherwise. Reference to an object in the singular does not mean "the only one" unless expressly stated otherwise, but rather means "one or more."
[0168] In this disclosure, constructs such as "A, B, and / or C" indicate that either A, B, or C, or any combination of items A, B, and C, may be present. Constructs such as "at least one of" followed by a group of listed elements indicate that at least one of the group of elements is present, including possible combinations of any of the listed elements, where applicable.
[0169] References in this disclosure to "an embodiment," "at least one embodiment," or similar embodiment language indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the disclosure. Thus, these references to various embodiments do not necessarily refer to all the same embodiment, or to a specific embodiment that is different from all other embodiments described. References to embodiments should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed devices, systems, or methods.
[0170] As used herein, the term "set" refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.
[0171] Relative terms such as first and second, top and bottom, upper and lower, and left and right in this document are used merely to distinguish one entity or action from another entity or action, and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.
[0172] The terms "comprises, comprising, has, having, includes, including, contains, containing," or any other variations of these terms, are intended to cover non-exclusive inclusions, such that a process, method, article, or apparatus that comprises, has, or includes a list of elements does not include only those elements, but may also include other elements not expressly listed or that are inherent to such process, method, article, or apparatus. An element following "comprises ... a, has ... a, includes ... a, contains ... a" does not exclude, without further constraints, the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, or includes that element.
[0173] As used herein, the terms "approximately", "approximate", "substantially", "essentially" and "about", or any variation thereof, are used to describe and explain slight variations. When used in relation to events or circumstances, these terms can mean that the events or circumstances will definitely occur and that the events or circumstances are highly likely to occur. When used in relation to 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 angle 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.
[0174] In addition, amounts, ratios, and other numerical values may be expressed in range format in this specification. Such range formats are used for convenience and simplification, and include numerical values explicitly specified as the limits of the range, but should be understood to include all individual numerical values or subranges within the range as if each of these numerical values and subranges were explicitly stated. 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 include individual ratios such as about 2, about 3, about 4, and subranges such as about 10 to about 50, about 20 to about 100, etc.
[0175] The term "coupled," as used herein, is defined as connected, but not necessarily in a direct mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in other ways not listed.
[0176] Benefits, advantages, solutions to problems, and any element(s) that cause or make any advantage, advantage, or solution more pronounced are not to be construed as critical, necessary, or essential features or elements of the technology described herein, or of any or all of the claims.
[0177] Also, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may be embodied in less than all features of a single disclosed embodiment.
[0178] The Abstract of the Disclosure is presented 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.
[0179] It is understood that some jurisdictions have a practice of requiring the deletion of one or more portions of the present disclosure after filing. Thus, the reader should refer to the application as of its filing date for the original content of the present disclosure. The deletion of any of the disclosed content should not be construed as an abandonment, forfeiture, or dedication to the public of any subject matter of the application as originally filed.
[0180] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as a separate inventive subject matter.
[0181] 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 embrace other embodiments that may become apparent to those skilled in the art.
[0182] Structural and functional equivalents of elements of the embodiments of the present disclosure known to those skilled in the art are also expressly incorporated herein by reference and are intended to be included in the scope of the claims. Moreover, no element, component, or method step of the present disclosure is 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 explicitly recited using the phrase "means for". No claim element herein should be construed as a "step-plus-function" element unless the element is explicitly recited using the phrase "step for". [Explanation of symbols]
[0183] 310 Example of embodiment 312 AP is the TXOP owner and the TXOP overlaps with R-TWT SP 314 AP initiates frame exchange during R-TWT SP? 316 AP prioritizes frame exchange for latency-sensitive traffic during R-TWT SP 318 AP follows IEEE802.11ax EDCA TXOP during TXOP time outside R-TWT SP 320 TXOP finished?
Claims
1. An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit that performs transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network as an independent wireless station (STA) STA or as an STA in a multi-link device (MLD), and operates as either a normal STA or an access point (AP) STA that wirelessly communicates 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, in reserving channel resources for frame exchange of delay-sensitive traffic with a member STA for a restricted target wait time (R-TWT) service period (SP), (i) a non-AP STA acquires channel access rights before the scheduled start time of the R-TWT SP; (ii) the non-AP STA reserving a transmission opportunity (TXOP) that overlaps with the R-TWT SP; (iii) the non-AP STA performs any desired TXOP operation as a TXOP owner prior to the scheduled start time of the R-TWT SP; (iv) the non-AP STA shares a TXOP with an AP that can act as a TXOP owner until the end of the TXOP or the R-TWT SP; performing steps of a wireless communication protocol for said wireless communication circuit, An apparatus comprising:
2. The non-AP STA that reserves a TXOP that overlaps with the R-TWT SP ignores the TXOP restrictions of the primary AC; 2. The apparatus of claim 1.
3. The non-AP STA reserving a TXOP that overlaps with an R-TWT SP reserves the TXOP until the scheduled end time of the R-TWT SP; 2. The apparatus of claim 1.
4. The non-AP STA reserving a TXOP that overlaps with the R-TWT SP cannot exceed the TXOP limit of the primary AC plus the R-TWT SP duration; 2. The apparatus of claim 1.
5. The non-AP STA reserving a TXOP that overlaps with an R-TWT SP reserves a portion of the TXOP that does not exceed the scheduled end time of the R-TWT SP.
2. The apparatus of claim 1.
6. The non-AP STA shares a TXOP with the AP before or at the scheduled start time of the R-TWT SP; 2. The apparatus of claim 1.
7. The non-AP STA cannot share with the AP any portion of the TXOP that exceeds the scheduled end time of the R-TWT SP; 2. The apparatus of claim 1.
8. The AP acting as a TXOP owner shares the TXOP with non-AP STAs when it finishes transmitting during the R-TWT SP; 2. The apparatus of claim 1.
9. The member STAs of the R-TWT SP cannot contend for the channel until the end of the R-TWT SP after the AP completes its operation as the TXOP owner.
2. The apparatus of claim 1.
10. An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit that performs transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network as an independent wireless station (STA) STA or as an STA in a multi-link device (MLD), and operates as either a normal STA or an access point (AP) STA that wirelessly communicates 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, in reserving channel resources for frame exchange of delay-sensitive traffic with a member STA for a restricted target wait time (R-TWT) service period (SP), (i) a STA acting as an AP or a non-AP STA acquires channel access rights before the scheduled start time of an R-TWT SP; (ii) the STA, operating as an AP or a non-AP STA, reserves a TXOP until the scheduled end time of the R-TWT SP; (iii) the STA, operating as an AP or a non-AP STA, transmits frames of delay-sensitive traffic of the R-TWT with higher priority than other frames from both a primary access category (AC) and a non-primary access category during the R-TWT SP; performing steps of a wireless communication protocol for said wireless communication circuit, An apparatus comprising:
11. The method further includes a STA operating as an AP or a non-AP STA that is not subject to the TXOP restrictions of the primary AC reserving a TXOP that overlaps with the R-TWT SP; 11. The apparatus of claim 10.
12. The TXOP may not exceed the TXOP limit of the primary AC plus the R-TWT SP duration, and the STA may operate as an AP or a non-AP STA to reserve the TXOP.
11. The apparatus of claim 10.
13. The STA, acting as an AP or a non-AP STA reserving a TXOP, does not allow the TXOP to exceed the R-TWT SP duration; 11. The apparatus of claim 10.
14. A STA that reserves a TXOP that overlaps with an R-TWT SP shall share the TXOP with an AP on or before the scheduled start time of the R-TWT SP and allow the AP to act as the TXOP owner during the TXOP; 11. The apparatus of claim 10.
15. The STA, operating as an AP or a non-AP STA, extends the TXOP after the scheduled end time of the R-TWT SP, but does not allow the TXOP duration to exceed the TXOP limit of the primary AC; 11. The apparatus of claim 10.
16. 1. A method for conducting wireless communication in a network, comprising: (a) performing steps of a wireless communication protocol in performing transmission of frames between a medium access control (MAC) layer of an IEEE 802.11 network between wireless stations (STAs), each of which is an independent wireless station (STA) or a STA in a multi-link device (MLD), and which operate as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access / 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, to reserve channel resources for frame exchange of delay-sensitive traffic with member STAs in a restricted target wait time (R-TWT) service period (SP); (b) a non-AP STA acquires channel access rights before the scheduled start time of the R-TWT SP; (c) the non-AP STA reserving a transmission opportunity (TXOP) that overlaps with the R-TWT SP; (d) the non-AP STA performs any desired TXOP operation as a TXOP owner prior to the scheduled start time of the R-TWT SP; (e) the non-AP STA shares a TXOP with an AP that can act as a TXOP owner until the end of the TXOP or the R-TWT SP; The method according to claim 1, further comprising:
17. The non-AP STA that reserves a TXOP that overlaps with the R-TWT SP ignores the TXOP restrictions of the primary AC; 17. The method of claim 16.
18. The non-AP STA reserving a TXOP that overlaps with an R-TWT SP (a) reserves the TXOP until the scheduled end time of the R-TWT SP, (b) cannot exceed the TXOP limit of the primary AC plus the R-TWT SP duration, and / or (c) reserves a portion of the TXOP that does not exceed the scheduled end time of the R-TWT SP; 17. The method of claim 16.
19. The non-AP STA shares a TXOP with the AP before or at the scheduled start time of the R-TWT SP; 17. The method of claim 16.
20. The member STAs of the R-TWT SP cannot contend for the channel until the end of the R-TWT SP after the AP completes its operation as a TXOP owner; 17. The method of claim 16.