Coordinating station in OBSS with shared TXOP in frequency domain

Abstract

A wireless network communication protocol that allows sharing of transmit opportunities (TXOPs) in the same basic service set (BSS) or overlapping basic service sets (OBSS) over at least one channel. Sharing proposals and request information are exchanged with access point (AP) stations, and the access point (AP) stations share the sharing proposals and request information with APs on overlapping BSSs. Information is exchanged between stations to announce that upcoming TXOPs can be used for sharing, and to identify stations willing to join the upcoming TXOP. Resource unit (RU) distribution is determined for participant stations to use when sharing a TXOP, and the AP of the OBSS schedules and distributes RUs for stations in the OBSS.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. patent application serial number 17 / 152,536, filed on January 19, 2021, which is incorporated herein by reference in its entirety, and claims priority to and the benefit of U.S. provisional patent application serial number 63 / 043,309, filed on June 24, 2020, which is incorporated herein by reference in its entirety.

[0003] Statement Regarding Federally Funded Research and Development

[0004] not applicable

[0005] Computer Program Appendix Incorporation by Reference

[0006] not applicable

[0007] Notice of Copyrighted Material

[0008] Portions of the 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 C.FR §1.14. Technical Field

[0009] The technology of the present disclosure generally relates to Wi-Fi transmissions over a network, and more particularly to uplink (UL) multi-user (MU) transmissions over a network. Background Art

[0010] The use of Wi-Fi networks is expanding rapidly, with growth driven by the continued development of new applications and the proliferation of smart devices. Given the growing number and needs of Wi-Fi users, high throughput and low latency are required.

[0011] In order to improve the performance of WLAN, especially the performance of WLAN focusing on 2.4 GHz and 5 GHz bands, many 802.11 amendments have been proposed. Other technologies have proposed solutions for data rate improvement from the perspective of the physical (PHY) layer, such as increasing the bandwidth from 20 MHz to 160 MHz, proposing new modulation and coding schemes, and improving multiple-input multiple-output (MIMO) systems.

[0012] To reduce transmission overhead and thus increase data throughput, improvements have been made to the Medium Access Control (MAC) layer, such as by reducing the inter-frame space, aggregating and segmenting packets, and applying power consumption protocols to alternate between awake and dormant states of STAs to save power.

[0013] In addition, 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 in uplink (UL) and downlink (DL).

[0014] OFDMA allows multiple users to use the same time resource simultaneously and divides the frequency domain between multiple users. This results in improved use of resources and allows latency to be reduced because more users can be scheduled simultaneously.

[0015] Certain Wi-Fi communications involving real-time applications (RTA) such as real-time gaming are very sensitive to latency and therefore have stricter requirements for low-latency communications. User experience such as real-time interaction between different game players is very important in real-time gaming.

[0016] However, these current 802.11 protocols can still suffer from latency issues, which can be problematic for applications such as real-time gaming or other real-time applications.

[0017] Therefore, there is a need for a protocol that can improve UL efficiency by performing MU UL OFDMA transmissions by non-AP stations. The present disclosure satisfies this need and provides additional benefits over previous techniques. Summary of the invention

[0018] The present disclosure facilitates multi-user (MU) uplink (UL), which allows a non-access point (AP) station (STA) to initiate MU UL transmission once a channel is acquired without waiting for a trigger frame from the AP. The non-AP STA acts as a transmit opportunity (TXOP) holder STA, which is configured to initiate a shared TXOP access and schedule channel resources for other non-AP STAs (from an internal basic service set (BSS) or from an overlapping basic service set (OBSS)) in which the STA is willing to join the shared TXOP. The present disclosure also provides dynamic scheduling, exchanging messages with the AP for information sharing or approval, and exchanging information with other STAs (e.g., STAs willing to share the TXOP).

[0019] 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

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

[0021] FIG. 1 is a diagram illustrating slotted transmission of DL OFDMA MIMO transmission in IEEE 802.11.

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

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

[0024] FIG. 4 is a diagram showing a data field in a data frame format in a conventional WLAN system.

[0025] FIG. 5 is a diagram showing a data field of an ACK frame format in a conventional WLAN system.

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

[0027] FIG. 7 is a communication sequence diagram in which packets are discarded after the number of retransmissions exceeds the retry limit.

[0028] FIG. 8 is a communication sequence diagram of a conventional downlink multi-user transmission using OFDMA.

[0029] FIG. 9 is a communication sequence diagram of a conventional uplink multi-user transmission using OFDMA.

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

[0031] Fig.11 is an example of a network topology diagram in accordance with at least one embodiment of the present disclosure.

[0032] Fig.12 is a communication sequence diagram of a shared TXOP protocol in an OBSS scenario initiated by a non-AP TXOP holder STA according to at least one embodiment of the present disclosure.

[0033] Fig.13 is a communication sequence diagram of a dynamic scenario of a protocol having three phases including a shared TXOP setup phase in accordance with at least one embodiment of the present disclosure.

[0034] Fig.14 is a communication sequence diagram regarding shared information exchange in a shared TXOP setup phase of an OBSS scenario according to at least one embodiment of the present disclosure.

[0035] Fig.15 is a flow chart of a shared TXOP setup phase handled by an AP for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0036] Fig.16 is a flow chart of a shared TXOP setup phase for an OBSS scenario processed at a non-AP STA level according to at least one embodiment of the present disclosure.

[0037] Fig.17 is a communication sequence diagram of packet exchange in a shared TXOP initialization phase of an OBSS scenario according to at least one embodiment of the present disclosure.

[0038] Fig.18 Detailed description is a flow chart of a shared TXOP initialization phase for an OBSS scenario processed at a non-AP TXOP holder STA level according to at least one embodiment of the present disclosure.

[0039] Fig.19A and Fig.19B The invention is a flowchart of a shared TXOP initialization phase for an OBSS scenario processed at the AP level according to at least one embodiment of the present disclosure.

[0040] Fig. 20 Detailed description is a flow chart of a shared TXOP initialization phase for an OBSS scenario processed at a non-AP TXOP participant STA level in accordance with at least one embodiment of the present disclosure.

[0041] Fig.21 is a communication sequence diagram of TXOP scheduling and access phases with random access on a scheduled frequency band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0042] Fig. 22 is a flow chart of a TXOP scheduling and access phase with random access on a scheduled frequency band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0043] Fig.23 is a flow chart of a TXOP scheduling and access phase with random access on a scheduled frequency band for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the AP level.

[0044] Fig.24 The present invention is a flowchart of a TXOP scheduling and access phase with random access on a scheduled frequency band for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the level of a TXOP participant STA shared by a non-AP.

[0045] Fig.25 is a communication sequence diagram of TXOP scheduling and access phases with basic triggering on a scheduling band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0046] Fig.26 is a flow chart of TXOP scheduling and access phases with basic triggering on a scheduling band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0047] Fig. 27 is a flow chart of TXOP scheduling and access phases with basic triggering on a scheduling band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0048] Fig.28 is a flow chart of TXOP scheduling and access phases with basic triggering on a scheduling band for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0049] Fig.29 is a communication sequence diagram of TXOP scheduling and access phases with basic triggered transmission with time shift for an OBSS scenario according to at least one embodiment of the present disclosure.

[0050] Fig.30 is a flow chart of a TXOP scheduling and access phase with basic triggered transmission with time shift, which is handled at the non-AP TXOP holder STA level, in accordance with at least one embodiment of the present disclosure.

[0051] Fig.31 It is a flow chart of a TXOP scheduling and access phase with basic triggering on a scheduling band for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the AP level.

[0052] Fig.32 is a flow chart of a TXOP scheduling and access phase with basic triggered transmission with time shift, which is processed at the non-AP shared TXOP participant STA level in accordance with at least one embodiment of the present disclosure.

[0053] Fig.33 is a communication sequence diagram of a TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler in accordance with at least one embodiment of the present disclosure.

[0054] Fig.34is a flow chart of a TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler, which is handled at the non-AP TXOP holder STA level, in accordance with at least one embodiment of the present disclosure.

[0055] Fig.35 is a flow chart of a TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler, which is handled at the AP level, in accordance with at least one embodiment of the present disclosure.

[0056] Fig.36 is a flow chart of a TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler, which is handled at the non-AP TXOP participant STA level, in accordance with at least one embodiment of the present disclosure.

[0057] Fig.37 is a communication sequence diagram of unicast TXOP access request triggering (triggered by the AP) and time shifting in the scheduler in accordance with at least one embodiment of the present disclosure.

[0058] Fig.38 is a flow chart of a TXOP scheduling and access phase with unicast TXOP access request triggering (triggered by an AP) and time shifting in the scheduler, which is handled at the non-AP TXOP holder STA level in accordance with at least one embodiment of the present disclosure.

[0059] Fig.39 is a flow chart of a TXOP scheduling and access phase with unicast TXOP access request triggering (triggered by an AP) and time shifting in the scheduler, which is handled at the AP level, in accordance with at least one embodiment of the present disclosure.

[0060] Fig.40 is a communication sequence diagram of TXOP scheduling and access phases with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler in accordance with at least one embodiment of the present disclosure.

[0061] Fig.41 is a flow chart of a TXOP scheduling and access phase with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler, which is handled at the non-AP TXOP holder STA level in accordance with at least one embodiment of the present disclosure.

[0062] Fig.42is a flow chart of a TXOP scheduling and access phase handled at the AP level with a broadcast TXOP access request trigger (by non-AP TXOP holders) and a time shift in the scheduler in accordance with at least one embodiment of the present disclosure.

[0063] Fig.43 is a flow chart of a TXOP scheduling and access phase with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler, which is handled at the non-AP TXOP participant STA level in accordance with at least one embodiment of the present disclosure.

[0064] Fig.44 is a communication sequence diagram of a frame exchange process in a TXOP scheduling and access phase with a broadcast TXOP access request trigger (by an AP) and a time shift in the scheduler in accordance with at least one embodiment of the present disclosure.

[0065] Fig.45 is a flow chart of a TXOP scheduling and access phase with a broadcast TXOP access request trigger (by an AP) and a time shift in the scheduler, which is handled at the non-AP TXOP holder STA level, in accordance with at least one embodiment of the present disclosure.

[0066] Fig.46 is a flow chart of a TXOP scheduling and access phase with a broadcast TXOP access request trigger (by an AP) and a time shift in the scheduler, which is handled at the AP level, in accordance with at least one embodiment of the present disclosure.

[0067] Fig.47 is a communication sequence diagram of a frame exchange sequence in a sharing proposal / request setup sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure.

[0068] Fig.48 The invention is a flowchart of a sharing proposal / request setting sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the sharing proposal / request setting sub-phase is processed at a non-AP STA level.

[0069] Fig.49 is a flowchart of a sharing proposal / request setting sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the sharing proposal / request setting sub-phase is processed at the AP level.

[0070] Fig.50 is a communication sequence diagram of a frame exchange process in a TXOP holder configuration setup sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure.

[0071] Fig.51 The present invention is a flowchart of a TXOP holder configuration setting sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP holder configuration setting sub-phase is processed at a non-AP STA level.

[0072] Fig.52 The present invention is a flowchart of a TXOP holder configuration setting sub-phase of a semi-static protocol for an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP holder configuration setting sub-phase is processed at the AP level.

[0073] Fig.53 is a communication sequence diagram of a semi-static protocol with time-shifted TXOP scheduling and access phases for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0074] Fig.54 A semi-static protocol with time-shifted TXOP scheduling and access phases for an OBSS scenario in accordance with at least one embodiment of the present disclosure.

[0075] Fig.55 is a flow chart of a semi-static protocol with time-shifted TXOP scheduling and access phases for an OBSS scenario, which are processed at the AP level, in accordance with at least one embodiment of the present disclosure.

[0076] Fig.56 The present invention is a flow chart of a semi-static protocol with time-shifted TXOP scheduling and access phases for an OBSS scenario, which are processed at the level of non-AP shared TXOP participants STAs in accordance with at least one embodiment of the present disclosure.

[0077] Fig.57 is a communication sequence diagram of a semi-static protocol for TXOP scheduling and access phases on a scheduling band in an OBSS scenario according to at least one embodiment of the present disclosure.

[0078] Fig.58 The present invention is a flowchart of a semi-static protocol for TXOP scheduling and access phase on a scheduling band of an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the non-AP TXOP holder STA level.

[0079] Fig.59 The present invention is a flowchart of a semi-static protocol for TXOP scheduling and access phase on a scheduling band of an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the AP level.

[0080] Fig.60 A data field diagram of a semi-static protocol for a TXOP scheduling and access phase on a scheduling band of an OBSS scenario according to at least one embodiment of the present disclosure, wherein the TXOP scheduling and access phase is processed at the level of a TXOP participant STA shared by a non-AP.

[0081] Fig.61 is a diagram of data fields of a TXOP shareability element in accordance with at least one embodiment of the present disclosure.

[0082] Fig.62 According to at least one embodiment of the present disclosure, Fig.61 Figure 2 shows a data field diagram of the information (info) field of the TXOP shareability element shown in Figure 2.

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

[0084] Fig.64 According to at least one embodiment of the present disclosure Fig.63 Figure 14 shows the data field diagram for the Shared Proposal / Request Information field.

[0085] Fig.65 is a data field diagram of an OBSS shared STA frame format according to at least one embodiment of the present disclosure.

[0086] Fig.66 is a diagram of data fields of a multi-user request to send (MU-RTS) shared frame in accordance with at least one embodiment of the present disclosure.

[0087] Fig.67 is a diagram of a data field of a CTS shared frame according to at least one embodiment of the present disclosure.

[0088] Fig.68 is a diagram of data fields of an OBSS TXOP participant STA frame format in accordance with at least one embodiment of the present disclosure.

[0089] Fig.69 is a data field diagram of a TXOP resource request STA field according to at least one embodiment of the present disclosure.

[0090] Fig.70 is a diagram of data fields of a CTS-to-self frame according to at least one embodiment of the present disclosure.

[0091] Fig.71 is a diagram of data fields of a TXOP priority trigger frame format according to at least one embodiment of the present disclosure.

[0092] Fig.72is a diagram of data fields of an OBSS shared trigger frame according to at least one embodiment of the present disclosure.

[0093] Fig.73 is a data field diagram of a reserved band TXOP holder BSS field in accordance with at least one embodiment of the present disclosure.

[0094] Fig.74 Detailed description is a diagram of a data field of a TXOP random access request trigger frame according to at least one embodiment of the present disclosure.

[0095] Fig.75 is a diagram of data fields of a unicast TXOP access request trigger frame according to at least one embodiment of the present disclosure.

[0096] Fig.76 is a data field diagram of a TXOP access scheduler trigger frame format according to at least one embodiment of the present disclosure.

[0097] Fig.77 is a diagram of data fields of a broadcast TXOP access request trigger frame according to at least one embodiment of the present disclosure.

[0098] Fig.78 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.

[0099] Fig.79 is a data field diagram of a STA TXOP Access Allocation field in accordance with at least one embodiment of the present disclosure.

[0100] Fig.80 is a data field diagram of an allocation control information subfield in accordance with at least one embodiment of the present disclosure.

[0101] Fig.81 is a diagram of data fields of a TXOP access configuration frame in accordance with at least one embodiment of the present disclosure.

[0102] Fig.82 is a diagram of data fields of an OBSS TXOP access configuration frame in accordance with at least one embodiment of the present disclosure.

[0103] Fig.83 is a data field diagram of a TXOP sharing request trigger frame according to at least one embodiment of the present disclosure.

[0104] Fig.84 is a diagram of data fields of a TXOP sharing response trigger frame according to at least one embodiment of the present disclosure.

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

[0106] 1. Introduction

[0107] A new protocol for enabling multi-user (MU) uplink (UL) transmission in a shared TXOP is described, which can operate even in overlapping basic service sets (OBSS) scenarios. A shared TXOP means that channel access can be shared among different users during one TXOP. More specifically, when a non-AP STA obtains (seizes) a channel, it can initiate MU UL transmission without waiting for a trigger frame from the AP. The non-AP STA acts as a TXOP holder STA, which can initiate a shared TXOP access and schedule channel access resources for other non-AP STAs (in the same BSS or in the OBSS) willing to join the next shared TXOP. As an example and not a limitation, the disclosed solution focuses on the OBSS case because it is more challenging than the BSS case. The disclosed solution improves channel utilization efficiency and reduces OBSS interference and channel access contention delay, thereby improving flexibility and real-time application (RTA) performance.

[0108] 2. About the current IEEE 802.11 for WLAN

[0109] Current 802.11 technology initiates uplink (UL) multi-user (MU) transmission at the AP level. This requires that even if non-AP STAs need to send UL data to the AP and they sense that the channel is available, they cannot simply start transmitting. Non-AP STAs must wait until they receive a trigger frame from the associated AP before they can start UL data transmission.

[0110] The present disclosure describes a shared TXOP protocol initiated at the non-AP STA level for MU UL OFDMA transmission. In the disclosed solution, a non-AP STA that obtains channel access is enabled to initiate a shared TXOP and allocate different channel resources to other non-AP STAs for MU UL data transmission.

[0111] 2.1. WLAN characteristics that affect latency

[0112] 2.1.1. Channel Access and Delay Tolerance

[0113] 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 for the channel every time it is busy in order to gain access to the channel. This introduces additional transmission delays, but is necessary to avoid collisions. 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 viable solution to avoid contention delays, it has many disadvantages and is therefore not widely deployed, and most Wi-Fi devices are using contention-based access.

[0114] For STA to access the channel, it needs to sense the channel and determine whether the channel is busy. The channel is considered busy when any of the following conditions is detected: (a) STA detects the preamble of the frame, where the channel is considered busy within the length of the detected frame; (b) STA detects energy greater than the minimum sensitivity of 20dB; or (c) STA detects that the channel is actually busy by reading the NAV of the detected frame.

[0115] 802.11ax introduces two NAVs to avoid possible conflicts due to erroneous resetting of the NAV timer. One NAV is for BSS STAs and the other NAV is for non-BSS STAs. STAs maintain these two NAVs separately.

[0116] Like all traditional 802.11 WLAN devices, 802.11ax uses CSMA / CA for channel access. For the AP, in order to send a trigger frame for UL MIMO transmission, it still needs to compete for channel access. In order to enable the AP to obtain (win) channel access before any STA in its BSS, 802.11ax introduces a second set of enhanced distributed channel access (EDCA) only for 802.11ax devices to allow traditional non-802.11ax devices to freely access the channel using EDCA and increase the chances of the AP obtaining channel access in order to schedule UL or DL ​​OFDMA MIMO data transmission.

[0117] 2.1.2. Multi-user sending and receiving

[0118] 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 (UL) and downlink (DL).

[0119] This 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. Thus, an AP can allocate one or more streams to a STA in its BSS.

[0120] With the use of wide channels up to 160MHz for data transmission, it is expected that the channel is interference-frequency selective, with some frequencies experiencing different interference levels than other frequencies. This affects the expected achievable communication rate and can degrade performance. To address this issue, 802.11ax introduces OFDMA, where 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 signal-to-interference-and-noise ratio (SINR) of each receiver, allowing for higher modulation and coding schemes (MCS), thus improving the achieved throughput.

