Coordinated time division multiple access (CTDMA) procedure

Abstract

There is a method and a device arranged to perform the method. The method comprises transmitting, by a first access point (AP), to a second AP and during a transmit opportunity (TXOP) obtained by the first AP, a first frame indicating a first duration within the TXOP allocated to the second AP; receiving, by the first AP from the second AP and during the first duration, a trigger frame addressed to a first station (STA); receiving, by the first AP from the second AP and during the first duration, a second frame indicating a return of the first duration by the second AP to the first AP; and after receiving the trigger frame and the second frame, transmitting, by the first AP to the second STA, a third frame for resetting a basic network allocation vector (NAV) of the second STA.

Description

Technical Field

[0001] This invention relates to wireless networks, particularly local networks such as those using the IEEE 802.11 standard. Background Technology

[0002] Wireless networks are often extremely busy with numerous devices "wanting" to transmit. This heavy occupancy of wireless media can lead to unacceptable delays or latency in some critical transmissions. In some networks, such as IEEE 802.11 (also known as 'Wi-Fi'), devices like access points (APs) can coordinate among themselves to improve media usage. Furthermore, many wireless networks overlap with and are subject to interference from other similar and different wireless networks.

[0003] This application claims priority to U.S. Provisional Applications US 63 / 548408, 63 / 557641 and 63 / 626551, the entire disclosure of which is incorporated herein by reference. Summary of the Invention

[0004] To reduce latency in wireless networks, methods, apparatus, and computer program products as defined in the appended claims are provided.

[0005] In one aspect, a method is provided, comprising: transmitting from a first access point (AP) to a second AP during a transmission opportunity (TXOP) obtained by the first AP a first frame indicating a first duration allocated to the second AP within the TXOP; receiving from the second AP a trigger frame addressed to a first station (STA) during the first duration; receiving from the second AP a second frame indicating that the second AP will return the first duration to the first AP during the first duration; and after receiving the trigger frame and the second frame, transmitting from the first AP to the second STA a third frame for resetting the basic network allocation vector (NAV) of the second STA.

[0006] In one aspect, a method is provided, comprising: receiving a trigger frame by a first access point (AP) from a second AP and during a first duration allocated to the second AP by the first AP; receiving a first frame by the first AP from the second AP and during the first duration, the first frame indicating that the second AP returns the first duration to the first AP; and after receiving the first frame, transmitting a second frame by the first AP to a first station (STA) for resetting the basic network allocation vector (NAV) of the first STA.

[0007] In one aspect, a device is provided that is arranged to communicate in a wireless network as an access point (AP), the device being arranged to: transmit a first frame to a second AP during a transmission opportunity (TXOP) obtained by the device, the first frame indicating a first duration allocated to the second AP within the TXOP; receive a trigger frame addressed to a first station (STA) from the second AP during the first duration; receive a second frame from the second AP during the first duration, the second frame indicating that the first duration is returned to the first AP by the second AP; and after receiving the trigger frame and the second frame, transmit a third frame to the second STA for resetting the basic network allocation vector (NAV) of the second STA.

[0008] In one aspect, a device is provided that communicates as an access point (AP) in a wireless network, the device being arranged to: receive a trigger frame from a second AP and during a first duration allocated to the second AP by the device; receive a first frame from the second AP and during the first duration, the first frame indicating that the second AP returns the first duration to the device; and after receiving the first frame, transmit a second frame to a first station (STA) for resetting the basic network allocation vector (NAV) of the first STA.

[0009] In one aspect, a method is provided, comprising: receiving, by a first station (STA), a first frame from a second STA indicating a first duration, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic network allocation vector (NAV) of the first STA, wherein the first duration is within a transmission opportunity (TXOP) and is allocated to a first access point (AP), the first AP being an OBSS AP; setting the basic NAV of the first STA based on the first frame; receiving, by the first STA, a second frame from the second AP and during the first duration for resetting the basic NAV of the first STA; and resetting the basic NAV of the first STA after receiving the second frame.

[0010] In one aspect, a method is provided, comprising: receiving by a first station (STA) from a second STA an indication of a first duration, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic network allocation vector (NAV) of the first STA; setting the basic NAV of the first STA based on the first frame; and receiving by the first STA from a first access point (AP) during the first duration a second frame for resetting the basic NAV of the first STA.

[0011] In one aspect, a device is provided that is arranged to communicate in a wireless network, the device having a basic NAV and being arranged to: receive from a second STA an indication of a first duration, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic network allocation vector (NAV) of a first STA, wherein the first duration is within a transmission opportunity (TXOP) and is allocated to a first access point (AP), the first AP being an OBSS AP; set the basic NAV based on the first frame; receive from the second AP during the first duration a second frame for resetting the basic NAV; and reset the basic NAV after receiving the second frame.

[0012] In one aspect, a device is provided that is arranged to communicate in a wireless network, the device having a basic NAV and being arranged to: receive a first frame indicating a first duration from a second STA, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic network allocation vector (NAV) of the first STA; set the basic NAV based on the first frame; and receive a second frame from a first access point (AP) during the first duration for resetting the basic NAV.

[0013] It is worth noting that, in the case of C-TDMA, an AP (sharing AP) can allocate a portion of the TXOP to another AP (the shared AP). Upon hearing communication from the shared AP, the sharing AP and its associated STAs set their basic NAV to protect the shared AP's communication. If the shared AP and its associated STAs complete their communication before the TXOP allocation sharing ends, the shared AP can return (i.e., release) the remaining portion of the TXOP to the sharing AP. The inventors have recognized that a STA associated with the sharing AP may not be able to hear the shared AP, but may be able to hear its associated STA—which could be an OBSS STA targeting the sharing AP's BSS. Hearing a frame from that STA will cause the unassociated STA to set its NAV. Unfortunately, the NAV will remain set, even though the shared AP sends a frame to release the NAV because that frame has not yet been heard. It may then be unable to respond to frames from its associated AP.

[0014] In one aspect, a method is provided, comprising: transmitting a first frame by a first access point (AP), the first frame including an indication of whether a station (STA) is permitted to ignore its basic network allocation vector (NAV) during a first duration allocated by the first AP to a second AP; receiving a second frame by the first AP from the second AP during the first duration, the second frame indicating that the second AP returns the first duration to the first AP; and transmitting a third frame by the first AP to the STA based on the indication that the STA is permitted to ignore its basic NAV during the first duration, which triggers an uplink transmission from the STA to the first AP.

[0015] In one aspect, a method is provided, comprising: receiving a first frame from a first access point (AP) by a first station (STA), the first frame including an indication of whether the first STA is permitted to ignore its basic network allocation vector (NAV) during a first duration allocated by the first AP to a second AP; and transmitting a second frame from the first STA to the first AP and during the first duration based on the indication that the STA is permitted to ignore its basic NAV during the first duration, without taking the basic NAV into account when transmitting the second frame.

[0016] In one aspect, there is provided a device arranged to communicate in a wireless network, the device having a basic network allocation vector (NAV) and arranged to: receive a first frame from a first access point (AP), the first frame including an indication of whether a first STA is permitted to ignore the NAV during a first duration allocated by the first AP to a second AP; and based on the indication of permitting the device to perform NAV during the first duration, transmit a second frame to the first AP and during the first duration without considering the NAV when transmitting the second frame.

[0017] Allowing a STA associated with a shared AP to ignore or not update its NAV (after hearing a transmission from a STA associated with another (i.e., the shared) AP) permits it to respond to frames from its own AP (i.e., the sharing AP). This avoids the undesirable result of the STA being unnecessarily blocked from transmitting. Attached Figure Description

[0018] This document describes examples of several embodiments of various embodiments of the present disclosure with reference to the accompanying drawings.

[0019] Figure 1 An example wireless communication network in which embodiments of the present disclosure may be implemented is illustrated.

[0020] Figure 2 This is a block diagram illustrating an example implementation of a station (STA) and an access point (AP).

[0021] Figure 3 The illustration shows an example Media Access Control (MAC) frame format.

[0022] Figure 4 The illustration shows an example management frame that can be used as an action frame.

[0023] Figure 5 The illustration shows an example control frame that can be used as a trigger frame.

[0024] Figure 6 The illustration shows an example data frame that can be used as a Quality of Service (QoS) empty frame.

[0025] Figure 7 The illustration shows an example format of a Physical Layer (PHY) Protocol Data Unit (PPDU).

[0026] Figure 8 The illustration shows an example of a multi-AP network.

[0027] Figure 9 The illustration shows an example network that includes a set of coordinated APs.

[0028] Figure 10 The diagram illustrates a sample multi-AP operation process.

[0029] Figure 11 The illustration shows an example of a multi-AP probe phase.

[0030] Figure 12 The illustration shows an example of the downlink data transmission phase in a multi-AP setup.

[0031] Figure 13 The illustration shows an example of the uplink data transmission phase in a multi-AP setup.

[0032] Figure 14 The illustration shows Enhanced Distributed Channel Access (EDCA) and Coordinated Time Division Multiple Access (CTDMA).

[0033] Figure 15 The illustration shows an example of a Multi-User Request Transmission (MU-RTS) trigger frame that can be used in a triggered Transmission Opportunity (TXOP) Share (TXS) process.

[0034] Figure 16 The illustration shows an example of a triggered TXS process (mode=1).

[0035] Figure 17 The illustration shows an example of a triggered TXS process (mode=2).

[0036] Figure 18 An example of an existing CTDMA procedure is illustrated.

[0037] Figure 19Another example of an existing CTDMA procedure is illustrated.

[0038] Figure 20 An example of a CTDMA process according to an embodiment is illustrated.

[0039] Figure 21 Another example of the CTDMA process according to an embodiment is illustrated.

[0040] Figure 22 Another example of the CTDMA process according to an embodiment is illustrated.

[0041] Figure 23 Another example of the CTDMA process according to an embodiment is illustrated.

[0042] Figure 24 The illustration shows example operational elements that can be used in the embodiments.

[0043] Figure 25 An example process according to an embodiment is illustrated.

[0044] Figure 26 Another example process according to an embodiment is illustrated.

[0045] Figure 27 Another example process according to an embodiment is illustrated.

[0046] Figure 28 Another example process according to an embodiment is illustrated. Detailed Implementation

[0047] In this disclosure, various embodiments are presented as examples of how the disclosed techniques and / or how the disclosed techniques can be practiced in environments and scenarios. It will be apparent to those skilled in the art that various changes in form and detail can be made without departing from the scope. After reading the specification, those skilled in the art will understand how to implement alternative embodiments. This embodiment is not limited to any of the described exemplary embodiments. Embodiments of this disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments can be combined to create further embodiments within the scope of this disclosure. Any drawings highlighting features and advantages are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be used in ways other than those shown. For example, any actions listed in the flowcharts can be reordered or used only optionally in some embodiments.

[0048] The embodiments can be configured to operate as needed. The disclosed mechanisms can be executed when certain criteria are met, for example, in a station, access point, radio environment, network, or a combination thereof. Example criteria may be based at least in part on, for example, wireless device or network node configuration, traffic load, initial system settings, packet size, service characteristics, or a combination thereof. Various example embodiments can be applied when one or more criteria are met. Therefore, example embodiments that selectively implement the disclosed protocols can be implemented.

[0049] In this disclosure, “a” and “an” and similar phrases should be interpreted as “at least one” and “one or more”. Similarly, any term ending with the suffix “(s)” will be interpreted as “at least one” and “one or more”. In this disclosure, the term “may” should be interpreted as “may, for example,.” In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a variety of suitable possibilities that may or may not be employed by one or more embodiments in various embodiments. As used herein, the terms “comprising” and “consisting of” enumerate one or more components of the described element. The term “comprising” is interchangeable with “including” and does not exclude the inclusion of unlisted components in the described element. In contrast, “consisting of” provides a complete enumeration of one or more components of the described element. As used herein, the term “based on” can be interpreted as “at least partially based on” rather than, for example, “based on only.” The term “and / or” as used herein refers to any possible combination of the enumerated elements. For example, “A, B and / or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0050] If A and B are sets and every element of A is an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1, STA2} are: {STA1}, {STA2}, and {STA1, STA2}. The phrase “based on” (or likewise “at least based on”) indicates that the phrase following the term “based on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “in response to” (or likewise “at least in response to”) indicates that the phrase following the phrase “in response to” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “depends on” (or likewise “at least depends on”) indicates that the phrase following the phrase “depends on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “adopts / uses” (or likewise “adopts / uses at least”) indicates that the phrase following the phrase “adopts / uses” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments.

[0051] The term "configured" can refer to the capacity of a device, regardless of whether the device is in an operational or non-operational state. "Configured" can also refer to specific settings within a device that affect its operational characteristics, regardless of whether the device is in an operational or non-operational state. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within a device, regardless of whether the device is in an operational or non-operational state, to provide specific characteristics to the device. Terms such as "control messages generated in the device" can mean that control messages have parameters that can be used to configure specific characteristics or to perform certain actions within the device, regardless of whether the device is in an operational or non-operational state.

[0052] In this disclosure, a parameter (or equivalently referred to as a field or information element: IE) may include one or more information objects, and an information object may include one or more other objects. For example, if parameter (IE)N includes parameter (IE)M, and parameter (IE)M includes parameter (IE)K, and parameter (IE)K includes parameter (information element)J, then, for example, N includes K, and N includes J. In the example embodiments, when one or more messages / frames include multiple parameters, this means that a parameter among the multiple parameters is present in at least one of the one or more messages / frames, but not necessarily in every one of the one or more messages / frames.

[0053] Many of the features presented are described as optional using the word "may" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly describe every permutation that can be obtained by selecting from the set of optional features. This disclosure will be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features can be embodied in seven ways: having only one of the three possible features, having any two of the three possible features, or having three of the three possible features.

[0054] Many of the elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as an element that performs a defined function and has a defined interface to other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (e.g., hardware with biological elements), or combinations thereof, and may be behaviorally equivalent. For example, a module can be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). Modules can be implemented using physical hardware that combines discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, and C++. FPGAs, ASICs, and CPLDs are typically programmed using a hardware description language (HDL) (e.g., VHSIC Hardware Description Language (VHDL) or Verilog), which configures the connections between internal hardware modules with a limited set of functions on the programmable device. The techniques mentioned are often used in combination to implement the result of functional modules.

[0055] Figure 1 An example wireless communication network in which embodiments of the present disclosure may be implemented is illustrated.

[0056] like Figure 1 As shown, an example wireless communication network may include an IEEE 802.11 (WLAN) infrastructure network 102. The WLAN infrastructure network 102 may include one or more Basic Service Sets (BSS) 110 and 120 and a Distribution System (DS) 130.

[0057] BSS 110-1 and 110-2 each comprise a set of access points (APs or AP STAs) and at least one station (STAs or non-AP STAs). For example, BSS 110-1 includes AP 104-1 and STA 106-1, and BSS 110-2 includes AP 104-2 and STAs 106-2 and 106-3. The APs and at least one STA in the BSS perform an association procedure to communicate with each other.

[0058] The DS 130 can be configured to connect BSS 110-1 and BSS 110-2. In this way, the DS 130 can enable Extended Service Set (ESS) 150. Within the ESS 150, APs 104-1 and 104-2 are connected via the DS 130 and can have the same Service Set Identifier (SSID).

[0059] The WLAN infrastructure network 102 can be coupled to one or more external networks. For example, such as Figure 1 As shown, WLAN infrastructure network 102 can be connected to another network 108 (e.g., 802.X) via portal 140. Portal 140 can be used as a bridge to connect DS 130 of WLAN infrastructure network 102 to other networks 108.

[0060] Figure 1 The example wireless communication network shown may also include one or more ad-hoc networks or standalone BSSs (IBSSs). An ad-hoc network or IBSS is a network of multiple STAs that are within each other's communication range. The multiple STAs are configured such that they can communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

[0061] For example, in Figure 1 In this configuration, STAs 106-4, 106-5, and 106-6 can be configured to form a first IBSS 112-1. Similarly, STAs 106-7 and 106-8 can be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Instead, STAs within the IBSS are managed in a distributed manner. STAs forming an IBSS can be fixed or mobile.

[0062] A STA, serving as a predefined functional medium, may include a Media Access Control (MAC) layer conforming to the IEEE 802.11 standard. A physical layer interface for the radio medium can be used between APs and non-AP stations (STAs). STA may also be referred to using various other terms, including mobile terminal, radio device, radio transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" may be used to refer to a STA participating in uplink multi-user multiple-input multiple-output (MU MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmission.

[0063] A Physical Layer (PHY) Protocol Data Unit (PPDU) can be a composite structure including a PHY preamble and a PLCP Service Data Unit (PSDU) payload. For example, a PSDU may include a PHY Convergence Protocol (PLCP) preamble and header and / or one or more MAC Protocol Data Units (MPDUs). The receiving device can use the information provided in the PHY preamble to decode subsequent data in the PSDU. When transmitting a PPDU over a bonded channel (a channel formed by channel bonding), the preamble field can be copied and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble can be used for packet detection, automatic gain control, and channel estimation, among other things. It is also typically used to maintain compatibility with legacy equipment. The format, encoding, and information provided in the non-legacy portion of the preamble are based on the specific IEEE 802.11 protocol to be used to transmit the payload.

[0064] A frequency band can include one or more sub-bands or frequency channels. For example, PPDUs conforming to IEEE 802.11n, 802.11ac, 802.11ax, and / or 802.11be standard revisions can be transmitted in 2.4 GHz, 5 GHz, and / or 6 GHz frequency bands, each of which can be divided into multiple 20 MHz channels. PPDUs can be transmitted on physical channels with a minimum bandwidth of 20 MHz. Larger channels can be formed through channel bonding. For example, PPDUs can be transmitted on physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding multiple 20 MHz channels together.

[0065] Figure 2 This is a block diagram illustrating an example implementation of STA 210 and AP 260. (As shown...) Figure 2As shown, STA 210 may include at least one processor 220, memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, memory 280, and at least one transceiver 290. Processors 220 / 270 may be operatively connected to memory 230 / 280 and / or transceiver 240 / 290.

[0066] Processors 220 / 270 can implement the functions of the PHY layer, MAC layer, and / or logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processors 220 / 270 may include one or more processors and / or one or more controllers. One or more processors and / or one or more controllers may include, for example, general-purpose processors, digital signal processors (DSPs), microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), logic circuits, or chipsets.

[0067] Memory 230 / 280 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage units. Memory 230 / 280 may include one or more non-transitory computer-readable media. Memory 230 / 280 may store computer program instructions or code that can be executed by processor 220 / 270 to perform one or more operations / embodiments discussed in this application. Memory 230 / 280 may be implemented (or located) within or outside of processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.

