coordinated wifi stations with shared txop among dl and ul in time domain

Abstract

A wireless local area network (WLAN) protocol that allows a transmit opportunity (TXOP) holder (whether it is an AP or a non-AP STA) to share the TXOP with other stations (AP or non-AP STAs). The intent to share the TXOP is communicated by the TXOP holder directly or indirectly with the other STAs and / or APs, after which scheduling information (time and duration) is shared with the STAs and / or APs. When the TXOP occurs, the STAs and / or APs can access the channel at the specified time and for the specified duration, thereby increasing the use of the TXOP for increased efficiency.

Description

[0001] This application claims priority to U.S. Patent Application Serial No. 17 / 390,979, filed August 1, 2021, which is incorporated by reference herein in its entirety, which claims priority to U.S. Provisional Patent Application Serial No. 63 / 119,761, filed December 1, 2020, which is incorporated by reference herein in its entirety.

[0002] Statement Regarding Federally Sponsored Research and Development

[0003] Not Applicable

[0004] Incorporation by Reference of Computer Program Appendix

[0005] Not Applicable

[0006] Statement as to Copyright

[0007] A portion of the material in this patent document is subject to copyright protection under the copyright laws of the United States and other countries. The owner of the copyright rights has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner hereby TECHNICAL FIELD

[0008] The technology of this disclosure relates generally to wireless communication networks and more specifically to multi-user transmissions by a STA that obtains a transmit opportunity (TXOP) sharing the TXOP with other stations in a single basic service set (BSS). BACKGROUND

[0009] The use of Wi-Fi networks continues to grow at a very fast pace. This growth is driven by the rapid development of new types of applications and the ever-increasing number of smart devices on the market that need to access the Internet through a Wi-Fi network. As the number of Wi-Fi users grows and the demand increases, there is a significant push to enable increased throughput, lower latency, and higher efficiency.

[0010] Some applications, such as real-time gaming, are very sensitive to latency and thus have a higher requirement for low latency in order to provide a pleasant user experience, such as by supporting real-time interaction between different game players.

[0011] The contention for access to the channel between stations, including AP stations and non-AP stations, introduces contention delays when stations attempt to access the channel at the same time. Contention delays affect the performance of traffic that requires low latency to a large extent. Current 802.11ax technology initiates uplink (UL) and downlink (DL) multi-user (MU) transmissions at the AP level, meaning that for UL transmissions, a non-AP STA will send trigger-based (TB) UL data to the AP. Although this rule reduces contention from non-AP STAs, it can not fully utilize the communication channel in cases where a non-AP STA needs to send UL data and senses the channel to be idle (not busy) while the AP has not sent a trigger frame to the non-AP STA.

[0012] In this case, the present disclosure provides a mechanism in which stations, including AP stations and non-AP stations, can cooperate with each other. This means that if any station gains channel access and wins the TXOP, it can share a portion of its transmission opportunity (TXOP) with other stations. The cooperation scheme is configured to reduce contention between stations and, thus, contention delays.

[0013] Therefore, the approach utilized in current WLAN protocols fails to provide the beneficial level of performance that is increasingly demanded.

[0014] Thus, there is a need to improve the performance of WLAN communications, including shared TXOP transmissions. The present disclosure meets this need and provides additional benefits over the prior art. SUMMARY

[0015] In conventional 802.11 protocols, transmission opportunity (TXOP) scheduling is conducted at the AP level. Non-AP STAs that sense the channel to be idle in a conventional wireless LAN network cannot send data without receiving a trigger frame from the AP, thereby constraining channel utilization efficiency. In addition to this, the TXOP holder, which is the station that gains (wins) the TXOP, does not share a portion of its TXOP with other stations; therefore, each station must contend for the TXOP individually, even if it has only a small amount of data to send.

[0016] In this disclosure, stations including AP stations and non-AP stations cooperate with each other such that if any station gains channel access and wins a TXOP, it can share its transmit opportunity (TXOP) with other stations. This cooperation scheme helps to reduce contention among stations, thus reducing contention latency. Both non-AP STAs and AP STAs are allowed to do shared TXOP scheduling in time domain (time sharing TXOP with other cooperating stations willing to participate in this shared TXOP to transmit physical layer protocol data units (PPDUs) without channel contention). In this case, the TXOP holder STA that gains (preempts) channel access and knows the shared TXOP participant STAs information either through pre-configured sharing information or through collection of information of shared TXOP participants, can schedule TXOP sharing with other stations to improve channel utilization efficiency and achieve lower latency transmissions in wireless LAN networks.

[0017] In at least one embodiment of the disclosed technology, a non-AP TXOP holder STA is able to start the coordination process and share its TXOP with other STAs in the same BSS in time domain without waiting for a trigger frame from the AP. Various different scenarios are illustrated, including sharing TXOP with or without the AP as a coordinator, and use of semi-static TXOP sharing and simplified TXOP sharing.

[0018] In scenarios without AP coordination, a station that gains TXOP in a wireless LAN network is able to communicate with every other station in its BSS to share its TXOP with other stations in the same BSS by: (a) exchanging messages with the AP to inform and / or get permission to share its TXOP with other STAs; (b) when winning access to the channel, broadcasting a message to other STAs in the BSS to indicate that the upcoming TXOP is available for sharing; (c) exchanging messages with other STAs in the BSS to determine STAs that are requesting time in the open shared TXOP; (d) sending messages to STAs that will share the TXOP with this STA to inform them of the time and duration of channel access that will take place.

[0019] In an AP-coordinated scenario, a STA that gains TXOP in a wireless LAN network cannot communicate with all other stations in its BSS, and shares its TXOP with other stations in the same BSS by: (a) exchanging messages with the AP to inform and / or get permission to share its TXOP with other STAs; (b) unicasting messages to the AP, requesting the AP to broadcast messages to other STAs in the BSS to indicate that the upcoming TXOP is available for sharing; (c) letting the AP exchange messages with other STAs in the BSS and getting messages from the AP to determine the STAs that are requesting to share time in the TXOP; (d) unicasting messages to the AP, requesting the AP to send messages to the STAs that will share the TXOP with this STA to inform them of the time and duration of the channel access that will take place.

[0020] In semi-static TXOP sharing, the following operations occur in the first (TXOP sharing setup) phase. (a) Each non-AP STA sends sharing proposal / request information to the AP indicating the sharing or joining sharing TXOP capability of that non-AP STA. The AP then broadcasts this information to all stations. (b) Each station that can become a TXOP holder in the future configures a sharing TXOP schedule between itself and other stations and sends this configuration information to the AP.

[0021] After receiving this configuration information, the AP broadcasts this configuration information to all stations; then, in the second (TXOP sharing) phase, the following operations occur: (a) a Ready-To-Send-share (RTS share) and Clear-To-Send-share (CTS share) exchange occurs between the sharing STAs and the AP, announcing that the upcoming TXOP will be shared according to the agreed configuration; (b) once the other STAs of the sharing TXOP receive the RTS share or CTS share indicating that the TXOP will be shared and recognize that they are included in the sharing configuration, these STAs can determine when to access the channel; (c) the RTS share / CTS share messages used in this disclosure are modified RTS / CTS, with an added field containing information about the sharing TXOP; (d) different messages can be exchanged between the STA sharing its TXOP and the AP, so that other STAs can receive this message and obtain information about the TXOP sharing.

[0022] In a simplified TXOP sharing, the following operations occur. (a) Once a station gets channel access, it sends an RTS and receives a CTS, and then it can use the available TXOP time as it sees fit, subject only to the maximum TXOP duration. After completing a full transmission (sending a data PPDU and receiving an ACK / Block ACK), it sends a CTS-Reject to the AP to allow the AP to cycle through (sequentially) other stations to use the remaining time of the TXOP. (b) After receiving the CTS-Reject frame, if the current TXOP is not expired, the AP cycles through the next station by sending a CTS to the next station (non-AP STA). The AP also assigns a limited shared TXOP time to the next station; thus, when the AP is the next station to cycle through in the sequence, the AP can directly access the channel for transmission in the remaining limited shared TXOP time. (c) The non-AP STA that receives the CTS from the AP sends a SU PPDU to the AP in the limited shared TXOP time, and if: (i) the AP finishes transmitting earlier than the assigned shared TXOP limit time; (ii) the assigned shared TXOP limit time is about to expire and the AP has no SU PPDU to send, sends a CTS-Reject to the AP.

[0023] In the following sections of the specification, other aspects of the technology illustrated herein will be presented, where detailed explanations are used to fully disclose preferred embodiments of the technology, but not to limit it. BRIEF DESCRIPTION OF DRAWINGS

[0024] The technology illustrated herein will be more fully understood in view of the following drawings, in which:

[0025] FIG. 1 is a time-slotted transmission diagram of a MU data frame in a downlink (DL) orthogonal frequency division multiple access (OFDMA) multiple-in-multiple-out (MIMO) transmission.

[0026] FIG. 2 is a time-slotted transmission diagram of an uplink (UL) orthogonal frequency division multiple access (OFDMA) multiple-in-multiple-out (MIMO).

[0027] FIG. 3 is a flow diagram of a conventional retransmission scheme in CSMA / CA.

[0028] FIG. 4 is a data field diagram of a packet frame format for carrying data in a conventional WLAN system.

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

[0030] FIG. 6 is a communication sequence diagram of a double-sized contention window when retransmission is made in CSMA / CA.

[0031] Figure 7 is a communication sequence diagram of dropped packets due to retry limit in CSMA / CA.

[0032] Figure 8 is a communication sequence diagram of a conventional retransmission scheme in the downlink of an OFDMA system.

[0033] Figure 9 is a communication sequence diagram of a conventional retransmission scheme in the uplink of an OFDMA system.

[0034] Figure 10 Figure 10 is a communication sequence diagram of a semi-static scenario in time domain with or without AP as coordinator in accordance with at least one embodiment of the present disclosure.

[0035] Figures 11A-11C Figure 11 is a communication sequence diagram providing a deeper example of a semi-static scenario in time domain in accordance with at least one embodiment of the present disclosure.

[0036] Figure 12 Figure 12 is a hardware block diagram of a wireless station hardware in accordance with at least one embodiment of the present disclosure.

[0037] Figure 13 Figure 13 is a network topology diagram representing a single BSS scenario by way of example and not limitation, the BSS consisting of one AP and three STAs.

[0038] Figure 14 Figure 14 is a communication sequence diagram of a shared TXOP initiated by a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0039] Figure 15 Figure 15 is a communication sequence / protocol diagram of an overview of the general steps taken by the TXOP sharing protocol in accordance with at least one embodiment of the present disclosure.

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

[0041] Figure 17 Figure 17 is a flow diagram of the shared TXOP setup phase at the AP level in accordance with at least one embodiment of the present disclosure.

[0042] Figures 18A-18B Figure 18 is a flow diagram of the shared TXOP setup phase at the non-AP STA level in accordance with at least one embodiment of the present disclosure.

[0043] Figure 19 Figure 19 is a communication sequence diagram of the shared TXOP announcement phase in accordance with at least one embodiment of the present disclosure.

[0044] Figure 20is a flow diagram of UL initiated TXOP participant acquisition by an AP, showing responses after receiving a TXOP proposal.

[0045] Figure 21 is a flow diagram of UL initiated TXOP participant acquisition phase by a non-AP TXOP holder STA, showing responses after receiving a CTS.

[0046] Figure 22 is a communication sequence diagram of UL initiated TXOP participant acquisition phase by a non-AP TXOP holder STA, showing responses after receiving a dedicated TXOP proposal frame.

[0047] Figure 23 is a flow diagram of UL initiated TXOP participant acquisition phase at a non-AP TXOP holder STA processing, in accordance with at least one embodiment of the present disclosure.

[0048] Figure 24 is a flow diagram of UL initiated TXOP participant acquisition phase at an AP processing, in accordance with at least one embodiment of the present disclosure.

[0049] Figure 25 is a flow diagram of UL initiated TXOP participant acquisition phase at a non-AP shared TXOP participant STA processing, in accordance with at least one embodiment of the present disclosure.

[0050] Figure 26 is a communication sequence diagram of UL initiated TXOP scheduling and access with unicast TXOP proposal frame, in accordance with at least one embodiment of the present disclosure.

[0051] Figure 27 is a communication sequence diagram of UL initiated TXOP scheduling and access with unicast TXOP access scheduler, in accordance with at least one embodiment of the present disclosure.

[0052] Figure 28 is a communication sequence diagram of UL initiated TXOP scheduling and access with broadcast TXOP scheduler, in accordance with at least one embodiment of the present disclosure.

[0053] Figures 29A-29B is a flow diagram of UL initiated TXOP scheduling and access phase at a non-AP TXOP holder STA level processing, in accordance with at least one embodiment of the present disclosure.

[0054] Figures 30A-30B is a flow diagram of UL initiated TXOP scheduling and access phase at a non-AP shared TXOP participant STA level processing, in accordance with at least one embodiment of the present disclosure.

[0055] Figures 31A-31B is a flow diagram of an UL initiated TXOP scheduling and access phase handled at the AP level in accordance with at least one embodiment of the present disclosure.

[0056] Figure 32 is a communication sequence diagram of a DL initiated shared TXOP announcement phase in accordance with at least one embodiment of the present disclosure.

[0057] Figure 33 is a flow diagram of a shared TXOP announcement phase handled at the AP in accordance with at least one embodiment of the present disclosure.

[0058] Figure 34 is a flow diagram of a shared TXOP announcement phase handled at the non-AP STA level in accordance with at least one embodiment of the present disclosure.

[0059] Figure 35 is a communication sequence diagram of an UL initiated TXOP participant acquisition phase (with AP) with response after receiving a TXOP proposal in accordance with at least one embodiment of the present disclosure.

[0060] Figure 36 is a communication sequence diagram of a DL initiated TXOP participant acquisition phase with response after receiving a TXOP proposal in accordance with at least one embodiment of the present disclosure.

[0061] Figure 37 is a communication sequence diagram of an UL initiated TXOP participant acquisition phase (with AP) with response after receiving a CTS in accordance with at least one embodiment of the present disclosure.

[0062] Figure 38 is a communication sequence diagram of a DL initiated TXOP participant acquisition phase with response after receiving a CTS in accordance with at least one embodiment of the present disclosure.

[0063] Figure 39 is a communication sequence diagram of an UL initiated TXOP participant acquisition phase (with AP) with response after receiving a dedicated TXOP proposal in accordance with at least one embodiment of the present disclosure.

[0064] Figure 40 is a communication sequence diagram of a DL initiated TXOP participant acquisition phase with response after receiving a dedicated TXOP proposal in accordance with at least one embodiment of the present disclosure.

[0065] Figure 41 is a flow diagram of an UL initiated TXOP participant acquisition phase handled at the AP level in accordance with at least one embodiment of the present disclosure.

[0066] Figure 42is a flowchart of an UL initiated TXOP participant acquisition phase handled at the non-AP shared TXOP participant STA level according to at least one embodiment of the present disclosure.

[0067] Figure 43 is a flowchart of a DL initiated TXOP participant acquisition phase handled at the AP level according to at least one embodiment of the present disclosure.

[0068] Figure 44 is a communication sequence diagram of an UL initiated TXOP scheduling and access phase with AP coordination using unicast TXOP proposal frames according to at least one embodiment of the present disclosure.

[0069] Figure 45 is a communication sequence diagram of a DL initiated TXOP scheduling and access using unicast TXOP proposal frames according to at least one embodiment of the present disclosure.

[0070] Figure 46 is a communication sequence diagram of an UL initiated TXOP scheduling and access phase with AP coordination using unicast TXOP access scheduler frames according to at least one embodiment of the present disclosure.

[0071] Figure 47 is a communication sequence diagram of a DL initiated TXOP scheduling and access using unicast TXOP access scheduler frames according to at least one embodiment of the present disclosure.

[0072] Figure 48 is a communication sequence diagram of an UL initiated TXOP scheduling and access phase with AP coordination using broadcast TXOP scheduler frames according to at least one embodiment of the present disclosure.

[0073] Figure 49 is a communication sequence diagram of a DL initiated TXOP scheduling and access using broadcast TXOP scheduler frames according to at least one embodiment of the present disclosure.

[0074] Figures 50A-50B is a flowchart of an UL initiated TXOP scheduling and access phase handled at the non-AP TXOP holder STA level with AP coordination according to at least one embodiment of the present disclosure.

[0075] Figures 51A-51C is a flowchart of an UL initiated TXOP scheduling and access phase handled at the AP level with AP coordination according to at least one embodiment of the present disclosure.

[0076] Figures 52A-52Bis a flow diagram of UL initiated TXOP scheduling and access phase processing at a non-AP shared TXOP participant STA with AP coordination in accordance with at least one embodiment of the present disclosure.

[0077] Figures 53A-53B is a flow diagram of DL initiated TXOP scheduling and access phase processing at an AP level in accordance with at least one embodiment of the present disclosure.

[0078] Figure 54 is a communication sequence diagram of a semi-static TXOP sharing setup phase in accordance with at least one embodiment of the present disclosure.

[0079] Figure 55 is a communication sequence diagram of an UL initiated semi-static TXOP sharing phase in accordance with at least one embodiment of the present disclosure.

[0080] Figure 56 is a communication sequence diagram of a DL initiated semi-static TXOP sharing phase in accordance with at least one embodiment of the present disclosure.

[0081] Figures 57A-57B is a communication sequence diagram of an UL initiated simplified TXOP sharing scheme in accordance with at least one embodiment of the present disclosure.

[0082] Figure 58 is a flow diagram of simplified shared TXOP scheduling processing at a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0083] Figure 59 is a flow diagram of simplified shared TXOP scheduling processing at a non-AP TXOP holder STA in accordance with at least one embodiment of the present disclosure.

[0084] Figures 60A-60C is a flow diagram of simplified shared TXOP scheduling processing at an AP in accordance with at least one embodiment of the present disclosure.

[0085] Figures 61A-61B is a communication sequence diagram of a DL initiated simplified TXOP sharing scheme in accordance with at least one embodiment of the present disclosure.

[0086] Figures 62A-62C is a flow of simplified TXOP scheduling processing at an AP in accordance with at least one embodiment of the present disclosure.

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

[0088] Figure 64is a data field diagram of a STA information field format in accordance with at least one embodiment of the present disclosure.

[0089] Figure 65 is a data field diagram of an access request information element format in accordance with at least one embodiment of the present disclosure.

[0090] Figure 66 is a data field diagram of an allocation control subfield in accordance with at least one embodiment of the present disclosure.

[0091] Figure 67 is a data field diagram of an allocation control subfield format in accordance with at least one embodiment of the present disclosure.

[0092] Figure 68 is a data field diagram of a share proposal / request frame format in accordance with at least one embodiment of the present disclosure.

[0093] Figure 69 is a data field diagram of a STA share proposal / request information field format in accordance with at least one embodiment of the present disclosure.

[0094] Figure 70 is a data field diagram of an RTS share frame in accordance with at least one embodiment of the present disclosure.

[0095] Figure 71 is a data field diagram of a CTS share frame in accordance with at least one embodiment of the present disclosure.

[0096] Figure 72 is a data field diagram of a TXOP proposal frame format in accordance with at least one embodiment of the present disclosure.

[0097] Figure 73 is a data field diagram of an access request frame format in accordance with at least one embodiment of the present disclosure.

[0098] Figure 74 is a data field diagram of an access priority subfield format in accordance with at least one embodiment of the present disclosure.

[0099] Figure 75 is a data field diagram of a TXOP access scheduler frame format in accordance with at least one embodiment of the present disclosure.

[0100] Figure 76 is a data field diagram of a TXOP access allocation information subfield format in accordance with at least one embodiment of the present disclosure.

[0101] Figure 77 is a data field diagram of a broadcast TXOP schedule frame format in accordance with at least one embodiment of the present disclosure.

[0102] Figure 78is a data field diagram of a STA TXOP Schedule field format in accordance with at least one embodiment of the present disclosure.

[0103] Figure 79 is a data field diagram of an Allocation Control subfield format in accordance with at least one embodiment of the present disclosure.

[0104] Figure 80 is a data field diagram of a Shared TXOP Participants Advertisement frame format in accordance with at least one embodiment of the present disclosure.

[0105] Figure 81 is a data field diagram of a STA TXOP Participants field format in accordance with at least one embodiment of the present disclosure.

[0106] Figure 82 is a data field diagram of a Request TXOP Proposal frame format in accordance with at least one embodiment of the present disclosure.

[0107] Figure 83 is a data field diagram of a Request TXOP Access Scheduler frame format in accordance with at least one embodiment of the present disclosure.

[0108] Figure 84 is a data field diagram of a STA TXOP Access Request field format in accordance with at least one embodiment of the present disclosure.

[0109] Figure 85 is a data field diagram of an Allocation Control subfield format in accordance with at least one embodiment of the present disclosure.

[0110] Figure 86 is a data field diagram of a Shared Proposal / Request frame format in accordance with at least one embodiment of the present disclosure.

[0111] Figure 87 is a data field diagram of a Shared Proposal / Request Information field format in accordance with at least one embodiment of the present disclosure.

[0112] Figure 88 is a data field diagram of a Shared Proposal / Request frame format in accordance with at least one embodiment of the present disclosure.

[0113] Figure 89 is a data field diagram of a STA Shared Proposal / Request Information field format in accordance with at least one embodiment of the present disclosure.

[0114] Figure 90 is a data field diagram of a Shared Configuration frame format in accordance with at least one embodiment of the present disclosure.

[0115] Figure 91 is a data field diagram of a STA TXOP Access Allocation field format in accordance with at least one embodiment of the present disclosure.

[0116] Figure 92 Figure is a data field diagram of an allocation control subfield, in accordance with at least one embodiment of the present disclosure.

[0117] Figure 93 Figure is a data field diagram of a shared configuration frame format, in accordance with at least one embodiment of the present disclosure.

[0118] Figure 94 Figure is a data field diagram of a STA configuration field format, in accordance with at least one embodiment of the present disclosure.

[0119] Figure 95 Figure is a data field diagram of a CTS frame for CTS denial, CTS-to-self, and CTS, in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION

[0120] 1. INTRODUCTION

[0121] To improve the performance of 802.11 WLANs, many protocol amendments have been proposed, very specifically targeting systems that communicate on the 2.4 GHz and 5 GHz bands. Most of these techniques are aimed at increasing the data rate from the physical (PHY) layer perspective, such as increasing the bandwidth from 20 MHz to 160 MHz, proposing new modulation and coding schemes, and improving MIMO system operation.

[0122] Other MAC layer improvements have been introduced to reduce the overhead of transmissions, thereby increasing the data throughput. This can be achieved by reducing the interframe spacing, aggregating and segmenting packets, and applying power save protocols to alternate between the awake state and the doze (sleep) state of the STA to save power at the STA.

[0123] IEEE 802.11ax introduced the orthogonal frequency division multiple access (OFDMA) technique, in which adjacent subcarriers are grouped into resource units (RUs). This technique maximizes the transmission rate by assigning RUs for multi-user (MU) uplink (UL) and downlink (DL) data transmissions.

[0124] Orthogonal frequency division multiple access (OFDMA) allows multiple users to use the same time resources simultaneously and divides the frequency domain among multiple users. This results in an improved use of channel resources and allows to reduce the latency, as more users can be scheduled simultaneously.

[0125] 2.1. WLAN features that impact latency

[0126] 2.1.1. Channel access and latency tolerance

