Protection mechanism during TXOP sharing process between collaborative multiple APs

Abstract

Techniques are provided that may enable an STA that may be associated with a shared AP to utilize a channel without excessive waiting without adversely affecting transactions involving the shared AP. Therefore, the overall medium utilization rate can be improved under the condition that no unreasonable problem interference risk exists. In certain aspects, a method includes generating, in a first access point (AP) device, a trigger frame having a transmission sharing opportunity (TXOP), the TXOP having an associated TXOP duration, the frame including a MAC header timer duration that is less than the TXOP duration, and wirelessly transmitting the sharing opportunity trigger frame to one or more other access points (APs).

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 584,420, filed September 21, 2023, which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically, to protection of transmission opportunity sharing in wireless networks. Background Technology

[0004] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard is a set of standards for enabling wireless local area network (WLAN) communication at various frequencies, including but not limited to the 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz bands. These standards define the protocols that enable Wi-Fi devices to communicate with each other. The IEEE 802.11 standard family has evolved over time to accommodate higher data rates, improved 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 that facilitate interoperability between devices from various manufacturers. IEEE 802.11 has played a significant role in the widespread adoption of wireless networking in homes, offices, and public places, enabling users to connect their devices to the internet and interconnect without wired connections.

[0005] IEEE 802.11be, also known as "Wi-Fi 7," is the next-generation standard in the IEEE 802.11 family of standards for wireless local area networks. Currently under development, 802.11be aims to significantly improve upon its predecessor, 802.11ax / Wi-Fi 6, by providing even higher data rates, lower latency, and increased reliability. The standard is expected to utilize advanced technologies such as Multi-Link Operation (MLO), which allows devices to use multiple frequency bands and channels simultaneously for enhanced performance and reliability. Furthermore, 802.11be will introduce 4096-QAM (Quadrature Amplitude Modulation), achieving higher data rates by encoding more bits for each symbol. The standard also features improved Media Access Control (MAC) efficiency, enhanced energy efficiency, and better support for high-density environments. With these advancements, 802.11be is expected to deliver data at theoretical maximum rates of up to 46 gigabits per second (Gbps), making it suitable for bandwidth-intensive applications such as virtual reality, augmented reality, 8K video streaming, and high-performance gaming. The IEEE 802.11be standard is expected to be completed by the end of 2024, paving the way for next-generation Wi-Fi devices and networks. Attached Figure Description

[0006] This disclosure will be more fully understood from the detailed description provided below and the accompanying drawings depicting various embodiments of the present disclosure. However, these drawings should not be construed as limiting the disclosure to the specific embodiments shown; they are provided for explanation and understanding only.

[0007] Figure 1A It is a diagram showing a single BSS with AP and multiple non-AP STAs.

[0008] Figure 1B This is a table showing the operating parameters for various WiFi versions prior to 802.11bn.

[0009] Figure 2 This is a block diagram illustrating a wireless device according to certain embodiments.

[0010] Figure 3A This is a diagram illustrating components of a WLAN device configured to transmit data according to certain embodiments.

[0011] Figure 3B This is a diagram illustrating components of a WLAN device configured to receive data according to certain embodiments.

[0012] Figure 4 This is a diagram illustrating the inter-frame spacing (IFS) relationship for WiFi transmission according to certain embodiments.

[0013] Figure 5This is a diagram illustrating a frame transmission process based on Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) according to certain embodiments, which is used to avoid collisions between frames in the channel.

[0014] Figure 6A This is a diagram illustrating the general structure of a trigger frame according to certain embodiments.

[0015] Figure 6B This is a diagram illustrating an example triggered frame uplink (UL) transmission scenario according to certain embodiments.

[0016] Figure 6C An example trigger frame downlink (UL) transmission scenario is shown according to certain embodiments.

[0017] Figure 7A and 7B The general structures of EHT (WiFi 7) multi-user and trigger-based physical layer protocol data unit (PPDU) frames according to certain embodiments are shown respectively.

[0018] Figure 7C It is a table that lists the fields for TB PPDU and their associated information according to certain embodiments.

[0019] Figure 7D It is a table listing descriptions and information of subfields in the General Signal (U-SIG) field for MU or TB PPDU frames according to certain embodiments.

[0020] Figure 8 This is a diagram illustrating three BSSs with overlapping coverage areas according to certain embodiments.

[0021] Figure 9 This illustrates the third-party competition rules involved in using traditional channels. Figure 8 A diagram showing the TXOP transmissions of the STA and AP in the three BSSs.

[0022] Figure 10A This illustrates the implications according to certain embodiments. Figure 8 A diagram of TXOP transmissions for STA and AP, which allows OBSS sites to reset their NAV timers well before the TXOP duration expires.

[0023] Figure 10B This is a diagram illustrating an RTS-TXS trigger frame with a multi-AP shared indicator according to certain embodiments.

[0024] Figure 10C This is a diagram illustrating a conventional MU-RTS-TXS frame with a multi-AP sharing indicator according to certain embodiments.

[0025] Figure 10D and10E This is a diagram illustrating the MU and TB PPDU frame structure, which may include a multi-AP sharing indicator, according to certain embodiments.

[0026] Figure 11A This illustrates the implications according to certain embodiments. Figure 8 The diagram shows the TXOP transmissions of the STA and AP, but the shared AP has a reduced NAV duration.

[0027] Figure 11B This is a diagram illustrating a MU-RTS-TXS frame according to certain embodiments, which has an allocated duration subfield for setting a small NAV timer.

[0028] Figure 12A This is a flowchart illustrating a routine for generating a TXOP trigger frame for an AP according to certain embodiments.

[0029] Figure 12B This is a flowchart illustrating a routine for an AP to generate RTS TXS frames for multiple APs to share, according to certain additional embodiments.

[0030] Figure 12C This is a flowchart illustrating a routine for a site to process TXOP trigger frames in a multi-AP sharing scenario, according to certain embodiments. Detailed Implementation

[0031] As mentioned above, some goals of next-generation wireless networking standards (e.g., versions other than IEEE 802.11bn or IEEE 802.11be) include increasing data rates and range. However, increasing data rates and improving range are often competing goals (there is a trade-off between data rates and range). As will be discussed below, in multi-access point (AP) sharing scenarios, when APs and non-AP sites (STAs) are at least partially within range of other Basic Service Sets (BSS) but do not conflict with sites involved in sharing activities, some rules applicable to previous and existing WiFi implementations impose inconvenient channel access restrictions on these APs and non-AP STAs. In some cases, these sites are forced to wait excessively long Network Allocation Vector (NAV) periods before attempting to access the channel. Therefore, in some embodiments, techniques are provided that enable STAs associated with a shared AP to utilize the channel without excessive waiting without adversely affecting transactions involving the shared AP. This improves overall media utilization without the risk of unreasonable interference.

