Coordinating station in a single BSS with shared TXOP in the frequency domain

Abstract

A wireless local area network (WLAN) protocol that allows a transmit opportunity (TXOP) holder to share the TXOP with other stations working in concert. The intention to share a TXOP communicates to other stations that the TXOP is available for sharing and notifies the access point (AP) of stations willing to participate in the TXOP. When a TXOP is in place, stations can access the channel simultaneously using different frequency domains for a specified duration, thereby improving TXOP utilization and increasing efficiency.

Description

[0001] This application claims priority to and the benefit of U.S. patent application serial number 17 / 141,840, filed on January 5, 2021, which is incorporated herein by reference in its entirety, and which claims priority to and the benefit of U.S. provisional patent application serial number 63 / 043,217, filed on June 24, 2020, which is incorporated herein by reference in its entirety.

[0002] Statement Regarding Federally Funded Research and Development

[0003] not applicable

[0004] Computer Program Appendix Incorporation by Reference

[0005] not applicable

[0006] Notice of Copyrighted Material

[0007] Portions of material in this patent document are protected by copyright under the copyright laws of the United States and other countries. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the publicly available U.S. Patent and Trademark Office file or records, but otherwise reserves all copyrights whatsoever. The copyright owner hereby does not waive any rights to have this patent document maintained in secrecy, including but not limited to its rights pursuant to 37 CFR §1.14. Technical Field

[0008] The technology of the present disclosure relates generally to wireless network communications, and more particularly to sharing transmit opportunities (TXOPs) with other stations in a single basic service set (BSS) scenario in the frequency domain. Background Art

[0009] With the rapid development of new applications and the increasing number of smart devices accessing the internet via Wi-Fi, the use of Wi-Fi networks is rapidly increasing, and the demands of Wi-Fi users are also increasing. To address these demands, several goals of ongoing communication network design include high throughput, low latency, and high efficiency. Some applications, such as real-time applications (RTA) (e.g., data acquisition and gaming), transmit highly latency-sensitive communication data, thus requiring low-latency packet communication.

[0010] However, current Wi-Fi network protocols do not aim to minimize latency for these time-sensitive applications.

[0011] Therefore, there is a need for an apparatus and method for reducing RTA packet delay. The present disclosure satisfies this need and provides additional benefits over prior art techniques. Summary of the Invention

[0012] By performing the following steps, a station (STA) can share its transmit opportunity (TXOP) in the frequency domain with other STAs in a single BSS scenario in a wireless LAN network. It exchanges messages with an access point (AP) to notify and / or obtain permission to share its transmit opportunity (TXOP) with other STAs. Upon gaining access to a channel, it exchanges information with other STAs indicating that the upcoming TXOP is available for sharing, and identifies non-AP TXOP participant STAs based on received responses.

[0013] A message is sent to non-AP shared TXOP participant STAs willing to join the next shared TXOP, along with information about resource units (RUs) that each non-AP shared TXOP participant STA should use to send uplink (UL) data during channel access.

[0014] Other aspects of the technology described herein will be presented in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The technology described herein will be more fully understood with reference to the following drawings, which are provided for illustration purposes only:

[0016] FIG1 is a diagram illustrating slotted transmission of DL OFDMA MIMO transmission in IEEE 802.11.

[0017] FIG. 2 is a diagram illustrating slotted transmission of UL OFDMA MIMO transmission in IEEE 802.11.

[0018] FIG3 is a flow chart of a conventional UL OFDMA MIMO transmission.

[0019] FIG4 is a diagram showing data fields in a data frame format in a conventional WLAN system.

[0020] FIG5 is a diagram showing a data field of an ACK frame format in a conventional WLAN system.

[0021] FIG6 is a communication sequence diagram of conventional retransmission in CSMA / CA, in which the backoff time is increased due to the retransmission.

[0022] FIG7 is a communication sequence diagram in which a packet is discarded after the number of retransmissions exceeds the retry limit.

[0023] FIG8 is a communication sequence diagram of a conventional downlink multi-user transmission using OFDMA.

[0024] FIG9 is a communication sequence diagram of a conventional uplink multi-user transmission using OFDMA.

[0025] Figure 10 is a block diagram of station (STA) hardware in accordance with at least one embodiment of the present disclosure.

[0026] Figure 11 is an example of a network topology diagram according to at least one embodiment of the present disclosure.

[0027] Figure 12 is a communication sequence diagram of a proposed shared TXOP protocol according to at least one embodiment of the present disclosure, where the shared TXOP protocol is initiated by a non-AP TXOP holder STA.

[0028] Figure 13 This is a general overview of protocol design according to at least one embodiment of the present disclosure.

[0029] Figure 14 is a communication sequence diagram of shared information exchange in a shared TXOP setup phase in accordance with at least one embodiment of the present disclosure.

[0030] Figure 15 is a flow chart of a shared TXOP setup phase handled by an AP in accordance with at least one embodiment of the present disclosure.

[0031] Figure 16 is a flow chart of a shared TXOP setup phase processed at the non-AP STA level in accordance with at least one embodiment of the present disclosure.

[0032] Figure 17 is a communication sequence diagram of a shared TXOP initialization phase without an AP coordinator in accordance with at least one embodiment of the present disclosure.

[0033] Figure 18 is a flow chart of a shared TXOP initialization phase handled by a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0034] Figure 19 is a flow chart of a shared TXOP initialization phase handled by a non-AP shared TXOP participant STA in accordance with at least one embodiment of the present disclosure.

[0035] Figure 20 The present invention is a communication sequence diagram of a TXOP scheduling and access phase according to at least one embodiment of the present disclosure, wherein a unicast TXOP access request trigger frame is used to schedule TXOP participants STAs that are shared by non-APs.

[0036] Figure 21The present invention is a communication sequence diagram of a TXOP scheduling and access phase according to at least one embodiment of the present disclosure, wherein the TXOP is scheduled by broadcasting a TXOP access request trigger frame for all non-AP shared TXOP participant STAs.

[0037] Figure 22 is a communication sequence diagram of a TXOP scheduling and access phase by allowing random access to a non-AP shared TXOP participant STA in accordance with at least one embodiment of the present disclosure.

[0038] Figure 23A and Figure 23B is a flow chart of a TXOP scheduling and access phase handled by a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0039] Figure 24A and Figure 24B is a flow chart of a TXOP scheduling and access phase handled by a non-AP shared TXOP participant STA in accordance with at least one embodiment of the present disclosure.

[0040] Figure 25 is a communication sequence diagram of a shared TXOP initialization phase in a scenario where an AP acts as a coordinator according to at least one embodiment of the present disclosure.

[0041] Figure 26 is a flow chart of a shared TXOP initialization phase handled by a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0042] Figure 27 is a flow chart of a shared TXOP initialization phase handled by an AP in accordance with at least one embodiment of the present disclosure.

[0043] Figure 28 is a communication sequence diagram of the TXOP scheduling and access phases in a scenario where the AP acts as a coordinator according to at least one embodiment of the present disclosure.

[0044] Figure 29 is a communication sequence diagram of the TXOP scheduling and access phases in a scenario where the AP acts as a coordinator according to at least one embodiment of the present disclosure.

[0045] Figure 30 is a communication sequence diagram of the TXOP scheduling and access phases in a scenario where the AP acts as a coordinator according to at least one embodiment of the present disclosure.

[0046] Figure 31 is a communication sequence diagram of the TXOP scheduling and access phases in a scenario where the AP acts as a coordinator according to at least one embodiment of the present disclosure.

[0047] Figure 32A and Figure 32B is a flow chart of the TXOP scheduling and access phases handled by an AP (with the AP as a coordinator) with random access in accordance with at least one embodiment of the present disclosure.

[0048] Figure 33A and Figure 33B is a flow chart of a TXOP scheduling and access phase with random access handled by a non-AP TXOP holder STA (with the AP as a coordinator) in accordance with at least one embodiment of the present disclosure.

[0049] Figure 34A and Figure 34B is a flow chart of a TXOP scheduling and access phase with random access handled by a non-AP shared TXOP participant STA (with the AP as a coordinator) in accordance with at least one embodiment of the present disclosure.

[0050] Figure 35 is a communication sequence diagram of a shared TXOP setup phase according to at least one embodiment of the present disclosure, the shared TXOP setup phase including a sharing proposal / request setup subphase and a TXOP holder configuration setup subphase.

[0051] Figure 36 Flowchart of the sharing proposal / request setup sub-phase processed by the AP. According to at least one embodiment of the present disclosure, after the sharing proposal / request setup sub-phase begins.

[0052] Figure 37 is a flow chart of a sharing proposal / request setup sub-phase processed by a non-AP STA in accordance with at least one embodiment of the present disclosure.

[0053] Figure 38 is a flow chart of a TXOP holder configuration setup sub-phase processed by an AP in accordance with at least one embodiment of the present disclosure.

[0054] Figure 39 is a flow chart of a TXOP holder configuration setup sub-phase processed by a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0055] Figure 40 is a communication sequence diagram of TXOP scheduling and access phases in a semi-statistical scenario without an AP as a coordinator according to at least one embodiment of the present disclosure.

[0056] Figure 41 The present invention is a flowchart of the TXOP scheduling and access phases handled by non-AP TXOP holder STAs in a semi-statistical scenario without an AP as a coordinator according to at least one embodiment of the present disclosure.

[0057] Figure 42 The present invention is a flowchart of the TXOP scheduling and access phases handled by non-AP shared TXOP participant STAs in a semi-statistical scenario without an AP as a coordinator according to at least one embodiment of the present disclosure.

[0058] Figure 43 is a communication sequence diagram of TXOP scheduling and access phases in a semi-statistical scenario with an AP as a coordinator according to at least one embodiment of the present disclosure.

[0059] Figure 44 The present invention is a flowchart of the TXOP scheduling and access phases handled by non-AP TXOP holder STAs in a semi-statistical scenario with an AP as a coordinator according to at least one embodiment of the present disclosure.

[0060] Figure 45 The present invention is a flowchart of the TXOP scheduling and access phases handled by the AP in a semi-statistical scenario with the AP acting as a coordinator according to at least one embodiment of the present disclosure.

[0061] Figure 46 is a diagram of the data field of a STA TXOP shareability element in accordance with at least one embodiment of the present disclosure.

[0062] Figure 47 is a data field diagram of a STA information field according to at least one embodiment of the present disclosure.

[0063] Figure 48 is a diagram of data fields of a sharing proposal / request frame format in accordance with at least one embodiment of the present disclosure.

[0064] Figure 49 is a data field diagram of a STA sharing proposal / request information field format having the following fields according to at least one embodiment of the present disclosure.

[0065] Figure 50 is a diagram of data fields of a frame format of a MU-RTS shared frame according to at least one embodiment of the present disclosure.

[0066] Figure 51 is a diagram of a data field of a CTS shared frame according to at least one embodiment of the present disclosure.

[0067] Figure 52 is a data field diagram for a TXOP random access request trigger according to at least one embodiment of the present disclosure.

[0068] Figure 53 FIG. 4 is a diagram of data fields of a unicast TXOP access request trigger frame format according to at least one embodiment of the present disclosure.

[0069] Figure 54FIG. 4 is a diagram of data fields of a broadcast TXOP access request trigger frame format according to at least one embodiment of the present disclosure.

[0070] Figure 55 is a diagram of the data field of a CTS-to-self sharing frame according to at least one embodiment of the present disclosure.

[0071] Figure 56 is a diagram of the data field of a TXOP participant announcement frame in accordance with at least one embodiment of the present disclosure.

[0072] Figure 57 is a data field diagram of a STA TXOP participant field in accordance with at least one embodiment of the present disclosure.

[0073] Figure 58 is a diagram of data fields of a TXOP access scheduler trigger frame format according to at least one embodiment of the present disclosure.

[0074] Figure 59 is a diagram of data fields of a TXOP priority trigger frame format according to at least one embodiment of the present disclosure.

[0075] Figure 60 is a diagram of a data field of a TXOP holder configuration frame format in accordance with at least one embodiment of the present disclosure.

[0076] Figure 61 FIG. 4 is a diagram of a data field of a frame format of a STA TXOP access allocation field according to at least one embodiment of the present disclosure.

[0077] Figure 62 1 is a data field diagram of a priority subfield of an allocation control information subfield according to at least one embodiment of the present disclosure, the priority subfield indicating the priority of traffic of a TXOP sharing participant STA.

[0078] Figure 63 is a diagram of data fields of a TXOP access configuration frame format according to at least one embodiment of the present disclosure.

[0079] Figure 64 FIG. 4 is a diagram of a data field of a TXOP sharing request trigger frame according to at least one embodiment of the present disclosure.

[0080] Figure 65 FIG. 4 is a diagram of data fields of a TXOP sharing response trigger frame format according to at least one embodiment of the present disclosure.

[0081] Figure 66 is a block diagram of station (STA) hardware according to at least one embodiment of the present disclosure, where the stations belong to a multi-link device (MLD) configuration. DETAILED DESCRIPTION

[0082] 1. Introduction

[0083] To improve the performance of WLANs, especially in the 2.4 GHz and 5 GHz bands, many 802.11 amendments were proposed. Numerous data rate improvements were set in the PHY layer, such as increasing bandwidth from 20 MHz to 160 MHz, new modulation and coding schemes, and improved MIMO systems.

[0084] To reduce transmission overhead and thus increase data throughput, other MAC layer improvements are introduced. For example, this is achieved by reducing the inter-frame interval, aggregating and fragmenting packets, and applying power consumption protocols to alternate between STAs' awake and dormant states to save STA power.

[0085] IEEE 802.11ax introduces Orthogonal Frequency Division Multiple Access (OFDMA) technology, in which adjacent subcarriers are grouped into resource units (RUs). This technology maximizes the transmission rate by allocating RUs for multi-user (MU) data transmission on uplink (UL) and downlink (DL).

[0086] The use of OFDMA allows many users to utilize the same time resources simultaneously by dividing the frequency domain among them. Since more users can be scheduled simultaneously, this technology improves resource utilization and reduces latency.

[0087] However, current 802.11 technologies initiate uplink (UL) multi-user (MU) transmissions at the AP level. This means that even if non-AP STAs need to send UL data to the AP and sense that channel access is available, they cannot simply start transmitting. Non-AP STAs must wait until they receive a trigger frame from their associated AP before they can begin UL data transmission.

[0088] This disclosure describes a shared TXOP protocol initiated at the non-AP STA level for MU UL OFDMA transmission. In this disclosure, a non-AP STA that has gained channel access can initiate a shared TXOP and allocate different channel resources to other non-AP STAs for MU UL data transmission.

[0089] WLAN Characteristics Affecting Packet Delay

[0090] 2.1.1. Channel Access and Delay Tolerance

[0091] Both contention-based access and contention-free access are allowed in WLAN devices. Contention-based access requires the device to sense the channel and contend each time if the channel is busy in order to gain access to the channel. This need for contention introduces additional transmission delay, but is necessary to provide proper collision avoidance. Contention-free channel access allows the AP to gain access to the channel without contention. This is allowed in hybrid controlled channel access, where channel access coordination is achieved by using a shorter interframe space equal to PIFs (PCF interframe space) compared to the DIFS (distributed interframe space) used by other STAs. Although contention-free access seems to be a reasonable solution to avoid contention delays, it is not widely deployed and most Wi-Fi devices use contention-based access.

[0092] For a STA to access a channel, it must sense the channel and determine that the channel is not busy. A channel is considered busy when any of the following conditions are detected: (1) the STA detects the preamble of a frame, and the channel is considered busy for the length of the detected frame; (2) the STA detects in-band energy greater than the minimum sensitivity of 20dB; or (3) the STA detects that the channel is actually busy by reading the network allocation vector (NAV) of the detected frame. It should be noted that NAV is a virtual carrier sensing mechanism used with wireless network protocols, where NAV represents the number of microseconds (up to 32,767 microseconds) that the transmitting STA intends to keep the medium busy.

[0093] 802.11ax introduces two NAVs to avoid potential conflicts due to incorrect NAV timer resets. One NAV is used for BSS STAs, and the other is used for non-BSS STAs. STAs maintain these two NAVs separately.

[0094] Like all traditional 802.11 WLAN devices, 802.11ax uses CSMA / CA for channel access. For an AP to send a trigger frame for UL MIMO transmission, it must first contend for channel access. To enable the AP to win (acquire) channel access before any STA within its BSS, 802.11ax introduces a second set of EDCA specifically for 802.11ax devices. This allows legacy non-802.11ax devices to freely access the channel using EDCA and increases the AP's chances of gaining access to the channel in order to schedule UL or DL OFDMA MIMO data transmissions.

[0095] 2.1.2. Multi-user sending and receiving

[0096] 802.11 WLAN devices allow the use of MIMO antennas for transmission and reception, as well as OFDMA channel access. IEEE 802.11ax supports multi-user transmission in both uplink and downlink.