[0068] Transceiver 240 / 290 can be configured to transmit / receive radio signals. In embodiments, transceiver 240 / 290 can implement the PHY layer of the corresponding device (STA 210 or AP 260). In embodiments, STA 210 and / or AP 260 can be multi-link devices (MLDs), which are devices capable of operating on multiple links defined by the IEEE 802.11 standard. Thus, STA 210 and / or AP 260 can each implement multiple PHY layers. Multiple PHY layers can be implemented using one or more of transceivers 240 / 290.

[0069] Figure 3The illustration shows an example format for MAC frame 300. In operation, the STA can construct a subset of MAC frames for transmission and can decode a subset of received MAC frames during verification. The specific subset of frames that the STA can construct and / or decode can be determined by the functions supported by the STA. The STA can use the Frame Check Sequence (FCS) contained in the frame to verify received MAC frames and can interpret certain fields from the MAC header of all frames.

[0070] like Figure 3 As shown, MAC frame 300 includes a MAC header, a variable-length frame body, and a frame check sequence (FCS).

[0071] The MAC header includes a frame control field, an optional duration / ID field (not in PS-Poll frames), an address field, an optional sequence control field, an optional QoS control field (only in QoS data frames), and an optional high throughput (HT) control field (only in +HTC frames).

[0072] The frame control field includes the following subfields: protocol version, type, subtype, to DS, from DS, more fragments, retry, power management, more data, protected frames, and high throughput control (+HTC).

[0073] The protocol version subfield remains unchanged in size and layout across all revisions of the IEEE 802.11 standard. For MAC frames, the value of the protocol version subfield is 0.

[0074] The type and subtype subfields together identify the function of a MAC frame. There are three frame types: control, data, and management. Each frame type has several defined subtypes. Bits within the subtype subfield are used to indicate specific modifications to the underlying data frame (subtype 0). For example, in a data frame, the most significant bit (MSB) of the subtype subfield (bit 7 (B7) of the frame control field) is defined as the QoS subfield. When the QoS subfield is set to 1, it indicates a QoS subtype data frame, which is a data frame that includes a QoS control field in its MAC header. When set to 1 in the data subtype, the second MSB of the subtype field (bit 6 (B6) of the frame control field) indicates a data frame that does not include a frame body field.

[0075] The "To DS" subfield indicates whether the data frame is destined for the Distribution System (DS). The "From DS" subfield indicates whether the data frame originated from the DS.

[0076] In all data or management frames where the MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) carried by the MAC frame has another fragment to follow, set the More Fragments subfield to 1. In all other frames where the More Fragments subfield exists, set it to 0.

[0077] The retry subfield is set to 1 in any data or management frame that is a retransmission of an earlier frame. It is set to 0 in all other frames in which the retry subfield exists. The receiving STA uses this indication to aid in its process of eliminating duplicate frames. These rules do not apply to frames transmitted by the STA under the block protocol.

[0078] The power management subfield is used to indicate the power management mode of the STA.

[0079] The More Data subfield indicates to the STA in Power Saving (PS) mode that a bufferable unit (BU) is buffered for that STA at the AP. The More Data subfield is valid in individually addressed data or management frames transmitted from the AP to the STA in PS mode. The More Data subfield is set to 1 to indicate the presence of at least one additional buffered BU for the STA.

[0080] If the frame body field contains information that has already been processed by the cryptographic encapsulation algorithm, then the protected frame subfield is set to 1.

[0081] The +HTC subfield indicates that MAC frame 300 contains the HT control field. Frames containing the HT control field are called +HTC frames. Control wrapper frames are +HTC frames.

[0082] The Duration / ID field in the MAC header indicates various aspects depending on the frame type and subtype, as well as the QoS capabilities of the sending STA. For example, in a control frame of the Power Saving Polling (PS-Poll) subtype, the Duration / ID field carries the Association Identifier (AID) of the STA transmitting the frame in 14 least significant bits (LSBs), and both most significant bits (MSBs) are set to 1. In other frames sent by the STA, the Duration / ID field contains a duration value (in microseconds) that is used by the receiver to update the Network Allocation Vector (NAV). The NAV is a counter that indicates to the STA the amount of time it must postpone access to the shared medium.

[0083] A MAC frame 300 format may contain up to four address fields. These fields are used to indicate the Basic Service Set Identifier (BSSID), source address (SA), destination address (DA), transmitter address (TA), and receiver address (RA). Some frames may not contain some of these address fields. Some address fields are specified using the relative positions of address fields (1-4) within the MAC header, regardless of the address type present in that field. Specifically, address 1 always identifies the intended receiver of the frame, and address 2 (if present) always identifies the transmitter of the frame.

[0084] The sequence control field consists of two subfields: the sequence number subfield and the fragment number subfield. In a data frame, the sequence number subfield indicates the sequence number of the MSDU (if not in an aggregated MSDU (A-MSDU)) or A-MSDU. In a management frame, the sequence number subfield indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of the MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of the MSDU or MMPDU and increments by 1 for each subsequent fragment of that MSDU or MMPDU. In a MAC Protocol Data Unit (MPDU) containing an A-MSDU, or in an MPDU containing an unsegmented MSDU or MMPDU, the fragment number is set to 0. The fragment number remains constant throughout all retransmissions of the fragment.

[0085] The QoS control field identifies the Service Category (TC) or Service Flow (TS) to which the MAC frame 300 belongs. The QoS control field can also indicate various other QoS-related, A-MSDU-related, and mesh-related information about the frame. This information can vary depending on the frame type, frame subtype, and the type of STA being transmitted. The QoS control field exists in all data frames where the QoS subfield of the subtype subfield is equal to 1.

[0086] The HT control field exists in QoS data, QoS empty, and management frames, as determined by the +HTC subfield of the frame control field. The control frame subtype containing the HT control field is the control wrapper frame. A control frame described as +HTC (e.g., Request to Send (RTS) +HTC, Clear to Send (CTS) +HTC, Block Ack +HTC, or Block Ack Req +HTC frame) means that a control wrapper frame is used to carry that control frame.

[0087] The frame body field is a variable-length field that contains information specific to the individual frame type and subtype. It can include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.

[0088] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated from all fields in the MAC header and frame body.

[0089] Figure 4 The illustration shows an example management frame 400 that can be used as an action frame. In the example, management frame 400 includes a MAC header, a variable-length frame body, and a Frame Check Sequence (FCS). The MAC header includes a frame control field, a duration field, an address 1 field, an address 2 field, an address 3 field, a sequence control field, and an optional HT control field. The presence of the HT control field is determined by the setting of the +HTC subfield of the frame control field.

[0090] like Figure 4 As shown, when used as an action frame, the frame body of a management frame includes an action field, a vendor-specific element, a Management Message Integrity Code (MME) element, a Message Integrity Code (MIC), and an Authenticated Mesh Peer Exchange element.

[0091] The action field includes a category field and an action details field. The action field provides a mechanism for specifying extended management actions. The category field indicates the category of the action frame. The action details field contains details of the action requested by the action frame. For example, the action frame could be a common action frame. Figure 4 As shown, in the common action frame format, the action details field is included in the common action field in eight bytes immediately following the category field, followed by the variable-length common action details field.

[0092] Optionally, one or more supplier-specific elements may exist. These elements are not present when the category subfield of the action field is supplier-specific.

[0093] When negotiating management frame protection, an MME exists, the frame is a group-addressed robust action frame, and (MBSS only) the action frame's class does not support group-addressed privacy as indicated by the class value; otherwise, it does not exist.

[0094] If a shared pairwise master key (PMK) exists between the sender and receiver of a self-protection action frame, the MIC element is present in the frame; otherwise, it is not.

[0095] If a shared PMK exists between the sender and receiver of a self-protection action frame, then the authenticated mesh peer-to-peer exchange element is present in the frame; otherwise, it is not.

[0096] Figure 5 The illustration shows an example format of trigger frame 500. Trigger frame 500 can be used by an AP to allocate resources for one or more STAs and to request one or more TBPPDU transmissions from them. Trigger frame 500 may also carry additional information required by a STA to transmit a TBPPDU to the AP.

[0097] like Figure 5 As shown, the trigger frame 500 includes a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a public information field, a user information list field, a padding field, and an FCS field.

[0098] The frame control field includes the following subfields: protocol version, type, subtype, to DS, from DS, more fragments, retry, power management, more data, protected frames, and +HTC.

[0099] The duration field indicates various aspects depending on the frame type and subtype, as well as the QoS capabilities of the sending STA. For example, in a control frame of the Power Saving Polling (PS-Poll) subtype, the duration field carries the association identifier (AID) of the STA transmitting the frame in 14 least significant bits (LSBs), and both most significant bits (MSBs) are set to 1. In other frames transmitted by the STA, the duration field contains a duration value (in microseconds) that the receiver uses to update the Network Allocation Vector (NAV).

[0100] The RA field is the address of the STA intended to receive the incoming transmission from the transmission station. If trigger frame 500 is addressed to an STA belonging to a single BSS, the TA field is the address of the STA that transmitted trigger frame 500. If trigger frame 500 is addressed to an STA from at least two different BSSs from a set of multiple BSSIDs, the TA field is the transmitted BSSID.

[0101] The common information field specifies the trigger frame type of trigger frame 500, the transmission power of trigger frame 500 in dBm, and several key parameters of the TB PPDU transmitted by the STA in response to trigger frame 500. The trigger frame type used by the AP to receive QoS data using the UL MU is called the basic trigger frame. Non-EHT, non-AP HE STAs interpret the common information field as an HE variant. If B54 and B55 in the common information field are equal to 1, non-AP EHT STAs interpret the common information field as an HE variant; otherwise, they interpret it as an EHT variant. The HE variant common information field and the EHT variant common information field use the same encoding method for trigger type, UL length, additional TF, CS requirement, LDPC extra symbol segment, AP TX power, FEC prepare factor, PE disambiguation, and trigger-related common information subfields.

[0102] The user information list field contains zero or more user information fields. There are three variations of the user information field: special user information field, EHT variant user information field, and HE variant user information field.

[0103] The Special User Information field is a user information field that carries extended public information not provided in the Public Information field but does not carry user-specific information. If the Special User Information field is included in the trigger frame, the Special User Information Field Flag subfield of the EHT Variant Public Information field is set to 0; otherwise, it is set to 1. The Special User Information field is identified by the AID12 value 2007 and optionally exists in the trigger frame generated by the EHT AP. The Special User Information field (if present) immediately follows the Public Information field in the trigger frame and carries information for the U-SIG field of the requested EHT TB PPDU. The PHY Version Identifier subfield indicates the PHY version of the requested TB PPDU, which is not an HE TB PPDU. For EHT, the PHY Version Identifier subfield is set to 0. Other values ​​from 1 to 7 are reserved. The UL Bandwidth (BW) Extended subfield and the UL BW subfield in the Public Information field indicate the bandwidth of the requested TB PPDU from the addressed EHT STA (i.e., the bandwidth in the U-SIG field of the EHT TB PPDU). The EHT Space Reuse n subfield carries the value from the corresponding Space Reuse n subfield to be included in the U-SIG field of the EHT TBPPDU. The U-SIG Ignore and Verify subfield carries the value from the Ignore and Verify subfield of the U-SIG field of the requested EHT TBPPDU. The presence and length of the Trigger-Related User Information subfield in the Special User Information field depend on the variant of the trigger frame.

[0104] The EHT variant user information field is included in the user information field for each STA addressed in trigger frame 500. Each STA user information field includes the AID12 subfield, RU allocation subfield, UL FEC coding type subfield, UL EHT-MCS subfield, reservation subfield, spatial stream (SS) allocation / RA-RU information subfield, UL target received power subfield, and power saving (PS) 160 subfield (for use by the STA in the TB PPDU transmitted in response to trigger frame 500), as well as trigger-related user information subfields, etc. The RU allocation subfield in the EHT variant user information field of trigger frames that are not MU-RTS trigger frames, as well as the UL BW subfield in the common information field, the UL BW extension subfield in the special user information field, and the PS160 subfield in the EHT variant user information field, identify the size and location of the RU or MRU. The values ​​of the PS160 subfield and B0 in the RU allocation subfield indicate an 80MHz frequency subblock, where the RU or MRU is located in the 26-tone RU, 52-tone RU, 106-tone RU, 242-tone RU, 484-tone RU, 996-tone RU, 52br 26-tone RU, and 106+26-tone RU. The value of the PS160 subfield indicates the 160 MHz segment in which the RU or MRU of the 2996-tone RU, 996+484-tone MRU, and 996+484+242-tone MRU resides. The UL FEC encoding type subfield in the User Information field indicates the code type of the requested EHT TB PPDU. The UL FEC encoding type subfield is set to 0 to indicate BCC and set to 1 to indicate LDPC. The UL EHT MCS subfield in the User Information field indicates the EHT MCS of the requested EHT TB PPDU. The SS allocation subfield of the EHT variant user information field indicates the spatial flow of the requested EHT TB PPDU. The UL target received power subfield indicates the expected received signal power of the EHT portion of the EHT TB PPDU, measured at the AP's antenna connector and averaged on the antenna, transmitted over the allocated RU. The AP can use the trigger-related user information subfield to specify the preferred access class (AC) for each STA. The preferred AC setting can be determined by the minimum priority AC traffic transmitted by the participating STAs. The AP determines the list of participating STAs, as well as BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and the maximum duration of the TB PPDU for each participating STA. The RA-RU information subfield is reserved in the EHT variant user information field.

[0105] The padding field is optionally present in the trigger frame 400 to extend the frame length, giving the receiver STA sufficient time to prepare a response for transmitting an SIFS after receiving the frame. The padding field (if present) is at least two octets long and is set to all 1s.

[0106] The FCS field is used by the STA to verify received frames and interpret certain fields from the MAC header of the frame.

[0107] Figure 6 The illustration shows an example data frame 600 that can be used as a QoS empty frame. A QoS empty frame is a QoS data frame with an empty frame body. A QoS empty frame includes a QoS control field and an optional HT control field, which may contain a Buffer Status Report (BSR) control subfield. QoS empty frames indicating buffer status information can be transmitted from the STA to the AP.

[0108] QoS control fields may include a Service Identifier (TID) subfield, an Acknowledgment (Ack) policy indicator subfield, and a queue size subfield (or a Transmission Opportunity (TXOP) duration request subfield).

[0109] The TID subfield identifies the TC or TS requesting a TXOP by setting the requested TXOP duration or queue size subfield. The encoding of the TID subfield depends on the access policy (e.g., allowed values ​​of 0 to 7 for Enhanced Distributed Channel Access (EDCA) access policies to identify the user priority of the TC or TS).

[0110] The Ack policy indicator subfield, along with other information, identifies the acknowledgment policy followed during MPDU delivery (e.g., normal Ack, implicit block Ack request, no Ack, block Ack, etc.).

[0111] The queue size subfield is an 8-bit field that indicates the buffered traffic at the STA for a given TC or TS to be transmitted to the AP identified by the receiver address of the frame containing the subfield. The queue size subfield is present in QoS empty frames transmitted by the STA when bit 4 of the QoS control field is set to 1. The AP can use the information contained in the queue size subfield to determine the duration of a TXOP allocated to the STA or to determine the uplink (UL) resources allocated to the STA.

[0112] In frames transmitted by or to an inefficient (non-HE) STA, the following rules may be applied to the queue size value: The queue size value is an approximate total size of all MSDUs and A-MSDUs (excluding MSDUs or A-MSDUs included in the current QoS data frame) buffered at the STA in the delivery queues used for MSDUs and A-MSDUs, rounded up to the nearest multiple of 256 octets and represented in units of 256 octets, where the TID value is equal to the value indicated in the TID subfield of the QoS control field. A queue size value of 0 is used only to indicate that there are no buffered transactions in the queue used for the specified TID. The queue size value of 254 is used for all sizes greater than 64,768 octets. The queue size value of 255 is used to indicate an unspecified or unknown size.

[0113] In frames sent from HE STA to HE AP, the following rules can be applied to queue size values.

[0114] The queue size value QS is an approximate total size in octet of all MSDUs and A-MSDUs buffered at the STA in the delivery queue for MSDUs and A-MSDUs (including MSDUs or A-MSDUs contained in the same PSDU as the frame containing the queue size subfield), where the TID value is equal to the value indicated in the TID subfield of the QoS control field.

[0115] The queue size subfield includes the scaling factor subfield in bits B14-B15 of the QoS control field and the unscaled value UV in bits B8-B13 of the QoS control field. The scaling factor subfield provides the scaling factor SF.

[0116] The STA obtains the queue size QS from the received QoS control field, which contains the scaling factor SF and the unscaled value UV, as shown below: QS= 16×UV, if SF equals 0; 1024 + 256 × UV, if SF equals 1; 17 408 + 2048 × UV, if SF equals 2; 148 480+32 768×UV, if SF equals 3 and UV is less than 62; >2 147 328, if SF equals 3 and UV equals 62; Unspecified or unknown if SF equals 3 and UV equals 63.

[0117] The TXOP Duration Request subfield, which can be included in place of the Queue Size subfield, indicates the duration in 32 microseconds (µs) that the sending STA needs to determine for the next TXOP for the specified TID. The TXOP Duration Request subfield is set to 0 to indicate that no TXOP is requested for the specified TID during the current Service Hour (SP). The TXOP Duration Request subfield is set to a non-zero value to indicate the requested TXOP duration in increments of 32 µs, ranging from 32 µs to 8160 µs.

[0118] HT control fields can include aggregate control (AC control) subfields. A-control subfields can include control list subfields that contain one or more control subfields.

[0119] The control subfield can be a BSR control subfield, which can contain buffer status information used for UL MU operations. The BSR control subfield can be formed by the Access Class Index (ACI) bitmap subfield, incremental TID subfield, ACI high subfield, scaling factor subfield, queue size high subfield, and all queue size subfields of the HT control field.

[0120] The ACI bitmap subfield indicates the access category for reporting buffer status (e.g., B0: Best Effort (AC_BE), B1: Background (AC_BK), B2: Video (AC_VI), B3: Voice (AC_VO), etc.). Each bit of the ACI bitmap subfield is set to 1 to indicate that the buffer status of the corresponding AC is included in all subfields of the queue size, otherwise it is set to 0, except that if the ACI bitmap subfield is 0 and the incremental TID subfield is 3, then the buffer status of all 8 TIDs is included.

[0121] The incremental TID subfield, together with the value of the ACI bitmap subfield, indicates the number of TIDs that the STA is reporting the buffer status for.

[0122] The ACI high subfield indicates the ACI of the AC of the BSR in the queue size high subfield. The ACI to AC mapping is defined as ACI value 0 mapping to AC_BE, ACI value 1 mapping to AC_BK, ACI value 2 mapping to AC_VI, and ACI value 3 mapping to AC_VO.

