Coordinated time division multiple access (CTDMA) truncation procedure

Abstract

There is provided methods and device for use in a wireless network. A method comprises transmitting, by a first access point (AP) to a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; receiving, by the first AP from the first STA, a second frame in response to the first frame, based on the second frame indicating that the first STA has no buffered data for transmission to the first AP, transmitting, by the first AP to the first STA, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmitting, by the first AP, a second truncation frame for resetting a second basic NAV of a third STA.

Description

COORDINATED TIME DIVISION MULTIPLE ACCESS (CTDMA) TRUNCATIONPROCEDUREBACKGROUND

[0001] Wireless networks are frequently very busy with many devices ‘wanting’ to transmit. The heavy occupation of the wireless medium can result in unacceptable delays or latency for some high importance transmissions. In certain networks like IEEE 802.11 (also known as ‘WiFi’), device like Access Points (APs) may coordinate between themselves with the aim of improving usage of the medium. Also, many wireless networks overlap with and are subject to interference from other, similar and different, wireless networks.

[0002] The present application claims priority from US provisional applications 63 / 548408, 63 / 557641 and 63 / 626551, the entire disclosures of which are incorporated by reference.SUMMARY

[0003] With the aim of reducing latency in wireless networks, there are provided methods, devices and computer program products as defined in the appended claims.

[0004] In an aspect, there is provided a method, comprising transmitting, by a first access point (AP) to a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, receiving, by the first AP from the first STA, a second frame in response to the first frame, based on the second frame indicating that the first STA has no buffered data for transmission to the first AP, transmitting, by the first AP to the first STA, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmitting, by the first AP, a second truncation frame for resetting a second basic NAV of a third STA.

[0005] In an aspect, there is provided a method, comprising receiving, by a first access point (AP) from a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, based on the first frame indicating that the first STA has no buffered data for transmission to the first AP, transmitting, by the first AP to the first STA, a second frame that triggers transmission by the first STA of a first truncation frame; and transmitting, by the first AP, a second truncation frame.

[0006] In an aspect, there is provided a method, comprising receiving, by a first station (STA) from a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, transmitting, by the first STA to the first AP, a second frame in response to the first frame, wherein the second frame indicates whether the first STA has buffered data for transmission to the first AP, receiving, by the first STA from the first AP, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmitting, by the first STA, the first truncation frame.

[0007] In an aspect, there is provided a method comprising transmitting, by a first station (STA) to a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, wherein the first frame indicates whether the first STA has buffered data for transmission to the first AP, receiving, by the first STA from the first AP, a second frame that triggers transmission by the first STA of a first truncation frame.

[0008] In an aspect there is provided computer-program product, storable on a computer- readable medium and arranged to, when run on a computer, execute the method disclosed herein.

[0009] In aspects there is provided devices, arranged to function in an access point (AP) and stations (STA) of a wireless netowrk, the device being arranged perform the methods disclosed herein.

[0010] In C-TDMA, where one AP (the sharing AP) shares a TXOP with another AP (the shared AP). It may happen that the sharing AP may receive a trigger frame from the shared AP during the period allocated to the shared AP. This trigger frame has the effect of updating a basic NAV of a STA associated with the shared AP. The shared AP may then send a frame (e.g. a CF-End frame) returning the TXOP (i.e. releasing it) to the sharing AP. A STA associated with the shared AP may hear a frame from that STA which allows it to reset it NAV and commence communicating with its AP.

[0011] The inventor has realized that problems may occur for a STA outside the range of the shared AP but within the range of the sharing AP and not part of the multi-AP group. It may set its NAV when the sharing AP sends the first frame setting up the shared TXOP. It then hears the frame from the sharing AP releasing or truncating the TXOP, sent as part of the exchanges for the multi-AP group, and resets its NAV, which is undesirable because there may be exchanges to come within the multi-AP group. If the truncation of the first part of the TXOP is achieved by frames from the shared AP and its STA’s, the STA outside range of the shared AP and STAs does not reset its NAV and the protection of the TXOP is preserved.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings.

[0013] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.

[0014] FIG. 2 is a block diagram illustrating example implementations of a station (STA) and an access point (AP).

[0015] FIG. 3 illustrates an example Medium Access Control (MAC) frame format.

[0016] FIG. 4 illustrates an example management frame which may be used as an action frame.

[0017] FIG. 5 illustrates an example control frame which may be used as a trigger frame.

[0018] FIG. 6 illustrates an example data frame which may be used as a Quality of Service (QoS) null frame.

[0019] FIG. 7 illustrates an example format of a physical layer (PHY) protocol data unit (PPDU).

[0020] FIG. 8 illustrates an example multi-AP network.

[0021] FIG. 9 illustrates an example network that includes a coordinated AP set.

[0022] FIG. 10 illustrates an example multi-AP operation procedure.

[0023] FIG. 11 illustrates an example multi-AP sounding phase.

[0024] FIG. 12 illustrates an example multi-AP downlink data transmission phase.

[0025] FIG. 13 illustrates an example multi-AP uplink data transmission phase.

[0026] FIG. 14 illustrates Enhanced Distributed Channel Access (EDCA) and Coordinated Time Division Multiple Access (CTDMA).

[0027] FIG. 15 illustrates an example of a Multi-User Request-to-Send (MU-RTS) trigger frame which may be used in a triggered Transmission Opportunity (TXOP) sharing (TXS) procedure.

[0028] FIG. 16 illustrates an example of a triggered TXS procedure (Mode =1).

[0029] FIG. 17 illustrates an example of a triggered TXS procedure (Mode =2).

[0030] FIG. 18 illustrates an example of an existing CTDMA procedure.

[0031] FIG. 19 illustrates another example of an existing CTDMA procedure.

[0032] FIG. 20 illustrates another example of a CTDMA procedure.

[0033] FIG. 21 illustrates another example of a CTDMA procedure.

[0034] FIG. 22 illustrates an example of a CTDMA procedure according to an embodiment.

[0035] FIG. 23 illustrates another example of a CTDMA procedure according to an embodiment.

[0036] FIG. 24 illustrates another example of a CTDMA procedure according to an embodiment.

[0037] FIG. 25 illustrates an example process according to an embodiment.

[0038] FIG. 26 illustrates another example process according to an embodiment.DETAILED DESCRIPTION

[0039] In the present disclosure, various embodiments are presented as examples of how the disclosed techniques may be implemented and / or how the disclosed techniques may be practiced in environments and scenarios. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the scope. After reading the description, it will be apparent to one skilled in the relevant art how to implement alternative embodiments. The present embodiments may not be limited by any of the described exemplary embodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of the disclosure. Any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.

[0040] Embodiments may be configured to operate as needed. The disclosed mechanism may be performed when certain criteria are met, for example, in a station, an access point, a radio environment, a network, a combination of the above, and / or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and / or the like. When the one or more criteria are met, various example embodiments may be applied. Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.

[0041] In this disclosure, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not,be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes” and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of’ provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on”. The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or A, B, and C.

[0042] If A and B are sets and every element of A is an element of B, 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 equally “based at least on”) is indicative that the phrase following the term “based on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “in response to” (or equally “in response at least to”) is indicative that the phrase following the phrase “in response to” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “depending on” (or equally “depending at least to”) is indicative that the phrase following the phrase “depending on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “employing / using” (or equally “employing / using at least”) is indicative that the phrase following the phrase “employing / using” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments.

[0043] The term configured may relate to the capacity of a device whether the device is in an operational or non-operational state. Configured may refer to specific settings in a device that effect the operational characteristics of the device whether the device is in an operational or non-operational state. In other words, the hardware, software, firmware, registers, memory values, and / or the like may be “configured” within a device, whether the device is in an operational or nonoperational state, to provide the device with specific characteristics. Terms such as “a control message to cause in a device” may mean that a control message has parameters that may be used to configure specific characteristics or may be used to implement certain actions in the device, whether the device is in an operational or non-operational state.

[0044] In this disclosure, parameters (or equally called, fields, or Information elements: IES) may comprise one or more information objects, and an information object may comprise oneor more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K, and N comprises J. In an example embodiment, when one or more messages / frames comprise a plurality of parameters, it implies that a parameter in the plurality of parameters is in at least one of the one or more messages / frames but does not have to be in each of the one or more messages / frames.

[0045] Many features presented are described as being optional through the use of “may” or the use of parentheses. For the sake of brevity and legibility, the present disclosure does not explicitly recite each and every permutation that may be obtained by choosing from the set of optional features. The present disclosure is to be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features may be embodied in seven ways, namely with just one of the three possible features, with any two of the three possible features or with three of the three possible features.

[0046] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g., hardware with a biological element) or a combination thereof, which may be behaviorally equivalent. For example, modules may 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 or the like) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEWMathScript. It may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and / or quantum hardware. Examples of programmable hardware comprise 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, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. The mentioned technologies are often used in combination to achieve the result of a functional module.

[0047] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.

[0048] As shown in FIG. 1, the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WLAN) infra-structure network 102. WLAN infra-structure network 102 may include one or more basic service sets (BSSs) 110 and 120 and a distribution system (DS) 130.

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

[0050] DS 130 may be configured to connect BSS 110-1 and BSS 110-2. As such, DS 130 may enable an extended service set (ESS) 150. Within ESS 150, APs 104-1 and 104-2 are connected via DS 130and may have the same service set identification (SSID).

[0051] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1, WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802. X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108.

[0052] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network that includes a plurality of STAs that are within communication range of each other. The plurality of STAs are configured so that they may communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

[0053] For example, in FIG. 1, STAs 106-4, 106-5, and 106-6 may be configured to form a first IBSS 112-1. Similarly, STAs 106-7 and 106-8 may 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. Rather, STAs within an IBSS are managed in a distributed manner. STAs forming an IBSS may be fixed or mobile.

[0054] A STA as a predetermined functional medium may include a medium access control (MAC) layer that complies with an IEEE 802.11 standard. A physical layer interface for a radio medium may be used among the APs and the non-AP stations (STAs). The STA may also be referred to using various other terms, including mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term “user” may be used to denote a STA participating in uplink Multi-user Multiple Input, Multiple Output (MU MIMO) and / or uplink Orthogonal Frequency Division Multiple Access (OFDMA) transmission.

[0055] A physical layer (PHY) protocol data unit (PPDU) may be a composite structure that includes a PHY preamble and a payload in the form of a PLCP service data unit (PSDU). Forexample, the PSDU may include a PHY Convergence Protocol (PLCP) preamble and header and / or one or more MAC protocol data units (MPDUs). The information provided in the PHY preamble may be used by a receiving device to decode the subsequent data in the PSDU. In instances in which PPDUs are transmitted over a bonded channel (channel formed through channel bonding), the preamble fields may be duplicated 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 may be used for packet detection, automatic gain control and channel estimation, among other uses. The legacy preamble also may generally be used to maintain compatibility with legacy devices. The format of, coding of, and information provided in the non-legacy portion of the preamble is based on the particular IEEE 802.11 protocol to be used to transmit the payload.

[0056] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.1 In, 802.1 lac, 802.1 lax and / or 802.11be standard amendments may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which may be divided into multiple 20 MHz channels. The PPDUs may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Larger channels may be formed through channel bonding. For example, PPDUs may be transmitted over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding together multiple 20 MHz channels.

[0057] FIG. 2 is a block diagram illustrating example implementations of a STA 210 and an AP 260. As shown in FIG. 2, STA 210 may include at least one processor 220, a memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, a memory 280, and at least one transceiver 290. Processor 220 / 270 may be operatively connected to memory 230 / 280 and / or to transceiver 240 / 290.

[0058] Processor 220 / 270 may implement functions of the PHY layer, the MAC layer, and / or the logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processor 220 / 270 may include one or more processors and / or one or more controllers. The one or more processors and / or one or more controllers may comprise, for example, a general- purpose processor, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a logic circuit, or a chipset, for example.

[0059] Memory 230 / 280 may include a read-only memory (ROM), a random-access memory (RAM), a flash memory, a memory card, a storage medium, and / or other storage unit. Memory 230 / 280 may comprise one or more non-transitory computer readable mediums. Memory230 / 280 may store computer program instructions or code that may be executed by processor 220 / 270 to carry out one or more of the operations / embodiments discussed in the present application. Memory 230 / 280 may be implemented (or positioned) within processor 220 / 270 or external to processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.

[0060] Transceiver 240 / 290 may be configured to transmit / receive radio signals. In an embodiment, transceiver 240 / 290 may implement a PHY layer of the corresponding device (STA 210 or AP 260). In an embodiment, STA 210 and / or AP 260 may be a multi -link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11 standard. As such, STA 210 and / or AP 260 may each implement multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers 240 / 290.

[0061] FIG. 3 illustrates an example format of a MAC frame 300. In operation, a STA may construct a subset of MAC frames for transmission and may decode a subset of received MAC frames upon validation. The particular subsets of frames that a STA may construct and / or decode may be determined by the functions supported by the STA. A STA may validate a received MAC frame using the frame check sequence (FCS) contained in the frame and may interpret certain fields from the MAC headers of all frames.

[0062] As shown in FIG. 3, MAC frame 300 includes a MAC header, a variable length frame body, and a frame check sequence (FCS).

[0063] The MAC header includes a frame control field, an optional duration / ID field (not in PS-Poll frames), address fields, 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).

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

[0065] The protocol version subfield is invariant in size and placement across all revisions of the IEEE 802.11 standard. The value of the protocol version subfield is 0 for MAC frames.

[0066] The type and subtype subfields together identify the function of the MAC frame. There are three frame types: control, data, and management. Each of the frame types has several defined subtypes. Bits within the subtype subfield are used to indicate a specific modification of the basic data frame (subtype 0). For example, in data frames, 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 contains a QoS control field in its MAC header. The second MSB of the subtype field, bit6 (B6) of the frame control field, when set to 1 in data subtypes, indicates a data frame that contains no frame body field.

[0067] The To DS subfield indicates whether a data frame is destined to the DS. The From DS subfield indicates whether a data frame originates from the DS.

[0068] The more fragments subfield is set to 1 in all data or management frames that have another fragment to follow of the MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU) carried by the MAC frame. It is set to 0 in all other frames in which the more fragments subfield is present.

[0069] 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 is present. A receiving STA uses this indication to aid it in the process of eliminating duplicate frames. These rules do not apply for frames sent by a STA under a block agreement.

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

[0071] The More Data subfield indicates to a STA in power save (PS) mode that bufferable units (BUs) are buffered for that STA at the AP. The more data subfield is valid in individually addressed data or management frames transmitted by an AP to a STA in PS mode. The more data subfield is set to 1 to indicate that at least one additional buffered BU is present for the STA.

[0072] The protected frame subfield is set to 1 if the frame body field contains information that has been processed by a cryptographic encapsulation algorithm.

[0073] The +HTC subfield indicates that MAC frame 300 contains an HT control field. A frame that contains the HT Control field is referred to as a +HTC frame. A Control Wrapper frame is a +HTC frame.

[0074] The duration / ID field of the MAC header indicates various contents depending on frame type and subtype and the QoS capabilities of the sending STA. For example, in control frames of the power save poll (PS-Poll) subtype, the duration / ID field carries an association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most significant bits (MSB) are both set to 1. In other frames sent by STAs, the duration / ID field contains a duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV). The NAV is a counter that indicates to a STA an amount of time during which it must defer from accessing the shared medium.

[0075] There can be up to four address fields in the format of MAC frame 300. 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). Certain frames might notcontain some of the address fields. Certain address field usage may be specified by the relative position of the address field (1-4) within the MAC header, independent of the type of address present in that field. Specifically, the address 1 field always identifies the intended receiver(s) of the frame, and the address 2 field, where present, always identifies the transmitter of the frame.