[0097] The use of multi-user communications allows multi-stream transmission to one or more users via up to 8 streams, such as in SU-MIMO DL in 802.11ac, or multi-user transmission to more than one user via MU-MIMO DL transmission as defined in 802.11ac. This allows the AP to allocate one or more streams to STAs in its BSS.

[0098] With the use of wide channels up to 160MHz for data transmission, the channel is expected to be interference-frequency selective, with some frequencies experiencing different levels of interference than others, which affects the expected achievable rate and degrades performance. To address this issue, 802.11ax introduces OFDMA, in which adjacent subcarriers are grouped into resource units (RUs). These RUs can be assigned to different receivers to maximize the transmission rate. This scheduling can result in maximizing the SINR at each receiver, allowing for higher modulation and coding schemes (MCS), thereby improving the achieved throughput.

[0099] OFDMA allows many users to utilize resources simultaneously by dividing the frequency domain among many users. This improves resource utilization and reduces latency because more users can be scheduled simultaneously. In addition, by allowing STAs with small amounts of data to occupy narrower RUs, scheduling efficiency is improved and allows for improved resource allocation between applications that require channel access to transmit small amounts of data, thereby helping to reduce channel access time and the overhead required for frame headers and preambles.

[0100] Combining OFDMA with MIMO transmission improves OFDMA efficiency. Depending on the STA's MIMO capabilities, a RU can be used to transmit multiple spatial streams to a STA. Furthermore, a single RU can be shared by more than one STA, each with one or more spatial streams, depending on the STA's MIMO capabilities. Packing more STAs into the same resource reduces latency between the STA and the AP.

[0101] Figure 1 illustrates an example of a DL OFDMA MIMO transmission. The AP is sending a PHY preamble to all STAs, specifying the frequency / RU mapping and RU allocation for the STA. Following the preamble, the AP DL data is transmitted using the specific RU allocation for a given STA. Multi-user ACK transmission should be synchronized with the reception of the DL data frame, where the STA begins transmission a short interframe space (SIFS) after receiving the DL trigger frame.

[0102] Figure 2 is an example of UL OFDMA MIMO transmission, where the AP is sending a trigger frame to all STAs. The trigger frame contains the frequency, RU mapping, and RU allocation for the STA. UL MIMO transmission should be synchronized with the reception of this frame, where the STA starts transmitting SIFS after receiving the DL trigger frame.

[0103] 2.1.4. Resend

[0104] Figure 3 illustrates the use of CSMA / CA in WLAN systems, according to IEEE 802.11, to allow STAs to gain channel access for packet transmission and retransmission. In a CSMA / CA system, before each transmission and retransmission, the STA must sense the channel and set a backoff time to contend for channel access. The backoff time is determined by a uniform random variable between 0 and the size of the contention window. After the STA waits for the backoff time and senses that the channel is idle, it transmits the packet. If the STA does not receive an ACK before the timeout, a retransmission is required. Otherwise, the transmission is successful. When a retransmission is required, the STA checks the number of retransmissions for the packet. If the number of retransmissions exceeds the retry limit, the packet is discarded and no retransmission is scheduled. Otherwise, a retransmission is scheduled, and another backoff time is required to contend for retransmission channel access. If the contention window size has not reached the upper limit, the STA increases the contention window. The STA sets another backoff time based on the new contention window size. The STA waits for the backoff time to retransmit, and so on.

[0105] Figure 4 illustrates the data frame format and its fields in a conventional WLAN system. The Frame Control field indicates the frame type. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The Sequence Control field contains the fragment number and sequence number of the packet.

[0106] Figure 5 illustrates the ACK frame format and its fields in a conventional WLAN system. The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame.

[0107] Figure 6 illustrates an example of retransmission in CSMA / CA, where the backoff time is increased due to retransmission. The data packet frame and ACK frame use the formats shown in Figures 4 and 5, respectively. After the transmitter sends the initial transmission of the packet, it does not receive an ACK before the timeout. Therefore, it sets another backoff time, so that the size of the contention window is n time slots. After waiting for this backoff time, the transmitter STA retransmits the packet for the first time. However, in this example, this retransmission also fails. The transmitter STA needs to retransmit the packet and set the backoff time again to compete for channel access. This time, due to the retransmission, the size of the contention window is doubled, that is, 2*n time slots. The expected backoff time is also doubled according to the contention window size. The second retransmission is successful because it receives an ACK before the timeout.

[0108] Figure 7 illustrates an example of packet discarding after the number of retransmissions exceeds the retry limit. The data packet frame and ACK frame use the formats shown in Figures 4 and 5, respectively. As shown in the figure, after the initial transmission of the packet fails, the transmitter STA retransmits the packet multiple times. However, none of the retransmissions are successful. After N retransmissions, the number of retransmissions exceeds the retry limit. The transmitter STA stops retransmitting the packet, and the packet is discarded.

[0109] Figure 8 illustrates an example of a downlink multi-user transmission using OFDMA. A transmitter, AP, sends a data packet to receivers 1, 2, 3, and 4. The data packet may use the HE MU PPDU format. After completing the initial transmission, the AP sends a Multi-User Block ACK Request (MU-BAR) to all receivers. The receivers then send a Block ACK (BA) back to the AP. Based on the contents of the BA, the AP decides to retransmit the packet to receivers 1, 3, and 4. The AP contends for the channel and waits for the backoff time. The first retransmission occurs after the AP gains channel access.

[0110] Figure 9 shows an example of an uplink multi-user transmission using OFDMA. The AP first sends a trigger frame to all transmitters 1, 2, 3, and 4. The transmitters receive the trigger frame and begin initial transmission using the channel resources allocated by the trigger frame. Data packets can use the HE TB PPDU format. The AP receives data packets from the transmitters and sends a BA frame to report correct reception of the transmission. In this example, only the packet from transmitter 3 is correctly received. Retransmissions need to be scheduled for transmitters 1, 2, and 4. The AP contends for the channel and waits for a backoff time to gain channel access. Retransmissions are then performed at the same time as the initial transmission.

[0111] UL OFDMA Random Access

[0112] 802.11ax introduces UL OFDM random access for UL transmissions when the AP does not know which STA has data to send, or when an unassociated STA wants to transmit data. A trigger frame can allocate a number of RUs for random UL channel access. When the AP allocates specific RUs for uplink random access, STAs use the OFDMA backoff procedure to determine whether they will access the random access channel. This is achieved by selecting a backoff random value and comparing it to the number of RUs allocated for random access. If the current backoff random value is less than the number of RUs, the STA randomly accesses one of the RUs allocated for random access. Random access is expected to improve the efficiency of short packet transmission.

[0113] 3. Problem Statement

[0114] For MU UL transmissions, previous technologies such as 802.11n / ac implemented a request-to-send / clear-to-send (RTS / CTS) or extended RTS / CTS in the channel access scheme to help avoid collisions. However, this scheme only allows one user to occupy the channel at a time. In addition, the overhead of exchanging RTS / CTS frames introduces significant latency.

[0115] In comparison, 802.11ax technology implements an OFDMA scheme, which allows different users to access the channel simultaneously. This improves channel utilization efficiency and reduces average latency. However, current 802.11ax technology relies on the AP to initiate UL transmissions for shared TXOPs. Therefore, even if a non-AP STA senses that the channel is idle and has data to send to the AP, it must wait until it receives a trigger frame from the associated AP before it can begin UL data transmission. Furthermore, current 802.11ax technology must rely on the AP to schedule and allocate available channel resources between the non-AP STA that has acquired the channel and other non-AP STAs. In this situation, the introduction of OFDMA introduces several issues, including low channel utilization efficiency and increased latency.

[0116] 4. Contributions of this Disclosure

[0117] This disclosure proposes a novel solution that enables multi-user UL transmission within a shared TXOP in a single BSS. The phrase "shared TXOP" used herein means that channel access can be shared among different users during a TXOP. More specifically, when a non-AP STA acquires a channel, it can initiate a multi-user UL transmission without waiting for a trigger frame from the AP. This non-AP STA acts as a TXOP holder STA, initiating shared TXOP access and scheduling channel resources for other non-AP STAs joining the next shared TXOP. The studied scenario focuses on the case of a single BSS. The proposed solution improves channel utilization efficiency and reduces latency on the non-AP STA side, thereby enhancing flexibility and RTA performance on the non-AP STA side.

[0118] 5. Non-AP STA hardware settings

[0119] Figure 10 The diagram illustrates an example embodiment 10 of a non-AP STA having external I / O 14 in bus 16 into station circuitry 12 having a CPU 18 and RAM 20 for executing wireless network communication protocols and for storing data. The station hardware of the present disclosure may be configured to communicate in a variety of ways, which may include bidirectional and / or unidirectional communication.

[0120] The host 12 houses at least one modem 22 that supports communications, coupled to at least one RF module 24, 28, which is connected to one or more antennas 26a, 26b, 26c-26n, and 29, for communication, for example, in the sub-6 GHz frequency band (e.g., 2.4, 5, 6 GHz) and / or via millimeter wavelengths (mmW). In the example shown, the RF antenna 29 is an omnidirectional antenna. For example, the RF module 24 is shown as having multiple antennas to support beamforming for transmission and reception in this frequency band. In this way, STAs can use multiple sets of beam patterns to transmit signals. It should be appreciated that while the example illustrates sub-6 GHz communications, the teachings of the present disclosure can support any desired frequency band. It should also be noted that multiple STAs can be grouped (aggregated) in any desired configuration without departing from the teachings of the present disclosure.

[0121] The bus 14 allows various devices to be connected to the CPU, such as sensors, actuators, etc. Instructions from the memory 20 are executed on the processor 18 to execute a program that implements the communication protocol, the execution of which allows the STA to function as an access point (AP) station or a non-AP (regular) station (STA). It should also be appreciated that the program is configured to operate in different modes (source, sender, intermediate, destination, receiver, first AP, other AP, non-AP station associated with the first AP, non-AP TXOP holder station, non-AP TXOP participant station, non-AP TXOP non-participant station, station associated with other APs, coordinator, coordinator, etc.) depending on the role it plays in the current communication context.

[0122] It should be appreciated that the present disclosure can be configured with multiple modems 22, each coupled to any arbitrary number of RF circuits. Generally, using a greater number of RF circuits results in wider coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and antennas used is determined by the hardware constraints of a particular device. When a STA determines that it does not need to communicate with a neighboring STA, some of the RF circuits and antennas may be disabled.

[0123] Figure 66 The diagram illustrates Figure 10 A variation of this embodiment 1370 is provided in which the wireless communication station belongs to a multi-link device (MLD) hardware configuration. Each STA within the MLD operates on a link of a different frequency. Each station 10' may be configured as follows: Figure 10 As shown in FIG, each station 10' has a CPU, RAM, a modem, an RF circuit, and one or more antennas. As can be seen from the figure, each of the n stations shown provides a different link (eg, link 1, link 2 to link n are shown).

[0124] The MLD also includes circuitry 1372, an MLD management entity, having at least one processor (CPU) 1374 and memory 1376. Circuitry 1372 provides external I / O for accessing MLD applications and implementing communication protocols at the MLD level. The MLD is configured to assign tasks to and collect information from each of its subordinate STAs, and to share information among its subordinate STAs.

[0125] It should also be appreciated that each STA of an MLD need not have its own processor and memory. In at least one embodiment, one or more stations within an MLD may share a processor and memory among themselves, or share the processor and memory of the MLD circuitry. Thus, the present disclosure contemplates many possible arrangements for communicating over multiple links within an MLD.

[0126] 6. Topology and scenario description

[0127] 6.1. Topology under study

[0128] Figure 11 An example embodiment 30 of a scenario (topology) for a single WLAN BSS 32 scenario is illustrated, as an example and not by way of limitation, in the following operational discussion of the present disclosure. This scenario provides a topology to help explain the operations described herein without limiting the use of the teachings herein to any particular network scenario. The single WLAN BSS 32 consists of one AP 34 and multiple stations, illustrated as STA1 36, STA2 38, and STA3 40. STA3 is a non-AP TXOP holder STA that has acquired a channel and is willing to share the next (subsequent) TXOP with other non-AP STAs. The other two STAs are non-AP shared TXOP participant STAs that have not acquired a channel but are willing to join the next TXOP shared by the TXOP holder STA. This example serves to illustrate the proposed solution, which can be applied to any WLAN topology without limitation.

[0129] 6.2. Scenario Description

[0130] The BSS studied consists of an AP and multiple non-AP STAs. Each non-AP STA has packets that can be generated periodically or frequently for transmission to the AP. This disclosure focuses on uplink (UL) OFDMA transmissions, for which latency is a critical issue due to the more complex scheduling required between each non-AP STA and the AP.

[0131] In 802.11ax technology, multiple STAs can simultaneously transmit UL data sequences within a shared TXOP, which improves TXOP utilization efficiency. In 802.11ax, the AP can initiate UL data transmission. The AP typically sends a trigger frame (e.g., a Buffer Status Report Poll (BSRP)) to non-AP STAs to inquire about their buffer status and their traffic priority. Upon receiving a response frame (e.g., a Buffer Status Report (BSR)) from these non-AP STAs, the AP sends another trigger frame (e.g., a Basic Trigger) with resource allocation information to these non-AP STAs for them to use in transmitting UL data sequences. In existing technologies, AP-initiated TXOPs cannot support the dynamic needs of non-AP STAs, especially if these non-AP STAs have RTA (Real-Time Application) packets to transmit. Although RTA packets are generally small, they require fast (low latency) transmission.

[0132] This disclosure provides a new solution from the perspective of non-AP STAs. Specifically, for non-AP STAs that sense channel availability and have packets to send immediately to the AP, a shared TXOP solution is enabled for those STAs that gain channel access and are willing to share channel access with other STAs in the following TXOP. This shared TXOP solution effectively reduces latency by reducing backoff delay and providing more efficient channel utilization for STAs competing for channel access.

[0133] More specifically, the present disclosure has the following features. Once any non-AP STA obtains channel access, it can immediately initiate a shared TXOP. This non-AP STA is referred to herein as a non-AP TXOP holder STA. A non-AP STA willing to participate in a shared TXOP is referred to herein as a non-AP shared TXOP participant STA. The non-AP TXOP holder STA shares the TXOP duration in the frequency domain with other non-AP shared TXOP participant STAs in the same BSS or in another BSS. The non-AP TXOP holder STA does not need to wait for the AP to initiate shared TXOP access. The non-AP TXOP holder STA can schedule and allocate available frequency resources to other non-AP shared TXOP participant STAs. Once the TXOP is reserved, the non-AP TXOP holder STA can send a schedule to the AP. Potential non-AP TXOP holder STAs can use the predetermined schedule to allocate channel access resources.

[0134] The present disclosure may benefit WLAN operations by reducing latency in accessing channels and improving channel utilization efficiency.

[0135] Figure 12 An example embodiment 50 illustrates a high-level example of the proposed shared TXOP protocol initiated by a non-AP TXOP holder STA. During the TXOP setup process, non-AP STAs including the non-AP TXOP holder STA and non-AP shared TXOP participant STAs exchange TXOP shareability information through the coordination of the AP.

[0136] This figure depicts the interaction between a receiver AP 52, two non-AP transmitters acting as shared TXOP participants 54 and 56, and a non-AP transmitter TXOP holder 58. A TXOP setup process 60 is performed. When a non-AP TXOP holder STA 58 acquires a channel, it initiates a shared TXOP for uplink (UL). The TXOP holder STA may need to confirm which non-AP STAs are willing to participate in the next shared TXOP. The first shared TXOP access 62 then begins when headers 64, 68, and 72 are sent from the transmitting non-AP STA. The TXOP holder STA transmits UL data on a reserved RU 74, while the non-AP shared TXOP participant STAs transmit UL data on RUs 66 and 70 allocated by the non-AP TXOP holder STAs. A second TXOP 76 is also shown, and after headers 78 and 82, the TXOP holder 58 utilizes the larger resources in RU2 84, while the only other non-AP shared TXOP participant transmits in RU1 80.

[0137] 6.3. Scene Classification

[0138] This disclosure describes various solutions for two different scenarios: a dynamic scenario and a semi-static scenario. For both scenarios, solutions are discussed from two perspectives: using and not using the AP as a coordinator. The solution for a single BSS scenario is described in Section 7, the associated frame formats in Section 8, and Section 9 summarizes the proposed solution.

[0139] 7. Protocol Design

[0140] 7.1. Overview of protocol design

[0141] Figure 13 The diagram illustrates an example embodiment 90 of the overall overview of the proposed protocol, where, for example, a non-AP STA senses that a channel is available and acquires (seizes) the channel and shares the channel access with other STAs in the frequency domain. Similarly, the diagram depicts the interaction between a receiver AP 52, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. If other STAs also have UL data to transmit, they will access the channel according to the schedule determined by the shared TXOP holder STA or based on a predetermined semi-persistent scheduling scheme. The disclosed protocol includes three phases and can be applied to different channel access designs, such as random access and scheduled access.

[0142] In the first phase, i.e., shared TXOP setup 92, non-AP STAs including a TXOP holder STA and a shared TXOP participant STA exchange TXOP shareability information indicating the STA's willingness to share (propose / request) a TXOP by embedding the TXOP shareability information in an authentication frame, an association frame, or any other frame exchanged through coordination of the AP.