[0121] OFDMA allows multiple users to use the same time resources at the same time and divides the frequency domain among multiple users; this improves resource utilization and reduces communication latency because more users can be scheduled simultaneously. In addition, STAs with small amounts of data to transmit (which is a typical case for RTAs) can occupy narrower RUs, making scheduling very efficient and allowing for better distribution of resources between applications that need access for small amounts of data. This can help reduce channel access time and the amount of overhead associated with frame headers and preambles.

[0122] OFDMA can be more efficient when combined with the use of MIMO transmissions. Depending on the MIMO capacity of the STA, an RU can be used to send multiple spatial streams to the STA. In addition, an RU can be allocated for sharing between more than one STA, where each STA can have one or more spatial streams depending on the MIMO capacity of the STA. Packing more STAs in the same resource also advantageously reduces the latency of the STA and the AP.

[0123] Figure 1 depicts an example of DL OFDMA MIMO transmission. The AP is sending a PHY preamble to all STAs to specify the frequency / RU mapping and RU allocation for the STA. After the preamble, the AP sends DL data to a specific STA using the RU allocation for that STA. Multi-user ACK transmission should be synchronized with the reception of the DL data frame, where the STA starts transmission SIFS after receiving the DL trigger frame.

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

[0125] 2.1.4. Resend

[0126] FIG3 depicts a flow chart of an operation of using CSMA / CA in a WLAN system to allow STAs to obtain access to a channel for packet transmission and retransmission according to IEEE 802.11. In a CSMA / CA system, before each transmission and retransmission, the STA must sense the channel state 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, the STA sends a packet.

[0127] 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 of the packet. If the number of retransmissions exceeds the retry limit, the packet is discarded and the retransmission is not scheduled. Otherwise, a retransmission is scheduled. If a retransmission is scheduled, another backoff time is required to contend for channel access for the retransmission. If the size of the contention window does not reach the upper limit, the STA increases the contention window. The STA sets another backoff time depending on the size of the new contention window. The STA waits for the backoff time to retransmit, and so on.

[0128] FIG4 illustrates the data frame format in a conventional WLAN system. The frame control field indicates the type of frame. The duration field contains the NAV information 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.

[0129] Figure 5 illustrates the ACK frame format in a conventional WLAN system. The frame control field indicates the type of frame. The duration field contains the NAV information for CSMA / CA channel access. The RA field contains the address of the receiver of the frame.

[0130] FIG. 6 illustrates an example of retransmission in CSMA / CA, where the backoff time is increased due to retransmission. The data packet frame and the ACK frame use the formats shown in FIG. 4 and FIG. 5, respectively. After the initial transmission of the transmitter sending the packet, it does not receive an ACK before the timeout. So, it sets another backoff time so that the size of the contention window is n time slots. After waiting for the backoff time, the transmitter STA retransmits the packet for the first time. However, the retransmission also fails. The transmitter STA needs to retransmit the packet and set the backoff time again to contend for channel access. This time, due to the retransmission, the size of the contention window is doubled, i.e., 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.

[0131] FIG. 7 illustrates an example of discarding packets after the number of retransmissions exceeds a retry limit.

[0132] The data packet frame and the 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 succeed. After retransmitting N times, the number of retransmissions exceeds the retry limit. The transmitter STA stops retransmitting the packet, and the packet is discarded.

[0133] FIG8 illustrates another example of discarding a packet after the number of retransmissions exceeds the retry limit. The data packet frame and the ACK frame use the formats shown in FIG4 and FIG5, respectively. As shown, after the initial transmission of the packet fails, the transmitter STA retransmits the packet multiple times. However, none of the retransmissions succeed. After retransmitting N times, the number of retransmissions exceeds the retry limit. The transmitter STA stops retransmitting the packet, and the packet is discarded.

[0134] FIG. 9 illustrates an example of discarding packets after the number of retransmissions exceeds a retry limit.

[0135] The data packet frame and the 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 succeed. After retransmitting N times, the number of retransmissions exceeds the retry limit. The transmitter STA stops retransmitting the packet, and the packet is discarded.

[0136] UL OFDMA Random Access

[0137] 802.11ax introduces UL OFDM random access for UL transmission when the AP does not know which STA has data to send or when an unassociated STA wants to send data. A trigger frame can allocate some RUs for random UL channel access. When the AP allocates specific RUs for uplink random access, STAs use the OFDMA backoff process to determine whether they will access the random access channel. This is done by selecting a random backoff value and comparing the random backoff value with the number of RUs allocated for random access. If the current random backoff 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 provide efficient short packet transmission.

[0138] 3. Problem Statement

[0139] For MU UL transmission, 802.11n / ac and the like implement request to send / clear to send (RTS / CTS) or RTS / CTS with extensions in the channel access scheme to help avoid packet collisions. However, this scheme only allows one user to occupy the channel at a time. In addition, the overhead of the RTS / CTS frame exchange mechanism introduces long delays.

[0140] In comparison, the 802.11ax technology implements an OFDMA scheme, which allows different users to access the channel at the same time. This improves channel utilization efficiency and reduces average latency. However, the current 802.11ax technology relies on the AP to initiate UL transmission for the shared TXOP. This means that even if a non-AP STA senses that the channel is available and it has data to send to the AP, the non-AP STA must wait until it receives a trigger frame from the associated AP to start UL data transmission. In addition, the non-AP STA must rely on the AP to schedule and distribute available channel resources between the non-AP STA and other non-AP STAs that have obtained the channel. In this case, it introduces several problems, including low channel utilization efficiency and increased latency.

[0141] The latency problem becomes worse when considering the OBSS case, where interference from neighboring BSSs causes more contention when accessing the channel, resulting in longer latency.

[0142] 4. Contributions of the Invention

[0143] The present disclosure provides a new solution, which enables multi-user (MU) upload (UL) transmission in a shared TXOP for OBSS scenarios. A shared TXOP means that channel access can be shared among different users during one TXOP. More specifically, when a non-AP STA obtains (seizes) a channel, it can initiate MU UL transmission without waiting for a trigger frame from the AP. The non-AP STA acts as a TXOP holder STA, which is configured in this protocol to initiate shared TXOP access and schedule channel resources for other non-AP STAs (in the same BSS or in the OBSS) who are willing to join the shared TXOP. The studied scenario mainly focuses on the OBSS case because it is more robust than the subset BSS case. The disclosed solution improves channel utilization efficiency and reduces OBSS interference and delay on the non-AP STA side, thereby improving flexibility and real-time application (RTA) performance on the non-AP STA side.

[0144] 5. Non-AP STA hardware settings

[0145] Fig.10 An example embodiment 10 of a wireless station including a non-AP STA is illustrated. A circuit 12 is shown with an external I / O 14 to access applications. The I / O 14 is connected to a bus 16, which is coupled to at least one CPU 18 and a memory 20 (e.g., RAM) to execute (run) a program that implements a communication protocol.

[0146] The host 10 accommodates at least one modem 22, which transmits / receives data frames with adjacent STAs on at least one frequency band and can be directional or omnidirectional. The modem 22 is connected to at least one RF module 24, 28 to generate and receive physical signals. In at least one embodiment, the RF module includes a frequency converter, an array antenna controller, etc. In this example, the RF module is shown as being connected to multiple antennas 26a, 26b, 26c~26n, and 29, which are controlled to perform beamforming or omnidirectional communication for transmission and reception. In this way, the STA can use multiple sets of beam patterns to send signals. The modem and antenna can also or additionally be configured for omnidirectional operation.

[0147] It should be appreciated that the station hardware of the present disclosure can be configured to communicate on any desired frequency band, such as the millimeter wave band and the sub-6GHz band. It should also be noted that multiple STAs can be grouped (aggregated), such as configured as a multi-link device (MLD) in any desired configuration without departing from the teachings of the present disclosure.

[0148] 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 programming is configured to operate in different modes (source, sender, intermediate, destination, receiver, first AP, other APs, non-AP stations associated with the first AP, non-AP TXOP holder stations, non-AP TXOP participant stations, non-AP TXOP non-participant stations, stations associated with other APs, coordinators, coordinators, etc.) depending on the role it plays in the current communication context.

[0149] Fig.85 Graphical instructions Fig.10 A variation of this is an embodiment 1950 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 as follows Fig.10 As described in the figure, each station 10' has a CPU, RAM, modem, RF circuit, and one or more antennas. As can be seen from the figure, each of the n stations of the MLD shown provides a different link (eg, link 1, link 2 to link n are shown).

[0150] It can also be seen that the MLD includes a circuit 1952 of an MLD management entity having at least one processor (CPU) 1954 and a memory 1956. The circuit 1952 provides external I / O to access the application of the MLD and implement the communication protocol at the MLD level. The MLD is configured to distribute tasks to each subordinate STA and collect information from each subordinate STA, and share information between subordinate STAs.

[0151] 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 processors and memory between them, or share processors and memory of MLD circuitry. Thus, the present disclosure contemplates many possible arrangements for communicating over multiple links within an MLD.

[0152] 6. Topology and scenario description

[0153] 6.1. Topology under study

[0154] Fig.11The diagram illustrates an example embodiment 30 of the topology representing a WLAN OBSS scenario consisting of two overlapping BSSs, wherein BSS1 44 consists of an AP (AP1) 32 and three STAs 33, 34, and 36. Wherein, for the sake of illustration, STA3 36 is represented as a non-AP TXOP holder STA that acquires a channel and shares its TXOP with other non-AP STAs, while the other two STAs 33 and 34 are non-AP shared TXOP participant STAs that do not acquire a channel as a TXOP holder but are willing to join a TXOP shared by a TXOP holder STA. BSS2 46 consists of an AP (AP2) 38 and two STAs including STA1'42 and STA2'40, in this example, STA1'42 and STA2'40 in BSS2 are non-AP TXOP participant STAs.

[0155] It should be noted that the role of the TXOP holder station is not a fixed role, because any non-AP station or AP can play the role of the TXOP holder if it obtains the TXOP. This topology example is used to illustrate the disclosed solution; however, the present disclosure can be applied without limitation to any WLAN topology with single or multiple BSSs and one or more stations per AP.

[0156] 6.2. Scenario description

[0157] In the scenario studied, each BSS contains one AP and multiple non-AP STAs. Each non-AP STA has packets that are generated periodically or aperiodically and need to be sent to the associated AP. The present disclosure mainly focuses on the use of uplink (UL) orthogonal frequency division multiple access (OFDMA) transmission. For UL OFDMA transmission, latency is always a critical issue due to the more complex scheduling between each non-AP STA and the AP, but the techniques in this article are applicable to other use cases.

[0158] In 802.11ax, multiple STAs can simultaneously send UL data sequences in a shared TXOP, which improves channel utilization efficiency.

[0159] However, in 802.11ax, the AP is the only device that can initiate UL data transmission. The AP usually sends a trigger frame (e.g., BSRP) to non-AP STAs to inquire about their buffer status and traffic priority, and receives a response frame (e.g., BSR) from these non-AP STAs. The AP sends another trigger frame (e.g., Basic Trigger) with resource allocation information to these non-AP STAs for them to use in sending UL data sequences.

[0160] AP-initiated TXOP cannot capture dynamic requirements from the non-AP STA side, especially for those non-AP STAs that have RTA (real-time application) packets to send. RTA packets are usually small in size; however, RTA packets require fast, low-latency transmission. In the illustrated OBSS scenario, the delay performance is more serious because the interference in the OBSS scenario introduces more intense channel contention, resulting in longer delays.

[0161] The present disclosure describes a new solution for OBSS scenarios from the perspective of non-AP STAs. In particular, for those non-AP STAs that sense that a channel is available and have packets to be sent to the AP immediately. A STA that obtains channel access and is willing to share the channel access in its TXOP with other STAs enables a shared TXOP scheme. Coordination between non-AP STAs and APs makes it more efficient for each device to access the channel by joining the shared TXOP. Non-AP STA participants in the shared TXOP can come from the same BSB or from an OBSS. The shared TXOP scheme between multiple collaborative devices for OBSS scenarios effectively reduces OBSS interference while reducing latency, and provides more efficient channel utilization between competing STAs from the same BSS or from an OBSS.

[0162] More specifically, the present disclosure operates as follows. Once any non-AP STA obtains channel access, it can immediately initiate the next shared TXOP. The non-AP STA is referred to as a non-AP TXOP holder STA in this article. A non-AP STA willing to participate in the next shared TXOP is referred to as a non-AP shared TXOP participant STA in this article.

[0163] A non-AP TXOP holder STA shares the TXOP in the frequency domain with other non-AP shared TXOP participant STAs in the same BSS or in another BSS. A non-AP TXOP holder STA does not need to wait for the AP to initiate shared TXOP access. A non-AP TXOP holder STA is able to schedule and distribute available frequency resources to other non-AP shared TXOP participant STAs. Once the access resources in the shared TXOP are reserved, the non-AP TXOP holder STA can also allow the associated AP to schedule. Potential non-AP TXOP holder STAs can also use predetermined scheduling to allocate channel access resources. The present disclosure provides a protocol that reduces the latency of accessing a channel and also improves channel utilization efficiency.

[0164] Fig.12An example embodiment 50 of a high level example of the disclosed shared TXOP protocol initiated by a non-AP TXOP holder STA is illustrated. The figure depicts the interaction between a receiver AP (AP1) 52, two non-AP transmitters in BSS1 as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. An OBSS with a receiver AP (AP2) 60, non-AP shared TXOP participant STAs 62 and 64 can be seen. A TXOP setup process 66 is performed.

[0165] During the TXOP setup process, non-AP STAs exchange TXOP shareability information, such as sharing proposals and sharing requests, through the coordination of associated APs in a single BSS. In addition, APs from different BSSs also exchange sharing proposal / request information of their associated STAs.

[0166] This figure depicts an example of conducting two TXOPs. When the non-AP TXOP holder STA 58 acquires a channel, it initializes the shared TXOP and may need to confirm which non-AP STAs (from its own BSS and OBSS) are willing to participate in the shared TXOP. The TXOP holder STA allocates channel access (RU) to other STAs (from its own BSS and from overlapping BSS) that are willing to join the shared TXOP.

[0167] The RUs allocated to a specific non-AP shared TXOP participant STA may be different in different TXOPs, for example, the first TXOP 68 and the second TXOP 92. When the shared TXOP access starts, the TXOP holder STA sends UL data on the reserved RUs. The non-AP shared TXOP participant STA sends UL data on the allocated RUs. Data is shown in the first TXOP 68 in which STA1, STA2 and STA1' share 70, 72 and 74 STA3 58's TXOP, with the header and data 76, 78, 80, 82, 84 and 86 sent to AP1 52, and the header and data 88 and 90 sent to AP2 60. Data is represented in the second TXOP 92 where STA1 and STA2′ share 94 , 96 the TXOP of STA3 58 , with the transmission of header and data 98 ​​, 100 , 102 , and 104 to AP1 52 , and with the transmission of header and data 106 and 108 to AP2 60 .

[0168] 6.3. Scene classification

[0169] Different embodiments are described in this disclosure, which include dynamic scenarios and semi-static scenarios. For dynamic scenarios, solutions are described from two aspects with and without AP coordination. For semi-static scenarios, AP is required as a coordinator.

[0170] The solution is analyzed in the OBSS topology in Section 7, followed by the frame format design in Section 8, and then a summary of the disclosure is provided.

[0171] 7. Protocol design for OBSS scenarios

[0172] 7.1. Overview of protocol design

[0173] In this section, the OBSS protocol is described with a dynamic scenario where the shared TXOP access scheduling is done on the fly and a semi-static scenario where the shared TXOP access scheduling is predetermined. In the OBSS scenario, the AP always needs to be involved to coordinate between the BSSs.

[0174] Fig.13 An example embodiment 110 of a dynamic scenario involving an AP 52, multiple non-AP shared TXOP participant STAs 54 and 56, and a non-AP TXOP holder STA 58 is illustrated, wherein the disclosed protocol has three phases, including Fig.12 The shared TXOP setup phase 66, the shared TXOP initialization phase 112, and the TXOP scheduling and access phase 114 are shown in FIG.

[0175] In the shared TXOP setup phase 66, non-AP STAs including a TXOP holder STA and a shared TXOP participant STA exchange TXOP shareability information by embedding the TXOP shareability information in an authentication frame or an association frame or any other frame exchanged via the coordination of the coordinating AP, the TXOP shareability information indicating whether the STA is willing to share the proposed / requested shared TXOP.

[0176] In the shared TXOP initialization phase 112, the non-AP TXOP holder STA obtains channel access and announces its willingness to share its TXOP with other non-AP STAs, such as by broadcasting a MU-RTS sharing frame to potential TXOP participant STAs to indicate that the TXOP is shareable. Other non-AP STAs willing to join the ensuing shared TXOP respond to the TXOP holder STA to confirm their participation (by sending back a CTS sharing frame).

[0177] In the TXOP scheduling and access phase 114, the non-AP TXOP holder STA and the non-AP shared TXOP participant STA access the channel simultaneously. The non-AP TXOP holder STA uses the reserved RUs to send UL data. Depending on which channel access protocol is utilized, the non-AP shared TXOP participant STA sends UL data by using the allocated RUs or randomly accessing the remaining RUs.

[0178] 7.2. Shared TXOP Setup Phase

[0179] Fig.14 An example embodiment 130 of the process of sharing information exchange in the shared TXOP setup phase of an OBSS scenario is illustrated. As with the previous example interactions, a first BSS (BSS1) is shown with a receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In a second BSS (BSS2), a receiver AP 60 and two non-AP transmitters as shared TXOP participants 62 and 64 can be seen.

[0180] The non-AP STAs indicate their sharing proposal / request information 132, for example, in the authentication / association request frame sent to the associated AP. A new element designed as the STA TXOP shareability element is embedded in these management frames or any other frames exchanged with the AP, such as the authentication / association response frame or the beacon frame, to exchange the sharing proposal / request information of the non-AP STAs.

[0181] The communication of the sharing frame begins the NAV (sharing) period 136. Once the associated AP receives the sharing frame containing the STA TXOP shareability element, it checks the shareability information and responds 138 to confirm successful reception, such as through an authentication or association response. The AP then broadcasts the sharing offer / request information of all associated non-AP STAs using a sharing offer / request frame 140. In this case, once the non-AP STA receives the sharing offer / request frame, it knows the shareability of other non-AP STAs and updates its database.

[0182] The AP then unicasts the OBSS sharing STA frame 142 to another AP of the neighboring BSS and indicates the shareability of all associated non-AP STAs. In response to the OBSS sharing frame being sent, the NAV (OBSS) interval 146 begins.

[0183] Once another AP 60 in the OBSS receives the OBSS shared STA frame, it checks the sharing proposal / request information of the non-AP STA indicated by the TA field and broadcasts the information 144 within its BSS using a sharing proposal / request frame with the BSSID set to the TA as indicated in the received OBSS shared STA frame.