[0127] Both contention-based access and contention-free access are allowed in WLAN devices. Contention-based access requires a device to sense the channel and contend for the channel if it is busy in order to gain access to the channel. This mechanism introduces additional transmission latency necessary to provide collision avoidance. Contention-free channel access allows an AP to gain access to the channel without contending. This is allowed in hybrid control channel access, where channel access coordination is achieved by using a shorter interframe space equal to PIFs (PCF Interframe Space) compared to DIFS (Distributed Interframe Space) used by other STAs. Although contention-free access seems to be a good solution to avoid contention delay, it is not widely deployed and most Wi-Fi devices are using contention-based access.

[0128] For a STA to access the channel, it needs to sense the channel and find that it is not busy before gaining and utilizing the channel. The channel is considered busy when: (a) the STA detects a preamble of a frame, where the channel is considered busy for the length of the detected frame; (b) the STA detects in-band energy greater than the minimum sensitivity of 20 dB; or (c) the STA detects that the channel is actually busy by reading the NAV of the detected frame.

[0129] 802.11ax introduces two NAVs to avoid collisions that can occur due to erroneously resetting the NAV timer. It is to be appreciated that one network allocation vector (NAV) is used for BSS STAs, while the other NAV is used for non-BSS STAs. The STAs maintain these two NAVs separately.

[0130] 802.11ax uses carrier sense multiple access / collision avoidance for channel access for all legacy 802.11 WLAN devices. Thus, for an AP to transmit a trigger frame for uplink multiple-input multiple-output (UL MIMO) transmission, it still needs to contend for channel access. To enable the AP to win (gain) channel access in preference to any STA within its BSS, 802.11ax introduces a second set of enhanced distributed channel access (EDCA) for 802.11ax devices only, which allows legacy non-802.11ax devices to freely access the channel with EDCA and increases the chances for the AP to gain access to the channel in order to schedule uplink (UL) or downlink (DL) OFDMA MIMO data transmissions.

[0131] 2.1.2 Multi-user transmission and reception

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

[0133] MIMO allows for multi-stream transmission to one or more users through up to 8 streams, for example in SU-MIMO DL in 802.11ac, or multi-user transmission to more than one user through MU-MIMO DL transmission as defined in 802.11ac. This allows the AP to assign one or more streams to STAs within its BSS.

[0134] As data transmission using wide channels of up to 160MHz is used, the channel is expected to be interference frequency selective, with some frequencies experiencing different interference levels than others. This affects the expected achievable rate and reduces 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 noise ratio (SINR) for each receiver, allowing a higher modulation and coding scheme (MCS) to be selected, thus increasing the achieved throughput.

[0135] OFDMA allows multiple users to use the same time resources simultaneously and divides the frequency domain among multiple users. The result is improved utilization of resources, and allows for reduced latency as more users can be scheduled simultaneously. This also allows STAs that need to transmit small amounts of data to occupy a narrow RU, making the scheduling very efficient, and providing improved resource allocation among applications that need to access the channel, while reducing channel access time and overhead of frame headers and preambles.

[0136] OFDMA can be more efficient when combined with MIMO transmission. Depending on the MIMO capacity of the STAs, RUs can be used to transmit multiple spatial streams to the STAs. In addition, one RU can be assigned to more than one STA to be shared, with each STA having one or more spatial streams depending on the MIMO capacity of the STA. Encapsulating more STAs in the same resource also helps to improve latency for both the STAs and the AP.

[0137] Figure 1 represents an example 10 of DL OFDMA MIMO transmission. The AP is sending a PHY preamble to all STAs in order to specify the frequency / RU mapping and the RU assignment for the STAs. After the preamble, the AP is sending DL data to a specific STA (e.g. STA 1 - STA 6) using the RU assignment for that STA. The multi-user ACK transmission should be synchronized with the reception of the DL data frame, where the STAs start the transmission of the SIFS after the reception of the DL trigger frame.

[0138] Figure 2 represents an example 30 of UL OFDMA MIMO transmission. The AP is sending a trigger frame to all STAs containing the frequency and / or RU mapping and the RU assignment for the STAs. The UL MIMO transmission is preferably synchronized with the reception of the trigger frame, where the STAs start the transmission with the SIFS after the reception of the DL trigger frame

[0139] 2.1.3. Retransmission

[0140] Figure 3 illustrates a retransmission scheme 50 in CSMA / CA. WLAN systems of IEEE 802.11 use CSMA / CA to allow STAs to access the channel for packet transmission and retransmission. In a CSMA / CA system, before each transmission and retransmission, a STA needs to sense the channel status and set a backoff time to contend for channel access if the channel seems not busy. The backoff time is determined by a uniform random variable between 0 and the contention window size. After the STA waits for the backoff time and senses that the channel is idle, the STA transmits the packet. If the STA does not receive an ACK before the timeout, a retransmission is needed. Otherwise, the transmission is successful.

[0141] When a retransmission is needed, the STA checks the number of retransmissions of the packet. If the number of retransmissions exceeds the retry limit, the packet is discarded and no retransmission is scheduled. Otherwise, a retransmission is scheduled. If a retransmission is scheduled, another backoff time is needed to contend for channel access for the retransmission. If the size of the contention window does not reach its 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 for the retransmission, and so on.

[0142] Figure 4 illustrates a data frame format 90 in a conventional WLAN system. The frame control field indicates the type of the frame. The duration field contains the NAV information for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that transmits the frame. The sequence control field contains the fragment number and the sequence number of the packet. The data field is shown for passing the data to be transmitted. In this and many other data formats explained in this disclosure, a Frame Check Sequence (FCS) can be seen, which provides an error detection code added to the frame in the communication protocol.

[0143] Figure 5 illustrates an ACK frame format 110 in a conventional WLAN system. 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 address of the recipient of the frame. The frame check sequence (FCS) can be seen in this and many other data formats illustrated in this disclosure, and provides an error detection code added to the frame in the communication protocol.

[0144] Figure 6 illustrates a double size contention window 150 utilized in an example of retransmission under CSMA / CA, where the backoff time is increased for each retransmission. The data packet frame and ACK frame use the formats shown in Figures 4 and 5, respectively. After the initial transmission of the packet by the sender, it does not receive an ACK before the timeout. It then sets another backoff time, so the size of the contention window is "n" slots. After waiting for this backoff time, the sender STA retransmits the packet for the first time. However, the retransmission also fails. The sender STA needs to retransmit the packet, so it sets the backoff time again to contend for channel access. This time, the size of the contention window is doubled, i.e., 2*n slots, due to the retransmission. The expected backoff time is also doubled in accordance with the contention window size. The second retransmission is successful because it receives an ACK before the timeout.

[0145] Figure 7 depicts an example 190 of a packet being discarded due to exceeding the retry limit in CSMA / CA. The data packet frame and ACK frame use the formats shown in Figures 4 and 5, respectively. As shown, after the initial transmission of the packet fails, the sender STA retransmits the packet multiple times. However, none of the retransmissions is successful. After retransmitting N times, the number of retransmissions exceeds the retry limit. The sender STA stops retransmitting the packet, and the packet is discarded.

[0146] Figure 8 depicts a conventional retransmission scheme 210 representing an example of downlink multi-user (DL MU) transmission using OFDMA. The sender AP transmits a data packet to its receivers 1, 2, 3, and 4. The data packet can use the HE MU PPDU format. After completing the initial transmission, the AP sends a multi-user block ACK request (MU-BAR) to all receivers. Then, the receivers send back a block ACK (BA) to the AP. According to the contents in the BA, the AP decides to retransmit the packet to receivers 1, 3, and 4. It contends for the channel and waits for a backoff time, where the first retransmission occurs after the AP gets channel access.

[0147] Figure 9 depicts a legacy retransmission scheme 250 representing an example of uplink multi-user (UL MU) transmission using OFDMA. The AP first sends a trigger frame to all transmitters 1, 2, 3, and 4. The transmitters receive the trigger frame and start the initial transmission using the channel resources allocated by the trigger frame. The data packets can use the high efficiency (HE) trigger-based (TB) PPDU format. Note that PPDU is a physical layer conformance procedure (PLCP) protocol data unit (PPDU). The AP receives the data packets from the transmitters and sends a BA frame to report the correctness of the transmission. In this example, only the packet from transmitter 3 is correctly received, retransmission needs to be scheduled for transmitters 1, 2, and 4. The AP contends for the channel and waits for the backoff time to gain channel access, after which the retransmission is made in the same way as the initial transmission.

[0148] 3. Problem Statement

[0149] For MU UL transmission, previous technologies such as 802.11n / ac implement request to send / clear to send (RTS / CTS) or an extension of RTS / CTS with a channel access scheme to help avoid collision. However, this scheme only allows one user to occupy the channel at a time. In addition, there is a problem of long latency introduced by the overhead of RTS / CTS frame exchange.

[0150] As a comparison, 802.11ax technology implements an OFDMA scheme, which allows different users to access the channel simultaneously by utilizing different resource units (RUs). This improves channel utilization efficiency and reduces average latency. However, the current 802.11ax technology relies on the AP to initiate UL transmission for a shared TXOP. This means that if a non-AP STA senses that the channel is ideal (unoccupied) and the STA has data to send to the AP, it needs to wait until it receives a trigger frame from the associated AP to join the shared TXOP for UL data transmission. In addition, the STA has to rely on the AP to schedule and allocate available channel resources among the non-AP STA that preempts (gains) the channel and other non-AP STAs. In this case, the protocol does not capture the dynamic demand from the non-AP STAs, and it introduces several problems, including low channel utilization efficiency, thus increasing latency.

[0151] Furthermore, the TXOP obtained from one TXOP holder cannot be shared among several cooperating stations. In this case, each station needs to contend for the TXOP for itself.

[0152] In the inventors’ previous disclosure, a non-AP STA can spontaneously share the TXOP with other non-AP STAs, meaning that the TXOP holder STA can schedule and allocate channel access slots to the shared TXOP participant STAs; however, this sharing scheme is implemented only for UL transmission.

[0153] 4. Contributions of the invention

[0154] The present disclosure provides a solution that enables multi-user UL and DL transmissions within a time domain in a single BSS by sharing TXOP, which can be initiated by either UL or DL transmission. In the present disclosure, a STA shares its TXOP with other STAs in the BSS within a time domain. Once any STA gains access, it shares its TXOP with other STAs, which can advantageously reduce channel contention and channel access latency. The STA does not necessarily need to wait for the AP to allow access to the channel through trigger-based (TB) access.

[0155] The present disclosure provides three different TXOP sharing scenarios, including dynamic shared TXOP, semi-static shared TXOP, and simplified shared TXOP. In the dynamic shared TXOP, the TXOP holder station, once it gains channel access, collects current shared TXOP participant information with or without coordination from the AP. The TXOP holder schedules the shared TXOP and assigns channel access time and access duration based on the collected information.

[0156] In the semi-static shared TXOP scenario, the shared TXOP is configured to be used among all the cooperating stations sharing this TXOP with a pre-configured scheduling and access time allocation. Thus, once the TXOP holder gains channel access, it broadcasts a signal to indicate the start of the shared TXOP. Other stations receiving this signal access the channel in the shared TXOP based on the pre-configured sharing schedule.

[0157] In the simplified shared TXOP scenario, there is neither pre-configured scheduling nor timely scheduling for the shared TXOP. The TXOP holder gains channel access and uses the TXOP as needed. If the TXOP holder does not use up the TXOP, it allows the AP to cycle through other stations to share the remaining part of the TXOP, while indicating to each shared station a limit of sharing time. In this case, the AP just cycles through each station one by one without knowing whether the station is willing to participate in the shared TXOP.

[0158] 4.1. Dynamic scenario of shared TXOP

[0159] A brief overview of the dynamic scenario shared TXOP protocol is provided below, showing four phases, including (a) shared TXOP setup phase, (b) shared TXOP announcement phase, (c) TXOP participant acquisition phase, and (d) TXOP scheduling and access phase.

[0160] In the shared TXOP setup phase, stations (non-AP STAs and AP STAs) exchange their TXOP shareability information through the coordination of the AP. The shareability information indicates the station's capability to share or join a shared TXOP, which can be embedded in the authentication request / response frames, association request / response frames, or any other frames exchanged between non-AP STAs and APs.

[0161] In the shared TXOP announcement phase, the TXOP holder announces the start of a new shared TXOP after it successfully obtains (wins) channel access by sending a signal (e.g., RTS share) and receiving a corresponding feedback frame (e.g., CTS share).

[0162] In the TXOP participant acquisition phase, the TXOP holder acquires other stations to identify whether they will join the shared TXOP, which is handled with or without AP coordination.

[0163] In the TXOP scheduling and access phase, the shared TXOP holder schedules the shared TXOP between itself and other stations that will join the shared TXOP. The TXOP holder sends scheduling information with or without AP coordination. Each shared TXOP participant STA should access the channel in the assigned time slot for PPDU transmission.

[0164] 4.2. Semi-static scenario of shared TXOP

[0165] Figure 10 An example semi-static overview scenario 3 290 is illustrated, depicting interactions between an AP 12, a STA1 14, a STA2 16, and a STA3 18. Shown here in combination are phase 0 and phase 1 292, including both the shared proposal / request setup phase and the TXOP holder configuration setup phase. Phase 2 represents the TXOP sharing announcement phase, and phase 3 represents the TXOP sharing period.

[0166] A STA can set the configuration for TXOP sharing through a setup procedure (with a STA or with an AP) at a certain time, and whenever it obtains a TXOP in the channel, the STA shares the TXOP with a pre-set number of STAs for a pre-set duration.

[0167] In the example, multiple TXOPs 294, 304, and 314 can be seen, each TXOP representing a Stage 2 TXOP sharing announcement period 296, 306, and 316, each followed by a Stage 3 TXOP sharing period, TXOP portions 298, 308, and 318 that are taken up by TXOP holder STA3. As a result, repeated sharing of the TXOP held by STA3 is conducted, as shown by STA2 sharing 300, 310, and 320, STA1 sharing 302, 312, and 322, and AP sharing 303, 313, and 323.

[0168] Figures 11A-11C Example embodiments 330, 350, and 370 are illustrated, showing communications in accordance with the protocol for the four-stage semi-static scenario summarized previously in Figure 10 As in the previous examples, the interaction between AP 12, STA1 14, STA2 16, and STA3 18 is shown by way of example and not limitation.

[0169] In the example 330, a stage of sharing proposal / request setting can be seen, in which non-AP STAs exchange sharing proposal / request information with each other. In this example, STA1 sends a sharing proposal / request 332 to the AP, which acknowledges 334 the sharing proposal / request, and then the AP shares 336 the information with the other STAs. Similarly, it can be seen that STA3 sends a sharing proposal / request 338 to the AP, which acknowledges 340 the sharing proposal / request, and then the AP shares 342 the information with the other STAs. Figure 11A In the example 350, a stage of TXOP holder configuration setting can be seen, in which a potential TXOP holder STA exchanges configuration, semi-static TXOP sharing schedule with all STAs. In this example, STA2 sends TXOP holder configuration information 352 to the AP, which acknowledges (OK) 354 receipt of the information, and then the AP broadcasts a sharing configuration frame to indicate the latest TXOP access configuration 356 to the other STAs. Similarly, STA3 sends TXOP holder configuration information 358 to the AP, which acknowledges (OK) 360 receipt of the information, and then the AP broadcasts a sharing configuration frame 362 to the other STAs.

[0170] Figure 11B In the example 370, a stage of TXOP holder configuration setting can be seen, in which a potential TXOP holder STA exchanges configuration, semi-static TXOP sharing schedule with all STAs. In this example, STA2 sends TXOP holder configuration information 372 to the AP, which acknowledges (OK) 374 receipt of the information, and then the AP broadcasts a sharing configuration frame to indicate the latest TXOP access configuration 376 to the other STAs. Similarly, STA3 sends TXOP holder configuration information 378 to the AP, which acknowledges (OK) 380 receipt of the information, and then the AP broadcasts a sharing configuration frame 382 to the other STAs.

[0171] In the example 370, a stage of TXOP holder configuration setting can be seen, in which a potential TXOP holder STA exchanges configuration, semi-static TXOP sharing schedule with all STAs. In this example, STA2 sends TXOP holder configuration information 372 to the AP, which acknowledges (OK) 374 receipt of the information, and then the AP broadcasts a sharing configuration frame to indicate the latest TXOP access configuration 376 to the other STAs. Similarly, STA3 sends TXOP holder configuration information 378 to the AP, which acknowledges (OK) 380 receipt of the information, and then the AP broadcasts a sharing configuration frame 382 to the other STAs. Figure 11C ​In the TXOP sharing announcement and TXOP sharing phases 370 are illustrated embodiments. In the TXOP sharing announcement phase 372, the TXOP holder STA announces that the upcoming TXOP is allowed to be shared according to the agreed configuration. It can be seen that the TXOP holder (STA3) sends an RTS share 376 to the AP. The AP responds with a CTS share 376 to STA3, and STA1 and STA2 receive the CTS share and thus know the NAV set in the CTS share.

[0172] In the TXOP sharing period 374, each station (non-AP STA and AP STA) accesses the shared TXOP according to the agreed configuration. In response to the CTS share, the TXOP holder (STA3) uses its portion 378 in the shared TXOP interval, after which the other stations share the TXOP, e.g. STA1 and STA2 use their portions 380 and 382 of the TXOP, followed by the AP using portion 384; thus, all these STAs share the TXOP.

[0173] 5. Non-AP STA hardware setup

[0174] Figure 12 An example embodiment 390 of a non-AP STA hardware setup is illustrated, with external I / O 394 into a circuit 392, which has a CPU 398 for executing programs implementing communication protocols and a RAM 400. The host accommodates at least one modem supporting communication coupled to an RF module connected to a plurality of antennas for beamforming for transmission and reception. In this way, the STA can use multiple sets of beam patterns to transmit signals.

[0175] In particular, a WLAN station according to the present disclosure is shown, with I / O path 394 represented into a circuit block 392, which has a bus 396 connected to at least one computer processor (CPU) 398, memory (RAM) 400 and at least one modem 402. The bus 394 allows connecting various devices to the CPU, such as sensors, actuators, etc. Instructions from the memory 400 are executed on the processor 398 to execute programs implementing communication protocols, the execution of which allows the STA to function as an access point (AP) station or a regular station (STA). It should also be appreciated that the programming is configured to run in different modes (source, intermediary, destination, first AP, other AP, station associated with the first AP, station associated with the other AP, coordinator, coordinated, etc.) depending on the role it plays in the current communication context.

[0176] The host is represented as being configured with at least one modem and RF circuitry. By way of example and not limitation, mmW modem 402 is coupled to at least one radio frequency (RF) circuit 404, which is connected to a plurality of antennas 406a, 406b, 406c ~ 406n (e.g., an antenna array) to transmit and receive frames with neighboring STAs. The combination of processor, modem, and RF circuitry allows for support of beamforming (directional) communications, as well as support for quasi-omni (herein simply omni) mode transmissions from the antenna array. Additionally, in at least one preferred embodiment, a null can be created in the pattern of directivity created by the antenna array to shield selected directions (sectors) to reduce interference between stations.

[0177] Thus, the STA HW is represented as being configured with at least one modem and associated RF circuitry for providing communications over at least one frequency band. By way of example and not limitation, the intended frequency band for directional communications is implemented with a mmW modem and its associated RF circuitry for transmitting and receiving data in the mmW band. In some implementations, another frequency band (often referred to as a discovery band) can be supported in hardware, by way of example and not limitation, which can include a sub-6 GHz modem and its associated RF circuitry for transmitting and receiving data in the sub-6 GHz band.

[0178] It should be appreciated that the present disclosure can be configured with multiple modems 402, each coupled to any number of RF circuitry. Generally, using a larger number of RF circuitry will result in a wider coverage of the antenna beam direction. It should be appreciated that the number of RF circuitry used and the number of antennas is determined by the hardware constraints of the particular device. When the STA determines that it does not need to communicate with a neighboring STA, some of the RF circuitry and antennas can be disabled. In at least one embodiment, the RF circuitry includes frequency converters, array antenna controllers, etc., and is connected to a plurality of antennas that are controlled for beamforming for transmission and reception. In this way, the STA can use multiple sets of beam patterns to transmit signals, with each beam pattern direction being considered an antenna sector.

[0179] Additionally, it should be noted that multiple instances of the station hardware as shown can be combined into a multi-link device (MLD), which generally has a processor and memory for coordinating activities, however, each STA within the MLD does not always need a separate CPU and memory.

[0180] 6. Topology and Scenario Description

[0181] 6.1. Topology in the Study

[0182] Figure 13An example topology 410 illustrating a single Basic Service Set (BSS) scenario, which consists of one AP 12 and three STAs 14, 16 and 18 as represented by way of example and not limitation, as the present disclosure can support any topology resulting from a plurality of stations, which can include APs and non-AP STAs. Among them, the station that obtains channel access is the TXOP holder, which can be an AP or a non-AP STA. As shown in this example, the TXOP holder is a non-AP STA. The stations that join the shared TXOP and transmit using a portion of the TXOP are shared TXOP participants, and can include APs and / or non-AP STAs, which are represented as AP and non-AP shared TXOP participant STAs, respectively.

[0183] However, for the sake of understanding, only a few examples of interaction between stations are given here, each station being described in its specific role for the example; the non-AP STA that initiates the shared TXOP, STA3, is generally considered as a non-AP TXOP holder STA, the other two STAs are considered as non-AP shared TXOP participant STAs, while the AP can also join the shared TXOP and act as another shared TXOP participant STA. It should be noted that the holder STA obtains (preempt) the channel and is willing to share the TXOP with other stations. The TXOP participant stations do not obtain (preempt) the channel themselves, but are willing to join the TXOP shared by the TXOP holder STA. To simplify the description of the AP-initiated shared TXOP, the AP is generally considered as the TXOP holder, while the remaining stations are non-AP shared TXOP participant STAs. The AP can share a portion of its TXOP with the non-AP shared TXOP participant STAs for UL data transmission.

[0184] 6.2. Scenario description

[0185] The example BSS contains one AP and multiple non-AP STAs. Each non-AP STA can have packets to transmit to the AP generated at different rates and in different patterns (e.g., continuous, bursty or periodic). The AP also generates packets to each STA with possibly different traffic rates and patterns.

[0186] The present disclosure focuses on UL / DL OFDMA transmission, for which latency is always a critical issue due to the complex scheduling between each non-AP STA and the AP.

[0187] In 802.11ax technology, multiple non-AP STAs can simultaneously transmit UL data sequences or receive DL data sequences within a shared TXOP, which improves TXOP utilization efficiency.