[0076] The sequence control field includes two subfields, a sequence number subfield and a fragment number subfield. The sequence number subfield in data frames indicates the sequence number of the MSDU (if not in an Aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield in management frames indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of an MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in a MAC protocol data unit (MPDU) containing an A-MSDU, or in an MPDU containing an MSDU or MMPDU that is not fragmented. The fragment number remains constant in all retransmissions of the fragment.

[0077] The QoS control field identifies the traffic category (TC) or traffic stream (TS) to which MAC frame 300 belongs. The QoS control field may also indicate various other QoS related, A-MSDU related, and mesh-related information about the frame. This information can vary by frame type, frame subtype, and type of transmitting STA. The QoS control field is present in all data frames in which the QoS subfield of the subtype subfield is equal to 1.

[0078] The HT control field is present in QoS data, QoS null, and management frames as determined by the +HTC subfield of the frame control field. The control frame subtype for which HT control field is present is the control wrapper frame. A control frame that is described as +HTC (e.g., a request to send (RTS)+HTC, clear to send (CTS)+HTC, block acknowledgment (BlockAck)+HTC or block acknowledgment request (BlockAckReq)+HTC frame) implies the use of the control wrapper frame to carry that control frame.

[0079] The frame body field is a variable length field that contains information specific to individual frame types and subtypes. It may include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.

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

[0081] FIG. 4 illustrates an example management frame 400 which may be used as an action frame. In an 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 a +HTC subfield of the frame control field.

[0082] As shown in FIG. 4, when used as an action frame, the frame body of management frame includes an action field, vendor specific elements, management message integrity code element (MME), message integrity code (MIC), and an authenticated mesh peering exchange element.

[0083] 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 a category of the action frame. The action details field contains the details of the action requested by the action frame. For example, the action frame may be a public action frame. As shown in FIG. 4, in the public action frame format, the action details field includes a public action field, in the octet immediately after the category field, followed by a variable length public action details field.

[0084] One or more vendor specific elements are optionally present. These elements are absent when the category subfield of the Action field is vendor-specific.

[0085] The MME is present when management frame protection is negotiated, the frame is a group addressed robust Action frame, and (MBSS only) the category of the action frame does not support group addressed privacy as indicated by category values; otherwise not present.

[0086] The MIC element is present in a self-protected action frame if a shared pairwise master key (PMK) exists between the sender and recipient of this frame; otherwise not present.

[0087] The authenticated mesh peering exchange element is present in a self-protected action frame if a shared PMK exists between the sender and recipient of this frame; otherwise not present.

[0088] FIG. 5 illustrates an example format of a trigger frame 500. Trigger frame 500 may be used by an AP to allocate resources for and solicit one or more TB PPDU transmissions from one or more STAs. Trigger frame 500 may also carry other information required by a responding STA to transmit a TB PPDU to the AP.

[0089] As shown in FIG. 5, trigger frame 500 includes a Frame Control field, a Duration field, a receiver address (RA) field, a transmitter address (TA) field, a Common Info field, a User Info List field, a Padding field, and an FCS field.

[0090] The Frame Control field includes the following subfields: protocol version, type, subtype, To DS, From DS, more fragments, retry, power management, more data, protected frame, and +HTC.

[0091] The Duration field indicates various contents depending on frame type and subtype and the QoS capabilities of the sending STA. For example, in control frames of the power save poll(PS-Poll) subtype, the Duration field carries an association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most significant bits (MSB) are both set to 1. In other frames sent by STAs, the Duration field contains a duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV).

[0092] The RA field is the address of the STA that is intended to receive the incoming transmission from the transmitting station. The TA field is the address of the STA transmitting trigger frame 500 if trigger frame 500 is addressed to STAs that belong to a single BSS. The TA field is the transmitted BSSID if trigger frame 500 is addressed to STAs from at least two different BSSs of the multiple BSSID set.

[0093] The Common Info field specifies a trigger frame type of trigger frame 500, a transmit power of trigger frame 500 in dBm, and several key parameters of a TB PPDU that is transmitted by a STA in response to trigger frame 500. The trigger frame type of a trigger frame used by an AP to receive QoS data using UL MU operation is referred to as a basic trigger frame. A non-EHT non-AP HE STA interprets the Common Info field as HE variant. A non-AP EHT STA interprets the Common Info field as HE variant if B54 and B55 in the Common Info field are equal to 1; and interprets the Common Info field as EHT variant otherwise. The HE variant Common Info field and the EHT variant Common Info field use the same encoding method for the Trigger Type, UL Length, More TF, CS Required, LDPC Extra Symbol Segment, AP TX Power, Pre-FEC Padding Factor, PE Disambiguity, and Trigger Dependent Common Info subfields.

[0094] The User Info List field contains zero or more User Info fields. There are three variants for the User Info field, which are the Special User Info field, the EHT variant User Info field, and the HE variant User Info field.

[0095] The Special User Info field is a User Info field that does not carry the user specific information but carries the extended common information not provided in the Common Info field. If the Special User Info field is included in the Trigger frame, then the Special User Info Field Flag subfield of the EHT variant Common Info field is set to 0, otherwise it is set to 1. The Special User Info field is identified by an AID12 value of 2007 and is optionally present in a Trigger frame that is generated by an EHT AP. The Special User Info field, if present, is located immediately after the Common Info field of the Trigger frame and carries information for the U-SIG field of a solicited EHT TB PPDU. The PHY Version Identifier subfield indicates the PHY version of the solicited TB PPDU that is not an HE TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. The UL Bandwidth (BW) Extension subfield, together with the UL BW subfield in the Common Infofield, indicates the bandwidth of the solicited TB PPDU from the addressed EHT STA (i.e., the bandwidth in the U-SIG field of the EHT TB PPDU). The EHT Spatial Reuse n subfield carries the values to be included in the corresponding Spatial Reuse n subfield in the U-SIG field of the EHT TB PPDU. The U-SIG Disregard And Validate subfield carries the values to be included in the Disregard and Validate subfields of the U-SIG field of the solicited EHT TB PPDUs. The presence and length of the Trigger Dependent User Info subfield in the Special User Info field depends on the variant of the Trigger frame.

[0096] The EHT variant User Info field contains a User Info field per STA addressed in trigger frame 500. The per STA User Info field includes, among others, an AID 12 subfield, an RU Allocation subfield, a UL FEC Coding Type subfield, a UL EHT-MCS subfield, a Reserved subfield, a Spatial Stream (SS) Allocation / RA-RU information subfield, a UL Target Receive Power subfield, and a Power Save (PS) 160 subfield to be used by a STA in a TB PPDU transmitted in response to trigger frame 500, and a Trigger Dependent User Info subfield. The RU Allocation subfield in an EHT variant User Info field in a Trigger frame that is not an MU- RTS Trigger frame, along with the UL BW subfield in the Common Info field, the UL BW Extension subfield in the Special User Info field, and the PS 160 subfield in the EHT variant User Info field, identifies the size and the location of the RU or MRU. The values of PS160 subfield and B0 of RU Allocation subfield indicate the 80 MHz frequency subblock in which the RU or MRU is located for 26-tone RU, 52-tone RU, 106-tone RU, 242-tone RU, 484-tone RU, 996-tone RU, 52+26-tone RU, and 106+26-tone RU. The values of PS 160 subfield indicates the 160 MHz segment in which the RU or MRU is located for 2D 996-tone RU, 996+484-tone MRU, and 996+484+242-tone MRU. The UL FEC Coding Type subfield of the User Info field indicates the code type of the solicited EHT TB PPDU. The UL FEC Coding Type subfield is set to 0 to indicate BCC and set to 1 to indicate LDPC. The UL EHT-MCS subfield of the User Info field indicates the EHT-MCS of the solicited EHT TB PPDU. The SS Allocation subfield of the EHT variant User Info field indicates the spatial streams of the solicited EHT TB PPDU. The UL Target Receive Power subfield indicates the expected receive signal power, measured at the AP’s antenna connector and averaged over the antennas, for the EHT portion of the EHT TB PPDU transmitted on the assigned RU. The Trigger Dependent User Info subfield can be used by an AP to specify a preferred access category (AC) per STA. The preferred AC sets the minimum priority AC traffic that can be sent by a participating STA. The AP determines the list of participating STAs, along with the BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and maximum duration of the TB PPDU per participating STA. The RA-RU Information subfield is reserved in the EHT variant User Info field.

[0097] The Padding field is optionally present in trigger frame 400 to extend the frame length to give recipient STAs enough time to prepare a response for transmission one SIFS after the frame is received. The Padding field, if present, is at least two octets in length and is set to all Is.

[0098] The FCS field is used by a STA to validate a received frame and to interpret certain fields from the MAC headers of a frame.

[0099] FIG. 6 illustrates an example data frame 600 which may be used as a QoS null frame. A QoS null frame refers to a QoS data frame with an empty frame body. QoS null frame includes a QoS control field and an optional HT control field which may contain a buffer status report (BSR) control subfield. A QoS null frame indicating buffer status information may be transmitted by a STA to an AP.

[0100] The QoS control field may include a traffic identifier (TID) subfield, an acknowledgment (Ack) policy indicator subfield, and a queue size subfield (or a transmission opportunity (TXOP) duration requested subfield).

[0101] The TID subfield identifies the TC or TS of traffic for which a TXOP is being requested, through the setting of the TXOP duration requested or queue size subfield. The encoding of the TID subfield depends on the access policy (e.g., Allowed value 0 to 7 for enhanced distributed channel access (EDCA) access policy to identify user priority for either TC or TS).

[0102] The ack policy indicator subfield, together with other information, identifies the Ack policy followed upon delivery of the MPDU (e.g., normal Ack, implicit block Ack request, no Ack, block Ack, etc.)

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

[0104] In a frame sent by or to a non-high efficiency (non-HE) STA, the following rules may apply to the queue size value:The queue size value is the approximate total size, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU contained in the present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS Control field.A queue size value of 0 is used solely to indicate the absence of any buffered traffic in the queue used for the specified TID.A queue size value of 254 is used for all sizes greater than 64 768 octets.A queue size value of 255 is used to indicate an unspecified or unknown size.

[0105] In a frame sent by an HE STA to an HE AP, the following rules may apply to the queue size value.

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

[0107] The queue size subfield includes a scaling factor subfield in bits B14-B15 of the QoS control field and an unsealed value, UV, in bits B8-B13 of the QoS control field. The scaling factor subfield provides the scaling factor, SF.

[0108] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unsealed value, UV, as follows:QS =16 x up7, if SF is equal to 0;1024 + 256 x [ / J7, if SF is equal to 1;17 408 + 2048 x UE, if SF is equal to 2;148 480 + 32 768 x UE, if SF is equal to 3 and UEis less than 62;> 2 147 328, if SF equal to is 3 and UEis equal to 62;Unspecified or Unknown, if SF is equal to 3 and UEis equal to 63.

[0109] The TXOP duration requested subfield, which may be included instead of the queue size subfield, indicates the duration, in units of 32 microseconds (us), that the sending STA determines it needs for its next TXOP for the specified TID. The TXOP duration requested subfield is set to 0 to indicate that no TXOP is requested for the specified TID in the current service period (SP). The TXOP duration requested subfield is set to a nonzero value to indicate a requested TXOP duration in the range of 32 us to 8160 us in increments of 32 us.

[0110] The HT control field may include an aggregated control (A-Control) subfield. The A- Control subfield may include a control list subfield including one or more control subfields.[OHl] The control subfield may be a B SR control subfield, which may contain buffer status information used for UL MU operation. The BSR control subfield may be formed from an access category index (ACI) bitmap subfield, a delta TID subfield, an ACI high subfield, ascaling factor subfield, a queue size high subfield, and a queue size all subfield of the HT control field.

[0112] The ACI bitmap subfield indicates the access categories for which buffer status is reported (e.g., BO: best effort (AC BE), Bl : 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 the queue size all subfield, and set to 0 otherwise, except that if the ACI bitmap subfield is 0 and the delta TID subfield is 3, then the buffer status of all 8 TIDs is included.

[0113] The delta TID subfield, together with the values of the ACI bitmap subfield, indicate the number of TIDs for which the STA is reporting the buffer status.

[0114] The ACI high subfield indicates the ACI of the AC for which the BSR is indicated 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.

[0115] The scaling factor subfield indicates the unit 5F, in octets, of the queue size high and queue size all subfields.

[0116] The queue size high subfield indicates the amount of buffered traffic, in units of SF octets, for the AC identified by the ACI high subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0117] The queue size all subfield indicates the amount of buffered traffic, in units of SF octets, for all ACs identified by the ACI Bitmap subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0118] The queue size values in the queue size high and queue size all subfields are the total sizes, rounded up to the nearest multiple of SF octets, of all MSDUs and A-MSDUs buffered at the STA (including the MSDUs or A-MSDUs contained in the same PSDU as the frame containing the BSR control subfield) in delivery queues used for MSDUs and A-MSDUs associated with AC(s) that are specified in the ACI high and ACI bitmap subfields, respectively.

[0119] A queue size value of 254 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is greater than 254 x SF octets. A queue size value of 255 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is an unspecified or unknown size. The queue size value of QoS data frames containing fragments may remain constant even if the amount of queued traffic changes as successive fragments are transmitted.

[0120] MAC service provides peer entities with the ability to exchange MSDUs. To support this service, a local MAC uses the underlying PHY-level service to transport the MSDUs to a peer MAC entity. Such asynchronous MSDU transport is performed on a connectionless basis.

[0121] FIG. 7 illustrates an example format of a PPDU. As shown, the PPDU may include a PHY preamble, a PHY header, a PSDU, and tail and padding bits.

[0122] The PSDU may include one or more MPDUs, such as a QoS data frame, an MMPDU, a MAC control frame, or a QoS null frame. In the case of an MPDU carrying a QoS data frame, the frame body of the MPDU may include a MSDU or an A-MSDU.

[0123] By default, MSDU transport is on a best-effort basis. That is, there is no guarantee that a transmitted MSDU will be delivered successfully. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis.

[0124] A STA may differentiate MSDU delivery according to designated traffic category (TC) or traffic stream (TS) of individual MSDUs. The MAC sublayer entities determine a user priority (UP) for an MSDU based on a 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, with 1 being the lowest value, 7 the highest value, and 0 falling between 2 and 3.

[0125] An MSDU with a particular UP is said to belong to a traffic category with that UP. The UP may be provided with each MSDU at the medium access control service access point (MAC SAP) directly in an UP parameter. An A-MPDU may include MPDUs with different TID values.

[0126] A STA may deliver buffer status reports (BSRs) to assist an AP in allocating UL MU resources. The STA may either implicitly deliver BSRs in the QoS control field or BSR control subfield of any frame transmitted to the AP (unsolicited BSR) or explicitly deliver BSRs in a frame sent to the AP in response to a BSRP Trigger frame (solicited BSR).

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

[0128] A STA may report buffer status to the AP, in the QoS control field, of transmitted QoS null frames and QoS data frames and, in the BSR control subfield (if present), of transmitted QoS null frames, QoS data frames, and management frames as defined below.

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

[0130] The STA may report buffer status in the BSR control subfield of transmitted frames if the AP has indicated its support for receiving the BSR control subfield.

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

[0132] A HE STA may report the queue size for ACs indicated by the ACI bitmap subfield in the queue size all subfield of the BSR control subfield. The STA may set the queue size all subfield to 255 to indicate an unknown / unspecified BSR for those ACs.

[0133] A multi-link device (MLD) is an entity capable of managing communication over multiple links. The MLD may be a logical entity and may have more than one affiliated station (STA). An MLD may be an access point MLD (AP MLD) where a STA affiliated with the MLD is an AP STA (or an AP). An MLD may be a non-access point MLD (non-AP MLD) where a STA affiliated with the MLD is a non-AP STA (or an STA).

[0134] Communication across different frequency bands / channels may occur simultaneously, or not, depending on the capabilities of both the communicating AP MLD and non-AP MLD.

[0135] An MLD may have a single MAC service access point (MAC-SAP) to the LLC layer, which includes a MAC data service. The MLD may support multiple MAC sublayers, coordinated by a sublayer management entity (SME). Each AP STA (or non-AP STA) affiliated with an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0136] The SME is responsible for coordinating the MAC sublayer management entities (MLMEs) of the affiliated STAs of the MLD to maintain a single robust security network association (RSNA) key management entity as well as a single IEEE 802. IX Authenticator or Supplicant for multi-link operation (MLO).

[0137] Multi-link operation (MLO) procedures allow a pair of MLDs to discover, synchronize, (de)authenticate, (re)associate, disassociate, and manage resources with each other on any common bands or channels that are supported by both MLDs. The Authenticator and the MAC- SAP of an AP MLD may be identified by the same AP MLD MAC address. The Supplicant and the MAC-SAP of a non-AP MLD may be identified by the same non-AP MLD MAC address.

[0138] FIG. 8 illustrates an example multi-AP network 800. Example multi-AP network 800 may be a multi-AP network in accordance with the Wi-Fi Alliance standard specification for multi-AP networks. As shown in FIG. 8, multi-AP network 800 may include a multi-AP controller 802 and a plurality of 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.