[0143] In the second phase, known as the shared TXOP initialization phase 94, the non-AP TXOP holder STA obtains channel access and announces its willingness to share the following TXOP with other non-AP STAs. In at least one embodiment, this process is performed, for example, by broadcasting a MU-RTS sharing frame to potential shared TXOP participant STAs, indicating that the following TXOP is shareable. Other non-AP STAs willing to join the following shared TXOP respond to the TXOP holder STA, for example, by sending back a CTS sharing frame to confirm their participation.

[0144] In the third phase, which is the TXOP scheduling and access phase 96, a non-AP TXOP holder STA and a non-AP shared TXOP participant STA simultaneously access the channel. The non-AP TXOP holder STA uses the reserved RUs to transmit UL data. Depending on which channel access mode has been selected, the non-AP shared TXOP participant STA uses the allocated RUs or randomly accesses the remaining RUs to transmit UL data.

[0145] The system may operate using a subset of these phases, so all phases are not mandatory.

[0146] 7.2. Dynamic Scenarios Without AP as Coordinator

[0147] In this case, after the non-AP TXOP holder STA seizes the channel, instead of waiting for the AP to send a trigger frame, the non-AP TXOP holder STA can initiate MU UL transmission with other non-AP STAs. The non-AP TXOP holder STA can directly coordinate with other non-AP STAs that are willing to participate in the next shared TXOP.

[0148] Figure 14An example embodiment 110 illustrates the process of exchanging shared information during the shared TXOP setup phase. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figure. Non-AP STAs indicate their shareability in frames exchanged with the AP. For example, they may append an element containing sharing information 112 to an authentication frame, association frame, or any other frame exchanged with the AP, which is then sent to the associated AP. Once the AP receives the authentication frame or association frame, it examines the sharing information and responds with a frame 114 to confirm successful receipt. The AP then broadcasts the shareability information to all associated non-AP STAs using a sharing offer / request frame 116. Once a non-AP STA receives the sharing offer / request frame, it learns which stations are willing to share the TXOP and which stations are requesting shareability of TXOP time from other non-AP STAs.

[0149] Towards the right in the figure, STA2 56 is requesting a share of the TXOP by sending a share request 118. At 120, the AP responds to the share request 118 and then transmits share information 122 to other STAs.

[0150] The shared TXOP setup phase is a common phase for dynamic scenarios with or without an AP as the coordinator. Sharability information is implemented in management frames through a new element designed as the STA TXOP shareability element.

[0151] Figure 15 An example embodiment 130 of the shared TXOP setup phase processed by an AP is illustrated. After the shared TXOP setup phase begins at 132, the AP receives a management frame, such as an authentication request frame or an association request frame, from a non-AP STA at 134, indicating whether the non-AP STA is willing to propose / request a shared TXOP with other non-AP STAs. The AP retains the shareability information from the non-AP STA and, at 136, sends back an authentication / association response frame to confirm successful receipt. The AP then records the latest shareability information in its database at 138 and rebroadcasts the latest shareability information to all associated non-AP STAs using sharing proposal / request frames, after which processing ends at 140.

[0152] Figure 16An example embodiment 150 of the shared TXOP setup phase handled at the non-AP STA level is illustrated. After the shared TXOP setup phase begins at 152, at 154, the non-AP STA sends a management frame, such as an authentication / association request frame, to the associated AP to indicate its sharing proposal / request information regarding the shared TXOP. At 156, a check is performed to determine whether any response has been received from the associated AP. If the non-AP STA does not receive any feedback from the associated AP before the management frame times out after sending an authentication frame or association frame containing the sharing proposal / request information, execution moves to block 158 due to the management frame timeout, and then execution returns to block 154, where the non-AP STA resends a management frame to the associated AP to indicate its shareability.

[0153] Otherwise, if the non-AP STA receives a response from the AP at block 156, block 160 is reached where it is determined whether the non-AP STA has received a sharing offer / request frame indicating the latest TXOP shareability information from the associated AP. If it has received sharing offers / requests from all associated non-AP STAs, block 164 is reached where the STA updates its database of sharing offer / request information for all other STAs, and processing ends at block 166. If no sharing offer / request frame is received before a timeout, block 162 is reached due to the timeout, and execution returns to block 154 where the non-AP STA should retransmit the authentication / association request frame with the TXOP sharing offer / request information embedded therein.

[0154] Figure 17 Illustrated is an example embodiment 170 of the process for the shared TXOP initialization phase without an AP acting as a coordinator. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0155] In this example, it is assumed that the non-AP TXOP holder STA performs channel sounding (beamforming test) 172 to obtain beamforming information for other non-AP STAs. This can be done at any time before the STA initiates the sharing process. The frequency of this process depends on the channel characteristics.

[0156] At this stage, the non-AP TXOP holder STA acquires (seizes) the channel and is willing to share the TXOP with other non-AP STAs. It needs to confirm which other non-AP STAs are willing to join the next shared TXOP. The non-AP TXOP holder STA sends a MU-RTS share frame 174 to potential non-AP shared TXOP participant STAs. The MU-RTS share frame carries the bandwidth (BW) indicated for each designated non-AP STA. The network allocation vector (NAV) (MU-RTS) period 176 begins. Once the non-AP STAs receive the MU-RTS share frame and are willing to join the next shared TXOP, they respond to the non-AP TXOP holder STA with a CTS share frame 178, 180 using the BW indicated in the received MU-RTS share frame. NAV (CTS share) starts 182. If the AP receives the MU-RTS share frame, it knows that a shared TXOP has been initiated.

[0157] Figure 18 An example embodiment 190 of the shared TXOP initialization phase handled by a non-AP TXOP holder STA is illustrated. After the shared TXOP initialization phase begins at 192, channel sounding is performed at 194. Then, at 196, the non-AP TXOP holder STA sends MU-RTS shared frames to potential non-AP shared TXOP participant STAs and the AP, allocating a specific BW for them to respond. Then, at 198, a check is performed to determine whether the non-AP TXOP holder STA has received all CTS shared frames.

[0158] If at block 198 it is found that the non-AP TXOP holder has not received any CTS shared frame within the MU-RTS shared frame timeout, then MU-RTS timeout 200 is reached and then block 196 is reached where the MU-RTS shared frame should be retransmitted to some other non-AP STA.

[0159] Otherwise, if at block 198 the non-AP TXOP holder STA receives all CTS sharing frames from the non-AP shared TXOP participant STAs, it knows that these non-AP STAs will all participate in the next shared TXOP, thus reaching block 202 where the non-AP TXOP holder STA records the AIDs of all non-AP shared TXOP participants contained in the received CTS sharing frames, after which execution ends at 204.

[0160] Figure 19An example embodiment 210 of a shared TXOP initialization phase processed by a non-AP shared TXOP participant STA is illustrated. After the shared TXOP initialization phase begins at 212, a check is performed at 214 to determine whether the non-AP STA has received a MU-RTS sharing frame. If no MU-RTS sharing frame has been received, the process ends at 222.

[0161] Otherwise, if the non-AP STA receives a MU-RTS sharing frame in which the AID12 subfield in one of the User Information List fields is the same as the receiver's AID, the non-AP STA checks to determine whether the non-AP STA is willing to join the shared TXOP at block 216. If, at block 216, it is determined that the non-AP STA is willing to join the next shared TXOP, then at block 218, the STA responds with a CTS sharing frame with the TXOP Sharing Participant AID field set to its AID to indicate that it will join the next shared TXOP, and the process ends at 222. Otherwise, if the non-AP STA is not willing to join, then block 220 is reached, and the non-AP STA responds with a CTS sharing frame with the TXOP Sharing Participant AID field set to 0 to indicate that it will not join the next shared TXOP.

[0162] 7.2.3.TXOP Scheduling and Access Phase

[0163] In the present disclosure, there are multiple solutions for the TXOP scheduling and access phases, three of which are exemplified here by (1) the unicast TXOP access request triggering method as described in Section 7.2.3.1, (2) the broadcast TXOP access request triggering method as described in Section 7.2.3.2, and (3) the random access method as described in Section 7.2.3.3.

[0164] 7.2.3.1. TXOP Scheduling and Access Phase with Unicast TXOP Access Request Triggering

[0165] Figure 20 This diagram illustrates an example embodiment 230 of the TXOP scheduling and access phase using unicast TXOP access request trigger frames for each non-AP shared TXOP participant STA. This process is based on information received from the shared TXOP initialization phase. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figure.

[0166] The non-AP TXOP holder STA performs channel sounding (beamforming test) 232 to obtain beamforming information for other non-AP STAs. Figure 17As in the previous example, a shared TXOP initialization phase 234 occurs, wherein a non-AP TXOP holder STA acquires (seizes) a channel and is willing to share the TXOP with other non-AP STAs, and sends a MU-RTS share frame 236 to potential non-AP shared TXOP participant STAs. The MU-RTS share frame carries the bandwidth (BW) indicated for each designated non-AP STA. A network allocation vector (NAV) (MU-RTS) period 238 begins. Once the non-AP STAs receive the MU-RTS share frame and are willing to join the next shared TXOP, they respond to the non-AP TXOP holder STA with CTS share frames 240, 242, and 244 using the BW indicated in the received MU-RTS share frame. NAV (CTS share) begins 246.

[0167] A non-AP TXOP holder STA unicasts a series of unicast TXOP access request trigger frames 248 and 250, which indicate the resource units (RUs) allocated for UL transmission for a specific non-AP shared TXOP participant STA. After the non-AP TXOP holder STA sends the last unicast TXOP access request trigger frame, or after the non-AP shared TXOP participant STA receives the last unicast TXOP access request trigger frame sent by the shared TXOP holder, the non-AP STA sends its uplink (UL) data 252, 254, and 256 to the AP, with the TXOP holder using reserved RUs and the TXOP participant STA using allocated RUs. Synchronization of all non-AP STAs transmitting in the shared TXOP is achieved by detecting the last unicast TXOP access request trigger frame with the TXOP Access Start Flag field set to 1. Receiver AP 52 issues a multi-station block acknowledgment (BA) 258 to confirm successful reception of the UL data.

[0168] 7.2.3.2. TXOP Scheduling and Access Phase with Broadcast TXOP Access Request Trigger

[0169] Figure 21 This diagram illustrates an example embodiment 270 of the TXOP scheduling and access phase, which utilizes a broadcast TXOP access request trigger frame for all non-AP shared TXOP participant STAs. This process is based on information obtained during the shared TXOP initialization phase. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figure.

[0170] The non-AP TXOP holder STA performs channel sounding (beamforming test) b272 to obtain beamforming information for other non-AP STAs. Figure 20 As in the previous example, a shared TXOP initialization phase 274 occurs, wherein a non-AP TXOP holder STA acquires (seizes) a channel and is willing to share the TXOP with other non-AP STAs, and sends a MU-RTS share frame 276 to potential non-AP shared TXOP participant STAs. The MU-RTS share frame carries the bandwidth (BW) indicated for each designated non-AP STA. A network allocation vector (NAV) (MU-RTS) period 278 begins. Once the non-AP STAs receive the MU-RTS share frame and are willing to join the next shared TXOP, they respond to the non-AP TXOP holder STA with CTS share frames 280, 282, and 284 using the BW indicated in the received MU-RTS share frame. NAV (CTS share) begins 286.

[0171] After the shared TXOP initialization phase 274, the non-AP TXOP holder STA sends a broadcast TXOP access request trigger frame 290 indicating the RUs allocated for UL transmission for each specific non-AP shared TXOP participant STA.

[0172] After sending the broadcast TXOP access request trigger frame, the non-AP TXOP holder STA uses its reserved RU to send its UL data 296 to the AP; and each non-AP shared TXOP participant STA, after receiving the broadcast TXOP access request trigger frame, uses its allocated RU to send its UL data 292 and 294. After these uploads, the receiver AP 52 sends a multi-station block acknowledgement (BA) 298.

[0173] 7.2.3.3. TXOP Scheduling and Access Phase with Random Access

[0174] Figure 22 Illustrates an example embodiment 300 of the TXOP scheduling and access phases by allowing random access for non-AP shared TXOP participant STAs. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0175] Since random access is applied, the non-AP TXOP holder STA can skip (abandon) the shared TXOP initialization phase.The non-AP TXOP holder STA broadcasts a TXOP random access request trigger frame 302, which informs the non-AP TXOP holder STA that the RU has been reserved for UL transmission.

[0176] After issuing a TXOP random access request trigger frame, the non-AP TXOP holder STA transmits its UL data 308 to the AP using the reserved RUs. After receiving the TXOP random access request trigger frame, the non-AP shared TXOP participant STAs perform random access to the shared TXOP to perform UL data transmissions 304 and 306 and compete for the remaining RUs. By assuming that the propagation delay of the TXOP random access request trigger frame is sufficiently small that it can be ignored, synchronization of all non-AP STAs in the shared TXOP is achieved. Following these transmissions, the receiver AP 52 issues a multi-station block acknowledgement (BA) 309.

[0177] Figure 23A and Figure 23B An example embodiment 310 of the TXOP scheduling and access phase handled by a non-AP TXOP holder STA is illustrated. After the TXOP scheduling and access phase begins at 312, the non-AP TXOP holder STA reserves RUs for itself and is willing to share the remaining RUs with other non-AP STAs at 314. By way of example and not limitation, three different forms of TXOP access scheduling that can be handled by a non-AP TXOP holder STA are described, including a random access-based scheduler, a unicast TXOP access trigger, and a broadcast TXOP access trigger.

[0178] At block 316, a determination is made as to whether random access is to be used during the shared TXOP. If this is random access, the process proceeds to block 318, where the non-AP TXOP holder STA broadcasts a TXOP random access request trigger by broadcasting a TXOP random access request trigger frame to announce the reserved RUs for itself and to indicate UORA (UL OFDMA-based random access) for other non-AP STAs. At block 320, the non-AP TXOP holder STA begins transmitting UL data in the reserved RUs, with the process terminating at 322.

[0179] Otherwise, if it is determined at block 316 that this is not a random access TXOP, execution moves to Figure 23BAt block 324, a check is made to see if the shared TXOP will utilize unicast access. If this is unicast sharing, then block 326 is reached where the non-AP TXOP holder STA sends a unicast TXOP access request trigger frame to the non-AP shared TXOP participant STA using the allocated RU. A check is then made at 328 regarding the last unicast TXOP access request trigger. If this is not the last request trigger, execution returns to block 326. Otherwise, if this request trigger is the last trigger, execution proceeds to block 329. Figure 23A At block 320 , the non-AP TXOP holder STA may begin its UL data transmission, with the process ending at 322 .

[0180] Otherwise, if it is determined at block 324 that this is not unicast access, then a determination is made at block 330 whether this is a broadcast access scheme. If this is not broadcast sharing, then since all three examples have been checked, the process ends at 322. It should be noted that the present disclosure is not limited to the illustrated forms of sharing.

[0181] However, if it is determined to be broadcast sharing in block 330, then in block 332, the non-AP TXOP holder STA sends a broadcast TXOP access request trigger to all non-AP STAs, and it allocates RUs to all non-AP TXOP sharing participant STAs, performing the move to Figure 23A 320 , where the non-AP TXOP holder STA starts UL data transmission in the reserved RU.

[0182] Figure 24A and Figure 24B Illustrating an example embodiment 340 of the TXOP scheduling and access phases handled by a non-AP shared TXOP participant STA.

[0183] After the TXOP scheduling and access phase begins at 342, a check is performed at 344 to determine whether a non-AP shared TXOP participant STA has received a TXOP random access request trigger frame.

[0184] If a non-AP shared TXOP participant STA receives a TXOP random access request trigger frame, then at block 346, the non-AP shared TXOP participant STA counts down an OBO (OFDMA Random Access Backoff) counter randomly selected in the range between zero (0) and the OCW (OFDMA Contention Window). At block 348, a check is performed to determine whether the OBO counter of the non-AP STA is less than the number of RUs allocated for random access. If this condition is not met, execution returns to block 346 and the OBO continues to count down. Otherwise, if this condition is met, at block 350, the non-AP STA randomly accesses one of the RUs allocated for random access, which is indicated by the selected subset of the User Information field of the TXOP Random Access Request Trigger frame, and the process ends at 368.

[0185] Returning to block 344, if the non-AP STA does not receive a TXOP random access request trigger, execution moves to Figure 24B At block 352, a check is performed to determine whether the non-AP shared TXOP participant STA has received a unicast TXOP access request trigger. If this condition is met, a check is performed at block 354 to determine whether a unicast TXOP access request trigger frame has been sent to the non-AP shared TXOP participant STA. If this condition is met, execution moves to block 356, where the non-AP shared TXOP participant STA checks its allocated RUs, and then execution proceeds to block 358. Otherwise, if the condition of block 354 is not met, execution moves directly to block 358.