[0032] In the following detailed description, certain embodiments of the invention are shown and described by way of example only. Those skilled in the art will recognize that the described embodiments can be modified in different ways without departing from the spirit or scope of the invention. Therefore, the drawings and description should be considered exemplary rather than restrictive in nature. Throughout the specification, similar reference numerals denote similar elements.

[0033] Figure 1A A wireless local area network (WLAN) 100 is shown, having a basic service set (BSS) 102 that includes multiple wireless devices 104 (sometimes referred to as WLAN devices 104). Each wireless device 104 may include a media access control (MAC) layer and a physical (PHY) layer according to IEEE (Institute of Electrical and Electronics Engineers) standard 802.11, which includes one or more amendments (e.g., 802.11a / b / g / n / p / ac / ax / bd / be). In one embodiment, the MAC layer of wireless device 104 can initiate the transmission of a frame to another wireless device 104 by passing a PHY-TXSTART.request (TXVECTOR) to the PHY layer. The TXVECTOR provides parameters for generating and / or transmitting the corresponding frame. Similarly, the PHY layer of a receiving wireless device can generate an RXVECTOR that includes parameters of the received frame and is passed to the MAC layer for processing.

[0034] Multiple wireless devices 104 may include wireless device 104A acting as an access point (sometimes referred to as an AP site or AP STA), and other wireless devices 104B1 to 104B4 acting as non-AP sites (sometimes referred to as non-AP STAs). Alternatively, in an ad hoc networking environment, all these 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 will be referred to as STAs. Although four non-AP STAs (e.g., wireless devices 104B1 to 104B4) are shown in the figure, WLAN 100 may include any number of non-AP STAs (e.g., one or more wireless devices 104B).

[0035] Figure 1B This is a table showing the operating parameters for various WiFi versions prior to 802.11bn (also known as WiFi 8 or UHR (Ultra-High Reliability)). The IEEE 802.11bn (UHR) working group was formed to address the growing need for higher peak throughput and reliability in Wi-Fi. Figure 1BAs shown, the peak PHY rate increases significantly from IEEE 802.11b to IEEE 802.11be (WiFi 7), with the latter focusing on further improving peak throughput. The UHR research group aims to enhance the tail and jitter of the latency distribution to support applications requiring low latency, such as video, gaming, augmented reality (AR), and virtual reality (VR) over WLAN. It is worth noting that various characteristics of UHR, such as maximum PHY rate, PHY rate enhancement, bandwidth / number of spatial streams, and operating frequency band, are still under consideration.

[0036] The focus of IEEE 802.11be (EHT or WiFi 7) is primarily on indoor and outdoor WLAN operation at fixed and walking speeds in the 2.4, 5, and 6 GHz bands. In addition to peak PHY rates, various candidate features are currently under discussion. These candidate features include: (1) more efficient use of 320 MHz bandwidth and discontinuous spectrum; (2) multi-band / multi-channel aggregation and operation; (3) enhanced 16 spatial streams and multiple-input multiple-output (MIMO) protocols; (4) multi-access point (AP) collaboration (e.g., collaborative 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.

[0037] The focus of IEEE 802.11bn (UHR) is still under discussion, with candidate features including multi-link opportunity (MLO) enhancements (e.g., in terms of improved throughput / reliability and reduced latency), latency and reliability improvements (e.g., supporting low-latency traffic through multi-AP collaboration), bandwidth extensions (e.g., to 240, 480, 640 MHz), polymer physical layer protocol data units (A-PPDU), enhanced multi-link single radio (eMLSR) extensions for APs, roaming improvements, and energy-saving solutions to extend battery life.

[0038] Some features, such as increased bandwidth and spatial stream quantity, are solutions that have proven effective in previous projects that focused on improving link throughput and whose feasibility has been validated.

[0039] 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 an additional unlicensed spectrum exceeding 1 GHz available. This would allow APs and STAs to become tri-band devices. Data transmission speeds greater than 160 MHz (e.g., 320 MHz or 640 MHz) could 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 across the 5 GHz and 6 GHz bands.

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

[0041] Figure 2 A schematic block diagram of a wireless device 104 according to an embodiment is shown. Wireless device 104 can be wireless device 104A (i.e., the access point of WLAN 100) in FIG1 or any of wireless devices 104B1 to 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.

[0042] 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 storing software (such as computer / machine programming instructions) and data.

[0043] 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 set of multiple 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 set of multiple functions of the MAC layer in dedicated hardware. However, the MAC processor 212 is not limited thereto. For example, depending on the implementation, the MAC processor 212 may be configured to execute the first and second sets of multiple functions entirely in software or entirely in hardware.

[0044] PHY processor 222 includes a transmit (TX) signal processing unit (SPU) 224 and a receive (RX) SPU 226. PHY processor 222 implements multiple functions of the PHY layer. Depending on the implementation, these functions may be performed in software, hardware, or a combination thereof.

[0045] The functions performed by the transmitting SPU 224 may include one or more of the following: forward error correction (FEC) coding, parsing a stream into one or more spatial streams, diversity coding of a spatial stream into multiple spatiotemporal streams, spatial mapping of spatiotemporal streams to a transport chain, inverse Fourier transform (iFT) calculation, and cyclic prefix (CP) insertion to create a guard interval (GI). The functions performed by the receiving SPU 226 may include the inverse operations of the functions performed by the transmitting SPU 224, such as GI removal and Fourier transform calculation.

[0046] 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 in WLAN 100) and to provide second information received from WLAN 100 (e.g., from another WLAN device 104 in WLAN 100) to baseband processor 210.

[0047] 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, and may be fixed or adjustable.

[0048] Input interface 234 receives information from the user, while 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.

[0049] 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 on 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.

[0050] As described herein, the functions of the components of WLAN device 104 can be implemented using a variety of electronic devices, circuits, firmware, software, and combinations thereof. Furthermore, WLAN device 104 may include other components such as application processors, storage interfaces, clock generator circuits, power supply circuits, etc., descriptions of which are omitted here for brevity.

[0051] Figure 3A The diagram illustrates components of a WLAN device 104 configured to transmit data according to an embodiment, including a transport (Tx) SPU (TxSP) 324, an RF transmitter 342, and an antenna 352. In this embodiment, the TxSP 324, RF transmitter 342, and antenna 352 respectively correspond to... Figure 2 The antenna of the transmission SPU 224, RF transmitter 242 and antenna unit 250.

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

[0053] 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 convolutional code (BCC) encoder followed by a punching device. The FEC encoder may include a low-density parity check (LDPC) encoder.

[0054] The TxSP 324 may also 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 also 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.

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

[0056] Mapper 304 maps the bit sequence 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.

[0057] When the TxSP 324 performs MIMO or MU-MIMO transmission, it may include multiple interleavers 302 and multiple mappers 304 depending on the number of spatial streams (NSS) transmitted. The TxSP 324 may also include a stream resolver for dividing the output of the encoder 300 into multiple blocks and sending these blocks to different interleavers 302 or mappers 304. The TxSP 324 may also include: a spatial-temporal block code (STBC) encoder for spreading constellation points from the spatial streams to multiple spatial-temporal streams (NSTS); and a spatial mapper for mapping the spatial-temporal streams to a transport chain. The spatial mapper may use direct mapping, spatial spreading, or beamforming.