[0188] However, in 802.11ax, the AP initiates UL data transmission; usually by sending a trigger frame (e.g., BSRP) to non-AP STAs to inquire their buffer status and traffic priority. When receiving the response frames (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 for sending their UL data sequences.

[0189] The AP-initiated TXOP cannot capture the dynamic demand from the non-AP STA side, especially for those non-AP STAs that have RTA (real-time application) packets to send. It should be noted that RTA packets are usually small in size (fewer bytes), however, RTA packets require more expedited transmission.

[0190] In the inventors' previous work, once a non-AP STA gains channel access, it can initiate and schedule MU-UL data transmission by sharing its TXOP with other non-AP STAs; but this sharing scheme is implemented only for UL transmission.

[0191] In this disclosure, TXOP sharing among UL and DL transmissions is implemented to further improve channel utilization efficiency and reduce latency.

[0192] In particular, the present disclosure provides the following main attributes. (a) Once any non-AP STA gains channel access, it can immediately initiate a shared TXOP. For example, a non-AP STA that gains channel access is referred to herein as a non-AP TXOP holder STA. The TXOP holder can also be an AP if the AP gains channel and is willing to share its TXOP. (b) Those non-AP STAs that are willing to participate in a shared TXOP are referred to herein as non-AP shared TXOP participant STAs. In this proposal, an AP can also be a shared TXOP participant. (c) The TXOP holder shares the TXOP duration in time domain with other shared TXOP participants in the same BSS. (d) The non-AP TXOP holder STA does not need to wait for the AP to initiate shared TXOP access. (e) The non-AP TXOP holder STA is able to schedule and allocate available channel access time resources to other shared TXOP participant STAs. (f) The non-AP TXOP holder STA can provide scheduling information to the AP once the TXOP is reserved. (g) The potential TXOP holder can allocate channel access resources using a predetermined schedule. (h) The TXOP is shared among UL and DL transmissions if the TXOP duration allows, and can be initiated by either UL transmission or DL transmission.

[0193] It should be noted that the RTS Shared frame and CTS Shared frame utilized in this disclosure are illustrated as modified RTS and CTS frames, which are used herein for a different purpose than they were created in IEEE 802.11 standards. Any other new (same purpose) frame can be utilized in the same place instead of RTS Shared and CTS Shared to do the same task. Similarly, for other frames in this disclosure, they can be replaced by new frames, or new elements can be added to do the same task.

[0194] The present disclosure helps to reduce the latency of the access channel, and also improves the channel utilization efficiency.

[0195] Figure 14 An example embodiment 510 is illustrated for a shared TXOP between multiple stations (including AP and non-AP stations) for transmitting uplink (UL) PPDUs and downlink (DL) PPDUs. The shared TXOP is illustrated between AP 12, STA1 14, STA2 16, and STA3 18. A high-level example of the shared TXOP protocol initiated by a non-AP TXOP holder STA can be seen in the figure.

[0196] In the TXOP setup procedure 532, the AP and non-AP STAs exchange TXOP shareability information with or without coordination of the AP.

[0197] Two TXOPs 514, 516 are shown in this figure. The TXOP holder can need to confirm the AP STAs or APs willing to participate in its shared TXOP and schedule channel access time and duration for each of them accordingly.

[0198] In the first shared TXOP, the TXOP holder conducts an UL transmission initiated shared TXOP 518. After the other non-AP STAs (in this case, STA1 and STA2) complete their UL SU PPDU transmissions 519 and 520, the AP transmits DL data 521 to each STA (e.g., STA1, STA2, and STA3) in the assigned shared TXOP slots.

[0199] The second shared TXOP is conducted with a DL transmission initiated shared TXOP. After the AP transmits its DL PPDU 522 to STA1 and STA2, the non-AP STAs (STA3 and STA1) start UL SU PPDU transmissions 524 and 526, respectively, using the assigned durations.

[0200] 6.3. Scenario Classification

[0201] The disclosure includes different solutions for three different scenarios: (1) Dynamic scenario: (A) No scheduling with AP as coordinator; (i) UL initiated sharing scheme; (B) Scheduling with AP as coordinator: (i) UL initiated sharing scheme, (ii) DL initiated sharing scheme; (2) Semi-static scenario: (i) UL initiated sharing scheme, (ii) DL initiated sharing scheme; and (3) Simplified scenario: (i) UL initiated sharing scheme, (ii) DL initiated sharing scheme.

[0202] These solutions for single BSS scenarios will exploit the described frame formats for analysis.

[0203] 7. Protocol design

[0204] 7.1. Overview of the protocol design

[0205] Figure 15 An example embodiment 530 illustrates the general overview of the proposed protocol (e.g., TXOP holder (STA / AP)) that senses the channel to be idle and gains (preempt) the channel access, then shares the channel access in time domain with other devices in the following TXOP. If other STAs have UL data to transmit, or if the AP has DL data to transmit, they will access the channel following the schedule determined by the sharing TXOP holder STA or based on a predetermined semi-static scheduling scheme. The proposed protocol is illustrated to include four phases, and can be applied to different channel access designs, such as random access and scheduled access.

[0206] In the first phase of the sharing TXOP setup 532, non-AP STAs and the AP exchange TXOP shareability information (by embedding the information in authentication request, authentication response, association request, association response, or any other frame exchanged, the information indicates the proposal / request of the STA or AP whether to share the TXOP) through the coordination of the AP.

[0207] In the second phase of the sharing TXOP announcement, the non-AP TXOP holder STA / AP gains the channel access and announces its willingness to share the TXOP with other devices. By way of example and not limitation, the procedure is achieved by sending an RTS sharing frame to indicate that the following TXOP is shareable, and receiving a feedback CTS sharing frame to confirm successful reception.

[0208] In the third phase of TXOP participant acquisition 536, the TXOP holder inquires other devices (e.g., through unicast or broadcast TXOP proposal frames) to identify sharing TXOP participant stations that will join the sharing TXOP, such as by receiving an access request frame from a sharing TXOP participant STA / AP.

[0209] In the fourth phase of TXOP scheduling and access 538, the TXOP holder and the shared TXOP participants access the channel at reserved times and scheduled times, respectively. The non-AP TXOP holder STA transmits UL data using the reserved time slots. The AP transmits DL data using the assigned time slots.

[0210] It should be appreciated that operational protocols can be implemented that contain a subset (or superset) of these phases, where not all phases are mandatory, nor are they limited to these phases.

[0211] 7.2. Dynamic scenarios without AP as coordinator

[0212] For UL initiated shared TXOP, the non-AP TXOP holder STA can coordinate directly with the APs and other non-AP STAs willing to participate in the shared TXOP. For DL initiated shared TXOP, the AP is the TXOP holder and can coordinate directly with other non-AP STAs willing to participate in the shared TXOP.

[0213] 7.2.1 Shared TXOP setup phase

[0214] Figure 16 An example embodiment 550 illustrating the shared TXOP setup phase is depicted, where the interactions between the AP 12, STA1 14, STA2 16 and STA3 18 are shown. In the figure, the process of the exchange of shared information in the shared TXOP setup phase is shown.

[0215] New elements are proposed, including (a) a STA TXOP shareability element, which is designed for the exchange of shared information, and (b) an access request information element, which is designed for the exchange of access time slot information and transmit request information. The new elements can be embedded in authentication request / response frames, association request / response frames, beacon frames, or any frames that can be exchanged between non-AP STAs and APs.

[0216] Non-AP STAs indicate their shareability in frames exchanged with the AP 552, such as for example, an element can be appended to an authentication request frame, an association request frame or any other frame that can be exchanged with the AP, which is sent to the associated AP. Once the AP receives the authentication request frame or the association request frame, the AP checks the sharing information and responds with a frame 554 to acknowledge (ACK) successful reception. The AP then broadcasts the shareability of all associated non-AP STAs using a share proposal / request frame 556. In this case, once a non-AP STA receives the share proposal / request frame, it knows the shareability, i.e., it can determine the STAs willing to share TXOP time and / or the STAs requesting TXOP time of other stations. Another sharing from non-AP STA 2 to the AP is also seen 558, the AP acknowledges 560 and broadcasts a share proposal / request 562.

[0217] The sharing TXOP setup phase is a common phase for dynamic scenarios with or without the AP as a coordinator. The sharing information is implemented in management frames by using a new element designed as a STA TXOP shareability element.

[0218] In addition to the above, the AP needs to indicate its shareability when sending the share proposal / request frames 556 and 562.

[0219] Figure 17 An example embodiment 570 illustrating the sharing TXOP setup phase at the AP level is shown. In the sharing TXOP setup phase, at 572, the AP receives a management frame such as an authentication request frame or an association request frame from a non-AP STA indicating whether this non-AP STA is willing to propose / request a shared TXOP with other non-AP STAs. The AP keeps information about the shareability of this non-AP STA and responds by sending an authentication / association response frame at 574 to acknowledge successful reception. Then, at 576, the AP preferably first records the latest shareability information to its database and then re-broadcasts the latest shareability information including its own shareability to all associated non-AP STAs using a share proposal / request frame. At 578, the AP also periodically broadcasts the latest TXOP share information of STAs and AP and channel access slot assignments by sending such as a beacon frame.

[0220] Figure 18A and Figure 18BFigure illustrates an example embodiment 590 of the shared TXOP setup phase handled at the non-AP STA layer. In the figure, at 592, the non-AP STA sends a management frame such as an authentication / association request frame to the associated AP indicating its sharing proposal / request information for a shared TXOP. At 594, a check is made to determine whether the non-AP STA receives a response from the associated AP before the management frame timeout after it has sent the authentication or association frame containing the sharing proposal / request information. If no response is received, a management frame timeout 596 occurs and the non-AP STA should resend the management frame to the associated AP at 592 to indicate its shareability.

[0221] If at block 594, it is determined that the non-AP STA receives a response, then block 598 is reached which determines whether the response is a sharing proposal / request frame from the associated AP indicating the latest TXOP shareability information for all associated non-AP STAs. If the non-AP STA does not receive its latest channel access slot through a sharing proposal / request frame or a beacon before the sharing proposal / request frame timeout, then when the sharing proposal / request timeout occurs, block 600 is reached and then the non-AP STA should send another frame at 592.

[0222] Otherwise, if the shareability information is received, then block 602 in Figure 5 is reached where the non-AP STA updates its database of sharing proposal / request information for all other STAs and the AP. Figure 18B

[0223] Then, a decision is made at 604 to determine whether the non-AP STA receives a beacon frame or a sharing proposal / request frame indicating its latest channel access slot. If it receives the beacon frame or the sharing proposal / request frame, then at block 606, the non-AP STA updates its database of the latest channel access slot. Otherwise, if at block 604, it does not receive the beacon frame or the sharing proposal / request frame, then at 608, the non-AP STA should continue to wait for a subsequent beacon frame or sharing proposal / request frame sent from the associated AP and continue to update the database at 606 based on the latest channel access slot information assigned to it.

[0224] 7.2.2. Shared TXOP announcement phase

[0225] Figure 19 ​An example embodiment 630 illustrating the shared TXOP announcement phase following the shared TXOP setup phase 532 is depicted, where the interaction between the AP 12, STA1 14, STA2 16 and STA3 18 is shown. The non-AP TXOP holder STA senses that the channel is idle (available) and it gains the channel, then announces its willingness to share the TXOP by sending an RTS share frame 634 to the AP, which is received by the other non-AP stations, thus knowing the NAV 638, 640 (set in the RTS share). After the AP receives the RTS share frame 634 from the non-AP TXOP holder STA, it responds with a CTS share frame 636 to STA3, indicating successful reception and knowing that the TXOP is a shared TXOP. The other non-AP stations receive the CTS share and then check the NAV 642, 644 (set in the CTS share).

[0226] In addition to the above example, it should be appreciated that the AP can also be the shared TXOP holder. When the AP is the TXOP holder, the AP can send an RTS share to the destination stations for which it has buffered data, and receive a CTS share frame to indicate successful transmission.

[0227] 7.2.3. UL initiated TXOP participant acquisition phase

[0228] 7.2.3.1. UL initiated TXOP participant acquisition with response after receiving a TXOP proposal

[0229] Figure 20 An example embodiment 650 illustrating the TXOP participant acquisition phase with response after receiving a TXOP proposal is depicted, where the interaction between the AP 12, STA1 14, STA2 16 and STA3 18 is shown. The shared TXOP setup 532 is performed, followed by the shared TXOP announcement 534. Then, the non-AP TXOP holder STA broadcasts 654 a new frame, i.e. a TXOP proposal frame, to the STAs and the AP, indicating that it is willing to share its TXOP and asking whether the other STAs are willing to join the shared TXOP.

[0230] Once STA1, STA2 and the AP receive the TXOP proposal frame, they respond 656a, 656b and 656c with new access request frames, indicating that they are willing to join the upcoming shared TXOP with the non-AP TXOP holder STA.

[0231] To avoid collisions of access request frames, a time slot design is implemented for random access or dedicated access, which is implemented in the shared TXOP setup phase. The time slots can be seen, where the responses about the sharing proposal are sent to STA3 in a specific time slot.

[0232] 7.2.3.2. UL initiated TXOP participant acquisition phase with response after receiving CTS sharing

[0233] Figure 21 An example embodiment 670 illustrating the TXOP participant acquisition (PA) phase with response after receiving CTS sharing is depicted, showing the interaction between the AP 12, STA1 14, STA2 16 and STA3 18. The shared TXOP setup 532 can be seen, followed by the shared TXOP announcement 534. Once the AP has sent the CTS sharing frame (not shown) in the previous shared TXOP announcement phase, it sends an access request frame to STA3 in time slot 672a through random access or dedicated access to indicate that it wants to join the shared TXOP with the non-AP TXOP referee STA. Once STA1 and STA2, which are non-AP shared TXOP participant STAs, receive the CTS sharing from the AP to STA3, which is a non-AP TXOP holder STA, they send an access request frame to STA3 in time slots 672b, 672c through random access or dedicated access to indicate that they want to join the next shared TXOP with the non-AP TXOP holder STA.

[0234] 7.2.3.3. UL initiated TXOP participant acquisition phase with response after receiving dedicated TXOP proposal frame

[0235] Figure 22 An example embodiment 690 illustrating the TXOP participant acquisition (PA) phase with response after receiving dedicated TXOP proposal is depicted. The interaction between the AP 12, STA1 14, STA2 16 and STA3 18 is described. The shared TXOP setup phase 532 is performed, followed by the shared TXOP announcement phase 534. Then, instead of broadcasting the TXOP proposal frame, STA3 unicasts the proposal frame to individually solicit potential shared TXOP participant STAs and the AP. First, a proposal 692 is sent from STA3 to STA1, which responds 694, then a proposal 696 is issued to STA2, which responds back 698. In addition, a proposal 700 is sent to the AP, which responds 702.

[0236] Therefore, once STA1, STA2 or the AP receive the TXOP proposal frame, they need to respond with an access request frame to the non-AP TXOP holder STA within a given time period (offset) if they want to join the next shared TXOP.

[0237] Figure 23Figure illustrates an example embodiment 710 of the TXOP participant acquisition phase handled by the non-AP TXOP holder STA. At 712, it is checked whether the non-AP TXOP holder has polled the TXOP sharing participant STAs and the AP. If no poll is detected at block 712, execution proceeds to block 716. However, if a poll is detected at block 712, at block 714 it is checked whether a TXOP proposal frame has been broadcast. If a TXOP proposal has been broadcast, execution proceeds to block 716, otherwise execution proceeds to block 720.

[0238] It should be noted that once STA1 or STA2 (non-AP sharing TXOP participant STAs) or the AP (sharing TXOP participant) receive the TXOP proposal frame, if they are willing to join the upcoming shared TXOP, they need to respond to the non-AP TXOP holder STA with an access request frame within the given time offset.

[0239] At block 716, it is checked whether the non-AP TXOP holder STA receives an access request frame within the given time offset during the upcoming slot access period. If no appropriate request frame is received, execution proceeds to block 722, the non-AP TXOP holder STA considers that no other non-AP STA or AP is willing to join the upcoming shared TXOP. Otherwise, if an appropriate access request frame is received at block 716, execution proceeds to block 718, the non-AP TXOP holder STA updates the database of upcoming shared TXOP participant STAs.

[0240] Returning to decision block 714, if the non-AP TXOP holder STA does not send a TXOP proposal frame; execution proceeds to block 720, which determines whether the non-AP TXOP holder STA receives an appropriate access request frame within the given time offset indicated in the unicast TXOP proposal frame. If this condition is met, an access request has been received, execution proceeds to block 718, otherwise execution proceeds to block 722.

[0241] Figure 24 Figure illustrates an example embodiment 730 of the TXOP participant acquisition phase handled by the AP. At 732, it is checked whether the AP receives a TXOP proposal frame from the non-AP TXOP holder STA.

[0242] If the AP does not receive a TXOP proposal frame from the non-AP TXOP holder STA, at block 736 the AP checks the RA field of the immediately preceding CTS share frame and responds with an access request frame to that address through random slot access or dedicated slot access.

[0243] Otherwise, if a TXOP proposal is received at block 732, a check is made at block 734 to determine if the TXOP proposal frame is broadcast. If the frame is broadcast, the AP responds to the non-AP TXOP holder STA with an access request frame through random or dedicated slot access at block 738.

[0244] However, if the TXOP proposal is not broadcast at block 734, then at block 740 the AP responds to the non-AP TXOP holder STA with an access request frame within a given time offset.

[0245] It should be noted that the dedicated slot duration is indicated by the allocation block duration subfield of the access request information element of the management frame previously exchanged in the shared TXOP setup phase.

[0246] Figure 25 An example embodiment 730 of a TXOP participant acquisition phase, processed at the non-AP shared TXOP participant STA side, is illustrated. The processing starts at 752, and then at 754 a check is made whether the non-AP shared TXOP participant STA has received a TXOP proposal frame from the non-AP TXOP holder STA.

[0247] If the non-AP shared TXOP participant STA has not received a TXOP proposal frame from the non-AP TXOP holder STA, then at block 756 the STA checks the RA field of the immediately preceding CTS share frame and responds to that address with an access request frame through random or dedicated slot access, after which the processing ends at 764.

[0248] If a TXOP proposal is received at block 754, a check is made at block 758 to determine if the TXOP proposal frame is broadcast. If the frame is broadcast, then at block 760 the non-AP shared TXOP participant STA responds to the non-AP TXOP holder STA with an access request frame through random or dedicated slot access, after which the processing ends at 764.

[0249] Otherwise, if the TXOP proposal is not broadcast at block 758, then at block 762 the non-AP shared TXOP participant STA that received the unicast TXOP proposal frame responds to the non-AP TXOP holder STA with an access request frame within a time offset, after which the processing ends.

[0250] 7.2.4. UL initiated TXOP scheduling and access

[0251] 7.2.4.1. UL initiated TXOP scheduling and access with unicast TXOP proposal frame

[0252] Figure 26An example embodiment 770 of TXOP scheduling and access utilizing unicast TXOP proposal frames is illustrated. The interaction between the AP 12, STA1 14, STA2 16, and STA3 18 is illustrated.

[0253] First, the shared TXOP setup phase 532, shared TXOP announcement phase 534, and TXOP participant acquisition phase 536 are performed.

[0254] The non-AP TXOP holder STA sends data to the associated AP, which it should receive an ACK from to indicate successful transmission, after which it unicasts a TXOP proposal frame to each next TXOP share participant STA indicating the transmission duration of the next TXOP share participant STA. In particular, this is illustrated in the following figure.

[0255] The non-AP TXOP holder STA sends data 771 to the associated AP (AP 12), which acknowledges 772 the data. STA3 then unicasts 773 a TXOP proposal frame to the next TXOP share participant STA (STA1) indicating the transmission duration of the next TXOP share participant STA. In response to the TXOP proposal 773 to STA1, STA1 sends data 774 to the AP, which acknowledges 775 the data. Thereafter, STA3 unicasts a TXOP proposal 776 to STA2, in response to which, STA2 sends data 777 to the AP, which acknowledges 778 the data. Thus, it can be seen that each participating non-AP TXOP holder STA sends data to the associated AP and receives an ACK from the AP to indicate successful transmission, after which the non-AP TXOP holder STA unicasts a TXOP proposal frame to the next TXOP share participant STA indicating the transmission duration of the next TXOP share participant STA.

[0256] Then, after looping through the non-AP share participant STAs, the TXOP holder unicasts a TXOP proposal frame 779 to the associated AP. Once the AP receives the TXOP proposal frame, the AP sends (downlink) DL data 780, 782, and 784 to the destination STAs at the scheduled times and waits for the corresponding ACKs 781, 783, and 786.

[0257] 7.2.4.2. UL initiated TXOP scheduling and access with unicast TXOP access scheduler

[0258] Figure 27 An example embodiment 790 of UL initiated TXOP scheduling and access with unicast TXOP access scheduler is illustrated. As with all these examples, the interaction between the AP 12, STA1 14, STA2 16, and STA3 18 in the procedure is illustrated by way of example and not limitation.

[0259] The shared TXOP setup phase 532, shared TXOP announcement phase 534 and TXOP participant acquisition 536 phases are first conducted.

[0260] The non-AP TXOP holder STA then unicast 792, 794 and 796 TXOP access scheduler frames to the non-AP shared TXOP participant STAs (STA1 and STA2) and the AP, indicating the TX duration for each STA. STA3 then sends its data 798 to the AP, which responds with an ACK 800.

[0261] Once the STAs receive the TXOP access scheduler frame, they send data to the associated AP in the different time slots as indicated in the allocation control field in the access request information element embedded in the beacon frame, and they wait for an ACK from the AP. This process is represented as STA2 sending data 802 to the AP and receiving an ACK 804 from the AP, then STA1 sending data 806 to the AP1, which responds with an ACK 808. Once the AP receives the TXOP access scheduler frame, it sends DL data 810, 814 and 818 to the respective destination STAs in the assigned time slots, and waits for the associated ACKs 812, 816 and 820.

[0262] 7.2.4.3. UL initiated TXOP scheduling and access with broadcast TXOP scheduler

[0263] Figure 28 An example embodiment 830 of TXOP scheduling and access with a broadcast TXOP scheduler frame is illustrated. The interaction between the AP 12, STA1 14, STA2 16 and STA3 18 is shown.

[0264] The shared TXOP setup phase 532, shared TXOP announcement phase 534 and TXOP participant acquisition 536 phases are first conducted.

[0265] The non-AP TXOP holder STA then broadcasts 832 a broadcast TXOP scheduling frame to the TXOP shared participant STAs and the AP, indicating the transmit (TX) duration for each STA and the AP. Thereafter, it can be seen that STA3 sends data 834 to the associated AP, which responds with an ACK 836.

[0266] Once the STAs receive the broadcast TXOP scheduler frame, they also send data 838, 842 to the associated AP in the different time slots as indicated in the broadcast TXOP scheduler frame, and the AP responds with ACKs 840 and 844.

[0267] Thus, it can be seen that first the non-AP TXOP holder STA broadcasts a broadcast TXOP scheduler frame indicating TX durations for each non-AP shared TXOP participant STA and the AP. Once the STAs receive the broadcast TXOP scheduler frame, they transmit data to the associated AP in different time slots as indicated in the broadcast TXOP scheduler frame and wait for ACK.

[0268] Then, once the AP receives the broadcast TXOP scheduler frame, it transmits DL data 846, 850 and 854 to the respective destination STAs in the assigned time slots and waits for the associated ACKs 848, 852 and 856.

[0269] Figure 29A and Figure 29B An example embodiment 870 illustrating the UL initiated TXOP scheduling and access phase of processing at the non-AP TXOP holder STA level.

[0270] At 872, a check is made whether the non-AP TXOP holder STA has already unicasted a TXOP proposal frame with a specified TX duration field.

[0271] If it has already unicasted a TXOP proposal frame, then execution proceeds to block 880 where after the specified TX duration, the non-AP TXOP holder STA unicasts another TXOP proposal frame to the next TXOP shared participant STA.

[0272] Then at block 882, a check is made whether there are more TXOP shared participants. If there are more participants, then execution proceeds back to block 880 to continue processing, otherwise execution proceeds to block 884 where the non-AP TXOP holder STA unicasts another TXOP proposal frame to the AP.

[0273] However, if at block 872 the test for unicasting a TXOP proposal is not met, then execution proceeds to block 874 where a check is made to determine whether the non-AP TXOP holder STA has already unicasted TXOP access scheduler information to the TXOP shared participant STAs. If it is determined that the scheduler information was unicasted, then at block 886 the non-AP TXOP holder STA indicates the TXOP access duration for the shared TXOP participants in the TXOP access scheduler frame and processing ends thereafter.

[0274] However, if at block 874 the STA has not unicasted a TXOP access scheduler, then execution proceeds to block 876 where a check is made to determine whether the non-AP TXOP holder STA has already unicasted a TXOP access frame to the TXOP shared participant STAs. If it is determined that the TXOP access frame was unicasted, then at block 888 the non-AP TXOP holder STA indicates the TXOP access duration for the shared TXOP participants in the TXOP access frame and processing ends thereafter. Figure 30BAt block 876 in the non-AP TXOP holder STA checks whether it has broadcasted a broadcast TXOP schedule frame to the TXOP participant STAs. If it decides that a broadcast was made, then it proceeds to block 888 in which the non-AP TXOP holder STA indicates the TXOP access duration for each of the shared TXOP participant STAs in the broadcast TXOP schedule frame.

[0275] However, if at block 876 the STA did not broadcast a broadcast TXOP schedule frame, then execution proceeds to block 878 in which it checks whether it received a DL data frame. If it received a DL data frame, then at block 890 the non-AP TXOP holder STA responds to the source of the data frame with an ACK frame, otherwise the process simply ends.

[0276] Figure 30A and Figure 30B An example embodiment 910 illustrates the UL initiated TXOP schedule and access phase at the level of the non-AP shared TXOP participant STAs. At block 912 it checks whether any of the non-AP shared TXOP participant STAs received a TXOP proposal frame with a specified TX duration field. If it received the TXOP proposal frame, then at block 920 it transmits a data frame to the associated AP for the specified TX duration, and then at block 922 the STA waits for an ACK from the AP to indicate successful transmission of the data, and then the process ends.

[0277] Otherwise, if at block 912 it finds that no TXOP proposal frame was received, then execution proceeds to block 914 which checks whether any of the non-AP shared TXOP participant STAs received a unicast TXOP access scheduler frame. If it received the unicast TXOP access scheduler frame, then at block 924 the STA maps the TID, source association ID (AID) and destination AID to the corresponding fields as set in the access request information element of the beacon frame and assigns it a TXOP access duration. The STA then transmits data to the associated AP for the TXOP access duration, and then execution proceeds to block 922, after which the process ends.

[0278] However, if at block 914 there was no unicast TXOP access scheduler frame, then execution proceeds to Figure 30Bframe. If the broadcast TXOP scheduler frame is received, then at block 926, the STA maps the TID, source AID, and destination AID to the corresponding fields as set in the broadcast TXOP schedule frame and allocates a TXOP access duration for it. The STA then transmits data to the associated AP within the TXOP access duration, and then performs block 922, after which the process ends.

[0279] If at block 916, the non-AP shared TXOP participant STA does not receive the broadcast TXOP scheduler frame, then execution proceeds to block 918, which determines whether any non-AP shared TXOP participant STA receives a DL data frame. If it does not receive a DL data frame, then the process ends. Otherwise, execution proceeds to block 928, in which the non-AP shared TXOP participant STA responds to the source of the data frame with an ACK frame, after which the process proceeds to block 922 in FIG. 9, and then the process ends. Figure 30A

[0280] Figure 31A and Figure 31B FIG. 9 illustrates an example embodiment 950 of UL initiated TXOP scheduling and access phase at the AP level. At 952, a check is made to determine whether the AP receives a TXOP proposal frame with a specified TX duration field. If the TXOP proposal frame is received, then at block 960, data frames are transmitted to the destination stations within the specified TX duration, after which at block 962, the AP waits for an ACK from each destination STA to indicate successful transmission of the DL data.

[0281] Otherwise, if at block 952, the AP is found not to have received a TXOP proposal frame, then execution proceeds to block 954, which determines whether the AP receives a unicast TXOP access scheduler frame. If the unicast TXOP access scheduler frame is received, then at block 964, the AP maps the TID, source association ID (AID), and destination AID to the corresponding fields as set in the access request information element of the management frame exchanged previously, and allocates a TXOP access duration for each DL traffic destination. The AP then transmits data to each destination within the TXOP access duration, after which execution proceeds to block 962, in which the AP waits for an ACK, after which the process ends.

[0282] However, if at block 954, the AP does not receive a unicast TXOP access scheduler frame, then execution proceeds to Figure 31B ​At block 956 in FIG. 9, block 956 checks whether the AP receives a broadcast TXOP scheduler frame. If the broadcast TXOP schedule frame is received, at block 966, the AP maps the TID, source AID and destination AID to the corresponding fields as set in the broadcast TXOP schedule frame and allocates TXOP access duration for each DL traffic destination. The AP transmits data to each destination within the TXOP access duration, after which processing proceeds to Figure 31A

[0283] However, if at block 956, the AP does not receive a broadcast TXOP scheduler frame, then processing proceeds to block 958, which determines whether the AP receives an UL data frame. If the frame is not received, then processing ends. Otherwise, at block 968, the AP responds to the source of the data frame with an ACK frame.

[0284] 7.3. Dynamic scenario with AP as coordinator

[0285] For UL initiated shared TXOP, the non-AP TXOP holder STA cannot directly communicate with other non-AP STAs willing to participate in the shared TXOP. In this case, the AP needs to get involved to coordinate between the non-AP TXOP holder STA and other non-AP shared TXOP participant STAs.

[0286] For DL initiated shared TXOP, the AP acquires (wins) the channel and is the TXOP holder. The AP can directly communicate with other non-AP STAs and share its TXOP with other non-AP STAs willing to participate in the shared TXOP.

[0287] The shared TXOP setup phase in the dynamic scenario with AP as coordinator is the same as explained above in section 7.2.1.

[0288] 7.3.1. Shared TXOP announcement phase

[0289] It should be noted that the UL initiated shared TXOP announcement phase in the scenario with AP as coordinator is the same as introduced above in section 7.2.2.

[0290] Figure 32 An example embodiment 990 illustrating the DL initiated shared TXOP announcement phase is shown. The interaction between the AP 12 and the non-AP sharing STAs illustrated as STA1 14, STA2 16 and STA3 18 is exemplified.

[0291] The shared TXOP setup phase 532 is performed, followed by the shared TXOP announcement phase.

[0292] ​In this case, the shared TXOP announcement phase is initiated by a DL transmission, where the AP acquires the channel and sends an RTS share 992 to STA3, which is the destination of the DL traffic. STA3 receives the RTS share and responds with a CTS share frame 998, while STAl and STA2 know the NAV RTS share 994 and 996. Upon sending the CTS share to the AP, STAl and STA2 know the NAV (CTS share) 1000 and 1002 and know the updated NAV value set by the CTS share frame. The AP receives the CTS share from STA3 and knows that the RTS share was successfully sent to STA3.

[0293] Figure 33 An example embodiment 1110 of the shared TXOP announcement phase at the AP's processing is illustrated. At 1112, the AP checks to determine if the channel is idle. If the channel is not idle, the AP takes a random backoff 1114 and returns to block 1112 to sense the channel again.

[0294] However, if the channel is found to be idle at block 1112, a check is made at block 1116 to determine if the AP is willing to share the upcoming TXOP. If the AP has DL data to send and is willing to share the TXOP, the AP TXOP sends an RTS share frame to the destination STA of the DL data at block 1118. Execution then proceeds to block 1120 to determine if the AP receives a CTS share frame from the destination STA as indicated by the RTS share before the RTS timeout. If a CTS share is not received, an RTS share timeout occurs at block 1122 and execution returns to block 1118 to send another RTS share. Otherwise, if a CTS share is received, the process ends.

[0295] Returning to decision block 1116, if the AP is not willing to share the channel, the process ends.

[0296] Figure 34 An example embodiment 1130 of the shared TXOP announcement phase at the non-AP STA's level processing is illustrated. A check 1132 determines if the non-AP STA receives an RTS share frame. If it does not receive an RTS share frame, the process in this routine ends. Otherwise, if an RTS share frame is received, a block 1134 determines if the non-AP STA is the destination of the RTS share. If the condition is met, the non-AP STA responds to the RTS share by sending a CTS share frame to the source of the RTS share frame at block 1136; the source of the RTS share frame is the STA / AP that sent the RTS share frame. The process ends thereafter.

[0297] Otherwise, if the non-AP STA is not the destination of the RTS sharing at block 1134, then a block 1138 is reached, which informs the non-AP STA of the NAV set by the RTS sharing frame. Then, a check 1140 determines whether the non-AP STA receives a CTS sharing frame. If it does not receive a CTS sharing frame, then the execution ends. Otherwise, upon receiving the CTS sharing frame, a block 1142 ensures that the non-AP STA is aware of the NAV set by the CTS sharing frame, after which the process ends.

[0298] 7.3.2. TXOP participant acquisition phase with AP as coordinator

[0299] 7.3.2.1. TXOP participant acquisition phase with response after receiving TXOP proposal (with AP)

[0300] Figure 35 An example embodiment 1150 illustrating a UL initiated TXOP participant acquisition phase (with AP as coordinator) with response after receiving TXOP proposal is illustrated. The interactions between the AP 12, STA1 14, STA2 16 and STA3 18 are depicted.

[0301] A shared TXOP setup phase 532 and a shared TXOP announcement phase 534 are first conducted. The AP then broadcasts 1152 a TXOP proposal frame indicating that the non-AP TXOP holder STA is willing to share its TXOP and asking whether there are other non-AP STAs willing to join the shared TXOP.

[0302] Upon receiving the TXOP proposal frame, other non-AP STAs respond to the AP with new access request frames sent in slots of slots 1154 and 1156 if they are willing to participate in the upcoming shared TXOP. It should be noted that access to the slots can be implemented based on random access or dedicated access in order to avoid collisions of access request frames.

[0303] The AP then unicasts 1158 a shared TXOP participant announcement frame to the non-AP TXOP holder STA to announce the shared TXOP participant information, including the AP's own participant information.

[0304] Figure 36 An example embodiment 1170 illustrating a (DL initiated) TXOP participant acquisition phase with response after receiving TXOP proposal is illustrated.

[0305] The interactions between the AP 12, STA1 14, STA2 16 and STA3 18 are depicted. A shared TXOP setup 532 is conducted, followed by a shared TXOP announcement 534.

[0306] The AP then broadcasts 1172 a TXOP proposal frame indicating that it is willing to share its TXOP and asking other STAs that are willing to join the shared TXOP.

[0307] Once the STAs receive the TXOP proposal frame, they respond with an access request frame 1174, 1176, and 1178 to indicate their willingness to join the shared TXOP. To avoid collision of access request frames, the non-AP shared TXOP participant STAs transmit the access request frames by either randomly accessing a time slot or specifically accessing a certain time slot. The time slot access rule is implemented in the shared TXOP setup phase.

[0308] 7.3.2.2. TXOP participant acquisition phase with response after CTS (AP as coordinator)

[0309] Figure 37 An example embodiment 1210 of a UL initiated TXOP participant acquisition phase with response after receiving CTS (AP as coordinator) is illustrated.

[0310] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. A shared TXOP setup 532 is conducted, followed by a shared TXOP announcement 534.

[0311] Once the non-AP STA receives the CTS share frame sent from the AP to the non-AP TXOP holder STA (from the previous shared TXOP announcement phase, not shown in this phase), if the non-AP STA is willing to join the following shared TXOP and it does not receive a TXOP proposal frame as shown in Figure 36 the non-AP TXOP holder STA, it can send an access request frame 1212, 1214 to the AP by either random access or specific access. After the access time slot time expires, the AP unicasts a shared TXOP participant announcement frame 1216 to the non-AP TXOP holder STA to announce the TXOP share participant information, including its own participant information about the AP.

[0312] Figure 38 An example embodiment 1230 of a DL initiated TXOP participant acquisition phase with response after receiving CTS is illustrated.

[0313] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. A shared TXOP setup 532 is conducted, followed by a shared TXOP announcement 534.

[0314] STA3 in this example is the destination of the RTS Share frame sent by the AP. Then, once STA3 sends the corresponding CTS Share frame, it sends an access request frame 1236 to the AP through random access or dedicated access to indicate that it is willing to join the shared TXOP with the AP.

[0315] Once STA1 and STA2 receive the shared CTS (sent from STA3 to the AP), STA1 and STA2 send access request frames 1232, 1234 to the AP through random access or dedicated access, respectively, to indicate that they are willing to join the shared TXOP with the TXOP holder.

[0316] 7.3.2.3 TXOP participant acquisition phase with responders after a dedicated TXOP proposal frame (with the AP as the coordinator)

[0317] Figure 39 Figure illustrates an example embodiment 1250 of the UL-initiated TXOP participant acquisition phase with responders after receiving a dedicated TXOP proposal, with the AP as the coordinator.

[0318] The interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. The shared TXOP setup 532 is conducted, followed by the shared TXOP announcement 534.

[0319] The AP unicasts TXOP proposal frames 1252, 1256 to each of the non-AP STAs (except the non-AP TXOP holder STA), which in this example are STA1 and STA2. Once the non-AP STAs, e.g., STA1 and STA2, receive the TXOP proposal frames, they respond with access request frames 1254 and 1258 to the associated AP within the specified time offset if they are willing to join the shared TXOP.

[0320] The AP then unicasts a shared TXOP participant announcement frame 1260 to the non-AP TXOP holder STA, which in this example is STA3, to announce the TXOP sharing participant information, including its own participant information.

[0321] Figure 40 Figure illustrates an example embodiment 1290 of the DL-initiated TXOP participant acquisition phase with responders after receiving a dedicated TXOP proposal.

[0322] The interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. The shared TXOP setup 532 is conducted, followed by the shared TXOP announcement 534.

[0323] AP unicast TXOP proposal frames 1252, 1256, and 1292 to interrogate non-AP STAs one at a time. Once the non-AP STAs receive the TXOP proposal frame, if they are willing to join the shared TXOP, they respond to the associated AP with an access request frame 1254, 1258, and 1294 within the time offset.

[0324] Figure 41 An example embodiment 1310 of the UL initiated TXOP participant acquisition phase handled at the AP level is illustrated.

[0325] A check 1312 determines whether the AP has interrogated TXOP sharing participant STAs by sending a TXOP proposal frame. If no TXOP proposal frame was sent, execution proceeds to block 1316 because non-AP shared TXOP participants can send an access request frame to the AP after receiving a CTS share frame sent during the shared TXOP announcement phase. Otherwise, a check is made at 1314 to determine whether the TXOP proposal frame was broadcast. If the TXOP proposal frame was broadcast, then at block 1316 the AP waits to receive one or more access request frames within the period of time for slotted access.

[0326] If the TXOP proposal was not broadcast, then at block 1318 the AP should receive an access request frame within the time offset as indicated in the unicast TXOP proposal frame.

[0327] Execution from either block 1316 or 1318 proceeds to decision block 1320 which determines whether there are more access requests to be received. If there are more expected access requests, execution proceeds to block 1322 where it continues to receive, after which it returns to block 1320.

[0328] Otherwise, with access requests received from all TXOP sharing participant STAs, execution proceeds to block 1324 where the AP unicasts a shared TXOP participant announcement frame to the non-AP TXOP holder STAs.

[0329] Figure 42 An example embodiment 1350 of the UL initiated TXOP participant acquisition phase handled at the non-AP shared TXOP participant STA level is illustrated.

[0330] A check 1352 determines whether the non-AP shared TXOP participant STA has received a broadcast TXOP proposal frame from the associated AP. If the participant STA has received a TXOP proposal frame, then at 1354 it checks whether the TXOP proposal frame was broadcast. If the frame is found to be broadcast, then at block 1356 the STA responds to the associated AP with an access request frame through either random slotted access or dedicated slotted access.

[0331] If at block 1354 it is determined that the TXOP proposal frame is not broadcasted, then flow proceeds to block 1360 where the non-AP shared TXOP participant STAs respond to the associated AP with an access request frame within the time offset as indicated in the TXOP proposal frame.

[0332] If at block 1352 it is determined that no TXOP proposal is received, then flow proceeds to block 1358 where the non-AP shared TXOP participant STAs send an access request frame to the associated AP through random slot access or dedicated slot access.

[0333] Figure 43 An example embodiment 1370 of the DL initiated TXOP participant acquisition phase at the AP processing is illustrated.

[0334] A check 1372 determines whether the AP has polled the non-AP TXOP shared participant by sending a TXOP proposal frame. If no poll is detected at block 1372, then flow proceeds to block 1376. However, if a poll is detected at block 1372, then a check is made at block 1374 to determine whether the TXOP proposal frame has been broadcasted. If the TXOP proposal is not broadcasted, then flow proceeds to block 1380, otherwise flow proceeds to block 1376.

[0335] It should be noted that once STA1 or STA2 (non-AP shared TXOP participant STAs) receive the TXOP proposal frame, if they are willing to join the upcoming shared TXOP, they need to respond to the non-AP TXOP holder STA with an access request frame within the time offset.

[0336] At block 1380, a check is made whether the AP receives an access request frame within the time and offset as indicated in the TXOP proposal frame as unicast. If no appropriate request frame is received at block 1380, then flow proceeds to block 1382 where the AP sets that no other non-AP STA is willing to join the upcoming shared TXOP. Otherwise, if an appropriate request frame is received at block 1380, then flow proceeds to block 1378 where the AP updates the database of the upcoming shared TXOP participant STAs. At block 1376, a check is made whether the AP receives an access request frame during the upcoming slot access. If an appropriate access request frame is received, then flow proceeds to block 1378 where the AP updates the database of the upcoming shared TXOP participant STAs. Otherwise, since the AP did not receive an access request frame at block 1376, flow proceeds to block 1382 already described.

[0337] It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in Figure 43 It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the non-AP shared TXOP participant STA level is the same as shown in It should be noted that the flowchart of the DL initiated TXOP participant acquisition phase at the

[0338] 7.3.3. TXOP scheduling and access (AP as coordinator)

[0339] 7.3.3.1. TXOP scheduling and access with unicast TXOP proposal frame (AP present)

[0340] Figure 44 An example embodiment 1410 illustrating UL initiated TXOP scheduling and access phase with unicast TXOP proposal frame (AP as coordinator) is described.

[0341] Interactions between the AP 12, STA1 14, STA2 16 and STA3 18 are depicted. A shared TXOP setup 532 is made, followed by a shared TXOP announcement 534, and then a TXOP participant acquisition phase 536. The non-AP TXOP holder STA, exemplified as STA3, sends a data 1412 to the associated AP, and it should receive an ACK 1414 to indicate successful transmission of the data. Then, the non-AP TXOP holder STA sends a request TXOP proposal frame 1416 to the associated AP for STA1; the request includes an indication of the start of shared TXOP access for the next TXOP shared participant STA.

[0342] Upon receiving the request TXOP proposal frame, the AP unicasts a TXOP proposal frame 1418 to the TXOP shared participant STA1, the TXOP proposal frame 1418 including an indication of the TX duration of the TXOP shared participant STA1. When receiving the TXOP proposal frame, the non-AP shared TXOP participant STA1 sends UL data 1420 to the associated AP with the transmission duration as indicated in the TXOP proposal frame, which the AP responds with an ACK 1422.

[0343] In case STA3 sends a request TXOP proposal frame 1424 to the associated AP for STA2, the above described process is repeated for STA2; the request includes an indication of the start of shared TXOP access for the TXOP shared participant STA2.

[0344] Upon receiving the request TXOP proposal frame, the AP unicasts a TXOP proposal frame 1426 to the TXOP shared participant STA2, the TXOP proposal frame 1426 including an indication of the transmission duration of the TXOP shared participant STA2.

[0345] When receiving the TXOP proposal frame, the non-AP shared TXOP participant STA2 sends UL data 1428 to the associated AP with the transmission duration as indicated in the TXOP proposal frame, which the AP responds with an ACK 1430.

[0346] After looping through all non-AP sharing TXOP participant STAs, the non-AP TXOP holder STA unicasts TXOP proposal frame to the AP 1432.

[0347] After receiving the TXOP proposal frame, the AP transmits DL data 1434, 1438 and 1442 to the destination STAs in the assigned time slots and waits for ACKs 1436, 1440 and 1444 from each destination STA.

[0348] Figure 45 An example embodiment 1470 illustrating DL initiated TXOP scheduling and access with unicast TXOP proposal frame is shown.

[0349] Interactions between the AP 12, STA1 14, STA2 16 and STA3 18 are depicted. A shared TXOP setup 532 is made, followed by a shared TXOP announcement 534, and then a TXOP participant acquisition phase 536.

[0350] First, the AP transmits DL data 1472, 1476 and 1480 to the destination STAs (STA1, STA2 and STA3), in response to which the AP should receive ACKs 1474, 1478 and 1482 from each destination STA indicating successful transmission.

[0351] Then, as the AP loops through all TXOP sharing participant STAs, the AP unicasts a TXOP proposal frame to each STA indicating the transmission duration of the next TXOP sharing participant STA. This is illustrated as TXOP proposal frames 1484, 1490 and 1496 transmitted to STA1, STA2 and STA3 respectively.

[0352] Upon receiving the TXOP proposal frame, each non-AP sharing TXOP participant STA that receives the frame transmits UL data 1486, 1492 and 1498 back to the associated AP for the duration as indicated in the TXOP proposal frame, and waits to receive ACKs 1488, 1494 and 1500 from the AP to indicate successful transmission.

[0353] 7.3.3.2. TXOP scheduling and access with unicast TXOP access scheduler (AP as coordinator)

[0354] Figure 46 An example embodiment 1530 illustrating UL initiated TXOP scheduling and access phase with unicast TXOP access scheduler frame (AP as coordinator) is shown.

[0355] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. A shared TXOP setup 532 is made, followed by a shared TXOP announcement 534, and then a TXOP participant acquisition phase 536.

[0356] Before the non-AP TXOP holder STA transmits data to the associated AP, it first transmits a request TXOP access scheduler frame 1532 to the associated AP, which indicates shared TXOP access to all other non-AP shared TXOP participant STAs and the AP.

[0357] Upon receiving the request TXOP access scheduler frame, the AP unicasts TXOP access scheduler frames to each non-AP shared TXOP participant STA, indicating the TX duration for each of them. In this example, these scheduler frames 1534 and 1536 are transmitted to STA1 and STA2.

[0358] Once the non-AP shared TXOP participant STAs receive the TXOP access scheduler frames, they will transmit data 1538, 1542, and 1546 to the associated AP in the time slots as indicated in the allocation control field of the access request information element embedded in the beacon frame, and wait for ACKs 1540, 1544, and 1548.

[0359] In addition, it can be seen that the AP transmits DL data 1550, 1554, and 1558 to the destination STAs in the assigned time slots, and waits for ACKs 1552, 1556, and 1560.

[0360] Figure 47 An example embodiment 1570 illustrating DL initiated TXOP scheduling and access with unicast TXOP access scheduler is illustrated.

[0361] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. A shared TXOP setup 532 is made, followed by a shared TXOP announcement 534, and then a TXOP participant acquisition phase 536.

[0362] First, the AP sends DL data 1572, 1576, and 1580 to the destination STAs and should receive ACKs 1574, 1578, and 1582 from each destination STA indicating that the transmission was successful. Then, the AP unicasts TXOP access scheduler frames 1584, 1586, and 1588 to each non-AP shared TXOP participant STA indicating the TX duration for each STA. Once the STAs receive the TXOP access scheduler frames, they will transmit data 1590, 1594, and 1598 to the associated AP in the assigned slots and wait for ACKs 1592, 1596, and 1600.

[0363] 7.3.3.3. TXOP scheduling and access with broadcast TXOP scheduler (AP as coordinator)

[0364] Figure 48 An example embodiment 1650 illustrating UL initiated TXOP scheduling and access with broadcast TXOP scheduler frames (AP as coordinator) is illustrated.

[0365] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. The shared TXOP setup 532 is performed, followed by the shared TXOP announcement 534, and then the TXOP participant acquisition phase 536.

[0366] Before the non-AP TXOP holder transmits data to the associated AP, it first transmits a request TXOP access schedule frame 1652 to the AP indicating shared TXOP access to all other non-AP shared TXOP participant STAs and the AP.

[0367] Upon receiving the request TXOP access scheduler frame, the AP broadcasts a TXOP scheduler frame 1654 to the non-AP shared TXOP participant STAs (here denoted as STA1, STA2, and TXOP holder STA3) indicating the TX duration for each shared TXOP participant. Once the non-AP shared TXOP participant STAs receive the broadcast TXOP scheduler frame, they respond by transmitting UL data 1656, 1660, and 1664 to the associated AP in the slots as indicated in the broadcast TXOP scheduler frame and wait for ACKs 1658, 1662, and 1666. After completing the reception of all UL data, the AP then transmits DL data 1668, 1672, and 1676 to the destination STAs in the assigned slots and waits for ACKs 1670, 1674, and 1678.

[0368] Figure 49 An example embodiment 1710 illustrating DL initiated TXOP scheduling and access with broadcast TXOP scheduler frames is illustrated.

[0369] Interactions between the AP 12, STA1 14, STA2 16, and STA3 18 are depicted. A shared TXOP setup 532 is made, followed by a shared TXOP announcement 534, and then a TXOP participant acquisition phase 536.

[0370] First, the AP sends DL data 1572, 1576, and 1580 to the respective destination STAs in the assigned time slots and waits for the associated ACKs 1574, 1578, and 1582. Then, the AP broadcasts a broadcast TXOP scheduler frame 1712 indicating the TX duration for each non-AP shared TXOP participant STA. Once the STAs receive the broadcast TXOP scheduler frame, they will send UL data 1538, 1542, and 1546 to the associated AP in different time slots as indicated in the broadcast TXOP scheduler frame and wait for the associated ACKs 1540, 1544, and 1548.

[0371] 7.3.4. UL initiated TXOP scheduling and access phase at non-AP TXOP holder STA level (with AP as coordinator)

[0372] Figure 50A and Figure 50B An example embodiment 1750 of an UL initiated TXOP scheduling and access phase at non-AP TXOP holder STA level (with AP as coordinator) is illustrated.

[0373] At 1752, a check is made to determine whether the non-AP TXOP holder STA has sent a request TXOP proposal frame with a specified TX duration field. If a request TXOP proposal was sent, at block 1760, the non-AP TXOP holder STA can send a request TXOP proposal frame to the AP to poll the next non-AP shared TXOP participant STA after the specified TX duration and a TXOP proposal frame transmission duration.

[0374] A check 1762 determines whether there are more TXOP participant STAs to poll. If there are more participants, execution returns to block 1760 so that the non-AP TXOP holder STA will continue to send request TXOP proposal frames to the AP. Once all TXOP participant STAs and available TXOP durations have been processed, at block 1764, the non-AP TXOP holder STA unicasts another TXOP proposal frame to the AP, after which processing ends.

[0375] Otherwise, if at block 1752, it is determined that the non-AP TXOP holder STA did not send a request TXOP proposal, then at block 1754, it is determined whether the non-AP TXOP holder STA has unicast a request TXOP access scheduler frame to the AP. If the scheduler frame was sent, then at block 1766, the non-AP shared TXOP holder STA indicates the TXOP access duration for the non-AP shared TXOP participant STAs and the AP in the request TXOP access scheduler frame, after which the process ends.

[0376] Otherwise, if at block 1754, the non-AP TXOP holder STA did not unicast a request TXOP access scheduler frame to the AP, then execution proceeds to block 1756 in Figure 51B

[0377] Otherwise, if at block 1756, it is determined that the non-AP TXOP holder did not send UL data to the AP, then execution proceeds to block 1758, which checks to determine whether the non-AP TXOP holder received DL data from the AP. If it did not receive DL data, then the process ends, otherwise at block 1770, the non-AP TXOP holder STA responds with an ACK.

[0378] 7.3.5. UL initiated TXOP scheduling and access phase at AP processing (with AP as coordinator)

[0379] Figures 51A-51C An example embodiment 1790 of the UL initiated TXOP scheduling and access phase at AP processing with AP coordination is illustrated.

[0380] A check is made at 1792 to determine whether the AP has received a request TXOP proposal frame. If a request TXOP proposal is received, then at block 1798, the AP unicasts a TXOP proposal frame to the next TXOP shared participant STA with the AID specified in the duration / ID field of the request TXOP proposal frame. The AP should also indicate the TX duration corresponding to the information from the received request TXOP proposal frame in the TXOP proposal frame.

[0381] A check 1800 determines whether the AP receives a data frame from the next non-AP shared TXOP participant STA within the TX duration. If the AP does not receive a data frame within the time limit, then at 1804, the TXOP proposal frame times out, and at 1798, the AP should resend the TXOP proposal frame.

[0382] ​However, if at block 1800, the AP has received a data frame from the next non-AP shared TXOP participant STA, then at 1802, the AP responds with an ACK, after which the process ends.

[0383] Otherwise, if at block 1792, it is determined that the AP did not receive the request TXOP proposal frame, then block 1794 in Figure 51B is reached, which checks whether the AP received a request TXOP access scheduler frame. If the AP received the TXOP scheduler frame, then at block 1806, the AP can either unicast the TXOP access scheduler frame to each TXOP shared participant STA, or send one broadcast TXOP scheduler frame to all non-AP shared TXOP participant STAs.

[0384] Check 1808 then determines whether the AP has received a data frame from a non-AP shared TXOP participant STA within the transmit duration. If the AP has received the data frame, then execution proceeds back to block 1802, where the AP responds with an ACK, after which the process ends. Otherwise, if the frame is not received, then execution proceeds to block 1810, where the TXOP access scheduler frame times out, returning to block 1806. Figure 51A

[0385] Otherwise, if at block 1794, it is determined that the AP did not receive the request TXOP access scheduler frame, then block 1796 in Figure 51C is reached. Block 1796 checks to determine whether the AP received either a TXOP proposal frame or a request TXOP access scheduler frame. If the AP did not receive either of these frames, then execution ends. However, if one of these frames is received, then at block 1812, the AP transmits a DL data frame to the destination STA within the assigned transmitter duration. The AP then waits for an ACK from each destination STA at 1814, indicating that the DL data was successfully received.

[0386] 7.3.6. UL initiated TXOP scheduling and access phase at non-AP shared TXOP participant STAs process (with AP as coordinator)

[0387] Figure 52A and Figure 52B Figure illustrates an example embodiment 1830 of an UL initiated TXOP scheduling and access phase at non-AP shared TXOP participant STAs process (with AP as coordinator).

[0388] In Figure 52A ​The non-AP shared TXOP participant STA checks at block 1832 to determine if it has received a TXOP proposal frame with a specified TX duration field. If it has received a TXOP proposal frame, then at block 1840 the non-AP shared TXOP participant STA transmits data frames to the associated AP for the specified TX duration. Then at block 1842 the non-AP shared TXOP participant STA waits to receive an ACK from the AP indicating successful transmission of the UL data, after which the process ends.

[0389] Otherwise, if at block 1832 the condition is not met, then execution proceeds to check 1834 which determines if any non-AP shared TXOP participant STA has received a unicast TXOP access scheduler frame. If it has received the frame such that the condition is met, then at block 1844 the non-AP shared TXOP participant STA maps the TID, source AID and destination AID to the corresponding fields as set in the access request information element of the beacon frame and allocates it a TXOP access duration. It then transmits data for the TXOP access duration. Execution then proceeds back to block 1842, after which the process ends.

[0390] Otherwise, if at block 1834 the condition is not met, then at Figure 52B The non-AP shared TXOP participant STA checks at block 1836 to determine if it has received a broadcast TXOP scheduler frame. If the condition is met, then at block 1846 the non-AP shared TXOP participant STA maps the TID, source AID and destination AID to the corresponding fields as set in the broadcast TXOP schedule frame and allocates it a TXOP access duration, after which it should transmit data for the TXOP access duration, execution proceeds to Figure 52A block 1842, after which the process ends.

[0391] Otherwise, if at block 1836 the condition is not met, then execution proceeds to block 1838 which checks to determine if the non-AP shared TXOP participant STA has received a DL data frame. If it has received a DL data frame, then at block 1848 the non-AP shared TXOP participant STA responds with an ACK to the source STA of the DL data frame, after which the process ends.

[0392] 7.3.7. DL initiated TXOP scheduling and access phase at the AP level

[0393] Figure 53A and Figure 53BFigure illustrates an example embodiment 1870 of DL initiated TXOP scheduling and access phase handled at the AP level. At 1872, the AP sends DL data to each DL traffic destination, then at 1874, the AP receives ACKs from each DL traffic destination.

[0394] Then at 1876, it is checked whether the AP unicast a TXOP Proposal frame with a specified TX duration field. If the AP has unicast a TXOP Proposal frame, then execution proceeds to block 1878 where after the specified TX duration, the AP unicast another TXOP Proposal frame to the next TXOP sharing participant STA.

[0395] Block 1880 checks to determine whether there are more TXOP sharing participants. If there are more participants, then execution proceeds back to block 1878 to continue processing, otherwise processing ends.

[0396] However, if at block 1876 it is determined that the AP did not unicast a TXOP Proposal frame, then execution proceeds to block 1882 which checks to determine whether the AP has unicast TXOP Access Scheduler information to a TXOP sharing participant STA. If it is determined that the Scheduler information was unicast, then at block 1884, the AP indicates the TXOP access duration for the non-AP sharing TXOP participant STA in the TXOP Access Scheduler frame, after which processing ends.

[0397] However, if at block 1882, it is determined that the AP did not unicast a TXOP Access Scheduler frame, then execution proceeds to block 1886 which checks whether the AP has broadcast a broadcast TXOP Scheduler frame to TXOP participant STAs. If it is determined that a broadcast was made, then at block 1888, the AP indicates the TXOP access duration for each non-AP sharing TXOP participant STA in the broadcast TXOP Schedule frame, after which processing ends. Figure 53B

[0398] Otherwise, if at block 1886 it is determined that the AP did not broadcast a broadcast TXOP Scheduler frame, then execution proceeds to block 1890 which determines whether the AP received an UL data frame. If an UL data frame was received, then at 1892, the AP responds by sending an ACK frame to the source of the data frame, after which processing ends.

[0399] It should be noted that the flowchart of DL initiated TXOP scheduling and access phase handled at the non-AP sharing TXOP participant STA level is the same as in Figures 30A-30B .

[0400] 7.4. Overview of Semi-static Scenario

[0401] ​The TXOP holder STA / AP can set the configuration for TXOP sharing at a certain time by a setup procedure, and whenever it gains TXOP in the channel, the TXOP holder STA / AP shares the TXOP with a pre-set number of STAs for a pre-set duration. The STA or AP can end the TXOP sharing configuration setup at a certain time by repeating the setup procedure.

[0402] Once the TXOP sharing setup is done, whenever the TXOP holder STA / AP shares its TXOP, the sharing TXOP participants are informed by receiving RTS sharing frames or CTS sharing frames and access the channel according to the pre-set access rules.

[0403] The TXOP holder STA / AP sharing its TXOP can decide (judge) whether to propose to share each TXOP it is gaining according to the pre-set rules (leave the TXOP completely to itself).

[0404] 7.4.1. Semi-static TXOP sharing setup procedure

[0405] Figure 54 An example embodiment 1910 illustrating the semi-static TXOP sharing setup phase is depicted, in which the interaction between an AP 12, a STA1 14, a STA2 16 and a STA3 18 is depicted. Each STA can judge whether it is willing to share its TXOP and for how long (how much duration) and / or receive sharing TXOP time from other STAs for the requested amount of time. The AP forwards the information to the STAs. The STAs decide their configuration of TXOP sharing and exchange the configuration with other STAs through the AP.

[0406] In particular, the figure illustrates that STA1 generates sharing proposals / requests 1912, which are acknowledged 1914 by the AP, the AP obtains sharing proposals / requests 1916 and sends them to the non-AP stations here illustrated as STA1, STA2 and STA3. Similarly, STA3 is later represented as a TXOP holder generating sharing proposals / requests 1918, which are sent to the AP, the AP generates acknowledgements 1920 and then shares proposals / requests 1922 with the non-AP STAs.

[0407] In response to receiving the offer / request 1922, the potential TXOP holder STA (STA1 in this example) sends a share configuration frame 1924 to indicate the distribution of shared TXOP access scheduling for each TXOP participant STA assigned by the TXOP holder STA. The AP receives and acknowledges 1926 the share configuration, and then the AP broadcasts 1928 the share configuration to non-AP STAs. The process is repeated with STA3 sending 1930 a share configuration to the AP, which acknowledges 1932 the share configuration, and then the AP shares the configuration by broadcasting 1934 to other STAs. The share configuration contains the distribution of shared TXOP access time information for all non-AP STAs assigned by each potential TXOP holder STA.

[0408] 7.4.2. Semi-static TXOP sharing (UL initiated shared TXOP)

[0409] Figure 55 An example embodiment 1950 illustrating the UL initiated semi-static TXOP sharing phase is described.

[0410] The exchange of RTS share and CTS share between the sharing STAs and the AP announces the upcoming TXOP that can be shared according to the agreed configuration. This figure describes the TXOP sharing announcement 1964 by the STAs, which in this example is described by TXOP holder STA3 sending an RTS share 1952 to the AP, and the AP sending a CTS share 1954 to STA3.

[0411] Once other STAs or APs that are willing to join the following shared TXOP receive the RTS share or CTS share that indicates that the TXOP will be shared, and know that they are included in the share configuration, then these STAs and APs can determine when to access the channel and how long (duration) they should transmit during the TXOP sharing period 1966. This example describes TXOP time 1956 used by TXOP holder STA3, TXOP time 1958 used by STA1, TXOP time 1960 used by STA2, and TXOP time 1962 used by the AP.

[0412] It should be appreciated that the present disclosure can use different messages exchanged between the STAs and APs sharing their TXOP, and other STAs can receive the messages and obtain the information.

[0413] Figure 56 An example embodiment 1990 illustrating the DL initiated semi-static TXOP sharing phase is described.

[0414] The exchange of RTS Share and CTS Share between the sharing AP and the STAs announces an upcoming TXOP that can be shared according to the agreed configuration. This figure depicts TXOP Share announcement, which is illustrated with the AP sending an RTS Share 1992 to STA3, which responds by sending a CTS Share 1994 back to the AP.

[0415] Other stations willing to join the following shared TXOP receive the RTS Share or CTS Share indicating that the TXOP will be shared and know that they are included in the sharing configuration. Then, during the TXOP Share period, these STAs can determine when to access the channel and for how long. This example depicts the AP using TXOP time 1996, STA3 using TXOP time 1998, STA1 using TXOP time 2000, and STA2 using TXOP time 2002.

[0416] It should be appreciated that different message types can be utilized for the communication exchange between the AP sharing its TXOP and the other STAs, which can also receive the message and sharing information.

[0417] 7.5. Simplified UL initiated TXOP Share scheme

[0418] Figure 57A and Figure 57B An example embodiment 2030 illustrating a simplified UL initiated TXOP Share scheme is shown.

[0419] The interaction between the AP 2032, STA2 2034, STA3 2036, STA4 2038, STA5 2040 is depicted, and the NAV 2042 is shown.

[0420] The simplified TXOP Share scheme shares the TXOP duration 2031 by directly looping through all the non-AP STAs and the AP. This scheme is simple to implement since it skips the steps of identifying the sharing TXOP participant STAs and assigning to each of them a corresponding time resource.

[0421] In this example, it can be seen that STA3 is contending 2044 for the channel. Once STA3 gets channel access, it sends an RTS 2046 to the AP and receives a CTS 2048. STA3 is the sharing TXOP holder STA. STA3 sends data 2050 to the AP, which responds by sending block acknowledgement 2052. The sharing TXOP holder STA can use the sharing TXOP time as needed (the maximum TXOP duration is configuration set), and is represented as transmitting one or more data 2054 and receiving BA 2056. After completing the transmission, STA3 sends a CTS reject 2058 to the AP.

[0422] If time permits in the TXOP period, the AP cycles through the next STAs (shared TXOP participant STAs) by sending a CTS 2060 to STA4. The AP assigns a limited shared TXOP time to each shared TXOP participant STA.

[0423] In this example, it can be seen that STA4 is sending data 2062, which is acknowledged by the AP 2064, and then STA4 sends a CTS reject frame 2066 to the AP. It should be noted that a CTS reject frame is sent if: (a) a STA (e.g., STA4 as shown in this example) finishes sending earlier than the assigned shared TXOP limit; (b) a STA (e.g., STA5 as shown in this example) is close to the end of the assigned shared TXOP limit; and (c) a STA (e.g., STA2 as shown in this example) has no data to send.

[0424] After the CTS reject 2066 from STA4, the AP sends a CTS 2068 to STA5, which sends data 2070 to the AP and receives a BA 2072, and can send additional data 2074, as shown. Figure 57B The additional data 2074 is acknowledged 2076, as shown in the middle. STA5 then sends a CTS reject 2078 to the AP. The AP sends a CTS 2080 to STA2, which sends a CTS reject 2082.

[0425] Then, after cycling through a round of non-AP STAs, the AP starts DL data transmission until the current TXOP ends or until it finishes sending all DL data. It can be seen that data 2084, 2088, 2092, and 2096 are sent to STA3, STA4, STA5, and STA2, and associated block acknowledgments 2086, 2090, 2094, and 2098.

[0426] After completing the DL data transmission, if the current TXOP duration has not expired (i.e., the current TXOP duration is less than the maximum TXOP limit), the AP broadcasts a CTS-to-self (CTS to self) 2100 to clear the NAV for all STAs.

[0427] Figure 58 An example embodiment 2150 illustrating a flow diagram of a simplified shared TXOP schedule for non-AP TXOP holder STA processing.

[0428] Check 2152 determines whether a CTS is received as a response to the immediately preceding RTS frame sent to the AP. If the STA receives a CTS, it is a shared TXOP holder STA and, after successfully gaining the channel, it starts sending data to the AP at 2154. Otherwise, if no CTS is received at block 2152, another RTS is sent after a CTS timeout at block 2164, after which the process ends.

[0429] The shared TXOP holder STA can use the available TXOP duration to any extent desired (i.e., from 0 to the maximum TXOP limit). At 2156, a check is made to determine whether the shared TXOP holder STA has completed sending all its data before the maximum TXOP limit expires. If the STA has completed its data transmission before the end of the TXOP, it sends a CTS denial to the AP at 2158. Otherwise, if the STA still has more data to send, a transition is made to block 2166 and, if it determines that there is not enough time for it to send one or more data frame transmissions, it stops its data transmission, makes a transition to block 2158 to send a CTS denial to the AP.

[0430] At 2160, a check is made to determine whether DL data has been received. If DL data has been received, a response is generated in the form of an ACK or block ACK (BA) at block 2162, after which the process ends. Otherwise, if it is determined that no DL data has been received at block 2160, the process ends.

[0431] Figure 59 An example embodiment 2190 is illustrated that illustrates a simplified shared TXOP schedule for a non-AP TXOP participant STA.

[0432] Check 2192 determines whether the STA receives a CTS for the STA that is not a response to the immediately preceding RTS frame sent from the STA. If the STA does not receive a CTS, the process ends.

[0433] Otherwise, after receiving a CTS as a shared TXOP participant STA, the STA gains channel access shared by the TXOP holder STA. At 2194, a check is made to determine whether the STA has data to send. If there is no data to send, a transition is made to block 2200, the STA sends a CTS denial to the AP.

[0434] Otherwise, if there is data to send, then at 2196, the shared TXOP participant STA starts sending data to the AP and can use the available TXOP duration as assigned in the configuration. At 2198, it is checked whether the STA will complete its data transmission before the maximum TXOP expiration time. If it will complete its data transmission before the end of the TXOP, then at block 2200, a CTS refusal is sent to the AP. Otherwise, if there is not enough time to complete its next data frame transmission, it goes to block 2206 where it stops the data transmission and then goes to block 2200 to send a CTS refusal to the AP.

[0435] After the CTS refusal is sent to the AP, then at 2202, a check is made to determine whether DL data has been received. If DL data is received, then at 2204, the STA responds with some form of acknowledgement (e.g., ACK or Block ACK) and the process is complete. If at block 2202 it is determined that no DL data has been received, then the process ends.

[0436] Figures 60A-60C An example embodiment 2250 of a simplified shared TXOP schedule at the AP is illustrated.

[0437] A check 2252 determines whether an RTS has been received from a STA. If no RTS has been received, then the process ends at 1372.

[0438] Otherwise, if an RTS is received, then at block 2254, the AP responds by sending a CTS frame to the STA, which reserves the channel for the STA until the duration of the maximum TXOP. A check 2256 determines whether the AP receives a data or aggregated data frame. If a data / aggregated data frame is received, then at block 2258, the AP responds with an acknowledgement such as an ACK or Block ACK (BA) and then it goes to block 2260. Otherwise, if at block 2256, it is determined that no data / aggregated data frame is received, then execution goes directly to block 2260. Thus, regardless of whether the AP receives data / aggregated data, execution goes to block 2260 which checks whether the AP has received a CTS refusal frame.

[0439] If no CTS refusal frame is received, then a check 2262 determines whether the maximum TXOP limit has expired. If it has not expired, then execution returns to block 2260 to continue waiting for a CTS refusal. Otherwise, in the case where the maximum TXOP limit has expired, execution ends.

[0440] If at block 2260, it is determined that a CTS refusal frame is received, then this indicates that the TXOP holder has completed sending data and execution goes to block 2264 where the AP sends a CTS frame to the STA to reserve the channel for the duration of the maximum TXOP. Then at block 2266, the AP waits for data / aggregated data frames from the STA. If at block 2268, it is determined that no data / aggregated data frames are received, then at block 2270, the AP sends a CTS refusal to the STA to end the TXOP. Otherwise, if at block 2268, it is determined that data / aggregated data frames are received, then at block 2272, the AP responds with an ACK or BA and then it goes to block 2274. Figure 60BIn box 2264, the AP checks if the TXOP limit has expired. If it hasn't expired, in box 2266, the AP iterates through the next STA in the current round and sends a new CTS to that STA. This preserves the channel until the current maximum TXOP limit expires. Since the AP needs to iterate through all STAs, for each STA, it returns... Figure 60A Box 2256 in the diagram. The loop terminates when the TXOP limit is determined to have expired in box 2264.

[0441] Then, in box 2268, it is determined whether the AP has completed a cycle for all STAs in a round. If the AP has not yet completed a round, execution returns to box 2264 to again determine if the TXOP limit has expired. However, if it is determined in box 2268 that the AP has completed a cycle for the stations, execution proceeds to the next step. Figure 60C In box 2270, it is determined whether the TXOP limit has expired. If it has expired, execution proceeds to box 2276, broadcasting a CTS-to-self frame to clear the NAV.

[0442] Otherwise, if it is determined in box 2270 that the TXOP limit has not expired, then in box 2272, the AP begins DL data transmission, and then checks 2274 to determine whether all DL data transmissions have been completed. If not all DL data transmissions have been completed, a return to box 2270 is executed. Otherwise, when all transmissions are complete, in box 2276, the AP broadcasts a CTS-to-self frame to reset the NAV to 0 for all STAs, after which processing ends.

[0443] Figure 61A and Figure 61B Illustrated Example 2310 of the simplified TXOP sharing scheme initiated by DL.

[0444] The interactions between AP 2032, STA2 2034, STA3 2036, STA4 2038, and STA5 2040 are depicted, and NAV 2042 is shown.

[0445] The AP contends 2312 for the channel. Once the AP gains channel access, it sends an RTS 2314 and receives a CTS 2316 from the shared TXOP holder (STA3 in this example). The AP can use the shared TXOP time as needed (desired) for DL transmissions, up to the maximum TXOP duration configured. Data transmissions 2318, 2322, 2326, and 2330, and their respective acknowledgements 2320, 2324, 2328, and 2332 for STAs 3, 4, 5, and 2 are illustrated, respectively. After these transmissions are completed, if time permits, the AP sends a CTS 2334 to the next STA to receive UL data. In this case, STA3 receives the CTS and sends UL data 2336 to the AP, which acknowledges it with a BA 2338, and then goes to Figure 61B It can be seen that STA3 continues to send data 2340, and a BA 2342, until the transmission is completed, at which time STA3 sends a CTS reject 2344 to the AP.

[0446] The AP cycles through the next STAs by sending a CTS to the next STA (shared TXOP participant STA) if time permits. The AP assigns a limited shared TXOP time to each shared TXOP participant STA. If: (a) a STA (e.g., STA4) completes transmission earlier than the assigned shared TXOP limit; (b) a STA (e.g., STA5) is near the end of the assigned shared TXOP limit; and (c) a STA (e.g., STA2) has no data to send, the STA sends a CTS reject frame to the AP.

[0447] This example describes the AP sending a CTS 2346 to STA4, which sends UL data 2348 to the AP and receives an acknowledgement 2350, then STA4 generates a CTS reject 2352. The AP goes to another STA and sends a CTS 2354 to STA5, which sends data 2356-2360 and receives an acknowledgement 2358-2362 for each of them, after which STA5 sends a CTS reject 2364. The AP then sends a CTS 2366 to STA2, which subsequently receives a CTS reject 2388.

[0448] If time permits, after cycling through a round of non-AP STAs, the AP broadcasts a CTS-to-Self (CTS to self) 2370 to clear the NAV for all STAs if the current TXOP duration has not expired (i.e., the current TXOP duration is less than the maximum TXOP limit).

[0449] Figures 62A-62C An example embodiment 2410 illustrating a simplified shared TXOP procedure handled by the AP is shown.

[0450] In 2412, the AP sends an RTS to the destination STA. Check 2414 determines whether the AP has received a CTS as a response to the preceding RTS it sent. If this condition is not true, in box 2416, the AP retransmits the RTS after the CTS times out, and then proceeds back to box 2414.

[0451] Otherwise, if a CTS is received, check step 2418 to determine if the TXOP limit has expired. If the TXOP limit has expired, proceed to... Figure 62C In box 2448, when the available TXOP time is insufficient to send one or more data frames, data transmission is stopped. If in box 2418 it is determined that the TXOP limit has not expired, then in box 2420, the AP sends DL data to the destination STA, and then checks in box 2422 to determine whether the AP has received an ACK or BA. If no acknowledgment (e.g., ACK or BA) is received, then in box 2424, if time permits, the AP retransmits the DL data to the same destination STA. If an acknowledgment (e.g., ACK or BA) is received, arrival is processed. Figure 63 In box 2426 of B, the AP sends DL data to the next destination STA.

[0452] Check 2428 to determine if the AP has completed all DL data transmissions. If not, proceed back to the previous step. Figure 62A Box 2418 in the diagram checks if the TXOP limit has expired. Otherwise, in 2430, after all DL data transmissions are complete, the AP sends a CTS to the next STA to trigger uplink data transmission.

[0453] Check 2432 to determine if the AP has received data or an aggregated data frame. If it has received the data, in 2434, the AP responds with an acknowledgment (e.g., ACK or BA), and then proceeds to box 2436. Otherwise, if no data has been received, proceed to box 2436 to check if the AP has received a CTS rejection frame. If the AP has not received a CTS rejection frame, proceed to box 2438 to determine if the maximum TXOP limit has expired. If it has expired, the process ends. Otherwise, if the TXOP limit has not expired, return to box 2436.

[0454] If it is determined in box 2436 that a CTS rejection frame has been received, then Figure 62CThe check 2440 determines whether the TXOP limit has expired. If the TXOP limit has expired (has been reached), then execution proceeds to block 2446. If the TXOP limit has not expired, then at block 2442 the AP loops through the next STA in the current round and sends a new CTS to the STA to reserve the channel until the maximum TXOP ends.

[0455] The check 2444 determines whether the AP has completed looping through a round of STAs. If the AP has not completed, then execution returns to block 2440. If the AP has completed looping through the STAs, then at block 2446 the AP broadcasts a CTS-to-self frame to clear the NAV and then processing ends.

[0456] The flow diagram for the simplified shared TXOP scheduling by non-AP TXOP participant STAs is the same as shown in Figure 59 .

[0457] 8. Example Frame Formats

[0458] 8.1. STA TXOP Shareability Element

[0459] Figure 63 An example embodiment 2510 illustrating the STA TXOP Shareability element format. The STA TXOP Shareability element is included in a management frame such as an authentication frame or an association request frame and is used by each non-AP STA to inform the associating AP of its TXOP shareability. The element ID field identifies the element and in this case indicates that this is the STA TXOP Shareability element. If the AP receives an authentication or association request frame with the element ID field set to the STA TXOP Shareability element, the AP records all the sharing offer / request information for each STA as shown 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. The STA information field (e.g., 1-n) provides information about the STA as illustrated in Figure 64 .

[0460] Figure 64 An example embodiment 2530 illustrating the STA information field format. The fields of this structure are as follows. The AID subfield contains the AID of the STA or AP for which TXOP shareability is indicated. The TXOP share holder subfield indicates the shareability of the STA / AP as a TXOP holder.

[0461] The TXOP Share Holder subfield is set to a first state (e.g., 1) to indicate that the STA / AP operating as a TXOP holder is willing to share its TXOP with other devices. The TXOP Share Holder subfield is set to a second state (e.g., 0) to indicate that the STA / AP operating as a TXOP holder is not willing to share its TXOP with other devices. The TXOP Share Participant subfield indicates the shareability of the STA / AP as a TXOP participant.

[0462] The TXOP Share Participant subfield is set to a first state (e.g., 1) to indicate that the STA / AP operating as a shared TXOP participant is willing to join the next TXOP shared by the TXOP holder STA / AP. Otherwise, if the TXOP Share Participant subfield is set to a second state (e.g., 0), it indicates that the STA / AP operating as a shared TXOP participant is not willing to join the next TXOP shared by the TXOP holder.

[0463] 8.2. Access Request Information Element

[0464] Figure 65 An example embodiment 2550 illustrating the Access Request information element format is shown. The fields include an element ID field identifying the element, which in this example indicates that this is an Access Request information element. A length field indicates the number of octets in the element, excluding the element ID field and the length field. Allocation control fields (1-n) are shown, the subfields of one of which are illustrated in Figure 66 .

[0465] Figure 66 An example embodiment 2570 illustrating the Allocation Control subfield is shown. The Allocation Control subfield indicates the TID and the allocation type, the format of which is shown in Figure 68 . The Source AID subfield is set to the AID of the STA / AP that initiates channel access during the allocation. The Destination AID subfield is set to the AID of the STA / AP that the source STA / AP is targeting during the allocation. The Random Access Counter subfield indicates the range of time (in microseconds) that can be selected to do a random access countdown. In an example embodiment, the possible values are 1-32,767. If a STA / AP receives a frame with the Access Request Type subfield set to a random access slot allocation and the Random Access Counter subfield is not zero, the STA / AP shall randomly access the channel and transmit an Access Request frame. The Allocation Start subfield indicates the access start time of the STA / AP and contains, for example, the lower 4 octets of the TSF at the access start. For the dedicated access slot allocation type and the dedicated transmit access allocation type, the following relationship holds.

[0466] Allocation start n = Allocation start 1 + (n-1)*Allocation block duration.

[0467] Allocation start 1 : Allocation start time of the first allocation.

[0468] Allocation start n: Allocation start time of the n-th allocation.

[0469] Allocation block duration subfield indicates the duration of the time block for which access allocation is made (in microseconds). For dedicated access slot allocation type, the block duration should be small, a possible example value range is 1-32,767.

[0470] For dedicated transmit access allocation type, the block duration should be long, a possible example value range is 1-65,535.

[0471] Figure 67 An example embodiment 2590 illustrating the allocation control subfield format. The traffic identifier (TID) subfield identifies the traffic class (TC) or traffic stream (TS) for which the allocation request or grant is made. The allocation type subfield defines the access request type, possible values are listed in Table 1 under the heading Allocation Type Subfield Values. It should be appreciated that different values can be used to represent these states, as well as other states exemplified herein, without departing from the present disclosure.

[0472] The TID subfield identifies the TC or TS for which the allocation request or grant is made. The allocation type subfield defines the access request type, possible values are listed in Table 1.

[0473] 8.3. Shared Proposal / Request Frame

[0474] Figure 68 An example embodiment 2610 illustrating the shared proposal / request format. 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. The TA field contains the MAC address of the STA sending the frame. The basic service set ID (BSSID) subfield is the MAC address of the AP with which the non-AP STA is associated. If the BSSID indicates the same MAC address as the TA, it means that the shared proposal / request frame is communicating shareability information for a non-AP STA from the internal BSS; otherwise, it means that the shared proposal / request frame is communicating shareability information for a non-AP STA from an inter-BSS, the ID of which is indicated by the BSSID. One or more STA share proposal / request information fields (e.g., 1-n) are shown, which indicate the TXOP share proposal / request information for non-AP STAs / APs, as shown in Figure 69

[0475] ​Figure 69 An example embodiment 2630 illustrating the format of the sharing proposal / request information field is shown. The STA sharing proposal / request field indicates the TXOP sharing proposal / request information of the non-AP STA / AP.

[0476] The priority field indicates the priority of the traffic stored in the buffer of the STA / AP, which can be used by the TXOP holder for TXOP access scheduler design.

[0477] The STA AID is the AID of the non-AP TXOP participant STA / AP. The TXOP sharing request subfield is set to a first state (e.g., 1) means that the STA / AP with the AID indicated in the STA AID field is requesting to share the TXOP, otherwise it is set to a second state (e.g., 0). When a device receives a sharing proposal / request frame with the TXOP sharing request field set to the first state (e.g., 1), the device knows that the STA / AP with the AID indicated in the STA AID field is willing to participate in sharing the TXOP.

[0478] If the TXOP sharing proposal subfield is set to the first state (e.g., 1), it indicates that the STA / AP with the AID indicated in the STA AID field is willing to be a TXOP holder and share its TXOP with other devices, otherwise it is set to the second state (e.g., 0). When a device receives a sharing proposal / request frame with the TXOP sharing proposal field set to the first state (e.g., 1), the device knows that the STA / AP with the AID indicated in the STA AID field is willing to share its TXOP.

[0479] 8.4. RTS sharing frame and CTS sharing frame

[0480] When a non-AP TXOP holder STA / AP senses that the channel is idle (not busy) and acquires the channel, it announces its willingness to share the TXOP by sending an RTS sharing frame to the AP / destination STA. After the AP / destination STA receives the RTS sharing frame from the non-AP TXOP holder STA / AP, it responds with a CTS sharing frame to indicate successful reception and knows that the TXOP is a shared TXOP.

[0481] Figure 70An example embodiment 2650 of a RTS Share frame is illustrated. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA / CA channel access. By way of example, and not limitation, the duration field is encoded where bits 0-13 are set for a short NAV duration value, which cannot be equal to 0; bits 14-15 are set to 01, which is the code to indicate this as sharing information. If sharing information is indicated in the duration value field in this RTS Share frame, this indicates that the TXOP is shareable. Table 2 details the duration field encoding, with the underlined reserved field used by the present disclosure.

[0482] The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA sending the frame. These fields are in the MAC header.

[0483] Figure 71 An example embodiment 2670 of a CTS Share frame is illustrated. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA / CA channel access. Table 2 also provides the duration field encoding for the CTS Share frame. The RA field contains the address of the recipient of the frame. These fields are in the MAC header.

[0484] 8.5. TXOP Proposal frame

[0485] Figure 72 An example embodiment 2690 of a TXOP Proposal frame format is illustrated.

[0486] In the TXOP participant acquisition phase; the non-AP TXOP holder STA / AP broadcasts a TXOP Proposal frame to indicate that it is willing to share its TXOP and to solicit other devices willing to join the shared TXOP. Once the other devices receive the TXOP Proposal frame, they respond with a newly designed frame, the Access Request frame, to indicate their willingness to join the upcoming shared TXOP with the non-AP TXOP holder.

[0487] In the TXOP scheduling and access phase: after the TXOP holder successfully transmits the UL / DL PPDU, it unicasts a TXOP Proposal frame to the next TXOP share participant STA to indicate the transmission duration for the next TXOP share participant STA. Once the non-AP shared TXOP participant STA receives the unicast TXOP Proposal frame, it transmits UL data to the associated AP for the transmission duration. Once the AP receives the unicast TXOP Proposal frame, it transmits DL data to the destination STA for the transmission duration.

[0488] The Duration / ID field contains the AID value assigned to the STA / AP that sent the frame. The RA field is set to the address of the STA / AP that receives the frame. If the frame is broadcast, the RA field should be set to the broadcast address, which should be FF:FF:FF:FF:FF:FF. The TA field value is the address of the STA / AP that sent the frame. The Response Offset field indicates that the STA / AP should send an access request frame to the non-AP TXOP holder STA / AP within this time offset once it receives the TXOP proposal frame. The TX Duration field value indicates that once the STA / AP receives the TXOP proposal frame, it should not exceed the TX duration to complete the transmit sequence.

[0489] 8.6. Access Request Frame

[0490] Figure 73 An example embodiment 2710 of an access request frame is illustrated.

[0491] As in the previous message example, the frame control field and the Duration / ID field are shown.

[0492] The value of the RA field of the access request frame is different in two scenarios (non-AP vs. AP as coordinator) and should be set as follows. In the case of no AP coordination, the RA is set to the address of the shared TXOP holder STA / AP. In the case of AP coordination, the RA is set to the address of the associated AP.

[0493] The access priority subfield provides information about the priority of the access and is described in Figure 74 .

[0494] Figure 74 An example embodiment 2730 of the access priority subfield format is illustrated. The access category information (ACI) bitmap subfield indicates the access categories for which the buffer status is reported. Each bit of the ACI bitmap subfield is set to a first state (e.g., 1) to indicate that the buffer status for the corresponding AC is contained in the Queue Size All subfield, otherwise it is set to a second state (e.g., 0) (unless the ACI bitmap subfield is set to the second state (e.g., 0) and the Delta TID subfield is 3), it indicates the buffer status for all eight TIDs. The Delta TID subfield, used in combination with the value of the ACI bitmap subfield, indicates the number of TIDs for which the STA reports buffer status.

[0495] The Access Category Information (ACI) High subfield indicates the ACI for which the access category (AC) is indicated in the Queue Size High subfield. The Scale Factor (SF) subfield indicates the unit in SF (in octets) for the Queue Size High subfield and the Queue Size All subfield. The Queue Size High subfield indicates the amount of buffered traffic (in SF octets) for the AC identified by the ACI High subfield. The Queue Size All subfield indicates the amount of buffered traffic (in SF octets) for all ACs identified by the ACI Bitmap subfield.

[0496] 8.7. TXOP Access Scheduler frame

[0497] Figure 75 An example embodiment 2750 of a TXOP Access Scheduler frame is illustrated. The non-AP TXOP holder STA / AP unicasts a TXOP Access Scheduler frame to the non-AP shared TXOP participant STAs, indicating the TX duration for each STA. Once the STAs receive the TXOP Access Scheduler frame, they will send data to the associated AP in different time slots as indicated in the Allocation Control field in the Access Request information element embedded in the beacon frame.

[0498] The RA field is set to the address of the STA / AP receiving the frame. The TA field value is the address of the STA / AP sending the frame. The TXOP Access Allocation Information field defines TXOP allocation information for dedicated transmission access.

[0499] Figure 76 An example embodiment 2770 of a TXOP Access Allocation Information subfield format is illustrated. The TID subfield: The TID subfield identifies the TC or TS for which TXOP access allocation is made. The Allocation Type subfield defines the type of access scheduler for the TXOP, possible values are listed in Table 1 (Access Request Type subfield values), B4 and B5 are set to 1 and 0 respectively to indicate this is a dedicated transmission access allocation. The Source AID subfield is set to the AID of the STA / AP initiating channel access during the access allocation. The Destination AID subfield is set to the AID of the STA for which the source STA / AP is targeting during the allocation.

[0500] 8.8. Broadcast TXOP Scheduler frame

[0501] The non-AP TXOP holder device broadcasts a Broadcast TXOP Scheduler frame to the TXOP shared participant devices, indicating the TX duration for each shared TXOP participant device. Once the STAs receive the Broadcast TXOP Scheduler frame, they will send data to the associated AP in different time slots as indicated in the Broadcast TXOP Scheduler frame, respectively.

[0502] Figure 77 An example embodiment 2790 illustrating the broadcast TXOP schedule frame format. As in the previous message example, the frame control field and duration / ID field are shown. The RA field is set to the address of the recipient STA that is to receive the frame. The TA field contains the address of the STA that sent the frame. One or more STA TXOP schedules (e.g., 1-n) are seen, which contain the TXOP schedule, and have Figure 78 The subfields shown.

[0503] Figure 78 An example embodiment 2810 illustrating the STA TXOP schedule field format. The allocation control subfield indicates the TID and allocation type, as shown in Figure 79 The source AID subfield is set to the AID of the STA / AP that initiated channel access during the allocation. The destination AID subfield is set to the AID of the STA / AP that the source STA / AP is targeting during the allocation. The allocation start subfield indicates the start time of the access, and contains, for example, the lower 4 octets of the TSF at the start of the access. For the dedicated transmit access allocation type defined in the allocation control subfield format, the following relationship holds.

[0504] Allocation start n = Allocation start 1 + (n-1)*allocation block duration.

[0505] Allocation start 1 : Allocation start time of the first STA TXOP schedule.

[0506] Allocation start n: Allocation start time of the n-th STA TXOP schedule.

[0507] The allocation block duration subfield indicates the duration of the time block for which the access allocation is made (in microseconds).

[0508] For the dedicated access slot allocation type, the block duration should be small, with a possible value range of 1-32,767, by way of example and not limitation. For the dedicated transmit access allocation type, the block duration should be large (e.g., double in size), for example, with a possible value range of 1-65,535.

[0509] Figure 79 An example embodiment 2830 illustrating the allocation control subfield format indicating the TID and allocation type.

[0510] 8.9. Shared TXOP participant announcement frame

[0511] Figure 80An example embodiment 2850 illustrating the Shared TXOP Participants Announce frame format is shown. As in the previous message examples, the frame control field and duration / ID field are shown, as well as the RA and TA fields, such as previously described. A field for one or more STA TXOP Participants is included, this example showing 1-n Participants. Subfields within the Participants field are shown Figure 81 .

[0512] Figure 81 An example embodiment 2870 illustrating the STA TXOP Participants field format is shown. The Source AID subfield is set to the AID of the STA that initiated channel access during the allocation. The Destination AID subfield is set to the AID of the STA that the source STA is targeting during the allocation. The ACI bitmap subfield indicates the access categories for which buffer status is reported. The Delta TID subfield is used in conjunction with the value of the ACI bitmap subfield to indicate the number of TIDs for which buffer status is reported by the STA.

[0513] The Access Category Information (ACI) High subfield indicates the ACI of the access category (AC) for which the queue size high subfield indicates an access request frame. The Scale Factor (SF) subfield indicates the unit SF (in octets) of the queue size high subfield and the queue size all subfield. The Queue Size High subfield indicates the amount of buffered traffic (in SF octets) for the AC identified by the ACI High subfield. The Queue Size All subfield indicates the amount of buffered traffic (in SF octets) for all ACs identified by the ACI bitmap subfield.

[0514] 8.10. Request TXOP Proposal frame

[0515] After the non-AP TXOP holder STA transmits data to the associated AP, it also transmits a Request TXOP Proposal frame to the associated AP, the Request TXOP Proposal frame indicating the start of shared TXOP access for the next TXOP shared participant STA. After receiving the Request TXOP Proposal frame, the AP unicasts a TXOP Proposal frame to the next TXOP shared participant STA and indicates the TX duration for the next STA.

[0516] Figure 82 An example embodiment 2890 illustrating the Request TXOP Proposal frame format is shown. As in the previous message examples, the frame control field, duration / ID field, RA and TA fields are shown. The duration / ID field indicates the AID of the STA to which the AP should transmit a TXOP Proposal frame, while the TX duration field indicates the maximum transmit duration to the next STA.

[0517] 8.11. Request TXOP Access Scheduler frame

[0518] Before a non-AP TXOP holder transmits data to an associated AP, it first transmits a request TXOP access scheduler frame to the AP, which indicates shared TXOP access for all other non-AP shared TXOP participant STAs. Upon receiving the request TXOP access scheduler frame, the AP unicasts a TXOP access scheduler frame to each of the non-AP shared TXOP participant STAs, indicating their TX duration, or broadcasts a broadcast TXOP scheduler frame to all non-AP shared TXOP participant STAs, indicating their TX duration.

[0519] Figure 83 An example embodiment 2910 illustrating the format of a request TXOP access scheduler frame is shown. As in the previous message examples, the frame control field, duration field, RA field, and TA field are shown. At least one STA TXOP access request field is included, this example showing TXOP access requests 1-n. The subfields within the TXOP access request field are described in Figure 85

[0520] Figure 84 An example embodiment 2930 illustrating the format of a TA TXOP access request field is shown. The allocation control field indicates the number of slots requested. The source AID subfield is set to the AID of the STA initiating channel access during the allocation. The destination AID subfield is set to the AID of the STA for which the source STA is targeting during the allocation. The allocation start subfield indicates the start time of the access, and in at least one embodiment, it contains the lower 4 octets of the TSF at the start of the access. For the dedicated transmit access allocation type defined in the allocation control subfield format, the following relationship holds.

[0521] Allocation Start n = Allocation Start 1 + (n-1)*Allocation Block Duration.

[0522] Allocation Start 1 : Allocation start time for the first allocation.

[0523] Allocation Start n : Allocation start time for the nth allocation.

[0524] The allocation block duration subfield indicates the duration of the time block for which the access allocation is made (in microseconds). For the dedicated access slot allocation type, a block duration of 1-32,767 is exemplified here. For the dedicated transmit access allocation type, the block duration should be larger, such as exemplified by a possible value of 1-65,535.

[0525] Figure 85 ​Figure illustrates an example embodiment 2950 of allocation control subfield format with TID subfield and allocation type subfield.

[0526] 8.12. Sharing Proposal / Request frame

[0527] Figure 86 Figure illustrates an example embodiment 2970 of sharing proposal / request frame format. As in some of the previous message examples, the sharing proposal / request frame has a frame control field, duration / ID field, RA field, and TA field. The sharing proposal / request field indicates the non-AP STA's TXOP sharing proposal / request information, and is described in Figure 88

[0528] Figure 87 Figure illustrates an example embodiment 2990 of sharing proposal / request information field format. The priority field indicates the priority of the traffic stored in the STA's buffer, which can be used by the TXOP holder for TXOP access scheduler. The TXOP sharing request is set to a first state (e.g., 1) to indicate that the STA is requesting to share TXOP time; otherwise, the TXOP sharing request 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 the first state, the AP knows (can decide) that the STA sending the frame is willing to participate in sharing TXOP. The TXOP duration request indicates the amount of time (in microseconds) that the STA is requesting in the shared TXOP. The AP will broadcast this information in the sharing proposal / request frame. The TXOP sharing proposal value is set to a first state (e.g., 1) to indicate that the STA is willing to be a TXOP holder and share its 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 the first state, the AP knows that the STA sending the frame is willing to share TXOP with other STAs. The TXOP duration proposal subfield indicates the amount of time (in microseconds) that the TXOP holder STA is willing to share with other STAs, which the AP will broadcast in the sharing proposal / request frame.

[0529] 8.13. Sharing Proposal / Request frame

[0530] The AP broadcasts a sharing proposal / request frame to all STAs, with for each STA a specific STA sharing proposal / request field designed for each STA, which indicates the specific STA and AP's TXOP sharing / request information.

[0531] Figure 88 ​An example embodiment 3010 illustrating the format of the Share Proposal / Request frame is shown. As in some of the previous message examples, the Share Proposal / Request frame has a Frame Control field, Duration field, RA field, and TA field. Multiple STA Share Proposals / Requests can be included in the frame, shown here as STA Share / Request 1 through N. The format of the STA Share Proposal / Request is shown in Figure 89 .

[0532] Figure 89 An example embodiment 3030 illustrating the format of the STA Share Proposal / Request Information field is shown. The Priority field indicates the priority of the traffic stored in the buffer of the STA / AP, which can be used by the TXOP holder for TXOP access scheduler design. The STA Address is the MAC address of the TXOP participant STA / AP, which can be used by the TXOP holder to assign TXOP access start time and duration for a specific STA / AP. The STA AID is the AID of the TXOP participant STA / AP. The remaining TXOP Share Request field, TXOP Duration Request field, TXOP Share Proposal field, and TX Duration Proposal field are described in Figure 86 .

[0533] 8.14. Share Configuration Frame

[0534] Figure 90 An example embodiment 3050 illustrating the format of the Share Configuration frame is shown. As in some of the previous message examples, the Share Configuration frame has a Frame Control field, Duration field, RA field, and TA field. The TXOP Share Proposal field indicates the total TXOP duration that the TXOP holder STA is willing to share with other STAs and APs. The STA TXOP Access Allocation field indicates the TXOP access start time and duration for each specific STA and AP; this example shows n fields. After the AP receives the Share Configuration frame, the AP will record the STA TXOP Access Allocation information and broadcast it using the Share Configuration frame as shown in Figure 93 .

[0535] Figure 91 An example embodiment 3070 illustrating the format of the STA TXOP Access Allocation field is shown.

[0536] The STA Address field indicates the MAC address of the TXOP holder. This information will be used by the AP to set the TXOP Holder MAC Address in the Share Configuration frame as shown in Figure 94 . The Participant Address indicates the MAC address of the TXOP participant. This information will be used by the AP to set the TXOP Participant MAC Address in the Share Configuration frame as shown in Figure 94The participant address subfield in the STA configuration field. The allocation start field indicates the start time of the TXOP transmission by the participant STA or AP. The allocation block duration field indicates the duration of the TXOP transmission by the participant STA or AP.

[0537] Figure 92 An example embodiment 3090 illustrating the allocation control subfield format is shown with a priority field and a reserved field.

[0538] 8.15. Shared Configuration Frame

[0539] Figure 93 An example embodiment 3110 illustrating the shared configuration frame format is shown. The AP broadcasts the shared configuration frame to all STAs, where the configuration of each STA and AP is indicated in the STA configuration field. As in some of the previous message examples, the shared configuration frame has a frame control field, a duration field, a RA field, and a TA field. The frame contains one or more configurations for specific stations depicted as STAl ~ STAn. The STA configuration subfield is described in Figure 94

[0540] Figure 94 An example embodiment 3130 illustrating the STA configuration field format is shown.

[0541] The TXOP holder MAC address indicates the MAC address of the TXOP holder STA or AP. For any TXOP holder STA: upon receiving the CTS shared frame, the STA maps the RA information indicated in the CTS shared frame with the TXOP holder MAC address information. Thus, the STA can know the TXOP holder and hence gain access to the corresponding STA configuration information.

[0542] One or more STA TXOP access allocation fields (e.g., 1 ~ n) are the same as defined in Figure 90 For non-TXOP holder STAs: upon mapping to a specific STA configuration field, the STA maps its MAC address with the participant address subfield to further gain the TXOP access start (as indicated in the allocation start subfield) and duration (as indicated in the allocation block duration subfield) information scheduled for it.

[0543] 8.16. CTS Reject Frame and CTS-To-Self (CTS to self) Frame

[0544] Figure 95 An example embodiment 3150 illustrating the frame format for the CTS reject frame, CTS-To-Self (CTS to self) frame, and CTS frame is shown.

[0545] ​When used as a CTS reject frame in the simplified shared TXOP scheme, the non-AP STA sends a CTS reject frame to the AP to indicate that it has finished data transmission or that it has no data to transmit. After receiving the CTS reject frame, the AP will cycle through the next STA by sending a new CTS frame to the next STA. In the CTS reject frame, the duration field is the time needed to send the CTS frame plus a SIFS in microseconds, and the RA field is set to the MAC address of the AP.

[0546] As a CTS-to-Self frame in the simplified shared TXOP scheme, the AP broadcasts a CTS-to-Self frame after it finishes the cycle through all UL and DL transmissions before the current maximum TXOP expires. After receiving the CTS-to-Self frame, the non-AP STA resets the NAV to 0 and starts channel access after a random backoff. The CTS-to-Self frame has a duration field and a RA field, the duration field is set to the time needed to send the CTS-to-Self frame plus a SIFS in microseconds, and the RA field is equal to the transmitter's MAC address, which is the MAC address of the AP in the simplified shared TXOP scheme. After receiving the CTS-to-Self frame, the non-AP STA resets the NAV to 0 and starts channel access after a random backoff.

[0547] As a CTS frame in the simplified shared TXOP scheme, the AP sends a CTS frame to cycle through all non-AP STAs, which indicates the start of the shared TXOP slot for the non-AP STAs. After receiving the CTS frame, the non-AP STAs should start UL data transmission. In the CTS frame, the duration field is set to the time of the end of the current maximum TXOP limit, and the RA field is equal to the MAC address of the next non-AP STA that the AP cycles through.

[0548] 9. General scope of implementation

[0549] The enhancements described in the present technology can be readily implemented within a variety of wireless network communication stations. It should also be appreciated that a wireless network communication station is preferably implemented to include one or more computer processor devices (e.g., CPUs, microprocessors, microcontrollers, computer-enabled ASICs, etc.) and associated memory (e.g., RAM, DRAM, NVRAM, FLASH, computer-readable media, etc.) storing instructions, such that the programming (instructions) stored in the memory are executed on the processor to perform the steps of the various processing methods described herein.

[0550] It should also be appreciated that the computer readable medium (memory) of the computing system in these embodiments is "non-transitory" in that it includes all forms of computer readable medium excluding only transitory propagating signals. Accordingly, the disclosed technology can include any form of computer readable medium, including those that are random access (e.g., RAM), those that require periodic refreshing (e.g., DRAM), those that degrade over time (e.g., EEPROM, disk media), or those that store data only for short periods of time and / or only when power is present, with the sole exception being transitory propagating signals.

[0551] Embodiments of the technology can be illustrated herein with reference to flow charts of methods and systems in accordance with embodiments of the technology, and / or can also be implemented as processes, algorithms, steps, operations, formulas, or other computational descriptions in a computer program product. In this regard, each block or step of a flow chart, and combinations of blocks (and / or steps) in a flow chart, and any process, algorithm, step, operation, formula, or computational description herein can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied on computer-readable program code logic. As will be appreciated, any such computer program instructions can be executed by one or more computer processors (including without limitation a general purpose computer or special purpose computer) or other programmable processing apparatus to produce a machine, such that the computer program instructions which, when executed by the computer processor(s) or other programmable processing apparatus, create means for implementing the functions specified.

[0552] Accordingly, the blocks of the flow charts, and processes, algorithms, steps, operations, formulas, or computational descriptions herein support combinations thereof for performing the specified functions, combinations of steps for performing the specified functions, and computer program instructions (such as embodied on computer-readable program code logic) for performing the specified functions. It should also be understood that each block of the flow charts, and any processes, algorithms, steps, operations, formulas, or computational descriptions herein, and combinations thereof, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer-readable program code.

[0553] Moreover, these computer program instructions (such as embodied in computer-readable program code) can also be stored in one or more computer-readable memory or storage devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or storage devices produce an article of manufacture including instructions which implement the function specified in the block(s) of the flowchart(s). The computer program instructions can also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus, thereby producing a computer-implemented process such that the instructions executed by the computer processor or other programmable processing apparatus provide steps for implementing the function specified in the block(s) of the flowchart(s), algorithm(s), procedure(s), step(s), operation(s), formula(s), or computational description(s).

[0554] It should also be appreciated that the term "program" or "executable program" as used herein refers to one or more instructions that can be executed by one or more computer processors to perform one or more functions described herein. The instructions can be embodied in software, firmware, or a combination of software and firmware. The instructions can be stored locally on a device in non-transitory media, or can be stored remotely, such as on a server, or the instructions can be stored in whole or in part locally and remotely. The remotely stored instructions can be downloaded (pushed) to the device by a user initiating the download, or automatically downloaded (pushed) to the device based on one or more factors.

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

[0556] From the description herein, it should be appreciated that the disclosure encompasses a variety of implementations of the technology, including but not limited to the following implementations:

[0557] The disclosure describes, in its most general sense, how any non-AP STA or AP that obtains a TXOP in a wireless LAN network can be able to share its TXOP with other STAs in the same BSS; the TXOP can be shared among UL and DL transmissions in the time domain.

[0558] Different solutions are provided to achieve this performance in different scenarios, which can be classified as follows:

[0559] Dynamic scenarios: (a) In UL initiated sharing scheme, no AP as coordinator for scheduling; (b) In UL initiated sharing scheme or DL initiated sharing scheme, AP as coordinator for scheduling.

[0560] Semi-static scenarios as UL or DL initiated sharing scheme.

[0561] Simplified scenarios as UL or DL initiated sharing scheme.

[0562] In UL initiated dynamic scenarios: Different conditions are considered, including or not including AP as coordinator; AP's shareability information should also be exchanged with other non-AP STAs; AP should also respond to TXOP holder if it has been queried for sharing TXOP participation; TXOP holder STA should also assign corresponding time for DL transmission to AP if AP also requests time for DL transmission in the shared TXOP; and AP should send DL data to destination STAs in the assigned time slots for the specified duration during the shared TXOP.

[0563] In DL initiated dynamic scenarios: AP is TXOP holder and operates as coordinator.

[0564] APs in wireless LAN networks obtain TXOP and share their TXOP with other non-AP STAs in the same BSS by sharing the TXOP among DL and UL transmissions by performing the following steps: exchanging shareability information between AP and non-AP STAs to inform and / or grant the AP to share the TXOP with non-AP STAs; when gaining access to the channel, the AP announces its willingness to share the TXOP by broadcasting a message to other non-AP STAs; the AP receives messages from other STAs to learn (determine) which STAs are requesting time in the TXOP; the AP broadcasts shareability information of all TXOP participants; and the AP queries non-AP STAs to learn (determine) which STAs are requesting time in the TXOP and assigns corresponding time slots for them.

[0565] APs and STAs exchange TXOP shareability and TXOP access time assignments through the exchange of management frames such as authentication request / response frames, association request / response frames, and beacon frames.

[0566] RTS sharing frames and CTS sharing frames are implemented to indicate that the upcoming TXOP can be shared.

[0567] The AP receives an access request frame from a STA indicating that the STA is requesting time in a shared TXOP; wherein the access request sent from a STA requesting a shared TXOP can be sent over a random access channel in a predefined time slot or in a dedicated time slot; alternatively or additionally, the AP can poll the STAs for their response.

[0568] The AP sends DL data to each destination STA for a specified duration; once the DL transmission is complete, the AP sends a TXOP access scheduler frame (such as a TXOP proposal frame, a TXOP access scheduler frame, and a broadcast TXOP scheduler frame) to the STAs; in accordance with the schedule, the other STAs send UL data to the AP at the scheduled time and for a specified duration.

[0569] In a semi-static scenario, the TXOP holder (STA or AP) can decide semi-statically the participants of the shared TXOP and the duration and order of access by exchanging messages with the shared TXOP participants accessing its TXOP; the TXOP holder (STA or AP) runs a setup procedure to set up the semi-static configuration; the TXOP holder (STA or AP) exchanges sharing / request information with other shared TXOP participants through the AP; the TXOP holder (STA or AP) exchanges configuration information with all shared TXOP participants through the AP regarding the semi-static TXOP sharing schedule;

[0570] The TXOP holder (STA or AP) that shares its TXOP with other devices follows the announced allocation schedule.

[0571] The TXOP holder (STA or AP) assigns some time to the STAs sharing its TXOP, when detecting the TXOP, the device starts using the TXOP at the announced time and for the announced duration.

[0572] In a simplified scenario, the AP can cycle through all non-AP STAs following a simplified shared TXOP scheme, sharing the TXOP in between UL and DL transmissions and initiating channel access.

[0573] For UL initiated case: non-AP TXOP holder STAs pre-empt (get) the channel and use shared TXOP as needed; after non-AP TXOP holder STAs finish data transmission, AP loops (sequentially) through the rest of non-AP STAs and starts shared TXOP slots for each of them; after looping through a round of non-STAs, AP starts DL transmission if TXOP time allows; if AP finishes its DL transmission, or if TXOP time expires, AP broadcasts CTS-to-Self frame to clear channel reservation for all non-AP STAs, in which case a new shared TXOP procedure can start.

[0574] For DL initiated case: AP pre-empts the channel and uses shared TXOP for DL transmission as needed; after AP finishes its DL transmission, AP loops (sequentially) through non-AP STAs and starts shared TXOP slots for each of them for UL transmission if time allows; after looping through a round of non-STAs, or if TXOP time expires, AP broadcasts CTS-to-Self frame to clear channel reservation for all non-AP STAs. In this case, a new shared TXOP procedure can start; and shared TXOP slots are pre-configured.

[0575] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) over at least one channel as a wireless station (STA); (b) a processor coupled within the station to the wireless communication circuitry, the station configured for operating on the WLAN as a station configured to support communicating using a shared transmit opportunity (TXOP) protocol; (c) a non-transitory memory storing instructions executable by the processor for execution by a STA in a same basic service set (BSS); and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) obtaining access to a channel and communicating that an upcoming TXOP is available for sharing by broadcasting a message to other STAs in the BSS from a STA that can be an AP STA or a non-AP STA that is a TXOP holder, or by communicating to an AP that the STA that is a TXOP holder is willing to share the TXOP with other STAs, and the STA operating as an AP also broadcasting the message on behalf of the STA that is a TXOP holder; (d)(ii) the STA operating as a non-AP STA or an AP STA sharing the TXOP with other stations in the same BSS on the network; d(iii) wherein the sharing of the TXOP is for both uplink (UL) physical layer protocol data unit (PPDU) transmissions and downlink (DL) PPDU transmissions in time domain; and (d)(iv) sending a message from the TXOP holder, or through the AP when the AP is not the TXOP holder, to STAs that will share the TXOP with the STA to inform them of the time and duration of channel access for the upcoming TXOP being shared.

