Techniques for multi-AP txop sharing

Abstract

Techniques are provided, such as a method comprising transmitting, in a first access point (AP) device, a polling frame indicating an available sharing opportunity in a channel; determining whether the available sharing opportunity is to be transferred to a second AP device; and transmitting a control frame that releases the channel if the available sharing opportunity is not to be returned.

Description

Cross-reference of technologies for multi-AP TXOP sharing

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 588,263, filed October 5, 2023, which is incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to wireless communications, and more specifically, to the sharing of transmission opportunities among multiple access points in a wireless network. Background Technology

[0003] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard is a set of standards for enabling wireless local area network (WLAN) communication in various frequency bands, including but not limited to 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. These standards define the protocols that enable Wi-Fi devices to communicate with each other. The IEEE 802.11 family of standards has evolved over time to accommodate higher data rates, greater security, and better performance in different environments. Some of the most widely used standards include 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, and 802.11ax (also known as "Wi-Fi 6"). These standards specify modulation techniques, channel bandwidth, and other technical aspects to facilitate interoperability between devices from different manufacturers. IEEE 802.11 has played a significant role in the widespread adoption of wireless networks in homes, offices, and public places, enabling users to connect their devices to the internet and to each other without wired connections. Attached Figure Description

[0004] This disclosure will be more fully understood from the following detailed description and accompanying drawings, which depict various embodiments of the disclosure. However, these drawings should not be construed as limiting the disclosure to the specific embodiments shown; they are for illustrative and understanding purposes only.

[0005] Figure 1A illustrates a wireless local area network (WLAN) with a basic service set (BSS) that includes multiple wireless devices.

[0006] Figure 1B is a table showing the operating parameters of various WiFi versions up to 802.11bn.

[0007] Figure 2 shows a schematic block diagram of a wireless device according to some embodiments.

[0008] Figure 3A illustrates components of a WLAN device configured to transmit data according to some embodiments.

[0009] Figure 3B illustrates components of a WLAN device configured to receive data according to some embodiments.

[0010] Figure 4 illustrates the relationship of inter-frame space (IFS).

[0011] Figure 5 illustrates a frame transmission process based on Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) to avoid inter-frame collisions in a channel, according to some embodiments.

[0012] Figure 6A is a diagram showing the general structure of a trigger frame.

[0013] Figure 6B illustrates an example triggered frame uplink (UL) transmission scenario according to some embodiments.

[0014] Figure 6C illustrates an example triggered frame downlink (DL) transmission scenario according to some embodiments.

[0015] Figures 7A and 7B show the general structures of EHT (WiFi 7) multi-user and trigger-based physical layer protocol data unit (PPDU) frames, respectively.

[0016] Figure 7C is a table listing the fields and additional information for a TB PPDU.

[0017] Figure 7D is a table listing the descriptions and information of the subfields in the universal signal (U-SIG) field of a MU or TB PPDU frame.

[0018] Figure 8 is a diagram illustrating three BSSs with overlapping coverage areas according to some embodiments.

[0019] Figure 9 illustrates an operational resource sharing scenario between a shared AP and a shared AP according to some embodiments.

[0020] Figure 10 shows the general format of a traditional PS-Poll frame.

[0021] Figure 11A is a diagram illustrating the frame format of a PS Poll frame with available TXOP duration indication capability according to some embodiments.

[0022] Figure 11B is a table illustrating the functionality of the duration / ID field of Figure 11A based on the values ​​of bits 14 and 15 according to some embodiments.

[0023] Figure 12 is a diagram illustrating the sequence of operations in which an AP responds to an available sharing opportunity indication frame when it wants to receive a sharing opportunity, according to some embodiments.

[0024] Figure 13 is a diagram illustrating the sequence of operations in which an AP responds to an available sharing opportunity indication frame when it does not want to receive sharing opportunities, according to some embodiments.

[0025] Figure 14 is a diagram illustrating the sequence of operations when the AP does not want to receive sharing opportunities according to some additional embodiments.

[0026] Figure 15A is a flowchart illustrating a routine for indicating the availability of a TXOP by a shared AP according to some embodiments.

[0027] Figure 15B is a flowchart illustrating a routine for AP processing instructions from an AP with available TXOPs shared, according to some embodiments. Detailed Implementation

[0028] As mentioned above, some goals of next-generation wireless network standards (e.g., IEEE 802.11be and later) include increasing data rates and range. However, increasing data rates and range are often competing goals (there is a trade-off between them). As will be discussed further below, under current WiFi standards (e.g., WiFi 6 and later), APs can share transmission opportunity resources (e.g., TXOPs) with each other, increasing channel utilization and overall wireless resource efficiency. However, in some cases, an AP with sharing opportunities (e.g., a sharing AP that cannot use all of its shared TXOPs or an AP whose TXOPs are being shared) cannot use or does not need to use the full duration of its allocated TXOPs. In this case, the AP should be able to offer its available TXOPs to other APs, for example, by returning them to the sharing AP or even to a different AP. If another AP expects to receive the available TXOPs, it should be able to receive them. However, there may not always be APs that need to use the available TXOP duration, even for shared APs. In this case, when no AP needs to use the available TXOP resources, other stations should be notified that the channel is idle to reduce resource waste. Accordingly, in some embodiments, frames such as polling frames (e.g., enhanced PS-Poll frames or other polling frames) can be used to facilitate the efficient allocation of available TXOP resources.

[0029] In the following detailed description, certain embodiments of the invention are shown and described by way of illustration only. As those skilled in the art will recognize, the described embodiments can be modified in different ways without departing from the spirit or scope of the invention. Accordingly, the drawings and descriptions are to be regarded as illustrative rather than restrictive in nature. The same reference numerals denote the same elements throughout the specification.

[0030] Figure 1A illustrates a wireless local area network (WLAN) 100 with a basic service set (BSS) 102, which includes multiple wireless devices 104 (sometimes referred to as WLAN devices 104). Each wireless device 104 may include a medium access control (MAC) layer and a physical (PHY) layer according to IEEE (Institute of Electrical and Electronics Engineers) standard 802.11 (including one or more revisions, such as 802.11a / b / g / n / p / ac / ax / bd / be). During wireless communication, the transmitting station (STA) creates a Physical Layer Protocol Data Unit (PPDU) frame and sends it to the receiving STA. The receiving STA then receives, detects, and processes the PPDU. In some embodiments, the MAC layer of wireless device 104 can initiate frame transmission to another wireless device 104 by passing a PHY-TXSTART.request (TXVECTOR) to the PHY layer. The TXVECTOR provides parameters for generating and / or sending corresponding frames. Similarly, the PHY layer of the receiving wireless device can generate an RXVECTOR, which includes the parameters of the received frame and is passed to the MAC layer for processing.

[0031] Multiple wireless devices 104 may include wireless device 104A as an access point (sometimes referred to as an AP station or AP STA) and other wireless devices 104B1 to 104B4 as non-AP stations (sometimes referred to as non-AP STAs). Alternatively, in an ad-hoc network environment, all of the multiple wireless devices 104 may be non-AP STAs. Typically, AP STAs (e.g., wireless device 104A) and non-AP STAs (e.g., wireless devices 104B1 to 104B4) may be collectively referred to as STAs. However, for ease of description, unless the context otherwise requires, only non-AP STAs may be referred to as STAs. Although four non-AP STAs (e.g., wireless devices 104B1 to 104B4) are shown, WLAN 100 may include any number of non-AP STAs (e.g., one or more wireless devices 104B).

[0032] Figure 1B is a table showing the operating parameters of various WiFi versions up to 802.11bn (also known as WiFi 8 or UHR (Ultra-High Reliability)). The IEEE 802.11bn (UHR) working group has been formed to address the growing need for higher peak throughput and reliability in Wi-Fi. As shown in Figure 1B, the peak PHY rate has increased significantly from IEEE 802.11b to IEEE 802.11be (Wi-Fi 7), with the latter focusing on further increasing peak throughput. The UHR research group aims to improve the tail and jitter of the latency distribution to support applications requiring low latency, such as WLAN video, gaming, AR, and VR. It should be noted that various features of UHR, such as maximum PHY rate, PHY rate enhancement, bandwidth / spatial stream number, and operating frequency band, are still under consideration.

[0033] The IEEE 802.11be (EHT or WiFi 7) focuses primarily on indoor and outdoor WLAN operation in the 2.4 GHz, 5 GHz, and 6 GHz bands for stationary and pedestrian speeds. In addition to peak PHY rates, various candidate features are under discussion. These include: (1) more efficient use of the 320 MHz bandwidth and discontinuous spectrum; (2) multi-band / multi-channel aggregation and operation; (3) enhancements to 16 spatial streams and Multiple Input Multiple Output (MIMO) protocols; (4) multi-access point (AP) coordination (e.g., coordinated and joint transmission); (5) enhanced link adaptation and retransmission protocols (e.g., Hybrid Automatic Repeat Request (HARQ)); and (6) adaptation to regulatory rules specific to the 6 GHz spectrum.

[0034] The focus of IEEE 802.11bn (UHR) is still under discussion, with candidate features including MLO enhancements (e.g., in terms of improving throughput / reliability and reducing latency), latency and reliability improvements (e.g., supporting multi-AP coordination for low-latency traffic), bandwidth extensions (e.g., to 240, 480, 640 MHz), aggregated PPDUs (A-PPDUs), enhanced multi-link single-radio (eMLSR) extended to APs, roaming improvements, and power-saving schemes for extending battery life.

[0035] Certain features, such as increased bandwidth and spatial stream count, are solutions that have been proven effective and feasible in previous projects focused on improving link throughput.

[0036] Regarding the operating frequency bands of IEEE 802.11be (e.g., 2.4 / 5 / 6 GHz), since the 6 GHz band (5.925–7.125 GHz) is being considered for unlicensed use, there may be additional unlicensed spectrum available exceeding 1 GHz. This would make APs and STAs tri-band devices. Data transmission speeds greater than 160 MHz (e.g., 320 MHz or 640 MHz) can be considered to increase the maximum PHY rate. For example, 320 MHz or 160+160 MHz data could be transmitted in the 6 GHz band. For example, 160+160 MHz data could be transmitted in both the 5 GHz and 6 GHz bands.