[0184] Next, the non-AP TXOP participant 62 in BSS2 sends a sharing frame 150 to AP 60 to indicate its sharing offer / request information, and NAV (sharing) 152 begins. AP 60 acknowledges 154 the sharing frame and broadcasts sharing offer / request information 156 of all associated non-AP STAs in its BSS using a sharing offer / request frame, after which AP 60 unicasts an OBSS sharing STA frame 158 to AP 52 of BSS1, which begins NAV (OBSS sharing) 160. In response to receiving the OBSS sharing STA frame, BSS1 AP52 then broadcasts a sharing offer / request 162.

[0185] Fig.15 An example embodiment 170 of a shared TXOP setup phase for an OBSS scenario processed by an AP is illustrated. After the shared TXOP setup phase begins, the AP receives a management frame such as an authentication frame or an association request frame from a non-AP STA at 172, indicating whether the non-AP STA is willing to propose / request a shared TXOP with other non-AP STAs. The AP maintains the shareability information of the non-AP STA and sends back an authentication or association response frame at 174 to confirm successful reception.

[0186] Then at 176, the AP broadcasts a sharing proposal / request frame to all non-AP STAs in the internal BSS to update the shareability of the newly associated non-AP STA. If the BSSID field of the sharing proposal / request frame indicates the same MAC address as the MAC address in the TA field, it means that the sharing proposal / request frame is conveying the shareability information of the non-AP STA from the internal BSS. Otherwise, it means that the sharing proposal / request frame is conveying the shareability information from the inter-BSS non-AP STA whose ID is indicated by the BSSID. The AP also updates the shareability information to the OBSS by unicasting an OBSS sharing STA frame to the inter-BSS AP at 178. After receiving the OBSS sharing STA frame, at 180, the AP from the inter-BSS broadcasts the updated shareability information to the non-AP STA.

[0187] Fig.16An example embodiment of the shared TXOP setup phase for OBSS scenarios handled at the non-AP STA level is illustrated 190. After the shared TXOP setup phase begins, at 192, the non-AP STA sends a management frame to the associated AP to indicate sharing proposal / request information of its shared TXOP, and the NAV is also set to prevent interference caused by transmissions in the OBSS.

[0188] A check is made at 194 to determine if a response has been received from the associated AP. If the non-AP STA does not receive any feedback from the associated AP within a timeout period after sending an authentication frame or an association frame containing shareability information, then block 196 is reached where the management frame times out and then, in this embodiment, execution returns to block 192 because the STA should resend a management frame to the associated AP to indicate its shareability.

[0189] Otherwise, if a response is received from the associated AP, a check is performed at 198 to determine whether the non-AP STA received a sharing proposal / request frame.

[0190] If no sharing offer / request is received at block 198, the process ends. However, if the non-AP STA receives the sharing offer / request frame, then at block 200, the STA updates the latest shareability information of other non-AP STAs, which may be from inter-BSS if the BSSID field and TA field of the sharing offer / request frame indicate different MAC addresses, or from intra-BSS if the BSSID field and TA field of the sharing offer / request frame indicate the same MAC address.

[0191] 7.2. Shared TXOP Initialization Phase

[0192] Fig.17 An example embodiment 210 of a packet exchange process in the shared TXOP initialization phase for an OBSS scenario is illustrated. As with the previous example interactions, a first BSS (BSS1) is shown with a receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In a second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0193] In this scenario, the non-AP TXOP holder STA only needs to know the AID (association ID) of the shared TXOP participant STA from its own BSS, and the non-AP TXOP holder STA can schedule access for the shared TXOP participant STA of the internal BSS, and leave the scheduling work for the shared TXOP STA from between BSSs to their associated AP. Therefore, for other shared TXOP participant STAs from between BSSs, their AID information is recorded by their associated AP, while the non-AP TXOP holder STA does not need their AID information.

[0194] At this stage, the non-AP TXOP holder STA obtains the channel and is willing to share the TXOP with other non-AP STAs from within or between BSSs. It needs to confirm which other non-AP STAs from the internal BSS are willing to join its shared TXOP.

[0195] The non-AP TXOP holder STA first performs channel sounding 212 to collect beamforming information for other non-AP STAs in the inner BSS, which is named the shared TXOP holder BSS.

[0196] The non-AP TXOP holder STA then sends a multi-user request to send (MU-RTS) shared frame 214 to potential non-AP shared TXOP participant STAs, with the bandwidth (BW) indicated for each designated non-AP STA. Once the non-AP STAs receive the MU-RTS shared frame, if they are willing to join the next shared TXOP, they respond to the non-AP TXOP holder STA with a CTS shared frame 216, 218 using the BW indicated in the received MU-RTS shared frame.

[0197] The non-AP TXOP holder STA also sends a MU-RTS share frame 214 to the associated AP to announce the start of the shared TXOP. Once the AP receives the MU-RTS share frame, it knows that the shared TXOP is initiated. Then, after the CTS share frame, the AP unicasts an OBSS TXOP participant STA frame 220 to another AP in the BSS inter-BSS, which is named the shared TXOP participant BSS. The OBSS TXOP participant STA frame does not contain any information of the non-AP shared TXOP participant STA.

[0198] After receiving the OBSS TXOP participant STA frame that does not contain any information of the non-AP shared TXOP participant STA, the AP of the shared TXOP participant BSS knows that the initiation of the shared TXOP has started, and in response, sends a MU-RTS sharing frame 224 to the potential non-AP shared TXOP participant STAs, the MU-RTS sharing frame with the BW indicated for each designated non-AP STA.

[0199] Once the non-AP STAs from the shared TXOP participant BSS receive the MU-RTS sharing frame, they respond with a CTS sharing frame 226, 228 to the associated AP if they are willing to join the next shared TXOP.

[0200] After receiving all CTS sharing frames from non-AP TXOP participant STAs willing to participate in the next shared TXOP, the AP of the shared TXOP participant BSS unicasts an OBSS TXOP participant STA frame 230 with the latest information of the shared TXOP participant STA to the AP of the shared TXOP holder BSS.

[0201] After receiving the OBSS TXOP participant STA frame with information of a shared TXOP participant STA from another BSS, the AP broadcasts a CTS-to-self shared frame 232 to announce the completion of the shared TXOP initialization work in the shared TXOP participant BSS.

[0202] Upon receiving the CTS-to-self sharing frame from the associated AP, the non-AP TXOP holder STA can start the TXOP scheduling and access phase.

[0203] Fig.18 An example embodiment 250 of the shared TXOP initialization phase for an OBSS scenario handled at the non-AP TXOP holder STA level is illustrated.

[0204] Once the channel has been acquired, the non-AP TXOP holder STA first performs channel sounding at 252 and then sends (broadcasts) a MU-RTS sharing frame at 254 to potential non-AP shared TXOP participant STAs and the AP.

[0205] At block 256, it is checked whether all CTS shared frames are received. If the non-AP TXOP holder STA does not receive the CTS shared frame before the MU-RTS shared frame times out, then at block 258, a MU-RTS shared frame timeout occurs, and the execution returns to block 254, where the non-AP TXOP holder STA retransmits the MU-RTS shared frame.

[0206] If a CTS sharing frame is received, a check is made at block 260 to determine if a CTS-to-self sharing frame is received. If the non-AP TXOP holder STA does not receive a CTS-to-self sharing frame before the OBSS TXOP participant STA frame times out, a timeout 264 is reached, and then at block 266 the non-AP TXOP holder STA begins the shared TXOP scheduling and access phase with respect to its own BSS.

[0207] Otherwise, if a CTS-to-self sharing frame is received, then at block 262, the non-AP TXOP holder STA starts the shared TXOP scheduling and access phase for the OBSS scenario.

[0208] Fig.19A and Fig.19B An example embodiment 270 of the shared TXOP initialization phase for an OBSS scenario processed at the AP level is illustrated. If at block 272, it is determined that the AP receives a MU-RTS sharing frame, then at 274, the AP unicasts an OBSS TXOP participant STA frame to another AP of the shared TXOP participant BSS without indicating the shared TXOP participant STA information.

[0209] If at block 276, it is determined that the AP receives an OBSS TXOP participant STA frame that does not contain any information of a non-AP shared TXOP participant STA, the AP knows that initiation of the shared TXOP has begun, and in response, at 278, sends a MU-RTS sharing frame to potential non-AP shared TXOP participant STAs, the MU-RTS sharing frame having a BW indicated for each designated non-AP STA.

[0210] If at block 280, it is determined that the AP has received all CTS sharing frames from non-AP TXOP participant STAs that are willing to participate in the next shared TXOP, then Fig.19B In 282, the AP unicasts an OBSS TXOP participant STA frame to the AP of the TXOP holder BSS, and the OBSS TXOP participant STA frame carries the latest information of the shared TXOP participant STA.

[0211] If it is determined at block 286 that the AP has received an OBSS TXOP participant STA frame with information of a shared TXOP participant STA from another BSS, then at 286, the AP broadcasts a CTS-to-self sharing frame to announce completion of the shared TXOP initialization work in the shared TXOP participant BSS.

[0212] However, if any of the checks at blocks 272, 276, 280, or 284 fail, then processing ends without any action being taken.

[0213] Fig. 20 An example embodiment 290 of a shared TXOP initialization phase handled at the non-AP TXOP participant STA level for an OBSS scenario is illustrated.

[0214] A check is performed to determine whether the non-AP STA has received the MU-RTS sharing frame at 292. If the MU-RTS sharing frame has not been received, the process ends.

[0215] Otherwise, the non-AP STA receives the MU-RTS sharing frame, and then checks whether the non-AP STA is willing to join the next shared TXOP at 294. If the station is willing to join, then at block 296, the non-AP STA responds with a CTS sharing frame by indicating its AID using the allocated frequency band.

[0216] Otherwise, if the non-AP STA will not join the shared TXOP, then at block 298, it sends back a CTS share frame with the AID set to 0 to indicate that it will not join the shared TXOP.

[0217] 7.3.TXOP Scheduling and Access Phase

[0218] In this section, various solutions are described regarding the TXOP scheduling and reception phase design, which include the following variations: (a) random access on the scheduled band, (b) basic triggering on the scheduled band, (c) basic triggered transmission with time shift, (d) unicast TXOP access request triggering and time shift in the scheduler, which is triggered by non-AP TXOP holders, (e) unicast TXOP access request triggering and time shift in the scheduler, which is triggered by the AP, (f) broadcast TXOP access request triggering and time shift in the scheduler, which is triggered by non-AP TXOP holders, (g) broadcast TXOP access request triggering and time shift in the scheduler, which is triggered by the AP.

[0219] Fig.21An example embodiment 310 of the TXOP scheduling and access phase with random access on the scheduled band for an OBSS scenario is illustrated. This process does not require the implementation of the shared TXOP initialization process. The figure shows a first BSS using a primary band 315 and a second BSS using a secondary band 316. As with the previous example interactions, this example shows a first BSS (BSS1) with a receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In the second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0220] The non-AP TXOP holder STA first unicasts a TXOP priority trigger frame 312 to the associated AP, which indicates the reserved RUs in the RU allocation subfield and the UL BW subfield, and sets the priority field to 1 to indicate that this is a non-AP TXOP holder STA.

[0221] After receiving the TXOP priority trigger frame, the AP of the shared TXOP holder BSS sends an OBSS sharing trigger frame 314, which indicates the use of random access (by setting the random access subfield of the reserved band TXOP holder BSS field to 1) and the band reserved for the shared TXOP holder BSS (by setting the reserved band subfield of the reserved band TXOP holder BSS field) in the shared TXOP, thereby leaving the remaining band for the TXOP participant BSSs.

[0222] Then, the AP of the shared TXOP holder BSS broadcasts a TXOP random access request trigger frame 318 using the frequency band reserved for the shared TXOP holder BSS.

[0223] If the AP from the shared TXOP participant BSS receives the OBSS sharing trigger frame, it broadcasts a TXOP random access request trigger frame 320 using the remaining frequency band for the shared TXOP participant BSS.

[0224] After receiving the TXOP random access request trigger frame, the non-AP TXOP holder STA transmits UL data 326 by accessing the reserved RU. The non-AP shared TXOP participant STA randomly accesses the available RU and transmits UL data 322, 324, 328, and 330 to the associated AP.

[0225] Once the AP receives UL data from the non-AP STA, it sends back a MU-BA frame 332 , 334 .

[0226] Fig. 22 An example embodiment 350 of the TXOP scheduling and access phase with random access on the scheduled frequency band for an OBSS scenario is illustrated, which is handled at the non-AP TXOP holder STA level. At 352, the non-AP TXOP holder STA sends a TXOP priority trigger frame to the associated AP to indicate that it has the highest priority and reserved RUs for UL data transmission in the shared TXOP. At 354, a check is performed to determine whether the non-AP TXOP holder STA has received a TXOP random access request trigger frame. If the TXOP random access request trigger frame is not received before the TXOP priority trigger frame times out, box 358 is reached, and then back to box 352 as shown, the non-AP TXOP holder STA will resend the TXOP priority trigger frame. Otherwise, at 356, the non-AP TXOP holder STA uses the reserved RUs to send UL data to the associated AP.

[0227] Fig.23 An example embodiment 370 of a TXOP scheduling and access phase with random access on a scheduled frequency band, handled at the AP level, is illustrated for an OBSS scenario.

[0228] At 372, a check is made to see if a TXOP priority trigger frame has been received. If a TXOP priority trigger frame has not been received, a check is performed moving to block 384 to determine if an AP in a TXOP participant BSS has received an OBSS sharing trigger frame.

[0229] If the AP receives a TXOP Priority Trigger frame, this is the BSS of the TXOP holder STA, then execution arrives at block 374 where the STA unicasts an OBSS Sharing Trigger frame to the other AP of the shared TXOP participant BSS, indicating the remaining band for the shared TXOP participant BSS.

[0230] At 376, the AP in the shared TXOP holder BSS broadcasts a TXOP random access request trigger in the primary band (reserved for the shared TXOP holder BSS), indicating the available BW for random access of the TXOP holder BSS.

[0231] A check is made at 378 to determine if the AP has received UL data. If the AP from the shared TXOP holder BSS has received UL data, then at 382, ​​the AP sends a MU-BA frame using the reserved band and the process ends. Otherwise, at block 380, the data frame times out and then at 376, the AP rebroadcasts a TXOP random access request trigger frame as shown in block 376.

[0232] Now returning to block 384, block 384 determines whether an OBSS sharing trigger frame has been received. If the trigger frame has not been received, the process ends. Otherwise, after receiving the trigger frame, then at block 386, it broadcasts a TXOP random access request trigger in the secondary band (the remaining band for the shared TXOP participant BSS) and indicates the available BW for random access of the TXOP participant BSS.

[0233] At 388, it is checked whether UL data is received. If the AP from the shared TXOP participant BSS receives UL data, then at 392, the AP sends a MU-BA frame using the frequency band for the TXOP participant BSS, and the process ends. Otherwise, if no UL data is received, a data frame timeout occurs at 390, and then at 386, the AP rebroadcasts a TXOP random access request trigger frame.

[0234] Fig.24 An example embodiment 410 of the TXOP scheduling and access phase with random access on the scheduled frequency band for an OBSS scenario is illustrated, which is processed at the non-AP shared TXOP participant STA level. A check is made at 412 to determine whether a TXOP random access request trigger frame has been received. If the non-AP TXOP participant STA receives the TXOP random access request trigger frame, then at 414 it sends UL data to the associated AP and randomly accesses the available BW, after which the process ends. Otherwise, if at block 412 it is determined that no trigger frame has been received, then the process ends.

[0235] 7.3.2. TXOP Scheduling and Access Phase with Basic Triggering on Scheduled Band

[0236] Fig.25An example embodiment 430 of the TXOP scheduling and access phase with basic triggering on the scheduling band for an OBSS scenario is illustrated. This process does not require a shared TXOP initialization process. As with the previous example interactions, the figure depicts a first BSS (BSS1) with a receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In the second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0237] In each BSS, AT and STA use BSRP frames and BSR frames to periodically exchange buffer status and traffic priority information. A non-AP TXOP holder STA first unicasts a TXOP priority trigger frame 432 to the associated AP, which contains an indication of the reserved RUs in the RU allocation subfield and the UL BW subfield, and sets the priority field to 1 to indicate that this is a non-AP TXOP holder STA.

[0238] After receiving the TXOP priority trigger frame, the AP of the TXOP holder BSS unicasts the OBSS sharing trigger frame 434 to another AP of the shared TXOP participant BSS and indicates the reserved band for the shared TXOP holder BSS (by setting the reserved band subfield of the reserved band TXOP holder BSS field), thereby leaving the remaining band for the TXOP participant BSS.

[0239] The AP in the shared TXOP holder BSS uses the primary band 436, which is the reserved band for the TXOP holder BSS, and broadcasts the basic trigger frame 440 on the primary band. The AP in the shared TXOP participant BSS broadcasts the basic trigger frame 450 on the secondary band 438 (the remaining band for the shared TXOP participant BSS). The basic trigger frame indicates the RU allocation for the non-AP shared TXOP participant STA.

[0240] Once the non-AP TXOP participant STAs receive the basic trigger frame, they transmit UL data 442, 444, 452, and 454 to the associated AP using the allocated RUs, while the TXOP holder STA transmits UL data 446 in its reserved RUs.

[0241] Once the APs from the shared TXOP holder BSS / shared TXOP participant BSS receive the UL data, they each transmit a MU-BA frame 448, 456 using the frequency band for the shared TXOP holder BSS / shared TXOP participant BSS, respectively.

[0242] Fig.26 An example embodiment 470 of TXOP scheduling and access phase with basic triggering on a scheduling band is illustrated for an OBSS scenario, which is handled at the non-AP TXOP holder STA level.

[0243] At 472, the non-AP TXOP holder STA sends a TXOP priority trigger frame to the associated AP to indicate that it has the highest priority in the next shared TXOP and indicates the reserved RUs for UL data transmission.

[0244] A check is performed at 474 to determine whether the non-AP TXOP holder STA has received a basic trigger frame. If the basic trigger frame is not received before the TXOP priority trigger frame times out, a timeout block 476 is reached and then a return block 472 is executed to retransmit the TXOP priority trigger frame. Otherwise, if the trigger frame is received, a block 478 is reached and the non-AP TXOP holder STA uses the reserved RU to send UL data to the associated AP.

[0245] Fig. 27 An example embodiment 490 of the TXOP scheduling and access phase with basic triggering on the scheduling band is illustrated for an OBSS scenario, the TXOP scheduling and access phase being handled at the AP level.

[0246] A check is performed at 492 to determine whether a TXOP priority trigger frame has been received. If a TXOP priority trigger frame has not been received, execution moves to block 504 to perform a different check.

[0247] If a TXOP priority trigger frame is received, this is the AP of the shared TXOP holder BSS, then at 494, the AP unicasts the OBSS sharing trigger frame to the other AP of the shared TXOP participant BSS and indicates the reserved band for the shared TXOP holder BSS, thereby leaving the remaining band for the TXOP participant BSS.