[0576] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) over at least one channel as a wireless station (STA); (b) a processor coupled to the wireless communication circuitry within a station configured for operation as a station on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for execution by STAs in a same basic service set (BSS); and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) sending a message indicating a capability to share a transmit opportunity (TXOP); (d)(ii) sending a frame from an access point (AP) STA that has obtained a TXOP to a non-AP STA indicating an allocated portion of time within the obtained TXOP to be shared with the non-AP STA; (d)(iii) wherein a station configured to operate as the non-AP STA sends a PPDU in the time allocated to the station within the frame to be shared; (d)(iv) wherein the non-AP STA receives a frame addressed to it from its associated AP and sends one or more non-trigger-based (non-TB) PPDUs within the allocated shared TXOP duration indicated in the frame while ensuring that the non-AP STA's physical layer protocol data unit (PPDU) transmissions and any expected responses can be completed entirely within the allocated time; (d)(v) if the non-AP STA requests an acknowledgement (ACK), the AP STA responds to the non-AP STA's sent PPDUs with an ACK; and (d)(vi) if the AP STA has PPDUs to send, the AP STA sends one or more PPDUs after the end of the allocated time and before the obtained TXOP NAV expires.

[0577] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) in its reception area over at least one channel as a wireless station (STA); (b) a processor coupled to the wireless communication circuitry within the station configured for operating on the WLAN as a station configured to support communicating using a shared transmission opportunity (TXOP) protocol; (c) a non-transitory memory storing instructions executable by the processor for the STA; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) wherein the STA operates as an AP STA of a BSS; (d)(ii) exchanging shareability information with non-AP STAs on the network for the BSS and broadcasting the obtained shareability information on the network for the BSS; (d)(iii) obtaining access to a channel and becoming a TXOP holder as the AP STA; (d)(iv) announcing to non-AP STAs that the TXOP is available for sharing; (d)(v) receiving messages from other STAs requesting to share the TXOP; (d)(vi) transmitting DL data to destination STAs using the obtained TXOP; and (d)(vii) broadcasting shareability information to all TXOP sharing participants and assigning time slots and durations for each TXOP sharing participant when the shared TXOP time allows.