[0037] Figure 2 shows a schematic block diagram of a wireless device 104 according to an embodiment. Wireless device 104 can be wireless device 104A (i.e., the AP of WLAN 100) in Figure 1 or any of wireless devices 104B1-104B4. Wireless device 104 includes a baseband processor 210, a radio frequency (RF) transceiver 240, an antenna unit 250, a storage device (e.g., a memory device) 232, one or more input interfaces 234, and one or more output interfaces 236. The baseband processor 210, storage device 232, input interfaces 234, output interfaces 236, and RF transceiver 240 can communicate with each other via a bus 260.

[0038] The baseband processor 210 performs baseband signal processing and includes a MAC processor 212 and a PHY processor 222. The baseband processor 210 may utilize a memory 232, which may include a non-transitory computer / machine-readable medium on which software (e.g., computer / machine programming instructions) and data are stored.

[0039] In this embodiment, the MAC processor 212 includes a MAC software processing unit 214 and a MAC hardware processing unit 216. The MAC software processing unit 214 can implement a first plurality of functions of the MAC layer by executing MAC software, which may be included in software stored in the storage device 232. The MAC hardware processing unit 216 can implement a second plurality of functions of the MAC layer in dedicated hardware. However, the MAC processor 212 is not limited thereto. For example, the MAC processor 212 may be configured to perform the first and second plurality of functions entirely in software or entirely in hardware, depending on the implementation.

[0040] PHY processor 222 includes a transmitting (TX) signal processing unit (SPU) 224 and a receiving (RX) SPU 226. PHY processor 222 implements multiple functions of the PHY layer. These functions may be implemented in software, hardware, or a combination thereof, depending on the implementation method.

[0041] The functions performed by the sending SPU 224 may include one or more of the following: forward error correction (FEC) encoding, parsing a stream into one or more spatial streams, diversity encoding a spatial stream into multiple space-time streams, spatial mapping of a space-time stream to a transmission chain, inverse Fourier transform (iFT) computation, adding a cyclic prefix (CP) to create a guard interval (GI), etc. The functions performed by the receiving SPU 226 may include the inverse operations of the functions performed by the sending SPU 224, such as GI removal, Fourier transform computation, etc.

[0042] RF transceiver 240 includes an RF transmitter 242 and an RF receiver 244. RF transceiver 240 is configured to transmit first information received from baseband processor 210 to WLAN 100 (e.g., to another WLAN device 104 of WLAN 100) and to provide second information received from WLAN 100 (e.g., from another WLAN device 104 of WLAN 100) to baseband processor 210.

[0043] Antenna element 250 includes one or more antennas. When using Multiple-Input Multiple-Output (MIMO) or Multi-User MIMO (MU-MIMO), antenna element 250 may include multiple antennas. In an embodiment, the antennas in antenna element 250 may operate as a beamforming antenna array. In an embodiment, the antennas in antenna element 250 may be directional antennas, which may be fixed or steerable.

[0044] Input interface 234 receives information from the user, and output interface 236 outputs information to the user. Input interface 234 may include one or more of a keyboard, keypad, mouse, touchscreen, microphone, etc. Output interface 236 may include one or more of a display device, touchscreen, speaker, etc.

[0045] As described herein, many functions of the WLAN device 104 can be implemented in hardware or software. Which functions are implemented in software and which are implemented in hardware will vary depending on the constraints imposed by the design. These constraints may include one or more of the following: design cost, manufacturing cost, time to market, power consumption, available semiconductor technology, etc.

[0046] As described herein, the functionality of the WLAN device 104 components can be implemented using a wide variety of electronic devices, circuits, firmware, software, and combinations thereof. Furthermore, the WLAN device 104 may include other components such as an application processor, storage interface, clock generation circuitry, power supply circuitry, etc., which have been omitted for the sake of brevity.

[0047] Figure 3A illustrates the components of a WLAN device 104 configured to transmit data according to an embodiment, including a transmitting (TX) SPU (TxSP) 324, an RF transmitter 342, and an antenna 352. In this embodiment, the TxSP 324, RF transmitter 342, and antenna 352 correspond to the antennas of the transmitting SPU 224, RF transmitter 242, and antenna element 250 of Figure 2, respectively.

[0048] The TxSP 324 includes an encoder 300, an interleaver 302, a mapper 304, an inverse Fourier transformer (IFT) 306, and a guard interval (GI) inserter 308.

[0049] Encoder 300 receives and encodes input data. In an embodiment, encoder 300 includes a forward error correction (FEC) encoder. The FEC encoder may include a binary convolution code (BCC) encoder followed by a punching device. The FEC encoder may include a low-density parity-check (LDPC) encoder.

[0050] The TxSP 324 may further include a scrambler for scrambling the input data before the encoder 300 performs encoding to reduce the probability of long sequences of 0s or 1s. When the encoder 300 performs BCC encoding, the TxSP 324 may further include an encoder parser for demultiplexing the scrambled bits among multiple BCC encoders. If LDPC encoding is used in the encoder, the TxSP 324 may not need an encoder parser.

[0051] Interleaver 302 interleaves the bits of each stream output from encoder 300 to change the order of the bits. Interleaver 302 can apply interleaving only when encoder 300 performs BCC encoding; otherwise, it can output the stream from encoder 300 without changing the order of the bits.

[0052] Mapper 304 maps the sequence of bits output from interleaver 302 to constellation points. If encoder 300 performs LDPC encoding, mapper 304 can also perform LDPC tone mapping in addition to constellation mapping.

[0053] When the TxSP 324 performs MIMO or MU-MIMO transmission, it can include multiple interleavers 302 and multiple mappers 304 depending on the number of spatial streams (NSS) being transmitted. The TxSP 324 may further include a stream resolver for dividing the output of the encoder 300 into blocks, which can then be sent to different interleavers 302 or mappers 304 respectively. The TxSP 324 may further include a space-time block code (STBC) encoder for expanding constellation points from the spatial streams to the number of space-time streams (NSTS), and a spatial mapper for mapping the space-time streams to the transmit chain. The spatial mapper can use direct mapping, spatial spreading, or beamforming.

[0054] IFT 306 converts the constellation point blocks output from mapper 304 (or, when performing MIMO or MU-MIMO, from the spatial mapper) into temporal blocks (i.e., symbols) using either the inverse discrete Fourier transform (IDFT) or the inverse fast Fourier transform (IFFT). If an STBC encoder and spatial mapper are used, IFT 306 can be provided for each transmit chain.

[0055] When the TxSP 324 performs MIMO or MU-MIMO transmissions, it can insert cyclic shift diversity (CSD) to prevent unintentional beamforming. The TxSP 324 can insert CSD before or after IFT 306. CSD can be specified for each transmit chain or for each spacetime stream. Alternatively, CSD can be applied as part of the spatial mapper.

[0056] When the TxSP 324 performs MIMO or MU-MIMO transmissions, it can provide certain blocks before the space mapper for each user.

[0057] The GI inserter 308 prepends a GI to each symbol produced by the IFT 306. Each GI may include a cyclic prefix (CP) corresponding to the repeating portion at the end of the symbol prepended by that GI. The TxSP 324 may optionally perform windowing to smooth the edges of each symbol after inserting the GI.

[0058] RF transmitter 342 converts symbols into RF signals and transmits the RF signals through antenna 352. When TxSP 324 performs MIMO or MU-MIMO transmission, a GI inserter 308 and an RF transmitter 342 can be provided for each transmit chain.

[0059] Figure 3B illustrates the components of a WLAN device 104 configured to receive data according to an embodiment, including a receiver (Rx) SPU (RxSP) 326, an RF receiver 344, and an antenna 354. In the embodiment, the RxSP 326, RF receiver 344, and antenna 354 may correspond to the antennas of the receiver SPU 226, RF receiver 244, and antenna unit 250 of Figure 2, respectively.

[0060] The RxSP 326 includes a GI remover 318, a Fourier transformer (FT) 316, a demapping unit 314, a deinterleaving unit 312, and a decoder 310.

[0061] RF receiver 344 receives RF signals via antenna 354 and converts the RF signals into symbols. GI remover 318 removes GI from each symbol. When the received transmission is a MIMO or MU-MIMO transmission, RF receiver 344 and GI remover 318 can be provided for each receive chain.

[0062] FT 316 transforms each symbol (i.e., each time-domain block) into a frequency-domain block of constellation points using either the Discrete Fourier Transform (DFT) or the Fast Fourier Transform (FFT). FT 316 can be provided for each receiver chain.

[0063] When the received transmission is a MIMO or MU-MIMO transmission, the RxSP 326 may include a spatial demapper for converting the respective outputs of the FT 316 of the receiver chain into constellation points of multiple space-time streams, and an STBC decoder for despreading the constellation points from the space-time streams to one or more spatial streams.

[0064] Demapper 314 demaps the constellation points output from the FT 316 or STBC decoder to the bitstream. If the received transmission is encoded using LDPC encoding, demapper 314 may further perform LDPC tone modulation mapping before performing constellation demapping.

[0065] Deinterleaver 312 deinterleaves the bits of each stream output from demapper 314. Deinterleaver 312 may perform deinterleaving only if the received transmission is encoded using BCC encoding; otherwise, it may output the stream output by demapper 314 without performing deinterleaving.

[0066] When the received transmission is a MIMO or MU-MIMO transmission, the RxSP 326 can use multiple demappers 314 and multiple deinterleavers 312 corresponding to the number of spatial streams transmitted. In this case, the RxSP 326 may further include a stream deparser for combining the streams output from the deinterleavers 312.

[0067] Decoder 310 decodes the stream output from deinterleaver 312 or stream deparser. In an embodiment, decoder 310 includes an FEC decoder. The FEC decoder may include a BCC decoder or an LDPC decoder.