[0248] At 496, the AP in the shared TXOP holder BSS broadcasts a basic trigger frame on the primary band (the reserved band for the TXOP holder BSS) and indicates RU allocations for non-AP shared TXOP participant STAs.

[0249] At 498, it is checked whether the AP from the shared TXOP holder BSS has received UL data. If the AP has received UL data, then at 502, the AP sends a MU-BA frame using the reserved frequency band. Otherwise, if at block 498, no UL data is received within the data frame timeout period, then at 500 a data timeout occurs, and execution moves to block 496, where the AP rebroadcasts a basic trigger frame.

[0250] If the frame received at block 492 is not a TXOP priority trigger frame, block 504 is reached. At block 504, a check is made to determine whether the AP has received an OBSS sharing trigger frame. If the OBSS sharing trigger frame has not been received, the process ends. Otherwise, if the frame has been received, the AP is in a shared TXOP participant BSS. At 506, the AP broadcasts a basic trigger in the secondary band (the remaining band for the shared TXOP participant BSS) indicating RU allocations for non-AP shared TXOP participant STAs in the TXOP participant BSS.

[0251] A check is performed at block 508 to determine whether the AP has received UL data. If UL data has been received, then at 512, the AP transmits a MU-BA frame using the frequency band for the TXOP participant BSS. Otherwise, if it is determined at block 508 that no UL data has been received within the data frame timeout period, then a timeout is reached block 510 is executed and the AP seeks to rebroadcast a basic trigger frame, such as returning to block 506.

[0252] Fig.28 The diagram illustrates an example embodiment of the TXOP scheduling and access phase with a basic trigger on the scheduling band for an OBSS scenario, which is handled at the non-AP shared TXOP participant STA level. If at 532, the non-AP TXOP participant STA receives the basic trigger frame, then box 534 is reached and the non-AP TXOP participant STA uses the allocated RU to send UL data to the associated AP.

[0253] 7.3.3. TXOP Scheduling and Access Phase with Basic Triggered Transmission with Time Shift

[0254] Fig.29An example embodiment 550 of the TXOP scheduling and access phase with basic triggered transmission with time shift for an OBSS scenario is illustrated. This process does not require the implementation of the shared TXOP initialization process. As with the previous example interaction, the figure shows a first BSS (BSS1) with a receiver AP 152, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In the second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. It is noted that for simplicity of illustration, the NAV interval is not shown.

[0255] In each BSS, ATs and STAs periodically exchange buffer status and traffic priority information using BSRP frames and BSR frames.

[0256] The non-AP TXOP holder STA first unicasts a TXOP priority trigger frame 552 to the associated AP, which indicates the reserved RUs for the non-AP TXOP holder STA. After the AP receives the TXOP priority trigger frame, it unicasts an OBSS shared trigger frame 554 to another AP of the shared TXOP participant BSS, and indicates the TF delay 558 (set in the TF delay field) and MU-BA delay 561 (set in the MU-BA delay field) for the transmission scheduling in the shared TXOP participant BSS. Then, the AP broadcasts a basic trigger frame 556, indicating the RU allocation and corresponding data delay duration (set in the data delay field) for the non-AP shared TXOP participant STA in the shared TXOP holder BSS.

[0257] Upon receiving the OBSS sharing trigger frame, the AP in the shared TXOP participant BSS broadcasts a basic trigger frame 560 after a trigger frame (TF) delay 558 and indicates RU allocations for non-AP shared TXOP participant STAs in the shared TXOP participant BSS.

[0258] If a non-AP TXOP participant STA or non-AP TXOP holder STA receives a basic trigger frame, it checks the data delay 562 duration indicated in the basic trigger. After the data delay duration, it sends UL data 564, 566 or 568 to the associated AP using the allocated or reserved RU. The participant STAs in the shared TXOP participant BSS also send their UL data 570, 572 to the associated AP.

[0259] As soon as the AP from the shared TXOP holder BSS receives the UL data, it immediately sends a MU-BA frame 574. The AP from the shared TXOP participant BSS also sends a MU-BA frame 576 after the MU-BA delay since it received the OBSS sharing trigger frame.

[0260] Fig.30 An example embodiment 590 of a TXOP scheduling and access phase with basic triggered transmission with time shifting is illustrated, which is handled at the non-AP TXOP holder STA level. At 592, the non-AP TXOP holder STA sends a TXOP priority trigger frame to the associated AP to indicate that it has the highest priority in the next shared TXOP and the reserved RUs for UL data transmission.

[0261] At 594, it is checked whether a basic trigger frame is received. If the non-AP TXOP holder STA does not receive the basic trigger frame before the TXOP priority trigger frame times out, a timeout block 596 is reached, after which the STA will retransmit the TXOP priority trigger frame by returning to block 592. Otherwise, after receiving the basic trigger frame, at 598, after first waiting for the data delay duration as indicated in the basic trigger frame, the non-AP TXOP holder STA sends UL data to the associated AP using the reserved RUs.

[0262] Fig.31 An example embodiment 610 of the TXOP scheduling and access phase with basic triggering on the scheduling band is illustrated for an OBSS scenario, the TXOP scheduling and access phase being handled at the AP level.

[0263] A check is made at 612 to determine if a TXOP priority trigger frame has been received. If the AP has received a TXOP priority trigger frame, then at block 614, the AP unicasts an OBSS sharing trigger frame to another AP of the shared TXOP participant BSS and indicates the TF delay and MU-BA delay for the transmit scheduling in the shared TXOP participant BSS.

[0264] At 616, the AP in the shared TXOP holder BSS broadcasts a basic trigger frame indicating RU allocation and data delay duration for non-AP shared TXOP participant STAs.

[0265] A check is performed at 618 to determine whether UL data has been received. If no UL data has been received within a given period of time, a data frame timeout occurs at 620, and the AP rebroadcasts the basic trigger frame, such as by executing back to block 616. Otherwise, if at block 618 it is determined that UL data has been received, then at 622 the AP from the shared TXOP holder BSS immediately sends a MU-BA frame.

[0266] Returning to block 612, if the priority trigger frame is not received, execution moves to block 624 to check whether the AP receives the OBSS sharing frame. If the OBSS sharing frame is not received, execution ends. Otherwise, if the OBSS sharing frame is received, the AP is determined to be the AP of the shared TXOP participant BSS, and the AP broadcasts the basic trigger frame at 626 after the TF delay and indicates the RU allocation for the non-AP shared TXOP participant STA in the TXOP participant BSS.

[0267] A check is made at 628 to determine if UL data has been received. If no UL data has been received within a given period, a data frame timeout occurs 630 and the AP rebroadcasts the basic trigger frame, such as by executing back to block 626. However, if an AP from a shared TXOP participant BSS receives UL data, then at 632 the AP sends a MU-BA frame after the MU-BA delay since it received the OBSS shared trigger frame.

[0268] Fig.32 An example embodiment 650 is illustrated of a TXOP scheduling and access phase with basic triggered transmission with time shifting, which is handled at the non-AP shared TXOP participant STA level.

[0269] A check is made at 652 to determine whether the non-AP TXOP participant STA has received the basic trigger frame. If the trigger frame has not been received, the process ends. Otherwise, when the non-AP TXOP participant STA receives the basic trigger frame, execution arrives at block 654 to check the data delay duration indicated in the basic trigger. After the data delay duration has elapsed, at 656, the STA sends their UL data to the associated AP using the allocated RU.

[0270] 7.3.4. TXOP Scheduling and Access Phase with Unicast TXOP Access Request Triggering and Time Shift in Scheduler (Triggered by Non-AP TXOP Holder)

[0271] Fig.33An example embodiment 670 of the frame exchange process in the TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler is illustrated. As with the previous example interactions, the figure shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0272] This process requires implementation of a shared TXOP initialization procedure 672.

[0273] The non-AP TXOP holder STA sends a unicast TXOP access request trigger frame 674, 678 (with a single BSS subfield of the User Information field set to 0) to each non-AP shared TXOP participant STA in the shared TXOP holder BSS, and indicates the allocated RU for each non-AP shared TXOP participant STA (as indicated in the RU Allocation subfield of the User Information field together with the UL BW subfield of the Common Information field) and the corresponding data delay 676, 680 to start UL data transmission (as defined in the Data Delay subfield of the User Information field). Then, the non-AP TXOP holder STA sends a TXOP access scheduler trigger frame 682 (with a single BSS subfield of the User Information field set to 0) to the associated AP, and indicates the allocated RU for the TXOP holder BSS (as indicated in the RU Allocation subfield of the User Information field together with the UL BW subfield of the Common Information field), and the updated data delay duration 686 for the shared TXOP participant BSS (as set in the Data Delay subfield of the User Information field).

[0274] After the AP of the shared TXOP holder BSS receives the TXOP access scheduler trigger frame, it unicasts the OBSS sharing trigger frame 684 to the other AP of the shared TXOP participant BSS and indicates the updated data delay, available band and MU-BA delay for transmission in the shared TXOP participant BSS.

[0275] The AP of the shared TXOP participant BSS receives the OBSS sharing trigger frame, which allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band. Then, it sends a unicast TXOP access request trigger frame 688, 692 to each non-AP shared TXOP participant STA, indicating the updated data delay 694 and the allocated RUs.

[0276] After the required data delays 686, 680, and 676, the non-AP stations send UL data 694, 696, and 698 to the AP of their BSS. In the OBSS, the non-AP TXOP participant STAs send UL data 700, 702 using the reserved RUs after the corresponding data delay 694 since receiving the TXOP Access Scheduler Trigger frame. The non-AP TXOP participant STAs send UL data in the allocated RUs to the associated AP after the corresponding data delay indicated in the unicast TXOP Access Request Trigger frame.

[0277] The AP of the shared TXOP holder BSS immediately broadcasts the MU-BA frame 704 after receiving the UL data. If the AP of the shared TXOP participant BSS receives the UL data, it broadcasts the MU-BA 706 after the MU-BA delay 690 based on the time when the OBSS sharing trigger frame is received.

[0278] Fig.34 An example embodiment 710 of the TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler is illustrated, which is handled at the non-AP TXOP holder STA level.

[0279] At 712, the non-AP TXOP holder STA sends a unicast TXOP access request trigger frame to each non-AP shared TXOP participant STA, indicating the allocated RU and the corresponding data delay to start UL data transmission.

[0280] Then, at 714, the non-AP TXOP holder STA sends a TXOP access scheduler trigger frame to the associated AP and indicates the RU to be used and the updated data delay for the shared TXOP holder BSS.

[0281] Then reaching block 716, waiting for the data delay for the non-AP TXOP holder STA determined from the time the TXOP access scheduler trigger frame was sent, after which the non-AP TXOP holder STA sends UL data using the reserved RU.

[0282] Fig.35 An example embodiment 730 is illustrated of the TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler, which is handled at the AP level.

[0283] A check is made at 732 to determine if a TXOP Access Scheduler Trigger frame has been received. If the AP receives a TXOP Access Scheduler Trigger frame, it knows that this is the AP of the shared TXOP Holder BSS, and then at 734, the AP unicasts an OBSS Shared Trigger frame to the APs of the shared TXOP Participant BSSs, indicating updated data delay, available band, and MU-BA delay for transmission in the shared TXOP Participant BSSs.

[0284] A check is performed at 736 to determine whether UL data has been received. If no UL data has been received, the process ends. Otherwise, after receiving the UL data, at block 738, the AP of the shared TXOP holder BSS broadcasts a MU-BA frame.

[0285] Returning to block 732, if the frame is not a TXOP access trigger frame, execution moves to block 740 to determine whether an OBSS sharing trigger frame has been received. If the OBSS sharing trigger frame has not been received, the process ends.

[0286] Otherwise, after the AP of the shared TXOP participant BSS receives the OBSS sharing trigger frame, box 742 is reached, in which the AP allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a unicast TXOP access request trigger frame indicating the updated data delay and allocated RUs for each non-AP shared TXOP participant STA.

[0287] A check is made at 744 to determine if UL data has been received. If no UL data has been received within the requisite period, a data frame timeout occurs 746 and execution returns to block 742 for another unicast of a TXOP access request frame.

[0288] Otherwise, if the AP of the shared TXOP participant BSS receives the UL data, then at 748, the AP broadcasts a MU-BA after the MU-BA delay since the receipt of the OBSS sharing trigger frame.

[0289] Fig.36 An example embodiment 750 is illustrated of the TXOP scheduling and access phase with unicast TXOP access request triggering and time shifting in the scheduler, which is handled at the non-AP TXOP participant STA level.

[0290] A check is performed at 752 to determine whether the non-AP TXOP participant STA has received a unicast TXOP access request trigger frame. If the non-AP TXOP participant STA has received a unicast TXOP access request trigger frame, then at 754, it sends UL data to the associated AP using the allocated RU after the corresponding data delay indicated in the unicast TXOP access request trigger frame.

[0291] 7.3.5. TXOP Scheduling and Access Phase with Unicast TXOP Access Request Triggering and Time Shift in Scheduler (Triggered by AP)

[0292] Fig.37 An example embodiment 770 of the TXOP scheduling and access phase with unicast TXOP access request triggering (triggered by the AP) and time shifting in the scheduler is illustrated. As with the previous example interactions, the figure shows a first BSS (BSS1) with a receiver AP 152, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In the second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0293] This process requires implementation of the shared TXOP initialization procedure 772. The non-AP TXOP holder STA sends a TXOP access scheduler trigger frame 774 to the associated AP, indicating reserved RUs for itself, and allocated RUs and corresponding data delays 776 for each non-AP shared TXOP participant STA in the TXOP holder BSS.

[0294] Once the AP of the shared TXOP holder BSS receives the TXOP access scheduler trigger frame, it sends a unicast TXOP access request trigger frame 778, 780 to each non-AP shared TXOP participant STA, indicating the allocated RU and the corresponding data delay 782, 786 to start UL data transmission. Then, it unicasts an OBSS sharing trigger frame 784 to the APs of the shared TXOP participant BSSs, and indicates the updated data delay 776, available band and MU-BA delay for transmission in the shared TXOP participant BSSs.

[0295] After the AP of the shared TXOP participant BSS receives the OBSS sharing trigger frame, it allocates RUs to each non-AP shared TXOP participant STA of the shared TXOP participant BSS based on the available frequency band. The AP then sends a unicast TXOP access request trigger frame 788, 790 to each non-AP shared TXOP participant STA, indicating the corresponding updated data delay 792 and the allocated RUs.

[0296] The non-AP TXOP holder STA sends UL data using the reserved RU after the corresponding data delay since receiving the TXOP access scheduler trigger frame 798. The non-AP TXOP participant STA sends UL data 794, 796, 800, 802 to the associated AP using the allocated RU after the corresponding data delay indicated in the unicast TXOP access request trigger frame.

[0297] The AP of the shared TXOP holder BSS broadcasts a MU-BA frame 804 after receiving UL data. If the AP of the shared TXOP participant BSS receives UL data, it also broadcasts a MU-BA 806 after the MU-BA delay 789 registered from the time the OBSS sharing trigger frame is received.

[0298] Fig.38 An example embodiment 810 of the TXOP scheduling and access phase with unicast TXOP access request triggering (triggered by the AP) and time shifting in the scheduler is illustrated, which is handled at the non-AP TXOP holder STA level. At 812, the non-AP TXOP holder STA sends a TXOP access scheduler trigger frame to the associated AP, indicating the reserved RUs for itself and the allocated RUs and corresponding data delays for each non-AP shared TXOP participant STA in the TXOP holder BSS. Then at 814, the non-AP TXOP holder STA sends UL data using the reserved RUs after the corresponding data delay.

[0299] Fig.39 An example embodiment 830 is illustrated of the TXOP scheduling and access phase, which is handled at the AP level, with unicast TXOP access request triggering (triggered by the AP) and time shifting in the scheduler.

[0300] A check is made at 832 to determine if a TXOP Access Scheduler Trigger frame has been received. If a TXOP Access Scheduler Trigger frame has been received, then this is the AP of the shared TXOP holder BSS, and then at block 834, the AP sends a unicast TXOP Access Request Trigger frame to each non-AP shared TXOP participant STA, indicating the allocated RU and the corresponding data delay to start UL data transmission.

[0301] The AP then unicasts an OBSS sharing trigger frame to the APs of the shared TXOP participant BSSs at 836, indicating updated data delay, available band, and MU-BA delay for transmission in the shared TXOP participant BSSs.

[0302] A check is performed at 838 to determine whether UL data has been received. If the AP of the shared TXOP holder BSS does not receive UL data within the required period, a data frame timeout 840 occurs, and the AP preferably retransmits the unicast TXOP access request trigger frame. Otherwise, if the AP of the shared TXOP holder BSS receives UL data, then at block 842, the AP immediately broadcasts a MU-BA frame.

[0303] Returning to block 832, if it is determined that the frame received by the AP is not a TXOP access scheduling trigger frame, execution proceeds to block 844, where it is checked whether an OBSS sharing trigger frame is received. If an OBSS sharing trigger frame is received, the AP is the AP of the shared TXOP participant BSS, and then in block 846, the AP allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a unicast TXOP access request trigger frame indicating the updated data delay and allocated RUs for each non-AP shared TXOP participant STA.

[0304] A check is made at 848 to determine if UL data has been received. If UL data has not been received within the required period, a data timeout occurs at 850 and the AP retransmits the unicast TXOP access request trigger frame, such as by returning to block 846. Otherwise, if the AP of the shared TXOP participant BSS receives UL data, then at 852, the AP broadcasts a MU-BA after the MU-BA delay since the receipt of the OBSS sharing trigger frame.

[0305] It should be noted that the flowchart of the TXOP scheduling and access phase with unicast TXOP access request triggering (triggered by AP) and time shifting in the scheduler processed at the non-AP shared TXOP participant STA level is Fig.36 The flowchart shown in .

[0306] 7.3.6. TXOP Scheduling and Access Phase with Broadcast TXOP Access Request Trigger and Time Shift in Scheduler (Triggered by Non-AP TXOP Holder)

[0307] Fig.40 An example embodiment 870 of frame exchanges in the TXOP scheduling and access phases with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler is illustrated. As with the previous example interactions, the figure shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0308] This process requires implementation of the shared TXOP initialization procedure 872. The non-AP TXOP holder STA sends a broadcast TXOP access request trigger frame 874 (with the single BSS subfield of the User Information field set to 0) indicating the reserved RUs for itself, the scheduled RUs (as indicated in the RU Allocation subfield of the User Information field together with the UL BW subfield of the Common Information field) for each non-AP shared TXOP participant STA in the TXOP holder BSS (as indicated in the AID subfield of the User Information field) and the corresponding data delay 876 (as defined in the Data Delay subfield of the User Information field).

[0309] Once the AP of the shared TXOP holder BSS receives the broadcast TXOP access request trigger frame, it unicasts the OBSS sharing trigger frame 878 to the other AP in the TXOP participant BSS and indicates the updated data delay, available band and MU-BA delay for transmission in the shared TXOP participant BSS.