[0578] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) over at least one channel as a wireless station (STA); (b) a processor coupled within the station to the wireless communication circuitry, the station configured for operating on the WLAN as a station configured to support communication using a shared transmission opportunity (TXOP) protocol; (c) a non-transitory memory storing instructions executable by the processor for the STA; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) wherein the STA operating as an AP STA or a non-AP STA has acquired a TXOP as a TXOP holder; (d)(ii) the TXOP holder determines sharing TXOP participants to access its TXOP and assigns time slots and durations to the sharing TXOP participants in a semi-static manner by exchanging messages with these participants via coordination by the AP; and (d)(ii) the STA performs a setup procedure to set up a semi-static configuration: (A) the STA exchanges sharing / request information with other STAs via the AP STA; then (B) the STA performs a semi-static sharing TXOP schedule and exchanges the schedule configuration with all other STAs via the AP STA.

[0579] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) over at least one channel as a wireless station (STA) operating as an AP STA within its basic service set (BSS); (b) a processor, coupled to the wireless communication circuit within the station, configured for operating as a station configured to support communication using a shared transmit opportunity (TXOP) protocol on the WLAN. A non-AP TXOP holder STA obtains channel access and is configured to use shared TXOP time as needed for UL data transmission and causes the AP STA to sequentially iterate through all non-AP STAs and share TXOP among uplink (UL) data transmission and downlink (DL) data transmission and initiate channel access in accordance with a simplified shared TXOP scheme; (c) wherein a STA operating as a non-AP STA sends a message to the AP after it completes UL transmission and indicates that the AP STA can iterate through the next non-AP STA; (d) a non-transitory memory storing instructions executable by the processor for the STA; and (e) wherein the instructions, when executed by the processor, perform steps comprising: (e)(i) detecting that a non-AP TXOP has completed its use of the TXOP; (e)(ii) the AP STA sequentially iterating through remaining non-AP STAs and providing at least one shared TXOP slot for UL transmission for each of them; (e)(iii) determining that sufficient TXOP time remains, wherein the AP STA begins DL transmission to non-AP STAs on the network; and (e)(iv) after the AP STA completes DL transmission, or if TXOP time expires, the AP STA broadcasts a CTS-To-Self (CTS-to-self) frame to clear the channel reservation for all non-AP STAs, whereby a new TXOP procedure can begin.