[0068] RxSP 326 may further include a descrambler for descrambling the decoded data. When decoder 310 performs BCC decoding, RxSP 326 may further include an encoder deparser for multiplexing data decoded by multiple BCC decoders. When decoder 310 performs LDPC decoding, RxSP 326 may not use the encoder deparser.

[0069] Before transmission, wireless devices such as wireless device 104 will use Clear Channel Assessment (CCA) to assess the availability of the wireless medium. If the medium is occupied, CCA can determine that it is busy, and if the medium is available, CCA can determine that it is idle.

[0070] The PHY entities in IEEE 802.11 are based on Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA). In the OFDM or OFDMA physical (PHY) layer, a STA (e.g., wireless device 104) can transmit and receive Physical Layer (PHY) Protocol Data Units (PPDUs) conforming to the mandatory PHY specification (also known as Physical Layer Convergence Procedure (PLCP) Protocol Data Units). The PHY specification defines the set of modulation and coding schemes (MCS) and the maximum number of spatial streams. Some PHY entities define downlink (DL) and uplink (UL) multi-user (MU) transmissions with a maximum number of space-time streams (STS) per user and employing up to a predetermined total number of STSs. The PHY entity can provide support for continuous channel bandwidths of 10 MHz, 20 MHz, 40 MHz, 80 MHz, 160 MHz, 240 MHz, and 320 MHz, and for discontinuous channel bandwidths of 80+80 MHz, 80+160 MHz, and 160+160 MHz. Each channel comprises multiple subcarriers, which may also be referred to as tone. The PHY entity can define signaling fields within the PPDU, represented by Legacy Signal (L-SIG), Signal A (SIG-A), and Signal B (SIG-B), through which necessary information related to the PHY Service Data Unit (PSDU) attributes can be communicated. For completeness and brevity, the following description references OFDM-based 802.11 technology. Unless otherwise specified, a station refers to a non-AP STA.

[0071] Figure 4 illustrates the inter-frame space (IFS) relationships. Specifically, Figure 4 shows the short IFS (SIFS), point coordination function (PCF) IFS (PIFS), distributed coordination function (DCF) IFS (DIFS), and arbitration IFS (AIFS[i]) corresponding to Access Category (AC) 'i'. Figure 4 also shows the time slots used for data frames to transmit data forwarded to higher layers. As shown, if the DIFS has passed (during which the medium is idle), the WLAN device 104 transmits a data frame after performing a backoff.

[0072] Management frames can be used to exchange management information, which is not forwarded to higher layers. Subtypes of management frames include beacon frames, association request / response frames, probe request / response frames, and authentication request / response frames.

[0073] Control frames can be used to control access to the medium. Subtypes of control frames include request to send (RTS) frames, clear to send (CTS) frames, and acknowledgement (ACK) frames.

[0074] When the control frame is not a response frame to another frame, if DIFS has passed (during which time the medium is idle), WLAN device 104 sends a control frame after performing backoff. When the control frame is a response frame to another frame, WLAN device 104 sends a control frame after SIFS has passed without performing backoff or checking if the medium is idle.

[0075] A WLAN device 104 (i.e., a QoS STA) that supports Quality of Service (QoS) functionality can perform a backoff after the AIFS (i.e., AIFS[AC]) of the associated access category (AC) has passed. When transmitted by a QoS STA, any of the data frames, management frames, and control frames that are not response frames can use the AIFS[AC] of the AC of the transmitted frame.

[0076] When a WLAN device 104, ready to transfer a frame, detects that the medium is busy, the WLAN device 104 can perform a backoff procedure. The backoff procedure includes determining a random backoff time consisting of N backoff slots, where each backoff slot has a duration equal to the slot time, and N is an integer greater than or equal to zero. The backoff time can be determined based on the length of the Contention Window (CW). In an embodiment, the backoff time can be determined based on the AC of the frame. All backoff slots occur after a DIFS or Extended IFS (EIFS) period, during which the medium is determined to be idle for the duration of that period.

[0077] When WLAN device 104 does not detect media activity for the duration of a specific backoff slot, the backoff process should reduce the backoff time by the slot duration. When WLAN device 104 determines that the media is busy during the backoff slot, the backoff process will pause until the media is again determined to be idle for the duration of the DIFS or EIFS period. When the backoff timer reaches zero, WLAN device 104 can perform frame transmission or retransmission.

[0078] The backoff process operates as follows: when multiple WLAN devices 104 are delaying and performing the backoff process, each WLAN device 104 can use a random function to select a backoff time, and the WLAN device 104 that selects the shortest backoff time can win the competition, thereby reducing the probability of conflict.

[0079] Figure 5 illustrates a frame transmission process based on Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) to avoid frame collisions in the channel, according to an embodiment. The distributed nature of channel access networks such as IEEE 802.11 WLANs makes carrier sense mechanisms important for collision-free operation. A STA's physical carrier sense is responsible for detecting transmissions from other STAs, but in some cases, it's impossible to detect every situation. For example, a STA far from another STA might assume the medium is idle and begin transmitting frames. To overcome this hidden node problem, the network allocation vector (NAV) is introduced. However, with the development of the IEEE 802.11 standard, simultaneous transmission / reception by multiple users within a BSS, such as in cascaded UL / DL MU transmissions, may require modified or newly defined mechanisms. As used herein, multi-user (MU) transmission refers to the situation where multiple frames are simultaneously transmitted to or from multiple STAs using different resources. Examples of different resources are different frequency resources in OFDMA transmissions and different spatial streams in MU-MIMO transmissions. DL-OFDMA, DL-MU-MIMO, UL-OFDMA, UL-MU-MIMO, and OFDMA with MU-MIMO are examples of MU transmissions.

[0080] Figure 5 shows a first station STA1 that transmits data, a second station STA2 that receives data, and a third station STA3. The third station STA3 can be located in an area that can receive frames transmitted from STA1, frames transmitted from the second station STA2, or both. Stations STA1, STA2, and STA3 can be the WLAN device 104 in Figure 1.

[0081] Station STA1 can determine whether the channel is busy through carrier sensing. Station STA1 can determine channel occupancy / state based on the energy level in the channel or the autocorrelation of the signal in the channel, or it can determine channel occupancy by using a network allocation vector (NAV) timer.

[0082] After determining that the channel is not used by other devices during DIFS (i.e., the channel is idle) (and performing backoff if necessary), station STA1 can send a Request-To-Send (RTS) frame to station STA2. Upon receiving the RTS frame, after SIFS, station STA2 can send a Clear-To-Send (CTS) frame in response to the RTS frame. If dual CTS is enabled and station STA2 is an AP, the AP can respond to the RTS frame by sending two CTS frames (e.g., a first CTS frame in a non-high-throughput format and a second CTS frame in HT format).

[0083] When station STA3 receives an RTS frame, it can use the duration information included in the RTS frame to set its NAV timer to the transmission duration of the subsequently transmitted frame (e.g., the duration of SIFS + CTS frame duration + SIFS + data frame duration + SIFS + ACK frame duration). When station STA3 receives a CTS frame, it can use the duration information included in the CTS frame to set its NAV timer to the transmission duration of the subsequently transmitted frame. If a new frame is received before the NAV timer expires, station STA3 can use the duration information included in the new frame to update its NAV timer. Station STA3 does not attempt to access the channel until the NAV timer expires.

[0084] When station STA1 receives a CTS frame from station STA2, it can send a data frame to station STA2 after the SIFS period has elapsed since the CTS frame was fully received. After successfully receiving the data frame, station STA2 can send an ACK frame as a response to the data frame after the SIFS period has elapsed.

[0085] When the NAV timer expires, the third station STA3 can use carrier sensing to determine if the channel is busy. After determining that the channel has not been used by other devices during the DIFS period after the NAV timer expires, station STA3 can attempt to access the channel after the contention window has passed, according to the backoff procedure.

[0086] When dual CTS is enabled, a station that has secured a transmission opportunity (TXOP) but has no data to transmit can send a CF-End frame to shorten the TXOP. An AP receiving a CF-End frame with the AP's Basic Service Set Identifier (BSSID) as the destination address can respond by sending two more CF-End frames: a first CF-End frame using Space-Time Block Coding (STBC) and a second CF-End frame using a non-STBC format. The station receiving the CF-End frame resets its NAV timer to 0 at the end of the PPDU containing the CF-End frame. Figure 5 illustrates station STA2 sending an ACK frame to acknowledge successful frame reception.

[0087] Figure 6A is a diagram illustrating the general structure of a trigger frame. The function of a trigger frame is to allocate resources and request trigger-based (TB) Physical Layer Protocol Data Unit (PPDU) transmissions from one or more associated stations (including APs and non-AP STAs). Among other things, they are used by APs to allocate resources for multi-user Orthogonal Frequency Division Multiple Access (OFDMA) transmissions. They specify how bandwidth and time slots should be allocated among multiple STAs, allowing multiple users to transmit data simultaneously without interference. This is crucial for improving overall network efficiency and throughput, especially in high-user-density environments.

[0088] As shown in the figure, a trigger frame typically includes several distinct parts, including a Media Access Control (MAC) header section 605, a Common Information section 610, and a User Information section 615. The MAC header includes several fields that facilitate communication between devices. For example, as shown, these may include frame control (FC), duration, receiver address (RA), and transmitter address (TA) fields. The FC field indicates the protocol version, type, and several different flags used for parameters such as power management. The duration field indicates the duration for which the medium is held, or in some implementations, it may carry an association identifier (AID) in certain contexts. The RA field indicates the address of the receiving STA, and the TA field indicates the address of the sending STA. The MAC header may also include sequence and QoS control fields.

[0089] Trigger frames have specific subfields within their frame control fields for their operation, including trigger frame type, such as basic trigger, MU-BAR (Multi-User Block Acknowledgment Request), and MU-RTS (Multi-User Request Send). Each of these subtypes has unique operational characteristics and requirements, especially in multi-user scenarios where coordination is crucial for efficient communication.