[0310] After the AP of the shared TXOP participant BSS receives the OBSS sharing trigger frame, it allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a broadcast TXOP access request trigger frame 880, which indicates the updated data delay and allocated RUs for each non-AP shared TXOP participant STA in the shared TXOP participant BSS.

[0311] The non-AP TXOP holder STAs use the reserved RUs to send UL data 888 after the corresponding data delay from the reception of the broadcast TXOP access request trigger frame. The non-AP TXOP participant STAs use the allocated RUs to send UL data 884, 886, 890, 892 to their associated APs after the corresponding data delay indicated in the broadcast TXOP access request trigger frame.

[0312] The AP of the shared TXOP holder BSS broadcasts a MU-BA frame 894 after receiving UL data. If the AP of the shared TXOP participant BSS receives UL data, it broadcasts a MU-BA 896 after the MU-BA delay 882 since receiving the OBSS sharing trigger frame.

[0313] Fig.41 An example embodiment 910 of the TXOP scheduling and access phase with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler is illustrated, which is handled at the non-AP TXOP holder STA level.

[0314] At 912, the non-AP TXOP holder STA sends a broadcast TXOP access request trigger frame indicating reserved RUs for itself, scheduled RUs for each non-AP shared TXOP participant STA in the TXOP holder BSS, and corresponding data delays.

[0315] Then at 914, the non-AP TXOP holder STA sends UL data after a corresponding data delay from receiving the broadcast TXOP access request trigger frame and using the reserved RU.

[0316] Fig.42 An example embodiment 930 is illustrated of the TXOP scheduling and access phase, which is handled at the AP level, with a broadcast TXOP access request trigger (by non-AP TXOP holders) and a time shift in the scheduler.

[0317] At 932, the received frame is checked to determine whether the received frame is a broadcast TXOP access request trigger frame. If the received frame is a broadcast TXOP access request trigger frame, this is the AP of the shared TXOP holder BSS, then at 934, the AP unicasts the OBSS sharing trigger frame to another AP in the TXOP participant BSS and indicates the updated data delay, available band, and MU-BA delay for transmission in the shared TXOP participant BSS. At 936, the AP of the shared TXOP holder BSS broadcasts a MU-BA frame after receiving the UL data.

[0318] Returning to block 932, if a TXOP access request trigger frame is not received, the frame is checked at block 938 to determine whether the frame is an OBSS sharing trigger frame. If not, the process is complete. Otherwise, if the frame is an OBSS sharing trigger frame, the AP is an AP of a shared TXOP participant BSS that receives the OBSS sharing trigger frame, the AP allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a broadcast TXOP access request trigger frame at 940, the broadcast TXOP access request trigger frame including an indication of the updated data delay and allocated RUs for each non-AP shared TXOP participant STA in the shared TXOP participant BSS.

[0319] A check is made at 942 to determine if UL data has been received. If data has not been received within the requisite period, a data frame timeout occurs 944 and the TXOP access request trigger frame is rebroadcast, such as by returning to block 940 as shown.

[0320] If the AP of the shared TXOP participant BSS receives the UL data, then at 946, the AP broadcasts a MU-BA after the MU-BA delay since the reception of the OBSS sharing trigger frame.

[0321] Fig.43 An example embodiment 950 is illustrated of the TXOP scheduling and access phase handled at the non-AP TXOP participant STA level with broadcast TXOP access request triggering (by non-AP TXOP holders) and time shifting in the scheduler.

[0322] A check is performed at 952 to determine whether the non-AP TXOP participant STA has received a TXOP access request trigger frame. If this condition is met, then at block 954, the non-AP TXOP participant STA begins by sending UL data to the associated AP using the allocated RU after the corresponding data delay indicated in the broadcast TXOP access request trigger frame.

[0323] 7.3.7. TXOP Scheduling and Access Phase with Broadcast TXOP Access Request Trigger and Time Shift in Scheduler (Triggered by AP)

[0324] Fig.44An example embodiment 970 of the frame exchange process in the TXOP scheduling and access phase with broadcast TXOP access request triggering (by AP) and time shifting in the scheduler is illustrated. As with the previous example interactions, the figure shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0325] This process requires implementation of the shared TXOP initialization procedure 972.

[0326] The non-AP TXOP holder STA sends a TXOP Access Scheduler Trigger frame 974 (with the single BSS subfield of the User Information field set to 0) to the associated AP, indicating the reserved RUs for itself, and the allocated RUs (as indicated in the RU Allocation subfield of the User Information field together with the UL BW subfield of the Common Information field) and the corresponding data delay 976 (as defined in the Data Delay subfield of the User Information field) for each non-AP shared TXOP participant STA (as indicated in the AID subfield of the User Information field) in the TXOP holder BSS.

[0327] Once the AP of the shared TXOP holder BSS receives the TXOP access scheduler trigger frame, it sends a broadcast TXOP access request trigger frame 978 indicating the updated data delay (as defined in the Data Delay subfield of the User Information field) and the allocated RU (as indicated in the RU Allocation subfield of the User Information field together with the UL BW subfield of the Common Information field) for each non-AP shared TXOP participant STA in the shared TXOP holder BSS. It then unicasts an OBSS shared trigger frame 980 to another AP in the TXOP participant BSS, which includes an indication of the updated data delay, available band, and MU-BA delay 984 for transmission in the shared TXOP participant BSS.

[0328] After the AP of the shared TXOP participant BSS receives the OBSS sharing trigger frame, it allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a broadcast TXOP access request trigger frame 982, which indicates the updated data delay and allocated RUs for each non-AP shared TXOP participant STA in the shared TXOP participant BSS.

[0329] The non-AP TXOP holder STA uses the reserved RU to send UL data after the corresponding data delay from receiving the broadcast TXOP access request trigger frame 990. The non-AP TXOP participant STA uses the allocated RU to send UL data 986, 988, 992, 994 to the associated AP after the corresponding data delay indicated in the broadcast TXOP access request trigger frame.

[0330] The AP of the shared TXOP holder BSS broadcasts a MU-BA frame 996 after receiving UL data. If the AP of the shared TXOP participant BSS receives UL data, it also broadcasts a MU-BA frame 998 after the MU-BA delay from receiving the OBSS sharing trigger frame.

[0331] Fig.45 An example embodiment 1010 of the TXOP scheduling and access phase with broadcast TXOP access request triggering (by the AP) and time shifting in the scheduler is illustrated, which is handled at the non-AP TXOP holder STA level.

[0332] At 1012, the non-AP TXOP holder STA sends a TXOP access scheduler trigger frame to the associated AP, which indicates reserved RUs for itself and allocated RUs and corresponding data delays for each non-AP shared TXOP participant STA in the TXOP holder BSS.

[0333] A check is performed at 1014 to determine whether the non-AP TXOP holder STA has received a broadcast TXOP access request trigger frame. If the trigger frame is not received within a timeout interval, a timeout occurs 1016, after which the TXOP access scheduler trigger frame is resent, as shown at block 1012.

[0334] If the broadcast TXOP access request trigger frame has been received, then in block 1018, the non-AP TXOP holder STA sends UL data using the reserved RU after a corresponding data delay determined from the reception of the broadcast TXOP access request trigger frame.

[0335] Fig.46 Illustrates an example embodiment 1030 of a TXOP scheduling and access phase handled at the AP level with a broadcast TXOP access request trigger (by the AP) and time shifting in the scheduler.

[0336] A check is performed at 1032 to determine whether the AP has received a TXOP access scheduler trigger frame. If this condition is not met, the AP is an AP of a shared TXOP holder BSS, and at 1034, the AP sends a broadcast TXOP access request trigger frame indicating updated data delays and allocated RUs for each non-AP shared TXOP participant STA in the shared TXOP holder BSS.

[0337] Then at 1036, the AP of the shared TXOP holder BSS unicasts the OBSS sharing trigger frame to another AP in the TXOP participant BSS and indicates the updated data delay, available band, and MU-BA delay for transmission in the shared TXOP participant BSS.

[0338] A check is performed at 1038 to determine whether UL data has been received. If no UL data has been received within the timeout interval, a data frame timeout occurs 1040, and the AP should retransmit the broadcast TXOP access request trigger frame at 1036. If the condition of block 1038 is met because the AP of the shared TXOP holder BSS has received the UL data in time, then at 1042, the AP immediately broadcasts a MU-BA frame.

[0339] Returning to box 1032, if the received frame is not a TXOP access scheduler frame, then at box 1044, a check is performed to determine whether the frame is an OBSS sharing trigger frame. If this condition is not met, the process ends. Otherwise, the AP has received the OBSS sharing trigger frame, so that the AP is the AP of the shared TXOP participant BSS, and then at box 1046, the AP allocates RUs to each non-AP shared TXOP participant STA based on the available frequency band, and then sends a broadcast TXOP access request trigger frame, which indicates the updated data delay and allocated RUs for each non-AP shared TXOP participant STA in the shared TXOP participant BSS.

[0340] A check is made at 1048 to determine if UL data has been received. If no UL data has been received during the timeout interval, a data frame timeout occurs 1050 and processing returns to block 1046 to rebroadcast the TXOP access request trigger frame. Otherwise, if the AP of the shared TXOP participant BSS receives UL data, then at 1052 it broadcasts a MU-BA after the MU-BA delay since receiving the OBSS sharing trigger frame.

[0341] It should be appreciated that the flowchart of the TXOP scheduling and access phase with broadcast TXOP access request triggering (by the AP) and time shifting in the scheduler is similar to that of FIG. Fig.43 The same flowchart as shown in .

[0342] 7.4. Overview of Semi-static Scenes

[0343] In this scenario, two phases are designed, including a shared TXOP setting phase and a TXOP scheduling and access phase.

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

[0345] Semi-static configuration is performed at the start-up phase and allows bypassing the complex scheduling process in the TXOP scheduling and access phases. Semi-static configuration can be reset or repeated at any time. Non-AP STAs directly access the TXOP channel using the allocated RUs configured in the shared TXOP setup phase. In the semi-static scenario, APs from different BSSs participate as coordinators.

[0346] In the semi-static scenario, the described protocol has two phases: (1) a shared TXOP setup phase, which includes a shared proposal / request setup subphase and a TXOP holder configuration setup subphase, and (2) a TXOP access phase, which can be achieved through a TXOP scheduling and access phase with time shift or a TXOP scheduling and access phase on a scheduled frequency band.

[0347] 7.4.1. Shared Proposal / Request Setup Subphase of Semi-Static Protocol

[0348] Fig.47 An example embodiment 1070 is illustrated of a frame exchange sequence in a sharing proposal / request setup sub-phase of a semi-static protocol for an OBSS scenario.

[0349] As with the previous example interactions, the diagram shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP 60 and two non-AP transmitters as shared TXOP participants 62 and 64 can be seen.

[0350] The non-AP STA sends a management frame such as an authentication / association request frame or any other frame 1072 with TXOP sharing proposal / request information embedded therein to the associated AP, and indicates that it is willing to propose or request a shared TXOP, and indicates the TXOP access resource it proposes or requests, respectively, and the NAV (sharing proposal / request) interval 1074 begins. The AP receives the sharing proposal / request frame from the non-AP STA and retains the shareability information while sending back a response frame 1076 to the non-AP STA. Then, the AP broadcasts a sharing proposal / request frame 1078 to update the latest shareability information to all non-AP STAs in its own BSS (BSS1). After that, the AP unicasts an OBSS sharing STA frame 1080 to another AP (AP2) of another BSS (BSS2), which indicates the shareability of the non-AP STA of BSS1, and the NAV (OBSS sharing) 1082 begins.

[0351] Once AP2 receives the OBSS shared STA frame, it broadcasts a sharing proposal / request frame 1084 to update the latest shareability information of the non-AP STAs of BSS1 to all non-AP STAs of BSS2.

[0352] The right side of the figure then shows one of the non-AP TXOP participant STAs sending a sharing proposal / request frame 1086 to the AP, and the NAV (sharing proposal / request) interval 1088 begins. The AP sends back a response frame 1090, and then transmits a sharing proposal / request 1092, followed by an OBSS shared STA frame 1094, at which time the NAV (OBSS sharing) 1096 begins, and then the AP in the shared TXOP holder BSS issues a sharing proposal / request 1098.

[0353] Fig.48 An example embodiment 1110 of the sharing proposal / request setup sub-phase of the semi-static protocol for an OBSS scenario is illustrated, which is processed at the non-AP STA level. At 1112, the non-AP STA sends a management frame (e.g., an authentication / association request frame) with sharing proposal / request information embedded therein to the associated AP. A check is performed at 1114 to determine whether a response has been received from the AP within a timeout interval. If the non-AP STA does not receive any feedback from the associated AP within the management frame timeout, a management frame timeout occurs at 1116, and then at block 1112, the non-AP STA retransmits the management frame.

[0354] Otherwise, if the condition is met and the non-AP STA receives a response from the AP, a check is performed at 1118 to determine whether a broadcast sharing offer / request frame has been received from the AP. If the condition is not met, the process ends. Otherwise, a broadcast sharing offer / request frame has been received from the AP, and at 1120, the non-AP STA updates the shareability with respect to all other non-AP STAs.

[0355] Fig.49 An example embodiment 1130 of the sharing proposal / request setup sub-phase of the semi-static protocol for the OBSS scenario is illustrated, which is processed at the AP level. At 1132, the AP receives a management frame (e.g., an authentication / association request frame) with sharing proposal / request information embedded therein from a non-AP STA. At 1134, the AP maintains the shareability information and sends back a response frame (e.g., an authentication / association response frame) to the non-AP STA.

[0356] Then at 1136, the AP broadcasts a sharing proposal / request frame to update the latest shareability information to all non-AP STAs in its BSS (BSS1). Thereafter at 1138, the AP unicasts an OBSS sharing STA frame to another AP (AP2) of another BSS (BSS2), which indicates the shareability of non-AP STAs of BSS1.

[0357] A check is performed at 1140 to determine whether an OBSS shared STA frame has been received. If this condition is not met, the process ends. Otherwise, once AP2 receives the OBSS shared STA frame, at 1142, it broadcasts a sharing proposal / request frame to update the latest shareability information of the non-AP STAs in BSS1 to all non-AP STAs in BSS2.

[0358] 7.4.2. TXOP Holder Configuration Setup Sub-Phase for Semi-Static Protocol

[0359] Fig.50 An example embodiment 1150 of the frame exchange process in the TXOP holder configuration setup sub-phase of the semi-static protocol for an OBSS scenario is illustrated.

[0360] As with the previous example interactions, the diagram shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP 60 and two non-AP transmitters as shared TXOP participants 62 and 64 can be seen.

[0361] A potential non-AP TXOP holder STA first sends a TXOP holder configuration frame 1152 to the associated AP, indicating the scheduling and distribution of RUs to other non-AP shared TXOP participant STAs. NAV (sharing offer / request) 1154 begins.

[0362] After the AP receives the TXOP holder configuration frame from the non-AP STA, the AP maintains the shared TXOP access scheduling information and sends a response frame 1156 back to the non-AP STA. Then, the AP broadcasts a TXOP access configuration frame 1158 to update the latest TXOP access scheduling information to all non-AP STAs in its BSS (BSS1). After that, the AP unicasts an OBSS TXOP access configuration frame 1160 to another AP (AP2) of another BSS (BSS2), which indicates the shared TXOP access scheduling of BSS1. NAV (OBSS sharing) 1162 starts.

[0363] Once AP2 receives the OBSS TXOP access configuration frame, it broadcasts a TXOP access configuration frame 1164 to update the latest shared TXOP access scheduling information of the non-AP STAs of BSS1 to all non-AP STAs of BSS2.

[0364] Then, one of the non-AP TXOP participant STAs sends a TXOP holder configuration frame 1166 to the AP of BSS2, and a NAV (sharing offer / request) 1168 begins. The AP returns a response frame 1170, then sends a TXOP access configuration frame 1172, followed by an OBSS TXOP access configuration frame 1174, and a NAV (OBSS sharing) interval 1176 begins. Upon receiving the OBSS TXOP access configuration frame, the AP in BSS1 sends a TXOP access configuration frame 1178.

[0365] Fig.51 An example embodiment 1190 of the TXOP holder configuration setup sub-phase of the semi-static protocol for an OBSS scenario is illustrated, the TXOP holder configuration setup sub-phase being handled at the non-AP STA level.

[0366] At 1192, the non-AP STA sends a TXOP holder configuration frame to the associated AP and indicates the scheduling and distribution of RUs to other non-AP shared TXOP participant STAs.

[0367] A check is performed at 1194 to determine whether the non-AP STA has received a response frame from the AP. If the non-AP STA does not receive any feedback from the associated AP before the TXOP holder STA configuration frame times out, a timeout 1196 occurs and the non-AP TXOP holder STA retransmits the TXOP holder configuration frame, such as by returning to block 1192.

[0368] If the non-AP STA receives a response from the AP, a check is performed at 1198 to determine whether a TXOP access configuration frame has been received. If this condition is not met, the process ends. Otherwise, a TXOP access configuration frame has been received, and then at 1200, the non-AP STA updates the database of the overall TXOP access configuration.

[0369] Fig.52 An example embodiment 1210 of the TXOP holder configuration setup sub-phase of the semi-static protocol for an OBSS scenario is illustrated, the TXOP holder configuration setup sub-phase being handled at the AP level.

[0370] At 1212, the AP receives the TXOP holder configuration frame from the non-AP STA and maintains the shared TXOP access scheduling information, and then sends a response frame back to the non-AP STA at 1214. Then at 1216, the AP broadcasts the TXOP access configuration frame to update the latest TXOP access scheduling information to all non-AP STAs in its BSS (BSS1). Thereafter, at 1218, the AP unicasts an OBSS TXOP access configuration frame to another AP (AP2) of another BSS (BSS2), and the OBSS TXOP access configuration frame indicates the shared TXOP access scheduling of BSS1.

[0371] A check is performed at 1220 to determine whether the AP of BSS2 has received the OBSS TXOP access configuration frame. If this condition is not met, the process ends. Otherwise, the AP has received the OBSS TXOP access configuration frame, and then at 1222, it broadcasts the TXOP access configuration frame to update the latest shared TXOP access scheduling information of the non-AP STAs of BSS1 to all non-AP STAs of BSS2.

[0372] 7.5.1. TXOP Scheduling and Access Phase with Time Shift

[0373] Fig.53 An example embodiment 1230 of a semi-static protocol with time-shifted TXOP scheduling and access phases for an OBSS scenario is illustrated.

[0374] As with the previous example interactions, the diagram shows a first BSS (BSS1) with receiver AP1 52, two non-AP transmitters as shared TXOP participants 54, 56, and non-AP transmitter TXOP holder 58. In the second BSS (BSS2), receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0375] The TXOP setup phase is performed 1232. Then, the non-AP TXOP holder STA unicasts a TXOP sharing request trigger frame 1234 to the associated AP, which indicates the start of the TXOP scheduling and access phase.

[0376] After the AP receives the TXOP sharing request trigger frame, it unicasts an OBSS sharing trigger frame 1236 to another AP of the shared TXOP participant BSS and indicates the TF delay 1240 and MU-BA delay 1246 for the transmission schedule in the shared TXOP participant BSS. Then, the AP broadcasts a TXOP sharing response trigger frame 1238, which indicates the data delay duration 1244.