[0580] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit configured for wireless communication with other wireless stations (STAs) on a local area network (WLAN) in its reception area over at least one channel as a wireless station (STA) operating as an AP STA within its basic service set (BSS); (b) a processor coupled to the wireless communication circuit within the station configured for operating as a station configured to support communication using a shared transmit opportunity (TXOP) protocol on the WLAN, and causing the AP STA to sequentially iterate through all non-AP STAs and share TXOPs and initiate channel access among uplink (UL) data transmissions and downlink (DL) data transmissions in accordance with a simplified shared TXOP scheme; (c) a non-transitory memory storing instructions executable by the processor for the STA; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) the AP STA obtaining a channel and sending a DL physical layer protocol data unit (PPDU) using the obtained TXOP, the AP STA as a TXOP holder being configured to use the obtained TXOP time as needed for it to send DL transmissions; (d)(ii) completing its DL transmissions and determining that there is enough time left in the TXOP to start sharing the TXOP with non-AP STAs; (d)(iii) the AP STA iterating through the non-AP STAs sharing at least one TXOP slot for UL transmissions for each of them; (d)(iv) upon completing one iteration of the sequence of sharing with non-AP STAs, or if the TXOP time expires, the AP broadcasting a CTS-To-Self (CTS-to-self) frame to clear the channel reservation for all non-AP STAs, whereby a new shared TXOP procedure can start.