[0139] Multi-AP controller 802 may be a logical entity that implements logic for controlling the APs in multi-AP network 800. Multi-AP controller 802 may receive capability information and measurements from the APs and may trigger AP control commands and operations on the APs. Multi-AP controller 802 may also provide onboarding functionality to onboard and provision APs onto multi-AP network 800.

[0140] Multi-AP group 804, multi-AP group 806, and multi-AP group 808 may each include a plurality of APs. APs in a multi-AP group are in communication range of each other. However, the APs in a multi-AP group are not required to have the same primary channel. As used herein, the primary channel for an AP refers to a default channel that the AP monitors for management frames and / or uses to transmit beacon frames. For a STA associated with an AP, the primary channel refers to the primary channel of the AP, which is advertised through the AP’s beacon frames.

[0141] In one approach, one of the APs in a multi-AP group may be designated as a master AP. The designation of the master AP may be done by multi-AP controller 802 or by the APs of the multi-AP group. The master AP of a multi-AP group may be fixed or may change over time between the APs of the multi-AP group. An AP that is not the master AP of the multi-AP group is known as a slave AP.

[0142] In one approach, a multi-AP group or an AP candidate set is a set of APs that can initiate or participate in multi-AP coordination. An AP in a multi-AP group can participate as a slave AP in multi-AP coordination initiated by a master AP in the same multi-AP group. At least one AP in a multi-AP group shall be capable of being a master AP.

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

[0144] Multi-AP group coordination may be enabled by the 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 may control time and / or frequency sharing in a TXOP. For example, when one of the APs (e.g., the master AP) in the multi-AP group obtains a TXOP, the multi-AP controller and / or the master AP may control how time / frequency resources of the TXOP are to be shared with other APs of the multi-AP group. In an implementation, the AP of the multi-AP group that obtains a TXOP becomes the master AP of the multi-AP group. The master AP may then sharea portion of its obtained TXOP (which may be the entire TXOP) with one or more other APs of the multi -AP group.

[0145] Multi-AP operation may be enabled by at least two APs that support multi-AP coordination within one or more multi-AP groups. The APs may support multi-AP transmission schemes in a multi-AP network. A master AP may coordinate with slave AP(s) to enable multi-AP coordination and to support a multi-AP transmission. Slave AP(s) may participate in a multi-AP transmission. The master AP may select the slave AP(s) which are suitable for the multi-AP transmission. Slave APs may be candidates for a multi-AP transmission before being designated by the master AP.

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

[0147] Coordinated OFDMA (COFDMA) and coordinated TDMA (CTDMA) may be categorized as coordinated TXOP, in which frequency or time resources of a TXOP may be used to coordinate the interference. Coordinated spatial reuse (CSR) may provide reuse of spatial domain of neighboring BSSs by adjusting the transmit powers of coordinated APs. Coordinated beamforming (CBF) may provide dedicated null steering with spatial radiation based on channel state information (CSI) feedback from coordinated APs with the aid of multiple antennas to suppress the interference. JT / JR may use distributed MIMO precoding or detection, via shared CSI, for data streams among multiple APs.

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

[0149] APs 902-1 and 902-2 may belong to the same ESS as described above in FIG. 1. In such a case, APs 902-1 and 902-2 may be connected by a DS to support ESS features. In addition, as part of a coordinated AP set, APs 902-1 and 902-2 may be connected by a backhaul. The backhaul is used to share information quickly between APs to support coordinated transmissions. The shared information may be channel state information or data to be sent to associated STAs. The backhaul may be a wired backhaul or a wireless backhaul. A wired backhaul is preferred for high-capacity information transfer without burdening the main radios of the APs. However, a wired backhaul may require a higher deployment cost and may place greater constraints on AP placement. A wireless backhaul is preferred for its lowerdeployment cost and flexibility regarding AP placement. However, because a wireless backhaul relies on the main radios of the APs to transfer information, the APs cannot transmit or receive any data while the wireless backhaul is being used.

[0150] Typically, one of APs 902-1 and 902-2 may act as a Master AP and the other as a Slave AP. The Master AP is the AP that is the owner of the TXOP. The Master AP shares frequency resources during the TXOP with the Slave AP. When there are more than two APs in the coordinated set, a Master AP may share its TXOP with only a subset of the coordinated AP set. The role of the Master AP may change over time. For example, the Master AP role may be assigned to a specific AP for a duration of time. Similarly, the Slave AP role may be chosen by the Master AP dynamically or can be pre-assigned for a duration of time.

[0151] Depending on the capability of APs in a coordinated AP set, the APs may only do certain type of coordinated transmissions. For example, in FIG. 9, if AP 902-1 supports JT and CSR while AP 902-2 supports CSR and CBF, both APs may only perform CSR as a coordinated transmission scheme. An AP may also prefer to perform single AP transmissions for a duration of time if the benefit of coordinated transmission does not outweigh some disadvantages with coordinated transmission such as reduced flexibility and increased computational power required.

[0152] CSR is one type of multi-AP coordination that may be supported by AP 901-1 and AP 902-2 as shown in FIG. 9. Spatial reuse using CSR can be more stable than non-AP coordinated spatial reuse schemes such as overlapping basic service set (OBSS) packet detect (PD)-based SR and PSR-based SR. For example, in an example network 900, APs 902-1 and 902-2 may perform a joint sounding operation in order to measure path loss (PL) on paths of network 900. For example, the joint sounding operation may result in 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 may then be shared between APs 902-1 and 902-2 (e.g., using the backhaul) to allow for simultaneous transmissions by APs 902-1 and 902-2 to their associated STAs 904- 1 and 904-2 respectively. Specifically, one of APs 902-1 and 902-2 obtains a TXOP to become the Master AP. The Master AP may then send a CSR announcement frame to the other AP(s). In an embodiment, the Master AP may perform a polling operation, before sending the CSR announcement frame, to poll Slave APs regarding packet availability for transmission. If at least one Slave AP responds indicating packet availability, the Master AP may proceed with sending the CSR announcement frame. In the CSR announcement, the Master AP may limit the transmit power of a Slave AP in order to protect its own transmission to its target STA. The Slave AP may similarly protect its own transmission to its target STA by choosing amodulation scheme that enables a high enough Signal to Interference Ratio (SIR) margin to support the interference due to the transmission of the Master AP to its target STA.

[0153] FIG. 10 illustrates an example 1000 of a multi -AP operation procedure. In example 1000, the multi-AP operation procedure is illustrated with respect to a multi -AP network that includes APs 1002 and 1004 and STAs 1006 and 1008. In an example, APs 1002 and 1004 may form a multi-AP group. AP 1002 may be the master AP and AP 1004 may be a slave AP of the multi-AP group. For example, AP 1002 may obtain a TXOP making it the master AP of the multi-AP group. Alternatively, AP 1002 may be designated as the master AP by a multi- AP controller.

[0154] As shown in FIG. 10, the multi-AP operation procedure may include a series of phases in time, each of which may contain a plurality of frame exchanges within the multi-AP network. Specifically, the multi-AP operation procedure may include a multi-AP selection phase 1010, a multi-AP data sharing phase 1012, a multi-AP sounding phase 1014, and a multi- AP data transmission phase 1016.

[0155] A multi-AP network may carry out a multi-AP operation based on a specific multi-AP transmission scheme. The multi-AP transmission scheme may be chosen by the master AP based on the capabilities of the slave APs in a multi-AP group. Prior to a multi-AP operation, a slave AP may inform the master AP of capability information related to the slave AP, including the capabilities of supporting one or more multi-AP transmission schemes. The slave AP may also inform the master AP of BSS information of the BSS of the slave AP and of link quality information for STAs associated with the slave AP. The master AP may receive information related to all available slave APs. The information related to slave APs may include capability information, BSS information, and link quality information. Based on the information provided by available slave APs, the master AP may determine during a multi-AP selection phase the slave APs to be designated for a multi-AP transmission and a specific multi- AP transmission scheme to be used during the multi-AP transmission.

[0156] Multi-AP selection phase 1010 may include procedures for soliciting, selecting, or designating slave AP(s) for a multi-AP group by a master AP. As seen in FIG. 10, the multi- AP selection phase may include transmissions of frame 1018 from AP 1002 and frame 1020 from AP 1004. AP 1002 may transmit frame 1018 to solicit information regarding the buffer status of AP 1004. In response, AP 1004 may transmit frame 1020 to inform AP 1002 of its and its associated STAs buffer status and / or whether it intends to join multi-AP operation. Multi-AP selection phase 1010 may also be used to exchange information related to multi-AP operation, including BSS information of APs and link quality information between each AP and its associated STAs, for example. The BSS information of an AP may include a BSS IDof the BSS of the AP, identifiers and / or capabilities of STAs belonging to the BSS, information regarding sounding capabilities of the STAs, information regarding MIMO capabilities of the AP, etc. Link quality information may include received signal strength indicator (RS SI), signal-to-noise ratio (SNR), signal-to-interference-plus-noise-ratio (SINR), channel state information (CSI), channel quality indicator (CQI).

[0157] Multi-AP data sharing phase 1012 may include procedures for sharing data frames to be transmitted by APs to associated STAs among the master AP and selected slave AP(s) via direct connections between APs. Phase 1012 may be optional for some multi -AP data transmission schemes. For example, phase 1012 may be required for JT / JR as data frames may be exchanged between APs before or after multi-AP data transmission phase 1016.

[0158] Multi-AP data sharing phase 1012 may be performed using a wired backhaul, an in- channel wireless backhaul, or an off-channel wireless backhaul. In some cases, multi-AP data sharing phase 1012 may be performed over an in-channel backhaul, e.g., using the same wireless channel used to transmit / receive data to / from STAs. For example, as shown in FIG. 10, in phase 1012, AP 1002 may transmit a frame 1022, which may be received by AP 1004. Frame 1022 may include MPDUs that AP 1002 wishes to transmit to associated STAs using a multi-AP operation. Similarly, AP 1004 may transmit a frame 1024, which may be received by AP 1002. Frame 1024 may include MPDUs that AP 1004 wishes to transmit to associated STAs using a multi-AP operation.

[0159] Multi-AP sounding phase 1014 may include procedures for multi-AP channel sounding, including channel estimation and feedback of channel estimates among the master AP, candidate slave AP(s), and associated STAs. Phase 1014 may be optional for some multi- AP transmission schemes, such as COFDMA, CDTMA, and CSR. For example, phase 1014 may be performed by the master AP to aid in resource unit allocation when orchestrating a COFDMA transmission.

[0160] Multi-AP data transmission phase 1016 may include exchange of data frames between the master AP, slave AP(s), and their associated STAs based on multi-AP transmission scheme(s) determined by the master AP. Depending on the multi-AP transmission scheme(s) to be used, phase 1016 may include optional synchronization between APs of the multi-AP group, before exchange of data frames between APs and STAs within the multi-AP group.

[0161] The order of phases 1010, 1012, 1014 and 1016 may be different than shown in FIG. 10. For example, in COFDMA, phase 1016 may occur immediately after phase 1010, whereas, in JT / JR, phase 1012 may occur after phase 1010. Further, as mentioned above, some phases may be optional and may or may not be present. For example, phase 1014 may not be required for COFDMA but may be required for JT / JR.

[0162] FIG. 11 illustrates an example 1100 of a multi-AP sounding phase. Multi-AP sounding phase 1100 may be an example of multi-AP sounding phase 1014. As shown in FIG. 11, example 1100 may include a master AP 1102 and a slave AP 1104 of a multi-AP group. Example 1100 may further include a STA 1106 associated with AP 1102 and a STA 1108 associated with AP 1104.

[0163] As shown in FIG. 11, multi-AP sounding phase 1100 may include frame exchanges to allow AP 1102 (the master AP) to acquire channel state information (CSI) of channels in the multi-AP group. In an implementation, phase 1100 may include a first subphase 1110 and a second subphase 1112.

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

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

[0166] FIG. 12 illustrates an example 1200 of a multi-AP downlink data transmission phase. Multi-AP downlink data transmission phase 1200 may be an example of multi-AP data transmission phase 1016. As shown in FIG. 12, example 1200 may include a master AP 1202 and a slave AP 1204 of a multi-AP group. Example 1200 may further include a STA 1206 associated with AP 1202, and a STA 1208 associated with AP 1204.

[0167] As shown in FIG. 12, multi-AP downlink data transmission phase 1200 may include frame exchanges to enable master AP 1202 to coordinate with slave AP 1204 to perform specific multi-AP transmission schemes with their associated STAs 1206 and 1208, respectively. The multi-AP transmission schemes may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0168] As shown in FIG. 12, master AP 1202 may begin phase 1200 by transmitting a frame 1210 to AP 1204. Frame 1210 may include information related to AP 1204 (e.g., an identifier of AP 1204), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to a resource unit (RU) for use by AP 1204 to acknowledge frame 1210. Frame 1210 may comprise a control frame. For example, frame 1210 may comprise a multi-AP trigger frame.

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

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

[0171] FIG. 13 illustrates an example 1300 of a multi-AP uplink data transmission phase. Multi-AP uplink data transmission phase 1300 may be an example of multi-AP data transmission phase 1016. As shown in FIG. 13, example 1300 may include a master AP 1302 and a slave AP 1304 of a multi-AP group. Example 1300 may further include STAs 1306 and 1308 associated with AP 1302, and a STA 1310 associated with AP 1304.

[0172] As shown in FIG. 13, multi-AP uplink data transmission phase 1300 may include frame exchanges to enable master AP 1302 to coordinate with slave AP 1304 to perform specific multi-AP transmission schemes with STAs 1306, 1308, and 1310. The multi-AP transmission schemes may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0173] As shown in FIG. 13, master AP 1302 may begin phase 1300 by transmitting a frame 1312 to AP 1304. Frame 1312 may include information related to AP 1304 (e.g., an identifier of AP 1304), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to an RU for use by AP 1304 to acknowledge frame 1312. Frame 1312 may comprise a control frame. For example, frame 1312 may comprise a multi-AP trigger frame.

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

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

[0176] FIG. 14 illustrates Enhanced Distributed Channel Access (EDCA) and Coordinated Time Division Multiple Access (CTDMA). In CTDMA, an AP (generally referred to as a master AP or a sharing AP) may share a portion of its TXOP with one or more APs (generally referred to as slave APs or shared APs). Specifically, the sharing AP may assign / allocate each of the one or more APs a respective time period within the TXOP of the sharing AP. A shared AP may use its allocated time period to communicate with one or more STA. CTDMA is illustrated in FIG. 14 as a multi -AP channel access scheme, compared with Enhanced Distributed Channel Access (EDCA). As shown in FIG. 14, in EDCA, channel access by multiple APs (e.g., API, AP2) may occur in consecutive time periods (e.g., TXOPs), where each AP has its own TXOP. During a given channel access, the channel in its entirety may be used by a single AP for the duration of the TXOP. In contrast, in CTDMA, access by multiple APs may take place in a same TXOP over consecutive time periods. For example, as shown in FIG. 14, a TXOP may be divided into two non-overlapping time periods, each assigned to a respective AP of the multiple APs. The multiple APs may transmit in a coordinated manner in the same TXOP consecutively. In an example, as shown in FIG. 14, a master / sharing AP (e.g., API) may use itself a first portion of a first TXOP and may share a second portion of the first first TXOP with a slave / shared AP (e.g., AP2). In another example, the master / shared AP (e.g., API) may share a first portion of a second TXOP with a slave / shared AP (e.g., AP2) and may use itself a second portion of the second TXOP.

[0177] Triggered TXOP sharing (TXS) is a technique introduced in the IEEE 802.11be standard amendment. TXS allows an AP to allocate a time duration within an obtained TXOP to a STA for transmitting one or more non-trigger-based (non-TB) PPDUs. For the TXS procedure, the AP may transmit a multi-user request-to-send (MU-RTS) trigger frame with a triggered TXOP sharing mode subfield set to a non-zero value. The MU-RTS trigger frame is a trigger frame for triggering CTS frame(s) from multiple users. An MU-RTS trigger frame with the triggered TXOP sharing mode subfield set to a non-zero value is called an MU-RTS TXS trigger (MRTT) frame.

[0178] In an example, when the triggered TXOP sharing mode subfield is set to 1, the STA may transmit the one or more non-TB PPDUs to the AP during the allocated time duration. In an example, when the triggered TXOP sharing mode subfield is set to 2, the STA may transmit the one or more non-TB PPDUs to the AP or a peer STA during the allocated time duration. The peer STA may be a STA with a connection for peer-to-peer (P2P) communication or direct communication with the STA. In an example, the direct wireless link is established according to the tunneled direct link setup (TDLS) protocol.