[0090] The Public Information Section 610 includes parameters such as expected uplink length, bandwidth, guard interval, and transmit power used by the AP. These parameters help the STA prepare for upcoming transmissions.

[0091] Different fields in the Public Information field are used to inform the responding STA how to set the frame in the response. The response to MU-RTS is a traditional CTS frame in a non-HT format. At 5 GHz, this means traditional OFDM. Therefore, most subfields in the Public Information field of MU-RTS may not be needed. For the included fields, for MU-RTS requests, the Trigger Type is set to 3; more TF is used for TWT or power saving with UORA (otherwise set to 00); if the responding STA does not need to consider the medium or NAV when determining whether to respond, the CS Required is set to 0. If the responding STA needs to use ED (Energy Detection) to listen and consider the medium and NAV when determining whether to respond, the CS Required is set to 1. UL BW is usually used to describe the bandwidth of the response in the TB PPDU, but for MU-RTS, it can describe the bandwidth of the frame carrying the MU-RTS (e.g., 0=20 MHz, 1=40 MHz, 2=80 MHz, 3=80 + 80 MHz or 160 MHz).

[0092] User information section 615 includes detailed information for each participating STA, such as Association ID (AID), resource unit (RU) allocation, modulation and coding scheme (MCS), and received signal strength indicator (RSSI). This information allows each STA to know its specific transmission parameters. The AID12 field indicates the STA-id (Association ID) for each receiver. Other values ​​used in this space are used for other variations of the trigger frame. The RU allocation is used to indicate on which primary channel the CTS response should be transmitted. This is specific to 40 MHz and 80 MHz channels, regardless of whether the primary channel is the lowest, second lowest, etc. The user information fields are typically repeated for each STA acting as a receiver in a MU-RTS. The receiving STA is addressed by its Association ID, STA-id, rather than by its MAC address as in a traditional RTS. Depending on the specific trigger frame type, there may be additional information. For example, it may also include the allocation duration subfield from the user information for TXS (TXOP Shared) frames. The user information field in a trigger frame (such as a MU-RTS trigger frame) may include an allocation duration subfield. This subfield indicates the time allocated by the AP for transmission during the TXOP period to the STA. This field may also contain an allocation duration subfield indicating the duration of time allocated for P2P communication associated with the client device. This allocation duration subfield is used to manage transmission time and allows other devices to set their network allocation vector (NAV) accordingly.

[0093] Figure 6B illustrates an example triggered frame uplink (UL) transmission scenario according to some embodiments. In versions of the IEEE 802.11 specification since 802.11ax (WiFi 6), triggered frames have played a useful role in facilitating uplink and downlink multi-user (MU) transmissions.

[0094] The trigger frame contains information required in response to the STA sending its uplink TB PPDU. This information includes a trigger type specifying the type of the expected TB PPDU, and an uplink length (ULLength) indicating the duration of the uplink transmission.

[0095] In the example scenario of Figure 6B, an access point (AP) operating in an 80 MHz bandwidth environment sends trigger frames to multiple associated STAs to allow them to perform uplink data transmission. Upon receiving the trigger frame, the STAs respond by sending their respective CTS (Complete Transmission) response frames. The CTS frame is a response to the MU-RTS. All STAs addressed in the user information field of the MU-RTS trigger frame should respond with a CTS if they wish to participate in uplink transmission. When a STA sends its CTS, it uses its TA address, which is the address of the STA (AP) that should receive the CTS. The AP then sends a transmission to initiate uplink transmission from the STA that responded appropriately. From here, the STAs utilize the allocated resources within the specified 80 MHz bandwidth to transmit Orthogonal Frequency Division Multiple Access (ULOFDMA) TB PPDUs. Upon successfully receiving the ULOFDMA TB PPDU, the AP acknowledges the STA by sending an acknowledgment frame. This acknowledgment can take the form of 80 MHz wide multi-STA block acknowledgment (Block Ack) or block acknowledgment with a Direct Feedback (DF) OFDMA method. Multi-STA block acknowledgment allows the AP to acknowledge multiple STAs simultaneously, while block acknowledgment with DF OFDMA enables the AP to provide feedback to the STAs using the same OFDMA technology sampled in the uplink transmission.

[0096] Figure 6C illustrates an example triggered frame downlink (UL) transmission scenario according to some embodiments. This is similar to the uplink process, except that it facilitates bulk data transmission from the AP to the STA (rather than from the STA to the AP). The AP sends a multi-user RTS, such as MU-RTS-TXS, to the STA to request downlink transmissions to the STA. The process begins with the AP sending an MU RTS-TXS trigger frame to a non-AP STA. Upon receiving this frame, the STA is expected to respond with a CTS frame, indicating that it is ready to receive data. From here, the AP transmits an MU PPDU to the responding STA, which includes the data prepared for the STA. Finally, the STA responds to the AP with an acknowledgment frame.

[0097] Figures 7A and 7B illustrate the general structure of EHT (WiFi 7) multi-user and trigger-based physical layer protocol data unit (PPDU) frames, respectively. (The UHR PPDU is expected to be the same or similar. For simplicity, EHT examples may be used in this document and other parts of this disclosure, but it should be understood that UHR and subsequent specification parameters can also be implemented.) Referring to Figure 7A, the MU PPDU can be sent to a single user or multiple users. The frame has a legacy (705A) and contemporary (710A) preamble portion, and data and packet extension field portions. The legacy portion includes a legacy short training field (L-STF), a legacy long training field (L-LTF), and a legacy signal field (L-SIG). The contemporary portion includes the universal signal field (U-SIG), EHT signal field (EHT-SIG), EHT short training field (EHT-STF), EHT long training field (EHT-LTF), data field for the actual data payload, and packet extension (PE) field. The EHT-SIG field, together with the U-SIG field, provides RU (Resource Unit) allocation and other information needed by the STA to understand the MU packet. When the MU PPDU is sent to multiple users, the transmission can be OFDMA or MU-MIMO.

[0098] Referring to Figure 7B, after receiving a trigger-based RTS from the AP, the STA can respond to the trigger using an EHT TB PPDU. The EHT TB frame format is similar to the MU PPDU. However, the TB PPDU does not include the EHT-SIG preamble field, and it includes a repeated legacy (RL) signal field in its legacy section. Furthermore, the length of the EHT-STF field can be twice that of the EHT MU PPDU to improve uplink transmission performance and reliability.

[0099] Figure 7C is a table listing the fields and additional information of a TB PPDU. Figure 7D is a table listing the descriptions and information of the subfields in the universal signal (U-SIG) field of a MU or TB PPDU frame.

[0100] For many years, the preamble has been an important design component used to provide the receiver with the relevant information needed to decode the transmitted data. It is also used to provide backward compatibility with previous PHY versions. However, the preamble does not directly convey the PHY version of the data packet. Automatic detection (or spoofing) mechanisms have been created to allow the receiver to implicitly determine the PHY version. However, automatic detection algorithms have become increasingly complex. EHT attempts to address this issue using the universal signal (U-SIG) field. The U-SIG follows the traditional and RL SIG fields and is two OFDM symbols long. It includes version-independent bits and version-related bits. The version-independent bits are the first 20 bits of the U-SIG and have the same position and definition for EHT and subsequent PHYs. The first three bits (bits 0 to 2) identify the PHY version, which simplifies automatic detection. The next three bits (bits 3 to 5) indicate the spectral occupancy of the PPDU (e.g., 80 MHz bandwidth). The seventh bit (bit 6) indicates the link direction (i.e., uplink or downlink). The next 6 bits (bits 7 to 12) identify the basic serviceset (BSS) being used via BSS color, while the 7 TXOP bits (bits 13 to 19) provide information about how long the PPDU has been using the media. The remainder of the U-SIG bits / fields depends on the PHY version and PPDU type.

[0101] To provide flexibility and prepare for potential new features, the EHT categorizes reserved bits in the EHT preamble as either "ignore" or "verify." This categorization helps the receiver determine the appropriate action when it encounters a bit value that is not used in its supported PHY. "Ignore" means ignoring the bit and continuing reception. "Verify" means checking if the bit matches a known value; if not, reception is terminated. For example, values ​​1 through 7 in the PHY version identifier field would correspond to a future IEEE 802.11 PHY version, which devices supporting the current EHT version would not recognize. If a baseline EHT device receives a value other than 0 (0 indicates an EHT PHY), the device should stop receiving.

[0102] When the transmitter (TX) fails to receive an acknowledgment from the receiver (RX) or the receiver fails to decode the MPDU, a wireless network system can rely on retransmission of the Media Access Control (MAC) Protocol Data Unit (MPDU). Using the Automatic Repeat Request (ARQ) method, the receiver discards the last failed MPDU before receiving a new retransmitted MPDU. With increasing demands for enhanced reliability and reduced latency, wireless network systems can evolve towards Hybrid ARQ (HARQ) methods.

[0103] There are two methods for HARQ processing. In the first type of HARQ scheme (also known as chase-combining (CC) HARQ (CC-HARQ) scheme), the signal to be retransmitted is the same as the previously failed signal because all sub-data packets to be retransmitted use the same puncturing pattern. Punching is needed to remove some parity bits after encoding with error correction codes. The reason CC-HARQ uses the same puncturing pattern is to generate an encoded data sequence with forward error correction (FEC) and to allow the receiver to use maximum-ratio combining (MRC) to combine the received retransmitted bits with the same bits from the previous transmission. For example, the information sequence is transmitted in packets of fixed length. At the receiver, error correction and detection are performed on the entire packet. However, ARQ schemes can be inefficient when burst errors are present. To address this issue more efficiently, sub-data packets are used. In sub-data packet transmission, only the sub-data packets containing the errors need to be retransmitted.