[0581] The apparatus of any of the foregoing implementations, wherein the STAs exchange information of TXOP sharing capabilities by exchanging management frames with STAs operating as AP STAs or non-AP STAs on the network.

[0582] The apparatus of any of the foregoing implementations, wherein the selected management frames are selected from a group of frames consisting of authentication request frames, authentication response frames, association request frames, association response frames, and beacon frames.

[0583] The apparatus of any of the preceding implementations, wherein the STA has a communication range based on a type of the STA: (i) if the STA is a non-AP STA, the communication range is not able to cover all other STAs in a same basic service set (BSS), the STA is able to communicate with other non-AP STAs under coordination of an AP STA, or can directly communicate with other non-AP STAs if the other non-AP STAs are within the communication range of the STA; and (ii) if the STA is an AP STA, the communication range covers all other STAs in a same basic service set (BSS).

[0584] The apparatus of any of the preceding implementations, further comprising exchanging messages with other STAs in the BSS directly or indirectly through an associated AP upon determining a STA that is a non-AP STA or an AP STA in the BSS is requesting time in an upcoming TXOP that can be used for sharing.

[0585] The apparatus of any of the preceding implementations, wherein the UL transmission in time domain comprises a dynamic scenario for scheduling UL initiated and TXOP sharing with AP coordination.

[0586] The apparatus of any of the preceding implementations, wherein a STA operating as an AP STA performs steps comprising: receiving a message from a non-AP STA on the network indicating sharing offer / request information; exchanging the obtained sharing offer / request information with other non-AP STAs on the network; sending a response after receiving a frame indicating that a non-AP STA has obtained a TXOP and started sharing; sending an inquiry message on behalf of the TXOP holder to identify non-AP STAs requesting to join an upcoming shared TXOP; collecting requests from non-AP STAs to join an upcoming shared TXOP on behalf of the TXOP holder; and sending the collected sharing request information to the STA operating as the TXOP holder; receiving a frame from the TXOP holder indicating an assigned time and duration for STAs requesting to join an upcoming shared TXOP; sharing a portion of the obtained TXOP time with other non-AP STAs on behalf of the TXOP holder STA by sending a frame indicating an assigned start time and duration for each or all sharing non-AP STAs; receiving an assigned start time and duration for TXOP sharing from the TXOP holder if the STA operating as an AP STA has requested to participate in the shared TXOP for DL transmission; and sending a downlink (DL) PPDU to destination STAs on the network within the assigned shared TXOP duration assigned by the TXOP holder STA.