[0179] FIG. 15 illustrates an example of a MRTT frame 1500 which may be used in a TXS procedure. As shown in FIG. 15, example MRTT frame 1500 may comprise a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a common info field, a user info list field, a padding field, and / or frame check sequence (FCS) field.

[0180] In an example, the common info field may be a high-efficiency (HE) variant common info field or an extremely high throughput (EHT) variant common info field. An EHT variant common info field may comprise, as shown in FIG. 15, one or more of the following subfields: trigger type, UL length, more TF, CS required, UL BW, GI and HE / EHT-LTF Type / Triggered TXOP sharing mode, number of HE / EHT-LTF symbols, LDPC extra symbol segment, AP Tx Power, Pre-FEC padding factor, PE disambiguity, UL spatial reuse, HE / EHT Pl 60, special user info field flag, EHT reserved, reserved, or trigger dependent common info.

[0181] The trigger type subfield indicates that frame 1500 is an MRTT frame.

[0182] The GI and HE / EHT-LTF Type / Triggered TXOP sharing mode subfield may include a triggered TXOP sharing mode subfield. In an example, the triggered TXOP sharing mode subfield may be set to a non-zero value (e.g., 1 or 2). In an example, the triggered TXOP sharing mode subfield may be set to 1. As such, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID 12 subfield of a user info field (of the user info list field) may transmit one or more non-TB PPDUs to the AP during a time indicated in the allocation duration subfield of the user info field. In another example, the triggered TXOP sharing mode subfield may be set to 2. As such, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID 12 subfield of a user info field (of the user info list field) may transmit one or more non-TB PPDUs to the AP or to a peer STA during the time indicated by the allocation duration subfield of the user info field. In an example, the peer STA may be a STA with a connection for P2P communication or direct communication with the STA.

[0183] The user info list field may include one or more user info fields. In an example, an EHT variant user info field may comprise, as shown in FIG. 15, one or more of the following subfields: AID12, RU allocation, allocation duration, reserved, or PS160.

[0184] The AID12 subfield may indicate an association identifier (AID) of a STA that may use a time indicated by the allocation duration subfield.

[0185] The RU allocation subfield may indicate the location and size of the RU allocated for a STA indicated by the AID12 subfield.

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

[0187] FIG. 16 illustrates an example 1600 of a TXS procedure (Mode =1). As shown in FIG.16, the TXS procedure may begin by an AP 1610 transmitting an MRTT frame 1620 to a STA 1611. MRTT frame 1620 may allocate a portion of a TXOP obtained by AP 1610 to STA 1611 and may indicate a TXS mode equal to 1. STA 1611 receiving MRTT frame 1620 may use the allocated time to transmit one or more non-TB PPDUs to AP 1610. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

[0188] In an example, MRTT frame 1620 may comprise a triggered TXOP sharing mode subfield that indicates the TXS mode and / or subfield that indicates a first time period corresponding to the allocated time. In an example, the first time period may be set to a value of X microseconds (us).

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

[0190] FIG. 17 illustrates an example 1700 of a TXS procedure (Mode =2). As shown in FIG.17, the TXS procedure may begin by an AP 1710 transmitting an MRTT frame 1720 to a STA 1711. MRTT frame 1720 may allocate a portion of a TXOP obtained by AP 1710 to STA 1711 and may indicate a TXS mode equal to 2. STA 1711 receiving MRTT frame 1720 may use the allocated time to transmit one or more non-TB PPDUs to STA 1712. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

[0191] In an example, MRTT frame 1720 may comprise a triggered TXOP sharing mode subfield that indicates the TXS mode and / or subfield that indicates a first time period corresponding to the allocated time. In an example, the first time period may be set to a value of Y microseconds (us).

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

[0193] In CTDMA, one approach for TXOP sharing may be achieved via the TXS procedure described above. The TXS procedure may be used to allow a sharing AP, which obtains a TXOP and is the TXOP owner, to allocate a time duration within its obtained TXOP to a shared AP for downlink and / or uplink transmission between the shared AP and its associated STAs.

[0194] FIG. 18 illustrates an example 1800 of an existing CTDMA procedure. As shown in FIG. 18, example 1800 may include APs 1802 and 1804 and STAs 1806 and 1808. AP 1802 and AP 1804 may be members of a multi -AP group. AP 1802 may be a sharing / master AP of the multi-AP group. AP 1804 may be a 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 communication range of each other.

[0195] In an implementation, an AP, such as APs 1802 and 1804, or a STA, such as STAs 1806 and 1808, may 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 different BSS than the BSS to which the STA / AP belongs (also referred to as inter-BSS or OBSS)) or PPDUs that cannot be classified as intra-BSS or inter-BSS.

[0196] For a STA to access the channel using EDC A, both NAVs must be non-zero. The basic NAV of the STA is not updated by transmissions from the AP with which the STA is associated so that if the basic NAV of the STA is nonzero and the STA receives, from the AP, a Trigger frame with the CS Required subfield equal to 1, the STA does not respond. The STA does not consider the intra-BSS NAV in determining whether to respond to a Trigger frame sent by the AP with which the STA is associated. The STA considers the basic NAV in determining whether to respond to a Trigger frame sent by the AP with which the STA is associated.

[0197] As shown in FIG. 18, the procedure may begin with AP 1802 transmitting an MRTT frame 1812 after obtaining a TXOP 1810. In an implementation, MRTT frame 1812 may comprise an allocation for AP 1804. An allocation of MRTT frame 1812 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 1800, MRTT frame 1812 may comprise an allocation for AP 1804. The allocation may comprise a first duration (denoted tl in FIG. 18) of the TXOP allocated to AP 1804. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 1812. In an implementation, a duration field of MRTT frame 1812 may indicate a second duration (denoted t2 in FIG. 18). The second duration indicated in the duration field of MRTT frame 1812 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field ofMRTT frame 1812 to the second duration allows AP 1802 to protect a CTS frame and / or trigger frame of the shared AP.

[0198] In example 1800, on receiving MRTT frame 1812, STA 1806 may set its intra-BSS NAV (not shown in FIG. 18) to the second duration t2 indicated in MRTT frame 1812. On receiving MRTT frame 1812, STA 1808 may set its basic NAV (not shown in FIG. 18) to the second duration t2. On receiving MRTT frame 1812, AP 1804 may determine that AP 1802 has shared TXOP 1810 with AP 1804 for the duration tl. AP 1804 may transmit a CTS frame 1814 to AP 1802, in response to MRTT frame 1812.

[0199] On receiving CTS frame 1814, AP 1802 may set its intra-BSS NAV (not shown in FIG. 18) for the remaining duration of t2. After transmitting CTS frame 1814, AP 1804 may use the TXOP for the remaining duration of tl. In an example, AP 1804 may transmit a downlink frame (not shown in FIG. 18) to STA 1808. In another example, AP 1804 may trigger STA 1808 to transmit an uplink frame to AP 1804.

[0200] In example 1800, after transmitting CTS frame 1814, AP 1804 may transmit a trigger frame 1816 to STA 1808 to trigger an uplink transmission from STA 1808. In an implementation, a duration field of trigger frame 1816 may indicate a third duration t3. On receiving trigger frame 1816, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 1816. Specifically, in example 1800, on receiving trigger frame 1816, AP 1802 may set its basic NAV (not shown in FIG. 18) to the third duration indicated in trigger frame 1816. Similarly, on receiving trigger frame 1816, STA 1806 may set its basic NAV (as shown by NAV 1818 in FIG. 18) to the third duration indicated in trigger frame 1816.

[0201] In an implementation, on receiving trigger frame 1816 and seeing its own address in the RA field of trigger frame 1816, STA 1808 may determine that it is to transmit an uplink frame to AP 1804. In an implementation, with trigger frame 1816 transmitted by AP 1804 with which STA 1808 is associated, STA 1808 may set its intra-BSS NAV (not shown in FIG. 18) to the third duration indicated in trigger frame 1816. In another implementation, STA 1808 may not set its intra-BSS NAV. Subsequently, STA 1808 may transmit a data frame 1820 to AP 1804. Data frame 1820 may include a duration field that indicates the remaining duration of the third duration. In response to data frame 1820, AP 1804 may transmit a BA frame 1822 to STA 1808.

[0202] In an example, after transmitting BA frame 1822 to STA 1808, AP 1804 may not have further uplink and / or downlink transmissions to perform within 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 a frame 1824 indicating a return by AP 1804 of the first duration to AP 1802 (or indicating truncation by AP 1804 of the first duration). In an example, frame 1824 may be a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 1804. In an example, the CF-end frame may be a broadcast frame.

[0203] In example 1800, on receiving CF-end frame 1824, AP 1802 may reset its basic NAV to zero before the end of the third duration. AP 1802 may further determine that AP 1804 has returned the first duration to AP 1802. With the return of the first duration to AP 1802, AP 1802 (which is the owner of the TXOP) returns to being the holder of the TXOP. Similarly, on receiving CF-end frame 1824, STA 1806 may reset its basic NAV before the end of the third duration (as shown in FIG. 18). On receiving CF-end frame 1834, STA 1808 may reset its intra-BSS NAV before the end of the third duration.

[0204] In an example, with the return of the first duration to AP 1802, AP 1802 may initiate uplink and / or downlink transmissions for the remaining duration of TXOP 1810 (which includes the remainder of the first duration). In an example, AP 1802 may transmit a frame 1826 to STA 1806 to initiate an uplink transmission. In an example, frame 1826 may be a trigger frame. On receiving frame 1826, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 1804 may set its basic NAV (not shown in FIG. 18) to a duration indicated in frame 1826. Similarly, STA 1808 may set its basic NAV (not shown in FIG. 18) to the duration indicated in frame 1826.

[0205] On receiving frame 1826 and seeing its own address in the RA field of frame 1826, STA 1806 may determine that it is to transmit an uplink frame to AP 1802. STA 1806 may set its intra-BSS NAV (not shown in FIG. 18) to the duration indicated in frame 1826. In another implementation, STA 1806 may not set its intra-BSS NAV. In response to frame 1826, STA 1806 may transmit a frame 1828 to AP 1802. In an example, frame 1828 may be a data frame. In an implementation, frame 1828 may include a duration field that indicates the remainder of the duration indicated frame 1826. In an example, after receiving frame 1828, AP 1802 may transmit a BA frame (not shown in FIG. 18) to STA 1806 and may continue uplink and / or downlink transmissions within TXOP 1810. In another example, AP 1802 may share a remaining portion of TXOP 1810 with another shared AP.

[0206] FIG. 19 illustrates another example 1900 of an existing CTDMA procedure. As shown in FIG. 19, example 1900 may include APs 1902 and 1904 and STAs 1906 and 1908. AP 1902 and AP 1904 may be members of a multi -AP group. AP 1902 may be a sharing / master AP of the multi-AP group. AP 1904 may be a 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 communication range of each other. It is further assumed that STA 1906 is outside the communication range of AP 1904 but is within the communication range of AP 1902 and STA 1908.

[0207] As shown in FIG. 19, the procedure may begin with AP 1902 transmitting an MRTT frame 1912 after obtaining a TXOP 1910. In an implementation, MRTT frame 1912 may comprise an allocation for AP 1904. An allocation of MRTT frame 1912 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 1900, MRTT frame 1912 may comprise an allocation for AP 1904. The allocation may comprise a first duration (denoted tl in FIG. 19) of the TXOP allocated to AP 1904. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 1912. In an implementation, a duration field of MRTT frame 1912 may indicate a second duration (denoted t2 in FIG. 19). The second duration indicated in the duration field of MRTT frame 1912 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 1912 to the second duration allows AP 1902 to protect a CTS frame and / or trigger frame of the shared AP.

[0208] In example 1900, on receiving MRTT frame 1912, STA 1906 may set its intra-BSS NAV (not shown in FIG. 19) to the second duration t2 indicated in MRTT frame 1912. On receiving MRTT frame 1912, STA 1908 may set its basic NAV (not shown in FIG. 19) to the second duration t2. On receiving MRTT frame 1912, AP 1904 may determine that AP 1902 has shared TXOP 1910 with AP 1904 for the duration tl. AP 1904 may transmit a CTS frame 1914 to AP 1902, in response to MRTT frame 1912.

[0209] On receiving CTS frame 1914, AP 1902 may set its intra-BSS NAV (not shown in FIG. 19) for the remaining duration of t2. After transmitting CTS frame 1914, AP 1904 may use the TXOP for the remaining duration of tl. In an example, AP 1904 may transmit a downlink frame (not shown in FIG. 19) to STA 1908. In another example, AP 1904 may trigger STA 1908 to transmit an uplink frame to AP 1904.

[0210] In example 1900, after transmitting CTS frame 1914, AP 1904 may transmit a trigger frame 1916 to STA 1908 to trigger an uplink transmission from STA 1908. In an implementation, a duration field of trigger frame 1916 may indicate a third duration t3. On receiving trigger frame 1916, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 1916. Specifically, in example 1900, on receiving triggerframe 1916, AP 1902 may set its basic NAV (not shown in FIG. 19) to the third duration indicated in trigger frame 1916. However, being outside the communication range of AP 1904, STA 1906 may not receive trigger frame 1916 and may not set its basic NAV.

[0211] In an implementation, on receiving trigger frame 1916 and seeing its own address in the RA field of trigger frame 1916, STA 1908 may determine that it is to transmit an uplink frame to AP 1904. In an implementation, with trigger frame 1916 transmitted by AP 1904 with which STA 1908 is associated, STA 1908 may set its intra-BSS NAV (not shown in FIG. 19) to the third duration indicated in trigger frame 1916. In another implementation, STA 1908 may not set its intra-BSS NAV. Subsequently, STA 1908 may transmit a data frame 1918 to AP 1904. Data frame 1918 may include a duration field that indicates the remaining duration of the third duration. On receiving data frame 1918, STA 1906 may read the duration field of data frame 1918 and may set its basic NAV (as shown by NAV 1920 in FIG. 19) for the remaining duration of third duration. In response to data frame 1918, AP 1904 may transmit a BA frame 1922 to STA 1908.

[0212] In an example, after transmitting BA frame 1922 to STA 1908, AP 1904 may not have further uplink and / or downlink transmissions to perform within 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 a frame 1924 indicating a return by AP 1904 of the first duration to AP 1902 (or indicating truncation by AP 1904 of the first duration). In an example, frame 1924 may be a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 1904. In an example, the CF-end frame may be a broadcast frame.

[0213] In example 1900, on receiving CF-end frame 1924, AP 1902 may reset its basic NAV to zero before the end of the third duration. AP 1902 may further determine that AP 1904 has returned the first duration to AP 1902. With the return of the first duration to AP 1902, AP 1902 (which is the owner of the TXOP) returns to being the holder of the TXOP. Being outside the communication range of AP 1904, STA 1906 may not receive CF-end frame 1924 and may not reset its basic NAV, which was set upon receiving data frame 1918 transmitted by STA 1908. On receiving CF-end frame 1924, STA 1908 may reset its intra-BSS NAV before the end of the third duration.

[0214] In an example, with the return of the first duration to AP 1902, AP 1902 may initiate uplink and / or downlink transmissions for the remaining duration of TXOP 1910 (which includes the remainder of the first duration). In an example, AP 1902 may transmit a frame 1926 to STA 1906 to initiate an uplink transmission. In an example, frame 1926 may be atrigger frame. On receiving frame 1926, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 1904 may set its basic NAV (not shown in FIG. 19) to a duration indicated in frame 1926. Similarly, STA 1908 may set its basic NAV (not shown in FIG. 19) to the duration indicated in frame 1926.

[0215] In example 1900, having set its basic NAV for the remainder of the third duration on receiving data frame 1918, despite receiving frame 1926 and seeing its own address in the RA field of frame 1926, STA 1906 cannot respond to frame 1926 transmitted by AP 1902 according to the existing IEEE 802.11 standard. In an implementation, STA 1906 may set its intra-BSS NAV (not shown in FIG. 19) to the duration indicated in frame 1926. In another implementation, STA 1906 may not set its intra-BSS NAV.

[0216] Accordingly, 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 the TXOP to AP 1902 before the end of the first duration (tl) by transmitting CF-end frame 1924, STA 1906 associated with AP 1902 may be prevented, for the remaining duration of the first duration, from using the channel to transmit uplink frames to AP 1902. This may result in channel access unfairness between STAs, associated with AP 1902, that are within the communication range of AP 1902 and STAs, associated with AP 1902, that are outside the communication range of AP 1902.