[0186] At block 358, the TXOP Access Start Flag subfield of the unicast TXOP access request trigger is analyzed. A check is then performed at block 360 to determine whether this is the last unicast TXOP access trigger. If this is the last unicast TXOP access request trigger (as indicated by the TXOP Access Start Flag subfield of the most recently received unicast TXOP access request trigger frame), then at block 362, the non-AP STA transmits UL data to the associated AP using the allocated RU size indicated in the unicast TXOP access request trigger, after which processing ends at block 368. Otherwise, if the condition of block 360 is not met, the non-AP STA continues to check the TXOP Access Start Flag subfield of the next received unicast TXOP access request trigger by returning to block 358.

[0187] Returning to block 352, if no unicast TXOP access request trigger has been received, the process proceeds to block 364, where a check is performed to determine whether the non-AP STA has received a broadcast TXOP access request trigger. If this condition is met, the STA transmits UL data to the associated AP using the allocated RU indicated in the broadcast TXOP access request trigger frame at block 366. In either case, the process terminates at block 368.

[0188] 7.3. Dynamic Scenario with AP as Coordinator

[0189] In this scenario, after a non-AP TXOP holder STA acquires (seizes) the channel, it can initiate MU UL transmissions with other non-AP STAs, rather than waiting for the AP to send a trigger frame. The non-AP TXOP holder STA cannot directly communicate with other non-AP STAs willing to participate in the subsequent shared bTXOP. In this case, the AP needs to be involved to coordinate between the non-AP TXOP holder STA and other non-AP shared TXOP participant STAs.

[0190] 7.3.1. Shared TXOP Initialization Phase

[0191] Figure 25 Illustrated is an example embodiment 370 of a shared TXOP initialization phase 372 in a scenario with an AP as the coordinator. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0192] like Figure 14 372. Non-AP STA3 58 communicates shareability information 374 with the AP, the AP responds 376, and the AP then broadcasts the shareability information to all associated non-AP STAs using a share offer / request frame 378. STA2 56 is also shown sending a share 380 to the AP, the AP responds 382, and then broadcasts a share offer / request 384.

[0193] The figure depicts periodic buffer status operations 386, where the AP periodically sends buffer status report poll (BSRP) frames 388 to poll non-AP STAs to request their buffer status reports (BSRs). Once the non-AP STAs receive the BSRPs, they all respond with BSR frames 390, 392, and 394 to report their buffer status and traffic priority.

[0194] Since the non-AP TXOP holder STA may not be able to communicate directly with other non-AP STAs in the BSS, it starts the TXOP initialization phase by unicasting a modified CTS-to-self (CTS to itself) sharing frame 396 to the associated AP, which indicates that the next TXOP is a shared TXOP, which also starts NAV (CTS-to-self sharing) 398.

[0195] AP 52 receives the modified CTS-to-self share frame from the non-AP TXOP holder STA and then broadcasts a MU-RTS-share frame 400 to all non-AP STAs, thereby initiating NAV (MU-RTS share) 402. After receiving the MU-RTS share frame, each non-AP STA checks whether it is willing to participate in the ensuing shared TXOP. If the non-AP STA is willing to participate, it responds with a CTS-share frame indicating its AID in the TXOP share participant AID field and sends the CTS-share frame back to the associated AP. If it is not willing to participate, the non-AP STA responds with a CTS-share frame with the TXOP share participant AID field set to 0. The figure depicts STA1 54 and STA2 56 responding to AP1 with CTS-share 404 and 406, at which point NAV (CTS share) 408 begins. After receiving the CTS share information, the AP then sends a TXOP participant announcement 410 to STA3 58.

[0196] Figure 26 An example embodiment 430 of a shared TXOP initialization phase handled by a non-AP TXOP holder STA is illustrated. After the shared TXOP initialization phase begins at 432, the non-AP TXOP holder STA unicasts a CTS-to-self sharing frame to the AP at 434 to indicate the start of the shared TXOP initialization phase. A check is performed at 436 to determine whether a MU-RTS sharing frame has been received. If a MU-RTS sharing frame is not received within the CTS-to-self sharing frame timeout, a CTS-to-self sharing timeout occurs at 438, and the non-AP TXOP holder STA then retransmits the CTS-to-self frame at block 434.

[0197] Otherwise, if a MU-RTS sharing frame is received, a check is performed to determine whether a TXOP participant announcement is received from the AP at 440. If this condition is met, at 442, the STA updates the database of the AIDs of the shared TXOP participant STAs, and the process ends at 448.

[0198] Otherwise, if at block 440 , no participant announcement is received from the AP, the non-AP TXOP holder STA no longer waits for a TXOP participant announcement frame because the TXOP participant announcement frame has timed out 444 , and then at 446 , assuming that no other STA is willing to join the next shared TXOP, the process ends at 448 .

[0199] Figure 27 An example embodiment 450 of a shared TXOP initialization phase handled by an AP is illustrated. After the shared TXOP initialization phase begins at 452, a check is performed at 454 to determine whether the AP has received a CTS-to-self sharing frame from a non-AP TXOP holder STA. If the AP has not received a CTS-to-self sharing frame, processing ends at 466. Otherwise, after receiving a CTS-to-self sharing frame, at 456, the AP sends a MU-RTS sharing frame to at least some potential non-AP shared TXOP participant STAs and allocates a specific BW to each non-AP shared TXOP participant STA in response to the CTS sharing frame.

[0200] At 458, a check is performed to see if a CTS shared frame is received. If the AP does not receive any CTS shared frame within the MU-RTS shared frame timeout period, a MU-RTS timeout occurs at 460 and the process returns to block 456 to retransmit the MU-RTS shared frame.

[0201] Otherwise, if it is determined that the AP has received a CTS Share frame from a non-AP shared TXOP participant STA, then at block 462, the AIDs of the STAs willing to participate in the next shared TXOP are recorded. Note that this AID information is included in the received CTS Share frame. Then, at block 464, the AP unicasts a TXOP Participant Advertisement frame to the non-AP TXOP holder to notify the non-AP TXOP holder of the participant information for the next shared TXOP, and the process ends at block 466. Note that the MAC address of the non-AP TXOP holder STA can be found in the RA field of the CTS-to-self frame.

[0202] Flowchart of the shared TXOP initialization phase handled by a non-AP shared TXOP participant STA Figure 19 Same as shown in .

[0203] 7.3.2.TXOP Scheduling and Access Phase (with AP as Coordinator)

[0204] In this section, an example of a method for performing TXOP scheduling and access phases by using the AP as a coordinator is given.

[0205] Figure 28 This diagram illustrates an example embodiment 470 of the TXOP scheduling and access phase for a unicast-TXOP access request trigger in a scenario where an AP acts as a coordinator. Scheduling is achieved by transmitting a request trigger, more specifically, by triggering a unicast-TXOP access request. Again, by way of example and not limitation, this diagram shows the same AP and STA participants as in the previous diagram.

[0206] Shared initialization phase 472 with Figure 25 . TXOP holder STA3 58 unicasts a CTS-to-self share frame 474 to receiver AP 52, which also starts NAV (CTS-to-self share) 476. AP 52 receives the modified CTS-to-self share frame from the non-AP TXOP holder STA, then broadcasts a MU-RTS share frame 478 to all non-AP STAs, and NAV (MU-RTS share) 480 begins. After receiving the MU-RTS share frame, each non-AP STA checks whether it is willing to participate in the next shared TXOP and sends back CTS share frames 482 and 484 to the associated AP, starting NAV (CTS share) period 486. After receiving the CTS share information, the AP sends a TXOP participant announcement 488 to STA3.

[0207] The TXOP scheduling and access phase 504 is based on the shared TXOP participant information collected during the shared TXOP initialization phase. Since a non-AP TXOP holder STA cannot communicate directly with other non-AP STAs in the BSS, it begins the TXOP scheduling and access phase by sending a TXOP access scheduler trigger frame 490 to the AP. The TXOP access scheduler trigger frame contains information about RU allocations for all non-AP shared TXOP participant STAs.

[0208] After receiving the TXOP access scheduler trigger frame, the AP sends (preferably unicast) TXOP access request trigger frames 492 and 494 to each non-AP shared TXOP participant STA and indicates the RUs allocated for UL transmission for the specific non-AP shared TXOP participant STA.

[0209] After receiving the unicast TXOP access request trigger frame, each non-AP shared TXOP participant STA checks the allocated RU for UL transmission. For both the non-AP TXOP holder STA and all non-AP shared TXOP participant STAs, once they send / receive the last unicast TXOP access request trigger, such as when the TXOP access start flag field is set to valid (e.g., "1"), they start their UL data transmission 500, 498, and 496. Once the AP completes receiving the UL data, the AP responds with an MU block acknowledgement (BA) frame 502.

[0210] Figure 29 This diagram illustrates an example embodiment 510 of the TXOP scheduling and access phase for a broadcast TXOP access request trigger in a scenario where the AP acts as a coordinator. Scheduling is achieved by sending a broadcast TXOP access request trigger. Again, by way of example and not limitation, this diagram shows the same AP and STA participants as in the previous diagram.

[0211] Shared initialization phase 512 with Figure 28 514. TXOP holder STA3 58 unicasts a CTS-to-self share frame 514 to receiver AP 52, which also starts NAV (CTS-to-self share) 516. AP 52 receives the modified CTS-to-self share frame from the non-AP TXOP holder STA, then broadcasts a MU-RTS share frame 518 to all non-AP STAs, and NAV (MU-RTS share) 520 begins. After receiving the MU-RTS share frame, each non-AP STA checks whether it is willing to participate in the next shared TXOP and sends back CTS share frames 522 and 524 to the associated AP, starting NAV (CTS share) period 526. After receiving the CTS share information, the AP sends a TXOP participant announcement 528 to the TXOP holder (STA3).

[0212] The TXOP scheduling and access phase 529 is based on the shared TXOP participant information collected from the shared TXOP initialization phase 512. Since a non-AP TXOP holder STA cannot communicate directly with other non-AP STAs in the BSS, it begins the TXOP scheduling and access phase by sending a TXOP access scheduler trigger frame 530 to the AP. The TXOP access scheduler trigger frame contains RU allocations for all non-AP shared TXOP participant STAs.

[0213] After receiving the TXOP access scheduler trigger frame, the AP sends a broadcast TXOP access request trigger frame 532 to all non-AP shared TXOP participant STAs, indicating one or more RUs allocated to each specific non-AP shared TXOP participant STA for UL transmission. Once the broadcast TXOP access request trigger frame has been received, each non-AP shared TXOP participant STA checks the allocated RUs and starts its UL transmission 538, 536, and 534.

[0214] In at least one embodiment, once the non-AP TXOP holder STA issues a broadcast TXOP access request trigger, it begins sending its UL data using the reserved RUs. Other non-AP shared TXOP STAs send their UL data in their allocated RU or RUs. Once the AP has received the UL data, it responds with a MU-BA frame 540.

[0215] Figure 30 Illustrated is an example embodiment 550 of the TXOP scheduling and access phase using basic triggering in a scenario with an AP as the coordinator. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0216] In this case, the scheduler is designed for basic trigger frames. It can be seen that the non-AP TXOP holder, STA3, sends a TXOP priority trigger frame 552 to AP 52, and NAV (Trigger) 554 begins. Optional collection of buffer status reports 556 occurs. In this example, the AP periodically broadcasts BSRP frames 558 to query the buffer status of non-AP STAs, and NAV (BSRP) 555 begins. The non-AP STAs respond with BSR frames 560, 562, and 564 to indicate their buffer status and packet information, and NAV (BSR) 566 begins. The BSRP and BSR exchanges can occur within or outside the TXOP scheduling and access phase. Since the shared TXOP participant information can be collected from the exchange of BSRP and BSR frames, the shared TXOP initialization phase can be skipped.

[0217] A non-AP TXOP holder STA cannot communicate directly with other non-AP STAs in the BSS, as in this example, scheduling is done by the AP, so the non-AP TXOP holder begins the TXOP scheduling and access phase by sending a TXOP priority trigger frame 552 to the AP. The TXOP priority trigger frame indicates the RUs reserved for the non-AP TXOP holder STA.

[0218] After receiving the TXOP Priority Trigger frame, the AP broadcasts a Basic Trigger frame 568 to each non-AP shared TXOP participant STA and non-AP TXOP holder STA, and NAV (Basic Trigger) 570 begins. The Basic Trigger frame indicates one or more RUs allocated to each non-AP STA for transmitting a UL data sequence. After receiving the Basic Trigger frame, each non-AP shared TXOP participant STA begins its UL data transmission 572 and 574 using the allocated RUs, and the non-AP TXOP holder STA begins its UL data transmission 576 using the reserved RUs, and NAV (Data) 578 begins. Once the AP has completed receiving the UL data, it responds with a MU-BA frame 580.

[0219] Figure 31 The diagram illustrates an example embodiment 590 of the TXOP scheduling and access phase using random access in a scenario where the AP is the coordinator. The scheduler in this scenario is based on random access. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figure.

[0220] Since accurate information about the shared TXOP participants is not required in this case, the shared TXOP initialization phase, as well as the BSRP and BSR exchanges, can be skipped.

[0221] Since the non-AP TXOP holder STA cannot communicate directly with other non-AP STAs in the BSS, it leaves the scheduling to the AP; then, the non-AP TXOP holder STA starts the TXOP scheduling and access phase by sending a TXOP priority trigger frame 592 to the AP, and NAV (priority trigger) 594 begins. The TXOP priority trigger frame indicates the reserved RU for the non-AP TXOP holder STA.

[0222] After receiving the TXOP priority trigger frame, the AP broadcasts a TXOP random access request trigger frame 596 to each non-AP shared TXOP participant STA and non-AP TXOP holder STA, which starts NAV (scheduling trigger) 598. After receiving the TXOP random access request trigger frame, each non-AP shared TXOP participant STA starts UL data transmission 600 and 602 by randomly accessing the remaining RUs, while the non-AP TXOP holder STA starts its UL data transmission 604 using the reserved RUs, and NAV (data) 606 starts. Once the AP has completed receiving the UL data, it responds with a MU-BA frame 608.

[0223] Figure 32A and Figure 32BAn example embodiment 610 of a TXOP scheduling and access phase with random access handled by an AP as a coordinator is illustrated. After the TXOP scheduling and access phase starts at 612, at 614 the AP first checks whether a non-AP TXOP holder will schedule at the non-AP STA level.

[0224] If a non-AP STA is currently being scheduled, the AP receives a TXOP access scheduler trigger from the non-AP TXOP holder STA, indicating that RUs are allocated to each non-AP shared TXOP participant STA. A check is then performed at 618 to determine whether unicast access is being used in the shared TXOP. If unicast access is being used, the AP sends a unicast TXOP access request trigger frame to each non-AP shared TXOP participant STA at 620, indicating the RUs allocated to that non-AP STA. After sending all unicast TXOP access request trigger frames, the AP will be able to receive UL data. Therefore, the AP checks for the last unicast access at 622, then returns to 620 until all unicast accesses are complete, at which point the AP reaches 624, where it waits for UL data to be received. The process then ends at 640.

[0225] Returning to block 618, if it is determined that unicast access is not being used, then at block 626, the AP sends a broadcast TXOP access request trigger frame to all non-AP shared TXOP participant STAs to trigger UL data transmission. Then, at block 628, the broadcast TXOP access request trigger frame indicates the allocated RUs for all non-AP shared TXOP participant STAs. Execution moves to block 624, where the AP waits to receive UL data.

[0226] Returning to block 614, in the case of scheduling by the AP, execution moves to Figure 32B At block 630, the AP receives a TXOP priority trigger from a non-AP TXOP holder STA, indicating the reserved RUs and priority of the non-AP TXOP holder STA. A check is performed at 632 to determine whether random access is used in the TXOP. If this is random access, then at block 634, the AP broadcasts a TXOP random access request trigger by announcing the reserved RUs for the TXOP holder and indicating UORA (UL OFDMA-based random access) for other non-AP shared TXOP participant STAs, and processing ends at 640. Otherwise, execution proceeds to block 636, where scheduling is performed based on buffer status information from the periodic exchange of BSRP and BSR frames, and then at 638, the AP sends a basic trigger with the RU allocations allocated to each non-AP shared TXOP participant STA, and processing ends at 640.

[0227] Figure 33A and Figure 33B An example embodiment 650 of a TXOP scheduling and access phase with random access handled by a non-AP TXOP holder STA using an AP as a coordinator is illustrated. After the TXOP scheduling and access phase begins at 652, at 654 the non-AP TXOP holder STA first decides whether it would like to be scheduled at its own level or at the AP level.

[0228] If the non-AP TXOP holder STA is scheduled, then at block 656, the non-AP TXOP holder STA, willing to share the next shared TXOP with other STAs, reserves one or more RUs for itself. Then, at block 658, the non-AP TXOP holder STA unicasts a TXOP access scheduler trigger frame to the AP, indicating the allocation of RUs to each non-AP shared TXOP participant STA. A decision is then made as to whether to perform a broadcast or unicast operation. At block 660, a check is performed to determine whether the non-AP TXOP holder STA received a unicast TXOP access request trigger from the AP before the TXOP access scheduler trigger frame times out.