[0377] The AP in the shared TXOP participant BSS receives the OBSS sharing trigger frame and after a TF delay 1240 , it broadcasts a TXOP sharing response trigger frame 1242 .

[0378] If the non-AP TXOP participant STA or the non-AP TXOP holder STA receives the TXOP sharing response trigger frame, they check the data delay duration indicated in the basic trigger. After the data delay duration, they send UL data 1248, 1250, 1252, 1254 and 1256 to the associated AP using the configured RU, respectively.

[0379] Once the UL data has been received, the AP from the shared TXOP holder BSS immediately sends a MU-BA frame 1258. The AP from the shared TXOP participant BSS then sends a MU-BA frame 1260 after a MU-BA delay 1246 indicating the time since it received the 10BSS sharing trigger frame.

[0380] Fig.54An example embodiment 1270 of a semi-static protocol with time-shifted TXOP scheduling and access phases for OBSS scenarios handled at the non-AP TXOP holder STA level is illustrated. At 1272, the non-AP TXOP holder STA sends a TXOP sharing request trigger frame to the associated AP to indicate that TXOP access will begin.

[0381] A check is made at 1272 to determine whether a TXOP sharing response trigger frame has been received. If the condition is not met, the non-AP TXOP holder STA does not receive the TXOP sharing response trigger frame before the TXOP sharing request trigger frame times out, then a timeout occurs at 1276 and the non-AP TXOP holder STA retransmits the TXOP sharing request trigger frame, such as by executing back to block 1272. Otherwise, if a TXOP sharing response trigger frame has been received, then at block 1278, after a data delay duration as indicated in the TXOP sharing response trigger frame, the non-AP TXOP holder STA sends UL data to the associated AP using the configured RU.

[0382] Fig.55 An example embodiment 1290 of a semi-static protocol with time-shifted TXOP scheduling and access phases handled at the AP level for an OBSS scenario is illustrated.

[0383] A check is performed at 1292 to determine whether a TXOP sharing request trigger frame has been received. If the AP receives a TXOP sharing request trigger frame, the AP is an AP of the shared TXOP holder BSS, and then at 1294, the AP unicasts an OBSS sharing trigger frame to another AP of the shared TXOP participant BSS, indicating the TF delay and MU-BA delay for the transmission scheduling in the shared TXOP participant BSS.

[0384] Then at 1296, the AP in the shared TXOP holder BSS broadcasts a TXOP sharing response trigger frame indicating the data delay duration.

[0385] A check is performed at 1298 to determine whether UL data has been received within the timeout interval. If the UL data is not received in time, a data frame timeout occurs 1300 and the AP rebroadcasts the TXOP sharing response trigger frame, such as by executing back to block 1296.

[0386] If the AP from the shared TXOP holder BSS receives UL data, then at 1302, the AP immediately sends a MU-BA frame.

[0387] Returning to block 1292, if the received frame is not a TXOP sharing request trigger frame, execution proceeds to block 1304 where a check is made as to whether the received frame is an OBSS sharing trigger frame. If this condition is not met, then the frame does not meet either of the two conditions and the process ends. Otherwise, since the AP received the OBSS sharing trigger frame, the AP is in a shared TXOP participant BSS. At 1306, the AP broadcasts a TXOP sharing response trigger frame after a TF delay and indicates a data delay for non-AP shared TXOP participant STAs in the TXOP participant BSS.

[0388] A check is made at 1308 to determine whether UL data has been received. If no UL data has been received within the timeout period, a data frame timeout occurs 1310 and the AP rebroadcasts the TXOP sharing response trigger frame. Otherwise, the AP from the shared TXOP participant BSS receives UL data, and then at 1312, the AP sends a MU-BA frame after the MU-BA delay since it received the OBSS sharing trigger frame.

[0389] Fig.56 An example embodiment 1330 of a semi-static protocol with time-shifted TXOP scheduling and access phases handled at the non-AP shared TXOP participant STA level for an OBSS scenario is illustrated.

[0390] A check is performed at 1332 to determine whether a TXOP sharing response trigger frame has been received. If the condition is not met, the process ends.

[0391] If the non-AP TXOP participant STA receives the TXOP Sharing Response Trigger frame, it checks the data delay duration indicated in the TXOP Sharing Response Trigger at block 1334. After the data delay duration, at 1336, it sends UL data to the associated AP using the configured RU.

[0392] 7.5.2. TXOP Scheduling and Access Phase on the Scheduled Band

[0393] Fig.57An example embodiment 1350 of a semi-static protocol for the TXOP scheduling and access phase on a scheduling band for an OBSS scenario is illustrated, and operations on a primary band 1358 and a secondary band 1360 are shown. As with the previous example interactions, the figure shows a first BSS (BSS1) with a receiver AP 152, two non-AP transmitters as shared TXOP participants 54, 56, and a non-AP transmitter TXOP holder 58. In a second BSS (BSS2), a receiver AP 60 can be seen, as well as two non-AP transmitters as shared TXOP participants 62 and 64. Note that for simplicity of illustration, the NAV interval is not shown.

[0394] The shared TXOP setup 1352 is performed. Then, the non-AP TXOP holder STA unicasts a TXOP sharing request trigger frame 1354 to the associated AP, which indicates the start of the TXOP scheduling and access phase. After the AP receives the TXOP sharing request trigger frame, it unicasts an OBSS sharing trigger frame 1356 to another AP of the shared TXOP participant BSS and indicates the primary band 1358 (set in the reserved band TXOP holder BSS field), which is the reserved band for the shared TXOP holder BSS. Thus, the AP reserves the remaining band as the secondary band 1360 for the shared TXOP participant BSS. Then, the AP in the shared TXOP holder BSS broadcasts a TXOP sharing response trigger frame 1362 on the primary band.

[0395] If the AP in the shared TXOP participant BSS receives the OBSS sharing trigger frame, it broadcasts a TXOP sharing response trigger frame 1372 on the secondary frequency band.

[0396] If the non-AP TXOP participant STA or the non-AP TXOP holder STA receives the TXOP sharing response trigger frame, it transmits UL data 1364, 1366, 1368, 1374, and 1376 to the associated AP using the configured RU.

[0397] If the AP from the shared TXOP holder BSS receives UL data, it immediately sends a MU-BA frame 1370 on the primary band. Otherwise, it shall rebroadcast a TXOP Sharing Response Trigger frame.

[0398] If the AP from the shared TXOP participant BSS receives UL data, it immediately sends a MU-BA frame 1378 on the secondary band. Otherwise, it shall rebroadcast a TXOP Sharing Response Trigger frame.

[0399] Fig.58An example embodiment 1390 of a semi-static protocol for TXOP scheduling and access phase on a scheduled band for an OBSS scenario is illustrated, which is handled at the non-AP TXOP holder STA level. At 1392, the non-AP TXOP holder STA sends a TXOP sharing request trigger frame to the associated AP to indicate that TXOP access should begin.

[0400] A check is made at 1394 to determine whether a TXOP sharing response trigger frame has been received. If the non-AP TXOP holder STA does not receive the TXOP sharing response trigger frame before the TXOP sharing request trigger frame times out, a timeout occurs at 1396, and the non-AP TXOP holder STA retransmits the TXOP sharing request trigger frame, as shown here by returning to block 1392. Otherwise, the non-AP TXOP holder receives the TXOP sharing response trigger frame, and at 1398, the STA sends UL data to the associated AP using the configured RU.

[0401] Fig.59 An example embodiment 1410 of a semi-static protocol for the TXOP scheduling and access phase on a scheduled band for an OBSS scenario is illustrated, the TXOP scheduling and access phase being handled at the AP level.

[0402] A check is performed at 1412 to determine whether a TXOP sharing request trigger frame has been received. If the AP receives the TXOP sharing request trigger frame, then at 1414, the AP unicasts an OBSS sharing trigger frame to another AP of the shared TXOP participant BSS and indicates the primary band, which is a reserved band for the shared TXOP holder BSS. Thus, the AP reserves the remaining band as the secondary band for use by the shared TXOP participant BSS.

[0403] At 1416, the AP in the shared TXOP holder BSS broadcasts a TXOP sharing response trigger frame on the primary frequency band.

[0404] A check is performed at 1418 to determine if UL data has been received within the timeout interval. If this condition is not met, a data frame timeout occurs 1420, and the TXOP Sharing Response Trigger is then rebroadcast on the primary band, as shown here, and execution returns to block 1416.

[0405] If the condition is met and the AP from the shared TXOP holder BSS receives UL data, then at 1422, the AP immediately sends a MU-BA frame on the primary frequency band.

[0406] Returning to block 1412, if no TXOP sharing request trigger frame is received, a check is performed at 1424 to determine whether the frame is an OBSS sharing frame.

[0407] If the AP receives the OBSS sharing trigger frame, the AP is the AP of the shared TXOP participant BSS, and then at 1426, the AP broadcasts a TXOP sharing response trigger frame on the secondary frequency band.

[0408] A check is made at 1428 to determine if UL data has been received within the timeout interval. If this condition is not met, a data frame timeout occurs 1430 and the TXOP Sharing Response Trigger is rebroadcast on the secondary band, with execution returning to block 1426 as shown.

[0409] If the AP from the shared TXOP participant BSS receives UL data, then at 1432, it immediately sends a MU-BA frame on the secondary band.

[0410] Fig.60 An example embodiment 1450 of a semi-static protocol for TXOP scheduling and access phases on a scheduled band for an OBSS scenario is illustrated, the TXOP scheduling and access phases being handled at the non-AP shared TXOP participant STA level.

[0411] A check is made at 1452 to determine if a TXOP Shared Response Trigger frame has been received. If this condition is not met, the process ends. Otherwise, if the non-AP TXOP participant STA receives a TXOP Shared Response Trigger frame, then at block 1454, it checks the data delay duration indicated in the TXOP Shared Response Trigger. After the data delay duration, it sends UL data to the associated AP using the configured RU.

[0412] 8. Frame format design

[0413] In this section, example frame formats extending the existing 802.11 protocol in accordance with the present disclosure are presented. It should be appreciated that fields / subfields not specifically described operate in the same manner as those same fields / subfields described elsewhere or in previous exploits of existing 802.11 standards.

[0414] 8.1.STA TXOP Shareability Elements

[0415] Fig.61The diagram illustrates an example embodiment 1470 of the TXOP shareability element, which is included in management frames exchanged between an AP and a non-AP STA, such as an authentication or association request frame, an authentication or association response frame, a beacon frame, and any other management frame, and is used by each non-AP STA to notify the associated AP of its TXOP sharing proposal / request information. The shareability element has the following fields. The element ID field is an identifier of the element, in this example, it is set to a value of 8 to indicate it as a STA TXOP shareability element. If the AP receives an authentication or association request frame with the element ID field set to 8, the AP records all sharing proposal / request information for each STA (as indicated in the STA information field) and sends 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. There are multiple STA information fields, whose subfields are in Fig.62 In the description.

[0416] Fig.62 Illustration from Fig.61 The example embodiment 1490 of the STA information (info) field of the TXOP shareability element shown in , has the following subfields. The AID subfield contains the AID of the STA whose TXOP shareability is indicated. The TXOP share holder subfield indicates the shareability of the STA as a TXOP holder. The TXOP share holder subfield is set to a first value (e.g., 1) to indicate that the STA acting as a TXOP holder is willing to share its TXOP with other STAs. The TXOP share holder subfield is set to a second state (e.g., 0) to indicate that the STA acting as a TXOP holder is unwilling to share its TXOP with other STAs.

[0417] The TXOP Sharing Participant subfield indicates the shareability of the STA as a TXOP participant. The TXOP Sharing Participant subfield is set to a first state (e.g., 1) to indicate that the STA, which plays the role of a shared TXOP participant STA, is willing to join the TXOP shared by the TXOP holder STA. Otherwise, if the TXOP Sharing Participant subfield is set to a second state (e.g., 0), it indicates that the STA, which plays the role of a shared TXOP participant STA, is unwilling to join the TXOP shared by the TXOP holder STA.

[0418] 8.2 Sharing Proposal / Request Frame

[0419] Fig.63An example embodiment 1510 of the sharing proposal / request frame format is illustrated. The frame control field indicates the type of frame. The duration field contains the 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 associated with the non-AP STA. If the BSSID indicates the same MAC address as the TA, this indicates that the sharing proposal / request frame is conveying shareability information for a non-AP STA from an internal BSS; otherwise, it means that the sharing proposal / request frame is conveying shareability information for a non-AP STA from an inter BSS whose ID is indicated by the BSSID. The frame may contain multiple STA sharing proposal / request information fields, the STA sharing proposal / request information field includes the TXOP sharing proposal / request information of the non-AP STA, and has Fig.64 The subfields described in .

[0420] Fig.64 The diagram illustrates an example embodiment 1530 of the STA sharing proposal / request information field, which includes the following subfields. The priority field indicates the priority of the traffic stored in the buffer of the STA and can be used by the TXOP holder or the AP for TXOP access scheduler design. The STA AID is the AID of the non-AP TXOP participant 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, the subfield is set to a second state (e.g., 0). When the AP receives a sharing proposal / request frame with the TXOP sharing request field set to 1, the AP knows that the STA that sent the frame is willing to participate in the shared TXOP.

[0421] The TXOP Resource Request subfield indicates the number of consecutive RUs requested by the non-AP STA in the shared TXOP, as given in the basic RU (26 subcarriers) in this embodiment; a valid value range is provided from 1 to 37. The AP will broadcast this information in the sharing proposal / request frame.

[0422] The TXOP Sharing Proposal subfield is set to a first state (e.g., 1) to indicate that the STA is willing to become a non-AP TXOP holder STA and share the STA's TXOP with other STAs; otherwise, the value is set to a second state (e.g., 0). When the AP receives a sharing proposal / request frame with the TXOP Sharing Proposal field set to 1, the AP knows that the STA that sent the frame is willing to share the STA's TXOP with other STAs.

[0423] The TXOP Resource Proposal subfield indicates the number of contiguous RUs that the TXOP holder STA is willing to share with other STAs, expressed as a basic RU (26 subcarriers) with valid values ​​ranging from 1 to 37. The AP will broadcast this information in the sharing proposal / request frame.

[0424] 8.3.OBSS Shared STA Frame

[0425] Fig.65 An example embodiment 1550 of the OBSS shared STA frame format is illustrated. The frame control field indicates the type of frame. The duration field contains the NAV information for CSMA / CA channel access. The RA field indicates the BSSID of the reception of the trigger frame. The TA field indicates the BSSID of the transmission of the trigger frame.

[0426] One or more STA sharing proposal / request information fields may be provided in this frame. The contents of each field are Fig.64 In the description.

[0427] The OBSS shared STA frame is sent from one AP to another AP. Once the AP receives the OBSS shared STA frame, it checks the sharing proposal / request information of the non-AP STA and the sent BSSID and broadcasts the information within its BSS.

[0428] 8.4.MU-RTS Sharing

[0429] Fig.66 An example embodiment 1570 of a MU-RTS shared frame with the following fields is illustrated. The MAC header contains frame control, duration, RA, and TA information. 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 and the list user information field can be seen.

[0430] A common information field is shown with the following subfields. The Trigger Type subfield of the Common Information field identifies the trigger frame variant. In at least one embodiment, if these bits are set to 3 and the TXOP Shared subfield (B63) is set to 1, this indicates that it is a MU-RTS shared frame. If an AP or non-AP STA receives a MU-RTS shared frame, it knows that the shared TXOP is initialized, to which it should respond with a CTS shared frame using the designated RU as indicated in the MU-RTS shared frame (indicated by the UL BW subfield of the Common Information and the RU Allocation subfield of the User Information field). The Upload (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.6fKs GI or 4x HE-LTF+3.2fKs 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 set to the first state (e.g., 0), the HE-LTF symbol number and midamble periodicity subfield indicate the number of HE-LTF symbols present in the HE TB PPDU, and if the Doppler subfield is set to the second state (e.g., 1), the number of HE-LTF symbols and the periodicity of the midamble are indicated.

[0431] The field continues at bit 26, the UL STBC subfield indicates the state of the STBC encoding of the requested HE TB PPDU. The LDPC Extra Symbol Segment subfield indicates the state 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 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. The Pre-FEC Filling Factor subfield indicates the Pre-FEC filling factor. The PE Disambiguation subfield indicates the PE disambiguation. The UL Spatial Reuse subfield carries the value of the Spatial Reuse field to be included 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, otherwise it is set to a second state (e.g., 0). The UL HE-SIG-A2 reserved subfield carries the value in the reserved field in the HE-SIG-A2 subfield of the requested HE TB PPDU to be included. The TXOP sharing subfield of the common information field set to a first state (e.g., 1) indicates 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). Based on the value of the trigger type field, the trigger-related common information subfield is optionally present.

[0432] Returning to the top of the figure, the list user information field can be seen, and the user information 1 field, the user information 2 field to the user information n field are shown, each of which has subfields as depicted in the middle of the figure below. The user information field contains RU information allocated for a specific STA. The AID12 subfield of the user information field is used to allocate a fixed RU to a specific STA whose AID is equal to 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 HETB PPDU. The SS allocation subfield indicates the spatial stream of the requested HE TB PPDU. The RA-RU information subfield indicates the RA-RU information. The UL target RSSI subfield indicates the expected received signal power of the HE part of the HE TB PPDU sent on the allocated RU. Based on the value of the trigger type field, a trigger related user information subfield optionally exists.

[0433] 8.5.CTS Sharing

[0434] Fig.67 The diagram illustrates an example embodiment 1590 of a CTS sharing frame having the following fields. The frame control field indicates the type of frame. The duration field contains the 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 that sent the CTS sharing frame. Once the TXOP holder receives a CTS sharing frame as an immediate response to a previously sent MU-RTS sharing frame, by checking the TXOP sharing participant AID information, it knows which STAs are willing to join the shared TXOP and allocates resources to these STAs accordingly. If a non-AP STA receives a MU-RTS sharing frame addressed to it, but has nothing to send to the AP, in at least one embodiment, the non-AP STA sets the TXOP sharing participant AID to 0 to indicate that it will not join the next shared TXOP.

[0435] 8.6.OBSS TXOP Participant STA Frame

[0436] Fig.68 An example embodiment 1610 of an OBSS TXOP participant STA frame format is illustrated with the following fields. The Frame Control field indicates the type of frame. The Duration field contains the NAV information for CSMA / CA channel access. The RA field contains the BSSID of the receiver of this trigger frame. The TA field contains the BSSID of the transmitter of this trigger frame. One or more TXOP Resource Request STA fields are shown, with subfields in Fig.69 In the description.

[0437] Fig.69 An example embodiment 1630 of a TXOP Resource Request STA field is illustrated with the following subfields. Fig.64 Once the AP receives the MU-RTS sharing frame, it knows that the shared TXOP has been initiated. The AP then unicasts the OBSS TXOP participant STA frame to another AP of the shared TXOP participant BSS. The OBSS TXOP participant STA frame does not contain any information of the non-AP shared TXOP participant STA.