[0058] IFT 306 converts blocks of constellation points output from mapper 304 (or, in the case of MIMO or MU-MIMO, from the spatial mapper) into temporal blocks (i.e., symbols) using inverse discrete Fourier transform (IDFT) or inverse fast Fourier transform (IFFT). If an STBC encoder and a spatial mapper are used, IFT 306 can be provided for each transport chain.

[0059] When the TxSP 324 performs MIMO or MU-MIMO transmissions, it can insert cyclic shift diversity (CSD) to prevent unintended beamforming. The TxSP 324 can insert the CSD before or after IFT 306. The CSD can be specified per transport chain or per spatial-temporal stream. Alternatively, the CSD can be applied as part of the spatial mapper.

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

[0061] The GI inserter 308 adds a GI before each symbol generated by the IFT 306. Each GI may include a cyclic prefix (CP), which corresponds to the repeating portion at the end of the symbol preceding the GI. After inserting the GI, the TxSP 324 may optionally perform windowing to smooth the edges of each symbol.

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

[0063] Figure 3BThe diagram illustrates 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 this embodiment, the RxSP 326, RF receiver 344, and antenna 354 may correspond to... Figure 2 The antenna of the receiving SPU 226, RF receiver 244 and antenna unit 250.

[0064] The RxSP 326 includes a GI remover 318, a Fourier transform (FT) 316, a demapper 314, a deinterleaver 312, and a decoder 310.

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

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

[0067] When the received transmission is a MIMO or MU-MIMO transmission, the RxSP326 may include: a spatial demapper for converting the individual outputs of the FT 316 of the receive chain into constellation points of multiple spatial-temporal streams; and an STBC decoder for despreading the constellation points from the spatial-temporal streams to one or more spatial streams.

[0068] 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 also perform LDPC tone modulation mapping before performing constellation demapping.

[0069] Deinterleaving unit 312 deinterleaves bits of each stream output from demapping unit 314. Deinterleaving unit 312 performs deinterleaving only if the received transmission is encoded using BCC encoding; otherwise, it can output the stream output from demapping unit 314 without performing deinterleaving.

[0070] 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 also include a stream inverse parser for merging the streams output from the deinterleavers 312.

[0071] Decoder 310 decodes the stream output by deinterleaver 312 or stream inverse parser. In an embodiment, decoder 310 includes an FEC decoder. The FEC decoder may include a BCC decoder or an LDPC decoder.

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

[0073] Before transmission, the wireless device (such as wireless device 104) uses idle channel assessment (CCA) to evaluate the availability of the wireless medium. If the medium is occupied, CCA determines that it is busy; if the medium is available, CCA determines that it is idle.

[0074] The IEEE 802.11 PHY entities are based on Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA). In the OFDM or OFDMA physical 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 Process (PLCP) Protocol Data Units). The PHY specification defines a 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 spatial-time streams (STS) per user, using up to a predetermined total number of STSs. PHY entities can support continuous channel widths of 10 MHz, 20 MHz, 40 MHz, 80 MHz, 160 MHz, 240 MHz, and 320 MHz, and discontinuous channel widths of 80+80 MHz, 80+160 MHz, and 160+160 MHz. Each channel comprises multiple subcarriers, which may also be referred to as tones. The PHY entity can define signaling fields within the PPDU, such as Legacy Signal (L-SIG), Signal A (SIG-A), and Signal B (SIG-B), through which necessary information about the PHY Service Data Unit (PSDU) attributes is conveyed. For completeness and brevity, the following description refers to OFDM-based 802.11 technology. Unless otherwise specified, "site" refers to a non-AP STA.

[0075] Figure 4 This illustrates the inter-frame spacing (IFS) relationship. Specifically, Figure 4The diagram 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 Class (AC) "i". Figure 4 The time slot duration is also shown, and the data frame is used to transmit data forwarded to higher layers. As shown, if DIFS has passed (during which the medium is idle), the WLAN device 104 transmits the data frame after performing a backoff.

[0076] Management frames are used to exchange management information that is not forwarded to higher levels. Subtypes of management frames include beacon frames, association request / response frames, probe request / response frames, and authentication request / response frames.

[0077] 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 Acknowledge (ACK) frames.

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

[0079] If the AIFS of the associated Access Class (AC) (i.e., AIFS[AC]) has passed, the WLAN device 104 (i.e., QoS STA) that supports Quality of Service (QoS) can transmit the frame after performing backoff. When transmitted by the QoS STA, any of the data frames, management frames, and control frames (not response frames) can use the AIFS[AC] of the AC of the transmitted frame.

[0080] When a WLAN device 104 preparing to transmit a frame detects that the medium is busy, the WLAN device 104 may perform a backoff procedure. The backoff procedure includes determining a random backoff time consisting of N backoff slots, where the duration of each backoff slot is equal to the slot time, and N is an integer greater than or equal to zero. The backoff time may be determined based on the length of the contention window (CW). In an embodiment, the backoff time may be determined based on the frame's AC (Acceptance Time). All backoff slots occur after a DIFS (Distributed Incoming Window) or Extended IFS (EIFS) period, during which the medium is determined to be idle for the duration of that period.

[0081] When WLAN device 104 does not detect media activity for the duration of a specific backoff time slot, the backoff process should reduce the backoff time by the time slot duration. When WLAN device 104 determines that the media is busy during the backoff time slot, the backoff process will be suspended until it is determined again that the media is 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.

[0082] The backoff process works as follows: when multiple WLAN devices 104 postpone and execute 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 wins the competition, thereby reducing the probability of conflict.

[0083] Figure 5 The illustration shows a frame transmission process based on Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) according to an embodiment, used to avoid collisions between frames in the channel. Figure 5 The diagram illustrates a first station STA1 for transmitting data, a second station STA2 for receiving data, and a third station STA3. These stations can be located in areas where they can receive frames transmitted from STA1, frames transmitted from the second station STA2, or both. These stations STA1, STA2, and STA3 can be the WLAN device 104 shown in Figure 1.

[0084] Station STA1 can determine whether the channel is busy by 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 by using a network allocation vector (NAV) timer.

[0085] 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 may send a Request to Send (RTS) frame to station STA2. Upon receiving the RTS frame, station STA2 may send a Clear to Send (CTS) frame in response to the RTS frame, after SIFS. If Dual-CTS is enabled and station STA2 is an AP, the AP may send two CTS frames in response to the RTS frame (e.g., the first CTS frame is in a non-high-throughput format, and the second CTS frame is in a high-throughput (HT) format).