[0217] FIG. 20 illustrates another example 2000 of a CTDMA procedure. As shown in FIG. 20, example 2000 may include APs 2002 and 2004 and STAs 2006 and 2008. AP 2002 and AP 2004 may be members of a multi-AP group. AP 2002 may be a sharing / 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 communication range of each other. It is further assumed that STA 2006 is outside the communication range of AP 2004 but is within the communication range of AP 2002 and STA 2008.

[0218] As shown in FIG. 20, the procedure may begin with AP 2002 transmitting an MRTT frame 2012 after obtaining a TXOP 2010. In an implementation, MRTT frame 2012 may comprise an allocation for AP 2004. An allocation of MRTT frame 2012 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 2000, MRTT frame 2012 may comprise an allocation for AP 2004. The allocation may comprise a first duration (denoted tl in FIG. 20) of the TXOP allocated to AP 2004. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 2012. In an implementation, a duration field of MRTT frame 2012 may indicate a second duration (denoted t2 in FIG. 20). The second duration indicated in the duration fieldof MRTT frame 2012 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 2012 to the second duration allows AP 2002 to protect a CTS frame and / or trigger frame of the shared AP.

[0219] In example 2000, on receiving MRTT frame 2012, STA 2006 may set its intra-BSS NAV (not shown in FIG. 20) to the second duration t2 indicated in MRTT frame 2012. On receiving MRTT frame 2012, STA 2008 may set its basic NAV (not shown in FIG. 20) to the second duration t2. On receiving MRTT frame 2012, AP 2004 may determine that AP 2002 has shared TXOP 2010 with AP 2004 for the duration tl . AP 2004 may transmit a CTS frame 2014 to AP 2002, in response to MRTT frame 2012.

[0220] On receiving CTS frame 2014, AP 2002 may set its intra-BSS NAV (not shown in FIG. 20) for the remaining duration of t2. After transmitting CTS frame 2014, AP 2004 may use the TXOP for the remaining duration of tl. In an example, AP 2004 may transmit a downlink frame (not shown in FIG. 20) to STA 2008. In another example, AP 2004 may trigger STA 2008 to transmit an uplink frame to AP 2004.

[0221] In example 2000, after transmitting CTS frame 2014, AP 2004 may transmit a trigger frame 2016 to STA 2008 to trigger an uplink transmission from STA 2008. In an implementation, a duration field of trigger frame 2016 may indicate a third duration t3. On receiving trigger frame 2016, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 2016. Specifically, in example 2000, on receiving trigger frame 2016, AP 2002 may set its basic NAV (not shown in FIG. 20) to the third duration indicated in trigger frame 2016. However, being outside the communication range of AP 2004, STA 2006 may not receive trigger frame 2016 and may not set its basic NAV.

[0222] In an implementation, on receiving trigger frame 2016 and seeing its own address in the RA field of trigger frame 2016, STA 2008 may determine that it is to transmit an uplink frame to AP 2004. In an implementation, with trigger frame 2016 transmitted by AP 2004 with which STA 2008 is associated, STA 2008 may set its intra-BSS NAV (not shown in FIG. 20) to the third duration indicated in trigger frame 2016. In another implementation, STA 2008 may not set its intra-BSS NAV. Subsequently, STA 2008 may transmit a data frame 2018 to AP 2004. Data frame 2018 may include a duration field that indicates the remaining duration of the third duration. On receiving data frame 2018, STA 2006 may read the duration field of data frame 2018 and may set its basic NAV (as shown by NAV 2020 in FIG. 20) for theremaining duration of third duration. In response to data frame 2018, AP 2004 may transmit a BA frame 2022 to ST A 2008.

[0223] In an example, after transmitting BA frame 2022 to STA 2008, AP 2004 may not have further uplink and / or downlink transmissions to perform within 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 a frame 2024 indicating a return by AP 2004 of the first duration to AP 2002 (or indicating truncation by AP 2004 of the first duration). In an example, frame 2024 may be a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2004. In an example, the CF-end frame may be a broadcast frame.

[0224] In example 2000, on receiving CF-end frame 2024, AP 2002 may reset its basic NAV to zero before the end of the third duration. AP 2002 may further determine that AP 2004 has returned the first duration to AP 2002. With the return of the first duration to AP 2002, AP 2002 (which is the owner of the TXOP) returns to being the holder of the TXOP. Being outside the communication range of AP 2004, STA 2006 may not receive CF-end frame 2024 and may not reset its basic NAV, which was set upon receiving data frame 2018 transmitted by STA 2008. On receiving CF-end frame 2024, STA 2008 may reset its intra-BSS NAV before the end of the third duration.

[0225] Since AP 2002 owns the returned duration of the TXOP, AP 2002 may want to initiate uplink and / or downlink transmission for 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 reset their basic NAVs for the remaining duration of TXOP 2010 (e.g., due to not receiving CF-end frame 2024 transmitted by AP 2004) may not respond to a trigger frame from AP 2002. AP 2002 may further assess that these associated STAs may have set their basic NAVs based on receiving a frame from an associated STA of AP 2004. This frame would have been triggered by a trigger frame from AP 2004. As such, in an implementation, AP 2002 may transmit a frame to its associated STAs for resetting their basic NAVs, after AP 2002 receives a trigger frame from AP 2004 followed by a CF-end frame transmitted by AP 2004.

[0226] In example 2000, after receiving CF-end frame 2024, AP 2002 may transmit to STA 2006 a frame 2026 for resetting the basic NAV of STA 2006. In an implementation, frame 2026 may comprise a CF-end frame. In an implementation, the CF-end frame may comprise a transmitter address (TA) indicating an identifier of AP 2004 instead of an identifier of AP 2002. As such, when STA 2006 receives frame 2026, STA 2006 may determine that frame 2026 is an inter-BSS PPDU. STA 2006 may thus use frame 2026 to reset its basic NAV. In anotherimplementation, frame 2026 may comprise 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. In an implementation, the trigger frame, the MRTT frame, or the RTS frame may comprise a basic NAV reset indication. Even though the trigger frame, the MRTT frame, or the RTS frame is an intra-BSS PPDU, the presence of the basic NAV reset indication in the frame allows the STA to reset its basic NAV. In an implementation, the basic NAV reset indication may be provided in one of the reserved bits (e.g., B22, B26, B53 or B63) of the common info field of the trigger frame or the MRTT frame as illustrated in FIG. 5 and FIG. 15, respectively. In another implementation, the basic NAV reset indication may be provided in a frame control field of the RTS frame.

[0227] As shown in FIG. 20, on receiving frame 2026, STA 2006 may reset its basic NAV, before the end of the third duration (t3). After transmitting frame 2026, in an implementation, AP 2002 may transmit a frame 2028 to STA 2006 to initiate an uplink transmission. In an example, frame 2028 may be a trigger frame. On receiving frame 2028, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 2004 may set its basic NAV (not shown in FIG. 20) to a duration indicated in frame 2028. Similarly, STA 2008 may set its basic NAV (not shown in FIG. 20) to the duration indicated in frame 2028.

[0228] On receiving frame 2028 and seeing its own address in the RA field of frame 2028, STA 2006 may determine that it is to transmit an uplink frame to AP 2002. STA 2006 may set its intra-BSS NAV (not shown in FIG. 20) to the duration indicated in frame 2028. In another implementation, STA 2006 may not set its intra-BSS NAV. In response to frame 2028, STA 2006 may transmit a frame 2030 to AP 2002. In an example, frame 2030 may be a data frame. In an implementation, frame 2030 may include a duration field that indicates the remainder of the duration indicated frame 2028. In an example, after receiving frame 2030, AP 2002 may transmit a BA frame (not shown in FIG. 20) to STA 2006 and may continue uplink and / or downlink transmissions within TXOP 2010. In another example, AP 2002 may share a remaining portion of TXOP 2010 with another shared AP. As illustrated in example 2000, in case a shared AP has returned the TXOP to a sharing AP before the end of the shared TXOP, a STA outside the communication range of the shared AP has successfully reset its basic NAV, by receiving frame 2026, for successful uplink transmissions with its associated sharing AP.

[0229] FIG. 21 illustrates another example 2100 of a CTDMA procedure. As shown in FIG. 21, example 2100 may include APs 2102 and 2104 and STAs 2106, 2108 and 2109. AP 2102 and AP 2104 may be members of a multi -AP group. AP 2102 may be a sharing / master AP of the multi-AP group. AP 2104 may be a shared / slave AP of the multi-AP group. STA 2106 may be associated with AP 2102, and STA 2108 may be associated with AP 2104. STA 2109 maybe associated with AP 2102 or with another AP other than AP 2104 (not shown in FIG. 21). In example 2100, it is assumed that APs 2102, 2104 and STA 2108 are within communication range of each other. It is further assumed that STA 2106 is outside the communication range of AP 2104 but is within the communication range of AP 2102 and STA 2108. It is further assumed that STA 2109 is outside the communication ranges of AP 2104 and STA 2108 but is within the communication range of AP 2102.

[0230] As shown in FIG. 21, the procedure may begin with AP 2102 transmitting an MRTT frame 2112 after obtaining a TXOP 2110. In an implementation, MRTT frame 2112 may comprise an allocation for AP 2104. An allocation of MRTT frame 2112 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 2100, MRTT frame 2112 may comprise an allocation for AP 2104. The allocation may comprise a first duration (denoted tl in FIG. 21) of the TXOP allocated to AP 2104. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 2112. In an implementation, STA 2109 may have set its basic NAV (as shown by NAV value 2111 in FIG. 21), before the transmission of MRTT frame 2112 and for a duration longer than the first duration, on receiving a frame from an AP or a STA (not shown in FIG. 21) other than AP 2102, AP 2104, STA 2106, or STA 2108 (hereinafter called other AP / STA). In an implementation, a duration field of MRTT frame 2112 may indicate a second duration (denoted t2 in FIG. 21). The second duration indicated in the duration field of MRTT frame 2112 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 2112 to the second duration allows AP 2102 to protect a CTS frame and / or trigger frame of the shared AP.

[0231] In example 2100, on receiving MRTT frame 2112, STA 2106 may set its intra-BSS NAV (not shown in FIG. 21) to the second duration t2 indicated in MRTT frame 2112. On receiving MRTT frame 2112, STA 2108 may set its basic NAV (not shown in FIG. 21) to the second duration t2. On receiving MRTT frame 2112, AP 2104 may determine that AP 2102 has shared TXOP 2110 with AP 2104 for the duration tl. AP 2104 may transmit a CTS frame 2114 to AP 2102, in response to MRTT frame 2112.

[0232] On receiving CTS frame 2114, AP 2102 may set its intra-BSS NAV (not shown in FIG. 21) for the remaining duration of t2. After transmitting CTS frame 2114, AP 2104 may use the TXOP for the remaining duration of tl. In an example, AP 2104 may transmit a downlinkframe to STA 2108 (not shown in FIG. 21). In another example, AP 2104 may trigger STA 2108 to transmit an uplink frame to AP 2104.

[0233] In example 2100, after transmitting CTS frame 2114, AP 2104 may transmit a trigger frame 2116 to STA 2108 to trigger an uplink transmission from STA 2108. In an implementation, a duration field of trigger frame 2116 may indicate a third duration t3. On receiving trigger frame 2116, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 2116. Specifically, in example 2100, on receiving trigger frame 2116, AP 2102 may set its basic NAV (not shown in FIG. 21) to the third duration indicated in trigger frame 2116. However, being outside the communication range of AP 2104, STA 2106 may not receive trigger frame 2116 and may not set its basic NAV. Similarly, being outside the communication range of AP 2104, STA 2109 may not receive trigger frame 2116 and may not update its basic NAV to the third duration indicated in trigger frame 2116.

[0234] In an implementation, on receiving trigger frame 2116 and seeing its own address in the RA field of trigger frame 2116, STA 2108 may determine that it is to transmit an uplink frame to AP 2104. In an implementation, with trigger frame 2116 transmitted by AP 2104 with which STA 2108 is associated, STA 2108 may set its intra-BSS NAV (not shown in FIG. 21) to the third duration indicated in trigger frame 2116. In another implementation, STA 2108 may not set its intra-BSS NAV. Subsequently, STA 2108 may transmit a data frame 2118 to AP 2104. Data frame 2118 may include a duration field that indicates the remaining duration of the third duration. On receiving data frame 2118, STA 2106 may read the duration field of data frame 2118 and may set its basic NAV (as shown by NAV 2120 in FIG. 21) for the remaining duration of third duration. Being outside the communication range of STA 2108, STA 2109 may not receive data frame 2118 and may not update its basic NAV to the remaining duration of third duration indicated in data frame 2118. In response to data frame 2118, AP 2104 may transmit a BA frame 2122 to STA 2108.

[0235] In an example, after transmitting BA frame 2122 to STA 2108, AP 2104 may not have further uplink and / or downlink transmissions to perform within 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 a frame 2124 indicating a return by AP 2104 of the first duration to AP 2102 (or indicating truncation by AP 2104 of the first duration). In an example, frame 2124 may be a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2104. In an example, the CF-end frame may be a broadcast frame.

[0236] In example 2100, on receiving CF-end frame 2124, AP 2102 may reset its basic NAV to zero before the end of the third duration. AP 2102 may further 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) returns to being the holder of the TXOP. Being outside the communication range of AP 2104, STA 2106 may not receive CF-end frame 2124 and may not reset its basic NAV, which was set upon receiving data frame 2118 transmitted by STA 2008. On receiving CF-end frame 2124, STA 2108 may reset its intra-BSS NAV before the end of the third duration.

[0237] As AP 2102 owns the returned duration of the TXOP, AP 2102 may initiate uplink and / or downlink transmission for the remaining duration of TXOP 2110. In an implementation, AP 2102 may transmit a frame to allow its associated STAs to reset their basic NAVs, in the event that any of them still had a non-zero NAV. For example, an associated STA of AP 2102 that does not receive CF-end frame 2124 may still have a non-zero basic NAV. Such a STA may have set its basic NAV based on receiving a frame from a STA associated with AP 2104. This frame would have been triggered by a trigger frame from AP 2104. As such, in an implementation, AP 2102 may be configured to transmit a frame to its associated STAs to allow them to reset their basic NAVs, after / whenever AP 2102 receives a trigger frame from a shared AP, such as AP 2104, followed by a CF-end frame transmitted by the shared AP.

[0238] In accordance with this implementation, in example 2100, after receiving CF-end frame 2124, AP 2102 may transmit to STA 2106 a frame 2126 for resetting the basic NAV of STA 2106. In an implementation, frame 2126 may comprise a CF-end frame. In an implementation, the CF-end frame may comprise a transmitter address (TA) indicating an identifier of AP 2104 instead of an identifier of AP 2102. As such, when STA 2106 receives frame 2126, STA 2106 may determine that frame 2126 is an inter-BSS PPDU. STA 2106 may thus use frame 2126 to reset its basic NAV. In another implementation, frame 2126 may comprise 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. In an implementation, the trigger frame, the MRTT frame, or the RTS frame may comprise a basic NAV reset indication. Even though the trigger frame, the MRTT frame, or the RTS frame is an intra-BSS PPDU, the presence of the basic NAV reset indication in the frame allows the STA to reset its basic NAV. In an implementation, the basic NAV reset indication may be provided in one of the reserved bits (e.g., B22, B26, B53 or B63) of the common info field of the trigger frame or the MRTT frame as illustrated in FIG. 5 and FIG. 15, respectively. In another implementation, the basic NAV reset indication may be provided in a frame control field of the RTS frame. As shown in FIG. 21, on receiving frame 2126, STA 2106 may reset its basic NAV, before the end of the third duration (t3).

[0239] In example 2100, when AP 2102 transmits frame 2126 to STA 2106 or to other associated STAs of AP 2102 (not shown in FIG. 21) for resetting their basic NAVs, STA 2109 may also receive frame 2126. STA 2109 may determine that frame 2126 is an inter-BSS PPDU and may use frame 2126 to reset its basic NAV. As such, although the basic NAV of STA 2109 was set on receiving a frame from the other AP / STA, STA 2109 may reset its basic NAV on receiving frame 2126 from AP 2102. This eliminates or cancels the TXOP protection for the transmission from the other AP / STA, for which the basic NAV of STA 2109 was initially set.