[0229] If it is not unicast, a check is performed at block 668 to determine whether a broadcast TXOP access request trigger has been received. If no trigger has been received, a trigger timeout occurs at 670, and execution returns to block 658, where the non-AP TXOP holder retransmits the TXOP access scheduler trigger frame. Otherwise, if a broadcast TXOP access request trigger has been received, block 666 is reached, where the non-AP TXOP holder STA transmits UL data to the AP, and processing ends at 684.

[0230] Returning to block 660, if the non-AP TXOP holder receives a unicast TXOP access request trigger, the STA checks the TXOP access start flag field of the unicast TXOP access request trigger frame at block 662. At block 664, the process loops back to block 662 until the AP sends the last unicast TXOP access request trigger, at which point execution proceeds to block 666, where the non-AP TXOP holder STA sends UL data to the AP on its reserved RU, concluding the process at 684.

[0231] Returning to block 654, if it is determined that scheduling will be performed by the AP, execution moves to block 672, where the non-AP TXOP holder STA reserves a RU for itself and unicasts a TXOP priority trigger to the AP, indicating that the TXOP holder has the highest priority. At 674, a check is performed to determine whether the non-AP TXOP holder STA has received a TXOP random access request trigger frame from the AP within the TXOP priority trigger frame timeout interval. If it has received this trigger frame, block 666 is reached, where the non-AP TXOP holder STA transmits its UL data to the AP, and processing ends at 684.

[0232] Otherwise, if no random access trigger request is received at block 674, execution moves to block 676 to check whether the non-AP TXOP holder STA has received the BSRP. If it has received the BSRP, then at block 678, the non-AP TXOP holder responds with a BSR frame to indicate its buffer status and traffic priority, and execution then proceeds to block 680. If the check at block 676 determines that no BSRP has been received, execution moves directly to block 680.

[0233] At block 680, a determination is made as to whether the non-AP TXOP holder STA has received a basic trigger. If a basic trigger has been received, execution moves to block 666 to transmit UL data to the AP, after which processing ends at 684. Otherwise, if a basic trigger has not been received, a timeout for a priority trigger occurs at 682, and execution returns to block 672. If the non-AP TXOP holder STA receives a TXOP random access request trigger frame, it may begin UL transmission using the reserved RUs.

[0234] Figure 34A and Figure 34B Illustrates an example embodiment 690 of a TXOP scheduling and access phase with random access handled by non-AP shared TXOP participant STAs using an AP as a coordinator.

[0235] After the TXOP scheduling and access phase begins at 692, a check is performed at 694 to determine whether the non-AP shared TXOP participant STA has received a unicast TXOP access request trigger. If it has received a unicast TXOP access request trigger, execution proceeds to block 696 to determine whether the unicast TXOP access request trigger was intended for the station. If the unicast TXOP access request trigger was intended for the station, the non-AP shared TXOP participant STA checks its allocated RUs at 698. Then, at block 700, the non-AP shared TXOP participant STA checks the TXOP access start flag field of the unicast TXOP access request trigger. At block 702, the process loops back to block 700 until the AP sends the last unicast TXOP access request trigger, at which point execution proceeds to block 704, the non-AP TXOP sharing participant transmits UL data to the AP using the allocated RUs, and processing concludes at 718.

[0236] Returning to block 694, if a unicast TXOP access request trigger is not received, then at block 706, a determination is made as to whether the non-AP TXOP participant STA has received a broadcast TXOP access request trigger from the AP. If the non-AP TXOP participant STA has received a broadcast TXOP access request trigger, execution moves to block 704, where it begins transmitting UL data to the AP using the allocated RU.

[0237] Otherwise, if it is not a broadcast request trigger, execution moves to Figure 34B In block 708, a determination is made as to whether the non-AP shared TXOP participant STA has received a BSRP. If the non-AP shared TXOP participant STA has received a BSRP, then at 710, the non-AP TXOP participant STA responds with a BSR frame to indicate its buffer status and traffic priority, and execution then moves to block 712. Otherwise, if the BSRP has not been received, execution moves directly to block 712.

[0238] At block 712, it is determined whether the non-AP shared TXOP participant STA has received a basic trigger. If a basic trigger is received, execution moves to Figure 34A In block 704 , the non-AP shared TXOP participant STA starts sending UL data to the AP using the allocated RU, and then ends at 718 .

[0239] Otherwise, if it is not a basic trigger, a check is performed at block 714 to determine if it is a TXOP random access request trigger. If it is a TXOP random access request trigger, then at block 716, the non-AP shared TXOP participant STA randomly accesses the shared RU for UL transmission, and the process ends at 718. Otherwise, if it is not a random access trigger, it is not one of these categories, and the process ends at 718.

[0240] 7.4. Overview of Semi-static Scenes

[0241] In this scenario, a two-phase design is described for the shared TXOP setup phase and the TXOP scheduling and access phase.

[0242] During the shared TXOP setup phase, each non-AP STA exchanges sharing proposal / request information for the shared TXOP with the AP. In addition, each non-AP TXOP holder STA also announces the RU allocation of other non-AP shared TXOP participant STAs and exchanges this allocation configuration information with other non-AP STAs through AP coordination.

[0243] Semi-static configuration is performed at the start-up phase. In this case, the complex scheduling process in the TXOP scheduling and access phases can be skipped. Non-AP STAs directly access the TXOP channel using the allocated RUs configured in the shared TXOP setup phase.

[0244] Two semi-static scenarios with and without AP coordination are illustrated in this disclosure.

[0245] Figure 35 Illustrated is an example embodiment 730 of a shared TXOP setup phase including a sharing proposal / request setup sub-phase 732 and a TXOP holder configuration setup sub-phase 746. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0246] During the Sharing Proposal / Request Setup subphase, a non-AP STA sends a Sharing Proposal / Request frame 734, 740 to the associated AP to indicate its shareability. Once the AP receives the Sharing Proposal / Request frame, it sends a response frame 736, 742 back to the non-AP STA to confirm successful reception. The AP then broadcasts a Sharing Proposal / Request frame 738, 744 with the shareability of all associated non-AP STAs. In this case, once a non-AP STA receives the Sharing Proposal / Request frame, it becomes aware of the shareability of all other non-AP STAs. Note that in the Sharing Proposal / Request, non-AP TXOP participant STA1 54 (which may be a potential shared TXOP holder in the future) transmits the Sharing Proposal / Request, while non-AP TXOP holder STA3 58 (which may be a potential shared TXOP participant in the future) transmits the Sharing Proposal / Request.

[0247] In the TXOP holder configuration setup sub-phase 746, each potential non-AP shared TXOP holder STA announces the RU allocation for other non-AP shared TXOP participant STAs and sends the allocation information to the AP using TXOP holder configuration (config) frames 748, 754. Once the AP receives the TXOP holder configuration frame, it acknowledges receipt 750, 756 and then broadcasts the overall TXOP holder configuration information using TXOP access configuration frames 752, 758, which indicate the allocation of RUs allocated by each potential non-AP TXOP holder STA for each non-AP shared TXOP participant STA.

[0248] Figure 36 An example embodiment 770 of the sharing offer / request setup sub-phase processed by an AP is illustrated. After the sharing offer / request setup sub-phase begins at 772, at 774, the AP receives a sharing offer / request frame from a non-AP STA, indicating whether the non-AP STA is willing to propose / request a shared TXOP. At 776, the AP retains this information and sends back a response frame confirming knowledge of the shareability. Then, at 778, the AP broadcasts the latest shareability information to all associated non-AP STAs using the sharing offer / request frame, after which processing ends at 780.

[0249] Figure 37An example embodiment of a sharing proposal / request setup sub-phase processed by a non-AP STA is illustrated at 790. After the sharing proposal / request setup sub-phase begins at 792, at 794, the non-AP STA sends a sharing proposal / request frame to the associated AP, whereby it proposes to share or requests to share a shared TXOP and includes information about the TXOP access resources it proposes or requests, respectively.

[0250] At block 796, a determination is made as to whether the non-AP STA has received a response frame. If the non-AP STA does not receive any feedback from the associated AP within the sharing offer / request timeout period, a frame timeout occurs at 798, and execution returns to block 794, where the non-AP STA retransmits the sharing offer / request frame. Otherwise, if it receives a response frame, a check is performed at block 800 to determine whether the response frame is a broadcast sharing offer / request. If the broadcast sharing offer / request is not received in a timely manner, the broadcast sharing offer / request times out at 802, and execution also returns to block 794, allowing the non-AP STA to retransmit its offer / request.

[0251] Otherwise, if the non-AP STA receives the broadcast sharing proposal / request frame from the AP, it already knows the overall shareability of the non-AP STAs and updates the latest overall STA sharing proposal / request information in its database at 804 , after which the process ends at 806 .

[0252] Figure 38 An example embodiment 810 of the TXOP holder configuration setup sub-phase processed by an AP is illustrated. After the TXOP holder configuration setup sub-phase begins at 812, at 814, the AP receives a TXOP holder configuration frame from a non-AP TXOP holder STA, indicating the allocation of RUs to other non-AP shared TXOP participant STAs. The AP stores the TXOP holder configuration information and, at 816, sends back a response frame acknowledging successful receipt. The AP then broadcasts a TXOP access configuration frame at 818 to announce the overall TXOP access configuration for all associated non-AP STAs, with processing concluding at 820.

[0253] Figure 39 An example embodiment of a TXOP holder configuration setup sub-phase processed by a non-AP TXOP holder STA is illustrated at 830. After the TXOP holder configuration setup sub-phase begins at 832, at 834, the non-AP TXOP holder STA sends a TXOP holder configuration frame to the associated AP and indicates the schedule for allocation of RUs to other non-AP shared TXOP participant STAs.

[0254] The response frame is checked at 836. If the non-AP STA does not receive any feedback from the associated AP within the TXOP holder STA configuration frame timeout, a timeout occurs at 838 and the non-AP TXOP holder STA should resend the TXOP holder configuration frame, as shown by executing return block 834.

[0255] Otherwise, if a response frame has been received, a check is performed at 840 to determine whether the non-AP STA has received a broadcast TXOP holder configuration frame from the AP. If it does not receive a broadcast TXOP access configuration frame within the timeout interval, a timeout occurs at 842, and execution returns to block 834, where the non-AP TXOP holder STA retransmits the TXOP holder configuration frame to the associated AP. Otherwise, if the configuration frame has been received, the STA is aware of the overall TXOP access configuration and updates its database of TXOP access configurations for all other STAs at 844, after which processing ends at 846.

[0256] Figure 40 Illustrated is an example embodiment 850 of the TXOP scheduling and access phase in a semi-static scenario without AP coordination. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0257] The non-AP TXOP holder STA begins UL data transmission after sending the TXOP sharing request trigger frame 852, and NAV (TXOP sharing trigger) 854 begins. Upon receiving the TXOP sharing request trigger frame, the non-AP shared TXOP participant STAs begin their UL data transmission 856, 858 in the allocated time slots (RUs), and the non-AP TXOP holder station transmits its UL data 860 in the reserved time slots (RUs), and the NAV (data) interval 862 begins. When the UL data transmission is complete, the AP sends a MU-BA 864.

[0258] Figure 41An example embodiment 870 of the TXOP scheduling and access phase handled by a non-AP TXOP holder STA for a semi-static scenario without AP coordination is illustrated. After the TXOP scheduling and access phase begins at 872, the non-AP TXOP holder STA broadcasts a TXOP sharing request trigger frame at 874. Then, at 876, the non-AP TXOP holder STA transmits UL data to the associated AP using the RUs configured in the TXOP holder configuration setup sub-phase. At 878, a check is performed to see if the non-AP TXOP holder STA has received a MU-BA frame from the AP within the TXOP sharing request trigger frame timeout interval. If it does not receive a MU-BA within the timeout interval, a timeout occurs at 880 and the STA retransmits the TXOP sharing request trigger frame, such as by executing return block 874. Otherwise, if a MU-BA is received within the timeout interval, the process ends at 882.

[0259] Figure 42 An example embodiment 890 illustrates the TXOP scheduling and access phase handled by a non-AP-shared TXOP participant STA for a semi-static scenario without AP coordination. After the TXOP scheduling and access phase begins at 892, the non-AP-shared TXOP participant STA checks at 894 whether it has received a broadcast TXOP sharing request trigger frame. If it has not received the frame, the process ends at 898. Otherwise, if the trigger frame has been received, at 896 the STA begins its UL data transmission using the RUs configured during the TXOP holder configuration setup sub-phase.

[0260] Figure 43 An example embodiment 910 of the TXOP scheduling and access phases in a semi-static scenario with the AP as the coordinator is illustrated. Again, by way of example and not limitation, this figure shows the same AP and STA participants as in the previous figures.

[0261] Since a non-AP TXOP holder STA cannot communicate directly with other non-AP STAs, it should first send a TXOP sharing request trigger frame 912 to the AP, and NAV (TXOP sharing request trigger) 914 begins. Once the AP receives the TXOP sharing request trigger frame, it broadcasts a TXOP sharing response trigger frame 916, and NAV (TXOP sharing response trigger) 918 begins. Once the TXOP sharing response trigger frame is sent / received, the non-AP TXOP holder STA and all non-AP shared TXOP participant STAs begin their UL data transmissions 920, 922, and 924, and NAV (data) 926 begins. Upon receiving UL data, the AP responds with MU-BA 928.

[0262] Figure 44 An example embodiment 930 illustrates the TXOP scheduling and access phase handled by a non-AP TXOP holder STA for a semi-static scenario with AP coordination. The TXOP scheduling and access phase begins at 932. Since a non-AP TXOP holder STA cannot communicate directly with other non-AP STAs, it first unicasts a TXOP sharing request trigger to the associated AP at 934. At 936, the non-AP TXOP holder STA checks whether it has received a TXOP sharing response trigger frame from the AP within the TXOP sharing request trigger frame timeout interval.

[0263] If no response is received within the time interval, a timeout occurs at 938 and the STA retransmits the TXOP sharing request trigger frame, e.g., execution moves back to block 934. Otherwise, a response is received, and then at 940 the non-AP TXOP holder STA begins sending UL data transmissions using the RUs configured in the TXOP holder configuration setup sub-phase, after which the process ends at 942.

[0264] Figure 45 An example embodiment 950 of the TXOP scheduling and access phase handled by an AP for a semi-static scenario with AP coordination is illustrated. After the TXOP scheduling and access phase begins at 952, at 954, it is checked whether the AP has received a TXOP sharing request trigger.

[0265] If no trigger has been received, the process ends at 964. Otherwise, if a trigger frame has been received, then at 956, the AP broadcasts a TXOP sharing response trigger frame in response to receiving a TXOP sharing request trigger frame from the non-AP TXOP holder STA.

[0266] A check is then performed at 958 to determine whether the AP has received any UL data. If the AP does not receive any UL data within the TXOP Shared Response Trigger frame timeout interval, a timeout occurs at 960, and execution returns to block 956, where the AP retransmits the TXOP Shared Response Trigger frame. Otherwise, once the AP completes receiving the UL data sequence, it responds by sending a MU-BA frame at 962, after which processing ends at 964.

[0267] 8. Frame format

[0268] 8.1.STA TXOP Shareability Elements

[0269] Figure 46Illustrated is an example embodiment 970 of a STA TXOP shareability element that is included in a management frame, such as but not limited to an authentication or association request frame, and is used by individual non-AP STAs to notify an associated AP of their TXOP shareability. At least one embodiment of the shareability element has the following fields. The element ID field identifies the particular element, and in the specific example case here, it is set to 8 to indicate that this is a STA TXOP shareability element. If an AP receives an authentication or association request frame with the element ID field set to 8, the AP should record all sharing offer / request information for each STA (as indicated in the STA Information field) and send back an authentication or association response frame to indicate successful reception. The length field indicates the number of octets in the element excluding the element ID field and the length field. Includes one or more STA information fields, whose subfields are in Figure 47 described in .

[0270] Figure 47 An example embodiment 990 of the STA Information (Info) field is illustrated, at least one embodiment of which has the following subfields. The AID subfield contains the AID of the STA for which TXOP shareability is indicated. The TXOP Share Holder subfield indicates the shareability of the STA as the TXOP holder. The TXOP Share Holder subfield is set to a first state (e.g., 1) to indicate that the STA, acting as the TXOP holder, is willing to share its TXOP with other STAs; otherwise, the subfield is set to a second state (e.g., 0) to indicate that the TXOP holder is unwilling to share its TXOP with other STAs. The TXOP Share Participant subfield indicates the shareability of the STA as a TXOP participant. The TXOP Share Participant subfield is set to a first state (e.g., 1) to indicate that the STA, acting as a shared TXOP participant STA, is willing to participate in the next TXOP to be shared by the TXOP holder STA; otherwise, the subfield is set to a second state (e.g., 0) to indicate that the STA is unwilling to participate in the next TXOP shared by the TXOP holder STA.

[0271] 8.2. Sharing Proposal / Request Frame