[0587] The apparatus of any of the preceding implementations, wherein the UL transmission in time domain comprises a dynamic scenario for scheduling UL initiated and AP coordination free TXOP sharing.

[0588] The apparatus of any of the preceding implementations, wherein the STA operating as a non-AP STA performs the steps comprising: sending a frame to an associated AP to gain a channel if the non-AP STA detects the medium is idle based on a carrier sense (CS) mechanism; and indicating in the sent frame that the channel access attempt is to gain a shared TXOP; receiving a response from the associated AP indicating successful reception of the previously sent frame and indicating that the non-AP STA has gained a TXOP and can start using the shared TXOP; sending a query message to identify other STAs requesting to join the upcoming shared TXOP if the non-AP STA is operating as a TXOP holder; sending a message containing a request to join the upcoming shared TXOP if the STA is not operating as a TXOP holder; collecting requests from other STAs to join the upcoming shared TXOP if the non-AP STA is operating as a TXOP holder; and allocating time and duration to shared STAs requesting to join a portion of the gained TXOP time; sending a frame to each or all shared non-AP STAs indicating the allocated start time and duration; receiving an allocated start time and duration for TXOP sharing from the TXOP holder if the non-AP STA is not a TXOP holder and has requested to participate in the shared TXOP for UL transmission; and sending UL PPDUs to associated APs on the network within the allocated shared TXOP duration assigned by the TXOP holder STA.

[0589] The apparatus of any of the preceding implementations, wherein the UL transmission and DL transmission in time domain comprises a semi-static scenario with an AP STA as a coordinator when scheduling UL initiated or DL initiated TXOP sharing.

[0590] The apparatus of any of the preceding implementations, wherein the UL transmission and DL transmission in time domain comprises a simplified scenario when starting UL initiated or DL initiated TXOP sharing, wherein a STA operating as an AP does not identify shared TXOP participants but sequentially goes through all STAs one by one for participation.

[0591] The apparatus of any of the preceding implementations, wherein the STA exchanges information of TXOP sharing proposal / request capabilities and TXOP access time allocation by exchanging management frames with STAs operating as AP STAs or non-AP STAs on the network.

[0592] The apparatus of any of the preceding implementations, wherein the management frame is selected from a group of frames consisting of an authentication request frame, an authentication response frame, an association request frame, an association response frame, and a beacon frame.

[0593] The apparatus of any of the preceding implementations, wherein the RTS sharing frame and the CTS sharing frame comprise modified ready-to-send (RTS) frames and clear-to-send (CTS) frames containing information fields indicating that the obtained TXOP will be shared and the start of sharing the TXOP.

[0594] The apparatus of any of the preceding implementations, wherein the exchange of messages by which the other STAs are requesting access time in the upcoming TXOP can be sent by randomly accessing the at least one channel in a predefined time slot time or in a dedicated time slot.

[0595] The apparatus of any of the preceding implementations, wherein the STA that is the TXOP holder, when operating as an AP STA, can poll non-AP STAs to determine whether they are requesting time in the upcoming TXOP.

[0596] The apparatus of any of the preceding implementations, wherein the STA that is the TXOP holder, when operating as a non-AP STA, can poll non-AP STAs, by itself or by coordination of an AP STA, to determine whether they are requesting transmission time in the upcoming TXOP.

[0597] The apparatus of any of the preceding implementations, wherein the shared TXOP holder STAs, which can be AP STAs or non-AP STAs, send shared TXOP access scheduler frames to the STAs that are requesting time in the upcoming TXOP, with or without coordination of an AP STA, in response to which these STAs will send UL data to the AP STA or DL data to non-AP STAs at the scheduled time and for a specified duration.

[0598] The apparatus of any of the preceding implementations, wherein the TXOP access scheduler frame is selected from a group of message frames consisting of a TXOP proposal frame, a TXOP access scheduler frame, and a broadcast TXOP scheduler frame.

[0599] The apparatus of any of the preceding implementations, wherein the TXOP holder shares its TXOP with other STAs on the network in accordance with an announced resource (channel access) allocation schedule, which is configured in a setup procedure.

[0600] The apparatus of any of the preceding implementations, wherein the shared TXOP participant is configured to detect a start of a TXOP and begin using the shared TXOP at an assigned time slot and duration.

[0601] The apparatus of any of the preceding implementations, wherein the shared TXOP time slot is preconfigured.

[0602] It should also be noted that each of the apparatus implementations described above can also be stated in the context of a computer-implemented protocol for wireless communication between stations (STAs) on a network.

[0603] The term "implementation", as used herein, is intended to encompass, without limitation, embodiments, examples, protocols, or other forms of the technology described herein.

[0604] As used herein, the singular forms "a", "an" and "the" are intended to include plural objects, unless the context clearly indicates otherwise. The use of the singular form of a reference to an object does not necessarily mean "one and only one", but rather "one or more" unless expressly stated otherwise.

[0605] The phraseology "A, B, and / or C", as used in the present disclosure, indicates that there can be A, B, or C, or any combination of items A, B, and C. The phraseology "at least one of...", as used in the present disclosure, indicates that there can be at least one of the items, and includes any possible combination of the listed items.

[0606] References within the present disclosure to "an embodiment", "at least one embodiment", or similar language indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation of the disclosure. The various implementations of the disclosure, therefore, can have a different combination of the described features, structures, or characteristics, not specifically recited in the description and not necessarily appearing in the claims. Embodiment language should be interpreted to be broad enough to encompass a combination of the described features, structures, or characteristics, even if such a combination is not recited in the description or specifically appears in the claims.

[0607] The term "set", as used herein, refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[0608] Relative terms such as first and second, top and bottom, and the like can be used herein for ease of reference only and do not necessarily have to imply any actual relationship or order between things so described.

[0609] The terms "comprise," "comprising," "include," "including," "contain," "containing," "have," "having," "maintain," "maintaining," "preserve," "preserving," "consist," "consisting," "consisting essentially of," or any variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprises... a," "has... a," "includes... a," or "contains... a" does not, without a more particular recitation, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, or contains that element.

[0610] The terms "approximately," "about," "substantially," "essentially," and "around," or any other version thereof, as used herein are used to describe and account for small variations in, e.g., measurements, calculations, and the like. When used in connection with an event or circumstance, these terms can refer to instances in which the event or circumstance occurs exactly as well as instances in which the event or circumstance occurs approximately or in close enough proximity to the event or circumstance. When used in connection with a numerical value, these terms can refer to a range of variation of less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantially" aligned can refer to a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

[0611] Additionally, quantities, ratios and other numerical values are sometimes presented in a range format. It is to be understood that such range format is used for convenience and brevity and that the use of such range format is not intended to foreclose cases that are outside of the recited range, but rather, the use of the range format is to serve as shorthand for describing a range of values that would be encompassed if the minimum of the range were replaced with the maximum and the maximum were replaced with the minimum. For example, a range of about 1 to about 200 would be understood to include each and every number between about 1 and about 200, such as, for example, about 2, about 3, and about 4, and also sub-ranges such as about 10 to about 50, and about 20 to about 100.

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

[0613] Benefits, advantages, solutions to problems, and any element that might cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as essential elements or critical components of the technologies or any or all of the claims.

[0614] In addition, in the foregoing detailed description, various specific details are set forth in order to provide a thorough understanding of the subject matter. However, various embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail since they would be understood as relevant to the subject matter by persons skilled in the art. In other instances, various terminology can also be used, but shall not be limited to a specific meaning, unless explicitly so defined herein.

[0615] To quickly determine the essence of the disclosure of the present technologies, an abstract of the present disclosure is provided. The abstract is submitted in the understanding that the abstract will not be used to interpret or limit the scope or meaning of the claims.

[0616] It is to be appreciated that the practice of the present application in some jurisdictions can require the deletion or modification of one or more portions of the disclosure. Thus, the reader should seek advice from legal counsel prior to discarding any portion of the disclosure as irrelevant to the practice of the application. The deletion of any portion of the disclosure should not be interpreted as a surrender or dedication of any of the inventive subject matter to the public.

[0617] The following claims are hereby incorporated into the present disclosure, each claim standing on its own as a separate claimed subject matter.

[0618] While the specification contains many specifics, these should not be construed as limiting the scope of the application but as merely providing illustrations of some of the embodiments of the present application. Thus, it should be apparent that the scope of the subject technology is not intended to be limited to the particular embodiments described in the specification. The only genuine limitation pertaining to the claim of the subject technology is found in the attached claims.

[0619] All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether these disclosure elements are explicitly recited in the claims. The claims recited in the application are not to be interpreted to exclude any equivalence of structures or functions inherent in or reasonably suggested by the disclosure.

[0620] Table 1

[0621] Access request type subfield values

[0622] Access request type subfield values Bit 4 Bit 5 Meaning 0 0 Random access slot assignment 0 1 Dedicated access slot assignment 1 0 Dedicated transmit access assignment 1 1 Reserved

[0623] Table 2

[0624] RTS / CTS Shared Frame Duration field encoding

[0625]

[0626] PS-Poll frames sent during the CP, or frames sent using the HCF during the CFP, except.

Claims

1. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which is configured as a wireless station (STA) to communicate wirelessly with other wireless stations (STA) on a local area network (WLAN) via at least one channel; (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate over a WLAN as a station configured to support communication using the Shared Transmission Opportunity (TXOP) protocol; (c) Non-transitory memory, the non-transitory memory storing instructions executable by the processor for STAs in the same Basic Service Set (BSS); and (d) When the instruction is executed by the processor, it performs the following steps: (i) Obtain access to the channel and convey that the upcoming TXOP can be used for sharing by broadcasting a message from a STA that can be an AP STA or a non-AP STA as the TXOP holder to other STAs in the BSS, or by communicating to the AP to indicate that the STA as the TXOP holder is willing to share the TXOP with other STAs, and the STA operating as the AP also broadcasts the message on behalf of the STA as the TXOP holder. (ii) The STA, operating as a non-AP STA or AP STA, shares TXOP with other stations in the same BSS on the network; (iii) Wherein the sharing of TXOP is performed for both uplink (UL) physical layer protocol data unit (PPDU) transmission and downlink (DL) PPDU transmission in the time domain; and (iv) From the TXOP holder, or through the AP if the AP is not the TXOP holder, send a message to the STAs that will share the TXOP with the STA, informing them of the channel access time and duration of the upcoming TXOP to be shared. The time-domain UL transmission includes dynamic scenes shared by TXOPs initiated by the UL and coordinated by the AP, and The STA, as an AP STA operation, includes the following steps: Receive messages from non-AP STAs on the network indicating a sharing proposal / request information; Exchanged with other non-AP STAs on the network to obtain sharing proposal / request information; Send a response after receiving a frame indicating that a non-AP STA has acquired the TXOP and started sharing the TXOP; Send an inquiry message on behalf of the TXOP holder to identify non-AP STAs requesting to join an upcoming shared TXOP; Collect requests from non-AP STAs on behalf of TXOP holders to join an upcoming shared TXOP; The collected sharing request information is sent to the STA operating as the TXOP holder; Receive frames from the TXOP holder indicating the time and duration allocated for the STA request to join an upcoming shared TXOP; By sending frames indicating the start time and duration allocated to each or all shared non-AP STAs, the TXOP holder STA represents the sharing of a portion of the acquired TXOP time with other non-AP STAs. If a STA operating as an AP STA has requested to participate in sharing a TXOP for DL ​​transfer, it receives the start time and duration of the allocation for TXOP sharing from the TXOP holder. and During the duration of the shared TXOP allocated by the TXOP holder STA, a downlink (DL) PPDU is sent to the destination STA on the network. or The time-domain UL transmissions include dynamic scenarios for scheduling UL-initiated TXOP sharing that do not require AP coordination, and The steps involved in a non-AP STA operation include the following: If the non-AP STA detects that the medium is idle based on the carrier sense (CS) mechanism, it sends a frame to the associated AP to obtain the channel; The transmitted frame indicates that the channel access attempt is to obtain a shared TXOP; Receive a response from the associated AP indicating successful reception of the previously sent frame and indicating that the non-APSTA has acquired the TXOP and is able to begin using the shared TXOP; If the non-AP STA operates as a TXOP holder, an inquiry message is sent to identify other STAs requesting to join the upcoming shared TXOP; If the STA does not operate as a TXOP holder, a message containing a request to join the upcoming shared TXOP is sent; If the non-AP STA operates as a TXOP holder, it collects requests from other STAs to join the upcoming shared TXOP; Allocate time and duration to the shared STA for a portion of the requested TXOP time; Send a frame indicating the assigned start time and duration to each or all shared non-AP STAs; If a non-AP STA is not a TXOP holder and has requested to participate in sharing a TXOP for UL transfer, then receive the start time and duration of the allocation for TXOP sharing from the TXOP holder. and During the duration of the shared TXOP allocated by the TXOP holder STA, send a ULPPDU to the associated AP on the network.

2. The apparatus according to claim 1, wherein the STA has a communication range based on the STA type: (i) If the STA is a non-AP STA, and the communication range does not cover all other STAs in the same Basic Service Set (BSS), the STA is able to communicate with other non-AP STAs under the coordination of AP STAs, or if other non-AP STAs are within the communication range of the STA, they are able to communicate directly with other non-AP STAs; and (ii) If the STA is an AP STA, the communication range covers all other STAs in the same Basic Service Set (BSS).

3. The apparatus of claim 1, wherein after sharing a TXOP for both uplink (UL) physical layer protocol data unit (PPDU) transmission and downlink (DL) PPDU transmission in the time domain, the instruction further includes, when determining that a STA, which is a non-AP STA or AP STA in the BSS, is requesting a time in an upcoming TXOP that can be used for sharing, exchanging messages directly or indirectly with other STAs in the BSS relative to those other STAs, either through an associated AP.

4. The apparatus according to claim 1, wherein the UL transmission and DL transmission in the time domain include a semi-static scenario in which an AP STA is used as a coordinator when scheduling a UL-initiated or DL-initiated TXOP share.

5. The apparatus according to claim 1, wherein the UL transmission and DL transmission in the time domain include a simplified scenario when a UL-initiated or DL-initiated TXOP sharing begins, wherein the STA acting as an AP does not identify the participants in the shared TXOP, but instead sequentially traverses all STAs one by one for participation.

6. The apparatus according to claim 1, wherein the STA exchanges information on TXOP sharing proposal / request capability and TXOP access time allocation by exchanging management frames with STAs operating as AP STAs or non-AP STAs on the network.

7. The apparatus according to claim 6, wherein the management frame is selected from a set of frames consisting of an authentication request frame, an authentication response frame, an association request frame, an association response frame, and a beacon frame.

8. The apparatus according to claim 1, wherein the RTS sharing frame and CTS sharing frame include a modified Ready to Send (RTS) frame and a Clear to Send (CTS) frame, the RTS frame and CTS frame containing information fields indicating that the acquired TXOP will be shared and that sharing of the TXOP has begun.

9. The apparatus of claim 1, wherein the exchange of messages from other STAs requesting access time in an upcoming TXOP can be transmitted by randomly accessing the at least one channel in a predefined time slot or in a dedicated time slot.

10. The apparatus according to claim 1, wherein the STA, as a TXOP holder, when operating as an AP STA, is able to poll non-AP STAs to determine whether they are requesting time in an upcoming TXOP.

11. The apparatus according to claim 1, wherein the STA, as the holder of the TXOP, when operating as a non-AP STA, is able to poll non-AP STAs, either by itself or through coordination with AP STAs, to determine whether they are requesting a transmission time in an upcoming TXOP.

12. The apparatus of claim 1, wherein a shared TXOP holder STA, which may be an AP STA or a non-AP STA, sends a shared TXOP access scheduler frame to a STA requesting a time in an upcoming TXOP, with or without coordination from an AP STA, in response to which the STA will send UL data to an AP STA or DL ​​data to a non-AP STA at the scheduled time and for a specified duration.

13. The apparatus of claim 12, wherein the TXOP access scheduler frame is selected from a set of message frames consisting of a TXOP proposal frame, a TXOP access scheduler frame, and a broadcast TXOP scheduler frame.

14. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which is configured as a wireless station (STA) to communicate wirelessly with other wireless stations (STA) on a local area network (WLAN) via at least one channel; (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate as a station on a WLAN; (c) Non-transitory memory, the non-transitory memory storing instructions executable by the processor for STAs in the same Basic Service Set (BSS); and (d) When the instruction is executed by the processor, it performs the following steps: (i) Send a message indicating the ability to share a transmission opportunity (TXOP); (ii) Sending a frame from an Access Point (AP) STA that is a TXOP holder and has acquired a TXOP to a non-AP STA, the frame indicating a portion of the allocated time within the acquired TXOP that will be shared with the non-AP STA; (iii) Wherein the configuration is to send PPDUs within the time allocated to the station in the frame to be shared as a non-AP STA operation station; (iv) Whereby a non-AP STA receives a frame addressed to it from its associated AP and transmits one or more non-trigger-based (non-TB) PPDUs within the allocated shared TXOP duration indicated in the frame, while ensuring that the non-AP STA’s physical layer protocol data unit (PPDU) transmissions and any expected responses are carried out entirely within the allocated time. (v) If a non-AP STA requests an acknowledgment (ACK), the AP STA responds with an ACK to the PPDU sent by the non-AP STA; as well as (vi) If the AP STA has PPDUs to send, the AP STA sends one or more PPDUs after the allocated time has ended and before the acquired TXOP NAV expires.

15. The apparatus of claim 14, wherein the STA exchanges information about TXOP sharing capabilities by exchanging management frames with STAs operating on the network as AP STAs or non-AP STAs.

16. The apparatus of claim 15, wherein the management frame is selected from a set of frames consisting of an authentication request frame, an authentication response frame, an association request frame, an association response frame, and a beacon frame.

17. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which acts as a wireless station (STA) and is configured to communicate wirelessly with other wireless stations (STAs) on a local area network (WLAN) in its receiving area via at least one channel; (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate over a WLAN as a station configured to support communication using the Shared Transmission Opportunity (TXOP) protocol; (c) Non-transitory memory, the non-transitory memory storing instructions executable by the processor for the STA; and (d) When the instruction is executed by the processor, it performs the following steps: (i) wherein the STA is operated as an AP STA of the BSS; (ii) Exchange shareability information with non-AP STAs on the network for the BSS, and broadcast the obtained shareability information on the network for the BSS; (iii) Obtain access to the channel and become a TXOP holder as an AP STA; (iv) Notify non-AP STAs that TXOP can be used for sharing; (v) Receive messages from other STAs requesting to share the TXOP; (vi) Use the obtained TXOP to send DL data to the destination STA; and (vii) When the shared TXOP time permits, broadcast the shareability information to all shared TXOP participants and assign a time slot and duration to each shared TXOP participant.

18. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which is configured as a wireless station (STA) to communicate wirelessly with other wireless stations (STA) on a local area network (WLAN) via at least one channel; (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate over a WLAN as a station configured to support communication using the Shared Transmission Opportunity (TXOP) protocol; (c) Non-transitory memory, which stores instructions that can be executed by the processor for the STA; as well as (d) When the instruction is executed by the processor, it performs the following steps: (i) wherein the STA, operating as an AP STA or a non-AP STA, has obtained a TXOP as a TXOP holder; (ii) The TXOP holder identifies the shared TXOP participants that access its TXOP and assigns time slots and durations to the shared TXOP participants in a semi-static manner by exchanging messages with these participants via the coordination of the AP. and (ii) The STA performs a setup process to set up a semi-static configuration: (A) The STA exchanges sharing / request information with other STAs through the AP STA; Then the STA in (B) performs semi-static shared TXOP scheduling and exchanges scheduling configurations with all other STAs through the AP STA.

19. The apparatus of claim 18, wherein the TXOP holder shares its TXOP with other STAs on the network in accordance with the announced resource (channel access) allocation schedule, the announced resource allocation schedule being configured during setup.

20. The apparatus of claim 18, wherein the shared TXOP participant is configured to detect the start of a TXOP and begin using the shared TXOP in an assigned time slot and duration.

21. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which, as a wireless station (STA) operating as an AP STA within its basic service set (BSS), is configured to wirelessly communicate with other wireless stations (STAs) on a local area network (WLAN) via at least one channel. (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate on a WLAN as a station configured to support communication using the Shared Transmission Opportunity (TXOP) protocol, and to cause the AP STA to traverse all non-AP STAs in a simplified shared TXOP scheme sequence, sharing TXOP and initiating channel access during uplink (UL) and downlink (DL) data transmission, in which non-AP TXOP holder STAs obtain channel access and are configured to use the shared TXOP time as required for UL data transmission; (c) Wherein, after a non-AP STA has completed a UL transmission, it sends a message to an AP STA, instructing the AP STA to circumvent the next non-AP STA. (d) Non-transitory memory, the non-transitory memory storing instructions executable by the processor for a STA; and (e) When the instruction is executed by the processor, it performs the following steps: (i) Detect that a non-AP TXOP has completed its use of the TXOP; (ii) The AP STA sequentially traverses the remaining non-AP STAs and provides each of them with at least one shared TXOP time slot for UL transmission; (iii) Determine that there is sufficient remaining TXOP time, wherein the AP STA begins DL transmission to non-AP STAs on the network; and (iv) After the AP STA completes the DL transmission, or if the TXOP time expires, the AP STA broadcasts a CTS frame to its own network to clear channel reservations for all non-AP STAs, thereby enabling a new TXOP process to begin.

22. The apparatus according to claim 21, wherein the at least one shared TXOP time slot is pre-configured.

23. An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit, which is configured as a wireless station (STA) operating as an AP STA within its Basic Service Set (BSS), to wirelessly communicate with other wireless stations (STAs) in its receiving area on a local area network (WLAN) via at least one channel. (b) A processor coupled to the wireless communication circuitry within the station, the station being configured to operate on a WLAN as a station configured to support communication using the Shared Transmission Opportunity (TXOP) protocol, and to cause the AP STA to traverse all non-AP STAs in a simplified shared TXOP scheme order, and to share TXOP and initiate channel access during uplink (UL) data transmission and downlink (DL) data transmission. (c) Non-transitory memory, which stores instructions that can be executed by the processor for the STA; as well as (d) When the instruction is executed by the processor, it performs the following steps: (i) The AP STA obtains a channel and uses the obtained TXOP to transmit DL physical layer protocol data units (PPDUs). The AP STA, as the TXOP holder, is configured to use the obtained TXOP time according to its need to transmit DL transmissions. (ii) Complete its DL transfer and determine that there is enough time remaining in the TXOP to begin sharing the TXOP with non-AP STAs; (iii) The AP STA circulates through the non-AP STAs, sharing at least one TXOP time slot for each of them for UL transmission; (iv) Upon completion of a cycle of a shared sequence with a non-AP STA, or if the TXOP time expires, the AP broadcasts a CTS frame to its own channel to clear channel reservations for all non-AP STAs, thereby enabling the start of a new shared TXOP process.

24. The apparatus according to claim 23, wherein at least one shared TXOP time slot is pre-configured.

Images