[0086] When station STA3 receives an RTS frame, it can use the duration information included in the RTS frame to set its NAV timer for the duration of subsequent transmitted frames (e.g., SIFS duration + 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 for the duration of subsequent transmitted frames. If a new frame is received before the NAV timer expires, station STA3 can update its NAV timer by using the duration information included in the new frame. Station STA3 will not attempt to access the channel before the NAV timer expires.

[0087] When station STA1 receives a CTS frame from station STA2, it can transmit 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 transmit an ACK frame as a response to the data frame after the SIFS period has elapsed.

[0088] When the NAV timer expires, the third site 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 following the NAV timer expiration, site STA3 can attempt to access the channel after the contention window has passed, following the backoff process.

[0089] When Dual-CTS is enabled, a station that has acquired a Transmission Opportunity (TXOP) but has no data to transmit can transmit a CF-End frame to shorten the TXOP. An AP receiving a CF-End frame with its Basic Service Set Identifier (BSSID) as the destination address can respond by transmitting two CF-End frames: the first CF-End frame uses a Spatial Time Block Code (STBC), while the second CF-End frame uses a non-STBC. The station receiving the CF-End frame resets its NAV timer to 0 at the end of the PPDU containing that CF-End frame. Figure 5 The example demonstrates how station STA2 transmits an ACK frame to confirm that the receiver has successfully received the frame.

[0090] Figure 6AThis is a diagram illustrating the general structure of a trigger frame. A trigger frame is a control frame whose function is to allocate resources and request the transmission of one or more trigger-based (TB) Physical Layer Protocol Data Units (PPDUs) from associated sites (including both APs and / or non-AP STAs). APs use them, among other things, to allocate resources for multi-user Orthogonal Frequency Division Multiple Access (OFDMA) transmissions. They specify how bandwidth and time slots are divided among multiple STAs, enabling simultaneous data transmission by multiple users without interference. This is important for improving overall network efficiency and throughput, especially in high-user-density environments.

[0091] As shown in the figure, a trigger frame typically includes several distinct parts, including a MAC (Media Access Control) 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, these may include Frame Control (FC), Duration (or Duration / ID), Receiver Address (RA), and Transmitter Address (TA) fields, as shown in the figure. 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 of media retention, or, in some implementations and contexts, it may carry an Association Identifier (AID). The RA field indicates the address of the receiving STA, while the TA field indicates the address of the transmitting STA. The MAC header may also include fields for sequence and QoS control.

[0092] Trigger frames have specific subfields within the frame control field 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 characteristics and operational requirements, especially in multi-user scenarios where collaboration is important for efficient communication.

[0093] The common information section 610 includes parameters such as expected uplink length, bandwidth, guard interval, and transmission power used by the AP. These parameters help the STA prepare for its upcoming transmissions.

[0094] Different fields in the Public Information field are used to inform the responding STA how they set up 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 of the subfields in the Public Information field of MU-RTS may not be needed. For the included subfields, for MU-RTS requests, the Trigger Type is set to 3; More TF is used for TWT or to utilize UORA power saving (otherwise set to 00); "CS Required" is set to 0 if the responding STA does not need to consider the medium or NAV when determining whether to respond; "CS Required" is set to 1 if the responding STA needs to use ED (Energy Detection) to sense and consider the medium and NAV when determining whether to respond. 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, and 3=80+80 MHz or 160 MHz).

[0095] 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 Expected Received Signal Strength Indicator (RSSI). This information allows each STA to understand its specific transmission parameters. The AID 12 field indicates the STA-id (Association ID) for each receiver. Other values ​​used in this space are used in other variations of the trigger frame. The RU allocation is used to indicate on which primary channel the response CTS should be transmitted. This is specific to 40 MHz and 80 MHz channels, regardless of whether the primary channel is the lowest, second lowest, or other channel. User information fields are typically repeated for each STA acting as a receiver in the MU-RTS. The receiving STA is addressed by its Association ID (STA-id), not by its MAC address as in a traditional RTS. Depending on the specific trigger frame type, there may be additional information. User information fields in trigger frames (such as MU-RTS trigger frames) may also include an allocation duration subfield. This subfield indicates the time allocated by the AP for the STA to transmit during the TXOP. This field may 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.

[0096] Figure 6BThis illustrates an example trigger frame uplink (UL) transmission scenario according to certain embodiments. In versions of the IEEE 802.11 specification since 802.11ax (WiFi 6), trigger frames play a useful role in facilitating uplink and downlink multi-user (MU) transmissions.

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

[0098] use Figure 6B In an example scenario, 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 (Clear Send) 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 using the 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 STAs that have responded appropriately. From there, the STAs utilize the allocated resources within the specified 80 MHz bandwidth to transmit Orthogonal Frequency Division Multiple Access (UL OFDMA) TB PPDUs. Upon successfully receiving the UL OFDMA TB PPDU, the AP acknowledges the STA by sending an acknowledgment frame. This acknowledgment can be in the format of an 80 MHz wide multi-STA block acknowledgment (Block Ack) or a block acknowledgment using the Direct Feedback (DF) OFDMA method. Multi-STA block acknowledgment allows the AP to acknowledge multiple STAs simultaneously, while block acknowledgment using DF OFDMA enables the AP to provide feedback to STAs using the same OFDMA technology used in uplink transmissions.

[0099] Figure 6C This illustrates an example triggered frame downlink (DL) transmission scenario according to certain embodiments. It is similar to the uplink process, but differs in that it facilitates bulk data transfer from the AP to the STA, rather than from the STA to the AP. The AP sends a multi-user RTS, such as a MU RTS-TXS, to the STA to request a downlink transmission to the STA. The process begins with the AP sending a MU RTS-TXS trigger frame to a non-AP STA. Upon receiving this frame, the STA anticipates a response using a CTS frame, indicating its readiness to receive data. From there, the AP transmits a MU PPDU to the responding STA, which includes the data intended for the STA. Finally, the STA responds using an acknowledgment frame returned to the AP.

[0100] Figure 7A and 7B The general structures of EHT (WiFi 7) multi-user and trigger-based Physical Layer Protocol Data Unit (PPDU) frames are shown respectively. (It is expected that the UHR PPDU will be the same or similar. For simplicity, EHT examples may be used here and elsewhere in this disclosure, but it should be understood that the UHR and later specification parameters can be implemented in the same way.) Reference Figure 7A A MUPPDU can be sent to a single user or multiple users. The frame has a traditional (705A) and modern (710A) preamble portion, as well as data and packet extension field portions. The traditional portion includes the Traditional Short Training Field (L-STF), Traditional Long Training Field (L-LTF), and Traditional Signaling Field (L-SIG). The modern portion includes the Universal Signaling Field (U-SIG), EHT Signaling Field (EHT-SIG), EHT Short Training Field (EHT-STF), EHT Long Training Field (EHT-LTF), the data field for the actual data payload, and the Packet Extension (PE) field. The EHT-SIG field, together with the U-SIG field, provides resource unit (RU) allocation and other information required 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.