[0438] After receiving a frame containing no information of a non-AP shared TXOP participant STA from an OBSS TXOP participant STA, the AP of the shared TXOP participant BSS knows that initiation of the shared TXOP has started and sends a MU-RTS sharing frame to potential non-AP shared TXOP participant STAs.

[0439] After receiving all CTS sharing frames from non-AP TXOP participant STAs willing to participate in the next shared TXOP, the AP of the shared TXOP participant BSS unicasts the OBSS TXOP participant STA frame with the latest information of the shared TXOP participant STA to the AP of the shared TXOP holder BSS.

[0440] After receiving the OBSS TXOP participant STA frame with information of the shared TXOP participant STA from another BSS, the AP broadcasts a CTS-to-self sharing frame to announce in the shared TXOP participant BSS that the shared TXOP initialization process has been completed.

[0441] 8.7.CTS-to-self sharing

[0442] Fig.70 The diagram illustrates an example embodiment 1650 of a CTS-to-self frame format with the following fields. The frame control field indicates the type of frame. The duration field contains the NAV information for CSMA / CA channel access. The RA field contains the MAC address of the recipient of the frame. In a single BSS scenario, the TXOP holder STA may first unicast a CTS-to-self frame with the RA field equal to its own MAC address to the AP in order to reserve the medium for TXOP transmission. When the AP receives the CTS-to-Self frame, it broadcasts a MU-RTS sharing frame to potential TXOP sharing participant STAs. In an OBSS scenario, after receiving an OBSS TXOP participant STA frame with information of a shared TXOP participant STA from another BSS, the AP broadcasts a CTS-to-self sharing frame to announce the completion of the shared TXOP initialization process in the shared TXOP participant BSS.

[0443] Once a non-AP TXOP holder STA receives the CTS-to-self sharing frame, it can start the TXOP scheduling and access phase. NAV can be set in the duration field of the CTS-to-self frame. Bits 0-13 are set to contain the NAV duration value, which ranges from 1-16383. Bits 14-15 are set to contain sharing information and, when set to 01, indicate that the TXOP holder is willing to share the TXOP with other STAs. The AP that receives the CTS-to-self frame from the TXOP holder STA sends a MU-RTS sharing frame to the potential TXOP sharing participant STAs.

[0444] 8.8.TXOP Priority Trigger Frame

[0445] Fig.71 An example embodiment 1670 of a TXOP priority trigger frame format is illustrated with the following subfields. The Frame Control field indicates the type of frame. The Duration field contains the 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 and the List User Information field are described below.

[0446] The common information field is represented as having the following subfields. The trigger type subfield in this example is set to 12 (this field was previously reserved) to indicate that this is a TXOP priority trigger frame. The TXOP holder STA will reserve RUs for itself and share the remaining RUs with other STAs. After unicasting the TXOP priority trigger frame to the AP, the TXOP holder waits for a trigger frame with scheduled TXOP access information from the AP. After receiving the TXOP priority trigger frame, the AP performs shared TXOP access scheduling and triggers UL transmission. The AP allocates more resources to the TXOP holder STA.

[0447] 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 send trigger frames and normalized to a 20 MHz bandwidth.

[0448] The List User Information field contains the following subfields. The AID12 subfield (1-2007) of the User Information field is addressed to the associated STA whose AID is equal to the value in the AID12 subfield; the 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 Priority subfield of the User Information field indicates the priority of the STA that sent the TXOP Priority Trigger frame. When this subfield is set to the first state (e.g., 1), this indicates that the sender is the TXOP holder, so that the AP will allocate sufficient RU size, which cannot be less than the RU size indicated by the RU Allocation subfield and the UL BW subfield.

[0449] 8.9.OBSS Shared Trigger Frame

[0450] Fig.72The diagram illustrates an example embodiment 1690 of an OBSS shared trigger frame having the following subfields. The Frame Control field indicates the type of frame. The Duration field contains NAV information for CSMA / CA channel access. The RA field is the BSSID of the reception of the trigger frame. The TA field is the BSSID of the transmission of the trigger frame. The Reserved Band TXOP Holder BSS field indicates that the reserved band can be used by the shared TXOP holder BSS for data transmission, so that the remaining band can be utilized by the shared TXOP participant BSS. The TF Delay field indicates the delay duration between the AP receiving the OBSS shared trigger frame and sending the trigger frame. The Data Delay field indicates the delay duration between the reception of the OBSS shared trigger frame and the reception of UL data. The MU-BA Delay field indicates the delay duration between the AP receiving the OBSS shared trigger frame and sending the MU-BA frame to the associated AP.

[0451] Fig.73 An example embodiment 1710 of the Reserved Band TXOP Holder BSS field is illustrated with the following subfields. The Reserved Band subfield of the Reserved Band TXOP Holder BSS field indicates that the OBSS sharing trigger frame reserves the band for the TXOP holder BSS and leaves the remaining band for the TXOP participant BSSs. The combination of bits B0-B3 and bits B4-B5 indicates the reserved band. The Random Access subfield of the Reserved Band TXOP Holder BSS field indicates that the OBSS sharing frame triggers random access for non-AP STAs in the shared TXOP BSS. The Scheduled Access subfield of the Reserved Band TXOP Holder BSS field indicates that the OBSS sharing frame triggers scheduled access for non-AP STAs in the shared TXOP BSS.

[0452] 8.10.TXOP Random Access Request Trigger Frame

[0453] Fig.74 An example embodiment 1730 of a TXOP random access request trigger is illustrated with the following subfields. The Frame Control field indicates the type of frame. The Duration field contains the 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 Public Info field and the List User Info field are described below.

[0454] The public Info field has the following subfields. In this example embodiment, the trigger type subfield is set to 8 (using the previously reserved bit) 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 or receiving a TXOP random access request trigger, 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 while competing for the shared RUs. The TXOP holder STA uses the reserved RUs to access the channel. 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 a coordinator) or the non-AP TXOP holder STA (for dynamic scenarios without the AP as a coordinator) at the antenna connectors of all transmit antennas used to send the trigger frame and normalized to a 20MHz bandwidth.

[0455] The List User Info field has the following subfields. The TXOP holder STA announces the reserved RUs in the UL BW subfield of the common information and the RU allocation subfield of the user information field. In addition, it will announce its own AID in the AID12 subfield, and in at least one embodiment, the range of the AID12 subfield is 1 to 2007. For other associated STAs, the AID12 subfield of the user information field is set to 0, and then bits B26-B31 of the user information field are set to the RA-RU information subfield. In this case, the SS allocation / RA-RU information subfield of the user information field indicates the RA-RU information. The RA-RU information subfield is shown with additional subfields for the number of RA-RUs and more RA-RUs.

[0456] The RA-RU Number subfield indicates the number of consecutive RUs allocated for UL OFDMA random access (UORA). The value of the RA-RU Number subfield is equal to the number of consecutive RA-RUs minus 1. The More RA-RU subfield is set to a first state (e.g., 1) to indicate that the RA-RU of the type indicated by the AID12 subfield in the User Information field is allocated in subsequent trigger frames sent until the end of the TWT SP in which the trigger frame carrying the field is sent; 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-RU subfield is reserved.

[0457] 8.11. Unicast TXOP Access Request Trigger Frame

[0458] Fig.75An example embodiment 1750 of a unicast TXOP access request trigger frame format with the following fields is illustrated. The Frame Control field indicates the type of frame. The Duration field contains the 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 and the List User Information field are described below.

[0459] The Common Information field is shown having the following subfields: In this example embodiment, the Trigger Type subfield is set to 9 (these bits were previously reserved) to indicate that this is a Unicast TXOP Access Request Trigger frame.

[0460] 8.11.1. For single BSS scenario

[0461] After sending the last (indicated by the TXOP Access Start Flag subfield) unicast TXOP access request trigger frame, the TXOP holder STA shall unicast UL data to the AP in the reserved RUs.

[0462] After receiving the last unicast TXOP access request trigger frame (even if the destination is another STA), the TXOP sharing participant STA shall unicast UL data to the AP in the allocated RU.

[0463] 8.11.2. For OBSS scenarios

[0464] After sending / receiving a unicast TXOP access request trigger frame, the non-AP STA sends out UL data after the data delay indicated in the trigger frame.

[0465] 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 send trigger frames and normalized to a 20 MHz bandwidth.

[0466] The List User Information field contains the following subfields. The AID12 subfield (1-2007) of the User Information field is addressed to the associated STA whose AID is equal to the value in the AID12 subfield, the 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 for a single BSS scenario or for 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 is not used in a single BSS scenario. For an OBSS scenario, the Data Delay subfield is used to indicate the delay in sending data, and the TXOP Access Start Flag subfield is not used.

[0467] The TXOP access start flag subfield indicates whether the unicast TXOP access request trigger frame has been sent by the TXOP holder to the last TXOP sharing participant STA. If this is the last TXOP sharing participant STA, the flag is set to a first state (e.g., 1); otherwise, the flag is set to a second state (e.g., 0).

[0468] For each TXOP sharing participant STA that receives a unicast TXOP access request trigger, even if the frame is not sent to it, the STA still checks the TXOP access start flag subfield. If the field is 0, the STA keeps the data; otherwise, if the field is 1, the STA sends its data to the AP.

[0469] 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.

[0470] 8.12.TXOP Access Scheduler Trigger Frame

[0471] Fig.76 An example embodiment 1770 of a TXOP Access Scheduler Trigger frame format with the following fields is illustrated. The Frame Control field indicates the type of frame. The Duration field contains the 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 and the List User Information field are described below.

[0472] The Common Information field is shown as having the following subfields: In this example embodiment, the Trigger Type subfield of the Common Information field is set to 11 (these bits were previously reserved) to indicate that this is a TXOP Access Scheduler Trigger frame.

[0473] 8.12.1. For single BSS scenario

[0474] After sending the 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.

[0475] 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 1.

[0476] 8.12.2. For OBSS scenarios

[0477] After sending the TXOP access scheduler trigger frame, the TXOP holder STA unicasts UL data to the AP after the data delay duration. After receiving the TXOP access scheduler trigger frame, the AP sends a unicast TXOP access request trigger frame to each TXOP sharing participant STA by setting the corresponding data delay duration.

[0478] 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 send trigger frames and normalized to a 20 MHz bandwidth.

[0479] The List User Information field contains one or more groups of user information, each group of user information has the following subfields. The AID12 subfield (1-2007) of the User Information field 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 identifies the size and location of the RU together with the UL BW subfield in the Common Information field. The Data Delay subfield of the User Information field indicates the delay duration for a non-AP STA whose AID is equal to the value in the AID12 subfield to send UL data.

[0480] 8.13. Broadcast TXOP Access Request Trigger Frame

[0481] Fig.77 An example embodiment 1790 of a broadcast TXOP access request trigger frame format with the following fields is illustrated. The Frame Control field indicates the type of frame. The Duration field contains the 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 and the List User Information field are described below.

[0482] The Common Information field is shown as having the following subfields: In this example embodiment, the Trigger Type subfield of the Common Information field is set to 10 (these bits were previously reserved) to indicate that this is a Broadcast TXOP Access Request Trigger frame.

[0483] 8.13.1. For single BSS scenario

[0484] After sending the broadcast TXOP access request trigger frame, the TXOP holder STA unicasts UL data to the AP in the reserved RU. After receiving the broadcast TXOP access request trigger frame, the TXOP sharing participant STA unicasts UL data to the AP in the allocated RU.

[0485] 8.13.2. For OBSS scenarios

[0486] After sending the broadcast TXOP access request trigger frame, the TXOP holder STA unicasts UL data to the AP in the reserved RU after data delay. After receiving the broadcast TXOP access request trigger frame, the TXOP sharing participant STA unicasts UL data to the AP in the allocated RU after data delay.

[0487] 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 send trigger frames and normalized to a 20 MHz bandwidth.

[0488] The List User Information field contains the following subfields. The AID12 subfield (1-2007) of the User Information field 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 identifies the size and location of the RU together with the UL BW subfield in the Common Information field. The Data Delay subfield of the User Information field indicates the delay duration for a non-AP STA whose AID is equal to the value in the AID12 subfield to send UL data.

[0489] 8.14.TXOP holder configuration

[0490] Fig.78 An example embodiment 1810 of a TXOP holder configuration frame format with the following fields is illustrated: Frame Control field, Duration field, RA field, and TA field are as described above. One or more STA TXOP access allocation fields are included, and the STA TXOP access allocation field indicates the TXOP access allocation for each specific STA.

[0491] Fig.79 An example embodiment 1830 of the STA TXOP Allocation field format is illustrated, which includes the following fields. 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. The Allocation Control Information field includes the following: Fig.80 TXOP resource allocation information described in.

[0492] After the AP receives the TXOP holder configuration frame, the AP records the STA TXOP access allocation information and sends a confirmation frame to the STA.

[0493] Fig.80 Illustrated is an example embodiment 1850 of an Allocation Control Information subfield indicating a TXOP resource allocation for a particular TXOP sharing participant STA, and having the following subfields. The Priority subfield indicates the priority of the traffic of the TXOP sharing participant STA. The AID12 (1-2007) 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 TBPPDU. The RU Allocation subfield, together with the UL BW subfield, identifies the size and location of the allocated RU.

[0494] 8.15.TXOP access configuration

[0495] Fig.81 An example embodiment 1870 of the TXOP access configuration frame format is illustrated. The frame control field indicates the type of frame. The duration field contains the NAV information for CSMA / CA channel access. The RA field is the BSSID of the reception of the trigger frame. The TA field is the BSSID of the transmission of the trigger frame. Contains one or more STA configuration fields.

[0496] The STA configuration field indicates the configuration for each non-AP STA and contains one or more STA TXOP access allocation fields (e.g., 1 to N). After receiving a trigger from a TXOP holder (without AP as coordinator) or from an associated AP (with AP as coordinator), the STA uses the allocated RU to send data to the AP.

[0497] 8.16.OBSS TXOP Access Configuration

[0498] Fig.82An example embodiment 1890 of the OBSS TXOP access configuration frame format is illustrated with the following fields. The Frame Control field indicates the type of frame. The Duration field contains the 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 field indicates the ID of the BSS that generated the TXOP access configuration information. The BSSID is the MAC address of the AP in the BSS. The remaining fields are similar to those in FIG. Fig.81 The TXOP access configuration frame is the same as shown in .

[0499] The OBSS TXOP Access Configuration frame is sent from one AP to another AP to indicate the complete TXOP access configuration of the BSS of the sender AP.

[0500] 8.17.TXOP sharing request trigger

[0501] Fig.83 The diagram illustrates an example embodiment 1910 of a TXOP sharing request trigger frame format with the following fields. It should be noted that the user information list field is not required in the TXOP sharing request trigger frame format. The TA field contains the MAC address of the transmitter, which should be set to the MAC address of the TXOP holder. The RA field is the MAC address of the receiver set as follows. In a scenario where the AP is not the coordinator, the RA field is set to the broadcast MAC address (ff:ff:ff:ff:ff:ff). The TXOP holder broadcasts the TXOP sharing request trigger frame. Once the TXOP sharing participant STA receives the frame, they send UL data to the associated AP by using the allocated RUs as configured in the shared TXOP configuration phase. After sending the TXOP sharing request trigger frame, the TXOP holder sends UL data to the associated AP using the allocated RUs.

[0502] In the scenario using AP as coordinator, the RA field is set to the MAC address of the associated AP. The TXOP holder unicasts the TXOP sharing request trigger frame. Once the AP receives the frame, it broadcasts the TXOP sharing response trigger frame. All STAs shall then send UL data to the associated AP using the allocated RUs as configured in the shared TXOP configuration phase.

[0503] The other fields are as described in previous sections of this article.

[0504] 8.18.TXOP Shared Response Trigger

[0505] Fig.84An example embodiment 1930 of a TXOP sharing response trigger frame format is illustrated with the following fields. Note that the User Information List field need not be included in the TXOP sharing request trigger frame format. The RA field is the MAC address of the receiver, which is set to the broadcast MAC address (ff:ff:ff:ff:ff:ff) in the scenario where the AP acts as a coordinator. The Data Delay field indicates the delay duration between the reception of the TXOP sharing response trigger and the transmission of the UL data in the OBSS scenario. The other fields are as described in the previous sections herein.

[0506] 9. General Scope of the Embodiments

[0507] The enhancements described in the present 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 processor device 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 medium, 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.

[0508] It is also to be appreciated that the computer-readable media (memory storing instructions) in these computing systems is "non-transitory," which includes any and all forms of computer-readable media, with the sole exception of transitory propagating signals. Thus, the disclosed technology may include any form of computer-readable media, including those that are randomly accessed (e.g., RAM), those that require periodic refreshing (e.g., DRAM), those that degrade over time (e.g., EEPROM, magnetic disk media), or those that store data only for a short period of time and / or only while power is present, with the only limitation being that the term "computer-readable medium" does not apply to transitory electronic signals.

[0509] 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.

[0510] Thus, the blocks of the flowchart, 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 flowchart, and any process, algorithm, step, operation, formula or calculation description and combination thereof described herein can be implemented with a computer system based on dedicated hardware that performs the specified function or step, or a combination of dedicated hardware and computer-readable program code.

[0511] In addition, these computer program instructions (such as embodied as computer-readable program codes) 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 so that the instructions stored in the computer-readable memory or storage device produce a manufactured product 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 so that a series of operating steps are performed on the computer processor or other programmable processing device, thereby producing a computer-implemented process, so that the instructions executed on the computer processor or other programmable processing device provide steps for implementing the functions specified in the blocks, processes, algorithms, steps, operations, formulas or calculation descriptions of the flowchart.

[0512] 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 in 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. The remotely stored instructions may be downloaded (pushed) to the device by a user, or automatically downloaded (pushed) to the device based on one or more factors.

[0513] 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 include one or more devices, single-core and multi-core devices, and variations thereof.

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

[0515] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first station for wireless communication over at least one channel with at least one other station in the same or another basic service set (BSS) or from an overlapping basic service set (OBSS); (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) in a frequency domain with other stations in the OBSS by performing steps comprising: (d) (i) enabling a non-AP to share a transmit opportunity (TXOP) with other stations in the OBSS; and (ii) enabling a non-AP to share a transmit opportunity (TXOP) with other stations in the OBSS. A station exchanges sharing proposal and request information with an access point (AP) station to notify the AP and / or obtain approval from the AP to share the TXOP of the non-AP station with other non-AP stations of the shared TXOP holder BSS; (d)(ii) wherein the sharing proposal and request information is shared with the AP of an overlapping BSS that is a shared TXOP participant BSS; (d)(iii) when access to the at least one channel is obtained, exchanges information with other stations to indicate that the upcoming TXOP can be used for sharing and identifies stations willing to join the upcoming shared TXOP; (d)(iv) wherein the AP of the shared TXOP participant BSS identifies the shared TXOP participant STA; and (d)(v) enables the non-AP TXOP holder station to distribute resource units (RUs) to the shared TXOP participant stations in the TXOP holder BSS, and in the shared TXOP participant BSS, determines the scheduling and distribution of RUs for the shared TXOP participant stations at the AP level.