[0240] After transmitting frame 2126, AP 2102 may transmit a frame 2128 to STA 2106 to initiate an uplink transmission. In an example, frame 2128 may be a trigger frame. On receiving frame 2128, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 2104 may set its basic NAV (not shown in FIG. 21) to a duration indicated in frame 2128. Similarly, STA 2108 may set its basic NAV (not shown in FIG. 21) to the duration indicated in frame 2128. If STA 2109 is an associated STA of a shared AP other than AP 2104, STA 2109 may set its basic NAV (not shown in FIG. 21) to the duration indicated in frame 2128. If the duration indicated in frame 2128 is shorter than the duration of NAV 2111, STA 2109 may interfere with the other AP / STA when its NAV returns to zero at the end of the duration indicated in frame 2128. If STA 2109 is an associated STA of AP 2102, STA 2109 may set its intra-BSS NAV (not shown in FIG. 21) to the duration indicated in frame 2128. With its basic NAV reset by frame 2126, STA 2109 may respond to frames from AP 2102 and may cause interference to the other AP / STA.

[0241] On receiving frame 2128 and seeing its own address in the RA field of frame 2128, STA 2106 may determine that it is to transmit an uplink frame to AP 2102. STA 2106 may set its intra-BSS NAV (not shown in FIG. 21) to the duration indicated in frame 2128. In another implementation, STA 2106 may not set its intra-BSS NAV. In response to frame 2128, STA 2106 may transmit a frame 2130 to AP 2102. In an example, frame 2130 may be a data frame. In an implementation, frame 2130 may include a duration field that indicates the remainder of the duration indicated frame 2128. In an example, after receiving frame 2130, AP 2102 may transmit a BA frame to STA 2106 (not shown in FIG. 21) and may continue uplink and / or downlink transmissions within TXOP 2110. In another example, AP 2102 may share a remaining portion of TXOP 2110 with another shared AP.

[0242] As illustrated in example 2100, when a shared AP returns the TXOP to a sharing AP before the end of the shared TXOP, the sharing AP may aid a first STA outside the communication range of the shared AP to reset its basic NAV set based on a frame transmitted by the shared AP or by a STA associated with the shared AP. This allows the first STA totransmit uplink traffic to the sharing AP when triggered by the shared AP. However, the sharing AP may, by the same action, cause a second STA (which may be associated with the sharing AP or with another shared AP) to reset its basic NAV even when the second STA did not set its basic NAV based on a frame transmitted by the shared AP or by a STA associated with the shared AP but based on a frame transmitted by another AP / STA. This may result in the second STA interfering with, instead of remaining silent during, a transmission by the other AP / STA.

[0243] Embodiments of the present disclosure, as further described below, address the abovedescribed problem. In one aspect, a first AP may receive from a first STA and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame. Based on the first frame indicating that the first STA has no buffered data for transmission to the first AP, the first AP may transmit to the first STA, a second frame that triggers transmission by the first STA of a first truncation frame. The first AP further transmits a second truncation frame. As such, a STA that set its basic NAV based on receiving a frame from the first AP and / or the first STA may reset its basic NAV. In contrast, a STA that set its basic NAV based on receiving a frame from another AP / STA may not reset or update its basic NAV. Accordingly, when the second AP returns to being the owner of the TXOP, the second AP may initiate uplink and / or downlink transmission for the remaining duration of the TXOP without affecting STAs that may have set their basic NAVs based on frame(s) received from another AP / STA.

[0244] FIG. 22 illustrates an example 2200 of a CTDMA procedure according to an embodiment. As shown in FIG. 22, example 2200 may include APs 2202 and 2204 and STAs 2206, 2208 and 2209. AP 2202 and AP 2204 may be members of a multi-AP group. AP 2202 may be a sharing / master AP of the multi-AP group. AP 2204 may be a 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. STA 2209 may be associated with AP 2202 or with another AP other than AP 2204 (not shown in FIG. 22). In example 2200, it is assumed that APs 2202, 2204 and STA 2208 are within communication range of each other. It is further assumed that STA 2206 is outside the communication range of AP 2204 but is within the communication range of AP 2202 and STA 2208. It is further assumed that STA 2209 is outside the communication ranges of AP 2204 and STA 2208 but is within the communication range of AP 2202.

[0245] As shown in FIG. 22, the procedure may begin with AP 2202 transmitting an MRTT frame 2212 after obtaining a TXOP 2210. In an embodiment, MRTT frame 2212 may comprise an allocation for AP 2204. An allocation of MRTT frame 2212 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 2200,MRTT frame 2212 may comprise an allocation for AP 2204. The allocation may comprise a first duration (denoted tl in FIG. 22) of the TXOP allocated to AP 2204. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 2212. In an embodiment, STA 2209 may have set its basic NAV (as shown by NAV value 2211 in FIG. 22), before the transmission of MRTT frame 2212 and for a duration longer than the first duration, on receiving a frame from an AP or a STA (not shown in FIG. 22) other than AP 2202, AP 2204, STA 2206, or STA 2208 (hereinafter called other AP / STA). In an embodiment, a duration field of MRTT frame 2212 may indicate a second duration (denoted t2 in FIG. 22). The second duration indicated in the duration field of MRTT frame 2212 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 2212 to the second duration allows AP 2202 to protect a CTS frame and / or trigger frame of the shared AP.

[0246] In example 2200, on receiving MRTT frame 2212, STA 2206 may set its intra-BSSNAV (not shown in FIG. 22) to the second duration t2 indicated in MRTT frame 2212. On receiving MRTT frame 2212, STA 2208 may set its basic NAV (not shown in FIG. 22) to the second duration t2. On receiving MRTT frame 2212, AP 2204 may determine that AP 2202 has shared TXOP 2210 with AP 2204 for the duration tl. AP 2204 may transmit a CTS frame 2214 to AP 2202, in response to MRTT frame 2212.

[0247] On receiving CTS frame 2214, AP 2202 may set its intra-BSS NAV (not shown in FIG. 22) for the remaining duration of t2. After transmitting CTS frame 2214, AP 2204 may use the TXOP for the remaining duration of tl. In an example, AP 2204 may transmit a downlink frame to STA 2208 (not shown in FIG. 22). In another example, AP 2204 may trigger STA 2208 to transmit an uplink frame to AP 2204.

[0248] In example 2200, after transmitting CTS frame 2214, AP 2204 may transmit a trigger frame 2216 to STA 2208 to trigger an uplink transmission from STA 2208. In an embodiment, a duration field of trigger frame 2216 may indicate a third duration t3. On receiving trigger frame 2216, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 2216. Specifically, in example 2200, on receiving trigger frame 2216, AP 2202 may set its basic NAV (not shown in FIG. 22) to the third duration indicated in trigger frame 2216. However, being outside the communication range of AP 2204, STA 2206 may not receive trigger frame 2216 and may not set its basic NAV. Similarly, being outside thecommunication range of AP 2204, STA 2209 may not receive trigger frame 2216 and may not update its basic NAV to the third duration indicated in trigger frame 2216.

[0249] In an embodiment, on receiving trigger frame 2216 and seeing its own address in the RA field of trigger frame 2216, STA 2208 may determine that it is to transmit an uplink frame to AP 2204. In an embodiment, with trigger frame 2216 transmitted by AP 2204 with which STA 2208 is associated, STA 2208 may set its intra-BSS NAV (not shown in FIG. 22) to the third duration indicated in trigger frame 2216. In another embodiment, STA 2208 may not set its intra-BSS NAV. Subsequently, STA 2208 may transmit a data frame 2218 to AP 2204. Data frame 2218 may include a duration field that indicates the remaining duration of the third duration. In an example, STA 2208 may not have further data for transmission to AP 2204 other than data contained in the frame body of data frame 2218. In another example, STA 2208 may not have further data for transmission to AP 2204. In an embodiment, data frame 2218 may comprise a buffer status report (BSR) indicating that STA 2208 has no buffered data for transmission to AP 2204. In another embodiment, data frame 2218 may comprise a more data (MD) field indicating that STA 2208 has no buffered data for transmission to AP 2204.

[0250] On receiving data frame 2218, STA 2206 may process the duration field of data frame 2218 and may set its basic NAV (as shown by NAV 2220 in FIG. 22) for the remaining duration of the third duration. Being outside the communication range of STA 2208, STA 2209 may not receive data frame 2218 and may not update its basic NAV to the remaining duration of the third duration indicated in data frame 2218. In response to data frame 2218, AP 2204 may transmit a BA frame 2222 to STA 2208.

[0251] In an example, after transmitting BA frame 2222 to STA 2208, AP 2204 may not have further downlink transmissions to perform within the remainder of the first duration allocated to AP 2204. In addition, AP 2204 may not have further uplink frames to receive within 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 an embodiment, AP 2204 may transmit a truncation frame for resetting the basic NAVs of STAs that may have set their basic NAVs based on receiving frames from AP 2204. Additionally, AP 2204 may trigger associated STAs to transmit similar truncation frames. This allows STAs outside the communication range of AP 2204, and that may have set their basic NAVs based on frames transmitted by the associated STAs during the first duration, to also reset their basic NAVs.

[0252] In example 2200, based on data frame 2218 indicating that STA 2208 has no buffered data for transmission to AP 2204, AP 2204 may transmit to STA 2208 a frame 2224 that triggers transmission by STA 2208 of a truncation frame 2226. In an example, frame 2224triggers transmission by STA 2208 of truncation frame 2226 a short inter-frame space (SIFS) after receiving frame 2224. In an example, frame 2224 may be a trigger frame. In another example, frame 2224 may be a polling frame. In an example, truncation frame 2226 may cause STA 2206 to reset its basic NAV, which STA 2206 may have set based on data frame 2218 transmitted by STA 2208. In an example, truncation frame 2226 may comprise a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2204. In an example, the CF-end frame may be a broadcast frame. On receiving truncation frame 2226, STA 2206 may reset its basic NAV to zero before the end of the third duration. On the other hand, STA 2209 may not receive truncation frame 2226 and therefore, STA 2209 may not reset its basic NAV set to NAV value 2211.

[0253] In example 2200, after transmitting frame 2224, AP 2204 may transmit a truncation frame 2228. In an example, truncation frame 2228 may reset a basic NAV of AP 2202 or a basic NAV of a STA associated with AP 2202. In an example, the basic NAV of AP 2202 may be set by data frame 2218. In another example, the basic NAV of an associated STA of AP 2202 may be set by data frame 2218. In another example, the basic NAV of AP 2202 may be set by trigger frame 2216. In an example, truncation frame 2228 may comprise a CF-end frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2204. On receiving truncation frame 2228, AP 2202 or a STA associated with AP 2202 may reset its basic NAV to zero before the end of the third duration. On the other hand, as STA 2209 may not receive truncation frame 2228, STA 2209 may not reset its basic NAV set to NAV value 2211.

[0254] In example 2200, transmitting truncation frame 2228, by AP 2204, may comprise transmitting truncation frame 2228 concurrently with the transmission of truncation frame 2226 by STA 2208. In another example, transmitting truncation frame 2228, by AP 2204, may comprise transmitting truncation frame 2228 simultaneously with the transmission of truncation frame 2226 by STA 2208. In another example, transmitting truncation frame 2228, by AP 2204, may comprise transmitting truncation frame 2228 a short interframe space (SIFS) after frame 2224. In another example, transmitting truncation frame 2228, by AP 2204, may comprise transmitting truncation frame 2228 during a time period that overlaps with the transmission of truncation frame 2226 by STA 2208. The main advantage of transmitting a truncation frame by AP 2204 during a time period that overlaps with the transmission of a truncation frame by STA 2208 is that AP 2202 may become the owner of the TXOP a SIFS after hearing the overlapping truncation frames, where the contents of the truncation frames are the same. AP 2202 may not need to assess if there are multiple truncation frames received.

[0255] In example 2200, AP 2202 may receive multiple truncation frames. In an example, AP 2202 may receive the truncation frames concurrently. In another example, AP 2202 may receive the truncation frames separated by a SIFS duration. On receiving truncation frame 2226 and / or truncation frame 2228, AP 2202 may reset its basic NAV to zero before the end of the third duration. AP 2202 may further 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) returns to being the holder of the TXOP. AP 2202 may transmit a frame 2230 to STA 2206 to initiate an uplink transmission. In an example, AP 2202 may transmit frame 2230 a SIFS after receiving truncation frame 2228. In another example, AP 2202 may transmit frame 2230 a point coordination function (PCF) IFS (PIFS) after receiving truncation frame 2228, where a PIFS is one slot time longer than a SIFS. In an example, frame 2230 may be a trigger frame. On receiving frame 2230, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 2204 may set its basic NAV (not shown in FIG. 22) to a duration indicated in frame 2230. Similarly, STA 2208 may set its basic NAV (not shown in FIG. 22) to the duration indicated in frame 2230. In addition, STA 2209 may update its basic NAV duration if the duration indicated in frame 2230 is longer than NAV value 2211. If the duration indicated in frame 2230 is shorter than NAV value 2211, STA 2209 maintains its basic NAV set to NAV value 2211.

[0256] On receiving frame 2230 and seeing its own address in the RA field of frame 2230, STA 2206 may determine that it is to transmit an uplink frame to AP 2202. STA 2206 may set its intra-BSS NAV (not shown in FIG. 22) to the duration indicated in frame 2230. In another embodiment, STA 2206 may not set its intra-BSS NAV. In response to frame 2230, STA 2206 may transmit a frame 2232 to AP 2202. In an example, frame 2232 may be a data frame. In an implementation, frame 2232 may include a duration field that indicates the remainder of the duration indicated frame 2230. In an example, after receiving frame 2232, AP 2202 may transmit a BA frame to STA 2206 (not shown in FIG. 22) and may continue uplink and / or downlink transmissions within TXOP 2210. In another example, AP 2202 may share a remaining portion of TXOP 2210 with another shared AP. As illustrated in example 2200, when a shared AP returns the TXOP to a sharing AP before the end of the shared TXOP (by transmitting a truncation frame), by having STAs associated with the shared AP also transmit truncation frames allows STAs that have set their basic NAVs based on the communication between the shared AP and its associated STAs to successfully reset their basic NAVs. The truncation frames however do not impact a STA that may have set its basic NAV based on a communication from another AP / STA that does not belong to the BSS of the shared AP. Sucha STA maintains its basic NAV as needed to protect the communication from the other AP / STA.

[0257] FIG. 23 illustrates an example 2300 of a CTDMA procedure according to an embodiment. As shown in FIG. 23, example 2300 may include APs 2302 and 2304 and STAs 2306, 2308 and 2309. AP 2302 and AP 2304 may be members of a multi-AP group. AP 2302 may be a sharing / master AP of the multi-AP group. AP 2304 may be a shared / slave AP of the multi-AP group. STA 2306 may be associated with AP 2302, and STA 2308 may be associated with AP 2304. STA 2309 may be associated with AP 2302 or with another AP other than AP 2304 (not shown in FIG. 23). In example 2300, it is assumed that APs 2302, 2304 and STA 2308 are within communication range of each other. It is further assumed that STA 2306 is outside the communication range of AP 2304 but is within the communication range of AP 2302 and STA 2308. It is further assumed that STA 2309 is outside the communication ranges of AP 2304 and STA 2308 but is within the communication range of AP 2302.

[0258] As shown in FIG. 23, the procedure may begin with AP 2302 transmitting an MRTT frame 2312 after obtaining a TXOP 2310. In an embodiment, MRTT frame 2312 may comprise an allocation for AP 2304. An allocation of MRTT frame 2312 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 2300, MRTT frame 2312 may comprise an allocation for AP 2304. The allocation may comprise a first duration (denoted tl in FIG. 23) of the TXOP allocated to AP 2304. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 2312. In an embodiment, STA 2309 may have set its basic NAV (as shown by NAV value 2311 in FIG. 23), before the transmission of MRTT frame 2312 and for a duration longer than the first duration, on receiving a frame from an AP or a STA (not shown in FIG. 23) other than AP 2302, AP 2304, STA 2306, or STA 2308 (hereinafter called other AP / STA). In an embodiment, a duration field of MRTT frame 2312 may indicate a second duration (denoted t2 in FIG. 23). The second duration indicated in the duration field of MRTT frame 2312 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 2312 to the second duration allows AP 2302 to protect a CTS frame and / or trigger frame of the shared AP.