[0104] Because the receiver uses both currently received and previously received sub-data packets to decode the data, the probability of decoding errors decreases as the number of sub-data packets used increases. The decoding process is performed using cyclic redundancy check (CRC) and ends when the entire data packet is decoded without errors or when the maximum number of sub-data packets is reached. Specifically, this scheme operates on a stop-and-wait protocol, such that if the receiver can decode the data packet, it sends an acknowledgment (ACK) to the transmitter. When the transmitter successfully receives the ACK, it terminates the HARQ transmission of that data packet. If the receiver cannot decode the data packet, it sends a negative acknowledgment (ACK) to the transmitter, and the transmitter performs a retransmission.

[0105] In the second type of HARQ scheme (also known as incremental redundancy (IR) HARQ (IR-HARQ) scheme), a different puncturing pattern is used for each sub-packet, such that the signal of each retransmitted sub-packet changes compared to the original transmitted sub-packet. IR-HARQ alternates between the two puncturing patterns for odd and even transmissions, respectively. The redundancy scheme of IR-HARQ improves the log likelihood ratio (LLR) of the parity bit to merge information sent across different transmissions due to requests, and reduces the code rate with the use of additional sub-packets. This results in a lower error rate for sub-packets compared to CC-HARQ. The puncturing pattern used in IR-HARQ is indicated by the subpacket identity (SPID). The SPID of the first sub-packet can always be set to 0, and all systematic bits and punctured parity bits are transmitted in the first sub-packet. Self-decoding is possible when the received signal-to-noise ratio (SNR) environment is favorable (i.e., high SNR). In some embodiments, the sub-data packets to be transmitted, each with a corresponding SPID, are arranged in ascending order of SPID, but may be swapped / switched except for the first SPID.

[0106] Multi-access point (M-AP) coordination is likely to become an important technology in IEEE 802.11 (including IEEE 802.11be and later versions) for enhancing reliable channel utilization. M-AP technology can not only improve spectral efficiency but also reduce data transmission latency.

[0107] An AP that acquires a TXOP (Transmission Opportunity) and can share some or all of it is called a sharing AP. A sharing AP initiates AP coordination to identify AP candidates by sending frames that include the sharing AP's TXOP capability (e.g., beacon frames, probe response frames, etc.). An AP that wants to receive a TXOP after receiving a frame from a sharing AP is called a shared AP. The sharing AP can also be called the master AP or coordinating AP, and the shared AP can be called the slave AP or coordinated AP.

[0108] Various M-AP technologies have been and are under discussion. These include coordinated beamforming (CBF), coordinated spatial reuse (CSR), joint transmission (JTX), and OFDMA / TDMA. Coordinated beamforming / nulling involves multiple APs transmitting on the same frequency resources based on coordination and spatial nulling to allow simultaneous transmission from multiple APs. Interference between M-APs is reduced through the sharing of channel state information (CSI). Using coordinated spatial reuse (CSR), multiple APs and / or STAs adjust their transmit power to reduce interference between stations (APs, non-AP STAs). Using the joint transmission (JTX) scheme, multiple APs simultaneously transmit to a given user by sharing data among themselves. In effect, multiple APs act as a single virtual AP. Using the coordinated OFDMA / TDMA scheme, M-APs use time and frequency in a coordinated manner to improve system throughput. They transmit on orthogonal frequency resources by coordinating and splitting the spectrum to use it more efficiently.

[0109] While all these M-AP technologies have their advantages and disadvantages, C-TDMA technology may be more efficient in some implementations, for example, in terms of fairness. If data needs to be transmitted on devices sharing an AP (i.e., non-TXOP holders), the chance of utilizing the access channel using C-TDMA is relatively higher compared to other M-AP technologies. Furthermore, compared to C-BF / Return-to-Zero techniques, it does not require feedback channel state information, and its implementation is relatively simpler compared to the JTX method, which requires synchronization between APs.

[0110] WiFi implementations (e.g., UHR) allow a new TXOP sharing method that allows a sharing AP to share its acquired transmission opportunities (TXOPs) with other APs (referred to as "shared" APs). In the context of Coordinated TDMA (C-TDMA), the AP with the transmission opportunities (TXOPs) to be shared is called the sharing AP. This AP initiates an AP coordination scheme by sending frames (e.g., management frames, such as beacon frames or probe response frames) that include information related to the AP coordination scheme's capabilities to determine a candidate set of APs. APs that participate in the AP coordination scheme after receiving frames from the sharing AP are called shared APs. The sharing AP is also called the master AP or coordinating AP, and the shared AP can be called the slave AP or the coordinated AP.

[0111] Figure 8 illustrates three BSSs with overlapping coverage areas. These BSSs include BSS1, BSS2, and BSS3, each with associated APs, namely AP1, AP2, and AP3. In this example, AP1 has two associated non-AP stations (STA1-1, STA1-2); AP2 has two associated non-AP stations (STA2-1, STA2-2); and AP3 has one associated non-AP station (STA3-1), as shown in the figure. AP1 is a sharing AP, sharing its TXOP with AP2, which is referred to as the shared AP. AP3 does not directly participate in TXOP sharing, but it can hear at least some transmissions from BSS1, BSS2, or both BSS1 and BSS2. With this capability, it is referred to as an over-hearing AP. Therefore, BSS1 is a sharing BSS; BSS2 is a shared BSS; and BSS3 is an over-hearing BSS (OBSS).

[0112] In Ultra-High Reliability (i.e., UHR, 801.11bn), the concept of TXOP sharing has been extended from sharing TXOP within a single BSS to sharing TXOP across multiple BSSs (e.g., a sharing AP and a shared AP). A shared AP can freely exchange frames, such as UL / DL, within its own BSS during the shared TXOP period. The duration of the TXOP shared between the sharing AP and the shared AP can be determined during the pre-connection process between the sharing AP and the shared AP, or the sharing AP can allocate an arbitrary TXOP duration to the shared AP. However, there can be situations where the shared AP may not be able to fully utilize the shared TXOP due to unforeseen circumstances. For example, suppose the shared AP requests a specific TXOP duration from the sharing AP during the pre-connection phase. In this example, the shared AP requests sufficient TXOP duration to support a certain number of UL / DL PPDU retransmissions. However, when the channel environment is better than expected, the transmission / reception of UL / DL PPDUs may be completed faster than expected. As another example, if the sharing AP arbitrarily allocates TXOP duration to the shared AP, it can allocate more than the shared AP needs or can use. In these scenarios, the duration of unused TXOPs (i.e., available TXOPs) can lead to resource waste. To address this issue, a standard method for managing the available TXOPs from available transmission opportunities at the AP is needed.

[0113] Transferring available TXOP time to other APs is an issue being discussed in UHR (and later versions) to avoid wasting resources when the shared AP cannot fully utilize the shared TXOP duration. A mechanism is needed to transfer available TXOP to other APs (e.g., the sharing AP (the original TXOP holder) or even to different APs) so that available TXOP can be used efficiently. For example, if an AP that has shared its TXOP now has packets that need urgent processing within its own BSS, it might want the unused TXOP duration returned to it, or it might want to share the unused duration with other APs. When the sharing AP receives available TXOP from the shared AP, the returned TXOP can be shared with other APs that can use the resources efficiently. Alternatively, even if the sharing AP does not need the available TXOP, other APs (such as OBSS APs) can still use it.

[0114] If the sharing AP wishes to receive an available TXOP, it should be able to receive it. However, situations where the sharing AP needs to use an available TXOP may not always exist. In such cases, the availability of the TXOP, or at least the channel being idle, should be communicated to other stations so that they have the opportunity to access it when needed. Accordingly, in some embodiments, the AP may use polling frames to indicate available TXOPs to be shared with one or more other APs. For example, in some embodiments, the shared AP may use polling frames to indicate the remaining available TXOPs, or the shared AP may use polling frames to identify one or more shared AP candidates to receive at least a portion of the TXOPs.

[0115] Figure 9 illustrates an operational resource sharing scenario between a sharing AP and a shared AP according to some embodiments, where the shared AP has remaining TXOPs available for sharing. At 905, the sharing AP sends a control frame (e.g., MU-RTS TXS) to transfer TXOPs (e.g., at least a portion of the TXOPs) with the shared AP. After the shared AP sends a response frame (e.g., CTS) at 910, it uses the TXOPs for the allocated time period and sends or requests PPDUs to one or more STAs in its BSS (915), and receives an acknowledgment frame (920) when the data transfer is complete.

[0116] However, in this example, the shared AP cannot fully utilize its allocated TXOP duration, and therefore has available TXOPs, which it may return to the sharing AP or to another AP. Accordingly, at 925, the shared AP initiates an indication, such as a polling frame, to relinquish its available TXOP duration. The shared AP may return the TXOPs to the sharing AP, or it may perform another TXOP sharing operation with another candidate AP. The sharing AP may or may not need TXOPs, so it is inefficient for the shared AP to arbitrarily and simply return its available TXOPs to the sharing AP. Instead, it may be more efficient, for example, for the shared AP to poll other APs (including the sharing AP) to determine whether TXOPs are needed or can be used by the AP. In some embodiments, the available TXOP indication may prioritize the sharing AP, for example, by utilizing a polling frame. Different ways of implementing the available TXOP indication are discussed in the following sections. Polling