[0123] The scaling factor subfield indicates the queue size height and the unit SF (in octet bytes) of all queue size subfields.

[0124] The queue size high subfield indicates the buffered traffic (in SF octets) of the AC identified by the ACI high subfield, which is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0125] The queue size all subfields indicate the amount of buffered traffic (in SF octets) of all ACs identified by the ACI bitmap subfield, which is intended for use by the STA identified by the receiver address of the frame containing the BSR control subfield.

[0126] The queue size values ​​in both the queue size high and queue size all subfields are the total size of all MSDUs and A-MSDUs buffered at the STA in the delivery queues of the MSDUs and A-MSDUs associated with the AC, as specified in the ACI high and ACI bitmap subfields respectively, including MSDUs or A-MSDUs contained in the same PSDU as the frame containing the BSR control subfield, rounded up to the nearest multiple of the SF octet.

[0127] A queue size value of 254 in both the queue size high and all queue size subfields indicates that the amount of buffered traffic is greater than 254 × SF octets. A queue size value of 255 in both the queue size high and all queue size subfields indicates that the amount of buffered traffic is unspecified or unknown. The queue size value for QoS data frames containing fragments can remain constant, even if the amount of queued traffic changes as consecutive fragments are transmitted.

[0128] The MAC service provides the ability to exchange MSDUs with peer entities. To support this service, the local MAC uses an underlying PHY-level service to transport MSDUs to peer MAC entities. This asynchronous MSD transport is performed on a connectionless basis.

[0129] Figure 7 The diagram illustrates an example format of a PPDU. As shown, a PPDU may include a PHY preamble, a PHY header, a PSDU, and a tail and padding bits.

[0130] A PSDU may include one or more MPDUs, such as a QoS data frame, an MMPDU, a MAC control frame, or a QoS empty frame. When an MPDU carries a QoS data frame, the frame body of the MPDU may include an MSDU or an A-MSDU.

[0131] By default, MSDU delivery is based on best-effort. That is, there is no guarantee that the delivered MSDU will be successfully delivered. However, QoS facilities use Service Identifiers (TIDs) to specify differentiated services based on each MSDU.

[0132] The STA can differentiate MSDU delivery based on the specified service category (TC) or service flow (TS) of an individual MSDU. The MAC sublayer entity determines the user priority (UP) for the MSDU based on the TID value provided with the MSDU. The QoS facility supports eight UP values. The UP values ​​range from 0 to 7 and form an ordered sequence of priorities, where 1 is the lowest value, 7 is the highest value, and 0 falls between 2 and 3.

[0133] MSDUs with a specific UP are referred to as belonging to the service category of that UP. Each MSDU at the Media Access Control Service Access Point (MAC SAP) can be provided directly to the UP in the UP parameters. A-MPDUs can include MPDUs with different TID values.

[0134] The STA can deliver Buffer Status Reports (BSRs) to assist the AP in allocating UL MU resources. The STA can deliver a BSR implicitly (unrequested BSR) in the QoS control field or BSR control subfield of any frame transmitted to the AP, or explicitly deliver a BSR (requested BSR) in a frame transmitted to the AP in response to a BSR P trigger frame.

[0135] The buffer status reported in the QoS control field includes the queue size value for a given TID. The buffer status reported in the BSR control field includes the ACI bitmap, incremental TID, high-priority AC, and two queue sizes.

[0136] The STA can report the buffer status of transmitted QoS empty frames and QoS data frames to the AP in the QoS control field, and report the buffer status of transmitted QoS empty frames, QoS data frames and management frames to the AP in the BSR control subfield (if present), as defined below.

[0137] The STA can report the queue size for a given TID in the queue size subfield of the QoS control field of the transmitted QoS data frame or QoS empty frame; the STA can set the queue size subfield to 255 to indicate an unknown / unspecified queue size for that TID. The STA can aggregate multiple QoS data frames or QoS empty frames in the A-MPDU to report the queue size for different TIDs.

[0138] If the AP has indicated its support for the receive BSR control subfield, the STA can report the buffer status in the BSR control subfield of the transmitted frame.

[0139] The High Efficiency (HE) STA can report the queue size for the preferred AC, as indicated by the ACI high subfield, in the queue size high subfield of the BSR control subfield. The STA can set the queue size high subfield to 255 to indicate an unknown / unspecified queue size for that AC.

[0140] The HE STA can report the queue size for an AC, indicated by the ACI bitmap field in all subfields of the queue size control subfield. The STA can set all subfields of queue size to 255 to indicate unknown / unspecified BSRs for those ACs.

[0141] A multi-link device (MLD) is an entity capable of managing communication on multiple links. An MLD can be a logical entity and can have more than one affiliated station (STA). An MLD can be an access point MLD (AP MLD), where the STAs affiliated with the MLD are AP STAs (or APs). An MLD can also be a non-access point MLD (non-AP MLD), where the STAs affiliated with the MLD are non-AP STAs (or STAs).

[0142] Depending on the capabilities of both the communication AP MLD and the non-AP MLD, communication across different frequency bands / channels can occur simultaneously or at different times.

[0143] An MLD can have a single MAC service access point (MAC-SAP) to the LLC layer, which includes MAC data services. An MLD can support multiple MAC sub-layers coordinated by a Sub-Layer Management Entity (SME). Each APSTA (or non-AP STA) attached to an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0144] The SME is responsible for coordinating the MAC sublayer management entity (MLME) of the MLD's affiliated STA to maintain a single Robust Secure Network Association (RSNA) key management entity and a single IEEE 802.1X authenticator or requester for multi-link operation (MLO).

[0145] The Multi-Link Operation (MLO) procedure allows MLD pairs to discover, synchronize, (de)authenticate, (re)associate, disassociate, and manage each other's resources on any common frequency band or channel supported by two MLDs. The authenticator and MAC-SAP of an AP MLD can be identified by the same AP MLD MAC address. The requester and MAC-SAP of a non-AP MLD can be identified by the same non-AP MLD MAC address.

[0146] Figure 8The illustration shows an example multi-AP network 800. The example multi-AP network 800 can be a multi-AP network according to the Wi-Fi Alliance standard specifications for multi-AP networks. For example... Figure 8 As shown, the multi-AP network 800 may include a multi-AP controller 802 and multiple multi-AP groups (or multi-AP sets or AP candidate sets), including multi-AP group 804, multi-AP group 806 and multi-AP group 808.

[0147] The multi-AP controller 802 can be a logical entity that implements the logic for controlling the APs in the multi-AP network 800. The multi-AP controller 802 can receive capability information and measurement results from the APs and can trigger AP control commands and operations on the APs. The multi-AP controller 802 can also provide loading functionality to load APs and provide them to the multi-AP network 800.

[0148] Multiple AP groups 804, 806, and 808 can each include multiple APs. APs in a multiple AP group are within each other's communication range. However, APs in a multiple AP group do not need to have the same primary channel. As used herein, the primary channel of an AP refers to the default channel used by the AP to monitor management frames and / or transmit beacon frames. For a STA associated with an AP, the primary channel refers to the AP's primary channel, which is advertised via the AP's beacon frames.

[0149] In one approach, one of the APs in a multi-AP group can be designated as the master AP. The designation of the master AP can be done by the multi-AP controller 802 or by the APs in the multi-AP group. The master AP of the multi-AP group can be fixed or can change over time among the APs in the group. APs that are not the master AP of the multi-AP group are referred to as slave APs.

[0150] In one approach, a multi-AP group or AP candidate set is a set of APs that can initiate or participate in multi-AP coordination. APs in a multi-AP group can participate as slave APs in multi-AP coordination initiated by a master AP in the same multi-AP group. At least one AP in the multi-AP group should be able to act as a master AP.

[0151] In one approach, the APs in a multi-AP group can coordinate with each other, including coordinating transmissions within the multi-AP group. One aspect of this coordination may include coordination for performing multi-AP transmissions within the multi-AP group. As used herein, a multi-AP transmission is a transmission event in which multiple APs (in a multi-AP group or multi-AP network) transmit simultaneously over a time period. The time period for simultaneous AP transmissions can be consecutive time periods.

[0152] Multi-AP group coordination can be enabled by a multi-AP controller and / or by the master AP of the multi-AP group. In one approach, the multi-AP controller and / or the master AP can control time and / or frequency sharing within a TXOP. For example, when one of the APs in the multi-AP group (e.g., the master AP) acquires a TXOP, the multi-AP controller and / or the master AP can control how the time / frequency resources of the TXOP are shared with other APs in the multi-AP group. In one implementation, the AP that acquires the TXOP in the multi-AP group becomes the master AP in the multi-AP group. The master AP can then share a portion (which can be the entire TXOP) of its acquired TXOP with one or more other APs in the multi-AP group.

[0153] Multi-AP operation can be enabled by at least two APs that support multi-AP coordination within one or more multi-AP groups. APs can support multi-AP transmission schemes in a multi-AP network. The master AP can coordinate with slave APs to implement multi-AP coordination and support multi-AP transmission. Slave APs can participate in multi-AP transmission. The master AP can select slave APs suitable for multi-AP transmission. Slave APs can be candidates for multi-AP transmission prior to being specified by the master AP.

[0154] Multi-AP transmission schemes may include transmission schemes such as coordinated OFDMA, coordinated time division multiple access (TDMA), coordinated spatial reuse, coordinated beamforming, joint transmission or reception (JT / JR), or a combination of two or more of the aforementioned schemes.

[0155] Coordinated OFDMA (COFDMA) and Coordinated TDMA (CTDMA) can be classified as coordinated TXOP, where the frequency or time resources of TXOP can be used to coordinate interference. Coordinated Spatial Reuse (CSR) can provide reuse of the spatial domain of adjacent BSSs by adjusting the transmit power of the coordinated AP. Coordinated Beamforming (CBF) can provide dedicated null control with spatial radiation to suppress interference by means of multiple antennas based on channel state information (CSI) feedback from the coordinated AP. JT / JR can use distributed MIMO precoding or detection for data streams between multiple APs via shared CSI.

[0156] Figure 9 The diagram illustrates an example network 900 that includes a set of coordinated access points. Figure 9 As shown, a coordinated AP set may include AP 902-1 and AP 902-2. The coordinated AP set may be a subset of the established multi-AP group. At least one STA may be associated with each of APs 902-1 and 902-2. For example, STA 904-1 may be associated with AP 902-1, and STA 904-2 may be associated with AP 902-2.

[0157] AP 902-1 and 902-2 can belong to the category mentioned above. Figure 1 The same ESS described in [the original text]. In such a case, AP902-1 and 902-2 can be connected via DS to support ESS features. Furthermore, as part of a coordinated AP set, AP 902-1 and 902-2 can be connected via backhaul. Backhaul is used to quickly share information between APs to support coordinated transmission. The shared information can be channel state information or data to be sent to the associated STA. Backhaul can be wired or wireless. Wired backhaul is preferred for high-capacity information transmission without burdening the AP's main radio. However, wired backhaul may require higher deployment costs and may impose greater constraints on AP placement. Wireless backhaul is preferred due to its lower deployment costs and flexibility regarding AP placement. However, because wireless backhaul relies on the AP's main radio to transmit information, the AP cannot transmit or receive any data while using wireless backhaul.

[0158] Typically, one of APs 902-1 and 902-2 can act as the primary AP, while the other acts as the secondary AP. The primary AP is the AP that owns the TXOP. The primary AP shares frequency resources with the secondary AP during the TXOP. When there are more than two APs in the coordination set, the primary AP may share its TXOP with only a subset of the coordination set of APs. The role of the primary AP can change over time. For example, the primary AP role can be assigned to a specific AP for a period of time. Similarly, the secondary AP role can be dynamically selected by the primary AP or pre-assigned for a period of time.

[0159] Depending on the capabilities of the APs in the coordinated AP set, an AP may perform only a certain type of coordinated transmission. For example, in Figure 9 In this context, if AP 902-1 supports JT and CSR, while AP 902-2 supports CSR and CBF, then both APs can execute CSR alone as a coordinated transmission scheme. If the benefits of coordinated transmission do not outweigh some of its disadvantages, such as reduced flexibility and increased computational power required, then the APs may prefer to execute a single AP transmission for a period of time.

[0160] CSR can be derived from, for example Figure 9The APs 901-1 and 902-2 shown support one type of multi-AP coordination. Spatial reuse using CSR can be more stable than non-AP coordinated spatial reuse schemes such as Overlapping Basic Service Set (OBSS) Packet Detection-based (PD) SR and PSR-based SR. For example, in example network 900, APs 902-1 and 902-2 can perform joint probe operations to measure path loss (PL) on paths in network 900. For example, the joint probe operation might achieve the measurement of PL 908 for the path between APs 902-1 and 902-2, path loss 910 for the path between AP 902-1 and STA 904-2, and path loss 912 for the path between AP 902-2 and STA 904-1. The measured path loss information can then be shared between APs 902-1 and 902-2 (e.g., using backhaul) to allow APs 902-1 and 902-2 to transmit simultaneously to their associated STAs 904-1 and 904-2, respectively. Specifically, one of APs 902-1 and 902-2 acquires a TXOP to become the master AP. The master AP can then send CSR advertisement frames to the other APs. In an embodiment, the master AP may perform a polling operation before sending the CSR advertisement frame to poll the slave APs regarding packet availability for transmission. If at least one slave AP responds indicating packet availability, the master AP can proceed to send the CSR advertisement frame. In the CSR advertisement, the master AP may limit the transmission power of the slave APs to protect its own transmission to its target STA. Similarly, the slave APs can protect their own transmission to their target STA by selecting a modulation scheme that achieves a sufficiently high signal-to-interference ratio (SIR) margin to support interference caused by transmissions from the master AP to its target STA.

[0161] Figure 10 Example 1000 illustrates a multi-AP operation flow. In Example 1000, the multi-AP operation flow is illustrated for a multi-AP network including APs 1002 and 1004, and STAs 1006 and 1008. In the example, APs 1002 and 1004 can form a multi-AP group. AP 1002 can be the master AP, and AP 1004 can be a slave AP. For example, AP 1002 can obtain a TXOP, making it the master AP of the multi-AP group. Alternatively, AP 1002 can be designated as the master AP by the multi-AP controller.

[0162] like Figure 10As shown, the multi-AP operation process may include a series of time phases, where each phase may include multiple frame exchanges within the multi-AP network. Specifically, the multi-AP operation process may include a multi-AP selection phase 1010, a multi-AP data sharing phase 1012, a multi-AP detection phase 1014, and a multi-AP data transmission phase 1016.

[0163] Multi-AP networks can perform multi-AP operations based on a specific multi-AP transmission scheme. The multi-AP transmission scheme can be selected by the master AP based on the capabilities of the slave APs in the multi-AP group. Before multi-AP operation, slave APs can notify the master AP of their associated capability information, including their ability to support one or more multi-AP transmission schemes. Slave APs can also notify the master AP of their BSS information and the link quality information of the STAs associated with them. The master AP can receive information related to all available slave APs. This information can include capability information, BSS information, and link quality information. Based on the information provided by the available slave APs, the master AP can determine, during the multi-AP selection phase, which slave APs will be designated for multi-AP transmission and the specific multi-AP transmission scheme to be used during the multi-AP transmission.

[0164] The multi-AP selection phase 1010 may include procedures for the master AP to request, select, or specify slave APs in a multi-AP group. For example... Figure 10 As shown, the multi-AP selection phase may include the transmission of frame 1018 from AP 1002 and frame 1020 from AP 1004. AP 1002 may transmit frame 1018 to request information about the buffer status of AP 1004. In response, AP 1004 may transmit frame 1020 to inform AP 1002 of its buffer status and / or whether it intends to join the multi-AP operation. The multi-AP selection phase 1010 may also be used to exchange information related to multi-AP operation, including, for example, the BSS information of the APs and the link quality information between each AP and its associated STAs. The BSS information of the APs may include the BSSID of the AP's BSS, the identifiers and / or capabilities of the STAs belonging to the BSS, information about the STAs' detection capabilities, information about the AP's MIMO capabilities, etc. The link quality information may include Received Signal Strength Indicator (RSSI), Signal-to-Noise Ratio (SNR), Signal-to-Interference-plus-Noise Ratio (SINR), Channel State Information (CSI), and Channel Quality Indicator (CQI).

[0165] Multi-AP data sharing phase 1012 may include a process for sharing data frames to be transmitted between the master AP and selected slave APs via direct connections between APs to the associated STA. Phase 1012 may be optional for some multi-AP data transmission schemes. For example, JT / JR may require phase 1012 because data frames can be exchanged between APs before or after multi-AP data transmission phase 1016.

[0166] The multi-AP data sharing phase 1012 can be performed using wired backhaul, in-channel wireless backhaul, or out-of-channel wireless backhaul. In some cases, the multi-AP data sharing phase 1012 can be performed on in-channel backhaul, for example, using the same wireless channel used to transmit / receive data to / from the STA. For example, as... Figure 10 As shown, in stage 1012, AP 1002 can transmit frame 1022, which can be received by AP 1004. Frame 1022 may include an MPDU that AP 1002 wishes to transmit to an associated STA using multi-AP operation. Similarly, AP 1004 can transmit frame 1024, which can be received by AP 1002. Frame 1024 may include an MPDU that AP 1004 wishes to transmit to an associated STA using multi-AP operation.

[0167] Multi-AP probing phase 1014 may include procedures for multi-AP channel probing, including channel estimation and feedback of channel estimates between the master AP, candidate slave APs, and associated STAs. Phase 1014 may be optional for some multi-AP transport schemes (such as COFDMA, CDTMA, and CSR). For example, phase 1014 may be performed by the master AP to assist in resource unit allocation when orchestrating COFDMA transports.

[0168] Multi-AP data transmission phase 1016 may include exchanging data frames between the master AP, slave APs, and their associated STAs based on a multi-AP transmission scheme determined by the master AP. Depending on the multi-AP transmission scheme to be used, phase 1016 may include optional synchronization between APs in the multi-AP group before exchanging data frames between APs and STAs within the multi-AP group.

[0169] The order of stages 1010, 1012, 1014, and 1016 can be compared with... Figure 10 The differences are illustrated. For example, in COFDMA, stage 1016 may occur immediately after stage 1010, while in JT / JR, stage 1012 may occur after stage 1010. Furthermore, as mentioned above, some stages may be optional and may or may not be present. For example, stage 1014 may not be required for COFDMA but may be required for JT / JR.