[0516] A method for wireless communication in a network, comprising: (a) wireless communication between a wireless communication circuit configured as a first station and at least one other station in the same or another basic service set (BSS) or from an overlapping basic service set (OBSS) through at least one channel, so as to share a transmit opportunity (TXOP) with other stations in the OBSS in the frequency domain; (b) exchanging sharing proposal and request information with an access point (AP) station to notify the AP and / or obtain approval from the AP to share the TXOP of a non-AP station with other non-AP stations of the shared TXOP holder BSS; (c) wherein the sharing proposal and request information is shared with an AP of an overlapping BSS that is a shared TXOP participant BSS; (d) when access to the at least one channel is obtained, exchanging information with other stations to indicate that an upcoming TXOP can be used for sharing and to identify stations willing to join the upcoming shared TXOP; (e) wherein the AP of the shared TXOP participant BSS identifies the shared TXOP participant STA; (f) enabling the non-AP station to A TXOP holder station is capable of distributing resource units (RUs) to shared TXOP participant stations in a TXOP holder BSS, and in the shared TXOP participant BSS, scheduling and distribution of RUs for shared TXOP participant stations are determined at the AP level; and (g) wherein the method is performed by one or more processors executing instructions stored on a non-transitory medium.

[0517] A device for wirelessly communicating with a station (STA) that obtains a transmit opportunity (TXOP) in a wireless LAN network, wherein the station (STA) shares its TXOP with other STAs in an OBSS in the frequency domain by performing the following steps: (a) exchanging messages with an access point (AP) station to notify and / or obtain permission to share the station's TXOP with other non-AP STAs. The APs of overlapping BSSs further exchange this information with each other; and (b) when gaining access to the channel, exchange information with other STAs to indicate that the upcoming TXOP can be used for sharing and identify STAs willing to join the upcoming shared TXOP; (c) the non-AP TXOP holder STA allocates RU distribution to the shared TXOP participant STAs in the internal BSS, wherein within the shared TXOP participant BSS, the scheduling and distribution of RUs for the shared TXOP participant STAs are left to the AP level; wherein in order to avoid interference between different BSSs, different frequency bands are used using scheduling or time shifting methods; (d) STAs of a single BSS exchange information on TXOP shareability by exchanging management frames under the coordination of the AP, wherein APs of different BSSs exchange this information by sending OBSS shared STA frames.

[0518] The apparatus or method of any preceding implementation, wherein OBSS TXOP participant station frames are utilized to synchronize shared operations between different BSSs.

[0519] Any preceding implementation of the apparatus or method, wherein different frequency bands are used or time shifting is performed to avoid interference between different BSSs.

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

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

[0522] Any of the aforementioned implementations of the apparatus or method, wherein APs of different BSSs exchange information regarding TXOP sharing proposal / request information by exchanging OBSS shared station frames.

[0523] Any of the aforementioned implementations of the apparatus or method, wherein the instructions, when executed by the processor, further perform one or more steps, including: the shared TXOP holder station or the AP in each BSS identifies the shared TXOP participant stations by exchanging multi-user request to send (MU-RTS) shared frames and clear to send (CTS) shared frames.

[0524] Any of the aforementioned implementations of the apparatus or method, wherein the instructions, when executed by the processor, further perform one or more steps, including: in a shared TXOP participant BSS, starting a shared TXOP initialization phase by receiving an OBSS TXOP participant station frame from an AP in a shared TXOP holder BSS without specifying a shared TXOP participant STA, and completing the shared TXOP initialization phase by sending back an OBSS TXOP participant station frame to the AP in the shared TXOP holder BSS with all shared TXOP participant stations specified.

[0525] Any of the aforementioned devices or methods implements the described device, wherein the instructions, when executed by the processor, further perform one or more steps, including: avoiding interference between overlapping BSSs due to shared TXOP access by sending frames simultaneously in different BSSs but on different frequency bands, or sending frames on the same frequency band but time-shifted.

[0526] Any of the aforementioned implementations of the apparatus or method, wherein shared TXOP access on different frequency bands comprises: performing scheduling based on random access and dedicated triggering, wherein the dedicated triggering comprises a basic triggering.

[0527] The apparatus or method of any preceding implementation, wherein shared TXOP access using time shifting includes scheduling based on: basic triggering, unicast TXOP access request triggering (with or without AP as coordinator), and broadcast TXOP access request triggering (which may or may not be performed using AP as coordinator).

[0528]

[0046] The apparatus or method of any preceding implementation, wherein the time shift information between the shared TXOP holder BSS and the shared TXOP participant BSS is exchanged by utilizing an OBSS sharing trigger frame.

[0529] Any of the aforementioned implementations of the apparatus or method, wherein when a trigger frame is received from the AP, the non-AP TXOP sharing participant station accesses the at least one channel according to the access information indicated in the trigger frame.

[0530] The apparatus or method of any preceding implementation, wherein non-AP stations determine both resource unit (RU) allocation and access order in a semi-static configuration for other non-AP stations from the same BSS and the OBSS accessing its TXOP by exchanging messages using AP coordination in a single BSS or OBSS scenario.

[0531] Any of the aforementioned implementations of the described apparatus or method, wherein the non-AP STA performs a setup process to set a semi-static configuration: (a) the non-AP stations exchange sharing proposal / request frames with each other through AP coordination in each BSS, and the AP further forwards the sharability information to another AP of the OBSS, after which the other AP broadcasts the received sharability information; (b) the non-AP stations exchange configurations of semi-static TXOP sharing scheduling with each other through AP coordination in each BSS, and the AP further forwards the shared TXOP access scheduler to another AP of the OBSS, after which the other AP broadcasts the received shared TXOP access scheduler in the OBSS; and (c) a scheduling method or a time-shifting method is performed to avoid interference between different BSSs utilizing different frequency bands in TXOP sharing, wherein the non-AP station uses the configured RU to access the shared TXOP.

[0532] The apparatus or method of any preceding implementation, wherein the allocation of resource unit (RU) distribution comprises an allocation schedule announced by a non-AP TXOP holder station for access to a shared TXOP, wherein non-AP stations from the same BSS / OBSS sharing the TXOP follow the announced allocation schedule.

[0533] The apparatus or method of any preceding implementation, wherein the shared TXOP access begins with a non-AP TXOP holder station unicasting a TXOP sharing request trigger, wherein in response to the TXOP sharing request trigger, the AP broadcasts a TXOP sharing response trigger with a time shift or a different frequency band scheduling to avoid OBSS interference.

[0534] Any of the aforementioned implementations of the apparatus or method, wherein the response trigger with time shift is performed by exchanging time shift information between a shared TXOP holder BSS and a shared TXOP participant BSS in an OBSS shared trigger frame.

[0535] Any of the aforementioned implementations of the apparatus or method, wherein after non-AP stations receive a broadcast TXOP sharing response trigger from an AP, the non-AP stations access the shared TXOP based on the announced allocation schedule with their RU allocations after the corresponding data delay indicated in the received trigger frame.

[0536] Any of the foregoing implementations of the apparatus or method, wherein in each BSS, the AP identifies the shared TXOP participant STAs by exchanging MU-RTS shared frames and CTS shared frames. In the shared TXOP participant BSS, the shared TXOP initialization phase is started by receiving an OBSS TXOP participant station frame from the AP in the shared TXOP holder BSS without specifying the shared TXOP participant STA, and the shared TXOP initialization phase is completed by sending back an OBSS TXOP participant station frame to the AP in the shared TXOP holder BSS (when all shared TXOP participant stations are specified).

[0537] Any preceding implementation of the apparatus or method, wherein in order to avoid interference between overlapping BSSs, frames may be sent simultaneously in different BSSs but on different frequency bands, or frames may be sent on the same frequency band but with a time shift.

[0538] Any of the aforementioned implementations of the apparatus or method, wherein the shared TXOP access method on different frequency bands includes: scheduling based on random access and dedicated triggering (basic triggering).

[0539] The apparatus or method of any preceding implementation, wherein the shared TXOP access method utilizing time shifting includes scheduling based on: basic triggering, unicast TXOP access request triggering (without AP as coordinator), and broadcast TXOP access request triggering (without AP as coordinator).

[0540] The apparatus or method of any preceding implementation, wherein time shift information between a shared TXOP holder BSS and a shared TXOP participant BSS is exchanged via an OBSS sharing trigger frame.

[0541] The apparatus or method of any preceding implementation, wherein when a trigger frame is received from the AP, other non-AP TXOP sharing participant STAs access the channel according to access information indicated in the trigger frame.

[0542] Any of the aforementioned implementations of the described apparatus or method, wherein the non-AP station can determine other non-AP STAs from the same BSS or from the OSSS accessing the TXOP of the non-AP station and the RU allocation and access order in a semi-static manner by exchanging messages under the coordination of the AP in a single BSS / OBSS scenario.

[0543] The apparatus or method of any preceding implementation, wherein the non-AP STA runs a setup procedure to set a semi-static configuration.

[0544] Any of the aforementioned implementations of the apparatus or method, wherein non-AP STAs exchange sharing proposal / request frames with each other through coordination of an AP in each BSS; wherein the AP further forwards the shareability information to another AP of the OBSS, and the other AP broadcasts the received shareability information.

[0545] Any of the aforementioned implementations of the apparatus or method, wherein the non-AP STAs exchange configurations of semi-static TXOP shared scheduling with each other through coordination of the AP in each BSS. The AP further forwards the shared TXOP access scheduler to another AP of the OBSS; wherein the other AP broadcasts the received shared TXOP access scheduler in the OBSS.

[0546] Any of the above implementations of the apparatus or method, wherein in order to avoid interference between different BSSs, different frequency band scheduling methods or time shift methods are used in shared TXOP access. The non-AP STA uses the configured RU to access the shared TXOP.

[0547]

[0066] The apparatus or method of any preceding implementation, wherein a non-AP STA that shares its TXOP with other non-AP STAs from the same BSS / OBSS follows the advertised allocation schedule.

[0548] The apparatus or method of any preceding implementation, wherein to initiate shared TXOP access, a non-AP TXOP holder STA unicasts a TXOP sharing request trigger, wherein in response, the AP broadcasts a TXOP sharing response trigger with a time shift or different frequency band scheduling to avoid OBSS interference.

[0549] The apparatus or method of any preceding implementation, wherein the time shift information between the shared TXOP holder BSS and the shared TXOP participant BSS is exchanged via an OBSS sharing trigger frame.

[0550] The apparatus or method of any preceding implementation, wherein once non-AP STAs receive a broadcast TXOP sharing response trigger from the AP, they access the channel based on the announced RU allocation after a corresponding data delay indicated in the received trigger frame.

[0551] 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.

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

[0553] Phrasing structures 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. Phrasing structures such as "at least one of" preceding a list of a group of elements indicate that at least one of the group of elements is present, which includes any possible combination of the listed elements as applicable.

[0554] 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 embodiments described. The embodiment language should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

[0555] 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.

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

[0557] The terms "comprising", "having", "including", "containing" or any variation 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 these elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprising...", "having...", "including...", "containing..." 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 the element.

[0558] 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 conjunction with an event or circumstance, these terms may refer to instances in which the event or circumstance occurs precisely, as well as instances in which the event or circumstance occurs approximately. When used in conjunction 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" alignment may refer to an angular variation range 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°.

[0559] In addition, quantities, ratios and other 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 values ​​that are explicitly specified as the limits of the range, and also include all individual values ​​or sub-ranges contained within the range, as if each value and sub-range 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 sub-ranges such as about 10 to about 50, about 20 to about 100.

[0560] As used herein, the term "coupled" is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0561] 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.

[0562] In addition, in the above disclosure, in order to simplify the present disclosure, various features may be grouped together in various embodiments. This disclosure method should not be interpreted as reflecting the intention that the claimed embodiments require more features than the features explicitly listed in each claim. The subject matter of the invention may lie in fewer features than all the features of a single disclosed embodiment.

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

[0564] 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 the disclosure, the reader should consult the application submitted. Any deletion of the content of the disclosure should not be interpreted as an abandonment, loss or dedication to the public of any theme of the application originally submitted.

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

[0566] 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 of the currently 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.

[0567] All structural equivalents and functional equivalents of the various elements of the disclosed embodiments known to those of ordinary skill in the art are expressly incorporated herein by reference and are included in the claims. In addition, the elements, components, or method steps in the present disclosure are not intended to be dedicated to the public, regardless of whether the elements, components, or method steps are explicitly recorded in the claims. The claim elements herein should not be interpreted as "means + function" elements unless the elements are explicitly recorded using the phrase "means for...". The claim elements herein should not be interpreted as "step + function" elements unless the elements are explicitly recorded using the phrase "step for...".

Claims

1. A device for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a first station for wireless communication over at least one channel with at least one other station in the same or another basic service set (BSS) or from an overlapping basic service set (OBSS), wherein the first station is a non-access point (AP) station and the other station is a non-AP 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) with other stations in the OBSS in the frequency domain by performing steps comprising: (i) exchanging sharing proposal and request messages with access point (AP) stations to inform the AP and / or obtain approval from the AP to share its TXOP with other non-AP stations of the shared TXOP holder BSS; (ii) wherein the sharing proposal and request information is shared with the AP of the overlapping BSS that is a BSS of the shared TXOP participant; (iii) upon obtaining access to the at least one channel, exchanging information with other stations to indicate that an upcoming TXOP is available for sharing, and identifying stations willing to join the upcoming shared TXOP; (iv) wherein the AP of the shared TXOP participant BSS identifies the shared TXOP participant STA; and (v) Enable non-AP TXOP holder stations to distribute resource units (RUs) for shared TXOP participant stations in a TXOP holder BSS, while in a shared TXOP participant BSS, scheduling and distribution of RUs for shared TXOP participant stations are determined at the AP level.

2. The apparatus of claim 1, wherein an OBSS TXOP participant station frame is used to synchronize sharing operations between different BSSs.

3. The apparatus according to claim 1, wherein different frequency bands are used or time shift is performed to avoid interference between different BSSs.

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

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

6. The apparatus according to claim 1, wherein APs of different BSSs exchange information about TXOP sharing proposal / request information through exchange of OBSS shared station frames.

7. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising: The shared TXOP holder station or the AP in each BSS identifies the shared TXOP participant stations by exchanging a Multi-User Request to Send (MU-RTS) sharing frame and a Clear to Send (CTS) sharing frame.

8. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising: In a shared TXOP participant BSS, the shared TXOP initialization phase is started by receiving an OBSS TXOP participant station frame from an AP in a shared TXOP holder BSS without specifying a shared TXOP participant STA, and the shared TXOP initialization phase is completed by sending back an OBSS TXOP participant station frame to the AP in the shared TXOP holder BSS with all shared TXOP participant stations specified.

9. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising: Interference between overlapping BSSs due to shared TXOP access is avoided by sending frames simultaneously in different BSSs but on different frequency bands, or sending frames on the same frequency band but time-shifted.

10. The apparatus of claim 9, wherein the shared TXOP access on different frequency bands comprises: Scheduling based on random access and dedicated triggering is performed, and the dedicated triggering includes a basic trigger.

11. The apparatus of claim 9, wherein the shared TXOP access using time shifting comprises scheduling based on: a basic trigger, a unicast TXOP access request trigger with or without an AP as a coordinator, and a broadcast TXOP access request trigger that can be performed with or without an AP as a coordinator.

12. The apparatus of claim 9, wherein the time shift information between the shared TXOP holder BSS and the shared TXOP participant BSS is exchanged by using an OBSS sharing trigger frame.

13. The apparatus according to claim 1, wherein when a trigger frame is received from an AP, the non-AP TXOP sharing participant station accesses the at least one channel according to access information indicated in the trigger frame.

14. The apparatus of claim 1, wherein the non-AP stations determine both resource unit (RU) allocation and access order in a semi-static configuration for other non-AP stations from the same BSS and the OBSS accessing its TXOP by exchanging messages using AP coordination in a single BSS or OBSS scenario.

15. The apparatus according to claim 14, wherein the non-AP STA performs a setup procedure to set a semi-static configuration: (a) Non-AP stations exchange sharing proposal / request frames with each other through coordination by the AP in each BSS, and the AP further forwards the shareability information to another AP of the OBSS, after which the other AP broadcasts the received shareability information; (b) non-AP stations exchange configurations of semi-static TXOP shared scheduling with each other through coordination with an AP in each BSS, and the AP further forwards the shared TXOP access scheduler to another AP of the OBSS, after which the other AP broadcasts the received shared TXOP access scheduler in the OBSS; and (c) A scheduling method or a time shift method is performed to avoid interference between different BSSs using different frequency bands in TXOP sharing, wherein a non-AP station accesses a shared TXOP using a configured RU.

16. The apparatus of claim 15, wherein the allocation of resource unit (RU) distribution comprises: An allocation schedule for a shared TXOP access is announced by a non-AP TXOP holder station, wherein non-AP stations from the same BSS / OBSS sharing the TXOP follow the announced allocation schedule.

17. The apparatus of claim 16, wherein the shared TXOP access starts from a non-AP TXOP holder station unicasting a TXOP sharing request trigger, wherein in response to the TXOP sharing request trigger, the AP broadcasts a TXOP sharing response trigger with a time shift or a different frequency band scheduling to avoid OBSS interference.

18. The apparatus according to claim 17, wherein the response triggering with time shift is performed by exchanging time shift information between a shared TXOP holder BSS and a shared TXOP participant BSS in an OBSS shared trigger frame.

19. The apparatus of claim 16, wherein after non-AP stations receive a broadcast TXOP sharing response trigger from an AP, the non-AP stations access the shared TXOP based on the announced allocation schedule with their RU allocations after a corresponding data delay indicated in the received trigger frame.

20. A method for wireless communication in a network, comprising: (a) wirelessly communicating between a wireless communication circuit configured as a first station and at least one other station in the same or another basic service set (BSS) or from an overlapping basic service set (OBSS) over at least one channel to share a transmit opportunity (TXOP) with the other stations in the OBSS in a frequency domain, wherein the first station is a non-access point (AP) station and the other stations are non-AP stations; (b) exchanging sharing proposal and request messages with access point (AP) stations to inform the AP and / or obtain approval from the AP to share its TXOP with other non-AP stations of the shared TXOP holder BSS; (c) wherein the sharing proposal and request information is shared with an AP of an overlapping BSS that is a BSS of a TXOP participant being shared; (d) upon obtaining access to the at least one channel, exchanging information with other stations to indicate that an upcoming TXOP is available for sharing, and identifying stations willing to join the upcoming shared TXOP; (e) wherein the AP of the shared TXOP participant BSS identifies the shared TXOP participant STA; (f) enabling a non-AP TXOP holder station to distribute resource units (RUs) for a shared TXOP participant station in a TXOP holder BSS, while in a shared TXOP participant BSS, scheduling and distribution of RUs for the shared TXOP participant stations are determined at the AP level; and (g) wherein the method is performed by one or more processors executing instructions stored on a non-transitory medium.

Images