[0117] In some embodiments, in addition to their conventional functions, polling frames can also be used to indicate available TXOP transmission opportunities. PS-Poll (Power Saving Polling) frames are an example of polling frames used in Wi-Fi to retrieve buffered frames from the AP after a non-AP station wakes up from power saving mode. In a typical implementation, when a STA wants to enter power saving mode, it sends a frame (e.g., an empty data frame) to the AP, asserting (e.g., setting the power management bit to 1) the power management bit in the frame control field of the empty data frame. This indicates to the AP that the STA is transitioning to a power saving state. The AP acknowledges this frame, confirming that it will buffer any frames intended to be sent to the STA while it is in power saving mode. After the STA sends an empty data frame (where the power management bit is set to 1), the AP begins buffering frames for the STA. The STA can then enter a power saving (e.g., sleep) state, conserving power until it wakes up according to a predetermined listening interval. The STA wakes up periodically to check the buffered data. It does this by listening for beacon frames from the AP, which include a Traffic Indication Map (TIM) field indicating whether any frames are waiting for the STA. If the STA's AID (Association Identifier) ​​is indicated in the TIM, it knows to wake up and retrieve buffered frames. If the STA wakes up and detects buffered frames, it sends a PS-Poll frame to the AP to request data. The PS-Poll frame also includes the STA's AID (e.g., in the AID or Duration / ID field of the PS-Poll frame), allowing the AP to identify the frames to send back. The AP responds with the buffered frames, and the STA remains awake as long as more data bits in frames from the AP are set to 1. Once the STA has received all buffered frames (indicated by more data bits being set to 0), it can send additional empty data frames (with power management bits set to 1) to indicate that it will return to power-saving mode.

[0118] Figure 10 illustrates the general format of a traditional PS-Poll frame. As shown, a PS-Poll frame includes a frame control field, an AID (or duration / ID) field, a BSS ID (RA) field, a TA field, and an FCS field. The frame control field indicates the type of frame. For PS-Poll frames, the frame subtype is set to 1010. The duration / ID field contains the AID, a numeric identifier assigned by the AP to the associated STA. This ID allows the AP to identify which frames are buffered for a waking STA. The BSS ID field includes the BSS identifier of the BSS currently associated with the AP. The TA field is the transmitter address field. This field stores the MAC address of the STA that is sending the PS-Poll frame. Note that PS-Poll frames do not include a duration field for updating the network allocation vector (NAV). Instead, the station receiving the PS-Poll frame updates its NAV timer based on the short inter-frame interval and the time required to transmit an acknowledgment (ACK) frame.

[0119] In power-saving mode, the PS-Poll frame allows the STA to notify the AP that it can wake up and is ready to receive frames from the AP. In some embodiments, the polling frame (e.g., PS-Poll frame) functionality can be extended when TXOP sharing opportunities are being shared between APs. Such an extended PS-Poll frame can be defined and used, having the ability to indicate available TXOP sharing opportunities. Essentially, this is used to query another AP (e.g., a sharing AP or other APs) whether they want an available TXOP (e.g., obtained anyway but available, such as when an obtained TXOP has been used but the TXOP duration remains available).

[0120] Figure 11A is a diagram illustrating the frame format of a PS Poll frame with available TXOP indication capability according to some embodiments. It includes the same fields as a conventional PS Poll frame (e.g., frame control, duration / ID, BSS-ID, TA, FCS). These fields can be used in the same manner as conventional PS Poll operations, but the duration / ID field can also be used by the AP to indicate that it has an available TXOP duration and to indicate the amount of time for that available duration.

[0121] In some embodiments, the most significant bit of this 16-bit field (e.g., bit 15) is used to indicate the duration of the available TXOP. In conventional applications, for example, when the STA wakes up and can receive buffered frames from the AP, bits 14 and 15 should be '11' for PS Poll operations, but when bit 15 is 0, the defined state is available and can be used to indicate the available TXOP state.

[0122] Figure 11B is a table illustrating the function of the Duration / ID field based on the values ​​of bits 14 and 15, according to some embodiments. As shown in the table, when both most significant bits are set to '11', the receiving station interprets the frame as a conventional power state PS-Poll operation. The 14 available low-order bits identify the AID value of the woken / awakened station. It is a unique identifier assigned to the station, ranging from 1 to 2007. It helps the AP identify which buffered frames belong to the woken station.

[0123] On the other hand, when a second AP (e.g., a sharing AP or another AP) receives a PS-Poll frame from a first AP (e.g., the shared AP or another AP) where bit 15 of the duration / ID field is '0', it is notified that the first (e.g., the shared) AP has available TXOP time (which is being offered to another AP for use). In this example, the amount of available TXOP time is indicated using the lower 15 bits (e.g., B0-B14). When the second (e.g., the sharing) AP receives a PS-Poll frame where bit 15 is equal to '0', and if the TA field identifier defines the address of the shared AP for which multi-AP sharing operation is defined, it can implicitly identify, when the second AP is the sharing AP, that it has transferred the sharing opportunity to the shared AP and is indicating the available TXOP duration. (Note that in other embodiments, if more or different functionality than simply indicating the available TXOP duration is required, two or more bits (e.g., the most significant bit) can be used in the polling frame to indicate the available TXOP. For example, when bit 15 is '0' and depends on the state of bit 14 ('0' or '1'), the available TXOP polling indication can be a general indication for any AP or a return indication for a shared AP. This leaves a smaller available range for the available TXOP duration (i.e., 14 bits), but this may be reasonable given the overall performance goals. In other embodiments, additional reserved subfields in the PS-Poll frame or any other polling frame (e.g., encapsulated in any suitable PPDU / MPDU (data, administration, and / or control) for polling) can be used to indicate the available TXOP to other APs.)

[0124] Figure 12 is a diagram illustrating the sequence of operations in which a sharing AP responds to an available sharing opportunity (TXOP) duration request frame when it wishes to receive a sharing opportunity request, according to some embodiments. At 1205, the shared AP sends an available sharing opportunity (TXOP) indication frame (PS Poll frame in this example). At 1210, the sharing AP responds by sending a frame (Self-CTS frame in this example) to indicate its desire for an available TXOP and causes the OBSS STA to set the basic NAV value. After transmitting the Self-CTS frame, the sharing AP (and the associated STA of the shared AP, not shown) can set the BSS internal NAV, while the OBSS STA can set the basic NAV value. In this way, the sharing AP and its associated STA can exchange frames (e.g., UL / DL transmission) during the transferred available TXOP duration.

[0125] Figure 13 is a diagram illustrating the sequence of operations in which a shared AP responds to a TXOP duration request frame when it does not want or need the available TXOP duration, according to some embodiments. In this example, when the shared AP does not want the available TXOP from the shared AP, the shared AP responds to the PS-Poll frame (1305) by sending an ACK frame to indicate that it does not want to use the TXOP. When the shared AP receives the ACK frame from the shared AP, in order to avoid wasting resources, it can send (in 1315) a frame such as a CF-End frame to release the channel, notifying the OBSS station that the channel is open.

[0126] Figure 14 is a diagram illustrating the sequence of operations when the sharing AP does not want to receive a sharing opportunity, according to some additional embodiments. If the sharing AP does not want to receive an available TXOP (1405), it can simply not send anything to the shared AP. This is not only a way for the sharing AP to reject an available TXOP, but it also explains why the sharing AP cannot hear the available TXOP indication frame (1405) from the shared AP. At 1410, if the shared AP does not hear any response frame from the sharing AP within a specific time period (e.g., PIFS), at 1415, it can send a CF-End frame to notify the station that the channel is open.

[0127] Figure 15A is a flowchart illustrating a method 1500 for a shared AP to indicate that it has a available TXOP duration, according to some embodiments. Method 1500 can be performed by the shared AP when interacting with the sharing AP or even with another AP different from the sharing AP. For this method and / or other methods described in this disclosure, one or two APs can be implemented by one or more devices described herein (e.g., wireless device 104). Furthermore, although shown in a specific order, in some embodiments, the operation of method 1500 (and other methods shown in the figures) can be performed in a different order. For example, although the operation of method 1500 is shown sequentially, some operations can be performed in partially or completely overlapping time periods.

[0128] In 1502, the shared AP sends a frame (e.g., a polling frame) to the AP (including the sharing AP) indicating that the shared AP has a available TXOP duration to share (e.g., for use by the sharing AP or other APs). In 1504, the shared AP determines whether the available TXOP is actually to be transferred or otherwise shared, i.e., whether the sharing AP or other APs want it. If not, in 1506, the shared AP sends a notification (e.g., a CF-End frame) to notify the STA that the channel is open. On the other hand, if the AP (e.g., the sharing AP or another AP) wants the available TXOP duration, in 1508, the shared AP sets the NAV (e.g., within the BSS) value to transfer channel access to the receiving (e.g., the sharing) AP. It may also perform other or additional frame transfers to acknowledge the exchange with the receiving AP.

[0129] Note that in 1504, the shared AP can determine, in any suitable manner, whether an AP such as the sharing AP wants an available sharing opportunity. For example, as shown in 1504A, it can wait for a period of time to determine if any AP will send a response. For example, it can wait to see if any AP sends a response within the time period corresponding to the PIFS (Point Coordination Function Inter-Frame Interval). In some embodiments, it can prioritize the sharing AP, and if it refuses or otherwise fails to respond within a period of time, it can offer the available TXOP duration to another station. If no response is received at all, the routine proceeds to 1506 and the channel is released.

[0130] On the other hand, if a response is received, the routine proceeds to step 1504B. Here, based on the response, it determines whether the shared AP accepts or rejects the available TXOP. The shared AP's response to this indication can be any suitable frame, including any suitable frame type. In some embodiments, a Self-CTS frame can be used to indicate acceptance, and in some embodiments, an ACK control frame can be used to indicate rejection.

[0131] When a receiving (e.g., sharing) AP wants a TXOP available, for example, a transmitted Self-CTS frame can cause the OBSS station to set a NAV (e.g., basic NAV) value. A Self-CTS frame can also cause the associated STA of the receiving AP and the TXOP transmitter (e.g., the AP being shared) to set a BSS internal NAV timer. (Other STAs, such as the OBSS, should set the basic NAV value.) In this way, the receiving AP and its associated STAs can exchange frames (e.g., UL / DL) for the available TXOP duration. In some embodiments, if there is a sufficient available TXOP duration, the receiving AP (e.g., the sharing AP) can even share the duration with another AP, and / or if the sharing AP does not want a TXOP available, the AP being shared can share it with other APs via polling frames. Following these ideas, in some embodiments, as described herein, polling frames can be used when any AP has a TXOP available for sharing. In other words, a shared AP can use polling frames to coordinate TXOP sharing with other APs, establish TXOP sharing with the shared AP before the shared AP uses the TXOP, and may share or return available TXOPs to other APs.