[0101] refer to Figure 7B Upon 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 includes a repeated legacy (RL) signal field in the legacy section. Furthermore, to improve uplink transmission performance and reliability, the EHT-STF field can be twice as long as that in the EHT MU PPDU. Figure 7C It is a table that lists the fields used for TB PPDU and additional information. Figure 7D It is a table that lists the descriptions and information of the subfields in the Universal Signal (U-SIG) field for MU or TB PPDU frames.

[0102] The preamble is a design component used to provide relevant information for the receiver to decode the transmitted data. It also provides backward compatibility with previous PHY versions. However, the preamble does not typically convey the PHY version of the packet directly. Automatic detection (or spoofing) mechanisms have been created for the receiver to implicitly determine the PHY version. However, these automatic detection algorithms have become increasingly complex. EHT attempts to address this issue using the Universal Signaling (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-dependent bits. The version-independent bits are the first 20 bits of the U-SIG and have the same position and definition for both the EHT and subsequent PHYs. The first three bits (bits 0 to 2) identify the PHY version, simplifying 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) signals the link direction (i.e., uplink or downlink). The next 6 bits (bits 7 to 12) indicate the Basic Service Set (BSS) being used via BSS color, while the 7 TXOP bits (bits 13 to 19) provide information about the media usage time of the PPDU. The remainder of the U-SIG bits / fields depends on the PHY version and PPDU type.

[0103] To provide flexibility and prepare for potential new capabilities, 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. Ignoring means ignoring the bit and continuing reception. Verifying means checking if the bit matches a known value, and if not, terminating reception. For example, values ​​1 through 7 in the PHY version identifier field would correspond to future IEEE 802.11 PHY versions that devices supporting the current EHT version cannot recognize. If a baseline EHT device receives a value other than 0 (0 indicates an EHT PHY), that device should stop receiving.

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

[0105] There are two methods for handling HARQ. In the first HARQ scheme, also known as chase-and-comb (CC) HARQ (CC-HARQ), the signal to be retransmitted is the same as the previously failed signal because all sub-packets to be retransmitted use the same pruning pattern. After encoding with error correction codes, pruning is required to remove some parity bits. The reason for using the same pruning pattern as CC-HARQ is to utilize forward error correction (FEC) to generate the encoded data sequence 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, in the presence of burst errors, the ARQ scheme can be inefficient. To address this problem more effectively, sub-packets are used. In sub-packet transmission, only those sub-packets containing errors need to be retransmitted.

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

[0107] In the second HARQ scheme, also known as Incremental Redundancy (IR) HARQ (IR-HARQ), each sub-packet uses a different pruning mode, resulting in a signal variation in each retransmitted sub-packet compared to the original. IR-HARQ alternates between two pruning modes, one for odd-numbered transmissions and one for even-numbered transmissions. The redundancy scheme of IR-HARQ improves the log-likelihood ratio (LLR) of the parity bits to combine information sent via different transmissions due to requests, and reduces the code rate due to the use of additional sub-packets. This reduces the sub-packet error rate compared to CC-HARQ. The pruning mode used in IR-HARQ is indicated by the Sub-packet Identifier (SPID). The SPID of the first sub-packet can always be set to 0, and all system bits and pruned parity bits are transmitted in the first sub-packet. Self-decoding is possible when the received signal-to-noise ratio (SNR) environment is good (i.e., high SNR). In some embodiments, the sub-packets to be transmitted with corresponding SPIDs are arranged in ascending order of SPIDs, but except for the first SPID, the other sub-packets can be swapped / switched.

[0108] In the IEEE 802.11be standard, AP collaboration is considered a potential technology to improve the throughput of WLAN systems, while in the IEEE 802.11bn (UHR) standard, AP collaboration is still under discussion. To support various AP collaboration schemes, such as cooperative beamforming, OFDMA, TDMA, spatial multiplexing, and joint transmission, predefined mechanisms for APs are desired.

[0109] In a Cooperative TDMA (C-TDMA) scenario, the AP with a Transmission Opportunity (TXOP) is called the sharing AP. This AP initiates an AP cooperative scheme by sending frames (such as beacon frames or probe response frames) containing information about the AP cooperative scheme's capabilities to determine the AP candidate set. After receiving a frame from the sharing AP, the AP participating in the AP cooperative scheme is called the shared AP. The sharing AP is also called the master AP or cooperative AP, and the shared AP is called the slave AP or cooperative AP.