[0170] Figure 11 The illustration shows an example 1100 of a multi-AP detection phase. Multi-AP detection phase 1100 can be an example of multi-AP detection phase 1014. For example... Figure 11 As shown, Example 1100 may include a master AP 1102 and a slave AP 1104 in a multi-AP group. Example 1100 may also include a STA 1106 associated with AP 1102 and a STA 1108 associated with AP 1104.

[0171] like Figure 11 As shown, the multi-AP detection phase 1100 may include frame switching to allow AP 1102 (the master AP) to acquire channel state information (CSI) of the channels in the multi-AP group. In an implementation, phase 1100 may include a first sub-phase 1110 and a second sub-phase 1112.

[0172] During the first sub-phase 1110, the AP can initiate channel sensing, and the STA can estimate the CSI. For example, AP 1102 can transmit frame 1114 to AP 1104 (from the AP) to trigger multi-AP sensing. Frame 1114 may include a multi-AP trigger frame. Subsequently, APs 1102 and 1104 can transmit advertisement frames 1116-1 and 1116-2 to their respective associated STAs 1106 and 1108 to announce the transmission of the sensing frames. Frames 1116-1 and 1116-2 may include multi-AP null data PPDU advertisement (NDPA) frames. Frames 1116-1 and 1116-2 may be transmitted simultaneously. Next, APs 1102 and 1104 can transmit frames 1118-1 and 1118-2 to STAs 1106 and 1108, respectively. Frames 1118-1 and 1118-2 may include multi-AP null data PPDU (NDP) frames. STAs 1106 and 1108 receive frames 1118-1 and 1118-2 respectively, and perform channel estimation for the channels from AP 1102 to STA 1106 and from AP 1104 to STA 1108 respectively.

[0173] During the second sub-phase 1112, the AP can initiate a process for STAs to feed back channel estimates to the AP. For example, AP 1102 can transmit frame 1120 to trigger STAs 1106 and 1108 to transmit their channel estimates to APs 1102 and 1104, respectively. Frame 1120 may include a multi-AP trigger frame. In response, STAs 1106 and 1108 can transmit frames 1122 and 1124, respectively, to APs 1102 and 1104, including feedback on the channel estimates. Frames 1122 and 1124 may include NDP feedback frames. The feedback on the channel estimates may include NDP feedback, CSI-related information, beamforming report (BFR), or channel quality indication (CQI) report.

[0174] Figure 12 The illustration shows an example 1200 of the multi-AP downlink data transmission phase. The multi-AP downlink data transmission phase 1200 can be an example of the multi-AP data transmission phase 1016. For example... Figure 12 As shown, Example 1200 may include a master AP 1202 and a slave AP 1204 in a multi-AP group. Example 1200 may also include a STA 1206 associated with AP 1202 and a STA 1208 associated with AP 1204.

[0175] like Figure 12 As shown, the multi-AP downlink data transmission phase 1200 may include frame switching to enable the master AP 1202 to coordinate with the slave AP 1204 to execute a specific multi-AP transmission scheme with its associated STAs 1206 and 1208, respectively. The multi-AP transmission scheme may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the above schemes.

[0176] like Figure 12 As shown, the master AP 1202 can initiate phase 1200 by transmitting frame 1210 to AP 1204. Frame 1210 may include information related to AP 1204 (e.g., an identifier for AP 1204), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to resource elements (RUs) used by AP 1204 to acknowledge frame 1210. Frame 1210 may include a control frame. For example, frame 1210 may include a multi-AP trigger frame.

[0177] AP 1204 can receive frame 1210 and can use synchronization information to synchronize with the master AP 1202. Subsequently, APs 1202 and 1204 can respectively perform data transmissions to their associated STAs 1206 and 1208. Specifically, AP 1202 can transmit data frame 1212 to its associated STA 1206, and AP 1204 can transmit data frame 1214 to its associated STA 1208. Depending on the multi-AP transmission scheme used, APs 1202 and 1204 can respectively transmit frames 1212 and 1214 to STAs in different BSSs. For example, when the multi-AP transmission scheme is JT / JR, AP 1202 can also transmit frame 1212 to STA 1208 associated with AP 1204, and AP 1204 can also transmit frame 1214 to STA 1208 associated with AP 1204. The resources used to transmit and receive frames 1212 and 1214 can depend on the specific multi-AP transmission scheme employed.

[0178] STAs 1206 and 1208 can acknowledge frames 1212 and 1214, respectively. For example, STA 1206 can transmit frame 1216 to AP 1202, and STA 1208 can transmit frame 1218 to AP 1204. Frames 1216 and 1218 may include block Ack (BA) frames. When required by the multi-AP transmission scheme used, STAs 1206 and 1208 can also transmit frames 1216 and 1218 to APs in different BSSs. For example, when the multi-AP transmission scheme is JT / JR, STA 1206 can also transmit frame 1216 to AP 1204, and STA 1208 can also transmit frame 1218 to AP 1202. The resources used for transmitting and receiving frames 1216 and 1218 may depend on the specific multi-AP transmission scheme employed.

[0179] Figure 13 The illustration shows an example 1300 of the multi-AP uplink data transmission phase. The multi-AP uplink data transmission phase 1300 can be an example of the multi-AP data transmission phase 1016. For example... Figure 13 As shown, Example 1300 may include a master AP 1302 and a slave AP 1304 in a multi-AP group. Example 1300 may also include STAs 1306 and 1308 associated with AP 1302, and STA 1310 associated with AP 1304.

[0180] like Figure 13 As shown, the multi-AP uplink data transmission phase 1300 may include frame switching to enable the master AP 1302 to coordinate with the slave AP 1304 to execute a specific multi-AP transmission scheme with STAs 1306, 1308, and 1310. The multi-AP transmission scheme may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the above schemes.

[0181] like Figure 13 As shown, the master AP 1302 can initiate phase 1300 by transmitting frame 1312 to AP 1304. Frame 1312 may include information related to AP 1304 (e.g., an identifier for AP 1304), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to the RU used by AP 1304 to acknowledge frame 1312. Frame 1312 may include a control frame. For example, frame 1312 may include a multi-AP trigger frame.

[0182] AP 1304 can receive frame 1312 and can use synchronization information to synchronize with the master AP 1302. Subsequently, APs 1302 and 1304 can use trigger frames to request uplink data transmissions from their associated STAs 1306, 1308, and 1310. Specifically, AP 1302 can transmit trigger frame 1314 to its associated STAs 1306 and 1308, and AP 1304 can transmit trigger frame 1316 to its associated STA 1310. Depending on the multi-AP transmission scheme used, APs 1302 and 1304 can also transmit frames 1314 and 1316 to STAs in different BSSs, respectively. For example, when the multi-AP transmission scheme is JT / JR, AP 1302 can also transmit frame 1314 to STA 1310 associated with AP 1304, and AP 1304 can also transmit frame 1316 to STAs 1306 and 1308 associated with AP 1302. The resources used for transmitting and receiving frames 1314 and 1316 may depend on the specific multi-AP transmission scheme employed.

[0183] STAs 1306 and 1308 can respond to frame 1314, and STA 1310 can respond to frame 1316. For example, STAs 1306 and 1308 can transmit frames 1318 and 1320 to AP 1302, respectively, while STA 1310 can transmit frame 1322 to AP 1304. Frames 1318, 1320, and / or 1322 can be transmitted simultaneously. Frames 1318, 1320, and 1322 may include data frames or empty data frames. When required by the multi-AP transmission scheme used, STAs 1306, 1308, and 1310 can also transmit frames 1318, 1320, and 1322 to APs in different BSSs, respectively. For example, when the multi-AP transmission scheme is JT / JR, STAs 1306 and 1308 can also transmit frames 1318 and 1320 to AP 1304, and STA 1310 can also transmit frame 1322 to AP 1302. The resources used for transmitting and receiving frames 1318, 1320, and 1322 can depend on the specific multi-AP transmission scheme employed. AP 1302 can acknowledge frames 1318 and 1320 by transmitting a multi-STA BA frame 1324 to STAs 1306 and 1308. AP 1304 can acknowledge frame 1322 by transmitting a BA frame 1326 to STA 1310.

[0184] Figure 14The diagram illustrates Enhanced Distributed Channel Access (EDCA) and Coordinated Time Division Multiple Access (CTDMA). In CTDMA, an AP (often called the master AP or sharing AP) can share a portion of its TXOP with one or more APs (often called slave APs or shared APs). Specifically, the sharing AP can assign / allocate a corresponding time slot within its TXOP for each of the one or more APs. The shared AP can use its assigned time slot to communicate with one or more STAs. Compared to Enhanced Distributed Channel Access (EDCA), CTDMA... Figure 14 The example shown is a multi-AP channel access scheme. Figure 14 As shown, in EDCA, channel access by multiple APs (e.g., AP1, AP2) can occur within consecutive time periods (e.g., TXOPs), where each AP has its own TXOP. During a given channel access period, a single AP can use its entire channel for the duration of the TXOP. Conversely, in CTDMA, access by multiple APs can occur within the same TXOP within consecutive time periods. For example, as... Figure 14 As shown, a TXOP can be divided into two non-overlapping time slots, each assigned to a corresponding AP among multiple APs. Multiple APs can transmit consecutively in a coordinated manner within the same TXOP. In the example, as... Figure 14 As shown, a primary / shared AP (e.g., AP1) can use itself as the first part of a first TXOP and can share the second part of the first TXOP with a secondary / shared AP (e.g., AP2). In another example, a primary / shared AP (e.g., AP1) can share the first part of a second TXOP with a secondary / shared AP (e.g., AP2) and can use itself as the second part of the second TXOP.

[0185] Triggered TXOP Sharing (TXS) is a technology introduced in the IEEE 802.11be standard modification. TXS allows an AP to allocate the duration within a acquired TXOP to a STA for sending one or more non-triggered (non-TB) PPDUs. For the TXS procedure, the AP can transmit a Multi-User Request to Send (MU-RTS) trigger frame with the Triggered TXOP Sharing Mode subfield set to a non-zero value. The MU-RTS trigger frame is used to trigger CTS frames from multiple users. An MU-RTS trigger frame with the Triggered TXOP Sharing Mode subfield set to a non-zero value is called a MU-RTS TXS Trigger (MRTT) frame.

[0186] In the example, when the triggered TXOP sharing mode subfield is set to 1, the STA can transmit one or more non-TB PPDUs to the AP during the allocated duration. In the example, when the triggered TXOP sharing mode subfield is set to 2, the STA can transmit one or more non-TB PPDUs to the AP or a peer STA during the allocated duration. A peer STA can be a STA with a connection for peer-to-peer (P2P) communication or direct communication with another STA. In the example, a direct wireless link is established according to the Tunnel Direct Link Establishment (TDLS) protocol.

[0187] Figure 15 The illustration shows an example of an MRTT frame 1500 that can be used in the TXS process. For example... Figure 15 As shown, the example MRTT frame 1500 may include a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a common information field, a user information list field, a padding field, and / or a frame check sequence (FCS) field.

[0188] In the example, the public information field can be either the High Efficiency (HE) variant public information field or the Extremely High Throughput (EHT) variant public information field. For example... Figure 15 As shown, the EHT variant public information field may include one or more of the following subfields: trigger type, UL length, additional TF, required CS, UL BW, GI and HE / EHT-LTF type / triggered TXOP sharing mode, number of HE / EHT-LTF symbols, LDPC additional symbol fragments, AP Tx power, pre-FEC fill factor, PE disambiguation, UL space reuse, HE / EHT P160, special user information field flag, EHT reservation, reservation, or trigger-related public information.

[0189] The trigger type subfield indicates that frame 600 is an MRTT frame.

[0190] The GI and HE / EHT-LTF type / triggered TXOP sharing mode subfield can include a triggered TXOP sharing mode subfield. In the example, the triggered TXOP sharing mode subfield can be set to a non-zero value (e.g., 1 or 2). In the example, the triggered TXOP sharing mode subfield can be set to 1. This allows the triggered TXOP sharing mode subfield to indicate that the STA indicated by the AID12 subfield of the User Information field (of the User Information List field) can transmit one or more non-TB PPDUs to the AP during the time period indicated in the Allocation Duration subfield of the User Information field. In another example, the triggered TXOP sharing mode subfield can be set to 2. This allows the triggered TXOP sharing mode subfield to indicate that the STA indicated by the AID12 subfield of the User Information field (of the User Information List field) can transmit one or more non-TB PPDUs to the AP or peer STA during the time period indicated in the Allocation Duration subfield of the User Information field. In the example, the peer STA can be a STA with a connection for P2P or direct communication with the STA.

[0191] The user information list fields can include one or more user information fields. In the example, such as... Figure 15 As shown, the EHT variant user information field may include one or more of the following subfields: AID12, RU allocation, allocation duration, reservation, or PS160.

[0192] The AID12 subfield can indicate the associated identifier (AID) of the STA that can use the time indicated by the Assigned Duration subfield.

[0193] The RU allocation subfield can indicate the location and size of the RU allocated to the STA indicated by the AID12 subfield.

[0194] The allocation duration subfield can indicate the time allocated by the AP transmitting MRTT frame 1500. The allocated time can be a portion of the TXOP obtained by the AP. In an example embodiment, the allocation duration subfield can indicate a first time period.

[0195] Figure 16 Example 1600 illustrates the TXS process (mode=1). Figure 16As shown, the TXS procedure can begin when AP1610 transmits MRTT frame 1620 to STA 1611. MRTT frame 1620 may allocate a portion of the TXOP obtained by AP 1610 to STA 1611 and may indicate a TXS mode equal to 1. STA 1611, receiving MRTT frame 1620, can use the allocated time to transmit one or more non-TB PPDUs to AP 1610. The one or more non-TB PPDUs may include data frames, control frames, management frames, or action frames.

[0196] In the example, MRTT frame 1620 may include a triggered TXOP shared mode subfield indicating TXS mode and / or a subfield indicating a first time period corresponding to the allocated time. In the example, the first time period may be set to a value of X microseconds (µs).

[0197] STA 1611 can respond to MRTT frame 1620 by transmitting CTS frame 1621 to AP 1610. Subsequently, STA 1611 can transmit non-TB PPDUs 1622, 1624, including one or more data frames, to AP 1610 during a first time period indicated in MRTT frame 1620. In the example, AP 1610 can transmit one or more block Ack(BA) frames 1623, 1625 in response to one or more data frames contained in the non-TB PPDUs 1622, 1624 received from STA 1611.

[0198] Figure 17 Example 1700 illustrates the TXS process (mode=2). For example... Figure 17 As shown, the TXS procedure can begin with AP1710 transmitting MRTT frame 1720 to STA 1711. MRTT frame 1720 may allocate a portion of the TXOP obtained by AP 1710 to STA 1711 and may indicate a TXS mode equal to 2. STA 1711, receiving MRTT frame 1720, can use the allocated time to transmit one or more non-TB PPDUs to STA 1712. The one or more non-TB PPDUs may include data frames, control frames, management frames, or action frames.

[0199] In the example, MRTT frame 1720 may include a triggered TXOP shared mode subfield indicating TXS mode and / or a subfield indicating a first time period corresponding to the allocated time. In the example, the first time period may be set to a value of Y microseconds (µs).

[0200] STA 1711 can respond to MRTT frame 1720 by transmitting CTS frame 1721 to AP 1710. Subsequently, STA 1711 can transmit non-TB PPDUs 1722, 1724, including one or more data frames, to STA 1712 during the first time period indicated in MRTT frame 1720. In the example, STA 1712 can transmit one or more BA frames 1723, 1725 in response to one or more data frames contained in the non-TB PPDUs 1722, 1724 received from STA 1711.

[0201] In CTDMA, a method for TXOP sharing can be implemented via the aforementioned TXS procedure. The TXS procedure can be used to allow a sharing AP that acquires and owns a TXOP to allocate the duration within its acquired TXOP to a shared AP for downlink and / or uplink transmissions between the shared AP and its associated STA.

[0202] Figure 18 The illustration shows an example 1800 of an existing CTDMA procedure. Figure 18 As shown, Example 1800 may include APs 1802 and 1804, and STAs 1806 and 1808. APs 1802 and 1804 may be members of a multi-AP group. AP 1802 may be the shared / master AP of the multi-AP group. AP 1804 may be the shared / slave AP of the multi-AP group. STA 1806 may be associated with AP 1802, and STA 1808 may be associated with AP 1804. In Example 1800, it is assumed that APs 1802, 1804 and STAs 1806, 1808 are within each other's communication range.

[0203] In implementations, an AP (such as AP 1802 and 1804) or STA (such as STA 1806 and 1808) can maintain two NAVs: an intra-BSS NAV and a basic NAV. The intra-BSS NAV is updated (set or reset) based on intra-BSS PPDUs (i.e., PPDUs received from the BSS to which the STA / AP belongs). The basic NAV is updated (set or reset) based on inter-BSS PPDUs (i.e., PPDUs received from a BSS different from the BSS to which the STA / AP belongs (also called inter-BSS or OBSS)) or PPDUs that cannot be classified as intra-BSS or inter-BSS.

[0204] For STAs using the EDCA access channel, both NAVs must be non-zero. The STA's basic NAV is not updated by transmissions from the AP associated with the STA, such that if the STA's basic NAV is non-zero and the STA receives a trigger frame from the AP with the CS demand subfield equal to 1, the STA does not respond. The STA does not consider the BSS-internal NAV when determining whether to respond to a trigger frame sent by the AP associated with the STA. The STA considers the basic NAV when determining whether to respond to a trigger frame sent by the AP associated with the STA.

[0205] like Figure 18 As shown, the process can begin with AP 1802 transmitting MRTT frame 1812 after acquiring TXOP 1810. In an embodiment, MRTT frame 1812 may include an allocation for AP 1804. The allocation of MRTT frame 1812 may include the identifier of the shared AP and the duration allocated to the shared AP (within the TXOP). In example 1800, MRTT frame 1812 may include an allocation for AP 1804. This allocation may include a first duration of the TXOP allocated to AP 1804 (within the TXOP). Figure 18 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field of MRTT frame 1812. In an embodiment, the duration field of MRTT frame 1812 can indicate a second duration (in...). Figure 18 (represented as t2). The second duration indicated in the duration field of MRTT frame 1812 can be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of MRTT frame 1812 to the second duration allows AP 1802 to protect the CTS frames and / or trigger frames of the shared AP.

[0206] In Example 1800, upon receiving MRTT frame 1812, STA 1806 can set its BSS-internal NAV (such as...) Figure 18 The I-BSS NAV (as shown in 1814) is set to the second duration t2 indicated in MRTT frame 1812. Upon receiving MRTT frame 1812, STA 1808 can set its basic NAV (as shown in 1814) to the second duration t2 indicated in MRTT frame 1812. Figure 18(As shown in NAV 1816) is set to the second duration t2. Upon receiving MRTT frame 1812, AP 1804 can determine that AP 1802 has shared TXOP 1810 with AP 1804 for duration t1. AP 1804 can then transmit CTS frame 1818 to AP 1802 in response to MRTT frame 1812.