[0132] Returning to Figure 15A, at 1504B, based on the response, if the shared AP determines that TXOP is available, it will be transferred, the routine proceeds to 1508 and sets NAV to avoid contention with the receiving (e.g., shared) AP. On the other hand, if the response indicates rejection, the routine proceeds to 1506 and sends a notification that the channel is available.

[0133] Figure 15B is a flowchart illustrating a routine for a receiving AP to process an indication from an AP that it has an available TXOP duration, according to some embodiments. At 1522, it receives from a first (e.g., shared) AP a frame indicating that the first AP has an available TXOP duration that can be passed to a receiving (or potential receiving) AP. For example, the frame could be a polling frame as discussed above, such as a PSPoll frame. At 1524, it determines whether it wants (e.g., needs or can use) the available TXOP duration. If not, then at 1526, it sends a frame (e.g., a control frame) to the first (e.g., shared) AP indicating that it will not use the available TXOP duration. For example, it could send back an ACK frame. Alternatively, it could not send anything back to the shared AP, implicitly indicating that it will not use the available duration. On the other hand, if a second (receiving) AP wants the available TXOP duration, then at 1528, it sends a frame indicating acceptance and reservation of the channel for the TXOP duration. For example, as described above, it could send back a Self-CTS control frame. Example

[0134] Example 1 is a method comprising: in a first access point (AP) device, sending a polling frame indicating available sharing opportunities in the channel; determining whether the available sharing opportunities will be transferred to a second AP device; and if the available sharing opportunities will not be transferred, sending a control frame to release the channel.

[0135] Example 2 includes the topics covered in Example 1, and includes setting a network allocation vector (NAV) timer if it is determined that an available sharing opportunity will be transferred to a second AP device.

[0136] Example 3 includes the subject of any one of Examples 1 to 2, where the NAV timer is an internal NAV timer of the non-basic service set (BSS).

[0137] Example 4 includes the subject of any one of Examples 1 through 3, where the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

[0138] Example 5 includes the subject of any of Examples 1 through 4, where the polling frame is a power savepolling (PS-Poll) frame.

[0139] Example 6 includes the subject of any one of Examples 1 to 5, wherein the PS-Poll frame includes a duration / ID field with at least one bit value indicating that an available sharing opportunity is being offered to a second AP device.

[0140] Example 7 includes the subject of any of Examples 1 through 6, wherein the most significant bit of the duration / ID field is set to '0', indicating that an available sharing opportunity is being offered to the second AP device.

[0141] Example 8 includes the subject of any of Examples 1 through 7, wherein the duration / ID field includes multiple least significant bits indicating the duration of a segment of available sharing opportunities.

[0142] Example 9 includes the subject of any one of Examples 1 to 8, wherein determining whether an available sharing opportunity will be transferred to a second AP device includes: determining whether a response is received from the sharing AP device within a certain period of time.

[0143] Example 10 includes the subject of any one of Examples 1 through 9, where a period of time corresponds to the point coordination function interframe space (PIFS).

[0144] Example 11 includes the subject of any one of Examples 1 to 10, wherein determining whether an available sharing opportunity will be transferred to a second AP device includes: if a self-clear-to-send (Self CTS) frame is received from the sharing AP device, determining whether the sharing opportunity will be returned to the sharing AP.

[0145] Example 12 includes the subject of any of Examples 1 through 11, where the control frame is a contention-free end (CF-End) frame.

[0146] Example 13 is a non-transitory machine-readable medium storing instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of Examples 1 to 12.

[0147] Example 14 is a wireless device comprising: a baseband processor; an RF transceiver; and a storage device. The RF transceiver is coupled to the baseband processor. The storage device is coupled to the baseband processor and includes instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of Examples 1 to 12.

[0148] Example 15 is a method comprising: in a first access point (AP) device, sending a polling frame indicating available sharing opportunities in a channel; determining whether an available sharing opportunity will be passed to a second AP device; and if an available sharing opportunity will be passed to the second AP device, setting a network allocation vector (NAV) timer.

[0149] Example 16 includes the subject of Example 15, where a shared opportunity is a transmission opportunity (TXOP) shared opportunity.

[0150] Example 17 includes the subject of any of Examples 15 to 16, where the polling frame is a power savepolling (PS-Poll) frame.

[0151] Example 18 includes the subject of any of Examples 15 to 17, wherein the PS-Poll frame includes a duration / ID field with at least one bit value indicating that an available sharing opportunity is being offered to a second AP device.

[0152] Example 19 includes the subject of any of Examples 15 through 18, wherein the most significant bit of the duration / ID field is set to '0', indicating that an available sharing opportunity is being offered to a second AP device.

[0153] Example 20 includes the subject of any of Examples 15 through 19, wherein the duration / ID field includes multiple least significant bits indicating the duration of a segment of available sharing opportunities.

[0154] Example 21 includes the subject of any of Examples 15 to 20, wherein determining whether an available sharing opportunity will be delivered to the second AP device includes: determining whether a response is received from the second AP device within a certain period of time.

[0155] Example 22 includes the subject of any of Examples 15 through 21, where a period of time corresponds to the point coordination function interframe space (PIFS).

[0156] Example 23 includes the subject of any one of Examples 15 through 22, wherein determining whether an available sharing opportunity will be delivered to a second AP device includes: if the available sharing opportunity will be returned, receiving a Selfclear-to-send (Self CTS) frame from the sharing AP device.

[0157] Example 24 includes the subject of any of Examples 15 through 23, where the NAV timer is set in response to the receipt of a SelfCTS frame.

[0158] Example 25 is a non-transitory machine-readable medium storing instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of Examples 15 to 24.

[0159] Example 26 is a wireless device comprising: a baseband processor; an RF transceiver; and a storage device. The RF transceiver is coupled to the baseband processor. The storage device is coupled to the baseband processor and includes instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of Examples 15 to 24.

[0160] Example 27 is a method comprising: in a second access point (AP) device, wirelessly receiving, via a channel, a polling frame indicating available sharing opportunities from a first AP device; if the second AP device will use the available sharing opportunities, sending a first frame of access channel to the first AP device; and if the second AP device will not use the available sharing opportunities, instructing the first AP device that the second AP device will not use the available sharing opportunities.

[0161] Example 28 includes the subject of Example 27, wherein instructing a first AP device that a second AP device will not use available sharing opportunities includes sending a different control frame to the first AP device.

[0162] Example 29 includes the subject of any of Examples 27 to 28, where the different control frames are acknowledgment (ACK) frames.

[0163] Example 30 includes the subject of any of Examples 27 to 29, wherein instructing the first AP device that the second AP device will not use the available sharing opportunities includes: not sending a response to a polling frame.

[0164] Example 31 includes the subject of any of Examples 27 through 30, where the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

[0165] Example 32 includes the subject of any of Examples 27 through 31, where the polling frame is a power savepolling (PS-Poll) frame.

[0166] Example 33 includes the subject of any of Examples 27 to 32, wherein the PS-Poll frame includes a duration / ID field with at least one bit value indicating that an available sharing opportunity is being offered to a second AP device.

[0167] Example 34 includes the subject of any of Examples 27 through 33, wherein the most significant bit of the duration / ID field is set to '0' to indicate that an available sharing opportunity is being offered to a second AP device.

[0168] Example 35 includes the subject of any of Examples 27 through 34, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

[0169] Example 36 includes the subject of any of Examples 27 through 35, wherein the second AP device is a shared AP device and the first control frame is a self-clear-to-send (Self CTS) frame.

[0170] Example 37 is a non-transitory machine-readable medium storing instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of Examples 27 to 36.

[0171] Example 38 is a wireless device comprising: a baseband processor; an RF transceiver; and a storage device. The RF transceiver is coupled to the baseband processor. The storage device is coupled to the baseband processor and includes instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of Examples 27 to 36.

[0172] Example 39 is a method comprising: in the shared access point (AP) device, sending a first frame to the sharing AP device indicating the duration of an available sharing opportunity in a channel shared by the sharing AP and the shared AP; determining whether the available sharing opportunity duration will be returned to the sharing AP device; and if the sharing opportunity duration will not be returned, sending a second frame to release the channel.

[0173] Example 40 includes the subject of Example 39 and includes: setting a network allocation vector (NAV) timer if it is determined that the duration of the available sharing opportunity will be returned to the sharing AP device.

[0174] Example 41 includes the subject of any of Examples 39 to 40, where the NAV timer is an internal NAV timer of the non-basic service set (BSS).

[0175] Example 42 includes the subject of any of Examples 39 through 41, where the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

[0176] Example 43 includes the subject of any of Examples 39 through 42, where the first frame is a power savepolling (PS-Poll) frame.

[0177] Example 44 includes the subject of any of Examples 39 to 43, wherein the PS-Poll frame includes a duration / ID field with at least one bit value indicating that an available sharing opportunity is being offered to a sharing AP device.

[0178] Example 45 includes the subject of any of Examples 39 through 44, wherein the most significant bit of the duration / ID field is set to '0', indicating that an available sharing opportunity is being offered to the shared AP device.

[0179] Example 46 includes the subject of any of Examples 39 to 45, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

[0180] Example 47 includes the subject of any of Examples 39 to 46, wherein determining whether the duration of the available sharing opportunity will be returned to the shared AP device includes: determining whether a response is received from the shared AP device within a certain period of time.

[0181] Example 48 includes the subject of any of Examples 39 through 47, where a period of time corresponds to the point coordination function interframe space (PIFS).

[0182] Example 49 includes the subject of any one of Examples 39 to 8, wherein determining whether the available sharing opportunity duration will be returned to the sharing AP device includes: if the available sharing opportunity duration will be returned, receiving a Self clear-to-send (Self CTS) frame from the sharing AP device.

[0183] Example 50 includes the subject of any of Examples 39 to 49, where the second frame is a contention-free end (CF-End) frame.