[0110] Various multi-M-AP technologies are currently being discussed and are being explored. These technologies include cooperative beamforming (CBF), cooperative spatial multiplexing (CSR), joint transmission (JTX), and OFDMA / TDMA. Cooperative beamforming / nulling involves multiple APs coordinating and forming transmissions on the same frequency resources based on spatial nulls, allowing simultaneous transmission from multiple APs. Interference between M-APs is reduced by sharing channel state information (CSI). Using cooperative spatial multiplexing (CSR), multiple APs and / or STAs adjust their transmission power to reduce interference between sites (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 cooperative OFDMA / TDMA scheme, M-APs use time and frequency cooperatively to improve system throughput. They transmit on orthogonal frequency resources by coordinating and partitioning the spectrum to utilize it more efficiently.

[0111] refer to Figure 8 Modern WiFi implementations (such as UHR) allow a new TXOP sharing method that allows a sharing AP to share its acquired transmission opportunities (TXOPs) with other APs (called "shared" APs). Figure 8This diagram illustrates three BSSs with overlapping coverage areas. These BSSs include BSS1, BSS2, and BSS3, each with associated APs, namely AP1, AP2, and AP3. As shown, AP1 has two associated non-AP sites (STA1-1, STA1-2); AP2 has two associated non-AP sites (STA2-1, STA2-2); and AP3 has one associated non-AP site (STA3-1). Using this example, AP1 is a shared AP, sharing its TXOP with AP2, which is referred to as the shared AP. AP3 is not directly involved in TXOP sharing, but it can listen to transmissions from BSS1 or BSS2, or at least a portion of both. Under this function, it is referred to as an occasional listening AP. Therefore, BSS1 is a shared BSS; BSS2 is a shared BSS; and BSS3 is an occasional listening BSS (OBSS).

[0112] Unfortunately, as described below, some rules used in previous and existing WiFi implementations impose inconvenient restrictions on STAs that are aware they are at least partially within range of other transmission sites. They are forced to wait excessively long NAV (Network Access Volume) periods before attempting to access the channel. Therefore, in some embodiments, techniques are provided that enable STAs hidden from the shared AP and not associated with it to utilize the channel without excessive waiting, without adversely affecting transactions involving the shared AP. This improves overall media utilization without the risk of unreasonable interference.

[0113] Before discussing the technologies related to multi-AP sharing, some background information on existing AP-to-non-AP STA TXOP sharing is provided to better understand these technologies. Using 802.11be (EHT), an AP can allocate time for its associated non-AP STA within the acquired TXOP by transmitting a MU-RTS-TXS trigger frame. From there, after receiving the MU-RTS-TXS trigger frame (containing the user information field addressed to it) from its associated AP, the STA can transmit one or more non-TB PPDUs within the time allocated in the MU-RTS-TXS trigger frame. After sending the CTS requested by the MU-RTS-TXS trigger frame, the STA ignores the intra-BSS NAV until the time allocation signaled in the MU-RTS-TXS trigger frame ends, as it has the right to access the channel for data transmission. On the other hand, during the NAV timeout period, the STA will not receive a PHY-RXSTART indication from the PHY and is not allowed to reset its NAV. STAs that update their NAV using information from the received MU-RTS TXS trigger frame as the latest basis should not reset their NAV after the NAV timeout has expired unless the STA receives a satisfactory CF-End frame. This applies to STAs in the BSS that are not involved in TXOP switching. Even if a STA not involved in the TXS process does not accidentally hear a CTS frame during the NAV timeout, it may still not reset its NAV. However, this is reasonable to protect the receiving STA of MU-RTS-TXS from interference from other STAs in the same BSS when transmitting one or more PPDUs.

[0114] WiFi 8 (UHR) introduces extended TXOP sharing, allowing a shared AP's TXOP to be shared with one or more other APs. Utilizing TXOP sharing among multiple APs (M-APs) may require additional protection for STAs to ensure that the AP being shared can transmit or request PPDUs within its allocated timeframe within its BSS without undue interference from STAs in nearby BSSs or within the same BSS. However, in some cases, such as when a STA is associated with a TXOP-sharing AP but not with the BSS of the AP being shared, it may be beneficial to allow that STA to compete for channel access within its allocated TXOP timeframe.

[0115] Figure 9 It shows the involvement Figure 8The diagram illustrates a TXOP transmission between STAs and APs in three BSSs, using the traditional third-party contention rule for the channel. Using this example, AP1 is the sharing AP, AP2 is the shared AP, and AP3 is the occasional listening AP in the occasional listening BSS (OBSS3). The sharing AP (AP1) and the shared AP (AP2) exchange frames for a TXOP transaction. AP1 sends a MU-RTS-TXS frame, which is received by AP2 and responded with a CTS frame. AP2 uses the shared time to transmit data between itself and one or more stations (STA2-1 as shown in the diagram). Data transmission is completed when STA2-1 sends an acknowledgment (BA) frame back to AP2.

[0116] Using this example, two STAs (AP3, STA1-2) can occasionally intercept MU-RTS TXS TF transmissions from AP1, but cannot intercept transmissions from sites in BSS2. Nevertheless, under the existing rules, they cannot reset their NAV timers. This might be reasonable for STA1-2, as it shouldn't be allowed to interfere with AP1 transmitting its PPDU during its allocated time. However, while AP3 doesn't cause a conflict with sites in BSS2, as shown, it still doesn't reset its NAV before its allocated TXOP time expires, which is a waste of available resources.

[0117] Therefore, in some embodiments, a process is proposed to efficiently utilize channel resources while avoiding channel contention during TXOP sharing among multiple APs. If a station (e.g., a UHR station) will not adversely affect the BSS of the shared AP during the allocated TXOP duration, the station should be allowed to compete for channel access without waiting for the TXOP timer duration to expire. In some embodiments, techniques are provided to allow such STAs to use the channel without waiting for the entire TXOP duration. In some embodiments, when a station determines that it is not part of the same BSS as the sharing AP, its NAV can be reset and it can attempt to access the channel. In other embodiments, the AP generating the MU-RTS-TXS can set a shorter duration than the TXOP duration in the MAC header (e.g., in the duration / ID field). This smaller NAV timer duration can be long enough to cover shared switching control activities (e.g., SIFS + response frame duration or SIFS + response frame duration + a short duration sufficient to transmit several pending frames) but will not cover the entire TXOP sharing duration. In fact, in some embodiments, this duration can even be set to 0.

[0118] Figure 10A This illustrates the implications according to certain embodiments. Figure 8The diagram illustrates the TXOP transmission between STA and AP, where the OBSS site is allowed to reset its NAV timer before the TXOP duration expires. Using this example, a transmission occurs between AP1, AP2, and STA2-1... Figure 9 The same basic TXOP transaction occurs. That is, AP1 shares its TXOP with AP2, and AP2 uses the TXOP to transfer data between itself and its associated site (STA2-1 in this example). However, taking advantage of this scenario, AP3 can reset its NAV timer before the TXOP duration expires. It can do this because it has determined that the TXOP is used for sharing between APs and that it is not associated with the sharing AP (AP1). Therefore, it is allowed to reset its NAV timer before the entire TXOP duration expires. An incidentally listening site can make these determinations in any suitable manner, and some examples will be discussed below. In some embodiments, the relevant frame may include one or more fields with data to allow a site to determine whether multi-AP sharing is occurring and whether it is associated with the sharing AP.

[0119] Figure 10B This is a diagram illustrating a MU-RTS-TXS trigger frame with a multi-AP sharing indicator according to certain embodiments. Using this implementation, the EHT or later MU-RTS TXS trigger frame includes an indicator in the user portion to indicate TXOP sharing between APs. For example, this indicator may be set within a subfield or one of the reserved subfields in the user information field, such as... Figure 10B As shown in Figure 1005. This includes bit indications to indicate TXOP sharing between APs (BSS).

[0120] Upon receiving a MU-RTS TXS PPDU with such indication, STAs should interpret the remaining fields of the user information, even if the user information is not specifically addressed to STAs such as UHR STAs. For OBSS STAs hidden from the shared AP, the basic NAV (e.g., as defined in the duration / ID field of the MAC header) is observed during the transmission of MU-RTS TXS and CTS frames, but after this time, they are allowed to attempt radio channel occupancy. Since the channel TXOP privilege is granted to the shared AP hidden from the OBSS STA, the OBSS STA does not need to unnecessarily extend the NAV configuration during the transmitted and shared TXOP period. The advantage of this approach is that the OBSS STA can attempt channel access without unnecessary delay.

[0121] On the other hand, if the received frame is an intra-BSS frame (associated with the STA and the shared AP), and the user information field indicates that the frame is not destined for the STA, the STA should still set its intra-BSS NAV for the duration specified in the allocation duration subfield of the user portion. Furthermore, when a STA receives a MU-RTS TXS frame transmitted from a BSS belonging to the same group, the STA should not perform an NAV reset even if no CTS frame is received during the NAV timeout period. Note that in some embodiments, BSSs classified as belonging to the same group include MYBSS (STAs belonging to the same AP), BSSs belonging to the same ESS, and a group of BSSs grouped together for multiple operational purposes.

[0122] Figure 10C This is a diagram illustrating a conventional MU-RTS-TXS frame with a multi-AP shared indicator according to certain embodiments. Using this example, the MU-RTS TXS frame specifies partial BSS information (e.g., BSSID information) in the AID 12 field of the User Information field, instead of the conventional AID information. This is indicated at 1010 in the diagram. In this case, the included BSS information can represent color information or a partial BSS ID, for example, using a reduced bit width instead of the 48-bit BSS ID field. For example, partial BSS ID, AP ID, or BSS color information can be represented with a 12-bit width as a subfield within the User Information field.

[0123] Figure 10D and 10E The diagram illustrates MU and TB PPDU frame structures according to certain embodiments, which may include multi-AP shared indicators. For example, BSS information identifying the participating TXOP BSS may be included in either signal field. In the depicted example, the BSS information is included in the common signal (U-SIG) fields (1015, 1020) of the MU and TB PPDU, respectively.

[0124] Figure 11A This illustrates the implications according to certain embodiments. Figure 8 The diagram illustrates the TXOP transfers of STAs and APs, but the shared AP has a reduced NAV duration set. Using this example, the same basic TXOP transaction occurs between AP1, AP2, and STA2-1. That is, AP1 shares its TXOP with AP2, and AP2 uses this TXOP to transfer data between itself and one or more of its associated stations (STA2-1 in this example). However, in this scenario, AP3 does not need to reset the specified NAV duration in advance, because the shared AP has defined it as a duration less than the duration available for the entire TXOP sharing opportunity.

[0125] Figure 11B This diagram illustrates a MU-RTS-TXS frame with a Duration / ID field (1105) for setting a small NAV timer used by the OBSS site, and an Allocation Duration field (1110) in the user section for the TXOP duration. For example, a shared AP could set the duration in the Duration / ID field 1105 to account for the time of response frames and pending frames, rather than the entire TXOP duration. The problem can be effectively mitigated by configuring the Duration field to the minimum time required for a single protection, or even setting it to zero duration. In other words, consider a scenario where the Duration field value in a MU-RTS TXS frame transmitted by a shared AP is defined as SIFS+CTS-Airtime, and the OBSS STA only listens to this MU-RTS TXS frame without receiving any corresponding response; in this case, the set duration value is shorter than the NAV timer allocated for the entire TXOP. Therefore, establishing a NAV for this specific duration for the OBSS site aligns with existing WiFi standards that prohibit NAV resets. Thus, the basic NAV is maintained for the specified duration, and once the OBSS NAV counter reaches zero, the OBSS site is eligible to attempt channel occupancy. In this way, since the channel's TXOP privileges are granted to the shared AP hidden from the OBSS site, the OBSS site does not need to unnecessarily extend the NAV configuration during the transmitted and shared TXOP period.

[0126] In some embodiments, a more proactive approach involves setting the duration field of the MU-RTS TXS frames transmitted by the shared AP to 0. This approach can be considered in scenarios where a STA associated with the shared AP and hidden from the shared AP can receive MU-RTS TXS frames but cannot receive response frames. For the STAs associated with the shared AP, they can use information from the user information field of the MU-RTS TXS PPDU to set their intra-BSS NAV to avoid affecting the shared AP during the shared TXOP period.

[0127] For OBSS STAs hidden from the shared AP, they can begin the backoff process immediately because the duration in the MU-RTS TXS frame is set to 0. However, it is important to consider potential collisions, especially when the OBSS STA is within range of a CTS frame from the shared AP.

[0128] In scenarios where the shared AP determines that TXOP sharing is unnecessary, it can effectively reject the TXOP sharing request by not responding. When the shared AP encounters a CTS timeout, it can naturally infer that its TXOP sharing request has been rejected by the shared AP. In this case, the shared AP can perform PIFS recovery or immediately transmit a CF-end frame after the CTS timeout, allowing all surrounding STAs to acquire radio resources by backing up contention. The scenario where the shared AP rejects TXOP sharing is consistent with the perspective of the shared AP's OBSS STA or associated STA when it receives a MU-RTS TXS frame but subsequently does not receive a CTS response. The OBSS site can reset its NAV timeout after the NAV timeout period, allowing it to regain access to the channel, while the shared AP's associated STA continues to maintain its intra-BSS NAV timeout.

[0129] Figure 12A This is a flowchart illustrating routine 1200 for an AP to generate a TXOP trigger frame according to certain embodiments. At 1202, a first access point (AP) device generates a trigger frame with a shared opportunity (TXOP) and an associated TXOP duration. For example, the trigger frame could be a MU-RTS-TXS trigger frame. In some embodiments, this TXOP duration corresponds to the amount of time allocated to the shared AP for receiving transmission opportunities.

[0130] At position 1204, the AP includes a timer duration in the frame that is less than the TXOP duration. For example, this timer duration may correspond to the time of a response (such as CTS), SIFS, and any pending frames. In some embodiments, the timer duration may even be as short as 0. In some embodiments, the timer duration is located in the duration / ID field of the MAC header. In some embodiments, the timer duration is a second duration, which the AP uses to set a first duration corresponding to the TXOP duration in the user portion of the trigger frame, wherein the second timer duration is less than the first timer duration. In some embodiments, the user portion may also, or alternatively, include a BSS identifier field.

[0131] At 1206, the AP wirelessly transmits a sharing opportunity trigger frame to one or more other access points (APs). In some embodiments, the trigger frame may also include a user portion, which includes fields indicating that opportunity sharing is occurring between multiple access points.

[0132] In some embodiments, the AP can generate a Physical Layer Protocol Data Unit (PPDU) having a Universal Signal (U-SIG) or version-specific (e.g., EHT-SIG, UHR-SIG, or later versions) field containing participating BSS information, and the AP wirelessly transmits the PPDU to another AP. For example, the participating BSS information may include at least one of coordinated multi-AP operation or multi-AP sharing activity.

[0133] Figure 12B This is a flowchart illustrating routine 1210 for an AP to generate a shared trigger frame for multiple APs, according to an additional embodiment. At 1212, the AP generates a trigger frame with a TXOP, which has an associated TXOP duration.

[0134] At 1214, the AP includes multi-BSS sharing information in the frame to allow sites not associated with the shared AP to reset their NAV timers before the end of the TXOP duration. At 1216, it wirelessly transmits the sharing opportunity trigger frame to one or more other access points.

[0135] Figure 12C This is a flowchart illustrating routine 1220, according to certain embodiments, for a site to process TXOP trigger frames in a multi-AP sharing scenario. At 1222, the site wirelessly receives a trigger frame with a sharing opportunity.

[0136] Next, at 1224, the station determines that the frame request is from the first AP to one or more other APs. At 1226, it determines whether it (the station) is in the associated BSS of the first AP. At 1228, based on whether it is associated with the first AP and / or any shared AP that accepted the request, it uses the duration information in the frame to set the NAV timer.

[0137] In some embodiments, the duration information is located in the MAC header portion of the frame. In some embodiments, it determines whether the STA is in an associated BSS by processing BSS color information from the PPDU or BSS identification information from the associated identifier (AID) portion of the frame. In some embodiments, the duration is less than the sharing opportunity duration associated with the sharing opportunity that triggered the frame.

[0138] While many of the solutions and techniques provided herein are described with reference 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 in or embodied in an article of manufacture in which instructions are stored on a non-transient machine-readable medium (such as microelectronic memory) that 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 (such as dedicated digital filter blocks and state machines) containing hard-wired logic. These operations may also be performed by any combination of programmable data processing components and fixed hard-wired circuit components.

[0139] In some cases, an embodiment may be an apparatus (e.g., an AP STA, non-AP STA, or other network or computing device) that includes one or more hardware and software logic structures for performing one or more operations described herein. For example, as described herein, the apparatus may include a storage unit that stores 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.

[0140] The symbolic representation of operations on data bits already in algorithms and computer memory presents some of the previously described details. These algorithmic descriptions and representations are the most effective way for those skilled in the art of data processing to communicate the essence of their work to others skilled in the art. Here, an algorithm is generally considered as a series of self-consistent operations that lead to a desired result. These operations require physical quantities. Typically, these physical quantities (though not necessarily) take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. For the sake of generality, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0141] 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 converts data represented as physical (electronic) quantities in the registers and memories of the computer system into other data similarly represented as physical quantities in the computer system's memory or registers or other such information storage systems.