[0259] In example 2300, on receiving MRTT frame 2312, STA 2306 may set its intra-BSS NAV (not shown in FIG. 23) to the second duration t2 indicated in MRTT frame 2312. On receiving MRTT frame 2312, STA 2308 may set its basic NAV (not shown in FIG. 23) to thesecond duration t2. On receiving MRTT frame 2312, AP 2304 may determine that AP 2302 has shared TXOP 2310 with AP 2304 for the duration tl . AP 2304 may transmit a CTS frame 2314 to AP 2302, in response to MRTT frame 2312.

[0260] On receiving CTS frame 2314, AP 2302 may set its intra-BSS NAV (not shown in FIG. 23) for the remaining duration of t2. After transmitting CTS frame 2314, AP 2304 may use the TXOP for the remaining duration of tl. In an example, AP 2304 may transmit a downlink frame to STA 2308 (not shown in FIG. 23). In another example, AP 2304 may trigger STA 2308 to transmit an uplink frame to AP 2304.

[0261] In example 2300, after transmitting CTS frame 2314, AP 2304 may transmit a trigger frame 2316 to STA 2308 to trigger an uplink transmission from STA 2308. In an embodiment, a duration field of trigger frame 2316 may indicate a third duration t3. On receiving trigger frame 2316, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 2316. Specifically, in example 2300, on receiving trigger frame 2316, AP 2302 may set its basic NAV (not shown in FIG. 23) to the third duration indicated in trigger frame 2316. However, being outside the communication range of AP 2304, STA 2306 may not receive trigger frame 2316 and may not set its basic NAV. Similarly, being outside the communication range of AP 2304, STA 2309 may not receive trigger frame 2316 and may not update its basic NAV to the third duration indicated in trigger frame 2316.

[0262] In an embodiment, on receiving trigger frame 2316 and seeing its own address in the RA field of trigger frame 2316, STA 2308 may determine that it is to transmit an uplink frame to AP 2304. In an embodiment, with trigger frame 2316 transmitted by AP 2304 with which STA 2308 is associated, STA 2308 may set its intra-BSS NAV (not shown in FIG. 23) to the third duration indicated in trigger frame 2316. In another embodiment, STA 2308 may not set its intra-BSS NAV. Subsequently, STA 2308 may transmit a data frame 2318 to AP 2304. Data frame 2318 may include a duration field that indicates the remaining duration of the third duration. In an example, STA 2308 may not have further data for transmission to AP 2304 other than data contained in the frame body of data frame 2318. In another example, STA 2308 may not have further data for transmission to AP 2304. In an embodiment, data frame 2318 may comprise a buffer status report (BSR) indicating that STA 2308 has no buffered data for transmission to AP 2304. In another embodiment, data frame 2318 may comprise a more data (MD) field indicating that STA 2308 has no buffered data for transmission to AP 2304.

[0263] On receiving data frame 2318, STA 2306 may process the duration field of data frame 2318 and may set its basic NAV (as shown by NAV 2320 in FIG. 23) for the remaining duration of the third duration. Being outside the communication range of STA 2308, STA 2309 may not receive data frame 2318 and may not update its basic NAV to the remaining durationof the third duration indicated in data frame 2318. In response to data frame 2318, AP 2304 may transmit a BA frame 2322 to STA 2308.

[0264] In an example, after transmitting BA frame 2322 to STA 2308, AP 2304 may not have further downlink transmissions to perform within the remainder of the first duration allocated to AP 2304. In addition, AP 2304 may not have further uplink frames to receive within 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 an embodiment, AP 2304 may transmit a truncation frame for resetting the basic NAVs of STAs that may have set their basic NAVs based on receiving frames from AP 2304. Additionally, AP 2304 may trigger associated STAs to transmit similar truncation frames. This allows STAs outside the communication range of AP 2304, and that may have set their basic NAVs based on frames transmitted by the associated STAs during the first duration, to also reset their basic NAVs.

[0265] In example 2300, based on data frame 2318 indicating that STA 2308 has no buffered data for transmission to AP 2304, AP 2304 may transmit to STA 2308 a frame 2324 that triggers transmission by STA 2308 of a truncation frame 2326. In an example, frame 2324 triggers transmission by STA 2308 of truncation frame 2326 a short inter-frame space (SIFS) after receiving frame 2324. In an example, frame 2324 may be a trigger frame. In another example, frame 2324 may be a polling frame. In an example, truncation frame 2326 may cause STA 2306 to reset its basic NAV, which STA 2306 may have set based on data frame 2318 transmitted by STA 2308. In an example, truncation frame 2326 may comprise a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2304. In an example, the CF-end frame may be a broadcast frame. On receiving truncation frame 2326, STA 2306 may reset its basic NAV to zero before the end of the third duration. On the other hand, STA 2309 may not receive truncation frame 2326 and therefore, STA 2309 may not reset its basic NAV set to NAV value 2311.

[0266] In example 2300, after transmitting frame 2324, AP 2304 may transmit a truncation frame 2328. In an example, truncation frame 2328 may reset a basic NAV of AP 2302 or a basic NAV of a STA associated with AP 2302. In an example, the basic NAV of AP 2302 may be set by data frame 2318. In another example, the basic NAV of an associated STA of AP 2302 may be set by data frame 2318. In another example, the basic NAV of AP 2302 may be set by trigger frame 2316. In an example, truncation frame 2328 may comprise a CF-end frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2304. On receiving truncation frame 2328, AP 2302 or a STA associated with AP 2302 may reset its basic NAV to zero before the end of the third duration. On the other hand, as STA 2309 maynot receive truncation frame 2328, STA 2309 may not reset its basic NAV set to NAV value 2311.

[0267] In example 2300, AP 2304 may transmit truncation frame 2328 a short interframe space (SIFS) after transmission of truncation frame 2326 by STA 2308.

[0268] In example 2300, AP 2302 may receive one or more truncation frames. In an example, AP 2302 may only receive truncation frame 2328 and may reset its basic NAV based on truncation frame 2328. In another example, AP 2302 may receive truncation frames 2326 and 2328, separated by a SIFS duration. On receiving truncation frame 2326 and / or truncation frame 2328, AP 2302 may reset its basic NAV to zero before the end of the third duration. AP 2302 may further 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) returns to being the holder of the TXOP. AP 2302 may transmit a frame 2330 to STA 2306 to initiate an uplink transmission. In an example, AP 2302 may transmit frame 2330 a SIFS after receiving truncation frame 2328. In another example, AP 2302 may receive multiple truncation frames separated from each other by a SIFS duration. AP 2302 may determine a last truncation frame of the multiple truncation frames and may transmit frame 2330 a PIFS (where a PIFS is one slot time longer than a SIFS) after receiving the last truncation frame. In an implementation, AP 2302 may determine the last truncation frame as the truncation frame that AP 2302 does not receive a further truncation after it, e.g., after waiting for at least a SIFS duration after receiving the truncation frame. In an example, frame 2330 may be a trigger frame. On receiving frame 2330, an OBSS AP or an OBSS STA may set its basic NAV. For example, AP 2304 may set its basic NAV (not shown in FIG. 23) to a duration indicated in frame 2330. Similarly, STA 2308 may set its basic NAV (not shown in FIG. 23) to the duration indicated in frame 2330. In addition, STA 2309 may update its basic NAV duration if the duration indicated in frame 2330 is longer than NAV value 2311. If the duration indicated in frame 2330 is shorter than NAV value 2311, STA 2309 maintains its basic NAV set to NAV value 2311.

[0269] On receiving frame 2330 and seeing its own address in the RA field of frame 2330, STA 2306 may determine that it is to transmit an uplink frame to AP 2302. STA 2306 may set its intra-BSS NAV (not shown in FIG. 23) to the duration indicated in frame 2330. In another embodiment, STA 2306 may not set its intra-BSS NAV. In response to frame 2330, STA 2306 may transmit a frame 2332 to AP 2302. In an example, frame 2332 may be a data frame. In an implementation, frame 2332 may include a duration field that indicates the remainder of the duration indicated frame 2330. In an example, after receiving frame 2332, AP 2302 may transmit a BA frame to STA 2306 (not shown in FIG. 23) and may continue uplink and / or downlink transmissions within TXOP 2310. In another example, AP 2302 may share aremaining portion of TXOP 2310 with another shared AP. As illustrated in example 2300, when a shared AP returns the TXOP to a sharing AP before the end of the shared TXOP (by transmitting a truncation frame), by having STAs associated with the shared AP also transmit truncation frames allows STAs that have set their basic NAVs based on the communication between the shared AP and its associated STAs to successfully reset their basic NAVs. The truncation frames however do not impact a STA that may have set its basic NAV based on a communication from another AP / STA that does not belong to the BSS of the shared AP. Such a STA maintains its basic NAV as needed to protect the communication from the other AP / STA

[0270] FIG. 24 illustrates an example 2400 of a CTDMA procedure according to an embodiment. As shown in FIG. 24, example 2400 may include APs 2402 and 2404 and STAs 2406, 2408 and 2409. AP 2402 and AP 2404 may be members of a multi-AP group. AP 2402 may be a sharing / master AP of the multi-AP group. AP 2404 may be a shared / slave AP of the multi-AP group. STA 2406 may be associated with AP 2402, and STA 2408 may be associated with AP 2404. STA 2409 may be associated with AP 2402 or with another AP other than AP 2404 (not shown in FIG. 24). In example 2400, it is assumed that APs 2402, 2404 and STA 2408 are within communication range of each other. It is further assumed that STA 2406 is outside the communication range of AP 2404 but is within the communication range of AP 2402 and STA 2408. It is further assumed that STA 2409 is outside the communication ranges of AP 2404 and STA 2408 but is within the communication range of AP 2402.

[0271] As shown in FIG. 24, the procedure may begin with AP 2402 transmitting an MRTT frame 2412 after obtaining a TXOP 2410. In an embodiment, MRTT frame 2412 may comprise an allocation for AP 2404. An allocation of MRTT frame 2412 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 2400, MRTT frame 2412 may comprise an allocation for AP 2404. The allocation may comprise a first duration (denoted tl in FIG. 24) of the TXOP allocated to AP 2404. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 2412. In an embodiment, STA 2409 may have set its basic NAV (as shown by NAV value 2411 in FIG. 24), before the transmission of MRTT frame 2412 and for a duration longer than the first duration, on receiving a frame from an AP or a STA (not shown in FIG. 24) other than AP 2402, AP 2404, STA 2406, or STA 2408 (hereinafter called other AP / STA). In an embodiment, a duration field of MRTT frame 2412 may indicate a second duration (denoted t2 in FIG. 24). The second duration indicated in the duration field of MRTT frame 2412 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the firstduration) after receiving the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 2412 to the second duration allows AP 2402 to protect a CTS frame and / or trigger frame of the shared AP.

[0272] In example 2400, on receiving MRTT frame 2412, STA 2406 may set its intra-BSS NAV (not shown in FIG. 24) to the second duration t2 indicated in MRTT frame 2412. On receiving MRTT frame 2412, STA 2408 may set its basic NAV (not shown in FIG. 24) to the second duration t2. On receiving MRTT frame 2412, AP 2404 may determine that AP 2402 has shared TXOP 2410 with AP 2404 for the duration tl. AP 2404 may transmit a CTS frame 2414 to AP 2402, in response to MRTT frame 2412.

[0273] On receiving CTS frame 2414, AP 2402 may set its intra-BSS NAV (not shown in FIG. 24) for the remaining duration of t2. After transmitting CTS frame 2414, AP 2404 may use the TXOP for the remaining duration of tl. In an example, AP 2404 may transmit a downlink frame to STA 2408 (not shown in FIG. 24). In another example, AP 2404 may trigger STA 2408 to transmit an uplink frame to AP 2404.

[0274] In example 2400, after transmitting CTS frame 2414, AP 2404 may transmit a trigger frame 2416 to STA 2408 to trigger an uplink transmission from STA 2408. In an embodiment, a duration field of trigger frame 2416 may indicate a third duration t3. On receiving trigger frame 2416, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 2416. Specifically, in example 2400, on receiving trigger frame 2416, AP 2402 may set its basic NAV (not shown in FIG. 24) to the third duration indicated in trigger frame 2416. However, being outside the communication range of AP 2404, STA 2406 may not receive trigger frame 2416 and may not set its basic NAV. Similarly, being outside the communication range of AP 2404, STA 2409 may not receive trigger frame 2416 and may not update its basic NAV to the third duration indicated in trigger frame 2416.

[0275] In an embodiment, on receiving trigger frame 2416 and seeing its own address in the RA field of trigger frame 2416, STA 2408 may determine that it is to transmit an uplink frame to AP 2404. In an embodiment, with trigger frame 2416 transmitted by AP 2404 with which STA 2408 is associated, STA 2408 may set its intra-BSS NAV (not shown in FIG. 24) to the third duration indicated in trigger frame 2416. In another embodiment, STA 2408 may not set its intra-BSS NAV. Subsequently, STA 2408 may transmit a data frame 2418 to AP 2404. Data frame 2418 may include a duration field that indicates the remaining duration of the third duration. In an example, STA 2408 may not have further data for transmission to AP 2404 other than data contained in the frame body of data frame 2418. In another example, STA 2408 may not have further data for transmission to AP 2404. In an embodiment, data frame 2418may comprise a buffer status report (BSR) indicating that STA 2408 has no buffered data for transmission to AP 2404. In another embodiment, data frame 2418 may comprise a more data (MD) field indicating that STA 2408 has no buffered data for transmission to AP 2404.

[0276] On receiving data frame 2418, STA 2406 may process the duration field of data frame 2418 and may set its basic NAV (as shown by NAV 2420 in FIG. 24) for the remaining duration of the third duration. Being outside the communication range of STA 2408, STA 2409 may not receive data frame 2418 and may not update its basic NAV to the remaining duration of third duration indicated in data frame 2418.

[0277] In an example, after receiving data frame 2418 from STA 2408, AP 2404 may not have further uplink and / or downlink transmissions to perform within the remainder of the first duration allocated to AP 2404. In an example, AP 2404 may not have further uplink frames to receive within the remainder of the first duration allocated to AP 2404. In an implementation, AP 2404 may return the remainder of the first duration to AP 2402 (also referred to as truncating the first duration). In an embodiment, AP 2404 may transmit a truncation frame for resetting the basic NAVs of STAs that may have set their basic NAVs based on receiving frames from AP 2404. Considering that there may be STAs outside the communication range of AP 2404 that may have set their basic NAVs based on communication between AP 2404 and its associated STAs such as STA 2408, AP 2404 may be configured to inform those associated STAs that may have transmitted frames in the first duration of (planned) truncation of the first duration.

[0278] In example 2400, based on data frame 2418 indicating that STA 2408 has no buffered data for transmission to AP 2404 and in response to data frame 2418, AP 2404 may transmit to STA 2408 a BA frame 2422 informing STA 2408 of truncation of the first duration at AP 2404. In an example, BA frame 2422 may include an indication for informing STA 2408 of truncation of the first duration at AP 2404, which may be provided in a frame control field, a BA control field, or a BA information field of BA frame 2422. In an example, after transmitting BA frame 2422, AP 2404 may transmit truncation frame 2424. In an example, truncation frame 2424 may be aggregated with BA frame 2422. In an example, truncation frame 2424 may cause a reset of a basic NAV of AP 2402 or of a STA associated with AP 2402. In an example, the basic NAV of AP 2402 may be set by data frame 2418. In another example, the basic NAV of an associated STA of AP 2402 may be set by data frame 2418 (not shown in FIG. 24). In another example, AP 2404 may transmit to STA 2408 and during the portion of the TXOP shared with AP 2404 by AP 2402, trigger frame 2416. As such, the basic NAV of AP 2402 may be set by trigger frame 2416. In an example, truncation frame 2424 may comprise a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise atransmitter address (TA) indicating AP 2404. On receiving truncation frame 2424, AP 2402 may reset its basic NAV to zero before the end of the third duration. On the other hand, STA 2409 may not receive truncation frame 2424 and therefore, STA 2409 may not reset its basic NAV set to NAV value 2411. Similarly, STA 2406 may not receive truncation frame 2424 and therefore, STA 2406 may not reset its basic NAV set to NAV value 2420.