[0184] Example 51 is a non-transitory machine-readable medium storing instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of Examples 39 to 50.

[0185] Example 52 is a wireless device comprising: a baseband processor; a radio frequency (RF) transceiver coupled to the baseband processor; and a storage device coupled to the baseband processor, the storage device including instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of Examples 39 to 50.

[0186] Example 53 is a method comprising: sending a first frame, in the shared access point (AP) device, to the sharing AP device, indicating the duration of available sharing opportunities in the channel; determining whether the available sharing opportunity duration will be returned to the sharing AP device; and if the available sharing opportunity duration will be returned to the sharing AP device, setting a network allocation vector (NAV) timer.

[0187] Example 54 includes the subject of Example 53, where a shared opportunity is a transmission opportunity (TXOP) shared opportunity.

[0188] Example 55 includes the subject of any of Examples 53 to 54, where the first frame is a power savepolling (PS-Poll) frame.

[0189] Example 56 includes the subject of any of Examples 53 to 55, wherein the PS-Poll frame includes a duration / ID field with at least one bit value indicating that an available sharing opportunity is being offered to a sharing AP device.

[0190] Example 57 includes the subject of any of Examples 53 to 56, wherein the most significant bit of the duration / ID field is set to '0', indicating that an available sharing opportunity is being offered to the shared AP device.

[0191] Example 58 includes the subject of any of Examples 53 to 57, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

[0192] Example 59 includes the subject of any of Examples 53 to 58, wherein determining whether the duration of the available sharing opportunity will be returned to the shared AP device includes: determining whether a response is received from the shared AP device within a certain period of time.

[0193] Example 60 includes the subject of any of Examples 53 to 59, where a period of time corresponds to the point coordination function interframe space (PIFS).

[0194] Example 61 includes the subject of any of Examples 53 to 60, wherein determining whether the available sharing opportunity duration will be returned to the sharing AP device includes: if the available sharing opportunity duration will be returned, receiving a Self clear-to-send (Self CTS) frame from the sharing AP device.

[0195] Example 62 includes the subject of any of Examples 53 to 61, where the NAV timer is set in response to receiving a SelfCTS frame.

[0196] While many of the solutions and techniques described herein have been referenced to WLAN systems, it should be understood that these solutions and techniques are also applicable to other network environments, such as cellular telecommunications networks, wired networks, etc. In some embodiments, the solutions and techniques provided herein may be, or may be embodied in, an article of manufacture in which instructions are stored on a non-transitory machine-readable medium (e.g., microelectronic memory) to program one or more data processing components (collectively referred to herein as “processors” or “processing units”) to perform the operations described herein. In other embodiments, some of these operations may be performed by specific hardware components containing hard-wired logic (e.g., dedicated digital filter blocks and state machines). These operations may alternatively be performed by any combination of programmed data processing components and fixed hard-wired circuit components.

[0197] In some cases, an embodiment may be an apparatus (e.g., an AP STA, a non-AP STA, or another network or computing device) including one or more hardware and software logic structures for performing one or more of the operations described herein. For example, as described herein, the apparatus may include a memory unit storing instructions executable by a hardware processor installed in the apparatus. The apparatus may also include one or more other hardware or software elements, including network interfaces, display devices, etc.

[0198] Some of the parts described in detail above have been presented in the form of algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the way that those skilled in the art of data processing use most effectively to convey the substance of their work to others skilled in the art. An algorithm here is, and is generally considered, a self-consistent sequence of operations that leads to a desired result. An operation is one that requires physical manipulation of physical quantities. Typically, though not always, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Primarily for general purposes, it has proven convenient to sometimes refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0199] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities. This disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within computer system registers and memories into other data similarly represented as physical quantities within computer system memory or registers or other such information storage devices.

[0200] This disclosure also relates to means for performing the operations described herein. Such means may be specifically constructed for the intended purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. For example, a computer system or other data processing system may perform the computer-implemented methods described herein in response to its processor executing a computer program (e.g., a sequence of instructions) contained in memory or other non-transitory machine-readable storage medium. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memories (ROMs), random access memories (RAM), EPROMs, EEPROMs, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0201] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs taught herein, or it can be demonstrated that it is convenient to construct more specialized devices to execute the methods. The structures of many of these systems will be described below. Furthermore, this disclosure is not directed to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using a variety of programming languages.

[0202] This disclosure can be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media include any mechanism for storing information in a machine-readable (e.g., computer-readable) form. In some embodiments, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory ("ROM"), random access memory ("RAM"), disk storage media, optical storage media, flash memory components, etc.

[0203] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific exemplary embodiments. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: In the first access point (AP) device, a polling frame indicating the available sharing opportunities in the channel is sent; Determine whether the available sharing opportunity will be transferred to the second AP device; If the available sharing opportunity is not to be transferred, send different frames to release the channel.

2. The method of claim 1, comprising: If it is determined that the available sharing opportunity will be transferred to the second AP device, set the Network Allocation Vector (NAV) timer.

3. The method of claim 2, wherein the NAV timer is an internal NAV timer of the Basic Service Set (BSS).

4. The method of claim 1, wherein the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

5. The method of claim 1, wherein the polling frame is a power-saving polling (PS-Poll) frame.

6. The method of claim 5, wherein the PS-Poll frame includes a duration / ID field having at least one bit value indicating that the available sharing opportunity is being provided to the second AP device.

7. The method of claim 6, wherein the most significant bit of the duration / ID field is set to '0' to indicate that the available sharing opportunity is being provided to the second AP device.

8. The method of claim 7, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

9. The method of claim 1, wherein determining whether the available sharing opportunity will be transferred to the second AP device comprises: Determine whether a response is received from the second AP device within a certain period of time.

10. The method of claim 9, wherein the time period corresponds to the Point Coordination Function Inter-Frame Interval (PIFS).

11. The method of claim 1, wherein determining whether the available sharing opportunity will be transferred to the second AP device comprises: If a Self-Allowed Transmit (Self CTS) frame is received from the shared AP device, it is determined whether the sharing opportunity will be returned to the shared AP.

12. The method of claim 1, wherein the different frames are contention-free end (CF-End) frames.

13. A non-transitory machine-readable medium having instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of claims 1 to 12.

14. A wireless device, comprising: Baseband processor; A radio frequency (RF) transceiver coupled to the baseband processor; A storage device coupled to the baseband processor, the storage device including instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of claims 1 to 12.

15. A method comprising: In the first access point (AP) device, a polling frame indicating the available sharing opportunities in the channel is sent; Determine whether the available sharing opportunity will be transferred to the second AP device; If the available sharing opportunity is to be passed to the second AP device, set the Network Allocation Vector (NAV) timer.

16. The method of claim 15, wherein the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

17. The method of claim 15, wherein the polling frame is a power-saving polling (PS-Poll) frame.

18. The method of claim 17, wherein the PS-Poll frame includes a duration / ID field having at least one bit value indicating that the available sharing opportunity is being provided to the second AP device.

19. The method of claim 18, wherein the most significant bit of the duration / ID field is set to '0' to indicate that the available sharing opportunity is being provided to the second AP device.

20. The method of claim 19, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

21. The method of claim 15, wherein determining whether the available sharing opportunity will be passed to the second AP device comprises: Determine whether a response is received from the second AP device within a certain period of time.

22. The method of claim 21, wherein the time period corresponds to the Point Coordination Function Inter-Frame Interval (PIFS).

23. The method of claim 15, wherein determining whether the available sharing opportunity will be passed to the second AP device comprises: If the available sharing opportunity is to be delivered, receive a Self-Allowed Transmission (Self CTS) frame from the shared AP device.

24. The method of claim 23, wherein the NAV timer is set in response to receiving the Self CTS frame.

25. A non-transitory machine-readable medium having instructions that, when executed, perform the method as claimed in any one of claims 15 to 24.

26. A wireless device, comprising: Baseband processor; A radio frequency (RF) transceiver coupled to the baseband processor; A storage device coupled to the baseband processor, the storage device including instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of claims 15 to 24.

27. A method comprising: In the second access point (AP) device, polling frames indicating available sharing opportunities are received wirelessly from the first AP device via a channel; If the second AP device will use the available sharing opportunity, it sends a first frame to the first AP device to access the channel; and if the second AP device will not use the available sharing opportunity, it indicates to the first AP device that the second AP device will not use the available sharing opportunity.

28. The method of claim 27, wherein instructing the first AP device that the second AP device will not use the available sharing opportunity comprises: Different frames are sent to the first AP device.

29. The method of claim 28, wherein the different frame is an acknowledgment (ACK) frame.

30. The method of claim 27, wherein instructing the first AP device that the second AP device will not use the available sharing opportunity comprises: No response is sent to the polling frame.

31. The method of claim 27, wherein the shared opportunity is a transmission opportunity (TXOP) shared opportunity.

32. The method of claim 27, wherein the polling frame is a power-saving polling (PS-Poll) frame.

33. The method of claim 32, wherein the PS-Poll frame includes a duration / ID field having at least one bit value indicating that the available sharing opportunity is being offered to the second AP device.

34. The method of claim 33, wherein the most significant bit of the duration / ID field is set to '0' to indicate that the available sharing opportunity is being offered to the second AP device.

35. The method of claim 34, wherein the duration / ID field includes a plurality of least significant bits indicating the duration of a segment of available sharing opportunities.

36. The method of claim 27, wherein the second AP device is a shared AP device, and the first frame is a self-permitted transmission (Self CTS) frame.

37. A non-transitory machine-readable medium having instructions that, when executed by a wireless device, cause the wireless device to perform the method as described in any one of claims 27 to 36.

38. A wireless device, comprising: Baseband processor; A radio frequency (RF) transceiver coupled to the baseband processor; A storage device coupled to the baseband processor, the storage device including instructions that, when executed by the baseband processor, cause the baseband processor to perform the method as described in any one of claims 27 to 36.

Images