[0142] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically constructed for the intended purpose, or 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 (such as a sequence of instructions) contained in memory or other non-transient 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 memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards, or optical cards, or any type of medium suitable for storing electronic instructions, each medium being connected to a computer system bus.

[0143] 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 program based on the teachings herein, or more specialized devices can be conveniently constructed to execute the methods. The structures of various such systems will be described in detail below. Furthermore, this disclosure does not refer to any particular programming language. It should be understood that the teachings disclosed herein can be implemented using various programming languages.

[0144] This disclosure can be provided as a computer program product or software that may include a machine-readable medium having instructions stored thereon that can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. A machine-readable medium includes any mechanism for storing information in a machine-readable (e.g., computer-readable) form. In some embodiments, a machine-readable (e.g., computer-readable) medium includes 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.

[0145] In the foregoing description, specific exemplary embodiments of the present disclosure have been referred to. It will be apparent that various modifications can be made without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the claims. Therefore, the description and drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: In the first access point (AP) device, a trigger frame with a transmission sharing opportunity (TXOP) is generated, the TXOP having an associated TXOP duration, and the frame including a MAC header timer duration that is less than the TXOP duration; and Shared opportunity trigger frames are wirelessly transmitted to one or more other access points (APs).

2. The method according to claim 1, wherein, The duration of the MAC header timer corresponds to the time it takes for the first AP to receive a response frame from the one or more other APs, but is less than the time available for the one or more other APs to use the TXOP.