[0207] When receiving CTS frame 1818, AP 1802 can set its BSS-in-NAV (e.g., ...) within the remaining duration t2. Figure 18 (As shown in I-BSS NAV 1820). After transmitting CTS frame 1818, AP 1804 can use TXOP for the remaining duration of t1. In the example, AP 1804 can send a TXOP to STA 1808 ( Figure 18 (Not shown in the image) Transmits downlink frames. In another example, AP 1804 can trigger STA 1808 to transmit uplink frames to AP 1804.

[0208] In Example 1800, after transmitting CTS frame 1818, AP 1804 can transmit trigger frame 1822 to STA 1808 to trigger an uplink transmission from STA 1808. In this embodiment, the duration field of trigger frame 1822 may indicate a third duration t3. Upon receiving trigger frame 1822, the OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 1822. Specifically, in Example 1800, upon receiving trigger frame 1822, AP 1802 can set its basic NAV (e.g., ...) Figure 18 The NAV (as shown in NAV 1824) is set to the third duration indicated in trigger frame 1822. Similarly, upon receiving trigger frame 1822, STA 1806 can set its basic NAV (as shown in NAV 1824) to the third duration indicated in trigger frame 1822. Figure 18 The NAV (shown in 1826) is set to the third duration indicated in trigger frame 1822.

[0209] In an implementation, upon receiving trigger frame 1822 and seeing its own address in the RA field of trigger frame 1822, STA 1808 can determine that it wants to transmit an uplink frame to AP 1804. In an embodiment, when trigger frame 1822 is transmitted by AP 1804 associated with STA 1808, STA 1808 can set its BSS NAV (such as...) Figure 18The I-BSSNAV (shown in 1828) is set to the third duration indicated in trigger frame 1822. In another embodiment, STA 1808 may not set its in-BSS NAV. Subsequently, STA 1808 may transmit data frame 1830 to AP 1804. Data frame 1830 may include a duration field indicating the remaining duration of the third duration. In response to data frame 1830, AP 1804 may transmit BA frame 1832 to STA 1808.

[0210] In the example, after transmitting BA frame 1832 to STA 1808, AP 1804 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 1804. In an implementation, AP 1804 may return the remainder of the first duration to AP 1802 (also referred to as truncating the first duration). In example 1800, AP 1804 may transmit frame 1834 indicating that AP 1804 is returning the first duration to AP 1802 (or indicating that AP 1804 is truncating the first duration). In the example, frame 1834 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 1804. In the example, the CF-end frame may be a broadcast frame.

[0211] In Example 1800, upon receiving CF-end frame 1834, AP 1802 can reset its basic NAV to zero before the end of the third duration. AP 1802 can also determine that AP 1804 has returned the first duration to AP 1802. With the first duration returned to AP 1802, AP 1802 (which is the owner of the TXOP) reverts to being the holder of the TXOP. Similarly, upon receiving CF-end frame 1834, STA 1806 can reset its basic NAV before the end of the third duration. Upon receiving CF-end frame 1834, STA 1808 can reset its intra-BSV before the end of the third duration.

[0212] In the example, as the first duration returns to AP 1802, AP 1802 can initiate uplink and / or downlink transmissions during the remaining duration of TXOP 1810 (which includes the remainder of the first duration). In the example, AP 1802 can transmit frame 1836 to STA 1806 to initiate an uplink transmission. In the example, frame 1836 can be a trigger frame. Upon receiving frame 1836, the OBSS AP or OBSS STA can set its basic NAV. Thus, AP 1804 can set its basic NAV (such as...) Figure 18The NAV (as shown in frame 1838) is set to the duration indicated in frame 1836. Similarly, STA 1808 can set its basic NAV (as shown in frame 1838) to the duration indicated in frame 1836. Figure 18 The duration (as shown in NAV 1840) is set to the duration indicated in frame 1836.

[0213] Upon receiving frame 1836 and seeing its own address in the RA field of frame 1836, STA 1806 can determine that it will transmit an uplink frame to AP 1802. STA 1806 can then set its BSS NAV (such as...) Figure 18 The I-BSS NAV (shown in frame 1842) is set to the duration indicated in frame 1836. In another embodiment, STA 1806 may not set its in-BSS NAV. In response to frame 1836, STA 1806 may transmit frame 1844 to AP 1802. In this example, frame 1844 may be a data frame. In this implementation, frame 1844 may include a duration field indicating the remaining portion of frame 1836 as indicated by the duration. In this example, after receiving frame 1844, AP 1802 may continue uplink and / or downlink transmissions within TXOP 1810. In another example, AP 1802 may share the remaining portion of TXOP 1810 with another shared AP.

[0214] Figure 19 Another example of an existing CTDMA procedure is illustrated in Figure 1900. Figure 19 As shown, Example 1900 may include APs 1902 and 1904, and STAs 1906 and 1908. APs 1902 and 1904 may be members of a multi-AP group. AP 1902 may be the shared / master AP of the multi-AP group. AP 1904 may be the shared / slave AP of the multi-AP group. STA 1906 may be associated with AP 1902, and STA 1908 may be associated with AP 1904. In Example 1900, it is assumed that APs 1902, 1904, and STA 1908 are within each other's communication range. It is further assumed that STA 1906 is outside the communication range of AP 1904, but within the communication range of APs 1902 and STA 1908.

[0215] like Figure 19As shown, the process can begin with AP 1902 transmitting MRTT frame 1912 after acquiring TXOP 1910. In an embodiment, MRTT frame 1912 may include an allocation for AP 1904. The allocation of MRTT frame 1912 may include the identifier of the shared AP and the duration allocated to the shared AP (within the TXOP). In example 1900, MRTT frame 1912 may include an allocation for AP 1904. This allocation may include a first duration of the TXOP allocated to AP 1904 (within the TXOP). Figure 19 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field in MRTT frame 1912. In an embodiment, the duration field of MRTT frame 1912 can indicate a second duration (in...). Figure 19 (represented as t2). The second duration indicated in the duration field of MRTT frame 1912 can be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of MRTT frame 1912 to the second duration allows AP 1902 to protect the CTS frames and / or trigger frames of the shared AP.

[0216] In Example 1900, upon receiving MRTT frame 1912, STA 1906 can store its BSS-internal NAV (such as...). Figure 19 The I-BSS NAV (as shown in 1914) is set to the second duration t2 indicated in MRTT frame 1912. Upon receiving MRTT frame 1912, STA 1908 can set its basic NAV (as shown in 1914) to the second duration t2 indicated in MRTT frame 1912. Figure 19 (As shown in NAV 1916) is set to the second duration t2. Upon receiving MRTT frame 1912, AP 1904 can determine that AP 1902 has shared TXOP 1910 with AP 1904 for duration t1. AP 1904 can then transmit CTS frame 1918 to AP 1902 in response to MRTT frame 1912.

[0217] When receiving CTS frame 1918, AP 1902 can set its BSS-in-NAV (e.g., ...) within the remaining duration t2. Figure 19(As shown in I-BSS NAV 1920). After transmitting CTS frame 1918, AP 1904 can use TXOP for the remaining duration of t1. In the example, AP 1904 can send a TXOP to STA 1908 ( Figure 19 (Not shown in the image) Transmits downlink frames. In another example, AP 1904 can trigger STA 1908 to transmit uplink frames to AP 1904.

[0218] In Example 1900, after transmitting CTS frame 1918, AP 1904 can transmit trigger frame 1922 to STA 1908 to trigger an uplink transmission from STA 1908. In this embodiment, the duration field of trigger frame 1922 can indicate a third duration t3. Upon receiving trigger frame 1922, the OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 1922. Specifically, in Example 1900, upon receiving trigger frame 1922, AP 1902 can set its basic NAV (e.g., ...) Figure 19 The NAV (shown in NAV 1924) is set to the third duration indicated in trigger frame 1922. However, outside the communication range of AP1904, STA 1906 may not receive trigger frame 1922 and may not set its basic NAV.

[0219] In an implementation, upon receiving trigger frame 1922 and seeing its own address in the RA field of trigger frame 1922, STA 1908 can determine that it wants to transmit an uplink frame to AP 1904. In an embodiment, when trigger frame 1922 is transmitted by AP 1904 associated with STA 1908, STA 1908 can set its BSS NAV (such as...) Figure 19 The I-BSSNAV (shown in Figure 1926) is set to the third duration indicated in trigger frame 1922. In another embodiment, STA 1908 may not set its in-BSS NAV. Subsequently, STA 1908 may transmit data frame 1928 to AP 1904. Data frame 1928 may include a duration field indicating the remaining duration of the third duration. Upon receiving data frame 1928, STA 1906 may read the duration field of data frame 1928 and may set its basic NAV (e.g., I-BSSNAV 1926) for the remaining duration of the third duration. Figure 19 (As shown in NAV 1930). In response to data frame 1928, AP 1904 can transmit BA frame 1932 to STA 1908.

[0220] In the example, after transmitting BA frame 1932 to STA 1908, AP 1904 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 1904. In an implementation, AP 1904 may return the remainder of the first duration to AP 1902 (also referred to as truncating the first duration). In example 1900, AP 1904 may transmit frame 1934 indicating that AP 1904 is returning the first duration to AP 1902 (or indicating that AP 1904 is truncating the first duration). In the example, frame 1934 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 1904. In the example, the CF-end frame may be a broadcast frame.

[0221] In Example 1900, upon receiving CF-end frame 1934, AP 1902 can reset its basic NAV to zero before the end of the third duration. AP 1902 can also determine that AP 1904 has returned the first duration to AP 1902. With the first duration returned to AP 1902, AP 1902 (which is the owner of the TXOP) returns to being the holder of the TXOP. Outside the communication range of AP1904, STA 1906 may not receive CF-end frame 1934 and may not reset its basic NAV, which was set upon receiving data frame 1928 transmitted by STA 1908. Upon receiving CF-end frame 1934, STA 1908 can reset its intra-BSV before the end of the third duration, as... Figure 19 As shown.

[0222] In the example, as the first duration returns to AP 1902, AP 1902 can initiate uplink and / or downlink transmissions for the remaining duration of TXOP 1910 (which includes the remainder of the first duration). In the example, AP 1902 can transmit frame 1936 to STA 1906 to initiate an uplink transmission. In the example, frame 1936 can be a trigger frame. Upon receiving frame 1936, the OBSS AP or OBSS STA can set its basic NAV. Thus, AP 1904 can set its basic NAV (such as...) Figure 19 The NAV (as shown in Frame 1938) is set to the duration indicated in Frame 1936. Similarly, STA 1908 can set its basic NAV (as shown in Frame 1938) to the duration indicated in Frame 1936. Figure 19 The duration (as shown in NAV 1940) is set to the duration indicated in frame 1936.

[0223] In Example 1900, its basic NAV has already been set for the remainder of the third duration of received data frame 1928. Although frame 1936 is received and its own address is seen in the RA field of frame 1936, STA 1906 cannot respond to frame 1936 transmitted by AP 1902 according to the existing IEEE 802.11 standard. In an implementation, STA 1906 can set its BSS-in-NAV (e.g., ...) Figure 19 The I-BSS NAV (shown in frame 1942) is set to the duration indicated in frame 1936. In another embodiment, STA 1906 may not have its BSS NAV set.

[0224] Therefore, STA 1906 may not transmit any uplink frames to AP 1902 until its basic NAV reaches zero or is reset. In other words, although AP 1904 has returned a TXOP to AP 1902 before the end of the first duration (t1) by transmitting CF-end frame 1934, STA 1906 associated with AP 1902 may be prevented from using the channel to transmit uplink frames to AP 1902 for the remainder of the first duration. This could result in unfair channel access between STAs associated with AP 1902 within AP 1902's communication range and STAs associated with AP 1902 outside AP 1902's communication range.

[0225] As further described below, embodiments of this disclosure address the aforementioned problems. In one aspect, a first AP can receive a trigger frame from a second AP and during a first duration allocated to the second AP by the first AP. The first AP can also receive a first frame from the second AP and during the first duration, the first frame indicating that the second AP should return the first duration to the first AP. After receiving the trigger frame and the first frame, the first AP can transmit a second frame to the first STA for resetting the first STA's basic NAV. Thus, the first STA can respond to any frame received from the first AP when resetting its basic NAV. In another aspect, the first AP can transmit a first frame including an indication of whether the STA is permitted to ignore its basic NAV during the first duration allocated to the second AP by the first AP. The first AP can then receive a second frame from the second AP and during the first duration, the second frame indicating that the second AP should return the first duration to the first AP. Based on the indication that the STA is permitted to ignore its basic NAV during the first duration, the first AP can transmit a third frame to the first STA, the third frame triggering an uplink transmission from the first STA to the first AP. Thus, the first STA can ignore its basic NAV and respond to any frame received from the first AP.

[0226] Figure 20 An example 2000 of a CTDMA process according to an embodiment is illustrated. Figure 20 As shown, Example 2000 may include APs 2002 and 2004, and STAs 2006 and 2008. APs 2002 and 2004 may be members of a multi-AP group. AP 2002 may be the shared / master AP of the multi-AP group. AP 2004 may be a shared / slave AP of the multi-AP group. STA 2006 may be associated with AP 2002, and STA 2008 may be associated with AP 2004. In Example 2000, it is assumed that APs 2002, 2004, and STA 2008 are within each other's communication range. It is further assumed that STA 2006 is outside the communication range of AP 2004, but within the communication range of APs 2002 and STA 2008.

[0227] like Figure 20 As shown, the process can begin with AP 2002 transmitting MRTT frame 2012 after acquiring TXOP 2010. In an embodiment, MRTT frame 2012 may include an allocation for AP 2004. The allocation of MRTT frame 2012 may include the identifier of the shared AP and the duration allocated to the shared AP (within TXOP). In example 2000, MRTT frame 2012 may include an allocation for AP 2004. This allocation may include a first duration of the TXOP allocated to AP 2004 (within TXOP). Figure 20 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field in the MRTT frame 2012. In an embodiment, the duration field of the MRTT frame 2012 can indicate a second duration (in...). Figure 20 (represented as t2). The second duration indicated in the duration field of the MRTT frame 2012 can be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of the MRTT frame 2012 to the second duration allows AP 2002 to protect the CTS frames and / or trigger frames of the shared AP.

[0228] In Example 2000, upon receiving MRTT frame 2012, STA 2006 can set its BSS-internal NAV (such as...) Figure 20The I-BSS NAV (as shown in 2014) is set to the second duration t2 indicated in MRTT frame 2012. Upon receiving MRTT frame 2012, STA 2008 can set its basic NAV (as shown in 2014) to the second duration t2 indicated in MRTT frame 2012. Figure 20 (As shown in NAV 2016) is set to the second duration t2. Upon receiving MRTT frame 2012, AP 2004 can determine that AP 2002 has shared TXOP 2010 with AP 2004 for duration t1. AP 2004 can then transmit CTS frame 2018 to AP 2002 in response to MRTT frame 2012.

[0229] When receiving CTS frame 2018, AP 2002 can set its BSS-in-NAV (e.g., ...) within the remaining duration t2. Figure 20 (As shown in I-BSS NAV 2020). After transmitting CTS frame 2018, AP 2004 can use TXOP for the remaining duration of t1. In the example, AP 2004 can send a TXOP to STA 2008 ( Figure 20 (Not shown in the image) transmits downlink frames. In another example, AP 2004 can trigger STA 2008 to transmit uplink frames to AP 2004.

[0230] In Example 2000, after transmitting CTS frame 2018, AP 2004 can transmit trigger frame 2022 to STA 2008 to trigger uplink transmission from STA 2008. In an embodiment, the duration field of trigger frame 2022 can indicate a third duration t3. Upon receiving trigger frame 2022, OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 2022. Specifically, in Example 2000, upon receiving trigger frame 2022, AP 2002 can set its basic NAV (e.g., ...) Figure 20 The NAV (shown in NAV 2024) is set to the third duration indicated in the trigger frame 2022. However, outside the communication range of AP2004, STA 2006 may not receive trigger frame 2022 and may not set its basic NAV.

[0231] In an embodiment, upon receiving trigger frame 2022 and seeing its own address in the RA field of trigger frame 2022, STA 2008 can determine that it wants to transmit an uplink frame to AP 2004. In an embodiment, when trigger frame 2022 is transmitted by AP 2004 associated with STA 2008, STA 2008 can set its BSS NAV (such as...) Figure 20The I-BSS NAV (shown in Figure 2026) is set to the third duration indicated in trigger frame 2022. In another embodiment, STA 2008 may not set its in-BSS NAV. Subsequently, STA 2008 may transmit data frame 2028 to AP 2004. Data frame 2028 may include a duration field indicating the remaining duration of the third duration. Upon receiving data frame 2028, STA 2006 may read the duration field of data frame 2028 and may set its basic NAV (e.g., I-BSS NAV2026) for the remaining duration of the third duration. Figure 20 (As shown in NAV 2030). In response to data frame 2028, AP 2004 can transmit BA frame 2032 to STA 2008.

[0232] In the example, after transmitting BA frame 2032 to STA 2008, AP 2004 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 2004. In an implementation, AP 2004 may return the remainder of the first duration to AP 2002 (also referred to as truncating the first duration). In example 2000, AP 2004 may transmit frame 2034 indicating that AP 2004 returns the first duration to AP 2002 (or indicating that AP 2004 truncates the first duration). In the example, frame 2034 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 2004. In the example, the CF-end frame may be a broadcast frame.

[0233] In Example 2000, upon receiving CF-end frame 2034, AP 2002 can reset its basic NAV to zero before the end of the third duration. AP 2002 can also determine that AP 2004 has returned the first duration to AP 2002. With the first duration returned to AP 2002, AP 2002 (which is the owner of the TXOP) reverts to being the holder of the TXOP. Outside the communication range of AP 2004, STA 2006 may not receive CF-end frame 2034 and may not reset its basic NAV, which was set upon receiving data frame 2028 transmitted by STA 2008. Upon receiving CF-end frame 2034, STA 2008 can reset its intra-BSV before the end of the third duration.

[0234] Because AP 2002 has the return duration of TXOP 2010, AP 2002 may want to initiate uplink and / or downlink transmissions during the remaining duration of TXOP 2010. If AP 2002 is to initiate an uplink transmission, AP 2002 may assess that its associated STAs that have not yet reset their basic NAV during the remaining duration of TXOP 2010 (e.g., due to not receiving CF-end frame 2034 transmitted by AP 2004) may not respond to the trigger frame from AP 2002. AP 2002 may also assess that these associated STAs may have already set their basic NAV based on a frame received from an associated STA of AP 2004. This frame will have already been triggered by the trigger frame from AP 2004. Thus, in an embodiment, after AP 2002 receives the trigger frame from AP 2004 and then AP 2004 transmits the CF-end frame, AP 2002 may transmit a frame to its associated STAs to reset their basic NAV.

[0235] In Example 2000, after receiving CF-end frame 2034, AP 2002 may transmit frame 2036 to STA 2006 for resetting STA 2006's basic NAV. In an embodiment, frame 2036 may include a CF-end frame. In an embodiment, the CF-end frame may include a transmitter address (TA) indicating the identifier of AP 2004 instead of the identifier of AP 2002. Thus, when STA 2006 receives frame 2036, STA 2006 can determine that frame 2036 is an inter-BSS PPDU. Therefore, STA 2006 can use frame 2036 to reset its basic NAV. In another embodiment, frame 2036 may include a trigger frame, a Multi-User Request to Send Triggered TXOP Share (MU-RTS TXS) Triggered (MRTT) frame, or a Request to Send (RTS) frame. In an embodiment, the trigger frame, MRTT frame, or RTS frame may include a basic NAV reset indication. Even if the trigger frame, MRTT frame, or RTS frame is an in-BSS PPDU, the presence of a basic NAV reset indicator in the frame allows the STA to reset its basic NAV. In embodiments, the basic NAV reset indicator may be provided in one of the reserved bits (e.g., B22, B26, B53, or B63) of the common information field of the trigger frame or MRTT frame, as shown in... Figure 5 and Figure 15 As illustrated in the diagram. In another embodiment, the basic NAV reset indication can be provided in the frame control field of the RTS frame.

[0236] like Figure 20As shown, upon receiving frame 2036, STA 2006 can reset its basic NAV before the end of the third duration (t3). After transmitting frame 2036, in this embodiment, AP 2002 can transmit frame 2038 to STA 2006 to initiate an uplink transmission. In this example, frame 2038 can be a trigger frame. Upon receiving frame 2038, OBSS AP or OBSS STA can set its basic NAV. Thus, AP 2004 can set its basic NAV (e.g., ...) Figure 20 The NAV (shown in frame 2040) is set to the duration indicated in frame 2038. Similarly, STA 2008 can set its base NAV (as shown in frame 2038) to the duration indicated in frame 2038. Figure 20 The duration (as shown in NAV 2042 in the image) is set to the duration indicated in frame 2038.

[0237] Upon receiving frame 2038 and seeing its own address in the RA field of frame 2038, STA 2006 can determine that it will transmit an uplink frame to AP 2002. STA 2006 can then set its BSS NAV (such as...) Figure 20 The I-BSS NAV (shown in 2044) is set to the duration indicated in frame 2038. In another embodiment, STA 2006 may not set its in-BSS NAV. In response to frame 2038, STA 2006 may transmit frame 2046 to AP 2002. In the example, frame 2046 may be a data frame. In an implementation, frame 2046 may include a duration field indicating the remaining portion of frame 2038 as indicated by the duration. In the example, after receiving frame 2046, AP 2002 may continue uplink and / or downlink transmission within TXOP 2010. In another example, AP 2002 may share the remaining portion of TXOP 2010 with another shared AP. As shown in Example 2000, in cases where the shared AP has returned the TXOP to the sharing AP before the shared TXOP ends, a STA outside the communication range of the shared AP has successfully reset its basic NAV using the proposed method for successful uplink transmission with its associated shared AP.

[0238] Figure 21 Another example 2100 of the CTDMA process according to an embodiment is illustrated. For example... Figure 21As shown, Example 2100 may include APs 2102 and 2104, and STAs 2106 and 2108. APs 2102 and 2104 may be members of a multi-AP group. AP 2102 may be a shared / master AP in the multi-AP group. AP 2104 may be a shared / slave AP in the multi-AP group. STA 2106 may be associated with AP 2102, and STA 2108 may be associated with AP 2104. In Example 2100, it is assumed that APs 2102, 2104, and STA 2108 are within each other's communication range. It is further assumed that STA 2106 is outside the communication range of AP 2104, but within the communication range of AP 2102 and STA 2108.

[0239] like Figure 21 As shown, the process can begin with AP 2102 transmitting MRTT frame 2112 after acquiring TXOP 2110. In an embodiment, MRTT frame 2112 may include an allocation for AP 2104. The allocation of MRTT frame 2112 may include the identifier of the shared AP and the duration allocated to the shared AP (within the TXOP). In example 2100, MRTT frame 2112 may include an allocation for AP 2104. This allocation may include a first duration of the TXOP allocated to AP 2104 (within the TXOP). Figure 21 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field of MRTT frame 2112. In an embodiment, the duration field of MRTT frame 2112 can indicate a second duration (in...). Figure 21 (represented as t2). The second duration indicated in the duration field of MRTT frame 2112 may be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of MRTT frame 2112 to the second duration allows AP 2102 to protect the CTS frames and / or trigger frames of the shared AP.

[0240] In Example 2100, upon receiving MRTT frame 2112, STA 2106 can set its BSS-internal NAV (such as...) Figure 21 The I-BSS NAV 2114 shown in the image is set to the second duration t2 indicated in the MRTT frame 2112. Upon receiving the MRTT frame 2112, the STA 2108 can set its basic NAV (as shown in the image) to the second duration t2 indicated in the MRTT frame 2112. Figure 21(As shown in NAV 2116) is set to the second duration t2. Upon receiving MRTT frame 2112, AP 2104 can determine that AP 2102 has shared TXOP 2110 with AP 2104 for duration t1. AP 2104 can then transmit CTS frame 2118 to AP 2102 in response to MRTT frame 2112.

[0241] When receiving CTS frame 2118, AP 2102 can set its BSS intra-NAV (e.g., ...) within the remaining duration t2. Figure 21 (As shown in I-BSS NAV 2120). After transmitting CTS frame 2118, AP 2104 can use TXOP for the remaining duration of t1. In the example, AP 2104 can send a TXOP to STA 2108 ( Figure 21 (Not shown in the image) transmits downlink frames. In another example, AP 2104 can trigger STA 2108 to transmit uplink frames to AP 2104.

[0242] In Example 2100, after transmitting CTS frame 2118, AP 2104 can transmit trigger frame 2122 to STA 2108 to trigger uplink transmission from STA 2108. In an embodiment, the duration field of trigger frame 2122 can indicate a third duration t3. Upon receiving trigger frame 2122, OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 2122. Specifically, in Example 2100, upon receiving trigger frame 2122, AP 2102 can set its basic NAV (e.g., ...) Figure 21 The NAV (shown in NAV 2124) is set to the third duration indicated in the trigger frame 2122. However, outside the communication range of AP 2104, STA 2106 may not receive trigger frame 2122 and may not set its basic NAV.

[0243] In an embodiment, upon receiving trigger frame 2122 and seeing its own address in the RA field of trigger frame 2122, STA 2108 can determine that it wants to transmit an uplink frame to AP 2104. In an embodiment, when trigger frame 2122 is transmitted by AP 2104 associated with STA 2108, STA 2108 can set its BSS NAV (such as...) Figure 21The I-BSSNAV 2126 shown in the diagram is set to the third duration indicated in the trigger frame 2122. In another embodiment, STA 2108 may not set its in-BSS NAV. Subsequently, STA 2108 may transmit data frame 2128 to AP 2104. Data frame 2128 may include a duration field indicating the remaining duration of the third duration. Upon receiving data frame 2128, STA 2106 may read the duration field of data frame 2128 and may set its basic NAV (e.g., I-BSSNAV 2126) for the remaining duration of the third duration. Figure 21 (As shown in NAV 2130). In response to data frame 2128, AP 2104 can transmit BA frame 2132 to STA 2108.

[0244] In the example, after transmitting BA frame 2132 to STA 2108, AP 2104 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 2104. In an implementation, AP 2104 may return the remainder of the first duration to AP 2102 (also referred to as truncating the first duration). In example 2100, AP 2104 may transmit frame 2134 indicating that AP 2104 returns the first duration to AP 2102 (or indicating that AP 2104 truncates the first duration). In the example, frame 2134 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 2104. In the example, the CF-end frame may be a broadcast frame.

[0245] In Example 2100, upon receiving CF-end frame 2134, AP 2102 may reset its basic NAV to zero before the end of the third duration. AP 2102 may also determine that AP 2104 has returned the first duration to AP 2102. With the return of the first duration to AP 2102, AP 2102 (which is the owner of the TXOP) reverts to being the holder of the TXOP. Outside the communication range of AP 2104, STA 2106 may not receive CF-end frame 2134 and may not reset its basic NAV, which was set upon receiving data frame 2128 transmitted by STA 2108. Upon receiving CF-end frame 2134, STA 2108 may reset its intra-BSV before the end of the third duration.

[0246] Because AP 2102 has the return duration of TXOP, AP 2102 may want to initiate uplink and / or downlink transmissions during the remaining duration of TXOP 2110. If AP 2102 is to initiate an uplink transmission, AP 2102 may assess that its associated STAs that have not yet reset their basic NAV during the remaining duration of TXOP 2110 (e.g., due to not receiving CF-end frame 2134 transmitted by AP 2104) may not respond to the trigger frame from AP 2102. AP 2102 may also assess that these associated STAs may have already set their basic NAV based on a frame received from an associated STA of AP 2104. This frame will have already been triggered by the trigger frame from AP 2104. Thus, in an embodiment, after AP 2102 receives the trigger frame from AP 2104 and then AP 2104 transmits the CF-end frame, AP 2102 may transmit a frame to its associated STAs to reset their basic NAV.

[0247] In Example 2100, after receiving CF-end frame 2134, AP 2102 can transmit frame 2136 to STA 2106 to reset STA 2106's basic NAV and to trigger uplink transmission. In this example, frame 2136 may be an aggregation of two frames. In an embodiment, the first frame of frame 2136 may include a CF-end frame. In an embodiment, the CF-end frame may include a transmitter address (TA) indicating the identifier of AP 2104 instead of the identifier of AP 2102. Thus, when STA 2106 receives frame 2136, STA 2106 can determine that the first frame of frame 2136 is an inter-BSS PPDU. Therefore, STA 2106 can use the first frame of frame 2136 to reset its basic NAV. In an embodiment, the second frame of frame 2136 may include a trigger frame, an MRTT frame, or an RTS frame. Thus, the transmission of the trigger frame, MRTT frame, or RTS frame can initiate uplink transmission from STA 2106.

[0248] In another embodiment, frame 2136 may include a trigger frame, an MRTT frame, or an RTS frame. In this embodiment, the trigger frame, MRTT frame, or RTS frame may include a basic NAV reset indication. Even if the trigger frame, MRTT frame, or RTS frame is an in-BSS PPDU, the presence of the basic NAV reset indication in the frame allows the STA to reset its basic NAV. In this embodiment, the basic NAV reset indication may be provided in one of the reserved bits (e.g., B22, B26, B53, or B63) of the common information field of the trigger frame or MRTT frame, as shown in... Figure 5 and Figure 15As illustrated in the diagram. In another embodiment, the basic NAV reset indication can be provided in the frame control field of the RTS frame. In addition to the basic NAV reset indication, frame 2136 can be used to initiate uplink transmissions.

[0249] like Figure 21 As shown, upon receiving frame 2136, STA 2106 can reset its basic NAV before the end of duration t3. Upon receiving frame 2136, the OBSS AP or OBSS STA can set its basic NAV. Thus, AP 2104 can set its basic NAV (e.g., ... Figure 21 The NAV (as shown in frame 2138) is set to the duration indicated in frame 2136. Similarly, STA 2108 can set its base NAV (as shown in frame 2138) to the duration indicated in frame 2136. Figure 21 The duration (as shown in NAV 2140 in the frame) is set to the duration indicated in frame 2136.

[0250] Upon receiving frame 2136 and seeing its own address in the RA field of frame 2136, STA 2106 can determine that it will transmit an uplink frame to AP 2102. STA 2106 can then set its NAV (such as...) within its BSS. Figure 21 The I-BSS NAV (shown in frame 2142) is set to the duration indicated in frame 2136. In another embodiment, STA 2106 may not set its in-BSS NAV. In response to frame 2136, STA 2106 may transmit frame 2144 to AP 2102. In the example, frame 2144 may be a data frame. In one implementation, frame 2144 may include a duration field indicating the remaining portion of frame 2136 indicated by the duration. In the example, after receiving frame 2144, AP 2102 may continue uplink and / or downlink transmission within TXOP 2110. In another example, AP 2102 may share the remaining portion of TXOP 2110 with another shared AP. As shown in example 2100, in cases where the shared AP has returned the TXOP to the sharing AP before the shared TXOP ends, a STA outside the communication range of the shared AP has successfully reset its basic NAV using the proposed method for successful uplink transmission with its associated shared AP.

[0251] Figure 22 Another example 2200 of the CTDMA process according to an embodiment is illustrated. For example... Figure 22As shown, Example 2200 may include APs 2202 and 2204, and STAs 2206 and 2208. APs 2202 and 2204 may be members of a multi-AP group. AP 2202 may be the shared / master AP of the multi-AP group. AP 2204 may be the shared / slave AP of the multi-AP group. STA 2206 may be associated with AP 2202, and STA 2208 may be associated with AP 2204. In Example 2200, it is assumed that APs 2202, 2204, and STA 2208 are within each other's communication range. It is further assumed that STA 2206 is outside the communication range of AP 2204, but within the communication range of AP 2202 and STA 2208.

[0252] like Figure 22 As shown, the process can begin with AP 2202 transmitting MRTT frame 2212 after acquiring TXOP 2210. In an embodiment, MRTT frame 2212 may include an allocation for AP 2204. The allocation of MRTT frame 2212 may include the identifier of the shared AP and the duration allocated to the shared AP (within the TXOP). In example 2200, MRTT frame 2212 may include an allocation for AP 2204. This allocation may include a first duration of the TXOP allocated to AP 2204 (within the TXOP). Figure 22 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field of MRTT frame 2212. In an embodiment, the duration field of MRTT frame 2212 can indicate a second duration (in...). Figure 22 (represented as t2). The second duration indicated in the duration field of MRTT frame 2212 may be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of MRTT frame 2212 to the second duration allows AP 2202 to protect the CTS frames and / or trigger frames of the shared AP.

[0253] It is worth noting that, in the case of C-TDMA, an AP (sharing AP) can allocate a portion of the TXOP to another AP (the shared AP). Upon hearing communication from the shared AP, the sharing AP and its associated STAs set their basic NAV to protect the shared AP's communication. If the shared AP and its associated STAs complete their communication before the TXOP allocation sharing ends, the shared AP can return (i.e., release) the remaining portion of the TXOP to the sharing AP. The inventors have recognized that a STA associated with the sharing AP may not be able to hear the shared AP, but may be able to hear its associated STA—which could be an OBSS STA targeting the sharing AP's BSS. Hearing a frame listening from that STA associated with the shared AP will cause a STA not associated with the shared AP to set its NAV. Unfortunately, the NAV will remain set, even though the shared AP sends a frame releasing the NAV because that frame has not yet been heard. It may then be unable to respond to frames from its associated AP.

[0254] In Example 2200, MRTT frame 2212 may further include an indication of whether a STA is permitted to ignore its basic NAV during a first duration allocated by AP 2202 to AP 2204. In an embodiment, if the basic NAV is set during the first duration, the STA may be permitted to ignore its basic NAV during the first duration allocated by AP 2202 to AP 2204. In an embodiment, the indication permitting the STA to ignore its basic NAV may be provided in one of the reserved bits (e.g., B22, B26, B53, or B63) of the common information field of MRTT frame 2212, such as... Figure 15 As illustrated in the figure. In an embodiment, based on this indication, when responding to a frame from AP 2202, the STA associated with AP 2202 is permitted to ignore its basic NAV for a first duration. In an embodiment, the frame from AP 2202 may include a trigger frame, an MRTT frame, or an RTS frame. Thus, after receiving an indication that the STA is permitted to ignore its basic NAV for a first duration, the STA associated with AP 2202 that receives a trigger frame, an MRTT frame, or an RTS frame from AP 2202 can respond to any of those frames (e.g., it can transmit an uplink frame to AP 2202), even if its basic NAV is nonzero when the frame is received. In example 2200, STA 2206 may receive an MRTT frame 2212, which includes an indication of whether the STA is permitted to ignore its basic NAV for a first duration (e.g., when the frame is received by AP 2202) during the first duration allocated by AP 2202 to AP 2204. Figure 22 The indication of its basic NAV is ignored during the t1 period shown.

[0255] In another example, MRTT frame 2212 may include an indication of whether a STA is permitted not to update its basic NAV during a first duration allocated by AP 2202 to AP 2204. In one embodiment, the indication of permitted STA not to update its basic NAV may be provided in one of the reserved bits (e.g., B22, B26, B53, or B63) of the public information field of MRTT frame 2212, such as... Figure 15 As shown. In an embodiment, based on this instruction, a STA associated with AP 2202 is permitted not to update its basic NAV during a first duration. For example, a STA may hear an OBSS STA or OBSS AP during the first duration and may not update its basic NAV. Thus, if the STA's basic NAV is zero, the STA may respond to a frame from AP 2202 (e.g., frame 2230). In an embodiment, frame 2230 from AP 2202 may include a trigger frame, an MRTT frame, or an RTS frame. Thus, a STA associated with AP 2202 that receives frame 2230 from AP 2202 may not update its basic NAV during the first duration allocated to AP 2204 by AP 2202, and therefore, if its basic NAV is zero when it receives frame 2230 (e.g., due to not updating its basic NAV), it may respond to frame 2230 (e.g., an uplink frame may be transmitted to AP 2202). In example 2200, STA 2206 can receive MRTT frame 2212, which includes whether the STA is permitted during a first duration (e.g., allocated by AP 2202 to AP 2204) Figure 22 The indication shown is that the underlying NAV is not updated during the t1 period.

[0256] Allowing a STA associated with a shared AP to ignore or not update its NAV (after hearing a transmission from a STA associated with another (i.e., the shared) AP) permits it to respond to frames from its own AP (i.e., the sharing AP). This avoids the undesirable result of the STA being unnecessarily blocked from transmitting.

[0258] In Example 2200, upon receiving MRTT frame 2212, STA 2206 can set its BSS-internal NAV (such as...) Figure 22 The I-BSS NAV 2214 shown in the image is set to the second duration t2 indicated in the MRTT frame 2212. Upon receiving the MRTT frame 2212, the STA 2208 can set its basic NAV (as shown in the image) to the second duration t2 indicated in the MRTT frame 2212. Figure 22(As shown in NAV 2216) is set to the second duration t2. Upon receiving MRTT frame 2212, AP 2204 can determine that AP 2202 has shared TXOP 2210 with AP 2204 for duration t1. AP 2204 can then transmit CTS frame 2218 to AP 2202 in response to MRTT frame 2212.

[0259] When receiving CTS frame 2218, AP 2202 can set its BSS intra-NAV (e.g., ...) within the remaining duration t2. Figure 22 (As shown in I-BSS NAV 2220). After transmitting CTS frame 2218, AP 2204 can use TXOP for the remaining duration of t1. In the example, AP 2204 can send a TXOP to STA 2208 ( Figure 22 (Not shown in the image) transmits downlink frames. In another example, AP 2204 can trigger STA 2208 to transmit uplink frames to AP 2204.

[0260] In Example 2200, after transmitting CTS frame 2218, AP 2204 can transmit trigger frame 2222 to STA 2208 to trigger uplink transmission from STA 2208. In an embodiment, the duration field of trigger frame 2222 can indicate a third duration t3. Upon receiving trigger frame 2222, OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 2222. Specifically, in Example 2200, upon receiving trigger frame 2222, AP 2202 can set its basic NAV (e.g., ...) Figure 22 The NAV (shown in NAV 2224) is set to the third duration indicated in trigger frame 2222. However, outside the communication range of AP 2204, STA 2206 may not receive trigger frame 2222 and may not set its basic NAV.

[0261] In an embodiment, upon receiving trigger frame 2222 and seeing its own address in the RA field of trigger frame 2222, STA 2208 can determine that it wants to transmit an uplink frame to AP 2204. In an embodiment, when trigger frame 2222 is transmitted by AP 2204 associated with STA 2208, STA 2208 can set its BSS NAV (such as...) Figure 22The I-BSSNAV 2226 shown in the example is set to the third duration indicated in trigger frame 2222. In another embodiment, STA 2208 may not set its in-BSS NAV. Subsequently, STA 2208 may transmit data frame 2228 to AP 2204. Data frame 2228 may include a duration field indicating the remaining duration of the third duration. Upon receiving data frame 2228, STA 2206 may read the duration field of data frame 2228 and may set its basic NAV (e.g., I-BSSNAV 2226) for the remaining duration of the third duration. Figure 22 (As shown in NAV 2230). In response to data frame 2228, AP 2204 may transmit BA frame 2232 to STA 2208. In another embodiment, based on an indication that STA 2206 is permitted not to update its basic NAV, STA 2206 may not update its basic NAV (as shown in NAV 2230). Figure 23 (Not shown in the image).

[0262] In the example, after transmitting BA frame 2232 to STA 2208, AP 2204 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 2204. In an implementation, AP 2204 may return the remainder of the first duration to AP 2202 (also referred to as truncating the first duration). In example 2200, AP 2204 may transmit frame 2234 indicating that AP 2204 returns the first duration to AP 2202 (or indicating that AP 2204 truncates the first duration). In the example, frame 2234 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 2204. In the example, the CF-end frame may be a broadcast frame.

[0263] In Example 2200, upon receiving CF-end frame 2234, AP 2202 may reset its basic NAV to zero before the end of the third duration. AP 2202 may also determine that AP 2204 has returned the first duration to AP 2202. With the return of the first duration to AP 2202, AP 2202 (which is the owner of the TXOP) reverts to being the holder of the TXOP. Outside the communication range of AP 2204, STA 2206 may not receive CF-end frame 2234 and may not reset its basic NAV, which was set after receiving data frame 2228 transmitted by STA 2208 (e.g., if it had already been set). Upon receiving CF-end frame 2234, STA 2208 may reset its intra-BSV before the end of the third duration.

[0264] Since AP 2202 has the return duration of TXOP, AP 2202 may want to initiate uplink and / or downlink transmissions for the remaining duration of TXOP 2210. In one embodiment, AP 2202 may want to initiate an uplink transmission. Based on the indication transmitted in MRTT frame 2212 that allows an associated STA of AP 2202 to ignore its basic NAV during the first duration in response to a frame from AP 2202, AP 2202 may transmit a frame that triggers an uplink transmission from one of its associated STAs to AP 2202. In another embodiment, if the indication transmitted in MRTT frame 2212 indicates that an associated STA of AP 2202 is allowed not to update its basic NAV during the first duration, then based on this indication, AP 2202 may transmit a frame that triggers an uplink transmission from one of its associated STAs to AP 2202, and a response can be expected if the STA's NAV is zero. In the example, AP 2202 can transmit frame 2230 to STA 2206 to trigger an uplink transmission. In an embodiment, frame 2230 may include a trigger frame, an MRTT frame, or an RTS frame.

[0265] like Figure 22 As shown, when receiving frame 2230, the OBSS AP or OBSS STA can set its basic NAV. Thus, AP2204 can set its basic NAV (such as...) Figure 22 The NAV (shown in frame 2238) is set to the duration indicated in frame 2230. Similarly, STA 2208 can set its base NAV (as shown in frame 2238) to the duration indicated in frame 2230. Figure 22 The duration (as shown in NAV 2240 in the image) is set to the duration indicated in frame 2230.

[0266] In an embodiment, STA 2206 may not reset its basic NAV for the remaining duration of TXOP 2210 due to not receiving CF-end frame 2234 transmitted by AP 2204. Upon receiving frame 2230 and seeing its own address in the RA field of frame 2230, STA 2206 can determine that it will transmit an uplink frame to AP 2202. STA 2206 can then reset its BSS-in-NAV (e.g., ...). Figure 22The I-BSS NAV (shown in frame 2242) is set to the duration indicated in frame 2230. In another embodiment, STA 2206 may not set its in-BSS NAV. In response to frame 2230, based on the indication transmitted in MRTT frame 2212 that allows the associated STA of AP 2202 to ignore the basic NAV during the first duration, STA 2206 may transmit frame 2244 to AP 2202 even if its basic NAV is non-zero when transmitting frame 2244. In another embodiment, in response to frame 2230, based on the indication transmitted in MRTT frame 2212 that allows the associated STA of AP 2202 to not update the basic NAV during the first duration, STA 2206 may transmit frame 2244 to AP 2202 if its basic NAV is zero when transmitting frame 2244 (e.g., the basic NAV was not updated during the first duration). In the example, frame 2244 may be a data frame. In one implementation, frame 2244 may include a duration field indicating the remaining portion of frame 2230, which indicates the duration. In one example, after receiving frame 2244, AP 2202 may continue uplink and / or downlink transmissions within TXOP 2210. In another example, AP 2202 may share the remaining portion of TXOP 2210 with another shared AP.

[0267] Figure 23 Another example 2300 of the CTDMA process according to an embodiment is illustrated. Figure 23 As shown, Example 2300 may include APs 2302 and 2304, and STAs 2306 and 2308. APs 2302 and 2304 may be members of a multi-AP group. AP 2302 may be a shared / master AP in the multi-AP group. AP 2304 may be a shared / slave AP in the multi-AP group. STA 2306 may be associated with AP 2302, and STA 2308 may be associated with AP 2304. In Example 2300, it is assumed that APs 2302, 2304, and STA 2308 are within each other's communication range. It is further assumed that STA 2306 is outside the communication range of AP 2304, but within the communication range of APs 2302 and STA 2308.

[0268] like Figure 23As shown, the process can begin with AP 2302 transmitting frame 2311 after obtaining TXOP 2310. In an embodiment, frame 2311 may include a beacon frame or a management frame. In an embodiment, frame 2311 may include an indication of whether a STA associated with AP 2302 is permitted to ignore its basic NAV during a first duration allocated by AP 2302 to AP 2304. In an embodiment, if the basic NAV is set during the first duration, the STA may be permitted to ignore its basic NAV during the first duration allocated by AP 2302 to AP 2304. In an embodiment, an indication to permit a STA to ignore its basic NAV is provided in a beacon frame or a management frame. Using this indication, in response to a frame from AP 2302, the STA associated with AP 2302 is permitted to ignore its basic NAV during the first duration. In an embodiment, the frame from AP 2302 may include a trigger frame, an MRTT frame, or an RTS frame. Thus, after receiving an indication that the STA is allowed to ignore its basic NAV during the first duration, the STA associated with AP 2302 that receives a trigger frame, MRTT frame, or RTS frame from AP 2302 can respond to any of those frames (e.g., it can transmit an uplink frame to AP 2202), even if its basic NAV is not zero.

[0269] In another example, frame 2311 may include an indication of whether a STA associated with AP 2302 is permitted not to update its basic NAV during a first duration assigned to AP 2304 by AP 2302. In an embodiment, the indication permitting the STA not to update its basic NAV may be provided in a beacon frame or management frame (e.g., probe response frame, associated response frame, or other individual management / action frame). In an embodiment, based on this indication, the STA associated with AP 2302 is permitted not to update its basic NAV during the first duration. For example, the STA may hear an OBSS STA or OBSS AP during the first duration and may not update its basic NAV. Thus, if the STA's basic NAV is zero, the STA may respond to a frame from AP 2302 (e.g., frame 2336). In an embodiment, frame 2336 from AP 2302 may include a trigger frame, an MRTT frame, or an RTS frame. Thus, the STA associated with AP 2302 that receives frame 2336 from AP 2302 may not update its basic NAV during the first duration allocated to AP 2304 by AP 2302, and therefore, if its basic NAV is zero when receiving frame 2336 (e.g., due to not updating its basic NAV), it can respond to frame 2336 (e.g., it can transmit an uplink frame to AP 2302).

[0270] In Example 2300, after transmitting frame 2311, AP 2302 may transmit MRTT frame 2312. In an embodiment, MRTT frame 2312 may include an allocation for AP 2304. The allocation of MRTT frame 2312 may include an identifier of the shared AP and a duration (within a TXOP) allocated to the shared AP. In Example 2300, MRTT frame 2312 may include an allocation for AP 2304. This allocation may include a first duration (within a TXOP) of the TXOP allocated to AP 2304. Figure 23 (represented as t1). The first duration can be indicated in the allocation duration subfield of the user information list field of MRTT frame 2312. In an embodiment, the duration field of MRTT frame 2312 can indicate a second duration (in...). Figure 23 (represented as t2). The second duration indicated in the duration field of MRTT frame 2312 can be shorter than the first duration. This is to avoid causing the associated STA of the shared AP, which is the OBSS STA of the shared AP, to set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would result in the associated STA not responding to trigger frames from its associated shared AP, which has TXOP during the first duration. In the implementation, setting the duration field of MRTT frame 2312 to the second duration allows AP 2302 to protect the CTS frames and / or trigger frames of the shared AP.

[0271] In Example 2300, upon receiving MRTT frame 2312, STA 2306 can set its BSS-internal NAV (such as...) Figure 22 The I-BSS NAV (as shown in 2314) is set to the second duration t2 indicated in the MRTT frame 2312. Upon receiving the MRTT frame 2312, the STA 2308 can set its basic NAV (as shown in 2314) to the second duration t2 indicated in the MRTT frame 2312. Figure 23 (As shown in NAV 2316) is set to the second duration t2. Upon receiving MRTT frame 2312, AP 2304 can determine that AP 2302 has shared TXOP 2310 with AP 2304 for duration t1. AP 2304 can then transmit CTS frame 2318 to AP 2202 in response to MRTT frame 2312.

[0272] When receiving CTS frame 2318, AP 2302 can set its BSS-in-NAV (e.g., ...) within the remaining duration t2. Figure 22(As shown in I-BSS NAV 2320). After transmitting CTS frame 2318, AP 2304 can use TXOP for the remaining duration of t1. In the example, AP 2304 can send a TXOP to STA 2308 ( Figure 23 (Not shown in the image) transmits downlink frames. In another example, AP 2304 can trigger STA 2308 to transmit uplink frames to AP 2304.

[0273] In Example 2300, after transmitting CTS frame 2318, AP 2304 can transmit trigger frame 2322 to STA 2308 to trigger uplink transmission from STA 2308. In an embodiment, the duration field of trigger frame 2322 can indicate a third duration t3. Upon receiving trigger frame 2322, OBSS AP or OBSS STA can set its basic NAV based on the duration field of trigger frame 2322. Specifically, in Example 2300, upon receiving trigger frame 2322, AP 2302 can set its basic NAV (e.g., ...) Figure 23 The NAV (shown in NAV 2324) is set to the third duration indicated in trigger frame 2322. However, outside the communication range of AP 2304, STA 2306 may not receive trigger frame 2322 and may not set its basic NAV.

[0274] In an embodiment, upon receiving trigger frame 2322 and seeing its own address in the RA field of trigger frame 2322, STA 2308 can determine that it wants to transmit an uplink frame to AP 2304. In an embodiment, when trigger frame 2322 is transmitted by AP 2304 associated with STA 2308, STA 2308 can set its BSS NAV (such as...) Figure 23 The I-BSSNAV (shown in Figure 2326) is set to the third duration indicated in trigger frame 2322. In another embodiment, STA 2308 may not set its in-BSS NAV. Subsequently, STA 2308 may transmit data frame 2328 to AP 2304. Data frame 2328 may include a duration field indicating the remaining duration of the third duration. Upon receiving data frame 2328, STA 2306 may read the duration field of data frame 2328 and may set its basic NAV (e.g., I-BSSNAV 2326) for the remaining duration of the third duration. Figure 23 (As shown in NAV 2330). In response to data frame 2328, AP 2304 may transmit BA frame 2332 to STA 2308. In another embodiment, based on an indication that STA 2306 is permitted not to update its basic NAV, STA 2306 may not update its basic NAV (as shown in NAV 2330). Figure 23 (Not shown in the image).

[0275] In the example, after transmitting BA frame 2332 to STA 2308, AP 2304 may not have any further uplink and / or downlink transmissions to perform during the remainder of the first duration allocated to AP 2304. In an implementation, AP 2304 may return the remainder of the first duration to AP 2302 (also referred to as truncating the first duration). In example 2300, AP 2304 may transmit frame 2334 indicating that AP 2304 returns the first duration to AP 2302 (or indicating that AP 2304 truncates the first duration). In the example, frame 2334 may be a contention-free end (CF-end) frame. In the example, the CF-end frame may include an indication of the transmitter address (TA) of AP 2304. In the example, the CF-end frame may be a broadcast frame.

[0276] In Example 2300, upon receiving the CF-end frame 2334, AP 2302 may reset its basic NAV to zero before the end of the third duration. AP 2302 may also determine that AP 2304 has returned the first duration to AP 2302. With the return of the first duration to AP 2302, AP 2302 (which is the owner of the TXOP) reverts to being the holder of the TXOP. Outside the communication range of AP 2304, STA 2306 may not receive the CF-end frame 2334 and may not reset its basic NAV, which was set after receiving the data frame 2328 transmitted by STA 2308 (e.g., if it had already been set). Upon receiving the CF-end frame 2334, STA 2308 may reset its intra-BSV before the end of the third duration.

[0277] Because AP 2302 has the return duration of TXOP, AP 2302 may want to initiate uplink and / or downlink transmissions for the remaining duration of TXOP 2310. In one embodiment, AP 2302 may want to initiate an uplink transmission. Based on the indication transmitted in frame 2311 that allows an associated STA of AP 2302 to ignore the basic NAV during the first duration in response to a frame from AP 2302, AP 2302 may transmit a frame that triggers an uplink transmission from one of its associated STAs to AP 2302. In another embodiment, if the indication transmitted in frame 2311 indicates that an associated STA of AP 2302 is allowed not to update its basic NAV during the first duration, then based on that indication, AP 2302 may transmit a frame that triggers an uplink transmission from one of its associated STAs to AP 2302, and if the STA's NAV is zero, then a response is expected. In the example, AP 2302 can transmit frame 2336 to STA 2306 to trigger an uplink transmission. In an embodiment, frame 2336 may include a trigger frame, an MRTT frame, or an RTS frame.

[0278] like Figure 23 As shown, when receiving frame 2336, the OBSS AP or OBSS STA can set its basic NAV. Thus, AP2304 can set its basic NAV (such as...) Figure 23 The NAV (as shown in frame 2338) is set to the duration indicated in frame 2336. Similarly, STA 2308 can set its basic NAV (as shown in frame 2338) to the duration indicated in frame 2336. Figure 23 The duration (as shown in NAV 2340 in the image) is set to the duration indicated in frame 2336.

[0279] In an embodiment, STA 2306 may not reset its basic NAV for the remaining duration of TXOP 2310 due to not receiving CF-end frame 2334 transmitted by AP 2304. Upon receiving frame 2336 and seeing its own address in the RA field of frame 2336, STA 2306 can determine that it will transmit an uplink frame to AP 2302. STA 2306 can then reset its NAV within its BSS (e.g., ...). Figure 23The I-BSS NAV (shown in frame 2342) is set to the duration indicated in frame 2336. In another embodiment, STA 2306 may not set its in-BSS NAV. In response to frame 2336, based on the indication transmitted in frame 2311 that allows the associated STA of AP 2302 to ignore the basic NAV during the first duration, STA 2306 may transmit frame 2344 to AP 2302 even if its basic NAV is non-zero when transmitting frame 2344. In another embodiment, in response to frame 2336, based on the indication transmitted in frame 2311 that allows the associated STA of AP 2302 to not update the basic NAV during the first duration, STA 2306 may transmit frame 2344 to AP 2302 if its basic NAV is zero when transmitting frame 2344 (e.g., the basic NAV was not updated during the first duration). In the example, frame 2344 may be a data frame. In one implementation, frame 2344 may include a duration field indicating the remaining portion of frame 2336, which indicates the duration. In one example, after receiving frame 2344, AP 2302 may continue uplink and / or downlink transmissions within TXOP 2310. In another example, AP 2302 may share the remaining portion of TXOP 2310 with another shared AP.

[0280] Figure 24 An example operation element 2400 that can be used in an embodiment is illustrated. The example operation element 2400 can be carried in a frame such as frame 2311 described above. Figure 24 As shown, operation element 2400 can have the format of an EHT operation element and can include an element ID field, a length field, an element ID extension field, an EHT operation parameter field, basic EHT-MCS and NSS setting fields, and an EHT operation information field.

[0281] like Figure 24 As shown, the EHT operation parameter field may include the EHT operation information presence subfield, the disabled subchannel bitmap presence subfield, the EHT default PE duration subfield, the group addressing BU indication limit subfield, the group addressing BU indication index subfield, and reserved bits.

[0282] In one embodiment, the EHT operation parameter field may carry an indication of whether a STA associated with an AP is permitted to ignore its basic NAV during a first duration allocated by the AP to another AP. In one embodiment, the indication may be provided in one of the reserved bits. In another embodiment, the indication may be provided in one of the other subfields.

[0283] Figure 25An example process 2500 according to an embodiment is illustrated. The example process 2500 is provided for illustrative purposes only and is not intended to be limiting. The example process 2500 may be performed by a first AP (such as, for example, AP 2002 or AP 2102).

[0284] like Figure 25 As shown, process 2500 may include: in step 2510, receiving a trigger frame from the second AP by the first AP and during a first duration allocated to the second AP by the first AP.

[0285] Process 2500 may further include: in step 2520, receiving a first frame from the second AP during a first duration by the first AP, the first frame indicating that the second AP will return the first duration to the first AP. In an embodiment, the first frame may include a contention-free end (CF-end) frame. In an embodiment, the CF-end frame may include an indicator of the transmitter address (TA) of the second AP.

[0286] Process 2500 may further include: in step 2530, after receiving the first frame, transmitting a second frame from the first AP to the first STA for resetting the basic NAV of the first STA. In an embodiment, process 2500 may further include the first AP receiving a trigger frame addressed to the second STA from the second AP during a first duration. The second STA may be associated with the second AP. In an embodiment, process 2500 may further include the first AP transmitting a third frame indicating the first duration to the second AP during a transmission opportunity (TXOP) obtained by the first AP, wherein the first duration is within the TXOP. In an embodiment, the third frame may be transmitted before the first and second frames.

[0287] In one embodiment, the second frame may include a CF-end frame. In another embodiment, the CF-end frame may include a transmitter address (TA) indicating the second AP. In yet another embodiment, the second frame may include a trigger frame, a Multi-User Request to Send Triggered TXOP Share (MU-RTS TXS) Triggered (MRTT) frame, or a Request to Send (RTS) frame. In another embodiment, the second frame may include a basic NAV reset indication.

[0288] In one embodiment, process 2500 may further include resetting the basic NAV of the first AP after receiving the first frame. In another embodiment, process 2500 may further include transmitting a fourth frame from the first AP to the first STA after the second frame. In yet another embodiment, the fourth frame may initiate an uplink transmission by the first STA.

[0289] In another embodiment, process 2500 may further include transmitting a fourth frame, aggregated with the second frame, from the first AP to the first STA. In this embodiment, the fourth frame may be configured to trigger an uplink transmission by the first STA.

[0290] In an embodiment, process 2500 may further include the first AP receiving a fifth frame in response to the fourth frame from the first STA.

[0291] Figure 26 Another example process 2600 according to an embodiment is illustrated. Example process 2600 is provided for illustrative purposes only and is not intended to be limiting. Example process 2600 may be performed by a first STA (such as, for example, STA 2006 or STA 2106). The first STA may be associated with a first AP.

[0292] like Figure 26 As shown, process 2600 may include: in step 2610, a first STA receives a first frame from a second STA, indicating a first duration, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic NAV of the first STA. In an embodiment, the first duration may be within a Transfer Opportunity (TXOP) allocated to the second AP. In an embodiment, the second AP may be an OBSS AP.

[0293] Process 2600 may further include: in step 2620, setting the basic NAV of the first STA based on the first frame. In an embodiment, the first frame may be a data frame.

[0294] Process 2600 may further include: in step 2630, receiving a second frame from the first AP for resetting the basic NAV of the first STA during a first duration. In an embodiment, process 2600 may further include resetting the basic NAV of the first STA after receiving the second frame. In an embodiment, the second frame may include a CF-end frame. In an embodiment, the CF-end frame may include an indication of the transmitter address (TA) of the second AP. In another embodiment, the second frame may include a trigger frame, a Multi-User Request to Transmit Triggered TXOP Share (MU-RTS TXS) Triggered (MRTT) frame, or a Request to Transmit (RTS) frame. In an embodiment, the second frame may include a basic NAV reset indication.

[0295] In an embodiment, process 2600 may further include a third frame following the receipt of the second frame by the first STA from the first AP. In an embodiment, the third frame may initiate an uplink transmission by the first STA.

[0296] In another embodiment, process 2600 may further include receiving a third frame aggregated with the second frame from the first AP by the first STA. In this embodiment, the third frame may be configured to trigger an uplink transmission by the STA.

[0297] In an embodiment, process 2600 may further include the first STA transmitting a fourth frame to the first AP in response to the third frame.

[0298] Figure 27 Another example process 2700 according to an embodiment is illustrated. The example process 2700 is provided for illustrative purposes only and is not intended to be limiting. The example process 2700 may be performed by a first AP (such as, for example, AP 2202 or AP 2302).

[0299] like Figure 27 As shown, process 2700 may include: in step 2710, a first frame is transmitted by the first AP, the first frame including an indication of whether the STA is permitted to ignore its basic NAV during a first duration allocated by the first AP to the second AP.

[0300] Process 2700 may further include: in step 2720, receiving a second frame from the second AP during a first duration by the first AP, the second frame indicating that the second AP returns the first duration to the first AP.

[0301] Process 2700 may further include: in step 2730, based on an indication that allows the STA to ignore its basic NAV during the first duration, the first AP transmits a third frame to the STA, which triggers an uplink transmission from the STA to the first AP.

[0302] In an embodiment, a STA may be allowed to ignore its basic NAV for a first duration in response to a third frame from a first AP. In an embodiment, the third frame may include a trigger frame, a Multi-User Request to Send Triggered TXOP Share (MU-RTS TXS) Triggered (MRTT) frame, or a Request to Send (RTS) frame.

[0303] In one embodiment, the first frame may include an MRTT frame. In another embodiment, an indication allowing the STA to ignore its basic NAV may be provided in the common information field of the MRTT frame. In yet another embodiment, the first frame may include a beacon frame or a management frame. In another embodiment, an indication allowing the STA to ignore its basic NAV may be provided in the beacon frame or the management frame.

[0304] In one embodiment, the second frame may include a contention-free end (CF-end) frame. In another embodiment, the CF-end frame may include a transmitter address (TA) indicating the second AP.

[0305] In an embodiment, process 2700 may further include a fourth frame received by the first AP from the first STA in response to the third frame.

[0306] Figure 28 Another example process 2800 according to an embodiment is illustrated. Example process 2800 is provided for illustrative purposes only and is not intended to be limiting. Example process 2800 may be performed by a first STA (such as, for example, STA 2206 or STA 2306). The first STA may be associated with a first AP.

[0307] like Figure 28 As shown, process 2800 may include, in step 2810, a first STA receiving a first frame from a first AP, the first frame including an indication of whether the first STA is permitted to ignore its basic NAV during a first duration allocated by the first AP to a second AP.

[0308] Process 2800 may further include: in step 2820, based on an indication that allows the STA to ignore its basic NAV during the first duration, the first STA transmits a second frame to the first AP during the first duration without considering the basic NAV when transmitting the second frame.

[0309] Process 2800 may further include the first STA receiving a third frame from the second STA, indicating a first duration, for setting the basic NAV of the first STA. In an embodiment, the third frame may be received before the second frame is transmitted. Process 2800 may also include setting the basic NAV of the first STA based on the third frame.

[0310] Process 2800 may further include the first STA receiving a fourth frame from the first AP during a first duration. In an embodiment, the fourth frame may be received before transmitting the second frame and after receiving the third frame. In an embodiment, the first STA may be allowed to ignore its basic NAV during the first duration in response to the fourth frame from the first AP. In an embodiment, the fourth frame may include a trigger frame, a Multi-User Request to Send Triggered TXOP Share (MU-RTS TXS) Triggered (MRTT) frame, or a Request to Send (RTS) frame. In an embodiment, the second frame may be an uplink frame received in response to the fourth frame.

[0311] In one embodiment, the first frame may include an MRTT frame. In another embodiment, an indication allowing the STA to ignore its basic NAV may be provided in the common information field of the MRTT frame. In yet another embodiment, the first frame may include a beacon frame or a management frame. In another embodiment, an indication allowing the STA to ignore its basic NAV may be provided in the beacon frame or the management frame.

Claims

1. A method comprising: A first frame is transmitted from a first access point (AP) to a second AP during a transmission opportunity (TXOP) obtained by the first AP, the first frame indicating a first duration allocated to the second AP within the TXOP; The first AP receives a trigger frame addressed to the first station (STA) from the second AP during the first duration. The first AP receives a second frame from the second AP during the first duration, and the second frame indicates that the second AP returns the first duration to the first AP. and After receiving the trigger frame and the second frame, the first AP transmits a third frame to the second STA to reset the basic network allocation vector (NAV) of the second STA.

2. A method comprising: A trigger frame is received by a first access point (AP) from a second AP and during a first duration allocated to the second AP by the first AP; The first AP receives a first frame from the second AP during the first duration, and the first frame indicates that the second AP returns the first duration to the first AP. and After receiving the first frame, the first AP transmits a second frame to the first STA to reset the basic network allocation vector (NAV) of the first STA.

3. The method according to claim 2, further comprising: The first AP receives a trigger frame addressed to the second STA from the second AP and during the first duration.

4. The method according to claim 3, further comprising: A third frame indicating the first duration is transmitted from the first AP to the second AP during a transmission opportunity (TXOP) obtained by the first AP, wherein the first duration is within the TXOP.

5. The method according to claim 4, wherein, The third frame is transmitted before the first and second frames.

6. The method according to any one of claims 2-5, wherein, The first frame includes a contention-free end (CF-end) frame.

7. The method according to claim 6, wherein, The CF-end frame includes an indication of the transmitter address (TA) of the second AP.

8. The method according to any one of claims 2-6, wherein, The second frame includes the CF-end frame.

9. The method according to claim 8, wherein, The CF-end frame includes an indication of the transmitter address (TA) of the second AP.

10. The method according to any one of claims 2-7, wherein, The second frame includes: a trigger frame, a multi-user request to send triggered TXOP sharing (MU-RTS TXS) trigger (MRTT) frame, or a request to send (RTS) frame.

11. The method according to claim 10, wherein, The second frame includes a basic NAV reset instruction.

12. The method according to any one of claims 2-11, further comprising resetting the basic NAV of the first AP after receiving the first frame.

13. The method according to any one of claims 2-12, further comprising: The fourth frame is transmitted from the first AP to the first STA after the second frame.

14. The method according to claim 13, wherein, The fourth frame is initiated by the first STA for uplink transmission.

15. The method according to any one of claims 2-12, further comprising: The first AP transmits a fourth frame, which is aggregated with the second frame, to the first STA.

16. The method according to claim 15, wherein, The fourth frame is configured to trigger uplink transmission by the first STA.

17. The method according to any one of claims 13-16, further comprising: The first AP receives the fifth frame in response to the fourth frame from the first STA.

18. A method comprising: A first frame indicating a first duration is received by a first station (STA) from a second STA, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the basic network allocation vector (NAV) of the first STA, wherein the first duration is within a transmission opportunity (TXOP) and is allocated to a first access point (AP), the first AP being an OBSSAP; The basic NAV of the first STA is set based on the first frame; The first STA receives a second frame from the second AP during the first duration to reset the basic NAV of the first STA; and After receiving the second frame, the basic NAV of the first STA is reset.

19. A method comprising: The first station (STA) receives a first frame from the second STA, which is an Overlapping Basic Service Set (OBSS) STA, indicating a first duration. The first frame is used to set the basic network allocation vector (NAV) of the first STA. The basic NAV of the first STA is set based on the first frame; and The first STA receives a second frame from the first access point (AP) during the first duration to reset the basic NAV of the first STA.

20. The method according to claim 19, wherein, The first duration is within the transmission opportunity (TXOP) allocated to the second AP.

21. The method according to claim 20, wherein, The second AP is the OBSS AP.

22. The method of claim 21, further comprising: The basic NAV of the first STA is reset after the second frame is received.

23. The method according to any one of claims 19-22, wherein, The first frame is a data frame.

24. The method according to any one of claims 19-23, wherein, The second frame includes the CF-end frame.

25. The method according to claim 24, wherein, The CF-end frame includes an indication of the transmitter address (TA) of the second AP.

26. The method according to any one of claims 19-23, wherein, The second frame includes: a trigger frame, a multi-user request to send triggered TXOP sharing (MU-RTS TXS) trigger (MRTT) frame, or a request to send (RTS) frame.

27. The method according to claim 26, wherein, The second frame includes a basic NAV reset instruction.

28. The method according to any one of claims 19-27, further comprising: The third frame is received by the first STA from the first AP after the second frame.

29. The method according to claim 28, wherein, The third frame is initiated by the first STA for uplink transmission.

30. The method according to any one of claims 19-27, further comprising: The first STA receives a third frame aggregated with the second frame from the first AP.

31. The method according to claim 30, wherein, The third frame is configured to trigger uplink transmission by the STA.

32. The method according to any one of claims 28-31, further comprising: The first STA transmits a fourth frame to the first AP in response to the third frame.

33. A method comprising: A first frame is transmitted by a first access point (AP), the first frame including an indication of whether a station (STA) is permitted to ignore the station's basic network allocation vector (NAV) during a first duration allocated by the first AP to a second AP; The first AP receives a second frame from the second AP during the first duration, and the second frame indicates that the second AP returns the first duration to the first AP. and Based on the instruction that allows the STA to ignore the STA's basic NAV during the first duration, the first AP transmits a third frame to the STA, which triggers an uplink transmission from the STA to the first AP.

34. The method according to claim 33, wherein, In response to the third frame from the first AP, the STA is permitted to ignore the STA's basic NAV during the first duration.

35. The method according to claim 34, wherein, The third frame includes: a trigger frame, a multi-user request to send triggered TXOP sharing (MU-RTS TXS) trigger (MRTT) frame, or a request to send (RTS) frame.

36. The method according to any one of claims 33-35, wherein, The first frame includes a TXOP Shared (MU-RTS TXS) Triggered (MRTT) frame triggered by multiple user request transmission.

37. The method of claim 36, wherein, The public information field of the MRTT frame provides an indication that allows the STA to ignore the STA's basic NAV.

38. The method according to any one of claims 33-35, wherein, The first frame includes a beacon frame or a management frame.

39. The method according to claim 38, wherein, The beacon frame or the management frame provides an indication that allows the STA to ignore the STA's basic NAV.

40. The method according to any one of claims 33-39, wherein, The second frame includes a contention-free end (CF-end) frame.

41. The method according to claim 40, wherein, The CF-end frame includes an indication of the transmitter address (TA) of the second AP.

42. The method according to any one of claims 33-41, further comprising: The first AP receives the fourth frame in response to the third frame from the first STA.

43. A method comprising: A first frame is received by the first STA from the first access point (AP), the first frame including an indication of whether the first STA is permitted to ignore the basic network allocation vector (NAV) of the first STA during a first duration allocated by the first AP to the second AP; and Based on the instruction that allows the STA to ignore the STA's basic NAV during the first duration, the first STA transmits a second frame to the first AP during the first duration without taking the basic NAV into account when transmitting the second frame.

44. The method of claim 43, further comprising: The first STA receives a third frame from the second STA indicating a first duration for setting the basic NAV of the first STA.

45. The method according to claim 44, wherein, The third frame was received before the second frame was transmitted.

46. ​​The method of claim 45, further comprising: The basic NAV of the first STA is set based on the third frame.

47. The method of claim 46, further comprising: The first STA receives the fourth frame from the first AP during the first duration.

48. The method according to claim 47, wherein, The fourth frame is received before the second frame is transmitted and after the third frame is received.

49. The method according to any one of claims 43-48, wherein, In response to the fourth frame from the first AP, the first STA is permitted to ignore the basic NAV of the first STA during the first duration.

50. The method of claim 47, wherein, The fourth frame includes: a trigger frame, a multi-user request to send triggered TXOP sharing (MU-RTS TXS) trigger (MRTT) frame, or a request to send (RTS) frame.

51. The method according to any one of claims 43-50, wherein, The second frame is an uplink frame obtained in response to the fourth frame.

52. The method according to any one of claims 43-51, wherein, The first frame includes an MRTT frame.

53. The method according to claim 52, wherein, The public information field of the MRTT frame provides an indication that allows the STA to ignore the STA's basic NAV.

54. The method according to any one of claims 43-51, wherein, The first frame includes a beacon frame or a management frame.

55. The method according to claim 54, wherein, The beacon frame or the management frame provides an indication that allows the STA to ignore the STA's basic NAV.

56. A computer program product that can be stored on a computer-readable medium, said computer program product being configured to perform the method according to any of the preceding claims when run on a computer.

57. A device arranged to communicate in a wireless network as an access point (AP), said device being arranged to: A first frame is transmitted to the second AP during a transmission opportunity (TXOP) obtained by the device, the first frame indicating a first duration allocated to the second AP within the TXOP; The trigger frame addressed to the first station (STA) is received from the second AP during the first duration. A second frame is received from the second AP during the first duration, the second frame indicating that the first duration is returned to the first AP by the second AP; and After receiving the trigger frame and the second frame, a third frame is transmitted to the second STA to reset the basic network allocation vector (NAV) of the second STA.

58. A device arranged to communicate in a wireless network as an access point (AP), said device being arranged to: Receive trigger frames from the second AP and during a first duration allocated to the second AP by the device; The device receives a first frame from the second AP during the first duration, the first frame indicating that the first duration is returned by the second AP; and After receiving the first frame, a second frame is transmitted to the first station (STA) to reset the basic network allocation vector (NAV) of the first STA.

59. A device arranged for communication in a wireless network, said device having a basic NAV and arranged as follows: A first frame indicating a first duration is received from a second STA, which is an Overlapping Basic Service Set (OBSS) STA. The first frame is used to set the Basic Network Allocation Vector (NAV) of the first STA. The first duration is within a transmission opportunity (TXOP) and is allocated to a first access point (AP), which is an OBSS AP; The basic NAV is set based on the first frame; A second frame is received from the second AP and during the first duration for resetting the basic NAV; and The basic NAV is reset after the second frame is received.

60. A device arranged for communication in a wireless network, the device having a basic NAV and arranged as follows: Receive a first frame indicating a first duration from a second STA, the second STA being an Overlapping Basic Service Set (OBSS) STA, the first frame being used to set the Basic Network Allocation Vector (NAV) of the first STA; The basic NAV is set based on the first frame; and A second frame is received from the first access point (AP) and during the first duration to reset the basic NAV.

61. A device arranged for communication in a wireless network, the device having a basic network allocation vector (NAV) and arranged as follows: A first frame is received from a first access point (AP), the first frame including an indication of whether the first STA is permitted to ignore the NAV during a first duration allocated by the first AP to the second AP; and Based on the instruction to allow the device to perform the NAV during the first duration, a second frame is transmitted to the first AP during the first duration, without considering the NAV when transmitting the second frame.

Images