[0272] Figure 48An example embodiment 1010 of a sharing offer / request frame format is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The BSSID subfield is the MAC address of the AP with which the non-AP STA is associated. If the BSSID indicates the same MAC address as the TA, it indicates that the sharing offer / request frame is conveying shareability information for a non-AP STA from an intra-BSS; otherwise, it indicates that the sharing offer / request frame is conveying shareability information for a non-AP STA from an inter-BSS whose ID is indicated by the BSSID. A frame check sequence (FCS) is found here and in other data formats herein; the FCS provides an error detection code added to the frames of the communication protocol.

[0273] Figure 49 An example embodiment 1030 of the STA Sharing Proposal / Request Information field format is illustrated, at least one embodiment of which has the following fields. The STA Sharing Proposal / Request Information field indicates the TXOP sharing proposal / request information of a non-AP STA. The Priority field indicates the priority of traffic stored in the STA's buffer, which can be used by the TXOP holder for TXOP access scheduler design. The STA AID field contains the AID of the non-AP STA. The TXOP Sharing Request subfield is set to a first state (e.g., 1) to indicate that the STA is requesting a shared TXOP; otherwise, it is set to a second state (e.g., 0). When an AP receives a Sharing Proposal / Request frame with the TXOP Sharing Request field set to the first state, it informs the AP that the STA sending the frame is willing to participate in a shared TXOP. The TXOP Resource Request subfield indicates the number of consecutive RUs requested by the non-AP STA in the shared TXOP. In at least one embodiment, a basic RU subcarrier sequence of 26 subcarriers is utilized, although other RU subcarrier sequences may be utilized without departing from the teachings of this disclosure. In this example, valid values for the basic RU range from 1 to 37. The AP will broadcast this information in a sharing proposal / request frame.

[0274] The TXOP Sharing Proposal subfield is set to the first state (e.g., 1) to indicate that the STA is willing to become a non-AP TXOP holder STA and share its TXOP with other STAs; otherwise, the subfield is set to the second state. When the AP receives a sharing proposal / request frame with the TXOP Sharing Proposal field set to the first state, the AP knows that the STA that sent the frame is willing to share its TXOP with other STAs. The TXOP Resource Proposal subfield indicates the number of consecutive RUs that the TXOP holder STA is willing to share with other STAs. Again, as an example, this is described using the basic RU (26 subcarriers), but other subcarriers can be used without restriction. In this example, the valid values of the basic RU range from 1 to 37. The AP will broadcast this information in the sharing proposal / request frame.

[0275] 8.3.MU-RTS Shared Frame

[0276] Figure 50 An example embodiment 1050 of the frame format of a MU-RTS shared frame 1052 is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the frame type. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1054 and continues at 1058. The User Information List subfield is described below at 1056. The frame is illustrated here with padding and FCS.

[0277] The Common Information field 1054, which continues at 1058, has the following subfields. The Trigger Type subfield of the Common Information field identifies the trigger frame variant. By way of example and not limitation, if this field is set to 3 and the TXOP Share subfield (B63) is set to the first state (e.g., 1), this indicates that the frame is a MU-RTS Share frame. If an AP or non-AP STA receives a MU-RTS Share frame, it knows that a shared TXOP is initialized and that it should respond to the CTS Share frame using the designated RU indicated in the MU-RTS Share frame (indicated by the UL BW subfield of the Common Information field and the RU Allocation subfield of the User Information field). The UL Length subfield indicates the value of the L-SIG Length field of the requested HE TB PPDU. The More TF subfield indicates whether a subsequent trigger frame is scheduled for transmission. The CS Required subfield indicates whether the STA identified in the User Information field needs to consider the medium status or NAV when deciding whether to respond. The UL BW subfield indicates the bandwidth in the HE-SIG-A of the HE TB PPDU. The GI and HE-LTF Type subfields indicate the GI and HE-LTF type of the HE TB PPDU response. When the GI and HE-LTF Type subfields indicate 2x HE-LTF + 1.6μs GI or 4x HE-LTF + 3.2μs GI, the MU-MIMO HE-LTF Mode subfield indicates the HE-LTF mode of the non-OFDMA MU-MIMO HE TB PPDU response. Otherwise, this subfield is set to indicate the HE single-stream pilot HE-LTF mode. If the Doppler subfield is 0, the HE-LTF Symbol Number and Midamble Periodicity subfields indicate the number of HE-LTF symbols present in the HE TB PPDU, and if the Doppler subfield is 1, the HE-LTF Symbol Number and Midamble Periodicity subfields indicate the periodicity of the HE-LTF symbols and midamble.

[0278] In the lower portion of the figure, the common information field continues at 1058 with the following subfields. The UL STBC subfield indicates the status of the STBC encoding of the requested HE TB PPDU. The LDPC Extra Symbol Segment subfield indicates the status of the LDPC extra symbol segment. The AP / Non-AP TXOP Owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or non-AP TXOP holder STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth. The Pre-FEC Filling Factor subfield indicates the Pre-FEC filling factor. The PE Disambiguation subfield indicates PE disambiguation. The UL Spatial Reuse subfield carries the value to be included in the Spatial Reuse field in the HE-SIG-A field of the requested HE TB PPDU. The Doppler subfield is set to a first state (e.g., 1) to indicate the presence of a midamble in the HE TB PPDU, and is otherwise set to a second state (e.g., 0). The UL HE-SIG-A2 Reserved subfield carries the value of the Reserved field in the HE-SIG-A2 subfield of the requested HE TB PPDU to be included. The TXOP Sharing subfield indicates, by a first state (e.g., 1), that the sender is willing to share the TXOP with other non-AP STAs; otherwise, the TXOP Sharing subfield is set to a second state (e.g., 0). The Trigger-Related Common Information subfield optionally exists based on the value of the Trigger Type field.

[0279] The User Information List field contains a list of user information. For each User Information subfield 1056, the following subfield 1057 contains information about the RUs allocated to a specific STA. The AID12 subfield is used to allocate a fixed RU to a specific STA whose AID equals the value in the AID12 subfield. The RU Allocation subfield, together with the UL BW subfield in the Common Information field, identifies the size and location of the RU. The UL FEC Coding Type subfield indicates the code type of the requested HE TB PPDU. The UL HE-MCS subfield indicates the HE-MCS of the requested HE TB PPDU. The UL DCM subfield indicates the DCM of the requested HE TB PPDU. The combined SS Allocation / RA-RU subfield is used as follows. The SS Allocation subfield indicates the spatial stream of the requested HE TB PPDU, while the RA-RU Information subfield indicates RA-RU information. The UL Target RSSI subfield indicates the expected received signal power of the HE portion of the HE TB PPDU transmitted on the allocated RU. Based on the value of the Trigger Type field, the Trigger-Related User Information subfield optionally exists.

[0280] 8.4.CTS Sharing

[0281] Figure 51 An example embodiment 1070 of the format of a CTS sharing frame is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TXOP Sharing Participant AID field indicates the AID of the TXOP Sharing Participant sending the CTS Sharing frame.

[0282] Once the TXOP holder receives the CTS sharing frame, it will know which STA is willing to join the shared TXOP by checking the TXOP sharing participant AID information, and thus allocate resources to the STA accordingly. If a non-AP STA receives the MU-RTS sharing frame but has nothing to send to the AP, the non-AP STA should set the TXOP sharing participant AID to the second state (e.g., 0) to indicate that it will not join the next shared TXOP.

[0283] 8.5. Random TXOP Access Request Trigger Frame

[0284] Figure 52 An example embodiment 1090 of a frame format for a TXOP random access request trigger is illustrated, at least one embodiment of which has the following fields 1092. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1094, 1100, and 1104. The User Information List subfield is described below at 1096. The frame is illustrated here with padding and FCS.

[0285] The public information subfield 1094 has the following subfields. The trigger type subfield utilizes the previously reserved space, and in the present disclosure, it is set to a specific value (e.g., 8, as an example and not a limitation) to indicate that it is a TXOP random access request trigger frame. The TXOP holder STA will reserve RUs for itself and share the remaining RUs with other STAs. After issuing a TXOP random access request trigger in a scenario without AP coordination, or after receiving a TXOP random access request trigger in a scenario with AP coordination, the TXOP holder STA unicasts UL data to the AP in the reserved RUs. After receiving the TXOP random access request trigger, the TXOP sharing participant STAs randomly access the channel and compete for the shared RUs.

[0286] Except as follows, the remaining subfields are Figure 50 Same as described in .

[0287] In the lower portion 1100 of the common information are subfields used as follows: The AP / Non-AP TXOP Owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or non-AP TXOP holder STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth.

[0288] The TXOP holder STA announces the reserved RUs through the UL BW subfield of the public information and the RU allocation subfield of the user information field. In addition, it will announce its own AID in the AID12 subfield. In this example, the range of the AID12 subfield should be 1 to 2007.

[0289] The User Information List field in the Random Access Request Trigger frame contains a list of User Information fields 1096, each with subfields shown below it at 1098. For other associated STAs, the AID12 subfield of the User Information field is set to 0, and then fields B26-B31 of the User Information field, labeled here as SS Allocation / RA-RU Information, are used to provide RA-RU information with subfield 1102. The Number of RA-RUs subfield indicates the number of consecutive RUs allocated for UL OFDMA Random Access (UL OFDMA Random Access). The value of the Number of RA-RUs subfield is equal to the number of connected RA-RUs minus 1. The More RA-RUs subfield is set to a first state (e.g., 1) to indicate that RA-RUs of the type indicated by the AID12 subfield in the User Information field are allocated in subsequent trigger frames transmitted until the end of the TWT SP in which the trigger frame carrying this field is transmitted; otherwise, the subfield is set to a second state (e.g., 0). If the More TF field in the Common Information field is set to 0, the More RA-RUs subfield is reserved.

[0290] 8.6. Unicast TXOP Access Request Trigger Frame

[0291] Figure 53 An example embodiment 1110 of a unicast TXOP access request trigger frame format is illustrated, at least one embodiment of which has the following fields 1112. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1114 and continues to 1118. The User Information field, with its subfields, is described below at 1116. The frame is illustrated here with padding and FCS.

[0292] The public information field has the following subfields 1114. Unspecified fields / subfields have the same data structure as previously described herein, such as Figure 50 and Figure 52 The Trigger Type subfield, which was previously a reserved field, is used to indicate the type of trigger frame, in this case a unicast TXOP access request trigger frame, and is set to 9 in this particular example as an example.

[0293] The following applies to the single BSS scenario. (a) After sending the last unicast TXOP access request trigger frame (indicated by the TXOP Access Start Flag subfield), the TXOP holder STA unicasts UL data to the AP in the reserved RUs. (b) After receiving the last unicast TXOP access request trigger frame (even if the destination is another STA), the TXOP sharing participant STA unicasts UL data to the AP in the allocated RUs.

[0294] In data segment 1118, the AP / non-AP TXOP owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or the non-AP TXOP holder STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth.

[0295] Going to the user field, a list of user information subfields can be seen in 1116, each of which contains subfields 1117. Unexplained fields / subfields have the same data structure as previously described, such as Figure 50 and Figure 52 The same functions as described in the data structure shown in . The AID12 subfield of the user information field (e.g., a value from 1 to 2007) is addressed to the associated STA whose AID is equal to the value in the AID12 subfield. This STA is a shared TXOP participant STA. The RU allocation subfield, together with the UL BW subfield in the common information field, identifies the size and location of the RU. The single BSS subfield indicates whether the unicast TXOP access request trigger frame is sent in a single BSS scenario or in an OBSS scenario. For a single BSS scenario, the TXOP access start flag subfield is used to indicate the last unicast TXOP access request trigger frame. The data delay subfield will not be used in this example. For the OBSS scenario, the data delay subfield is used to indicate the delay in sending data. Similarly, the TXOP access start flag subfield will not be used in this example.

[0296] The TXOP Access Start Flag subfield indicates whether the unicast TXOP Access Request Trigger frame was sent by the TXOP holder to the last TXOP-sharing participant STA. If this is the last TXOP-sharing participant STA, this field is set to the first state (e.g., 1); otherwise, it is set to the second state (e.g., 0). For each TXOP-sharing participant STA that receives a unicast TXOP Access Request Trigger, even if the frame is not addressed to it, the STA still checks the TXOP Access Start Flag subfield. If this field is set to the second state, the STA retains the data; otherwise, if this field is set to the first state, the STA sends its data to the AP. The Data Delay subfield indicates the delay between a non-AP STA sending / receiving a unicast TXOP Access Request Trigger frame and sending UL data.

[0297] 8.7. Broadcast TXOP Access Request Trigger Frame

[0298] Figure 54 An example embodiment 1130 of a broadcast TXOP access request trigger frame format 1132 is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1134 and extends to 1136 and 1142. The User Information field, having subfields 1138 and 1140, is described below. The frame is illustrated here with padding and FCS.