3. The method according to claim 2, wherein, The duration of the MAC header timer corresponds to the SIFS plus the response frame time, or the SIFS plus the response frame plus a duration sufficient to transmit one or more frames to be processed.

4. The method according to claim 2, wherein, The response frame is located in a Triggered Physical Protocol Data Unit (TBPPDU) frame.

5. The method according to claim 2, wherein, The response frame is a CTS frame.

6. The method according to claim 1, wherein, The duration of the MAC header timer corresponds to the network allocation vector (NAV) timer.

7. The method according to claim 1, wherein, The trigger frame includes a user portion, which includes a field indicating that opportunity sharing is being conducted among multiple access points.

8. The method according to claim 1, wherein, The TXOP duration is located in the user portion of the trigger frame.

9. The method of claim 1, wherein the trigger frame includes a user portion, the user portion including an AP identifier field.

10. The method according to claim 9, wherein, The TXOP duration is located in the user portion of the trigger frame.

11. The method according to claim 1, wherein, The TXOP duration is a first timer duration, and the AP is used to set a second timer duration in the Media Access Control (MAC) portion of the trigger frame, the second timer duration being less than the first timer duration.

12. The method according to claim 11, wherein, The duration of the first timer is located in the user portion of the trigger frame.

13. The method according to claim 12, wherein, Set the duration of the second timer in the MAC section to zero.

14. The method of claim 1, comprising: Generate a Physical Layer Protocol Data Unit (PPDU) with a Universal Signal U-SIG field, wherein the U-SIG field contains Basic Service Set (BSS) information for participation; And wireless transmission of the PPDU.

15. The method according to claim 14, wherein, The BSS information involved includes at least one of the following: coordinated multi-AP operation or multi-AP sharing activity.

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

17. A method comprising: In the first access point (AP) device, a physical layer protocol data unit (PPDU) is generated, the PPDU including a signal field with participating BSS information; and The PPDU is wirelessly transmitted to the station STA.

18. The method according to claim 17, wherein, The STA is a non-AP STA.

19. The method of claim 17, wherein, The BSS information involved includes at least one of the following: coordinated multi-AP operation or multi-AP sharing activity.

20. The method of claim 17, wherein, The PPDU is a multi-user MU PPDU.

21. The method according to claim 17, wherein, The signal field is the general signal U-SIG field.

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

23. A method comprising: In a site STA, wireless reception includes a trigger frame for a sharing opportunity, the sharing opportunity including a first duration associated with the sharing opportunity; Determine that the frame is from a first AP to one or more other APs; Determine whether the STA is in the BSS associated with the first AP; and If the STA is not in the BSS associated with the first AP, set the NAV timer with a second duration of a frame shorter than the first duration, or reset the NAV timer.

24. The method according to claim 23, wherein, The first duration information is located in the user portion of the trigger frame.

25. The method according to claim 23, wherein, Determining whether the STA is in the associated BSS includes processing BSS color information from the PPDU.

26. The method according to claim 23, wherein, Determining whether the STA is in an associated BSS includes processing the BSS identification information from the associated identifier AID portion of the trigger frame.

27. The method of claim 23, comprising: Even if the trigger frame is not addressed to the STA, all fields of the user section are interpreted.

28. The method of claim 23, comprising: If the STA determines that it is in the BSS associated with the first AP, the NAV timer is set to the first duration.

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

30. A method comprising: In the AP, a trigger frame with a TXOP is generated, the TXOP having an associated first duration; The frame includes multi-BSS sharing information to allow a site not associated with the shared AP to reset its NAV timer before the end of the first duration. and Shared opportunity trigger frames are wirelessly transmitted to one or more other access points.

31. The method according to claim 30, wherein, The frame includes a second duration that is shorter than the first duration.

32. The method according to claim 31, wherein, The second duration is located in the MAC header portion of the trigger frame, and the first duration is located in the user portion of the trigger frame.

33. A method comprising: In the first access point (AP) device, a physical layer protocol data unit (PPDU) is wirelessly received from the site (STA), the PPDU including a signal field with participating BSS information; and Process the PPDU.

34. The method according to claim 33, wherein, The STA is the second AP device.

35. The method according to claim 33, wherein, The BSS information involved includes at least one of the following: coordinated multi-AP operation or multi-AP sharing activity.

36. The method according to claim 33, wherein, The PPDU is a multi-user MU PPDU.

37. The method according to claim 33, wherein, The signal field is the general signal U-SIG field.

38. A non-transitory machine-readable medium having instructions that, when executed, perform the method of any one of claims 33 to 37.

Images