[0279] In example 2400, STA 2408 may transmit truncation frame 2426 after the transmission of truncation frame 2424 by AP 2404. In an embodiment, STA 2408 may transmit truncation frame 2426 a short interframe space (SIFS) after the transmission of truncation frame 2424. In another embodiment, STA 2408 may transmit truncation frame 2426 a SIFS after the transmission of truncation frame 2424, where truncation frame 2424 is aggregated with BA frame 2422. In an example, truncation frame 2426 may cause a reset of a basic NAV of STA 2406, which STA 2406 may have set based on data frame 2418. In an example, truncation frame 2426 may comprise a contention free-end (CF-end) frame. In an example, the CF-end frame may comprise a transmitter address (TA) indicating AP 2404. In an example, the CF- end frame may be a broadcast frame. On receiving truncation frame 2426, STA 2406 may reset its basic NAV to zero before the end of the third duration. On the other hand, STA 2409 may not receive truncation frame 2426 and therefore, STA 2409 may not reset its basic NAV set to NAV value 2411.

[0280] In another example (not shown in FIG. 24), STA 2408 may transmit truncation frame 2426 after receiving BA frame 2422 and before the transmission of truncation frame 2424 by AP 2404.

[0281] In example 2400, AP 2402 may receive one or more truncation frames. In an example, AP 2402 may only receive truncation frame 2424 and reset its basic NAV. In another example, AP 2402 may receive truncation frames 2424 and 2426, separated by a SIFS duration. On receiving truncation frame 2424 and / or truncation frame 2426, AP 2402 may reset its basic NAV to zero before the end of the third duration. AP 2402 may further determine that AP 2404 has returned the first duration to AP 2402. With the return of the first duration to AP 2402, AP 2402 (which is the owner of the TXOP) returns to being the holder of the TXOP. AP 2402 may transmit a frame 2428 to STA 2406 to initiate an uplink transmission. In an example, AP 2402 may transmit frame 2428 a SIFS after receiving truncation frame 2426. In another example, AP 2402 may receive multiple truncation frames separated from each other by a SIFS duration. AP 2402 may determine a last truncation frame of the multiple truncation frames and may transmit frame 2428 a PIFS (where a PIFS is one slot time longer than a SIFS) after receiving the last truncation frame. In an implementation, AP 2402 may determine the last truncation frame as the truncation frame that AP 2402 does not receive a further truncation after it, e.g.,after waiting for at least a SIFS duration after receiving the truncation frame. In an example, frame 2428 may be a trigger frame. On receiving frame 2428, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 2404 may set its basic NAV (not shown in FIG. 24) to a duration indicated in frame 2428. Similarly, STA 2408 may set its basic NAV (not shown in FIG. 24) to the duration indicated in frame 2428. In addition, STA 2409 may update its basic NAV duration if the duration indicated in frame 2428 is longer than NAV value 2411. If the duration indicated in frame 2428 is shorter than NAV value 2411, STA 2409 maintains its basic NAV set to NAV value 2411.

[0282] On receiving frame 2428 and seeing its own address in the RA field of frame 2428, STA 2406 may determine that it is to transmit an uplink frame to AP 2402. STA 2406 may set its intra-BSS NAV (not shown in FIG. 24) to the duration indicated in frame 2428. In another embodiment, STA 2406 may not set its intra-BSS NAV. In response to frame 2428, STA 2406 may transmit a frame 2430 to AP 2402. In an example, frame 2430 may be a data frame. In an implementation, frame 2430 may include a duration field that indicates the remainder of the duration indicated frame 2428. In an example, after receiving frame 2430, AP 2402 may transmit a BA frame to STA 2406 (not shown in FIG. 24) and may continue uplink and / or downlink transmissions within TXOP 2410. In another example, AP 2402 may share a remaining portion of TXOP 2410 with another shared AP. As illustrated in example 2400, when a shared AP returns the TXOP to a sharing AP before the end of the shared TXOP (by transmitting a truncation frame), by having STAs associated with the shared AP also transmit truncation frames allows STAs that have set their basic NAVs based on the communication between the shared AP and its associated STAs to successfully reset their basic NAVs. The truncation frames however do not impact a STA that may have set its basic NAV based on a communication from another AP / STA that does not belong to the BSS of the shared AP. Such a STA maintains its basic NAV as needed to protect the communication from the other AP / STA

[0283] FIG. 25 illustrates an example process 2500 according to an embodiment. Example process 2500 is provided for the purpose of illustration only and is not limiting. Example process 2500 may be performed by a first AP, such as AP 2204, AP 2304, or AP 2404 for example.

[0284] As shown in FIG. 25, process 2500 may include, in step 2510, receiving, by the first AP from a first STA and during a portion, of a TXOP, shared with the first AP by a second AP, a first frame. In an embodiment, the first frame may comprise a data frame. In an embodiment, the data frame may comprise a buffer status report (BSR) indicating that the first STA has no buffered data for transmission to the first AP. In another embodiment, the dataframe may comprise a more data (MD) field indicating that the first STA has no buffered data for transmission to the first AP.

[0285] Process 2500 may further include, in step 2520, based on the first frame indicating that the first STA has no buffered data for transmission to the first AP: transmitting, by the first AP to the first STA, a second frame that triggers transmission by the first STA of a first truncation frame; and transmitting, by the first AP, a second truncation frame. In an embodiment, the first truncation frame may be for resetting a first basic network allocation vector (NAV) of a second STA. In an embodiment, the first basic NAV of the second STA may be set by the first frame. In an embodiment, the first truncation frame may comprise a Contention Free-End (CF-End) frame. In an embodiment, the CF-End frame may comprise a transmitter address (TA) indicating the first AP. In an embodiment, the second STA may be associated with the second AP.

[0286] In an embodiment, the second truncation frame may for resetting a second basic NAV of a third STA. In an embodiment, the second truncation frame may comprise a Contention Free-End (CF-End) frame. In an embodiment, the CF-End frame may comprise a transmitter address (TA) indicating the first AP. In an embodiment, the second basic NAV of the third STA may be set by the first frame. In another embodiment, process 2500 may further comprise transmitting, by the first AP to the first STA and during the portion of the TXOP shared with the first AP by the second AP, a third frame. In an embodiment, the third frame may comprise a trigger frame. In an embodiment, the second basic NAV of the third STA may be set by the third frame. In an embodiment, the third STA may be associated with the second AP. In another embodiment, the third STA may comprise the second AP.

[0287] In an embodiment, the second frame may trigger transmission by the first STA of the first truncation frame a short inter-frame space (SIFS) after receiving the second frame. In an embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame concurrently with the transmission of the first truncation frame by the first STA. In another embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame simultaneously with the transmission of the first truncation frame by the first STA. In another embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame a short interframe space (SIFS) after the second frame. In another embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame during a time period that overlaps with the transmission of the first truncation frame by the first STA.

[0288] In another embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame a short interframe space (SIFS) after transmission of the first truncation frame by the first STA.

[0289] In another embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame before the transmission of the first truncation frame by the first STA. In an embodiment, transmitting the second truncation frame may comprise transmitting the second truncation frame a short interframe space (SIFS) before the transmission of the first truncation frame by the first STA. In an embodiment, process 2500 may further comprise transmitting a block acknowledgment (BA) frame before transmitting the second truncation frame. In an embodiment, the second truncation frame may be aggregated to the BA frame.

[0290] FIG. 26 illustrates another example process 2600 according to an embodiment. Example process 2600 is provided for the purpose of illustration only and is not limiting. Example process 2600 may be performed by a first STA, such as STA 2208, STA 2308, or STA 2408 for example.

[0291] As shown in FIG. 26, process 2600 may include, in step 2610, transmitting, by the first STA to a first AP and during a portion, of a TXOP, shared with the first AP by a second AP, a first frame, where the first frame indicates whether the first STA has buffered data for transmission to the first AP. In an embodiment, the first frame may comprise a data frame. In an embodiment, the data frame may comprise a buffer status report (BSR) indicating that the first STA has no buffered data for transmission to the first AP. In another embodiment, the data frame may comprise a more data (MD) field indicating that the first STA has no buffered data for transmission to the first AP.

[0292] Process 2600 may further include, in step 2620, receiving, by the first STA from the first AP, a second frame that triggers transmission by the first STA of a first truncation frame. In an embodiment, process 2600 may further comprise transmitting, by the first STA, the first truncation frame. In an embodiment, the first truncation frame may be for resetting a first basic network allocation vector (NAV) of a second STA. In an embodiment, the first basic NAV of the second STA may be set by the first frame. In an embodiment, the first truncation frame may comprise a Contention Free-End (CF-End) frame. In an embodiment, the CF-End frame may comprise a transmitter address (TA) indicating the first AP. In an embodiment, the second STA may be associated with the second AP.

[0293] In an embodiment, process 2600 may further comprise receiving, by the first STA from the first AP and during the portion of the TXOP shared with the first AP by the second AP, a third frame. In an embodiment, the third frame may comprise a trigger frame. In anembodiment, the third frame may set a second basic NAV of a third STA. In an embodiment, the third STA may be associated with the second AP. In another embodiment, the third STA may comprise the second AP.

[0294] In an embodiment, the second frame may trigger transmission by the first STA of the first truncation frame a short inter-frame space (SIFS) after receiving the second frame. In an embodiment, the first AP may transmit a second truncation frame, where transmitting the first truncation frame may comprise transmitting the first truncation frame after the second truncation frame. In another embodiment, the first AP may transmit a second truncation frame, where transmitting the first truncation frame may comprise transmitting the first truncation frame a short interframe space (SIFS) after the second truncation frame.

Claims

CLAIMS1. A method, compri sing : transmitting, by a first access point (AP) to a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; receiving, by the first AP from the first STA, a second frame in response to the first frame; based on the second frame indicating that the first STA has no buffered data for transmission to the first AP, transmitting, by the first AP to the first STA, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmitting, by the first AP, a second truncation frame for resetting a second basic NAV of a third STA.

2. A method, comprising: receiving, by a first access point (AP) from a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; based on the first frame indicating that the first STA has no buffered data for transmission to the first AP, transmitting, by the first AP to the first STA, a second frame that triggers transmission by the first STA of a first truncation frame; and transmitting, by the first AP, a second truncation frame.

3. The method of claim 2, wherein the first truncation frame is for resetting a first basic network allocation vector (NAV) of a second STA.

4. The method of claim 3, wherein the first basic NAV of the second STA is set by the first frame.

5. The method of any of claims 2-3, wherein the first truncation frame comprises a Contention Free-End (CF-End) frame.

6. The method of claim 5, wherein the CF-End frame comprises a transmitter address (TA) indicating the first AP.

7. The method of any of claims 3-6, wherein the second STA is associated with the second AP.

8. The method of any of claims 3-7, wherein the second truncation frame is for resetting a second basic NAV of a third STA.

9. The method of claim 8, wherein the second basic NAV of the third STA is set by the first frame.

10. The method of claim 8, further comprising transmitting, by the first AP to the first STA and during the portion of the TXOP shared with the first AP by the second AP, a third frame.

11. The method of claim 10, wherein the third frame comprises a trigger frame.

12. The method of any of claims 10-11, wherein the second basic NAV of the third STA is set by the third frame.

13. The method of any of claims 2-12, wherein the second truncation frame comprises a Contention Free-End (CF-End) frame.

14. The method of claim 13, wherein the CF-End frame comprises a transmitter address (TA) indicating the first AP.

15. The method of claim 8, wherein the third STA is associated with the second AP.

16. The method of claim 8, wherein the third STA comprises the second AP.

17. The method of any of claims 2-16, wherein the first frame comprises a data frame.

18. The method of claim 17, wherein the data frame comprises a buffer status report (BSR) indicating that the first STA has no buffered data for transmission to the first AP.

19. The method of claim 17, wherein the data frame comprises a more data (MD) field indicating that the first STA has no buffered data for transmission to the first AP.

20. The method of any of claims 2-19, wherein the second frame triggers transmission by the first STA of the first truncation frame a short inter-frame space (SIFS) after receiving the second frame.

21. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame concurrently with the transmission of the first truncation frame by the first STA.

22. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame simultaneously with the transmission of the first truncation frame by the first STA.

23. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame a short interframe space (SIFS) after the second frame.

24. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame during a time period that overlaps with the transmission of the first truncation frame by the first STA.

25. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame a short interframe space (SIFS) after transmission of the first truncation frame by the first STA.

26. The method of any of claims 2-20, wherein transmitting the second truncation frame comprises transmitting the second truncation frame before the transmission of the first truncation frame by the first STA.

27. The method of claim 26, wherein transmitting the second truncation frame comprises transmitting the second truncation frame a short interframe space (SIFS) before the transmission of the first truncation frame by the first STA.

28. The method of claim 27, further comprising transmitting a block acknowledgment (BA) frame before transmitting the second truncation frame.

29. The method of claim 28, wherein the second truncation frame is aggregated to the BA frame.

30. A method, comprising: receiving, by a first station (STA) from a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; transmitting, by the first STA to the first AP, a second frame in response to the first frame, wherein the second frame indicates whether the first STA has buffered data for transmission to the first AP; receiving, by the first STA from the first AP, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmitting, by the first STA, the first truncation frame.

31. A method, comprising: transmitting, by a first station (STA) to a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, wherein the first frame indicates whether the first STA has buffered data for transmission to the first AP; receiving, by the first STA from the first AP, a second frame that triggers transmission by the first STA of a first truncation frame.

32. The method of claim 31, further comprising transmitting, by the first STA, the first truncation frame.

33. The method of any of claims 31- 32, wherein the first truncation frame is for resetting a first basic network allocation vector (NAV) of a second STA.

34. The method of claim 33, wherein the first basic NAV of the second STA is set by the first frame.

35. The method of any of claims 31 - 34, wherein the first truncation frame comprises a Contention Free-End (CF-End) frame.

36. The method of claim 35, wherein the CF-End frame comprises a transmitter address (TA) indicating the first AP.

37. The method of any of claims 34 - 35, wherein the second STA is associated with the second AP.

38. The method of any of claims 31 - 37, further comprising receiving, by the first STA from the first AP and during the portion of the TXOP shared with the first AP by the second AP, a third frame.

39. The method of claim 38, wherein the third frame comprises a trigger frame.

40. The method of any of claims 38 - 39, wherein the third frame sets a second basic NAV of a third STA.

41. The method of claim 40, wherein the third STA is associated with the second AP.

42. The method of claim 40, wherein the third STA comprises the second AP.

43. The method of any of claims 31 - 42, wherein the first frame comprises a data frame.

44. The method of claim 43, wherein the data frame comprises a buffer status report (BSR) indicating that the first STA has no buffered data for transmission to the first AP.

45. The method of claim 44, wherein the data frame comprises a more data (MD) field indicating that the first STA has no buffered data for transmission to the first AP.

46. The method of any of claims 31 - 45, wherein the second frame triggers transmission by the first STA of the first truncation frame a short inter-frame space (SIFS) after receiving the second frame.

47. The method of any of claims 31 - 45, wherein the first AP transmits a second truncation frame, and wherein transmitting the first truncation frame comprises transmitting the first truncation frame after the second truncation frame.

48. The method of any of claims 31 - 45, wherein the first AP transmits a second truncation frame, and wherein transmitting the first truncation frame comprises transmitting the first truncation frame a short interframe space (SIFS) after the second truncation frame.

49. A computer-program product, storable on a computer-readable medium and arranged to, when run on a computer, execute the method of any claims 1 to 48.

50. A device, arranged to function in an access point (AP) of a wireless network, the device being arranged to: transmit, to a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; receive, from the first STA, a second frame in response to the first frame; based on the second frame indicating that the first STA has no buffered data for transmission to the device, transmit to the first STA, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; and transmit a second truncation frame for resetting a second basic NAV of a third STA.

51. A device, arranged to function in an access point (AP) of a wireless network, the device being arranged to: receive, from a first station (STA) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; based on the first frame indicating that the first STA has no buffered data for transmission to the device, transmit, to the first STA, a second frame that triggers transmission by the first STA of a first truncation frame; and transmit a second truncation frame.

52. A device, arranged to function in station (STA) of a wireless network, the device being arranged to: receive, from a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame; transmit, to the first AP, a second frame in response to the first frame, wherein the second frame indicates whether the first STA has buffered data for transmission to the first AP; receive, from the first AP, a third frame that triggers transmission by the first STA of a first truncation frame for resetting a first basic network allocation vector (NAV) of a second STA; andtransmit the first truncation frame.

53. A device, arranged to function in station (STA) of a wireless network, the device being arranged to: transmit, to a first access point (AP) and during a portion, of a transmission opportunity (TXOP), shared with the first AP by a second AP, a first frame, wherein the first frame indicates whether the first STA has buffered data for transmission to the first AP; receive, from the first AP, a second frame that triggers transmission by the first STA of a first truncation frame.

Images