[0299] The common information field has the following subfields 1134. Unspecified fields / subfields have the same meaning as those in the previously described data structures (e.g. Figure 50 and Figure 52 As an example and not a limitation, the trigger type subfield of the common information field is set to 10 in this example to indicate that it is a broadcast TXOP access request trigger frame.

[0300] The following situations apply to the single BSS scenario. (a) After sending a broadcast TXOP access request trigger frame, the TXOP holder STA unicasts UL data to the AP in the reserved RUs. (b) After receiving a broadcast TXOP access request trigger frame, the TXOP sharing participant STA unicasts UL data to the AP in the allocated RUs.

[0301] Continuing with subfield 1136, the AP / non-AP TXOP owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or the non-AP TXOP holder STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth.

[0302] The User Information List field has the following subfields 1138 and 1140. Multiple user information items 1138 may be retained, each having the format illustrated in 1140. The AID12 subfield of the User Information field (e.g., with a value range of 1 to 2007) is addressed to the associated STA whose AID is equal to the value in the AID12 subfield. This STA is a shared TXOP participant STA. The RU Allocation subfield, together with the UL BW subfield in the Common Information field, identifies the size and location of the RU. The Data Delay subfield indicates the delay duration for non-AP STAs whose AID is equal to the value in the AID12 subfield to transmit UL data.

[0303] 8.8.CTS-to-self sharing

[0304] Figure 55

[00106] The diagram illustrates an example embodiment 1150 of a CTS-to-self shared frame format, at least one embodiment of which has the following fields: The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame.

[0305] In a single BSS scenario, the TXOP holder STA can first unicast a CTS-to-self frame with the RA field equal to the AP's own MAC address to the AP to reserve the medium for TXOP transmission. When the AP receives the CTS-to-Self sharing frame, it broadcasts a MU-RTS sharing frame to potential TXOP sharing participant STAs.

[0306] The NAV can be set in the duration field of the CTS-to-self sharing frame. Bits 0-13 are set to contain the NAV duration value, which ranges from 1 to 16,383. Bits 14-15 are set to 01, indicating sharing information. This means that the TXOP holder is willing to share the TXOP with other STAs. The AP receives the CTS-to-self frame from the TXOP holder STA and sends the MU-RTS sharing frame to potential TXOP sharing participant STAs.

[0307] 8.9.TXOP Participant Advertisement Frame

[0308] Figure 56An example embodiment 1170 of the frame format of a TXOP participant announcement frame is illustrated, at least one embodiment of which has the following fields. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. One or more STA TXOP participant fields (e.g., 1-n) are included, such as Figure 57 As shown in and described below.

[0309] Figure 57 An example embodiment 1190 of a frame format for the STA TXOP participant field format, known to the AP / TXOP holder through the periodic exchange of BSRP and BSR frames, is illustrated, at least one embodiment of which has the following fields. The Source AID subfield and the Destination AID subfield indicate the AIDs of the source and destination STAs, respectively. The ACI Bitmap subfield indicates the access category for which the buffer status is reported. The Delta TID subfield, together with the value of the ACI Bitmap subfield, indicates the number of TIDs for which the STA reports the buffer status. The ACI High subfield indicates the ACI of the AC for which the frame is indicated in the Queue Size High subfield. The Scale Factor (SF) subfield indicates the SF units of the Queue Size High and Queue Size All subfields in octets. The Queue Size High subfield indicates the amount of buffered traffic for the AC identified by the ACI High subfield, in SF octets, intended for the STA identified by the receiver address of the frame containing the Frame Control subfield. The Queue Size Total subfield indicates, in units of SF octets, the amount of buffered traffic for all ACs identified by the ACI Bitmap subfield intended for the STA identified by the receiver address of the frame containing the Frame Control subfield.

[0310] 8.10.TXOP Access Scheduler Trigger Frame

[0311] Figure 58 An example embodiment 1210 of a TXOP Access Scheduler Trigger frame format 1212 is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the frame type. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1214 and extends to 1220 and 1222. The User Information field, with its subfields, is described below at 1216 and 1218. The TXOP Access Scheduler Trigger frame is illustrated here with padding and FCS.

[0312] The Common Information field includes the following subfields 1214. The Trigger Type subfield of the Common Information field is set (using the previously reserved bit) to indicate that it is a TXOP Access Scheduler Trigger frame, which is set to 11 as an example and not limitation.

[0313] The Trigger Type subfield is used in a single BSS scenario as follows. (1) After sending a TXOP Access Scheduler Trigger frame, the TXOP holder STA unicasts UL data to the AP after receiving the last unicast TXOP Access Request Trigger frame. (2) After receiving the TXOP Access Scheduler Trigger frame, the AP sends a unicast TXOP Access Request Trigger frame to each TXOP sharing participant STA. When sending the last unicast TXOP Access Request Trigger frame, the AP sets the TXOP Access Start Flag subfield to the first state (e.g., 1).

[0314] At 1220, the AP / Non-AP TXOP Owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or non-AP TXOP owner STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth. Unexplained fields / subfields have the same functions as those described above with respect to the data structure.

[0315] The User Information List field has the following subfields 1216 and 1218. A list of user fields is shown at 1216, each containing information shown at 1218, including the following subfields. The AID12 subfield of the User Information field (e.g., a value range of 1-2007) is addressed to the associated STA whose AID is equal to the value in the AID12 subfield. This STA is a shared TXOP participant STA. The RU Allocation subfield, together with the UL BW subfield in the Common Information field, identifies the size and location of the RU. The Data Delay subfield of the User Information field indicates the delay duration for non-AP STAs whose AID is equal to the value in the AID12 subfield to transmit UL data.

[0316] 8.11.TXOP Priority Trigger Frame

[0317] Figure 59An example embodiment 1230 of the TXOP Priority Trigger frame format is illustrated, at least one embodiment of which has the following fields. The Frame Control field indicates the frame type. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the MAC address of the receiver of the frame. The TA field contains the MAC address of the STA that sent the frame. The Common Information field is described below at 1234 and continues to 1240. The User Information field is described below using subfields 1236 and 1238. This frame is illustrated here with padding and FCS.

[0318] The Common Information field includes the following subfields 1234, and undescribed fields / subfields have the same functions as the data structures described previously herein: The Trigger Type subfield of the Common Information field (using the previously reserved bit) is set to indicate that this is a TXOP Priority Trigger frame, and as an example and not a limitation, it is set to 12.

[0319] The TXOP holder STA reserves RUs for itself and shares the remaining RUs with other STAs. After unicasting a TXOP priority trigger frame to the AP, the TXOP holder waits for a trigger frame from the AP with scheduled TXOP access information. After receiving the TXOP priority trigger frame, the AP schedules shared TXOP access and triggers UL transmission. The AP also allocates more resources to the TXOP holder STA.

[0320] Continuing with subfield 1240, the AP / non-AP TXOP owner STA Tx Power subfield indicates the combined transmit power (in dBm) of the AP (for dynamic scenarios with the AP as the coordinator) or the non-AP TXOP holder STA (for dynamic scenarios without the AP as the coordinator) at the antenna connectors of all transmit antennas used to transmit the trigger frame and normalized to a 20 MHz bandwidth.

[0321] Turning to the User Information List field, subfields 1236 and 1238 are visible. Unexplained fields / subfields have the same functions as the data structures described previously herein. Multiple user information 1236 may be retained (only one user information is shown here as an example), each having the format illustrated in 1238. The AID12 subfield of the User Information field (e.g., having a value range of 1 to 2007) is addressed to the associated STA whose AID is equal to the value in the AID12 subfield; thus, this STA is a shared TXOP participant STA.

[0322] The RU Allocation subfield, together with the UL BW subfield in the Common Information field, identifies the size and location of the RU.

[0323] The Priority subfield of the User Information field indicates the priority of the STA that sent the TXOP Priority Trigger frame. When set to the first state (e.g., 1), it indicates that the sender is the TXOP holder, and the AP should allocate a sufficient RU size that cannot be smaller than the RU size indicated by the RU Allocation subfield and the UL BW subfield.

[0324] 8.12.TXOP Holder Configuration

[0325] Figure 60

[00106] An example embodiment 1250 of the TXOP Holder Configuration frame format is illustrated, at least one embodiment of which has the following fields. The STA TXOP Access Allocation field indicates the TXOP access allocation for each specific STA. After the AP receives the TXOP Holder Configuration frame, the AP records the STA TXOP access allocation information and sends an acknowledgment frame to the STA.

[0326] Figure 61 The diagram shows Figure 60 The example embodiment 1270 of the frame format of the STA TXOP access allocation field illustrated in FIG. 1 has the following fields in at least one embodiment. The TXOP holder MAC address subfield indicates the MAC address of the TXOP holder. The TXOP participant MAC address subfield indicates the MAC address of the TXOP sharing participant STA. The allocation control information subfield indicates the TXOP resource allocation for a specific TXOP sharing participant STA and is shown in FIG. Figure 62 middle.

[0327] Figure 62 The diagram illustrates an example embodiment 1290 of the Priority subfield of the Allocation Control Information subfield, which indicates the priority of traffic for a TXOP sharing participant STA, at least one embodiment of which has the following subfields. The AID12 subfield (e.g., a value ranging from 1 to 2007) of the Allocation Control Information subfield indicates that the Allocation Control Information subfield is addressed to the associated STA whose AID is equal to the value in the AID12 subfield. The UL BW subfield of the Allocation Control Information subfield indicates the bandwidth in the HE-SIG-A of the HE TB PPDU. The RU Allocation subfield, together with the UL BW subfield, identifies the size and location of the allocated RUs.

[0328] 8.13.TXOP Access Configuration

[0329] Figure 63An example embodiment 1310 of the TXOP access configuration frame format is illustrated, at least one embodiment of which has the following fields 1312. Frame control, duration, RA, and TA are used as described in the previous sections. There may be multiple STA configuration fields (e.g., 1 to N) indicating the configuration of each non-AP STA. The STA configuration field format is illustrated in the lower portion 1314 of the figure and includes the following fields: Figure 61 TXOP access allocation for each non-AP STA is shown in . After receiving a trigger from the TXOP holder (not using the AP as a coordinator) or from the associated AP (using the AP as a coordinator), the STA uses the allocated RUs to send data to the AP.

[0330] 8.14.TXOP Sharing Request Trigger

[0331] Figure 64 This diagram illustrates an example embodiment 1330 of a TXOP Sharing Request Trigger frame format, at least one embodiment of which has the following fields. Frame control, duration, and common information are as described in the previous sections, while the User Information field is not required in this TXOP Sharing Request Trigger frame format. The TA field contains the MAC address of the transmitter station and should be set to the MAC address of the TXOP holder. The RA field contains the MAC address of the receiver, as described below.

[0332] In scenarios where the AP is not acting as the coordinator, the RA field is set to the broadcast MAC address (ff:ff:ff:ff:ff:ff). The TXOP holder broadcasts a TXOP Sharing Request Trigger frame. Once the TXOP Sharing Participant STAs receive this frame, they should send UL data to the associated AP using the allocated RUs configured during the shared TXOP configuration phase. After sending the TXOP Sharing Request Trigger frame, the TXOP holder uses the reserved RUs to send UL data to the associated AP.

[0333] In scenarios where the AP is used as a coordinator, the RA field is set to the MAC address of the associated AP. The TXOP holder unicasts a TXOP Sharing Request Trigger frame. Once the AP receives this frame, it broadcasts a TXOP Sharing Response Trigger frame. All applicable STAs should then send UL data to the associated AP using the allocated RUs configured during the shared TXOP configuration phase.

[0334] 8.15.TXOP Sharing Response Trigger

[0335] Figure 65This diagram illustrates an example embodiment 1350 of the TXOP Sharing Response Trigger frame format, at least one embodiment of which has the following fields. The Frame Control, Duration, and Common Information fields are as described in the previous sections, while the User Information List field is not required in this TXOP Sharing Request Trigger frame format. The RA field is the receiver's MAC address; in scenarios using an AP as a coordinator, it is set to the broadcast MAC address (ff:ff:ff:ff:ff:ff). The Data Delay field indicates the duration of the delay between receiving the TXOP Sharing Response Trigger and sending UL data in OBSS scenarios.

[0336] 9. General Scope of the Embodiments

[0337] The enhancements described in this technology can be easily implemented in various wireless network communication stations. It should also be appreciated that the wireless network communication station is preferably implemented as a computer including one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer-enabled ASIC, etc.) and an associated memory (e.g., RAM, DRAM, NVRAM, FLASH, computer-readable media, etc.) storing instructions, so that the programming (instructions) stored in the memory are executed on the processor to perform the steps of the various processing methods described herein.

[0338] For simplicity of illustration, computers and storage devices are selectively depicted, as one of ordinary skill in the art will recognize the use of computer devices to perform steps involving digital wireless communication. The present technology is not limited to memory and computer-readable media, as long as these memory and computer-readable media are non-transitory and do not constitute transitory electronic signals.

[0339] 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 processes, algorithms, steps, operations, formulas, or other computational descriptions that may also be implemented as computer program products. In this regard, each box or step of the flowchart, and combinations of boxes (and / or steps) in the flowchart, and any process, algorithm, step, operation, formula, or computational description may be implemented by various means, such as hardware, firmware, and / or software, including one or more computer program instructions embodied in computer-readable program code. It should be appreciated that any such computer program instructions may be executed by one or more computer processors (including, but not limited to, general-purpose computers or special-purpose computers), or other programmable processing devices, to produce a machine, such that the computer program instructions executed on the computer processor or other programmable processing device create a device for implementing the specified functions.

[0340] Thus, the blocks of the flowcharts, and the processes, algorithms, steps, operations, formulas, or calculation descriptions described herein support combinations of devices for performing specified functions, combinations of steps for performing specified functions, and computer program instructions (such as embodied as computer-readable program code logic devices) for performing specified functions. It should also be understood that each block of the flowcharts, and any processes, algorithms, steps, operations, formulas, or calculation descriptions and combinations thereof described herein can be implemented using a computer system based on dedicated hardware that performs the specified functions or steps, or a combination of dedicated hardware and computer-readable program code.

[0341] It should be appreciated that the boxes at the beginning and end of these flowcharts, such as "Start" and "Stop," do not imply that the instructions are limited to a particular routine, or that they themselves have actual starts and stops, but are merely provided as reference points with respect to the steps involved in performing the processing. The associated instructions of these processing steps may be executed within various routines, tasks, slices, threads, etc. without limitation, and these steps may be combined with other steps to perform other functions, or may be expanded to provide additional functionality without departing from the teachings of the present disclosure.

[0342] In addition, these computer program instructions (e.g., embodied as computer-readable program code) may also be stored in one or more computer-readable memories or storage devices, which may instruct a computer processor or other programmable processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory or storage device produce an article of manufacture including instruction means for implementing the functions specified in the blocks of the flowchart. The computer program instructions may also be executed by a 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, thereby producing a computer-implemented process, such that the instructions executed on the computer processor or other programmable processing device provide steps for implementing the functions specified in the blocks, procedures, algorithms, steps, operations, formulas, or calculation descriptions of the flowchart.

[0343] It should also be appreciated that the terms "programming" or "executable program" as used herein refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions described herein. The instructions may be embodied as software, firmware, or a combination of software and firmware. The instructions may be stored locally on the device in a non-transitory medium, or may be stored remotely, such as on a server, or all or part of the instructions may be stored locally and remotely. Remotely stored instructions may be downloaded (pushed) to the device by the user, or automatically downloaded (pushed) to the device based on one or more factors.

[0344] It should also be appreciated that the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer as used herein are used synonymously to refer to a device capable of executing instructions and communicating with input / output interfaces and / or peripherals, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass one or more devices, single-core and multi-core devices, and variations thereof.

[0345] Based on the description herein, it should be appreciated that the present disclosure encompasses multiple implementations of the technology, including but not limited to the following implementations:

[0346] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first station for wireless communication with at least one other station; (b) a processor coupled to the wireless communication circuitry within a station configured to operate on a wireless network; (c) a non-transitory memory storing instructions, the instructions being executable by the processor; and (d) wherein the instructions, when executed by the processor, cause a non-access point (non-AP) station to share a transmit opportunity (TXOP) in a frequency domain with other stations in a single basic service set (BSS) scenario by performing steps comprising: (d)(i ) exchanging messages with an access point (AP) station to notify the AP and / or obtain AP approval when sharing the TXOP of the non-AP station with other stations; (d)(ii) exchanging information with other stations to indicate that the TXOP can be used for sharing and identifying non-AP shared TXOP participant stations based on received responses; and (d)(iii) sending messages to non-AP shared TXOP participant stations willing to join the next shared TXOP, wherein the message includes information of resource units (RUs) for each non-AP shared TXOP participant station, the RUs being used to send uplink (UL) data within the shared TXOP during channel access.

[0347] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first wireless station for wireless communication with at least one other station; (b) a processor of the first station configured to operate on a wireless network; (c) a non-transitory memory storing instructions, the instructions being executable by the processor; and (d) wherein the instructions, when executed by the processor, cause a non-access point (non-AP) station to share a transmit opportunity (TXOP) in a frequency domain with other stations in a single basic service set (BSS) scenario by performing steps comprising: (i) exchanging messages with an access point (AP) station to transmit a TXOP in a frequency domain; (d)(iii) sending a message to non-AP shared TXOP participant stations that are willing to join the next shared TXOP through coordination of the AP station, indicating the RU that each of these non-AP shared TXOP participant stations should use to send UL data when the channel is accessed.

[0348] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first wireless station for wireless communication with at least one other station; (b) a processor of the first station configured to operate on a wireless network; (c) a non-transitory memory storing instructions, the instructions being executable by the processor; and (d) wherein the instructions, when executed by the processor, enable a non-access point (non-AP) station to share a transmit opportunity (TXOP) with other stations in a single basic service set (BSS) scenario in the frequency domain by performing steps comprising: (d)(i) each non-AP station determining which of the other non-AP stations can access the shared TXOP of the non-AP station if it is to be the shared TXOP holder; (d)(ii) communicating, through coordination by the AP stations, a configuration of RU allocation and access order for each potential shared TXOP participant station as a semi-static configuration as advertised; and (d)(iii) each non-AP station accessing the shared TXOP initiated by a specific shared TXOP holder station in accordance with the advertised semi-static configuration.

[0349] A STA that obtains a TXOP in a wireless LAN network shares the TXOP of the STA with other STAs in a single BSS in the frequency domain by performing the following steps: (a) exchanging messages with the AP to notify and / or obtain permission to share the STA's TXOP with other non-AP STAs; and (b) upon obtaining access to a channel, exchanging information with other STAs through AP coordination to indicate that the upcoming TXOP can be shared and to identify STAs willing to join the upcoming shared TXOP.

[0350] A STA that obtains a TXOP in a wireless LAN network shares the TXOP of the STA with other STAs in a single BSS scenario in the frequency domain by performing the following steps: (a) exchanging messages with the AP to notify and / or obtain permission to share the TXOP of the STA with other STAs; (b) upon obtaining access to a channel, exchanging information with other STAs to indicate that the upcoming TXOP can be used for sharing, and identifying non-AP shared TXOP participant STAs based on the response; (c) sending messages to non-AP shared TXOP participant STAs that are willing to join the next shared TXOP, and notifying the RU that each non-AP shared TXOP participant STA should use to send UL data when channel access occurs; (d) non-AP STAs exchange information on TXOP shareability by exchanging management frames (such as authentication / association request / response frames and beacon frames) under the coordination of the AP; (e) AP and non-AP STAs periodically exchange traffic information using BSRP frames and BSR frames; and (f) after channel sounding, the TXOP holder STA sends MU-RTS sharing frames to other STAs and receives CTS sharing frames from those STAs that are willing to join the next shared TXOP.

[0351] The apparatus or method of any preceding implementation, wherein the non-AP stations exchange information regarding TXOP shareability by exchanging management frames under the coordination of an AP station.

[0352] The apparatus or method of any preceding implementation, wherein the management frame is selected from a group of message frames consisting of an authentication frame, an association frame, a request frame, a response frame, and a beacon frame.

[0353] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise periodically exchanging traffic information between the non-AP station and the AP station.

[0354] The apparatus or method of any preceding implementation, wherein the traffic information is exchanged using a combination of a Buffer Status Report Poll (BSRP) frame and a Buffer Status Report (BSR) frame.

[0355] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: channel sounding by the TXOP holder station, the TXOP holder station sending MU-RTS shared frames to other stations and receiving CTS shared frames from other stations willing to join the next shared TXOP.

[0356] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: a TXOP holder station initiating shared TXOP access by sending a trigger frame, the trigger frame being selected from a group of messages consisting of: (a) a unicast TXOP access request trigger sent to each specific station using an allocated RU; (b) a broadcast TXOP access request trigger sent to all non-AP shared TXOP participant stations using an allocation of RU information indicated for each non-AP shared TXOP participant station among all non-AP shared TXOP participant stations; and (c) a TXOP random access request trigger broadcast to other stations and triggering random access of other stations using shared RUs.

[0357] The apparatus or method of any preceding implementation, wherein upon receiving a trigger frame from the TXOP holder station, other TXOP participant stations access the channel according to access information contained in the trigger frame.

[0358] The apparatus or method of any preceding implementation, wherein said exchanging of TXOP shareability information is performed by exchanging management frames under the coordination of an AP station.

[0359] The apparatus or method of any preceding implementation, wherein the management frame is selected from a group consisting of an authentication frame, an association frame, a request frame, a response frame, and a beacon frame.

[0360] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: periodically exchanging buffer status and traffic priority information between the non-AP station and the AP station.

[0361] The apparatus or method of any preceding implementation, wherein the buffer status and traffic priority information is exchanged using a combination of a Buffer Status Report Poll (BSRP) frame and a Buffer Status Report (BSR) frame.

[0362] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: the AP station receiving a CTS-to-self sharing frame from a non-AP TXOP holder station, the AP station sending a MU-RTS sharing frame to other stations, and receiving a CTS sharing frame from other stations willing to join a subsequent shared TXOP, wherein the AP station sends participant information to the non-AP TXOP holder station in a TXOP participant announcement frame.

[0363] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, comprise: the non-AP TXOP holding station initiating access to the shared TXOP by: (a) sending a TXOP access scheduler trigger frame to the AP station, the TXOP access scheduler trigger frame indicating an allocation of RUs to each of the other stations sharing the upcoming TXOP; or (b) sending a TXOP priority trigger frame to the AP station, wherein the TXOP priority trigger frame indicates a priority to the TXOP holder and allows the AP station to schedule RU allocation.

[0364] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further perform one or more steps, including, upon receiving a TXOP access scheduler trigger at an AP station, performing steps comprising: (a) unicasting a TXOP access request trigger to each specific station using the RU allocated to each specific station; or (b) broadcasting a TXOP access request trigger to all non-AP shared TXOP participant stations, wherein the TXOP access request trigger includes the RU allocated to each of all non-AP shared TXOP participant stations.

[0365] The apparatus or method of any preceding implementation, wherein an AP station receiving a TXOP priority trigger performs steps comprising: (a) performing scheduling based on the latest traffic information indicated in a BSR frame from each other station and triggering UL transmission using a basic trigger; or (b) broadcasting a TXOP random access request trigger to non-AP stations and triggering random access of non-AP shared TXOP participant stations to access the channel using RA-RU.

[0366] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: the AP station triggering a non-AP TXOP holder station to access a channel using a reserved RU.

[0367] The apparatus or method of any preceding implementation, wherein when a trigger frame is received from the AP, the non-AP TXOP sharing participant station accesses the channel according to the access information indicated in the trigger frame, and wherein the non-AP TXOP holder STA accesses the channel using a reserved RU.

[0368] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise: executing, by a non-AP station, a setup procedure to set a semi-static configuration by: (a) the non-AP station exchanging sharing proposal / request frames with other non-AP stations through coordination by an AP station; (b) the AP station forwarding the shareability information of the non-AP station to all other non-AP stations; (c) the non-AP station exchanging configurations of semi-static TXOP sharing scheduling with all other non-AP stations through coordination by the AP station; and (d) the AP station forwarding the shared TXOP access information to all non-AP stations using a TXOP access configuration frame.

[0369] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise the non-AP station sharing the non-AP station's TXOP with other non-AP stations according to the announced allocation schedule.

[0370] The apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further comprise a non-AP TXOP holder station acquiring a channel and: (a) broadcasting a TXOP sharing request trigger without an AP station as a coordinator; or (b) unicasting a TXOP sharing request trigger to the AP station with the AP station as a coordinator; and wherein in response to (b), the AP station broadcasts a TXOP sharing response trigger.

[0371] The apparatus or method of any preceding implementation, wherein when a non-AP station receives the broadcast TXOP sharing request frame, the non-AP station accesses the channel based on the advertised RU allocation.

[0372] The apparatus or method of any preceding implementation, wherein a message is sent to non-AP shared TXOP participant STAs willing to join the next shared TXOP through coordination of the AP, and notifies the RU that each non-AP shared TXOP participant STA should use to send UL data when channel access occurs.

[0373] The apparatus or method of any preceding implementation, wherein the STAs exchange TXOP shareability information by exchanging management frames (such as authentication / association request / response and beacon frames) under the coordination of the AP.

[0374] The apparatus or method of any preceding implementation, wherein the AP and non-AP STAs periodically exchange buffer status and traffic priority information using BSRP frames and BSR frames.

[0375] The apparatus or method of any preceding implementation, wherein, after receiving a CTS-to-Self sharing frame from a non-AP TXOP holder STA, the AP sends a MU-RTS sharing frame to other STAs and receives a CTS sharing frame from those STAs willing to join the next shared TXOP; and wherein the AP sends information about participating stations to the non-AP TXOP holder STAs using a TXOP participant announcement frame.

[0376] The apparatus or method of any preceding implementation, wherein a TXOP holder STA initiates a shared TXOP by sending a trigger frame, the trigger frame comprising: (a) a unicast TXOP access request trigger sent to each specific STA using an allocated RU; (b) a broadcast TXOP access request trigger sent to all non-AP shared TXOP participant STAs using an allocation of RU information indicated for each non-AP shared TXOP participant STA among all non-AP shared TXOP participant STAs; or (c) a TXOP random access request trigger broadcast to other STAs and triggering random access of other STAs using a shared RU.

[0377] The apparatus or method of any preceding implementation, wherein upon receiving a trigger frame from a TXOP holder STA, other TXOP sharing participant STAs access the channel according to access information indicated in the trigger frame.

[0378] The term "implementation" as used herein is intended to include, but is not limited to, embodiments, examples, or other forms of practicing the techniques described herein.

[0379] As used herein, the singular forms "a," "an," and "the" may include plural referents unless the context clearly indicates otherwise. Unless otherwise specified, reference to an object in the singular is not intended to mean "there is and only one" but rather "one or more."

[0380] Phrases such as "A, B, and / or C" within the present disclosure indicate that A, B, or C can be present, or any combination of items A, B, and C. Phrases such as "at least one of" preceding a list of elements indicate that at least one of the group of elements is present, including any possible combination of the listed elements as applicable.

[0381] 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 embodiment is included in at least one embodiment of the disclosure. Thus, these different embodiment phrases are not necessarily all referring to the same embodiment or to a particular embodiment that is different from all other described embodiments. The embodiment language should be interpreted as meaning that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

[0382] As used herein, the term "group" refers to a collection of one or more objects. Thus, for example, a group of objects may include a single object or multiple objects.

[0383] Relational terms such as first and second, top and bottom, and the like are used solely to distinguish one entity or action from another and do not necessarily require or imply any actual such relationship or order between such entities or actions.

[0384] The terms "comprises," "having," "includes," "contains," or any variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises, has, includes, or contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprises," "having," "includes," or "contains" does not, without more constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, or contains that element.

[0385] As used herein, the terms "approximately," "approximately," "substantially," and "about," or any other versions thereof, are used to describe and illustrate small variations. When used in connection with an event or circumstance, these terms may refer to instances in which the event or circumstance occurred precisely, as well as instances in which the event or circumstance occurred approximately. When used in connection with a numerical value, these terms may refer to a range of variation of less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantially" aligned may refer to an angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

[0386] In addition, quantities, ratios, and other numerical values may sometimes be presented in a range format herein. It should be understood that this range format is used for convenience and brevity and should be flexibly understood to include the values explicitly specified as the limits of the range, and also to include all individual values or subranges encompassed within that range, as if each value and subrange were explicitly specified. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly listed limits of about 1 and about 200, and also include individual ratios such as about 2, about 3, and about 4, and subranges such as about 10 to about 50, about 20 to about 100.

[0387] 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 certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0388] Benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more apparent are not to be construed as critical, required, or essential features or elements of the technology described herein or any or all the claims.

[0389] Additionally, in the foregoing disclosure, various features may be grouped together in various embodiments to simplify the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Inventive subject matter may lie in fewer than all features of a single disclosed embodiment.

[0390] The abstract of the present disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. The abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0391] It will be appreciated that after submitting this application, the practice of some jurisdictions may require deletion of one or more parts of the disclosure. Therefore, with respect to the original content of this disclosure, the reader should consult the application submitted. Any deletion of the contents of this disclosure should not be construed as a waiver, loss or dedication to the public of any theme of the application originally submitted.

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

[0393] Although the description herein contains many details, these details should not be understood as limiting the scope of the present disclosure, but should be understood as merely providing illustrations of some embodiments in the presently preferred embodiments. Therefore, it should be appreciated that the scope of the present disclosure fully encompasses other embodiments that are obvious to those skilled in the art.

[0394] All structural and functional equivalents of the various elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are encompassed by the claims. Furthermore, no element, component, or method step in this disclosure is intended to be dedicated to the public, regardless of whether the element, component, or method step is expressly recited in the claims. Claim elements herein should not be interpreted as “means-plus-function” elements unless the phrase “means for…” is used to expressly recite the element. Claim elements herein should not be interpreted as “step-plus-function” elements unless the phrase “parts for…” is used to expressly recite the element.

Claims

1. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first station for wirelessly communicating with at least one other station; (b) a processor coupled to the wireless communication circuitry within a station configured to operate on a wireless network; (c) a non-transitory memory storing instructions, the instructions being executable by the processor; and (d) wherein the instructions, when executed by the processor, share a transmit opportunity (TXOP) by a non-access point (non-AP) station with other stations in a single basic service set (BSS) scenario in the frequency domain by performing the steps comprising: (i) exchanging messages with an access point (AP) station to obtain AP approval when sharing the non-AP station's TXOP with other stations; (ii) exchanging information with other stations to indicate that the TXOP is available for sharing, and identifying non-AP shared TXOP participant stations based on received responses; and (iii) sending a message to non-AP shared TXOP participant stations that are willing to join the next shared TXOP, wherein the message contains information about resource units (RUs) for each non-AP shared TXOP participant station, the resource units being used to send uplink (UL) data within the shared TXOP during channel access.

2. The apparatus of claim 1, wherein the non-AP stations exchange information on TXOP shareability by exchanging management frames under the coordination of the AP station.

3. The apparatus of claim 2, wherein the management frame is selected from a group of message frames consisting of an authentication frame, an association frame, a request frame, a response frame, and a beacon frame.

4. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further comprise: The non-AP stations and AP stations exchange traffic information regularly.

5. The apparatus of claim 4, wherein the traffic information is exchanged using a combination of a buffer status report poll (BSRP) frame and a buffer status report (BSR) frame.

6. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further comprise: Channel sounding is performed by the TXOP holder station, which sends MU-RTS sharing frames to other stations and receives CTS sharing frames from other stations that are willing to join the next shared TXOP.

7. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further comprise: The TXOP holder station initiates a shared TXOP access by sending a trigger frame selected from a group of messages consisting of: (a) a unicast TXOP access request trigger sent to each specific station with allocated RUs; (b) a broadcast TXOP access request trigger sent to all non-AP shared TXOP participant stations with allocation of RU information indicated for each of all non-AP shared TXOP participant stations; and (c) a TXOP random access request trigger that broadcasts to other stations and triggers random access of other stations using the shared RU.

8. The apparatus according to claim 1, wherein upon receiving a trigger frame from the TXOP holder station, other TXOP participant stations access the channel according to access information contained in the trigger frame.

9. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first wireless station for wirelessly communicating with at least one other station; (b) a processor of the first wireless station configured to operate on a wireless network; (c) non-transitory memory storing instructions, said instructions being executable by said processor; and (d) wherein the instructions, when executed by the processor, share transmit opportunities (TXOPs) by a non-access point (non-AP) station with other stations in a single basic service set (BSS) scenario in the frequency domain by performing the steps comprising: (i) exchanging messages with an access point (AP) station to obtain the AP station's approval when sharing the non-AP station's TXOP with other stations; (ii) when the first wireless station obtains access to the channel as a TXOP holder, the first wireless station exchanges information with other stations through coordination by the AP station to indicate that the upcoming TXOP is available for sharing and to identify other stations willing to join the upcoming shared TXOP; and (iii) Sending a message to the non-AP shared TXOP participant stations willing to join the next shared TXOP through coordination of the AP station, and indicating the RU that each of those non-AP shared TXOP participant stations should use to send UL data when the channel is accessed.

10. The apparatus of claim 9, wherein the exchange of information on TXOP shareability is performed by exchanging management frames under the coordination of an AP station.

11. The apparatus of claim 10, wherein the management frame is selected from a group consisting of an authentication frame, an association frame, a request frame, a response frame, and a beacon frame.

12. The apparatus of claim 9, wherein the instructions, when executed by the processor, further comprise periodically exchanging buffer status and traffic priority information between non-AP stations and AP stations.

13. The apparatus of claim 12, wherein the buffer status and traffic priority information is exchanged by utilizing a combination of a buffer status report poll (BSRP) frame and a buffer status report (BSR) frame.

14. The apparatus of claim 9, wherein the instructions, when executed by the processor, further comprise: The AP station receives CTS-to-self sharing frames from non-AP TXOP holder stations, the AP station sends MU-RTS sharing frames to other stations, and receives CTS sharing frames from other stations that are willing to join the next shared TXOP, where the AP station sends participant information to non-AP TXOP holder stations in a TXOP participant announcement frame.

15. The apparatus of claim 9, wherein the instructions, when executed by the processor, further comprise: The non-AP TXOP holding station initiates access to the shared TXOP by: (a) sending a TXOP access scheduler trigger frame to the AP station, the TXOP access scheduler trigger frame indicating allocation of RUs to each of the other stations sharing the upcoming TXOP; Or (b) sending a TXOP priority trigger frame to the AP station, wherein the TXOP priority trigger frame indicates the priority to the TXOP holder and allows the AP station to schedule RU allocation.

16. The apparatus of claim 9 , wherein an AP station receiving a TXOP access scheduler trigger performs steps comprising: (a) unicasting a TXOP access request trigger to each specific station using the RU allocated to each specific station; or (b) broadcasting a TXOP access request trigger to all non-AP shared TXOP participant stations, wherein the TXOP access request trigger contains information about RU allocation to each of all non-AP shared TXOP participant stations.

17. The apparatus of claim 9, wherein when the AP station receives a TXOP priority trigger, steps are performed comprising: (a) performing scheduling based on the latest traffic information indicated in a BSR frame from each other station and triggering UL transmission using a basic trigger; or (b) broadcasting a TXOP random access request trigger to non-AP stations and triggering random access of non-AP shared TXOP participant stations to access a channel using RA-RU.

18. The apparatus of claim 17, wherein the instructions, when executed by the processor, further comprise: The AP station triggers the non-AP TXOP holder stations to access the channel using the reserved RU.

19. The apparatus of claim 9, wherein when a trigger frame is received from the AP, the non-AP TXOP sharing participant station accesses the channel according to access information indicated in the trigger frame, and wherein the non-AP TXOP holder STA accesses the channel using a reserved RU.

20. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first wireless station for wirelessly communicating with at least one other station; (b) a processor of the first wireless station configured to operate on a wireless network; (c) non-transitory memory storing instructions, said instructions being executable by said processor; and (d) wherein the instructions, when executed by the processor, share a transmit opportunity (TXOP) by a non-access point (non-AP) station with other stations in a single basic service set (BSS) scenario in the frequency domain by performing the steps comprising: (i) Each non-AP station determines which of the other non-AP stations can access the non-AP station's shared TXOP if it is to be the shared TXOP holder; (ii) communicating the configuration of RU allocation and access order of each potential shared TXOP participant station as a semi-static configuration through coordination of the AP station; and (iii) Each non-AP station accesses the shared TXOP initiated by a specific shared TXOP holder station according to the announced semi-static configuration without waiting for receiving a trigger frame for uplink data transmission from the AP station.

21. The apparatus of claim 20, wherein the instructions, when executed by the processor, further comprise: The setup process is performed by the non-AP station to set up a semi-static configuration by: (a) the non-AP station exchanges sharing proposal / request frames with other non-AP stations through coordination of the AP station; (b) The AP station forwards the shareability information of the non-AP station to all other non-AP stations; (c) The non-AP station exchanges the configuration of the semi-static TXOP sharing schedule with all other non-AP stations through the coordination of the AP station; and (d) the AP station forwards the shared TXOP access information to all non-AP stations using the TXOP access configuration frame.

22. The apparatus of claim 20, wherein the instructions, when executed by the processor, further comprise: The non-AP station shares its TXOP with other non-AP stations according to the announced allocation schedule.

23. The apparatus of claim 20, wherein the instructions, when executed by the processor, further comprise: The non-AP TXOP holder station obtains the channel and performs: (a) broadcasting a TXOP sharing request trigger without the AP station as the coordinator; or (b) with the AP station as the coordinator, unicasting a TXOP sharing request trigger to the AP station; and wherein in response to (b), the AP station broadcasts a TXOP sharing response trigger.

24. The apparatus of claim 20, wherein when a non-AP station receives the broadcast TXOP sharing request frame, the non-AP station accesses the channel based on the announced RU allocation.

Images